Canton has opened voting on CIP-0127, a proposal to automate Canton Coin locking rules for Super Validators and Featured Apps. Digital Asset is sponsoring the proposal, with Cumberland DRW as endorser. The vote was announced on October 19, 2026, and the proposal remains unapproved.
Locking means committing CC so it cannot be freely spent while it supports a network requirement. The change would move more of the work of checking these commitments and enforcing shortfalls into software, with common tools for wallets and locking services to manage them.
This builds on the existing Super Validator locking framework and Featured App locking requirements. It is not a new rule requiring every Canton validator or wallet user to lock CC.
Who does what on Canton?
Validators are the nodes through which people and organisations use Canton applications. They check transactions involving the parties they serve, rather than receiving every private transaction across the network.
Super Validators support the Global Synchronizer, the shared infrastructure that orders and coordinates messages between participants. They also contribute to network governance. This role does not give them access to the contents of everyone's private transactions.
Featured Apps are applications with an approved status that makes them eligible for app rewards under Canton's tokenomics rules. This is an application designation, not a third kind of validator.
These roles can overlap within one organisation. The important distinction for this proposal is between running infrastructure and holding reward rights. The owner of Super Validator reward rights can use a node operated by another organisation, and someone else can supply the locked CC.
What would happen when a lock falls short?
Under the proposed Featured App rules, automated checks would compare eligible locked CC with the app's required amount. A detected shortfall would immediately suspend its Featured App reward privileges.
The app would then have a default seven-day window to restore the required lock before losing Featured App status permanently. That window could be changed through Super Validator voting. This softens the earlier framework's immediate removal of status by allowing time to fix a shortfall.
Suspension would not itself shut the application down. Transactions could continue, but would no longer produce the records used to claim Featured App rewards. The app would also stop qualifying for app rewards tied to network usage for new reward rounds during suspension.
For Super Validators, a shortfall would reduce reward weight, which determines the rewards they can earn. The temporary reduction would apply on detection, removing the earlier seven-day grace period for temporary reductions. A separate 30-day recovery window would remain before an unrecovered reduction became permanent. Governance could adjust that window. Reward weight is not a measure of how much control a node has over consensus.
What this means for locked funds
Locking does not destroy coins. When unlocking begins, funds normally become available gradually through a vesting schedule. Provisional locks used when applying for Featured App status are an exception: those can be returned without vesting.
The proposal also supports replacing one provider's locked funds with another's, subject to the required approvals. As a simplified example, suppose an app has 5 million CC locked and a new provider replaces 1 million of it. The original provider receives that replacement amount while the app still has 5 million CC supporting it. The source of part of its backing changes, but the total stays the same.
A separate lock-transfer mechanism would allow ownership of the existing funds to change without first supplying replacement capital. Neither process would change which app the lock supports.
The practical benefit, and the work ahead
The clearest potential benefit is more consistent enforcement. Teams could work against rules applied by software, with fewer manual votes to handle individual shortfalls. The Featured App recovery window would also give operators time to replace missing backing before having to reapply for status.
That makes good wallet design important. Operators and capital providers would need to see which commitment a lock supports, who can authorise changes, and when funds become available. Automated enforcement would make a missed top-up consequential even without a separate manual decision.
Approval would not switch all of this on at once. The staged rollout links migration windows to delivery of the relevant features on MainNet. Its 30-day transition periods start after those features arrive, not when the proposal passes. Automated Super Validator enforcement would also require activation through a further vote.
Read the full CIP-0127 proposal and Canton's explanation of its network roles.
