IS20 - Token Standard - Decentralised and Interoperable

Developers
2

This is really exciting stuff. A lot of work has clearly been put in.

High-level comments & questions:

  • The auction idea is really interesting. The core issue is that transaction fees are collected in the native token, but canisters run on cycles. Auctions are a really smart way to exchange native tokens for cycles. The way you set up the auction (i.e. your cut of the fees depends on your cycle bid relative to others) means that there is theoretically no upper bound to the # of cycles that a token canister can collect in an auction. It does, however, still depend on how much the community values the token. People will not bid more than they think the token (or their estimated cut) is worth.

  • Do you expect token owners to blackhole their canister from day one? How will future extensions be handled? For example, I imagine there are many variations of auctions that can be run, and the current proposed auction may turn out to not be the version that wins in the end. If I blackhole my token canister, then I wouldn’t be able to upgrade my canister to take advantage of a better auction variation. In that case, do I just create a new token and migrate the old token balances to the new token canister?

  • You mention that IS20 will support both an ERC20-like approve / transferFrom flow as well as an ICP ledger-like transfer / notify flow. Which flow will the InfinitySwap DEX use to swap its users’ tokens? What are the security tradeoffs between using one flow or another, or are they used for different purposes? One example is that for transfer / notify the recipient canister may be offline or out-of-cycles when notify is called; but it’s possible the sender already transferred the tokens.

Low-level comments & questions:

  • inspect_message only works on update calls, not queries. That’s fine for now, as queries don’t consume cycles. However, this apparently will change in the future, so hopefully inspect_message can be updated to support queries as well (if that is even technically possible).

  • Why do you give owners the power to setMinCycles? Can’t the minimum # of cycles needed to run the auction be estimated algorithmically?

  • If a token canister has extra cycles left over from the previous auction, can it choose to skip the current auction and accumulate those fees for use during future periods of “famine”?

  • Will InfinitySwap run its own factory canister?

  • Transaction history seems to be stored on a single canister right now. While it is saved to stable memory between upgrades and stable memory is capped at 300 GB, that full 300 GB can’t be used currently because it is also loaded into wasm memory post-upgrade, and wasm memory remains capped at 4 GB. That might not be enough to store a token’s entire transaction history. Do you have plans on a BigMap-like storage solution where transaction history is sharded across multiple canisters? I believe the ICP ledger canister currently does that. Another solution is to have the token canister read and write directly to stable memory to utilize the full 300 GB, but that will incur performance overhead.

  • Balance queries (and other sensitive queries) should ideally use certified variables to ensure that users are getting the right data. Is that on the roadmap? The ICP ledger canister also does this.

6 Likes