Skip to content

Commit 399befd

Browse files
cocreaturecocreature
committed
Add CIP for supporting a 24h submission delay for CC
Signed-off-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
1 parent 570b857 commit 399befd

File tree

1 file changed

+169
-0
lines changed

1 file changed

+169
-0
lines changed

‎cip-24h-signing-delay/cip-XXXX.md‎

Lines changed: 169 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,169 @@
1+
## Title
2+
3+
<pre>
4+
CIP: CIP XXXX
5+
Layer: Daml
6+
Title: 24h Submission Delay for End-User CC Transactions
7+
Author: Simon Meier, Moritz Kiefer
8+
Status: Draft
9+
Type: Standards Track
10+
Created: 2026-01-21
11+
License: CC0-1.0
12+
</pre>
13+
14+
## Abstract
15+
16+
This CIP supports a 24 submission delay between preparing and
17+
execution for all CC end-user transactions. Specifically this applies to all
18+
token standard operations making CC fully compliant with the token as
19+
well as the CC specific public actions of creating, renewing, and
20+
archiving preapprovals, purchasing traffic, and tapping funds on
21+
DevNet.
22+
23+
## Copyright
24+
25+
This CIP is licensed under CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)
26+
27+
## Specification
28+
29+
### High Level Summary
30+
31+
The current 10 minute submission delay comes from the use of
32+
`OpenMiningRound`. To support a 24h submission delay a new
33+
`ExternalPartyConfigState` contract is introduced that is active for
34+
48h and copies the subset of information required for token standard
35+
operations from the latest `OpenMiningRound` contract at the time of
36+
its creation.
37+
38+
### Detailed Changes
39+
40+
- Add a new configuration parameter `externalPartyConfigStateTickDuration` which defaults to 24h.
41+
- Introduce a new `ExternalPartyConfigState` template which stores the
42+
amulet price, the round number, the holding fees and `maxNumInputs`,
43+
`maxNumOutputs`, `maxNumLockHolders` copied from the
44+
`OpenMiningRound` contract at the time of creation. Each of these
45+
contracts is active for `2 * externalPartyConfigStateTickDuration` and a new one is created every `externalPartyConfigStateTickDuration`.
46+
- Change the token standard implementation of CC to rely on
47+
`ExternalPartyAmuletRules` and `ExternalPartyConfigState` instead of `AmuletRules` and
48+
`OpenMiningRound`. At any given point the most recent
49+
`ExternalPartyConfigState` contract is still valid for at least
50+
`externalPartyConfigStateTickDuration`, i.e., 24h with the default
51+
configuration providing the desired submission delay. New `Amulet` contracts created from those choices will
52+
have the round they were created in set to the round from `ExternalPartyConfigState`.
53+
- Change the transfer implementation to create `FeaturedAppActivityMarker` contracts instead of directly creating `AppRewardCoupon`. This is required
54+
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.
55+
- Enforce additional restriction on the `AmuletConfig`. These restrictions all hold already on DevNet, TestNet and MainNet so this is not changing the configuration.
56+
- CC usage fees, which were set to zero in CIP 78, can no longer be set to non-zero values.
57+
- `extraFeaturedAppRewardAmount` must be identical to `featuredAppActivityMarkerAmount`.
58+
- The `futureValues` field in the configuration schedule must be empty. The options for setting it were already removed
59+
in CIP 51. Now it is just enforced more directly.
60+
- Expose choices for `AmuletRules_BuyTraffic` and `AmuletRules_Tap`
61+
through two new interface packages `splice-api-tap-v1` and
62+
`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.
63+
- Add new `LockedAmulet_UnlockV2` and `LockedAmulet_OwnerExpireLockV2` choices that do not require an `OpenMiningRound`.
64+
- Remove the existing `LockedAmulet_Unlock` and `LockedAmulet_OwnerExpireLock` choices.
65+
- Deprecate the non-token standard `TransferCommand` template and corresponding validator endpoints so they can be removed
66+
in future versions. This also applies to the corresponding validator APIs `/v0/admin/external-party/transfer-preapproval/prepare-send`
67+
and `/v0/admin/external-party/transfer-preapproval/submit-send`.
68+
- Add new `LockedAmulet_ExpireAmuletV2` and `Amulet_Expire` choices that require `ExternalPartyConfigState` instead of `OpenMiningRound`.
69+
- Remove the existing `LockedAmulet_ExpireAmulet` and `Amulet_Expire` choices.
70+
71+
## Motivation
72+
73+
Between preparing and executing a transaction, the key(s) registered in the topology state
74+
for the submitting external party must sign the transaction. This
75+
often requires explicit human approval sometimes even from multiple
76+
people. Doing that within a 10 minute window can be quite disruptive
77+
and does not match the expectations from other networks or even other
78+
assets on the global synchronizer. Supporting a 24h delay aligns
79+
Canton Coin with other CIP 56 assets.
80+
81+
## Rationale
82+
83+
### Propagation Delay
84+
85+
Supporting a longer submission delay necessarily implies that the
86+
accessed contracts need to be active for at least the duration of the
87+
submission delay. This is what the new `ExternalPartyConfigState`
88+
contract accomplishes.
89+
90+
This does however imply that changes to the
91+
values stored on that contract propagate more slowly. More specifically it
92+
takes up to 48h until the old values cannot be used anymore.
93+
94+
For `maxNumInputs`, `maxNumOutputs`, `maxNumLockHolders` this is a
95+
non-issue as those values have not been changed once and we don't
96+
expect to need any quick changes. The `amuletPrice` in a CC transfer
97+
is only used for converting the holding fee and from USD to CC. For holding fees,
98+
minor fluctuations play a negligible role so price changes propagating
99+
slower has negligible impact.
100+
101+
There is a bigger impact on traffic purchases where a price change is
102+
more significant. There is not really any way to enforce use of recent
103+
prices and support a long submission delay though so this is a
104+
necessary tradeoff.
105+
106+
### Holding Fees
107+
108+
`Amulet` contracts created via choices relying on
109+
`ExternalPartyConfigState` will have the round they were created in
110+
set to the round at the point in time when `ExternalPartyConfigState`
111+
was created. This can be up to 48h in the past at the time the
112+
transaction gets executed. By switching expiry to be based on
113+
`ExternalPartyConfigState` we compensate for that by delaying expiry
114+
by the same amount so the effective expiry date of `Amulet` contracts
115+
is unchanged.
116+
117+
### Additional AmuletConfig Restrictions
118+
119+
The additional restrictions enforced on `AmuletConfig` are required to
120+
make the implementation feasible. In particular switching from creating `AppRewardCoupon` contracts to `FeaturedAppActivityMarker` without changing the issued rewards requires
121+
that a CC transfer only produces featured application rewards, implied by no fees, and
122+
`extraFeaturedAppRewardAmount` must be identical to `featuredAppActivityMarkerAmount`.
123+
124+
## Limitations
125+
126+
This change supports a 24h submission delay for token standard
127+
operations, traffic purchases and tap. However, reward minting is
128+
still subject to the 10 minute submission delay. Short term, the
129+
minting delegation introduced by CIP 96 allows to delegate minting to
130+
a party that can support a shorter submission delay. Longer term, we
131+
expect that as part of switching to traffic based rewards we will also
132+
be able to support a longer signing delay for reward minting.
133+
134+
## Backwards compatibility
135+
136+
### Token Standard APIs
137+
138+
Changing the CC implementation of the token standard APIs to use
139+
`ExternalPartyConfigState` is an implemenation-internal change. Users of the token
140+
standard APIs do not need to make any change in their application.
141+
Note however, that the choice context returned by Canton Coin Scan
142+
will change. As applications should treat this opaquely and just pass
143+
it along, this should still not require changes in applications.
144+
145+
### Locking APIs
146+
147+
Applications that directly use `LockedAmulet_Unlock` or
148+
`LockedAmulet_OwnerExpireLock` will need to switch to the `V2` choices
149+
when they recompile their code against the new amulet versions. Note
150+
that existing DARs compiled against the previous version will continue
151+
working so the upgrade can be done at the developer's preferred
152+
schedule.
153+
154+
### Transaction History Parsing
155+
156+
App providers that parse transaction history through the [token standard
157+
API](https://docs.sync.global/app_dev/token_standard/index.html#reading-and-parsing-transaction-history-involving-token-standard-contracts)
158+
no change is required.
159+
160+
App providers that parse the CC specific choices directly will need to adjust
161+
your parser. In particular, `TransferPreapproval_SendV2` and the token
162+
standard implementation of transfers and allocations no longer
163+
exercise `AmuletRules_Transfer` internally and instead inline the
164+
adjusted implementation of that choice to rely on
165+
`ExternalPartyConfigState`.
166+
167+
## Reference implementation
168+
169+
A draft PR for the Daml changes can be found on [Github](https://github.com/hyperledger-labs/splice/pull/3487).

0 commit comments

Comments
 (0)