While everyone wants things to move faster it is not taking long, completely the opposite. Maybe you don’t understand what is being built, let me try to enlighten. Nash is moving at blazing speed.
In a bit over 2 years (18mo since public offering) Nash has built a high performance state channels layer-2 that is cross-chain to Bitcoin (and compatible) networks, Ethereum (and compatible) and NEO (and compatible). There are projects idiots call fast running for 2x the time with 2x the funding to do a single layer-2 for a single blockchain that has worse performance and UX characteristics.
The issue on transfers is mainly on clients, not on Nash, there is no transfers bug. Clients have unreliable connection with the blockchain and do unreliable signing commitment. We are not solving a simple thing, we are building (and is mostly in the product already) a reliable transaction management system to take over user concerns, there are also full projects only dedicated to build watch towers and relay services for layer-2 networks.
That is not even to add we have also built and delivered a trading protocol on top of that layer-2, something there are complete projects dedicated to build, a payment protocol and a web and mobile clients to those that people frequently compare and expect to work like centralized counter-parties - which we aim and will be happy to achieve! So much that this is the expectation instead of the sign with the browser extension every interaction and keep watching explorers of most of the competition.
Regardless, I am not concerned of this delivery, it will be done - when I look at the team I see excess capacity to deliver the transaction system and even future possibilities to simplify it with protocol improvements. So much that as communicated during July most of our team is moving to growth focused tasks, that are concentrated around prime tools (like trading bots and affiliate systems) and inter-exchange (like standardized SDKs and layer-2 liquidity solutions), fitting our vision.
Guys we are here to support you, not complaining! I am amazed by the product and team. This is a good clarification for every user level to better understand the efforts that are given in building this product. Thank you Nash
team go for a kill
I do not say nothing is being build, i think nash is the most impressive dex/non custodial exchange out there.
But issues like those transfer things are hindering mass adoption. What i think takes long is the time before these issues are finally solved once and for all. Ofcource its all new cutting edge technology you as a company are building, but for us users it takes a long time now.
Could you perhaps then say if you hope to improve the connection with users or is there no improvements to be made, because a user interacts directly with the blockchain?
It seems hard to believe that when a user has internet connection and access to nash, that it then fails to send funds on their ends because for some reason the connection to the blockchain fails. Since the command/interaction is perhaps on nash, maybe it could auto-retry or refresh if status doesnt change or something? Thats speculation from my side though, i am not a coder. But if nash is interacting with the different blockchains and the user issues commands through nash, then it should be priority to solve that in my opinion. Bug or issue, it is a hinderance to the user…
Sorry for sounding like nothing has been build, though. Not my intention.
As the client, there are so many things that can happen. I will describe 3 most common ones, keep in mind this will change in very near future with the new transaction system so I might go back to this and strike-through.
First it depends on the direction, if you are depositing or withdrawing.
If you are depositing, your client might say to the nash server: “Hey, I am sending this amount of funds - here is the signature”
So the server will create a movement to that deposit (that appears as pending in your screen), but the client can fail - maybe the internet disconnected, a packet got lost or the user machine shutdown - and in that case the server will be waiting for a transaction that is never realized in the blockchain, so to solve this (most common) scenario if your client still has the transaction data in it you can try resend the transaction on the blockchain using this link.
If you are depositing, your client might say to the nash server: “Hey, I am sending this amount of funds - here is the signature, and I have sent it to the blockchain, here is the proof”
Than we you will need to contact support clicking here, because we will need to reconciliate this is not happening because for some reason the client was mistaken. As a security measure the server will only recognize the deposits it can see in the blockchain, what support can do is cancel this movement and say to the server “the user is not depositing”, whitout it the server will keep “waiting”.
The last most common case is if you are withdrawing you can be in a situation where like in the first case you didn’t sent the transaction due to some issue - in this case you can clear the site data on the browser, and than visit the same retry-transaction link and resend it. As the client will re-build the withdraw payload and try to send to the blockchain again.
As there are other cases, the recommendation is always to contact support. I tried to explain and simplified wait to much, but did my best to get the gist of it - as there is fairly technical and enthusiasts on the community I think this post will serve both.
Until than, maybe a support case can be created automatic by the system if it notices a pending transaction for more than 12h? Or maybe a hyperlink to the know issues and how quick fix them, as the links you provided.
Thats a awesome detailed reply, thanks.
Support can luckily always help if there is a issue here, thats a true point.
Can I ask if Nash also seeks to improve this further, in time? For example double checks in case of a packet loss, or asking users to send the signature twice etc.
The system already retry the transactions, and there is fairly amount of logic to automatic handle cases, the reliability of a user connection with blockchain means a lot more than just being in the internet when opening and closing state channels - that is why you should not say there is a transfer bug - first because there isn’t - second because we don’t know which failure case the user is hitting, he should be directed to contact support for now.
I agree the deposits and withdrawals being flawless is currently the main blocker and that is why there is a new system being delivered, while achieving perfection is not possible as we could even have a shark biting the cable when the server sends data it should drive error rates to be very low.
It might be an attack - the system is built under the assumption the client might be trying to take advantage of it. So is not something to automate how support works. There is no need to do make-shift solutions for it as we are already on final stages of a more durable one.
Fair enough. Its easy to make comparisions with other exchanges where transfers are more stable then. Thanks for showing its not a bug and indeed- keep up the good work.
Which exchange? Looks like you are comparing changing a database entry like posting in this forum to joining a layer-2 protocol on the blockchains. I agree the UX must be the same, and we must improve it to exceed the expectations - which we currently are not, but as members of this forum (stakers) we must be aware of the distinctions and talk about it as they are - if not this will just be misinformation.
Why not integrate the retry link in the app in the meantime though? I had to use it yesterday: it would have been better if I hadn’t had to scroll through my favorites to find the link. Also, someone not aware of the link would have had to contact support.
Maybe pedantic worries about security from our side - previous versions of the link would force a sync state. A sync state cannot be blind (trust the backend) so we didn’t want to promote a insecure path. For now just link this post I did above ([Poll] Which one of these should be on the top of priority list) if someone for some reason is reluctant to contact the support…
When the new system is online we will make sure to tell the community.
Ok. One aspect that I like about it is, not trying to dissimulate and alleviate the issue. Fixing the source of it is the way to go. I like that Nash team never settles for half-measures.
Switcheo comes to thought, that i use a lot. When i use it with o3, it also is far from perfect, but never had to contact support, a simply refresh fixes it all. But when using it with a private key (yeah i know about the security) then it works perfect.
And agreed on to combat misinformation, so again thanks for explaining how it all works so we can describe it as a issue, one that is still being improved, and not describe it as a bug anymore.
Switcheo is doing something very simple, is like the transfer to external on Nash, you form a transaction and send it - is one way. Has nothing to do with this case, that is why their matching performance is very low (a few per seconds), they are doing batching to the trading contract like IDEX to settle it.
go for a kill 
