CIP-0107: 24 Hour Submission Delay for for End-User CC Transactions - Moritz Kiefer
- Hi,We'd like to propose a CIP to extend the current 10min submission delay between preparing and signing CC transfers and relatedend-user transactions to 24h.Full CIP Text:## Title
<pre>
CIP: CIP XXXX
Layer: Daml
Title: 24h Submission Delay for End-User CC Transactions
Author: Simon Meier, Moritz Kiefer
Status: Draft
Type: Standards Track
Created: 2026-01-21
License: CC0-1.0
</pre>
## Abstract
This CIP supports a 24 submission delay between preparing and
execution for all CC end-user transactions. Specifically this applies to all
token standard operations making CC fully compliant with the token as
well as the CC specific public actions of creating, renewing, and
archiving preapprovals, purchasing traffic, and tapping funds on
DevNet.
## Copyright
This CIP is licensed under CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)
## Specification
### High Level Summary
The current 10 minute submission delay comes from the use of
`OpenMiningRound`. To support a 24h submission delay a new
`ExternalPartyConfigState` contract is introduced that is active for
48h and copies the subset of information required for token standard
operations from the latest `OpenMiningRound` contract at the time of
its creation.
### Detailed Changes
- Add a new configuration parameter `externalPartyConfigStateTickDuration` which defaults to 24h.
- Introduce a new `ExternalPartyConfigState` template which stores the
amulet price, the round number, the holding fees and `maxNumInputs`,
`maxNumOutputs`, `maxNumLockHolders` copied from the
`OpenMiningRound` contract at the time of creation. Each of these
contracts is active for `2 * externalPartyConfigStateTickDuration` and a new one is created every `externalPartyConfigStateTickDuration`.
- Change the token standard implementation of CC to rely on
`ExternalPartyAmuletRules` and `ExternalPartyConfigState` instead of `AmuletRules` and
`OpenMiningRound`. At any given point the most recent
`ExternalPartyConfigState` contract is still valid for at least
`externalPartyConfigStateTickDuration`, i.e., 24h with the default
configuration providing the desired submission delay. New `Amulet` contracts created from those choices will
have the round they were created in set to the round from `ExternalPartyConfigState`.
- Change the transfer implementation to create `FeaturedAppActivityMarker` contracts instead of directly creating `AppRewardCoupon`. This is required
as `AppRewardCoupon`s are tied to a round which would impose a shorter submission delay. This does not change the amount of rewards that can be minted. However it does imply that `extraFeaturedAppRewardAmount` can no longer be configured independently of `featuredAppActivityMarkerAmount`, which is a feature that was never made use of.
- Enforce additional restriction on the `AmuletConfig`. These restrictions all hold already on DevNet, TestNet and MainNet so this is not changing the configuration.
- CC usage fees, which were set to zero in CIP-0078, can no longer be set to non-zero values.
- `extraFeaturedAppRewardAmount` must be identical to `featuredAppActivityMarkerAmount`.
- The `futureValues` field in the configuration schedule must be empty. The options for setting it were already removed
in CIP-0051. Now it is just enforced more directly.
- Expose choices for `AmuletRules_BuyTraffic` and `AmuletRules_Tap`
through two new interface packages `splice-api-tap-v1` and
`splice-api-traffic-purchase-v1`. These will also rely on `ExternalPartyConfigState` instead of `OpenMiningRound`. Note that during the implementation this may be rolled as a separate step.
- Add new `LockedAmulet_UnlockV2` and `LockedAmulet_OwnerExpireLockV2` choices that do not require an `OpenMiningRound`.
- Remove the existing `LockedAmulet_Unlock` and `LockedAmulet_OwnerExpireLock` choices.
- Deprecate the non-token standard `TransferCommand` template and corresponding validator endpoints so they can be removed
in future versions. This also applies to the corresponding validator APIs `/v0/admin/external-party/transfer-preapproval/prepare-send`
and `/v0/admin/external-party/transfer-preapproval/submit-send`.
- Add new `LockedAmulet_ExpireAmuletV2` and `Amulet_Expire` choices that require `ExternalPartyConfigState` instead of `OpenMiningRound`.
- Remove the existing `LockedAmulet_ExpireAmulet` and `Amulet_Expire` choices.
## Motivation
Between preparing and executing a transaction, the key(s) registered in the topology state
for the submitting external party must sign the transaction. This
often requires explicit human approval sometimes even from multiple
people. Doing that within a 10 minute window can be quite disruptive
and does not match the expectations from other networks or even other
assets on the global synchronizer. Supporting a 24h delay aligns
Canton Coin with other CIP-0056 assets.
## Rationale
### Propagation Delay
Supporting a longer submission delay necessarily implies that the
accessed contracts need to be active for at least the duration of the
submission delay. This is what the new `ExternalPartyConfigState`
contract accomplishes.
This does however imply that changes to the
values stored on that contract propagate more slowly. More specifically it
takes up to 48h until the old values cannot be used anymore.
For `maxNumInputs`, `maxNumOutputs`, `maxNumLockHolders` this is a
non-issue as those values have not been changed once and we don't
expect to need any quick changes. The `amuletPrice` in a CC transfer
is only used for converting the holding fee and from USD to CC. For holding fees,
minor fluctuations play a negligible role so price changes propagating
slower has negligible impact.
There is a bigger impact on traffic purchases where a price change is
more significant. There is not really any way to enforce use of recent
prices and support a long submission delay though so this is a
necessary tradeoff.
### Holding Fees
`Amulet` contracts created via choices relying on
`ExternalPartyConfigState` will have the round they were created in
set to the round at the point in time when `ExternalPartyConfigState`
was created. This can be up to 48h in the past at the time the
transaction gets executed. By switching expiry to be based on
`ExternalPartyConfigState` we compensate for that by delaying expiry
by the same amount so the effective expiry date of `Amulet` contracts
is unchanged.
### Additional AmuletConfig Restrictions
The additional restrictions enforced on `AmuletConfig` are required to
make the implementation feasible. In particular switching from creating `AppRewardCoupon` contracts to `FeaturedAppActivityMarker` without changing the issued rewards requires
that a CC transfer only produces featured application rewards, implied by no fees, and
`extraFeaturedAppRewardAmount` must be identical to `featuredAppActivityMarkerAmount`.
## Limitations
This change supports a 24h submission delay for token standard
operations, traffic purchases and tap. However, reward minting is
still subject to the 10 minute submission delay. Short term, the
minting delegation introduced by CIP-0096 allows to delegate minting to
a party that can support a shorter submission delay. Longer term, we
expect that as part of switching to traffic based rewards we will also
be able to support a longer signing delay for reward minting.
## Backwards compatibility
### Token Standard APIs
Changing the CC implementation of the token standard APIs to use
`ExternalPartyConfigState` is an implemenation-internal change. Users of the token
standard APIs do not need to make any change in their application.
Note however, that the choice context returned by Canton Coin Scan
will change. As applications should treat this opaquely and just pass
it along, this should still not require changes in applications.
### Locking APIs
Applications that directly use `LockedAmulet_Unlock` or
`LockedAmulet_OwnerExpireLock` will need to switch to the `V2` choices
when they recompile their code against the new amulet versions. Note
that existing DARs compiled against the previous version will continue
working so the upgrade can be done at the developer's preferred
schedule.
### Transaction History Parsing
App providers that parse transaction history through the [token standard
API](https://docs.sync.global/app_dev/token_standard/index.html#reading-and-parsing-transaction-history-involving-token-standard-contracts)
no change is required.
App providers that parse the CC specific choices directly will need to adjust
your parser. In particular, `TransferPreapproval_SendV2` and the token
standard implementation of transfers and allocations no longer
exercise `AmuletRules_Transfer` internally and instead inline the
adjusted implementation of that choice to rely on
`ExternalPartyConfigState`.
## Reference implementation
A draft PR for the Daml changes can be found on [Github](https://github.com/hyperledger-labs/splice/pull/3487).
--Moritz KieferArchitect - Canton NetworkDigital Asset, creators of Daml
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - toggle quoted message Show quoted textThe CIP is now also available on Github https://github.com/global-synchronizer-foundation/cips/pull/153On Wed, Jan 21, 2026 at 9:56 AM Moritz Kiefer via lists.sync.global <moritz.kiefer=digitalasset.com@...> wrote:Hi,We'd like to propose a CIP to extend the current 10min submission delay between preparing and signing CC transfers and relatedend-user transactions to 24h.Full CIP Text:## Title
<pre>
CIP: CIP XXXX
Layer: Daml
Title: 24h Submission Delay for End-User CC Transactions
Author: Simon Meier, Moritz Kiefer
Status: Draft
Type: Standards Track
Created: 2026-01-21
License: CC0-1.0
</pre>
## Abstract
This CIP supports a 24 submission delay between preparing and
execution for all CC end-user transactions. Specifically this applies to all
token standard operations making CC fully compliant with the token as
well as the CC specific public actions of creating, renewing, and
archiving preapprovals, purchasing traffic, and tapping funds on
DevNet.
## Copyright
This CIP is licensed under CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)
## Specification
### High Level Summary
The current 10 minute submission delay comes from the use of
`OpenMiningRound`. To support a 24h submission delay a new
`ExternalPartyConfigState` contract is introduced that is active for
48h and copies the subset of information required for token standard
operations from the latest `OpenMiningRound` contract at the time of
its creation.
### Detailed Changes
- Add a new configuration parameter `externalPartyConfigStateTickDuration` which defaults to 24h.
- Introduce a new `ExternalPartyConfigState` template which stores the
amulet price, the round number, the holding fees and `maxNumInputs`,
`maxNumOutputs`, `maxNumLockHolders` copied from the
`OpenMiningRound` contract at the time of creation. Each of these
contracts is active for `2 * externalPartyConfigStateTickDuration` and a new one is created every `externalPartyConfigStateTickDuration`.
- Change the token standard implementation of CC to rely on
`ExternalPartyAmuletRules` and `ExternalPartyConfigState` instead of `AmuletRules` and
`OpenMiningRound`. At any given point the most recent
`ExternalPartyConfigState` contract is still valid for at least
`externalPartyConfigStateTickDuration`, i.e., 24h with the default
configuration providing the desired submission delay. New `Amulet` contracts created from those choices will
have the round they were created in set to the round from `ExternalPartyConfigState`.
- Change the transfer implementation to create `FeaturedAppActivityMarker` contracts instead of directly creating `AppRewardCoupon`. This is required
as `AppRewardCoupon`s are tied to a round which would impose a shorter submission delay. This does not change the amount of rewards that can be minted. However it does imply that `extraFeaturedAppRewardAmount` can no longer be configured independently of `featuredAppActivityMarkerAmount`, which is a feature that was never made use of.
- Enforce additional restriction on the `AmuletConfig`. These restrictions all hold already on DevNet, TestNet and MainNet so this is not changing the configuration.
- CC usage fees, which were set to zero in CIP-0078, can no longer be set to non-zero values.
- `extraFeaturedAppRewardAmount` must be identical to `featuredAppActivityMarkerAmount`.
- The `futureValues` field in the configuration schedule must be empty. The options for setting it were already removed
in CIP-0051. Now it is just enforced more directly.
- Expose choices for `AmuletRules_BuyTraffic` and `AmuletRules_Tap`
through two new interface packages `splice-api-tap-v1` and
`splice-api-traffic-purchase-v1`. These will also rely on `ExternalPartyConfigState` instead of `OpenMiningRound`. Note that during the implementation this may be rolled as a separate step.
- Add new `LockedAmulet_UnlockV2` and `LockedAmulet_OwnerExpireLockV2` choices that do not require an `OpenMiningRound`.
- Remove the existing `LockedAmulet_Unlock` and `LockedAmulet_OwnerExpireLock` choices.
- Deprecate the non-token standard `TransferCommand` template and corresponding validator endpoints so they can be removed
in future versions. This also applies to the corresponding validator APIs `/v0/admin/external-party/transfer-preapproval/prepare-send`
and `/v0/admin/external-party/transfer-preapproval/submit-send`.
- Add new `LockedAmulet_ExpireAmuletV2` and `Amulet_Expire` choices that require `ExternalPartyConfigState` instead of `OpenMiningRound`.
- Remove the existing `LockedAmulet_ExpireAmulet` and `Amulet_Expire` choices.
## Motivation
Between preparing and executing a transaction, the key(s) registered in the topology state
for the submitting external party must sign the transaction. This
often requires explicit human approval sometimes even from multiple
people. Doing that within a 10 minute window can be quite disruptive
and does not match the expectations from other networks or even other
assets on the global synchronizer. Supporting a 24h delay aligns
Canton Coin with other CIP-0056 assets.
## Rationale
### Propagation Delay
Supporting a longer submission delay necessarily implies that the
accessed contracts need to be active for at least the duration of the
submission delay. This is what the new `ExternalPartyConfigState`
contract accomplishes.
This does however imply that changes to the
values stored on that contract propagate more slowly. More specifically it
takes up to 48h until the old values cannot be used anymore.
For `maxNumInputs`, `maxNumOutputs`, `maxNumLockHolders` this is a
non-issue as those values have not been changed once and we don't
expect to need any quick changes. The `amuletPrice` in a CC transfer
is only used for converting the holding fee and from USD to CC. For holding fees,
minor fluctuations play a negligible role so price changes propagating
slower has negligible impact.
There is a bigger impact on traffic purchases where a price change is
more significant. There is not really any way to enforce use of recent
prices and support a long submission delay though so this is a
necessary tradeoff.
### Holding Fees
`Amulet` contracts created via choices relying on
`ExternalPartyConfigState` will have the round they were created in
set to the round at the point in time when `ExternalPartyConfigState`
was created. This can be up to 48h in the past at the time the
transaction gets executed. By switching expiry to be based on
`ExternalPartyConfigState` we compensate for that by delaying expiry
by the same amount so the effective expiry date of `Amulet` contracts
is unchanged.
### Additional AmuletConfig Restrictions
The additional restrictions enforced on `AmuletConfig` are required to
make the implementation feasible. In particular switching from creating `AppRewardCoupon` contracts to `FeaturedAppActivityMarker` without changing the issued rewards requires
that a CC transfer only produces featured application rewards, implied by no fees, and
`extraFeaturedAppRewardAmount` must be identical to `featuredAppActivityMarkerAmount`.
## Limitations
This change supports a 24h submission delay for token standard
operations, traffic purchases and tap. However, reward minting is
still subject to the 10 minute submission delay. Short term, the
minting delegation introduced by CIP-0096 allows to delegate minting to
a party that can support a shorter submission delay. Longer term, we
expect that as part of switching to traffic based rewards we will also
be able to support a longer signing delay for reward minting.
## Backwards compatibility
### Token Standard APIs
Changing the CC implementation of the token standard APIs to use
`ExternalPartyConfigState` is an implemenation-internal change. Users of the token
standard APIs do not need to make any change in their application.
Note however, that the choice context returned by Canton Coin Scan
will change. As applications should treat this opaquely and just pass
it along, this should still not require changes in applications.
### Locking APIs
Applications that directly use `LockedAmulet_Unlock` or
`LockedAmulet_OwnerExpireLock` will need to switch to the `V2` choices
when they recompile their code against the new amulet versions. Note
that existing DARs compiled against the previous version will continue
working so the upgrade can be done at the developer's preferred
schedule.
### Transaction History Parsing
App providers that parse transaction history through the [token standard
API](https://docs.sync.global/app_dev/token_standard/index.html#reading-and-parsing-transaction-history-involving-token-standard-contracts)
no change is required.
App providers that parse the CC specific choices directly will need to adjust
your parser. In particular, `TransferPreapproval_SendV2` and the token
standard implementation of transfers and allocations no longer
exercise `AmuletRules_Transfer` internally and instead inline the
adjusted implementation of that choice to rely on
`ExternalPartyConfigState`.
## Reference implementation
A draft PR for the Daml changes can be found on [Github](https://github.com/hyperledger-labs/splice/pull/3487).
--Moritz KieferArchitect - Canton NetworkDigital Asset, creators of Daml
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.--Moritz KieferArchitect - Canton NetworkDigital Asset, creators of Daml
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - Hi everyone - I would like to sponsor this CIP and am looking for an Endorser please
- Hi Eric,
5N is happy to endorse this CIP. - Send Safe (multisig) currently is bounded by a ~10 minute signing window due to this constraint. We support this proposal.
- toggle quoted message Show quoted text
Dear All,
In principle, we agree with this CIP.
As a network KMS provider, however, we would appreciate additional guidance regarding its impact on participant node keys that are hosted in an external KMS. Specifically, we would like to understand whether the proposed changes alter node behavior in a way that would require adjustments by the KMS provider, particularly in how key requests are received and responded to.
It may be that this is fully handled within the Canton codebase and that any key operations will continue to pass through the existing KMS driver interface unchanged. However, before casting our vote, we would appreciate confirmation on whether there are any broader implications for external KMS integrations.
Many thanks,
Kinga Bosse (MPCH)
Get Outlook for iOS
From: cip-discuss@... <cip-discuss@...> on behalf of eho via lists.sync.global <eho=send.it@...>
Sent: Wednesday, March 11, 2026 2:27:05 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-0107: 24 Hour Submission Delay for for End-User CC Transactions - Moritz KieferYou don't often get email from eho=send.it@.... Learn why this is importantSend Safe (multisig) currently is bounded by a ~10 minute signing window due to this constraint. We support this proposal. - toggle quoted message Show quoted textHi Kinga,This has nothing to do with KMS. That interface is completely unchanged and the KMS operations a node will do won't change. This is only about externally signed Daml transactions supporting longer signing delay which doesn't involve the node KMS system.On Thu, Mar 12, 2026 at 6:39 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:
Dear All,
In principle, we agree with this CIP.
As a network KMS provider, however, we would appreciate additional guidance regarding its impact on participant node keys that are hosted in an external KMS. Specifically, we would like to understand whether the proposed changes alter node behavior in a way that would require adjustments by the KMS provider, particularly in how key requests are received and responded to.
It may be that this is fully handled within the Canton codebase and that any key operations will continue to pass through the existing KMS driver interface unchanged. However, before casting our vote, we would appreciate confirmation on whether there are any broader implications for external KMS integrations.
Many thanks,
Kinga Bosse (MPCH)
Get Outlook for iOS
From: cip-discuss@... <cip-discuss@...> on behalf of eho via lists.sync.global <eho=send.it@...>
Sent: Wednesday, March 11, 2026 2:27:05 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-0107: 24 Hour Submission Delay for for End-User CC Transactions - Moritz KieferYou don't often get email from eho=send.it@.... Learn why this is importantSend Safe (multisig) currently is bounded by a ~10 minute signing window due to this constraint. We support this proposal.--Moritz KieferArchitect - Canton NetworkDigital Asset, creators of Daml
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - toggle quoted message Show quoted text
From: cip-discuss@... <cip-discuss@...> on behalf of Moritz Kiefer via lists.sync.global <moritz.kiefer=digitalasset.com@...>
Sent: Thursday, March 12, 2026 3:07:38 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-0107: 24 Hour Submission Delay for for End-User CC Transactions - Moritz KieferHi Kinga,
This has nothing to do with KMS. That interface is completely unchanged and the KMS operations a node will do won't change. This is only about externally signed Daml transactions supporting longer signing delay which doesn't involve the node KMS system.
On Thu, Mar 12, 2026 at 6:39 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:
Dear All,
In principle, we agree with this CIP.
As a network KMS provider, however, we would appreciate additional guidance regarding its impact on participant node keys that are hosted in an external KMS. Specifically, we would like to understand whether the proposed changes alter node behavior in a way that would require adjustments by the KMS provider, particularly in how key requests are received and responded to.
It may be that this is fully handled within the Canton codebase and that any key operations will continue to pass through the existing KMS driver interface unchanged. However, before casting our vote, we would appreciate confirmation on whether there are any broader implications for external KMS integrations.
Many thanks,
Kinga Bosse (MPCH)
Get Outlook for iOS
From: cip-discuss@... <cip-discuss@...> on behalf of eho via lists.sync.global <eho=send.it@...>
Sent: Wednesday, March 11, 2026 2:27:05 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-0107: 24 Hour Submission Delay for for End-User CC Transactions - Moritz KieferYou don't often get email from eho=send.it@.... Learn why this is importantSend Safe (multisig) currently is bounded by a ~10 minute signing window due to this constraint. We support this proposal.
--
Moritz Kiefer
Architect - Canton NetworkDigital Asset, creators of Daml
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
