This document is also available as PDF download

Introduction

Bitcoin provides self-custodial, censorship-resistant money, yet its
on-chain transaction throughput and latency limit daily payments. The
Lightning Network improves speed and cost but introduces liquidity
constraints and custodial risk in routing nodes and hosted channels.
Recent innovations such as Cashu reintroduce Chaumian ecash—blind-signed
bearer tokens providing privacy and instant transfer—but at the cost of
custodial centralization. Cashu mints hold Lightning liquidity on behalf
of users, placing them under money transmitter regulation and exposing
them to legal and counterparty failure.

This paper presents a protocol design that resolves those trade-offs. By
anchoring ecash issuance and redemption in covenant-enforced collateral
on the Liquid sidechain, we decouple issuance authority from custodial
control. Redemption becomes an enforceable script condition, not a
promise. Mints operate as capital-staked liquidity oracles, and tokens
are claims directly on on-chain L-BTC. Users can verify solvency, redeem
autonomously, and transact privately. The architecture generalizes to
multiple mints sharing a common covenant pool, enabling open
participation, transparency, and sustainable incentives.

System Overview

The system consists of four actor classes:

1. Covenant Pool: a Liquid UTXO locked by a covenant script
   enforcing collateral and redemption rules.

2. Mints: entities staking L-BTC in the covenant to obtain issuance
   quotas and earn peg-in/peg-out fees.

3. Users: holders of blind-signed ecash tokens representing claims
   on the covenant’s L-BTC.

4. Federation/Watchers: optional signers aggregating off-chain
   state roots into periodic on-chain checkpoints.

Each mint maintains off-chain Cashu operations—issuance, burn,
reissuance—while covenant logic guarantees total liabilities never
exceed collateral. Users may transact and reissue ecash privately
through mints, or bypass them entirely by redeeming on-chain.

Covenant Structure

The covenant defines a state object per mint $i$:
$$S_i = (pk_i, q_i, R_i^{inactive}, R_i^{active}, R_i^{spent})$$ where
$pk_i$ is the mint’s public key, $q_i$ its quota (maximum issuance), and
$R_i$ denote Merkle roots for inactive, active, and spent serials
respectively. The covenant enforces:
$$\sum_i value(R_i^{active}) \leq \sum_i q_i$$ and disallows transitions
that violate value conservation:
$$R_i^{inactive} + R_i^{active} + R_i^{spent} = q_i$$

Each mint deposits collateral $q_i$ of L-BTC plus an honesty stake
$h_i$; both are locked by the covenant script. The honesty stake is
slashable for detected inflation or invalid activation proofs.

Proto-Tokenization and Activation

At seeding, a mint pre-tokenizes its full quota as a set of inactive
proto-tokens—cryptographic commitments to denominations but not yet
valid bearer notes. A user initiates a peg-in by paying L-BTC (via
Lightning or Liquid) to the mint, who supplies an activation proof
linking the payment receipt to a subset of inactive serials. Those
serials become active and are blind-signed to the user’s preimages. The
next covenant checkpoint records the transition
$R_i^{inactive} \rightarrow R_i^{active}$, maintaining total value.

Because every activation proof references a funded deposit, no
untokenized liquidity exists: all collateral is represented by
proto-tokens, either inactive, active, or spent. Over-issuance is thus
cryptographically impossible.

Circulation and Reissuance

Active ecash tokens circulate off-chain through standard Chaumian
blinding. Users can reissue spent tokens for fresh ones of equal value,
preserving privacy and fungibility. No on-chain interaction occurs; only
Merkle commitments change at the next checkpoint.

Redemption and Exit

Users may redeem ecash either through the issuing mint or directly via
the covenant.

• Through the mint: the user returns tokens, receives Lightning or
  Liquid payout minus a small off-chain fee. The mint burns the tokens
  and updates its state.

• Direct on-chain redemption: the user constructs a Liquid
  transaction spending the covenant UTXO, providing unblinded token data
  and inclusion proofs. The script verifies validity under $pk_i$,
  checks the serial is unspent, and pays $(1-F_{out})$ to the user,
  $(F_{out})$ to the mint’s fee address.

This guarantees liveness and solvency even if all mints disappear.

Checkpointing and Auditing

Checkpoints anchor off-chain state to the covenant at low cost. Mints or
a federation periodically publish updated Merkle roots $R_i$; these may
be aggregated across mints or encoded as succinct ZK proofs. Checkpoints
occur:

• On schedule (e.g., daily or per-volume threshold)

• Upon dispute or redemption challenge

Each checkpoint transaction updates the covenant state once for all
participating mints. Token holders can locally verify that their notes
are included in $R_i^{active}$ and that the aggregate liabilities remain
within collateral.

Fee Architecture

Fees maintain mint incentives while keeping the system non-custodial.

• Peg-in fees are charged off-chain as spread: users receive tokens
  worth slightly less than their deposit. The mint retains the
  difference as ecash.

• Peg-out fees are deducted on-chain during covenant redemption.

• Checkpoint costs are amortized through peg-in revenues or
  federation aggregation.

• Minimum peg size prevents spam activations and maintains Lightning
  efficiency.

Thus the mint’s income arises naturally from liquidity provision, not
from emissions or reissuance charges.

Economic and Regulatory Model

Traditional Cashu mints custody user funds, constituting money
transmission. In this design, mints never hold client assets; they stake
collateral and issue signed claims redeemable by anyone through
deterministic script logic. Custody and discretion are eliminated. The
system enforces solvency by code, satisfying audit and compliance
requirements without surrendering privacy.

Economically, mints operate as liquidity providers:

• They earn spread and redemption fees.

• They risk their honesty stake upon misbehavior.

• Their capital efficiency scales with checkpoint aggregation.

Competition among mints drives tight spreads and reliable service while
users retain absolute redemption sovereignty.

Security Analysis

Over-issuance: prevented by covenant value constraints and
activation proofs. Mint disappearance: users redeem directly
on-chain. Checkpoint omission: federation penalizes inactivity via
quota reduction or slashing. Privacy: Chaumian blinding preserves
unlinkability; only aggregate commitments reach the
chain. Auditability: any observer can verify total supply and
collateral equality.

Implementation Considerations

Liquid currently supports multisig and limited introspection (e.g.,
CHECKSIGFROMSTACK). Covenant functionality may require additional
opcodes such as OP_TXHASH or covenant templates. Off-chain software
leverages existing Cashu and Lightning infrastructure: mints run Cashu
daemons with covenant integration; users retain familiar wallets.
Checkpoint aggregation and watcher federation can be implemented as
sidecar services similar to Liquid functionaries.

Conclusion

By embedding Cashu’s blind-signed tokens within covenant-enforced
collateral, we reconcile privacy with self-custody. Mints transform from
custodians to capital-staked signers, and users regain bearer control
over digital cash. The result is non-custodial, auditable ecash that
scales Lightning’s privacy model and dissolves the regulatory boundaries
of money transmission. This architecture completes Chaum’s vision using
Bitcoin’s modern cryptographic tools: decentralized issuance, verifiable
reserves, and unconditional redemption—Bitcoin as cash, at last.