Essay
Locking funds on a condition, on any Canton registry
Canton's token standard can show a lock, but not a standard way to release on a condition. A draft interface, reference implementation, and ask for builders who need it across registries.
Canton's token standard can show that a holding is locked, but it gives applications no standard way to lock one under a condition. We have written a draft interface that does, with a working reference implementation, and we want to hear from the teams who would build on it.
The problem
A token-standard holding on Canton can carry a lock: who holds it, when it expires, and a short description. Wallets already show that. What the standard does not provide is a way to create a lock that releases on a condition, or a standard statement of who may release it and when.
So every application that needs conditional release builds its own. Some move the funds into an application-owned contract, which takes them out of the owner's portfolio and changes how they are held, reported, and taxed. Others use one registry's own lock contract, which works for that registry and no other. Neither gives an application one flow that works across every asset on the network.
Five things people are trying to build
Each use case below is the same shape: funds locked in the owner's account, one or more ways they can be released, and a deadline after which they come back.
| Use case | What has to happen | Who needs it |
|---|---|---|
| Cross-chain swap (HTLC leg) | The Canton leg releases on the same secret the other chain checks, and returns to the owner if the swap times out | Market makers and bridge operators quoting a Canton asset against Bitcoin, an EVM chain or Solana |
| Escrow with an arbiter | A named arbiter, who is neither party, awards all or part of the funds | Marketplaces, freelance and real-world-asset platforms, dispute-resolution services |
| Vesting | Fixed tranches open on published dates, with no one choosing amounts or destinations | Token issuers paying contributors, investors or grantees |
| Collateral | The pledgee releases the funds on repayment or claims them after maturity; both sides can adjust amount and maturity by consent | Lending and margin applications, custodians who need collateral to stay in the pledgor's account |
| Payment on attestation | Payment goes to the payee when a named attestor confirms, and only before a deadline | Invoice financing, parametric insurance, milestone payments |
What token standard V2 already does
A lot of trading does not need anything new. Token standard V2 (CIP-0112) uses allocations: funds set aside for a settlement that named executors carry out.
Two counterparties can be their own executors, so delivery versus payment between them needs no third party, on one registry or across two.
A venue that matches orders can settle the executed trade with the traders acting once.
Committed allocations hold funds ahead of a trade, and iterated settlement lets an order book settle repeatedly against one funded position.
If your need is one of these, use allocations. The conditional lock is not a replacement for any of them.
What a conditional lock adds
A conditional lock attaches a release policy to a holding. The policy is a short list of rules. Each rule says who may trigger it, what must be true, and where the funds go: back to the owner, to fixed recipients, or to recipients chosen within limits set up front. A rule fires once, and whatever it does not release stays locked. At expiry, the remainder returns to the owner.
That covers what allocations leave out:
- Release on a fact, not only on a party acting. A hash preimage or a point in ledger time, checked by the parties who hold the lock, not by whoever submits it.
- Several outcomes over one pool of funds. Settle before a deadline, or an arbiter decides after it.
- Bounded discretion. An arbiter can split an award, but only among recipients named when the lock was created.
- Partial release. A vesting tranche releases and the lock carries on with the rest.
- Amendment by consent. Both parties can top up collateral or extend maturity together.
Example: payment on attestation. A buyer locks 10,000 of a stablecoin for a supplier, with one rule: release to the supplier once the inspector confirms delivery, before 31 October. The inspector approves from their own wallet when the goods arrive. The supplier collects later. If no confirmation comes before the deadline, the buyer gets the funds back at expiry. The funds never leave the buyer's account until they are released, so the buyer's wallet shows them the whole time.
The design choices, and why
One release policy, not a special-purpose HTLC. Escrow, vesting, collateral, and conditional payment are an HTLC with different conditions and more than one outcome. One small data model covers them all, so a wallet learns one thing.
The funds stay in the owner's account. The lock is an attribute of the holding, so existing wallets already show it as locked, and custody and reporting do not change.
Conditions are a fixed, flat list. A rule is any of a few alternatives, each a list of conditions that must all hold: a hash preimage, before or after a time, or a number of named parties. There is no scripting and no nesting, so a wallet can always show what a lock will do.
Every registry behaves the same. The rules for checking conditions do not depend on the registry, and the reference implementation ships them as a package any registry can reuse. An application written against one registry works against the next.
Approvals can come one at a time. When a rule needs, say, two of three parties, each can approve from their own wallet when it suits them, and the rule fires once enough have. No delegation contract is needed.
Expiry always returns funds to the owner. Anything that should go elsewhere after a date is written as its own rule, with expiry as the safety net behind it.
A new, optional package. Nothing existing changes. Registries opt in, and wallets can tell which assets support it.
The lock is not built on allocations with extra metadata, because the conditions, the several outcomes, and the fixed recipient list would each become something every registry parses and enforces in its own way. That is exactly the cross-registry inconsistency this is meant to remove.
It is also not a governance lock. Locks that Super Validators and Featured Apps hold for network governance are specified separately, and this proposal does not touch them.
Where it stands
This is a draft, not a standard, and it has not been proposed for a vote. Interfaces are hard to change once registries implement them, so the right time to shape this one is now.
| Piece | Status |
|---|---|
| Draft specification | Written in the Canton Improvement Proposal format, revised through three rounds of review |
| Interface package | Proposed as a change to the Splice token standard (PR 7294), under review |
| Reference implementation | Apache-2.0, current release v0.2.0; the current version runs 94 test scripts on the Canton versions live on Mainnet and Testnet |
| Real Canton Coin | Tested as the payment leg of a delivery versus payment against a conditionally locked asset, on a local network matching Mainnet |
| Cross-chain hashing | The same test vectors pass on Canton, an EVM contract and a Solana program |
Two limits are worth saying plainly. Canton Coin itself cannot yet be locked this way; that needs a Canton Coin implementation, which only happens if the standard is accepted. And adoption by registries depends on applications showing they need it, which is why we are asking.
How to weigh in
The most useful thing you can tell us is a real need. If you are building, or planning, an application whose business depends on locking funds on a condition across registries, we want to hear about it.
Open an issue on the reference repository and tell us:
- Builders: which use case, which assets, and on what timeline.
- Registry operators: whether you would implement it, and what would make that cheap or expensive.
- Wallet providers: what you would need to show a conditionally locked holding and how it can be released.
- Everyone: which capabilities are essential and which could go.
- In the meantime: whether you would use the package out of tree before it is a standard.
If you are on the Canton Improvement Proposal mailing list, cip-discuss, the same questions are open there.
Related service: Web3 Advisory