28 May 2025 · 7 min read rgb stablecoin taproot

Towards a Privacy-Preserving Stablecoin on Bitcoin: An Architectural Note on RGB-Based Reserve Anchoring

Some notes on the design of a collateralised stablecoin issued over RGB, with reserve proofs anchored to Bitcoin via Taproot. What follows is a work-in-progress and makes no claim to completeness.

1. Motivation and Scope

Most stablecoins in circulation today are implemented as ERC-20 tokens on Ethereum. This is a perfectly sensible engineering decision for many use cases, but it carries certain trade-offs that are worth examining. In particular, the account-based model and the public global ledger make user balances and transaction flows trivially observable — a state of affairs that seems, at least to this author, rather at odds with the original cypherpunk aspirations of digital cash.

We set out to explore an alternative: a fully collateralised stablecoin issued under the RGB protocol, which settles atop Bitcoin. The core idea is straightforward. RGB employs a client-side validation model in which transaction data never hits the blockchain; only cryptographic commitments are anchored on-chain. This gives us, in principle, a degree of privacy that account-based systems simply cannot offer, whilst retaining the security guarantees of Bitcoin’s proof-of-work.

Our design attempts to reconcile three properties that are traditionally rather difficult to satisfy simultaneously: legal-grade compliance through off-chain custody and reconciliation, transparent proof-of-reserve through on-chain anchoring, and user privacy through UTXO-based programmability. Whether we have succeeded in this ambition remains an open question, and we welcome scrutiny.

2. Architecture

The following diagram attempts to capture the principal components and data flows. We confess it is somewhat busier than one might like; real-world financial plumbing tends to resist elegant simplification.

flowchart TD  
    classDef offchain fill:diagramAccentMuted,stroke:diagramAccent,color:diagramAccent
    classDef onchain  fill:diagramSuccessBg,stroke:diagramSuccess,color:diagramSuccessText
    classDef decision fill:diagramSurface,stroke:diagramBorderMuted,stroke-dasharray:5 5,color:diagramText

    CUST[Customer]:::offchain
    RAMP[Payment Gateway / Bank ACH]:::offchain
    ACC[Custodian USD Omni Account]:::offchain
    TRE[Treasury Desk]:::offchain
    BRO[Primary Dealer / Repo Agent]:::offchain
    TBL[T-Bill / Tri-party Repo Pool]:::offchain
    SNAP[End-of-day Reconciliation Snapshot]:::offchain
    RES[Reserve Engine Merkle Builder]:::offchain
    POR[Taproot ReserveProof Commit]:::onchain
    WAL[RGB Wallet]:::onchain
    DEX[DEX / CEX Integration]:::onchain
    REDEEM{Redemption Request}:::decision
    PAYOUT[USD Payout / ACH or SWIFT]:::offchain

    %% fiat in / out
    CUST --> RAMP --> ACC --> TRE
    TRE --> BRO --> TBL
    TRE --> ACC --> PAYOUT --> CUST

    %% onchain mint/burn
    TRE --> WAL
    WAL --> DEX
    CUST --> WAL

    %% redemption branch
    CUST --> REDEEM
    REDEEM -- Yes --> WAL --> TRE
    WAL --> TRE
    TRE --> ACC

    %% proof-of-reserve
    SNAP --> RES --> POR
    POR -.-> WAL
    POR -.-> DEX

    class CUST,RAMP,ACC,TRE,BRO,TBL,SNAP,RES,PAYOUT offchain
    class WAL,DEX,POR onchain
    class REDEEM decision

The blue nodes represent off-chain fiat movement; green nodes denote on-chain Bitcoin and RGB actions; grey diamonds are user decisions. The path SNAP -> RES -> POR is the daily proof-of-reserves anchoring pipeline, which we shall discuss in some detail below.

3. Minting and Redemption

Minting

The mint flow proceeds in three stages. First, the user deposits USD via a regulated payment gateway or ACH transfer into a custodian’s omnibus account — legally segregated under a “for the benefit of users” structure. Second, the treasury desk allocates a portion of the pooled reserves to T-Bills or tri-party repo arrangements through a primary dealer. Third, the treasury authorises a mint transaction, issuing RGB20-compatible tokens to the user’s wallet.

We should be candid about the trust assumptions here: the treasury desk holds considerable power. It controls both fiat reserves and the mint authority. In an ideal world we would distribute this authority across a multisig arrangement with time-locks, and we consider this an important piece of future work.

Redemption

Redemption is roughly the inverse. The user initiates a burn request through their RGB wallet. Tokens are destroyed (we discuss the precise mechanisms below), a redemption ticket is issued, and USD is wired back to the user’s linked bank account via ACH or SWIFT. The latency of this process is dominated not by the blockchain components, but by the traditional banking rails — a humbling reminder that off-chain infrastructure remains the bottleneck.

4. Reserve Proof Anchoring

This is, in our view, the most interesting part of the design — and also the part where we are least confident that we have got things right.

The pipeline works as follows. At the end of each business day, the custodian produces a snapshot (SNAP) of fiat balances and T-Bill allocations, currently in CSV or XML format. A reserve engine (RES) then constructs a Merkle tree over these balances, covering customer positions, treasury reserves, and matched burns. Finally, the Merkle root is committed to Bitcoin’s Taproot tree (POR), without using OP_RETURN.

The choice of Taproot anchoring rather than OP_RETURN is deliberate. It avoids polluting the UTXO set with unspendable outputs and benefits from Taproot’s script-masking properties. External auditors and clients can verify that the committed reserves match the on-chain token supply, without individual user balances being revealed.

However, we must be honest about the limitations. The on-chain anchor proves only that someone committed a particular hash on a particular day. It does not, by itself, prove that the underlying fiat reserves actually exist. The snapshot data is self-reported by the custodian. To meaningfully strengthen this assumption, one would need to introduce third-party audit oracles, or ideally attestations from trusted hardware (TEE). We regard this as the most pressing open problem in the design.

5. Burn Mechanics

“Burning” tokens on RGB is not a metaphor. It is a concrete, programmable supply-reduction action, and the protocol affords several distinct strategies. We have enumerated four below, though we suspect this taxonomy is unlikely to be exhaustive.

Method	RGB Action	Supply Effect	Remarks
True Burn	`burn` transition to null seal	Permanently reduced	The cleanest approach. Total supply is irreversibly decreased, which aligns with the “redemption equals extinction” doctrine found in MiCA and U.S. e-money regulation.
Redemption Vaulting	Transfer to issuer custody; later re-minted or burned	Temporarily removed from circulation	Operationally convenient for batch redemption, but it introduces a subtle risk: the mint authority could, in principle, re-issue vaulted tokens without corresponding new deposits. We would advise strict on-chain constraints on re-minting if this path is adopted.
Frozen Status	Tokens marked `frozen` in state	Logically unspendable but visible	Useful for fraud investigation and legal holds. The tokens remain on-chain and auditable, which is a desirable property under court order.
Custodial Sink	Tokens sent to multisig sink, hidden from UI	Technically extant but unusable	A somewhat inelegant compromise for jurisdictions where only “circulating” supply must match reserves. We include it for completeness but would not recommend it as a primary mechanism.

Our strong preference is for the true burn approach. It provides the simplest accounting, the strongest regulatory alignment, and — perhaps most importantly — the least scope for operational mishap.

6. On the Choice of RGB

The decision to build on RGB rather than, say, an EVM-compatible chain deserves some justification.

The primary consideration is privacy. RGB transactions are validated client-side; there is no global ledger on which user balances or transaction graphs are visible. In a stablecoin context, this is not merely a nicety but arguably a requirement. Financial privacy is a reasonable expectation, and one that most existing stablecoin designs fail rather badly at providing.

A secondary consideration is the anchoring surface. Bitcoin’s proof-of-work provides the strongest settlement guarantees available in the industry, and Taproot’s script structure is remarkably well-suited to embedding compact commitments. RGB inherits this security without requiring a separate consensus mechanism.

Finally, UTXO composability allows issued assets to participate in swaps, collateralisation, and other programmable financial constructs. The degree to which this is useful in practice remains to be seen, but the optionality is welcome.

7. Legal and Regulatory Considerations

We are cryptographers, not lawyers, and the following should not be taken as legal advice. That said, certain structural decisions have clear regulatory implications, and it would be remiss of us not to mention them.

Reserve funds are held in segregated accounts by qualified custodians. Issuance is performed by a special-purpose vehicle or licensed entity, with mint and burn rules enforced by contract. User claims are cryptographically tied to their RGB wallet signatures and redemption proofs.

We have also sketched — though not yet implemented — a zero-knowledge withdrawal ticketing scheme that would allow users to anonymise their redemption whilst preserving traceability under lawful request, for instance through viewing keys disclosed to regulators. This is a delicate business, and we are acutely aware that getting the privacy-compliance balance wrong in either direction would be consequential.

8. Open Questions and Future Work

We wish to be explicit about what this design does not yet address.

First, Lightning Network integration via RGB-over-Lightning for near-instant payments is an attractive prospect, but the relevant specifications are still maturing. We prefer not to make promises that depend on unfinished protocol work.

Second, cross-chain anchoring — for instance, minting on Ethereum or Solana backed by the same reserve proofs — is conceptually straightforward but introduces additional trust surfaces that we have not yet analysed carefully.

Third, and most fundamentally, the gap between “a hash was committed on-chain” and “the reserves genuinely exist” remains the hardest problem. We are actively investigating third-party oracle designs and hardware-based attestation as potential mitigations, but we do not yet have a solution we are confident in.

Concluding Remarks

What we have presented here is a working architecture, not a finished product. The combination of RGB’s client-side validation with Taproot-anchored reserve proofs offers, we believe, a promising path towards a stablecoin that respects user privacy without sacrificing auditability. But promising is not the same as proven, and there is a great deal of engineering and cryptographic work still to be done before this design can be considered production-ready.

We share these notes in the spirit of open inquiry, and we would be grateful for criticism — particularly from those better versed in the regulatory and operational realities than we are.