CIP-0112 Token Standard v2: committed allocations and cancellation policy

App Development
1

I’m looking for clarification on committed allocations in the v2 token standard.

My current understanding is that committed = True restricts Allocation_Withdraw, but does not by itself restrict Allocation_Cancel; cancel/settle authorization is ultimately enforced by the registry implementation.

Is that the intended model?

More specifically:

  • Are committed allocations meant only for settlement/DvP-style flows, or also for longer-lived escrow-style use cases?

  • If a client needs a committed allocation that cannot be cancelled unilaterally by the authorizer/executor, is that expected to be handled as registry-specific policy?

  • Is there any standard way for a client to discover or require such a policy, or would that need a future capability/profile/extension?

  • For adding funds to an existing committed allocation, is cancel-and-reallocate the expected portable pattern, or is there a preferred lock-preserving rollover/top-up flow?

Thanks.

2

Hi Sergey,

That is indeed the intended model. Committed allocations (with iterated settlement) are effectively under the exclusive control of the executors until the settlement deadline.

You can think of it as “escrow-style” use cases, except that in CIP-0112 the ownership doesn’t actually change.

If you want an allocation that cannot be unilaterally cancelled, just set multiple executors, or use a decentralized executor. The executors field is simply the set of parties that can settle OR cancel.

To add funds, create a second allocation with input (topup) holdings and settle the two allocations via a batch settlement, with an inbound leg on one and outbound leg on the other.