Issue Regarding Ada Handles Resolving To a JPG Store Contract Address

[cardano-dev4]

A Cardano community member @SPCWV recently lost a series of very high value NFTs because their Ada handle resolved to a jpg store contract when sending a transaction. He said that he tried to send Ada to the handle that was in his other wallet and had not been touched in a long time, at first it said error saying something like the address is invalid, but after a few seconds it turned up green.

However the transaction that was built and submitted was actually the jpg store contract which the assets were sent too with no datum meaning they were lost forever.

https://cardanoscan.io/transaction/3fbd24730eef83de612ab01bf0a2e786f5eefac7a58ccaf06f702b96acbab635?tab=utxo

--- A similar story occurred yesterday on twitter with another user

https://twitter.com/banjoTheGamer/status/1763032678176088490

I believe these 2 are the same issue and there is something wrong with the resolution of Ada handles to the jpg store address if there is some sort of invalid error.

EDIT: It looks like it might not be ada handle resolution specifically as the second user was attempting to send to a Binance address which does not support handles

This is a major issue to Cardano community members so I hope this can be resolved ASAP. Let me know if you need more information.

EDIT 2: It does appear like the issue is specifically occurring around Ada Handles (not 100% sure but most occurrences seem to point to that with the above exception)

My suspicion is Charles's tweet is correct as if a user is typing in an Ada handle and has not finished typing yet, the unfinished handle is very likely to be in a jpg contract which would have the address render to the contract address. I have seen this issue render addresses to both Jpg v1 and v2 contracts which means it isn't some sort of Nami address book

https://x.com/IOHK_Charles/status/1763961206917021811?s=20

[thaddeusdiamond]

There's a potential race condition in the way that handles are resolved that could be leading to this that I think is the culprit
https://x.com/WildTangz/status/1763596635139903714?s=20

Specifically, addresses being stored in React state are not being handled/cleared correctly. But, this may not have been the specific issue in this case.

[thaddeusdiamond]

The previous comment MAY be from a malicious actor ⚠️

• Do not click links ❌
• Do not reveal your recovery phrase (ever) ❌

This is an automated response aimed at protecting users from potential scams

Thanks for the warning but I'm not malicious and the link above is just a tweet. Please fix the problem so people don't lose their ADA.

[cardano-dev4]

There's a potential race condition in the way that handles are resolved that could be leading to this that I think is the culprit https://x.com/WildTangz/status/1763596635139903714?s=20

Specifically, addresses being stored in React state are not being handled/cleared correctly. But, this may not have been the specific issue in this case.

This is a good investigation, I haven't had time to look too deeply in it but it looks like its happening more:

https://x.com/DegenOm3n/status/1763659924251484367?s=20

Looks like this resolved to the jpg v2 contract, and also might be happening with non ada handles as well?

I have a bit more time this weekend ill be able to help with the investigation

[SmaugPool]

There's a potential race condition in the way that handles are resolved that could be leading to this that I think is the culprit https://x.com/WildTangz/status/1763596635139903714?s=20

Suspiciously, the debounce code was recently changed (awesome-debounce-promise package replaced by custom code):
5849891

[SmaugPool]

Note that transactions sent to jpg.store Plutus script addresses holding ada handles without a datum have basically always happened so the issue might not be new but it can also happen when doing a typo manually or when forgetting an handle has been listed.

That said it seems there's a slight increase recently:

select date_trunc('day',time),count(*) from tx_out join tx on tx_id=tx.id join block on block.id=block_id where address in ('addr1x8rjw3pawl0kelu4mj3c8x20fsczf5pl744s9mxz9v8n7efvjel5h55fgjcxgchp830r7h2l5msrlpt8262r3nvr8ekstg4qrx','addr1zxgx3far7qygq0k6epa0zcvcvrevmn0ypsnfsue94nsn3tgvp7yludr26w44pjv927202tt7ayffdwxjj688k690f03sr4chmz','addr1xxgx3far7qygq0k6epa0zcvcvrevmn0ypsnfsue94nsn3tfvjel5h55fgjcxgchp830r7h2l5msrlpt8262r3nvr8eks2utwdd','addr1zxgx3far7qygq0k6epa0zcvcvrevmn0ypsnfsue94nsn3tvpw288a4x0xf8pxgcntelxmyclq83s0ykeehchz2wtspks905plm','addr1zxj47sy4qxlktqzmkrw8dahe46gtv8seakrshsqz26qnvzypw288a4x0xf8pxgcntelxmyclq83s0ykeehchz2wtspksr3q9nx','addr1w999n67e86jn6xal07pzxtrmqynspgx0fwmcmpua4wc6yzsxpljz3') and data_hash is null group by date_trunc('day',time) order by date_trunc('day',time)

Ada handle support has been added in Nami in December 2021: 96b4025 and released in version 3.0.0 (https://github.com/input-output-hk/nami/releases/tag/3.0.0)

Lastly note that there are 35,682 listed on jpg.store out of 236,350. These is therefore a 15% chance for a random handle (like a misspelled or truncated one) to resolve into a jpg.store Plutus script address.

[SmaugPool]

Might be related (thanks nullHashPixel):
#487

[papag00se]

For reference, ADA Handles integration recommendations are called out here - https://mint.handle.me/verified-integration