Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Warn user when sending non-ADA tokens in the same UTXO to Enterprise Address. #3155

Open
junderw opened this issue Apr 6, 2023 · 3 comments
Assignees

Comments

@junderw
Copy link

junderw commented Apr 6, 2023

I work for a Japanese exchange that supports ADA deposits and withdrawals.

Our policy (clearly stated on our website in red letters when showing the deposit address) is to reject all UTXOs that contain non-ADA assets or a plutus datum hash.

Anything other than a simple send of ADA is rejected, and we require customers to send us a support ticket and pay a significant fee to get one of our engineers to manually refund the tokens. (This is also in our policy)

We have seen an increased frequency of cases where the customer says "I don't know what that means, I just told my Yoroi wallet to send ADA, I don't know what this other token is!!!"


I am not trying to point fingers here, I merely would like to fix what I see is a UX issue that requires the ADA wallet projects to make the distinction between ADA and non-ADA tokens clearer to the user.

We are open to any suggestions for how we should change the UX on our end, but keep in mind that we can't custody tokens for customers that we don't support, and if we deem the UTXO worthy of depositing ADA, we are also technically deeming it worthy for us to custody the other token... so we're kind of stuck here.

It would be great if the govt. just said "ok you can support any token that anyone makes on Cardano!" but unfortunately that is not the case.

For now, the only people suffering are the customers. A simple confirmation screen would help immensely.

Also, just so you are aware, our deposit addresses are enterprise addresses which don't contain a staking key... so maybe the warning could be restricted to just sending to enterprise addresses? (just an idea)

I look forward to any feedback.

@junderw
Copy link
Author

junderw commented Apr 6, 2023

Looking into the matter further, it seems like there is a common thread is users "unstaking everything" into our deposit address, which results in a UTXO with ADA and non-ADA tokens all mixed together.

It would be better if they unstake into their yoroi wallet first, then send only ADA to us.

@junderw
Copy link
Author

junderw commented Apr 6, 2023

Also, our deposit addresses are all cold multisig, and moving funds outside of pre-determined whitelists requires a firmware update (which we won't develop, as it would lower security) requires multiple human interventions (thus the hefty fee for recovery) and steps.

So "just send the tokens back" is not a viable solution on our end.

@junderw
Copy link
Author

junderw commented Apr 28, 2023

Looking into the issue further, an increasing number of instances has been occurring, and every single time the customer was unaware that native assets were being sent. (They didn't even know they had native assets)

The common thread is that people using Yoroi are having issues.

Upon checking every successful deposit into our system, I notice a trend of change outputs with 1.1 ADA and a bunch of native assets.

It seems as though the "Send Max" feature on Ledger Live will create a ~1.1 ADA change output to place all the native assets unless the user explicitly adds one-by-one each native asset they own.

Meanwhile, the Yoroi UI just says in green letters "This will send all ADA and all tokens"

A user not aware what "all tokens" is referring to will just assume that it's just a poor Japanese translation of "Send all ADA"


I suggest Yoroi should default to creating a change output for tokens when clicking send all, and should create a change output for tokens when unstaking (if possible).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants