Prebuilt ICRC wasm or write my own implementation for a token

Developers
1

Hey everyone,

I’m in the process of launching a token on the Internet Computer using the ICRC ledger, and I’m facing an important architectural decision:

Should I use a prebuilt WASM for the ICRC token standard, or should I go with a custom implementation?

Here’s the context:
I want the token to be flexible and upgradeable in the future, especially with potential upgrades to newer ICRC standards like ICRC-4, ICRC-5, etc. My thinking is that having my own implementation might make this easier, especially if I want to introduce additional features over time.

For example, I’m considering:

  • Rewarding early adopters with free tokens
  • Implementing an XP system where users earn XP and receive monthly token distributions based on their XP
  • Potentially more gamified or community-driven mechanics later on

I’m not sure how much flexibility the prebuilt WASM actually offers.

  • Can you extend or customize it before launch?
  • Is it possible to integrate custom logic like XP-based distributions with the prebuilt contract?
  • Or would it be better to fork the code and build in what I need from the start?

Am I overthinking this, or is going custom the right move if I care about long-term adaptability and unique token logic?

Would love to hear from those who’ve worked with the ICRC standards or launched similar projects!

Also if anyone has links to rust code that implement up-to icrc 3 that would be great. (Obvs dfinity one exists but is a little confusing since it is all separated and doesn’t feel complete)

Thanks :folded_hands:

1 Like
2

If I were you, I will create a new canister for distribute token instead modify this complex repo

you can see in this candid, it included icrc 1, 2, 3. Enough to be used by dapp

If you need future upgrade, why not create a new ledger and airdrop 1:1 to user

3

I would recommend to use the prebuilt WASM. this is the one which is actively maintained by DFINITY and getting regular updates (e.g. support for ICRC-103 has been implemented in the latest release, announcement on this is pending).

as long as you are the controller of the canister, you can always upgrade and add other features later on if needed. and in case you are using the a pre-built reference implementation, the chance for getting help is probably higher than if you implemented the core functionality on your own.

I also want to highlight the importance of implementing ICRC-3 along with ICRC-1 and ICRC-2. if ICRC-3 is not implemented, the tx history of a ledger is not visible (at least not in a standardized way). this means that an index canister or the Rosetta API won’t be able to index ledger data.

what exactly do you mean with extending / customizing? there are some configuration options you will have on deployment. but if you need custom logic on the ledger itself which is not part of the reference implementation, this requires code changes / additions and will result in a different WASM for deployment.

yes, actually the minting_account defined in ICRC-1 is a separate account which can also be a canister which implements any kind of custom logic.

I don’t think so, it depends on specific requirements though. if it is just about having custom minting logic / token distribution, this can be implemented on a separate canister.

migrating to a completely new ledger for whatever reason is also an option.

there does not yet exist a best practice how to perform such a migration though.

1 Like
4

So if I use the WASM which is actively maintained by DFINITY I could redeploy over the current ICRC-3 version with any new updates and fixes provided without having to do any migrations etc?

But I wouldn’t later be able to upgrade to ICRC-4/5 without doing migrations?

Also, if I set up a canister that could distribute tokens automatically as rewards for XP for example could I also make that canister a minting account or can you only have one minting account. How would that work?

5

in general, unless you remove the controllers to blackhole the canisters (which is not recommended right now), you will be able to perform any kind of upgrade to the ledger.

however, upgrades to add new functionality or to modify/add new data structures should ALWAYS be well tested.

in such cases it might be helpful being able to pause/unpause the ledger which will be possible in the future once ICRC-124 is implemented.

in general, the term “migration” be applied for two different scenarios:

  1. migrate to a new ledger version (code upgrade for the canister)
  2. migrate all balances (and possibly the history) to another (new) canister with the new implementation

when speaking about the missing best practices, I was referring to the second scenario.

so bottom line:

  • upgrades are always possible as long as you are the controller, but you should know how to do it and test it accordingly.
  • migrations are mainly needed if data structures are modified/added

an ICRC-1 ledger only defines 1 minting account and that must be set to the canister that implements that logic, yes.

6

I’m happy to support you in using Pan Industrial’s suite of ledger code. We have event hooks and interceptors that make doing custom token behaviors much easier to implement than with Dfinity’s ledger.

I haven’t implemented icrc 103 or 124 yet but they are on the list and I can bump them up if someone needs them urgently. They will be drop in once I have them.

Last I check it wa also compatible with dfinity’s index canister and Rosetta, but I likely need to check that with the new releases(I’m actually it sure how Rosetta is going to handle 124 :face_with_diagonal_mouth:.

So if you want motoko and custom features with just a couple lines of code it is a good option.

1 Like