CIP-TBD - Decentralized Stablecoin Enablement on Canton (iCC)
cip-discuss2 messagesstarted 24-04-2026
Number: CIP-TBD Title: Decentralized Stablecoin Enablement on Canton (iCC)Author(s): Elliott Dehnbostel Type: Tokenomics Status: Draft Created: 2026-04-24 License: CC0-1.0
Abstract
--------Inverse Canton Coin (iCC) is a non-redeemable token on Canton whose
USD value tracks 1/p, where p is the CC/USD oracle price. iCC is
minted by burning 1/p^2 CC per iCC and is destroyed only by burning
to pay network fees. Canton holds no iCC-denominated liabilities.The network incentive is straightforward: higher transaction volume.
iCC is the primitive that makes a Canton-native decentralized
stablecoin (cUSD) tractable; cUSD payments, arbitrage, and mint/redeem
activity drive fee revenue independent of CC price speculation.
Motivation
----------Canton holders can take directional positions in CC (long by holding,
short by selling) but have no native primitive for expressing non-
directional views. A holder of equal balances of CC and iCC has USD
portfolio value p + 1/p, with minimum $2 at p = $1 and convex increase
as p moves in either direction. iCC is the primitive that enables this
position.A secondary consequence of the mint curve is CC destruction: each iCC
minted permanently removes 1/p^2 CC from CC supply. The rate of CC
destruction per USD of gas activity scales as 1/p.
Specification
-------------Price. At oracle price p (USD per CC), the canonical USD value of
1 iCC is 1/p. Equivalently, 1 iCC = 1/p^2 CC.Mint. A minter calls Mint(n) to receive n iCC. The operation debits
n/p^2 CC from the minter and destroys it (reduces CC supply). No
reverse operation exists.Burn. A transaction envelope may specify a fee in USD (fee_usd). At
settlement:fee_icc = ceil(fee_usd * p)fee_icc is burned from the submitter's iCC balance. Fee credit is
distributed to SVs in iCC per existing fee-distribution rules.
Transactions that do not specify fee_usd pay in CC per existing
behavior.Oracle. p is read from Canton's existing in-protocol CC/USD oracle. No
new oracle infrastructure is introduced. While the oracle is in a
failure state as defined by that oracle, Mint and USD-denominated
fees are suspended; CC-denominated fees continue.CC destruction. CC paid at Mint is destroyed (removed from CC supply).
No protocol-operated iCC -> CC conversion is permitted.SV distribution. SVs receive fee income in iCC. SVs may hold or sell
iCC; no protocol reverse conversion is provided.
Rationale
---------Geometric inverse. 1/p has no zero crossing, is symmetric in
log-price, and produces a convex USD-payoff for a 1-CC + 1-iCC
portfolio. A linear inverse K - p crosses zero at p = K. A flat $1
price requires a peg defense and a redemption obligation.Non-redeemable. A redemption path iCC -> CC at stated price would
create a protocol liability scaling as 1/p, growing hyperbolically as
p -> 0. Non-redemption removes the liability entirely.No interest rate. Interest is compensation for a liability. iCC
represents no liability.No supply cap. Mint cost scales 1/p^2. Issuance is self-limiting.
Economic properties
-------------------Portfolio value. A holder of (a CC, b iCC) has USD value a*p + b/p,
minimized at p = sqrt(b/a) with minimum value 2*sqrt(a*b).Half-split floor. A holder receiving N CC at price p_0 who converts
half the CC value to iCC (burns N/2 CC, mints N*p_0^2/2 iCC) holds a
portfolio with USD minimum N*p_0, achieved at p = p_0.CC destruction rate. At daily gas volume G (USD) and price p, daily
CC destroyed by iCC mint to replenish fee-burned iCC is G/p. The rate
in CC units rises inversely with p.
Use cases
---------Stablecoin. A cUSD protocol can be built on iCC as follows.Deposit. A user brings $D of symmetric collateral — D/(2p) CC +
D*p/2 iCC at the current oracle price p — and receives D cUSD. The
contract does not burn or mint for the user; the user acquires the
symmetric pair externally and deposits it.Pool. Aggregate contract holdings after any sequence of deposits and
redemptions are (A CC, B iCC), with USD value at current price p
given by V = A*p + B/p.Redemption. Burning 1 cUSD returns A/V CC + B/V iCC at the current
oracle price — a 1/V slice of the pool. USD value = V * (1/V) = $1
exactly, at any oracle price. Never more. Always executable for
(A, B > 0). Pool composition ratio A:B is preserved through every
redemption.Over-collateralization. For a single deposit of $D at p_0, the
reserve's USD value at later price p is (D/2)(p/p_0 + p_0/p) >= D,
with equality only at p = p_0. For a mixture of deposits at various
prices, aggregate V >= total cUSD debt at all times by linearity. The
contract is never under-collateralized.Round-trip PnL for a depositor at p_0 who redeems at p_1:ΔUSD = -(D/2) * (p_1 - p_0)^2 / (p_0 * p_1) <= 0The depositor always pays a non-negative straddle premium on any
price movement. Remaining cUSD holders see their per-unit coverage
strictly increase: after k redemptions from a pool at (V, D),
remaining coverage is (V−k)/(D−k) > V/D whenever V > D. When all
cUSD is eventually redeemed, the pool retains V − D of residual
value as protocol equity.
Backwards compatibility
-----------------------This CIP adds an optional fee-payment path. Transactions that do not
specify fee_usd are unchanged. No migration is required.
Security considerations
-----------------------Oracle. Mint and burn prices depend on Canton's existing CC/USD
oracle. No new trust boundary is introduced.Demand collapse. If Canton transaction volume falls materially, iCC
market price can drift below the 1/p arbitrage ceiling. Gas-burn
demand is the baseline floor. A downstream cUSD contract, if
deployed, supplies an additional arbitrage route that pins iCC at
1/p independent of gas demand (see Q4); until such a contract
exists, demand collapse is an unmitigated risk property shared
with any utility token.Mint spam. Mint consumes CC and is self-funded. A per-block,
per-submitter cap of 1% of total iCC supply bounds oracle-
manipulation upside.Regulatory framing. iCC is a non-redeemable bearer voucher with a
variable USD conversion rate, usable only for paying protocol fees.
It pays no yield, has no issuer-guaranteed value, and has no fiat
settlement path.
Questions raised in review
--------------------------Q: What is the target use case? Who are the intended users?A: Canton offers no native instrument for expressing a non-directional
view on CC. iCC provides a token whose USD value varies inversely
with CC, such that a 1:1 CC + iCC portfolio has convex USD response to
any CC price movement. Intended users include:- CC treasuries (SVs, Digital Asset, ecosystem funds) hedging tail
risk without liquidating principal
- CC holders expressing volatility views without managing strikes,
expiries, or rollover
- Protocols holding CC receipts that require a USD floor (see
"Use cases" above)
Q: Why implement this in the protocol rather than as an app-layer
derivatives market?A: App-layer constructions can approximate the payoff but require
strike and expiry selection, active market making, and exposure to
market-maker solvency in stress scenarios. The protocol-level
construction produces the payoff from the arithmetic of the mint
curve alone, with no market-maker or parameter calibration.Two properties specifically require protocol-level implementation:- The one-way CC -> iCC conversion (non-redeemability) eliminates
bank-run vectors that apply to market-making alternatives.
- Permanent CC destruction via the 1/p^2 mint cost is a structural
effect on CC supply that market participants (who are CC-neutral
at the protocol level) cannot produce.This CIP does not preclude app-layer derivatives markets. A CC
perpetual or options protocol can coexist with iCC and may use iCC as
an internal hedging instrument.
Q: Why have no other chains built this?A: The design requires two protocol-level preconditions that Canton
has and most other chains do not:- An in-protocol native-token/USD price oracle. Canton's SV-quorum
oracle satisfies this. Ethereum, Solana, Bitcoin, and other
general-purpose L1s keep price oracles at the application layer
(Chainlink, Pyth, etc.) — trusted third-party feeds, not protocol
primitives with the same trust boundary as the rest of the chain.- USD-denominated transaction fees as a first-class mechanism.
Canton already prices fees at $60/MB and exposes the conversion
to users at the protocol layer. Most other chains price fees
purely in the native token; the USD denomination, if offered at
all, is a wallet-layer display convention.Without both, a chain can approximate iCC as an app-layer contract,
but loses the counter-cyclical native-token destruction property
(can't touch core fee flow) and inherits application-layer oracle
trust (not protocol consensus). The resulting product is a weaker
derivative with additional trust boundaries.
Q: What if iCC is not liquid?A: iCC does not require a dedicated liquidity venue. The cUSD
contract (if deployed) acts as an implicit exchange mechanism via
its symmetric-pair deposit rule. A holder of N iCC seeking a USD
exit at CC price p can execute:1. Purchase N/p^2 CC on the CC market (liquid). Cost: N/p USD.
2. Deposit N/p^2 CC + N iCC (symmetric pair, total value
2N/p USD) into the cUSD contract. Receive 2N/p cUSD.
3. Sell 2N/p cUSD on the cUSD market (liquid). Receive 2N/p USD.Net: 2N/p − N/p = N/p USD, exactly the fair-market value of N iCC
at current price. The user never trades iCC directly.The same arbitrage route enforces iCC's price from both sides:- Upper bound. If iCC market price rises above 1/p, arbers mint
fresh iCC via the mint facility (burn 1/p^2 CC, receive 1 iCC)
and sell. Market price is capped at 1/p.- Lower bound. If iCC market price falls below 1/p, arbers buy
cheap iCC, pair with CC, deposit into cUSD, sell cUSD for
profit. Market price is pulled back up to 1/p.iCC's price is pinned at 1/p by the mint facility and the cUSD
contract acting jointly. No dedicated AMM or order book is required.
Gas-burn demand provides additional support but is not a necessary
condition for price stability.- Why SVs should support CIP-TBD (iCC)
=====================================iCC adds a single protocol primitive that delivers direct economic
benefits to SVs and enables a downstream class of products (cUSD and
stablecoin-native applications) that drive fee revenue independent of
CC price speculation.
What is the catch: up to 0.3% yearly network inflation in the worst case
imaginable (explained below).
Direct benefits
---------------1. iCC-denominated fee income. USD-specified fees settle in iCC via
existing fee-distribution rules. SVs retain optionality: hold iCC,
sell for CC, or sell for fiat. A second income asset with a
payoff profile orthogonal to CC.2. CC supply reduction. Every iCC mint permanently destroys CC at
1/p^2 CC per iCC. SVs as large CC holders benefit proportionally
from this deflation. Strategic minting concentrates burns during
CC rallies — supply contraction at peak prices.3. Counter-cyclical stake defense. Fee-driven iCC mint creates
structural CC demand at 1/p CC per dollar of gas, intensifying
during drawdowns. Validator stake value is partially defended by
the same activity that generates fees.
Indirect benefits (once cUSD is deployed)
-----------------------------------------4. Canton-native stablecoin. cUSD built on iCC uses no governance
token, no liquidation logic, no peg defense, and no external
issuer. Structural over-collateralization from straddle convexity.
Never under-collateralized.5. Fee-revenue floor. Trinity-driven activity (CC/iCC rebalancing,
cUSD transfers, arbitrage) produces modeled fee revenue of
~$85K–$860K/year per $1B CC mcap at Canton pricing ($0.50/tx),
independent of enterprise dapp adoption. Scales linearly with CC
mcap.
Risk profile
------------- Uses existing CC/USD oracle; no new trust boundary (though oracle
"load" grows). We must cap on the fraction of iCC supply that can be
minted per-round to neutralize regime-change arbitrage. We propose
a per-round aggregate limit of 0.0025% iCC supply minted, configurable.
With ~104K rounds / year (5 minutes/round), this means iCC can dilute
by at most ~14x per year. The threat mitigated by the round limit is "unfair"
iCC dilution due to oracle front-running and/or manipulation, which only
applies in downward regime changes. We also propose a ~0.5% iCC mint fee,
which is burned. Simulations show that assuming 100% volatility in CC, we
expect a net (of fee) effective dilution of negative 0.17% in iCC per year coming
from pure arbitrage activity given these parameters. Sensitivity: the number
rises to positive ~0.13% net effective dilution per year under a 150% volatility
regime, and positive ~0.58% net effective dilution under a 200% volatility regime.
This equates to around -0.08% / +0.07% / +0.29% net effective dilution of the value
in the network, assuming that CC and iCC have equivalent capitalization. If you're
looking for a "catch" to this proposal, this is the whole catch! In reality, Canton is
likely to hover between 100% and 150% volatility, roughly neutralizing dilution.
Over 200% volatility would be a "meme-coin" market regime, for reference.
- Backwards-compatible (existing CC-fee path unchanged). We
simply make it possible to pay for a transaction in iCC, per the
oracle price.
- Volatility anti-fragility: the 1/p² mint cost creates minting pressure
at both price extremes — cheap insurance at highs, profitable short
positioning at lows. iCC demand is proportional to volatility, not direction.
Each mint destroys CC. Every volatility event, up or down, reduces CC
supply and raises the fundamental value of every remaining token.
CC is anti-fragile in the strict sense: volatility is a positive input to its
valuation, at all timescales.
- Zero protocol liability: non-redeemable iCC eliminates bank-run
vector. iCC can only be used to pay transaction fees on Canton;
the fungibility of iCC for transaction fees is essential for iCC to
have fundamental value within the network. The lack of iCC->CC
redemption prevents exactly the catastrophic reflexive minting
loop that incinerated $40Bn (!) in 4 days (!!) on Terra-Luna.
- Balance-of-power robustness is guaranteed by consensus. SV admission
is governance-permissioned — consensus weight is assigned, not purchased.
Market capitalization, in any form, does not map to consensus power. A CC
drawdown that inverts to mcap(iCC) > mcap(CC) does not threaten security:
iCC holders gain no consensus role, and existing SVs cannot be displaced
by market accumulation of either token. The typical asymmetric demand
(CC > iCC) is a natural consequence of SVs' structural need to hold CC
but it is not a requirement for security.
Questions for SVs
-----------------1. Oracle commitment. Are you comfortable extending the existing
CC/USD oracle's trust boundary to mint/burn pricing? Any proposed
tightening of oracle-failure semantics?3. Fee-income preference. SVs receive fee distribution in iCC and
CC. Preference: hold iCC, auto-convert to CC on receipt, or leave
configurable per-SV? Affects each SV's long-term CC vs iCC
balance-sheet composition.4. Deployment sequence. Prefer iCC standalone first (observe market
behavior before cUSD inherits its properties), or coordinated
iCC + cUSD launch?5. Strongest objection. What single concern would prevent your
support? Naming it early lets us address it in the CIP rather
than at vote time.
