• Introduction
• System Overview
• Covenant Structure
• Proto-Tokenization and Activation
• Circulation and Reissuance
• Redemption and Exit
• Checkpointing and Auditing
• Fee Architecture
• Economic and Regulatory Model
• Security Analysis
• Implementation Considerations
• Conclusion

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.