Strictly for research purposes. And maybe some engagement! We need to lighten up the mood little bit.
1 Like
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
1 Like
I agree. Nashcasino was fun till the time it lasted. I hope it comes back soon
In terms of priority (of those items) I’d say:
- Flawless Transfers
- Trading Bot
- Mobile Trading + Marketing
- Additional Trading Pairs.
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).
4 Likes
Yes trading bot should have been in the list!
1 Like
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.
33 Likes
So what we can do as users to avoid such issues while doing transfers?
1 Like
Open a ticket Rahil 
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 
6 Likes
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.
2 Likes
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.
18 Likes
Hello Fabio,
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.
1 Like
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.
12 Likes
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.
8 Likes
Understandable, thank you and keep up the good work 
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.
1 Like
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.
12 Likes
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.
8 Likes