From f9cf6f1a06c97ddccf81919f943911e97145a133 Mon Sep 17 00:00:00 2001 From: Moritz Kiefer Date: Thu, 15 Jan 2026 09:47:22 +0000 Subject: [PATCH 1/5] Add CIP for supporting a 24h submission delay for End-User CC Transactions Signed-off-by: Moritz Kiefer --- cip-24h-signing-delay/cip-XXXX.md | 169 ++++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 cip-24h-signing-delay/cip-XXXX.md diff --git a/cip-24h-signing-delay/cip-XXXX.md b/cip-24h-signing-delay/cip-XXXX.md new file mode 100644 index 0000000..cb1a337 --- /dev/null +++ b/cip-24h-signing-delay/cip-XXXX.md @@ -0,0 +1,169 @@ +## Title + +
+  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
+
+ +## 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 78, 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 51. 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 56 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 96 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). From bde26332854199e602438bfb8e4937b58d8ddc15 Mon Sep 17 00:00:00 2001 From: moritzkiefer-da <45630097+moritzkiefer-da@users.noreply.github.com> Date: Fri, 23 Jan 2026 14:16:52 +0100 Subject: [PATCH 2/5] Update cip-24h-signing-delay/cip-XXXX.md Co-authored-by: Matteo Limberto Signed-off-by: moritzkiefer-da <45630097+moritzkiefer-da@users.noreply.github.com> --- cip-24h-signing-delay/cip-XXXX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cip-24h-signing-delay/cip-XXXX.md b/cip-24h-signing-delay/cip-XXXX.md index cb1a337..74ff54d 100644 --- a/cip-24h-signing-delay/cip-XXXX.md +++ b/cip-24h-signing-delay/cip-XXXX.md @@ -15,7 +15,7 @@ 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 +token standard operations making CC fully compliant with the token standard as well as the CC specific public actions of creating, renewing, and archiving preapprovals, purchasing traffic, and tapping funds on DevNet. From 368bc9254ea4968a75a5d1a25773501d7db67195 Mon Sep 17 00:00:00 2001 From: moritzkiefer-da <45630097+moritzkiefer-da@users.noreply.github.com> Date: Fri, 23 Jan 2026 14:16:57 +0100 Subject: [PATCH 3/5] Update cip-24h-signing-delay/cip-XXXX.md Co-authored-by: Matteo Limberto Signed-off-by: moritzkiefer-da <45630097+moritzkiefer-da@users.noreply.github.com> --- cip-24h-signing-delay/cip-XXXX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cip-24h-signing-delay/cip-XXXX.md b/cip-24h-signing-delay/cip-XXXX.md index 74ff54d..ac36059 100644 --- a/cip-24h-signing-delay/cip-XXXX.md +++ b/cip-24h-signing-delay/cip-XXXX.md @@ -13,7 +13,7 @@ ## Abstract -This CIP supports a 24 submission delay between preparing and +This CIP supports a 24 hours 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 standard as well as the CC specific public actions of creating, renewing, and From f8262df2954f0605e3c94c126e43a48f3969e79e Mon Sep 17 00:00:00 2001 From: moritzkiefer-da <45630097+moritzkiefer-da@users.noreply.github.com> Date: Fri, 23 Jan 2026 16:40:31 +0100 Subject: [PATCH 4/5] Update cip-24h-signing-delay/cip-XXXX.md Co-authored-by: Simon Meier Signed-off-by: moritzkiefer-da <45630097+moritzkiefer-da@users.noreply.github.com> --- cip-24h-signing-delay/cip-XXXX.md | 1 + 1 file changed, 1 insertion(+) diff --git a/cip-24h-signing-delay/cip-XXXX.md b/cip-24h-signing-delay/cip-XXXX.md index ac36059..db1eb6a 100644 --- a/cip-24h-signing-delay/cip-XXXX.md +++ b/cip-24h-signing-delay/cip-XXXX.md @@ -67,6 +67,7 @@ its creation. 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. +- Update CIP-0056 to remove the ["Canton Coin Limitations" section in CIP-0056](https://github.com/global-synchronizer-foundation/cips/blob/main/cip-0056/cip-0056.md#canton-coin-limitations) once the change from this CIP lands on MainNet ## Motivation From 0bcf79eefaef0e014a47774589b6e4609f68e9a3 Mon Sep 17 00:00:00 2001 From: Moritz Kiefer Date: Fri, 30 Jan 2026 16:49:40 +0000 Subject: [PATCH 5/5] Mention scan_txlog.py removal Signed-off-by: Moritz Kiefer --- cip-24h-signing-delay/cip-XXXX.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cip-24h-signing-delay/cip-XXXX.md b/cip-24h-signing-delay/cip-XXXX.md index db1eb6a..0ed1e8e 100644 --- a/cip-24h-signing-delay/cip-XXXX.md +++ b/cip-24h-signing-delay/cip-XXXX.md @@ -68,6 +68,8 @@ its creation. - Add new `LockedAmulet_ExpireAmuletV2` and `Amulet_Expire` choices that require `ExternalPartyConfigState` instead of `OpenMiningRound`. - Remove the existing `LockedAmulet_ExpireAmulet` and `Amulet_Expire` choices. - Update CIP-0056 to remove the ["Canton Coin Limitations" section in CIP-0056](https://github.com/global-synchronizer-foundation/cips/blob/main/cip-0056/cip-0056.md#canton-coin-limitations) once the change from this CIP lands on MainNet +- The `scan_txlog.py` script will be removed in favor of documentation on how to parse the Scan update API as updating it to these changes + would have significant cost and it hasn't kept up with the scale requirements of mainnet for a while. ## Motivation