Foreword

RGBX unifies your Bitcoin-anchored RGB assets with a high-throughput Tondi execution plane. It is mode-selectable per asset, giving you precise control over cost, latency, security, and auditability:

• tondi-only — pure Tondi execution (no Bitcoin anchoring)

• tondi-led — execute on Tondi, periodically anchor to Bitcoin

• btc-led — every transition anchored on Bitcoin

• btc-only — classic RGB on Bitcoin (no Tondi)

The same asset can switch modes under governance or policy (risk, fee, value, trust). All modes share one set of identifiers, receipt/commitment formats, and client-validation logic.

---

1) Design Goals & Non-Goals

Goals

• Preserve RGB client-validation and the single-use seal ownership model.

• Offer programmable, high-throughput execution via Tondi with Bitcoin as an optional, public, offline-verifiable settlement anchor.

• Make cross-chain verification pluggable (SPV, light client, optimistic, committee).

• Support untrusted redemption (exit by spending the bound Bitcoin UTXO) and offline counterparty verification (SPV + minimal state proofs).

• Enable policy-driven mode selection per asset and per transfer.

Non-Goals

• No trusted custodial bridge is required or assumed.

• No global indexer trust assumption (indexers/relayers are replaceable accelerators; wallets remain the root of validation).

---

2) System Components

2.1 BindingController (on Tondi)

Smart contract/program that enforces the 1:1 binding between a Bitcoin UTXO (btc_prevout) and a Tondi container (container_id). It:

• records bindings and the latest finalized container state root,

• verifies cross-chain proofs through a ProofAdapter,

• enforces single-use seal semantics (each btc_prevout advances at most once),

• handles batch finalization (tondi-led) and per-step finalization (btc-led),

• provides reorg rollback to the last confirmed Bitcoin anchor.

Disabled in btc-only; reduced to a pure container state machine in tondi-only.

2.2 ProofAdapter (pluggable verification)

Uniform interface that validates “Bitcoin facts” presented to Tondi. Multiple implementations can co-exist:

• Offchain-SPV (wallet verifies; chain logs events only)

• LightClient (NiPoPoW/FlyClient-style header verification on Tondi)

• Optimistic (claims with challenge window + fraud proofs)

• Committee (threshold signatures, enterprise/allow-listed scenarios)

2.3 Observer / Committer

Off-chain services (commodity, replaceable):

• Observer: watches Bitcoin & Tondi; extracts headers, Merkle paths, commitment payloads; prepares ProofEnvelopes.

• Committer:

  • tondi-led: aggregates state roots and submits periodic Bitcoin commitments;

  • btc-led: optionally assists wallets in constructing P2TR transactions with RGBX payloads.
    Both can sit behind privacy tooling (MuSig2, CoinJoin, “Shadow Vault” routing) when batching outputs.

2.4 Policy Engine (on-chain + SDK)

A per-asset policy that declares the current mode, thresholds (value/fee/trust), adapter preference, batch windows, and cooldowns. Wallet SDK consults policy to decide the path for each transfer.

2.5 Wallet SDK (dual-view)

Tracks Bitcoin ownership (UTXO + commitments) and Tondi container state. It:

• distinguishes Finalized vs Pending balances,

• exports/imports receipts (Bitcoin SPV + minimal state proof),

• performs client-validation end-to-end.

---

3) Data Model

3.1 Identifiers

• asset_id — matches existing RGB definition (32-byte hash).

• container_id — H("RGBX" || creator_pubkey || salt); domain-separated, collision-resistant.

• btc_prevout — txid(32) || vout(4): the bound single-use seal currently carrying ownership.

3.2 Bitcoin Commitment (RGBXv1)

Taproot leaf TLV payload (recommend starting with a TapLeaf; TapTweak optional later):

• 0x01 asset_id (32B)

• 0x02 container_id (32B)

• 0x03 state_root_next (32B) — post-transition root (or batch aggregate)

• 0x04 tondi_txid (32B) — optional, recommended for btc-led

• 0x05 meta_hash (32B) — optional batch/epoch/snapshot descriptor

This payload is the public receipt anyone can parse from a confirmed Bitcoin transaction.

3.3 Container State (on Tondi)

• state_root — minimal verifiable state (Merkle/SSZ root).

• event — {prev_root, next_root, inputs[], outputs[], constraints, mode_flag, epoch}.

• Events carry the minimum material for client-side recomputation (avoid duplicating derivable data on Bitcoin).

---

4) Modes

4.1 tondi-only — Pure Tondi Execution

Purpose: low-fee, high-TPS domains (gaming, micro-payments, loyalty).
Process: create/transfer purely on Tondi; no binding nor Bitcoin anchor.
Optional: RGBX-snapshot — periodic read-only Bitcoin anchors of aggregate roots (not single-use sealed).
Trust model: participants accept Tondi consensus + client validation.
Pros: simplest, cheapest, fastest.
Cons: no untrusted redemption; limited offline verification to Tondi tooling.

---

4.2 tondi-led — Execute on Tondi, Periodically Anchor to Bitcoin

Purpose: high interaction while preserving public auditability.
Process:

1. Many Tondi transitions → Pending roots in BindingController.

2. At epoch (time/size/fee-aware), Committer writes aggregate root to Bitcoin using RGBXv1.

3. A ProofAdapter verifies the anchor; BindingController finalizes the epoch; balances move from Pending to Finalized.

Policy knobs:

• epoch_blocks / max_delay (e.g., 30–120 Tondi blocks or 3–30 min),

• min_batch,

• minConf for Bitcoin anchors,

• adapter priority: Optimistic → LightClient for high-value batches.

Pros: amortized fees, public audit points, scalable.
Cons: finality arrives per batch; offline verification of finalized steps only.

---

4.3 btc-led — Every Transition Anchored on Bitcoin

Purpose: institutional settlement, redemptions, cross-domain exits, high-value transfers.
Process:

1. Compute state_root_next on Tondi (or deterministically off-chain).

2. Construct and broadcast a Bitcoin P2TR with RGBXv1 payload.

3. Provide proof to BindingController → advanceWithBtc() updates state_root_prev and chains btc_prevout to the newly created output.

Policy knobs:

• minConf = 6–12 (or more),

• adapter priority: LightClient first; Optimistic with longer challenge windows as a fallback.

Pros: untrusted redemption, offline verification per step, strongest auditability.
Cons: latency/fees ≈ Bitcoin.

---

4.4 btc-only — Classic RGB on Bitcoin

Purpose: ultra-conservative deployments; no Tondi features required.
Process: standard RGB client-validation on Bitcoin; no BindingController.
Pros: minimum assumptions beyond Bitcoin.
Cons: limited programmability and throughput.

---

5) Binding & State Machines

Binding {
  bytes32 asset_id;
  bytes32 container_id;
  bytes36 btc_prevout;      // empty in tondi-only
  bytes32 state_root_prev;
  uint8   mode;             // 0: tondi-only, 1: tondi-led, 2: btc-led, 3: btc-only
  uint64  epoch;            // tondi-led batch window counter
  bool    finalized;        // whether initial bind is complete
}

5.1 Initialization (initBind)

Applies to: tondi-led, btc-led.
Requirement: a Bitcoin transaction with an RGBXv1 binding payload proving asset_id ↔ container_id on a specific btc_prevout.
Effect: records btc_prevout, sets state_root_prev (initial), finalized = true.
Security: only the owner of the Bitcoin UTXO can produce this payload; prevents forged bindings.

5.2 Per-step Advance (btc-led): advanceWithBtc(proofEnvelope)

• Verifies, via ProofAdapter, that the last recorded btc_prevout was spent or committed with a matching state_root_next.

• Enforces single-use seal: the same btc_prevout cannot advance twice.

• Updates state_root_prev and re-binds to the new btc_prevout from that transaction.

5.3 Tondi Internal Advance (tondi-led): advanceOnTondi(tentative_root)

• Queues tentative_root as Pending for the current epoch (no Bitcoin requirement yet).

5.4 Batch Finalization (tondi-led): finalizeEpoch(proofEnvelope)

• Verifies that the aggregate root of the epoch was written to Bitcoin.

• Promotes all queued Pending transitions in that epoch to Finalized.

• Increments epoch, clears queues.

Reorg policy (all modes)
Only accept anchors with height ≥ minConf. On Bitcoin reorg, rollback to the prior confirmed anchor; Pending remains pending until a new anchor is confirmed.

---

6) Cross-Chain Verification

6.1 Adapter Interface (EVM-style; AluVM analogues identical)

interface IProofAdapter {
  function meta() external view returns (bytes32 chainId, uint16 version);

  function verify(bytes calldata proofEnvelope)
    external view
    returns (
      bytes32 btcTxId,
      uint256 btcHeight,
      bytes32 parsedStateRootNext,
      bytes32 parsedContainerId,
      bytes32 parsedAssetId
    );

  function proveFraud(bytes calldata fraudProof) external; // Optimistic only
}

6.2 Adapter Types (when to use)

• Offchain-SPV: fastest time-to-market; wallet validates headers/Merkle; chain records events. (tondi-only / early tondi-led MVP)

• LightClient: sub-linear header verification on Tondi; strongest minimization of trust. (btc-led, high-value tondi-led batches)

• Optimistic: low on-chain footprint; challenge window and slashing bond. (retail tondi-led; btc-led fallback under congestion)

• Committee: threshold signatures for enterprise or allow-listed interop. (private/consortium)

6.3 ProofEnvelope (CBOR/TLV sketch)

ProofEnvelope {
  u16  type;      // 0: OffchainRef, 1: LightClient, 2: Optimistic, 3: Committee
  u16  version;
  u8   k_conf;    // required Bitcoin confirmations
  b32  asset_id;
  b32  container_id;

  // LightClient:
  bytes headers_subset;        // sampled headers or MMR proof
  bytes header_membership;     // MMR path / FlyClient sample proof
  bytes tx_merkle_path;
  bytes rgbx_leaf_payload;

  // Optimistic:
  b32   claim_id;
  bytes rgbx_leaf_payload;     // claim subject; fraud proofs submitted separately

  // Committee:
  b32   digest;                // H(block_hash || txid || payload_hash)
  bytes threshold_signature;   // MuSig2/FROST/BLS, etc.
}

---

7) Security Properties

• Anti-forgery: Initial bind must be proven from a Bitcoin tx under the spender’s control; container_id is domain-separated; both sides must match.

• Single-Use Seal: Every advance proves the same prior btc_prevout; replay rejected.

• Anti-replay: (btcTxId, btcHeight, payload_hash) recorded; duplicates rejected.

• Censorship & Liveness:

  • tondi-led: liveness depends on Tondi; settlement depends on periodic Bitcoin inclusion.

  • btc-led: liveness depends on Bitcoin inclusion; use RBF/CPFP policies under fee spikes.

• Reorg Handling: Accept anchors only after minConf; maintain a rollback pointer to last stable height.

---

8) Redemption & Offline Verification

• Untrusted Redemption (btc-led): the owner spends the bound Bitcoin UTXO with an RGBXv1 payload embedding the redemption/settlement root; this alone establishes exit/settlement without trusting any bridge. Tondi follows upon proof; Bitcoin is the source of truth.

• Offline Counterparty Verification: share a receipt consisting of:

  1. Bitcoin headers subset + tx Merkle path + RGBXv1 payload,

  2. minimal container state proof (events + Merkle proofs) to recompute state_root_next.

The verifier checks inclusion and recomputes the root offline (SPV); if confirmed (≥ minConf), the transfer is accepted as final.

---

9) Policy-Driven Mode Switching

struct Policy {
  uint8   mode;               // 0 tondi-only, 1 tondi-led, 2 btc-led, 3 btc-only
  uint8   minConf;            // Bitcoin confirmations
  uint32  epochBlocks;        // tondi-led batch window
  uint16  minBatch;           // tondi-led min batch size
  uint32  coolDown;           // seconds to prevent mode flapping
  uint128 valueThreshold;     // >V => prefer btc-led
  uint16  feeHigh;            // sat/vB above F => increase batch size / delay
  uint16  feeLow;             // sat/vB below f => reduce batch, allow btc-led
  uint16  trustCutoff;        // counterparty trust < τ => btc-led
  address[] allowedAdapters;  // permitted ProofAdapters
  uint8   adapterPriority;    // bitset or enum ordering
}

Hysteresis & Cooldown: apply different up/down thresholds and a cooldown (coolDown) to avoid rapid toggling.

Examples

• Retail: default tondi-led (epochBlocks=60, minBatch=50), valueThreshold=$3k, adapter Optimistic→LightClient.

• Institutional: btc-led, minConf=12, adapter LightClient; tondi-led allowed only for internal micro-flows with daily anchor.

---

10) Privacy & Fee Efficiency

• Batch commitments traverse a privacy aggregator (MuSig2, CoinJoin, Shadow-Vault-style output splitting) prior to Bitcoin anchoring.

• Batch sizing heuristics: target tx weight (vB) × fee rate (sat/vB) ≤ budget; maintain minBatch to amortize base overhead; expand/retract windows on fee volatility.

---

11) Compliance & Audit

• Audit snapshots: for tondi-led and tondi-only, periodically anchor read-only snapshots (RGBX-snapshot) on Bitcoin to provide public audit points (even without single-use seal semantics).

• Evidence retention: BindingController events (initBind, AdvancedByBtc, Pending, FinalizedEpoch), Bitcoin anchors (txids/heights), and policy-change events form a complete audit trail.

---

12) Testing & SRE Checklist

Correctness

• Single-use seal enforcement; prevout chaining; duplicate/replay rejection.

• Batch aggregation correctness (root recomputation matches on both sides).

• Mode transitions without balance inconsistencies.

Adversarial

• Bitcoin & Tondi reorg simulations (deep & shallow).

• Faulty proofs (bad Merkle, wrong payload), delayed/withheld proofs.

• Optimistic fraud proofs and slashing.

• Fee-spike scenarios with RBF/CPFP strategies.

Performance

• tondi-led at ≥1k TPS: batch latency & fee amortization curves.

• Wallet receipt export/import round-trip under cold-start SPV.

Observability

• Metrics: epoch delay, proof acceptance rate, adapter verification time, mode switches, fee regime triggers.

• Alerts: anchor stuck > S minutes, fraud-proof triggered, reorg rollback executed.

---

13) Repository Layout

rgbx/
 ├─ specs/
 │   └─ rgbxv1.md                 # Commitment, identifiers, Policy spec
 ├─ binding/
 │   ├─ controller/               # BindingController (AluVM / EVM)
 │   └─ adapters/                 # IProofAdapter: offchain, lightclient, optimistic, committee
 ├─ relayer/
 │   ├─ observer/
 │   └─ committer/
 ├─ wallet/
 │   └─ sdk/                      # Dual-view, receipts, client-validation
 └─ ops/
     ├─ docker/                   # bitcoind, tondi, observer, committer
     └─ dashboards/               # Grafana: epochs, fees, adapter health

---

14) Deployment Runbook (minimum viable path)

1. Freeze rgbxv1: TLV fields + domain-separated container_id.

2. btc-only / tondi-only: keep existing stacks; add container_id discipline.

3. Enable tondi-led: deploy BindingController + Observer/Committer; daily anchor → iterate to hourly/fee-aware.

4. Add btc-led for high-value/redemption: wallet flow for P2TR with RGBXv1 payload; ProofAdapter = LightClient (fallback Optimistic).

5. Turn on policy engine: thresholds V/F/τ + cooldown; wallet shows per-tx mode and balance tiers (Finalized vs Pending).

6. Privacy & fee: wire aggregator; tune batch sizing under live fee markets.

---

15) Quick Mode Comparison

---

One-liner Summary

RGBX decouples execution speed (Tondi) from public finality (Bitcoin) and lets you choose—per asset and per transfer—between tondi-only, tondi-led, btc-led, and btc-only, all on a single, consistent client-validation and proof stack.