I’m really excited to see you all already working on standardizing token interfaces.
I run the team that designed and built ICP, I hope we can find a standard that can work for you guys and ICP can adopt.
If we agree on a standard, not only will canisters be able to integrate new tokens easily, but also any centralized exchange that currently supports ICP will be able to support any other token with almost no technical work through our Rosetta API node.
I really need to write an article explaining the design of ICP some time because I think it will help people designing their own tokens.
ICP is pretty bare bones in terms of functionality, we put just enough into the contract to allow staking and exchange integration. The idea is that for everything else that you need you should be transferring funds into other canisters, so for example if you want ERC 20 functionality create an ERC 20 canister with the appropriate methods, transfer your tokens to a sub-account of that canister and let it manage them.
One of the big issues when designing a token is the memory limit on a single canister, so you either have to effectively shard your token or work hard to limit the amount of storage your data structures will use. This is why we didn’t follow ERC 20 on the ICP canister. I was concerned that an attacker could use approve to use O(number of accounts^2) storage space on the ICP canister.
The account identifier vs principal ID argument is a good one, we did it mainly to keep the cost of storage down, most of our transaction fee is going to go towards the costs of long term storage of transactions and storing Hash(Principal ID, Subaccount) vs (Principal ID, Subaccount) knocked about 25% off the transaction size. I’m not 100% sure it was the right decision because it makes it much less clear what’s going on in the ledger and makes integrations a bit more complicated with only a small gain in privacy so don’t feel obliged to cargo cult that one. Back of the envelope even on a large subnet ICP transactions should only cost about 0.001c, so 20% on top of that probably isn’t worth worrying about.
Oh and if you’re planning to deploy a token right now, use Rust. Currently the motoko GC has real problems running lots of small update calls on big heaps which is exactly the kind of workloads that tokens have.
I look forward to seeing this develop and let me know if anyone has any questions!