Account Identifiers origin recognition system

I was wondering for a while, how can I recognize if an Account Identifier is from my dapp or from another one. I found a solution, but I will walk you through the process first.

The benefits are a lot. It would be helpful if we wanted to warn the user, that sending to an account, which may belong to another dapp, may not support the token you are sending.

Sending fungible or non-fungible tokens to an address that doesn’t support them is kind of trapping them.
Retrieving them back without dapp developers doing something, will require one to take the dapps session private keys and use them in their own custom script. Hardly a good user experience.

The solutions which WON’T work:

  • One solution would be, to keep a list of all addresses the dapp ever created inside a canister and query it, but that is hitting a lot of bad design checkboxes.

  • Another would be to prefix addresses like NFTAf24380db6b95c504626c9e827c61e4ff42ce5e064f4e012585640868d831c61e
    which would work if it was part of the standard, but it’s not. So while it can work within your dapp, trying to send to an account like that from Binance will result in an error.

  • The address is actually a crc32 checksum + sha224 hash. These are also one-way functions and you cant find the subaccount or any of the inputs

What’s left - If you ever played with one of those scripts which create vanity names, they are creating a ton of addresses and checking if the first letters match your input text.

So I made the same thing and tried to find IC addresses with javascript in a web browser.
Luckily even with an unoptimized algorithm, I got tens of hits within one second of calculations while looking for “888”

88844ace381131a49b3630175da87441caad91e6d67ea68c6188bb3dd7700d56
8889e06b2fdcc8abc4a70fd0bf2a3a21db227fea1bc7ea779292ef0468445f74
888c587feb0a65c942bde330b9811c787a8010425695a5530771979c33143068
8885b7373aabe4f7c3f3174138c9fe9bfc207e5010de1efa972ef8ba02f1c5bc
88887ef99ff547008c7a6a43114db860b1e6fd7f3c7f093644f0c29c86cc0734
888f18494e1621cdf47bd2c2a1fde51336ffc712c88d0901de501969a519adaf
888879b01833eadebf0a3588179e2415e683d153ca68936b8ec1a432addf4fc6
888b7102eff7e79563036dd8a5604fbe4c1119aa8bdd6585b495c6e62a54f5e8
888967f1371259b1e9ae6a2874f6daa09c9206fec68f8a1a908d3bf711ad87b9
888f547c3448df6a00774559d8b4af65da0a3bd1c83eb3998a8d42e8777e08d9

I like that! Instead of developers creating accounts 0 subaccount, they will choose a prefix and search for it starting from subaccount 0,1,2,3,4… until it’s found.
From there on, when sending tokens to an address, the dapp will know with certainty that they do not belong, while having few false positives (unless everyone uses this system)

So what is next - Well, everyone can use that system without anyone’s permission and pick any prefix, but I suppose it’s best if we create a community-maintained canister which keeps these prefixes and who they belong to, along with a list of supported tokens.
Let me visualize it:

888 - EXT, ANV, DIP20
432 - DIP20
A00 - NFTA

If that’s done, when someone tries to send a token from one dapp to an unknown address. We could query that registry and ask which tokens the target dapp supports.

Anyway, I am calling dibs on A00 for Anvil :slight_smile:

4 Likes