TL;DR
- ICDevs just shipped its first ICRC-137 “veto-governed” canisters: a Veto Canister and a Veto Lifeline—both wired through ICRC-120 orchestration.
- Admins(DAP developers keep control but every sensitive(configured) call (upgrades, configs, token transfers, etc.) is subject to a DAO veto*. *The DAO can be a SNS, NNS, or other Item that returns proposal status in the same format as the NNS. For these canisters, that DAO is the NNS.
- Lifeline ⟷ Veto: each can upgrade/configure the other via ICRC-120, so there’s a safety line if one fails.
- Alpha has a backdoor (for safety); backdoor is removed at beta.
- ICRC-120 orchestrator will be the next canister governed under ICRC-137.
- This pattern is for Anti-DAOs, Pre-DAOs, and the DAOless who want accountability without having to establish a new DAO and who want to ‘inherit’ the security of the NNS.
- Links: Veto-Lifeline akiyk-waaaa-aaaai-atlca-cai, Veto anj66-3yaaa-aaaai-atlcq-cai, ICRC-120 Orchestrator a7pjh-xiaaa-aaaai-atlbq-cai (block logs available).
Anti-DAO, Pre-DAO, DAOless — ICRC-137 Veto-Based Governance
What we shipped
-
ICRC-137 Veto Canister and Veto Lifeline (subject to NNS veto).
-
Mutual upgrades via ICRC-120:
- Veto can upgrade the Lifeline through ICRC-120, config through self call.
- Lifeline can upgrade the Veto through ICRC-120, config through self call.
-
Roadmap: the ICRC-120 Orchestrator itself will go under ICRC-137 governance next.
Canisters
- Veto-Lifeline: https://dashboard.internetcomputer.org/canister/akiyk-waaaa-aaaai-atlca-cai
- Veto: https://dashboard.internetcomputer.org/canister/anj66-3yaaa-aaaai-atlcq-cai
- ICRC-120 Orchestrator: https://dashboard.internetcomputer.org/canister/a7pjh-xiaaa-aaaai-atlbq-cai
Field note: the Lifeline already executed a command against the ICRC-120 to upgrade the Veto canister to v0.0.4. We shortened the timeline to test; it failed at first, then succeeded after enabling orthogonal persistence flags.
You can explore calls/behavior in the ICRC-3 block logs for each canister.
Here is the command status for the successful icrc120_upgrade_to call:
[
[
{
"id": 1,
"status": {
"executed": "1759947563809335170"
},
"result": [
{
"Ok": "4449444c036d016b02bc8a017dc5fed201026b04efd1c6af057ff7b3b29d0871d4b4c59a097fecce99d4097f0100010007"
}
],
"request": {
"scheduled_time": [],
"method": "icrc120_upgrade_to",
"metadata": [
[
"icrc137_upgrade_type",
{
"Text": "veto_canister_upgrade"
}
],
[
"icrc137_description",
{
"Text": "Upgrade veto_canister through prod-orchestrator"
}
],
[
"icrc137_target_canister",
{
"Text": "anj66-3yaaa-aaaai-atlcq-cai"
}
],
[
"icrc137_wasm_hash",
{
"Text": "63f25d37647113c89eb65c8d3f02b13add3451cf3c7fb373e2348be768970d41"
}
]
],
"memo": [
"757067726164652d31373539393437343833353633"
],
"requested_at": [
"1759947483563000064"
],
"cycles": [],
"best_effort_timeout": [],
"method_args": [
"4449444c0d6d7b6b0285a19bb8047fb490a1d90a7f6e016e7e6c02dceaaefa0202c0a09bde05036e046b03c8bb8a707f9ce9c69906059baaebec087f6c006c02007101076d086e096c09c4b0d08d027edd9ad2830400cedfa0a80400e3a683c3040682e0efe2047eb3c4b1f20468aafdfa8b050acf8f97d5067ea1b5dcc70d7d6d0b010c0100314449444c076c006e006c02dbb7017d8d98f3e7047d6d026e036c0381a99a4001fdbdbbb90504e780c0b107016e050106002063f25d37647113c89eb65c8d3f02b13add3451cf3c7fb373e2348be768970d41010101000001010a0000000001009ac50101000180f092cbdd08"
],
"canister": "a7pjh-xiaaa-aaaai-atlbq-cai"
},
"scheduled_for": "1759947563044796132",
"veto": [],
"created_at": "1759947503044796132"
}
],
1
]
How it works (in one screen)
- ICRC-137 lets an admin make any IC call (e.g., upgrade/config/transfer), but requires subjecting each call to a veto window by a chosen DAO (here: NNS).
- On-chain: only the Veto Canister (and certain closed systems like the 120 Orchestrator) can perform protected actions on your target system; it is set as sole controller/admin for those functions.
- Off-chain: community discovers pending commands and can organize a veto motion. We’re building a discovery dashboard in Astroflora; bots/feeds are viable too.
Alpha → Beta
- Alpha: we maintain a backdoor (recovery).
- Beta: we remove the backdoor.
Why this design?
Coin-voting DAOs are unresolved at best, broken at worst (collusion, plutocracy, capture):
-
Vitalik on voting, collusion, and how coin-voting is broken:
At the same time, the NNS has “secured” >$2B for ~4+ years, while some SNS offspring have seen capture risks. We want operational clarity + last-resort accountability without pretending coin-vote solves everything today(and the expenses that come along with an SNS).
ICRC-137 requires a commitment to this ethos:
- Open source the code.
- Clear-communication about upcoming upgrades and/or service affecting actions.
- Honor the timeline - Announce publicly, wait 4 days, call command, wait 4 days, execution or veto.
This creates explicit power with explicit guardrails, not the murky implicit control that often accompanies governance theater.
Who this is for
- Anti-DAO: You don’t want to give up control, but you want credible accountability (including protection against coercion). ICRC-137 gives you a safety net when pressure mounts.
- Pre-DAO: You want to grow into decentralization. ICRC-137 sets rational limits and provides on-chain trust while you iterate toward a durable model.
- DAOless utilities: Mostly “black-hole,” but want a measured upgrade path for rare protocol changes. ICRC-137 makes that straightforward.
Consider your application is successful and you find yourself holding the keys(literally) to a service that has US $100m of users’ funds held by accounts on your back-end canister. On a Tuesday night, a man shows up at your door with a gun and kindly suggests that you install his crafted wasm that will extract all the tokens your canister owns into his account. What do you do? If your canister is under ICRC-137 governance, this scenario becomes much less possible because upgrades take, at the least, 4 days, and an unannounced upgrade that does not have code associated with it will likely be vetoed.
Practicalities
On-chain (easy)
- Propose the call via ICRC-137 → it enters a pending window.
- If no veto within the window → it executes automatically.
Off-chain (harder)
- People need to care and have information. We’ll surface pending requests in an Astroflora dashboard; third-party bots can help.
- The governing DAO (here, NNS) must also care. Expect to write clear proposals and rally quorum (>~3% on some NNS topics). Example style:
“DAOZZZ proposes upgrading to WASM XXXXXX. The new build adds a withdrawal function enabling DAOZZZ to remove user funds at discretion. This violates stated protocol guarantees and is unsafe. We request the NNS to veto this upgrade. Commit:
https://github.com/yyyyyyyy.”
The unstated subtext to the above proposed veto is that it is highly likely tha the THREAT of veto will cause the upgrade to not be issued in the first place and thus resolving the situation off chain.
Abuse & trolling
- A sufficiently funded actor can repeatedly file veto motions to stall you. There’s no silver bullet yet; economic costs and social norms help.
- ICRC-137 can plug into any governance system with a governance-canister-like interface; boards/councils are possible if NNS isn’t the right venue.
Security/operability notes
- Only the Veto Canister (and selected closed systems like the 120 Orchestrator) should be controller/admin for functions guarded by 137.
- Keep trivial stuff out of NNS governance; reserve veto for big promises and safety.
- Emergency stops, can be issued by a developer that controls a 137 canister if they provide a pre-determined fee/deposit as a part of the standard. This allows vulnerabilities to be taken offline immediately, and then the fee/deposit is refunded after a new wasm is deployed. This provides at least SOME ‘delete the canister’ protection.
FAQ
Q: Can I read the code?
A: Not yet. We’re running a few experiments first and figuring out funding. We applied for a grant; it’s in limbo as it’s not seen as driving immediate network metrics. We’ll keep pushing—infra/public goods aren’t flashy, but they’re essential. Got ideas? Donations, naming rights, even playful things like “buy-a-line-as-an-NFT” have been floated. We’ll open-source at release with better docs and self-service onboarding.
Q: Can I use it today?
A: If you have a clear use case and would like to participate in the Alpha/Beta, please reach out.
Next steps
- Run more experiments, including vetoing one of our own upgrades end-to-end to prove the loop.
- Remove the alpha backdoor.
- Open-source the code, document the spec, and package deployment tooling.
- Release the Astroflora dashboard for ICRC-137 discovery (pending-commands feed).
If you’re building an Anti-DAO, Pre-DAO, or DAOless service and want to ship with accountability—without pretending coin-vote is “solved”—ICRC-137 is for you.
You can currently launch your own ICRC-137 canister via the AstroFlora dashboard at https://muwct-xiaaa-aaaaj-a2ffq-cai.icp0.io/ if you create an empty canister and make a7pjh-xiaaa-aaaai-atlbq-cai a controller.