Guys just wanted to get a feel of community and see if we all are thinking alike or differently.
I have purposefully omitted NashCash & NashPay from this poll as I think its an addition which can be included when its ready or approved.
Let us know which one of these issue is most important to you for making Nash Exchange in its current iteration more usable and reaches wider audience.
In other words which one of these should be prioritized.
I think this transfer bug has to be number one. This is the kind of thing that will make people walk straight out the door with the exchange. It will also put huge pressure on the Support team once GA is rolled out.
What’s the use of this poll exactly? These issues should all be adressed. However, the team is already aware of the issues above mentioned and are busy working on them.
I see, well personally i’m waiting for some documentation how i could get a market maker bot running smoothly on the platform. I’ve tried to set it up with the documentantion Fabio provided, but couldn’t get it running unfortunately. As i’m not a big player in the space i don’t think it’s a big prio for the team, but it would be nice to use the platform some more and bring some liquidity
Thing is, priority doesn’t matter. You don’t have the entire team tackle issues singularly, one at a time. Obviously that would only bottleneck development, as assigning more engineers to a particular issue doesn’t necessarily guarantee faster results; poor allocation of resources would drastically slow down progress.
Best approach is to address all of those things simultaneously, which I assume is exactly what they’re doing. Having 6 teams each deliver something important with a 6-month time frame is better than having 1-2 teams fumbling over the most important feature and delivering 1-2 things every 2-3 months. They could hire more people to try and tackle those things, but I think the effort would be better spent forming a hypothetical 7th team and delivering something good within that 6-month time frame.
The biggest addition that would help to reach a wider audience, in my opinion, would be sending & receiving funds to other users within the contract wallets, via typing in their email. Followed by fiat ramps. Followed by a good bot for algorithmic trading. None of these are on the list, but are the most important for gaining traction and building momentum (the transfer issue doesn’t impact any of these things, and I’d classify them as non-existence issues of important features, but I don’t consider them an issue because I know it’s better to carefully time the release of such things).
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.
go for a kill 
