ICRC-105 and it's seven cousins

Hello everyone,

ICDevs.org is excited to present the following work that lays the foundation for a project we’re calling AstroFlora. AstroFlora seeks to build on top of the work we’ve done at https://daos.icdevs.org by building out the lego blocks that one would need to implement the patterns and forms identified in that project.

The IC currently offers a couple different options for launching new tokens with the most successful and popular being the SNS. Features are added to the SNS carefully as there are large amounts of interconnections and interdependencies. One goal of AstroFlora is to make it possible to deploy small modules of functionality into an SNS or other DAOs that allow for more free flowing experimentation in alternative governance or executive actions, community building, or whatever the big brains dream up next. More about AstroFlora later.

In the mean time we needed some tooling and standards to do some of what we wanted to do. This is a massive content dump of ICRC Drafts. Please bear with me as we muddy up the forums for a bit to give a proper place for discussion to continue on these topics.

The over-arching theme here is Transparency, Auditability, Provenance, and Traceability of wasms on the IC. To date, ventures on the IC have been fairly free to push up new wasms at will without much explanation, rhyme, or reason. (The recent SNS upgrade pathways have improved this somewhat for SNS DAOs, but we saw an opportunity for standardization and making these features available to anyone). These standards consist of number of lego blocks that work together to try to establish a pathway for us all to be far more responsible.

Using systems built on these 8 ICRC one would be able to:

  • Create an canister app type

  • Upload new versions of that app

  • Have other verify the build from source

  • Deploy the canister and orchestrate it with starts, stops, and snapshots.

  • Upgrade and roll back the canister.

  • Track these installs and upgrades in an ICRC log

  • Retrieve expired wasm via a bounty system if they become stale

  • Provide a fully end-to-end auditable canister where every interaction with a dapp or decentralized utility is in the transaction log(evm style if that is your jam).

Here they are:

ICRC-105: Installation and Configuration History Block Definitions

This standard extends ICRC-3 to record critical events during Wasm module installations and configuration changes. Think “we don’t know what has been installed on this canister and what changes have been made over time and we need a solution for this.” It ensures a deterministic log of installations and configuration adjustments to canisters, promoting transparency and auditability.

View Forum Post for ICRC-105

ICRC-118: Wasm Registry Definition for Version Control and History

ICRC-118 defines a standardized Wasm registry aimed at managing versions and maintaining an immutable history of Wasm modules. Think of this as npm for canisters. It supports search, version control, and Wasm management, separating registry functions from orchestration.

View Forum Post for ICRC-118

ICRC-119: Wasm Registry Block Specification

Focusing on detailed event logging in Wasm registry operations, ICRC-119 captures records such as canister type registration, chunked Wasm uploads, and controller management. It extends ICRC-3 by ensuring an auditable trail for every registry activity.

View Forum Post for ICRC-119

ICRC-120: Canister Wasm Orchestration Service Specification

ICRC-120 sets out the protocols for orchestrating upgrades, installations, and overall lifecycle management of canisters. Think of this as dfx via a canister. It standardizes processes for initiating upgrades, snapshot creation, rollback operations, and configuration management—streamlining canister deployments for DAOs and dApps.

View Forum Post for ICRC-120

ICRC-121: Wasm Orchestration Service Block Specification

Building on orchestration service needs, ICRC-121 records detailed events such as upgrade requests, snapshot completions, and replica level canister configuration changes. It enhances auditability by ensuring every orchestration step is recorded using immutable blockchain logs.

View Forum Post for ICRC-121

ICRC-126: Wasm Verification

ICRC-126 provides a framework for secure verification of Wasm modules through attestations, divergence reporting, and finalization records. Think “how do we know this thing does what you say it does?” This standard ensures that compiled Wasm binaries are trustworthy and meet stringent quality criteria.

View Forum Post for ICRC-126

ICRC-127: Generic Bounty System for Verification

This specification introduces a bounty mechanism to incentivize the accurate and timely verification of Wasm modules. Think “how do we incentivize recovering old, stale wasms that have been removed from the registry to save space?” With this ICRC we choose to be much more generic than that and we define a general purpose bounty set up that supports many different kinds of bounties. It details bounty creation, claim submission, and the secure release of escrowed funds upon successful validation of challenge criteria.

View Forum Post for ICRC-127

ICRC-133: Generic Input Capture and State Change - Extends ICRC-3

ICRC-133 extends ICRC-3 standards by logging user inputs and subsequent state changes in canisters. Think “what if IC canisters captured everything the way evms do”. It captures update method calls along with the resulting state modifications, ensuring thorough auditability of canister activity.

View Forum Post for ICRC-133

Conclusion

Together, these ICRC standards create a comprehensive framework addressing installation, registry management, orchestration, verification, bounty incentivization, and state change logging.

So whats next? As you read them, you’ll quickly realize these are DRAFTS. We need community input and support to bring them to final, accepted ICRC standards.

We will likely use the Event Utility Working Group slot on alternating weeks to begin engaging with the community(of course you can get started in the forum posts), with the first meeting being Wednesday March 19th at noon Central(US) Daylight Time.

In the mean time we’ll begin building reference implementations, an essential step in defining standards, to make sure we’ve captured all the things that need to be captured. We look forward to your feedback.

I’d like to thank the DFINITY Foundation for subsidizing this work with a developer’s grant.

10 Likes

Can you change the candy library to return a Result<T, Error> instead of throwing an error?

That seems to be like low hanging fruit

Like, if your code is really low-level and 6 layers deep and you’re trying to convert 300 to a u8, wouldn’t it be best to bubble that error up to the top? Not just panic?

I had you worked out in 2021 Austin.

That would be a wholly rational thing to do. I’ll put it on the list. (Would also take pull requests.) The whole thing needs to be refactored and updated to ICRC-16. Thats on the list as well.

I don’t think knew the difference between a trap and throw in 2021.

:joy: You too villa. Just keep doing your thing. I’ll do mine. Hope we all build something great.