Purpose and Scope
This document specifies The ₿ridge Network, the federated Bitcoin sidechain on which ₿USD, ₿OND, and ₿ILL circulate. It covers the sidechain layer only: consensus, block production, transaction format, payment finality, peg mechanics, multi-product support, privacy architecture, federation governance, and the IDMA monitoring interface.
₿ridge handles commerce. Between the moment a ₿USD is minted and the moment it's redeemed, every transfer, every payment, every salary deposit, every merchant settlement occurs on this network. No Bitcoin moves on the base layer during these transactions. The BTC reserves sit untouched in publicly addressable wallets until a holder crosses the boundary by minting new ₿USD or redeeming existing ones.
This specification does not cover the reserve architecture (the two-ledger system), redemption economics (surplus dynamics, the Profit Burn Priority algorithm), the defensive programmability toolkit (fee schedules, velocity limits, volume-triggered escalation), the BTCADP oracle methodology, or the ₿C denomination protocol. Where this specification references reserve mechanics or defensive parameters, it cites TBB and defers to it.
The intended audience is sidechain engineers, node operators, wallet developers, and anyone evaluating the technical feasibility of ₿ridge. The document defines what's fixed, what's parameterized, and what's open for research and calibration.
₿ridge is built on a fork of Elements, Blockstream's open-source extension of Bitcoin's codebase. Elements is the foundation of the Liquid Network and provides the UTXO transaction model, Confidential Transactions, issued asset support, and federation signing that ₿ridge requires. This specification defines where the consortium's implementation follows Elements and where it departs.
The Consortium Advantage
A sidechain is only as trustworthy as the entities operating it. On the Liquid Network, the functionaries who sign blocks and manage the peg have no economic relationship to the assets circulating on the chain. They don't issue the currency, don't hold the reserves, and don't profit from the system's success. If Liquid's assets lost all their value tomorrow, the functionaries would lose nothing beyond minor fee revenue.
₿ridge is different because the federation members are the consortium's treasury companies. They issue the currency, hold the Bitcoin reserves in publicly addressable wallets, and stake their balance sheets on the system's integrity. The International Digital Monetary Authority sits above the federation as an independent certifier and real-time monitor with no economic stake in any member's success, only in the network's soundness.
Every technical advantage below flows from this alignment.
1. No peg-in delay
Liquid requires 102 Bitcoin confirmations (roughly 17 hours) for peg-in because the federation doesn't trust the depositing user. The consortium has no such problem. When a treasury company mints ₿USD, it has already purchased the BTC and can confirm base-layer settlement internally. Issuance is authorized by the treasury company's own attestation, verified by IDMA's monitoring against the base-layer deposit. New ₿USD can appear on the sidechain within minutes of the BTC purchase settling, not hours.
2. Sub-second payment confirmation at point of sale
Block production requires a 2/3 supermajority of federation signers. No single member can double-spend, reverse transactions, or forge blocks. The risks from a rogue member are different in kind: minting without backing, draining reserves, or manipulating block production during their proposal round. IDMA's real-time monitoring addresses each of these (see Section 08: Threat Model). For the merchant at the register, the practical result is that a broadcast ₿USD payment is effectively final on receipt. Signed pre-confirmations from the current block proposer give the merchant a cryptographic receipt within a second or two. The block time becomes a bookkeeping interval, not a settlement gate.
3. Faster block times
Liquid produces blocks every two minutes. Because there's no proof-of-work on ₿ridge, the federation can produce blocks as fast as the network can propagate and sign them. With a professional federation of 10-20 members running institutional-grade infrastructure, a target block time of 30 seconds is realistic. Faster blocks reduce the gap between broadcast and on-chain inclusion, improving the experience for every transaction type.
4. Consortium controls its own membership
On Liquid, Blockstream determines the functionary set. On ₿ridge, the consortium defines its own admission criteria, threshold requirements, and removal process under the charter. IDMA certifies that the governance process is fair and that new members meet published compliance standards. No external party can add a hostile node or remove a member without the consortium's governance process authorizing it.
5. Consortium controls its own upgrade schedule
Deploying on Liquid means waiting for Blockstream to ship features. On ₿ridge, consortium members propose upgrades, IDMA certifies them before deployment, and the federation deploys on its own timeline. If the defensive programmability framework needs custom script extensions or new opcodes, the consortium can build and deploy them without depending on a third party's roadmap.
6. Consortium controls fee structures
Commerce-layer transaction fees, redemption fee enforcement, volume-triggered escalation: all of these are governed by the consortium under IDMA's published framework. On Liquid, the fee structure is whatever Blockstream's protocol defines. On ₿ridge, fee parameters are tuned to serve the system's monetary policy goals, calibrated through the high-friction governance process described in the IDMA charter.
7. Custom extensions for defensive programmability
The fee calculations based on UTXO age, network state awareness, velocity limits, and volume-triggered escalation may require script extensions or application-layer integrations that Liquid doesn't support. ₿ridge can add these capabilities at the protocol level. The entities engineering the protocol are the same entities whose reserves the defensive toolkit protects. Their incentive to get it right is direct and financial.
8. IDMA monitoring built in from day one
₿ridge is designed with IDMA's oversight role as a first-class requirement. Viewing keys for Confidential Transaction audit access, a dedicated monitoring API exposing mint volumes, burn activity, fee distribution, transaction ordering patterns, and velocity metrics. On Liquid, this kind of access would need to be negotiated with Blockstream. On ₿ridge, it's part of the architecture from launch.
9. Peg mechanics are internal operations
Liquid's peg-in is user-facing: anyone can lock BTC and receive L-BTC. ₿ridge's mint process is a consortium operation. End users never interact with a peg. They acquire ₿USD through a financial service provider (an exchange, a wallet app, a payment platform), and the treasury company handles the base-layer BTC purchase and sidechain issuance behind the scenes. Redemption works the same way in reverse. The peg is consortium infrastructure, not a public bridge with a 17-hour toll booth.
10. Settlement finality with no chargebacks
UTXO transactions on ₿ridge are irreversible at the protocol level. When a sender's outputs are consumed and new $1 outputs are created for the recipient, the protocol has no mechanism to reverse the transfer. Merchants receive real ₿USD that no entity can claw back. Refunds are forward transactions, new payments from the merchant to the customer with fresh timestamps and fresh UTXOs. Consumer protection and dispute resolution live at the FSP layer, not in the protocol. The roughly $100 billion in annual global chargeback costs that merchants absorb today has no equivalent on ₿ridge.
11. Multi-product separation enforced at the protocol level
₿USD, ₿OND, and ₿ILL circulate as distinct issued assets on the same chain. The protocol prevents cross-asset confusion. A user can't accidentally spend ₿OND as ₿USD any more than they could spend L-USDT as L-BTC on Liquid. Reserve contamination between products is impossible at the sidechain level, reinforcing the firewall architecture described in TBB.
12. Privacy architecture purpose-built
Confidential Transactions hide amounts and asset types from outside observers. The UTXO model means there are no persistent account balances visible on-chain. IDMA receives viewing keys for aggregate monitoring. Financial service providers handle identity requirements at the application layer, within their own regulatory frameworks. The protocol is structurally incapable of the surveillance that CBDC architectures enable. The data doesn't exist on-chain because the chain was designed not to collect it.
₿ridge is not a neutral piece of infrastructure adopted from an external provider. It is purpose-built monetary infrastructure operated by the entities whose reserves back the currency, certified by an independent authority whose only mandate is the network's integrity.
Architecture Overview
The ₿USD system is composed of four layers. Each performs a single function, and the failure of any one layer doesn't compromise the others.
| Layer | Function | Network | Verification |
|---|---|---|---|
| Reference Price | BTCADP daily price; ₿C cumulative average | Off-chain (open standard) | Any party with trade data |
| Reserve Layer | BTC custody in two-ledger system | Bitcoin blockchain | On-chain wallet addresses |
| Note Layer | Consortium's Digital Reserve Note inventory (provenance metadata, PBP# burn ordering) | Consortium internal systems | IDMA audit + base-layer cross-reference |
| Transaction Layer | ₿USD / ₿OND / ₿ILL circulation as $1 UTXOs | ₿ridge | Sidechain explorer + IDMA monitoring |
| Interface Layer | Consumer wallets, merchant terminals, FSP apps | Application layer | User experience |
The Reserve Layer holds the BTC. The Note Layer is the consortium's vault: individual Digital Reserve Notes with provenance metadata, managed internally, never visible to holders. A Digital Reserve Note is the digital equivalent of a banknote stored in a bank vault. Each one carries data about itself (mint date, cost basis, ₿C price, block age), and the consortium uses that data for reserve management and PBP# burn ordering. The holder never sees a reserve note, just as a depositor never sees the specific bills backing their balance. The Transaction Layer is where commerce happens: $1 UTXOs circulating on ₿ridge, representing the holder's redemption claims against the reserve. The relationship between a holder's balance on the Transaction Layer and the reserve notes in the Note Layer is the relationship between a deposit balance and the bills in a bank vault. The depositor owns the claim. The bank owns the bills. The bank decides which bills to hand over on withdrawal.
This specification covers the Transaction Layer. ₿ridge sits between the Reserve Layer (BTC in wallets on Bitcoin's blockchain) and the Interface Layer (the wallets and apps end users interact with). It connects to the Reserve Layer at exactly two points: minting and redemption. Everything between those two events is sidechain commerce, and no Bitcoin moves in the reserve during that commerce.
A consumer paying for coffee interacts with the Interface Layer (their wallet). The wallet constructs a transaction on ₿ridge. The Reserve Layer is untouched. The Note Layer is untouched. A million transactions can flow across ₿ridge without a single satoshi moving in the reserve. The reserve secures the backing. ₿ridge handles commerce.
Relationship to the Reserve Layer and Note Layer
₿ridge does not reference the reserve inventory. The reserve does not track sidechain balances. The Note Layer (the consortium's internal record of which reserve notes exist, their provenance, their cost basis) is completely separate from the Transaction Layer (the $1 UTXOs holders spend and receive). On the Note Layer, each reserve note carries provenance metadata: mint date, mint-day BTC spot price, mint-day ₿C price, and block age. The consortium uses this data for reserve management and Profit Burn Priority burn ordering. On the Transaction Layer, each ₿USD is a $1 UTXO with a transaction ID and timestamp. The fee algorithm reads UTXO age to price redemptions. No layer references any other.
Relationship to the Interface Layer
End users never interact with ₿ridge directly. They interact with financial service providers: wallet apps, exchanges, payment platforms, merchant terminals. The FSP constructs, signs, and broadcasts sidechain transactions on the user's behalf. The user sees a balance, taps "pay," and receives confirmation. The complexity of UTXO management, Confidential Transaction blinding, and fee calculation is handled by the FSP's software. From the user's perspective, ₿USD works like any other digital payment.
Section 04Consensus Model
₿ridge uses a federated consensus model inherited from Elements. There is no proof-of-work and no mining. Block production is performed by the consortium's member companies, each running a federation node called a functionary. The functionaries take turns proposing blocks in a round-robin rotation, and a supermajority must sign each block before it's accepted by the network.
4.1 Federation Signing
Each consortium member operates one functionary node. The node holds a signing key used to participate in block production. When a block is proposed, it must receive signatures from at least 2/3 of the federation (rounded up) before the network treats it as valid. With a 15-member federation, that means 10 signatures per block. With 10 members, 7 signatures.
The signing process uses a threshold signature scheme. The block proposer assembles pending transactions into a candidate block, signs it, and distributes it to the other functionaries. Each functionary validates the block (checks that all transactions are well-formed, that no UTXOs are double-spent, that issued assets come from authorized issuers) and, if valid, adds its signature. Once the threshold is met, the block is finalized and appended to the chain.
4.2 Block Production Rotation
The right to propose a block rotates through the federation in a deterministic sequence. Each functionary gets a time slot during which it's the designated proposer. If the current proposer fails to produce a block within its slot (due to downtime, network partition, or malfunction), the next functionary in the rotation takes over after a defined timeout. This means a single member's downtime causes a one-slot delay, not a chain halt.
4.3 Fault Tolerance
The 2/3 threshold determines the network's tolerance for offline or compromised members. In a 15-member federation, up to 5 members can be simultaneously offline without interrupting block production. In a 10-member federation, up to 3. If more than 1/3 of the federation goes offline, block production stalls until enough members come back online. The chain doesn't fork or lose data during a stall. It simply pauses and resumes where it left off.
This is a meaningful difference from proof-of-work chains, where a loss of hash rate makes the chain slower but never stops it entirely. On ₿ridge, the tradeoff is explicit: faster finality and deterministic block times in exchange for a liveness dependency on the federation's availability. For a federation of 10-20 publicly traded companies running institutional-grade infrastructure with redundant deployments, sustained unavailability of more than 1/3 of the membership is an extreme scenario.
4.4 The Trust Model
The trust assumption should be stated plainly. Anyone using ₿ridge is trusting that 2/3 of the federation will not collude to forge blocks, censor transactions, or steal pegged funds. The federation members are publicly traded Bitcoin treasury companies with known identities, regulatory obligations, public financial statements, and billions of dollars in Bitcoin on their balance sheets. Their incentive to protect the network is direct: the reserves backing ₿USD are their own Bitcoin. Fraud would destroy the value of their own holdings alongside the network's credibility.
IDMA adds an independent monitoring layer on top of this incentive alignment. Even if the trust assumption is sound, verification is better than trust. IDMA's real-time monitoring (Section 13) catches anomalies that incentive alignment alone might not prevent.
Section 05Block Parameters
5.1 Block Time
The target block time is 30 seconds. Liquid uses 120 seconds. ₿ridge can produce blocks faster because the federation is smaller (10-20 members vs. Liquid's ~60 functionaries) and runs on dedicated, professional infrastructure. Shorter block times reduce the interval between transaction broadcast and on-chain inclusion, which improves the experience for every transaction type.
With zero-confirmation acceptance (Section 07), the block time is less important for point-of-sale speed than it might appear. The merchant receives effective finality within seconds of broadcast, regardless of when the next block lands. The 30-second block time matters more for chain state updates: how quickly aggregate metrics (total supply, redemption velocity) refresh, and how soon IDMA's monitoring reflects new activity.
Block time is a tunable parameter. The consortium can adjust it through the governance process described in Section 16 if empirical data suggests a different interval performs better. The open questions section flags block time optimization as a research priority.
5.2 Block Size and Throughput
Elements inherits Bitcoin's transaction format with extensions for Confidential Transactions and issued assets. CT transactions are larger than standard Bitcoin transactions because they include range proofs that verify amounts are valid without revealing them. A typical ₿USD payment (one CT input, two CT outputs including change) is roughly 2-3 KB.
₿ridge targets a block weight limit sufficient to handle sustained commercial throughput without congestion. The initial parameter is set at 4 MB block weight (matching Liquid's current limit), which supports approximately 1,300-2,000 CT transactions per block. At 30-second block times, that's roughly 2,600-4,000 transactions per minute, or 150,000-240,000 transactions per hour.
For context: Visa processes roughly 65,000 transactions per minute at peak. ₿ridge's initial throughput target is below this, but ₿ridge won't be processing global Visa-scale volume at launch. The block weight limit is a parameter that can be increased as the federation's infrastructure matures and as demand grows.
5.3 Chain Growth
At 4 MB maximum block weight and 30-second block times, the theoretical maximum chain growth is approximately 11.5 GB per day (4 MB x 2 blocks/minute x 1,440 minutes/day). In practice, blocks won't be consistently full at launch. A more realistic early estimate is 1-2 GB per day, growing with adoption. Federation members must provision storage accordingly, with pruning strategies and archival nodes defined in the federation's operational requirements.
Section 06Transaction Model
6.1 UTXO Structure
Every ₿USD on ₿ridge is a discrete $1 Unspent Transaction Output (UTXO). Each UTXO carries a transaction ID (a unique cryptographic hash identifying the transaction that created it) and a timestamp (assigned when the UTXO is created, derived from the block time of the block that includes the transaction).
When a user pays a merchant, the transaction consumes one or more of the sender's existing UTXOs and creates new UTXOs for the recipient. If the payment amount doesn't exactly match the consumed inputs, a change output is created and returned to the sender. All new UTXOs carry fresh timestamps. The sender's consumed UTXOs are marked as spent and can never be used again.
A holder with a $50 ₿USD balance actually holds 50 individual $1 UTXOs. Their wallet software aggregates these into a single displayed balance. The holder never sees, selects, or manages individual UTXOs. When they send $12, their wallet selects 12 UTXOs to consume and creates 12 new $1 UTXOs for the recipient.
6.2 Timestamp Assignment and Holding Period
The timestamp on each UTXO records when it was created. For freshly minted ₿USD, that's the moment of issuance. For ₿USD received in a transfer, it's the time of the transfer. Every transfer resets the holding period because every transfer creates new UTXOs.
This has a specific implication for refunds. When a merchant refunds a customer, the customer receives new UTXOs with fresh timestamps. The refunded ₿USD is "young" again for redemption fee purposes, because the refund is economically a new acquisition of ₿USD by the customer. The original holding period doesn't carry over. This is inherent to the UTXO model, not an additional rule.
The redemption fee algorithm (defined in TBB) reads these timestamps to determine the holding period for each ₿USD being redeemed. Longer holding periods mean lower fees. The sidechain provides the timestamp data. The fee calculation logic lives in the application layer or in script extensions (see Section 18: Open Questions).
6.3 Confidential Transactions
₿ridge implements Confidential Transactions (CT) inherited from Elements. CT uses cryptographic commitments to hide two pieces of information from outside observers: the transaction amount and the asset type. A third party scanning ₿ridge blockchain can see that a transaction occurred between two addresses, but can't determine how much moved or whether it was ₿USD, ₿OND, or ₿ILL.
The sender and recipient can see the full transaction details. Their wallets hold the blinding factors needed to decrypt the committed values. Any third party who needs to verify a specific transaction (for audit, compliance, or dispute resolution) can be given a transaction proof, a cryptographic object that lets them verify the amount and asset type of that specific transaction without revealing any other transaction's details.
CT includes range proofs that mathematically guarantee each committed amount is positive and within a valid range, preventing an attacker from creating negative-value outputs that would inflate the total supply. The range proofs are verified by every functionary during block validation.
6.4 Viewing Keys
CT supports the creation of viewing keys: cryptographic keys that allow a designated party to unblind transaction amounts without being able to spend funds. IDMA receives a master viewing key that gives it read access to all transaction amounts and asset types on ₿ridge. This is the mechanism that enables IDMA's real-time monitoring (Section 13) without requiring IDMA to hold any spending authority.
Consortium members may also issue viewing keys to external auditors, regulators, or other parties as required by their local regulatory frameworks. The viewing key architecture means transparency is granular: each party sees only what they've been authorized to see, and no party needs spending capability to perform oversight.
6.5 Script Capabilities
Elements extends Bitcoin Script with additional opcodes. ₿ridge inherits these extensions, which support multisignature outputs, timelocks (both absolute and relative), hash locks, and basic covenant-style logic. These are sufficient for standard ₿USD transactions: simple payments, multi-party escrow, and time-locked outputs.
The open question is whether the defensive programmability features (fee calculations based on UTXO age, network state awareness, volume-triggered escalation) can be implemented within the existing script environment or require custom extensions. UTXO-age-based fee calculation is likely feasible using relative timelocks already available in Elements Script. Aggregate network metrics (rolling redemption velocity as a percentage of supply) probably require either new opcodes or an application-layer oracle that feeds this data into the transaction validation process. Section 18 flags this as a priority for implementation research.
Section 07Payment Finality and Point of Sale
The target for merchant payment confirmation is under 2 seconds from the moment the buyer initiates payment to the moment the merchant's terminal shows "paid." Three mechanisms work together to achieve this.
7.1 Zero-Confirmation Acceptance
On proof-of-work chains, accepting a transaction before it's included in a block carries real risk. A miner could include a conflicting transaction in a competing block, reversing the payment. On ₿ridge, this risk is structurally eliminated. There are no competing miners, no chain forks, and no reorganizations under normal operation. The federation produces one chain with one tip. Once a transaction is broadcast and accepted into the mempool by the federation's nodes, it will be included in the next block. The only way to prevent inclusion is for the current block proposer to deliberately exclude it, which buys one block of delay (30 seconds) before the next proposer includes it.
A merchant accepting a zero-conf ₿USD payment on ₿ridge is in a fundamentally different position than a merchant accepting a zero-conf Bitcoin payment on the base layer. The federation's deterministic block production makes double-spending infeasible without federation collusion, which IDMA's monitoring would detect.
7.2 Signed Pre-Confirmations
For additional assurance, the current block proposer can issue a signed pre-confirmation: a cryptographic receipt acknowledging that the transaction has been accepted and will be included in the next block. The merchant's terminal receives this receipt within a second or two of broadcast. If the block proposer signs a pre-confirmation and then fails to include the transaction, the violation is provable. IDMA can act on it, and the proposer's reputation and standing in the consortium are at risk.
Signed pre-confirmations are optional. A merchant who trusts zero-conf (reasonable given the security model) doesn't need them. A merchant handling high-value transactions may prefer the additional cryptographic guarantee. The protocol supports both modes.
7.3 The Merchant Experience
At the register, the flow looks like this:
The merchant's terminal displays a payment request (a QR code, an NFC tag, or a push notification to the buyer's wallet). The buyer's wallet constructs a ₿USD transaction consuming the appropriate UTXOs, signs it, and broadcasts it to ₿ridge. The federation nodes receive the transaction, validate it, and propagate it. The merchant's terminal, connected to a ₿ridge node (directly or through an FSP), sees the validated transaction appear in the mempool. If signed pre-confirmations are enabled, the current block proposer's receipt arrives within a second or two. The terminal displays "paid."
The buyer's experience is indistinguishable from tapping a card. The merchant's experience is indistinguishable from receiving a card authorization, except there's no processor fee of 2-3%, no chargeback risk, and no settlement delay of 1-3 business days. The merchant has the money, confirmed by the federation, in under two seconds. Final settlement (block inclusion) follows within 30 seconds. The funds are available immediately.
Card networks show "approved" at the terminal in 1-2 seconds, but actual settlement between banks takes 1-3 business days. ₿ridge shows "paid" in 1-2 seconds, and the merchant has the actual ₿USD in their wallet within 30 seconds. Faster confirmation and faster settlement.
Threat Model
₿ridge's security rests on two foundations: the 2/3 threshold requirement for block production and IDMA's real-time monitoring of every operation on the network. The threshold prevents unilateral action. The monitoring catches behavior that the threshold alone can't detect. Together, they address threats at three levels: rogue consortium members, external attackers, and buyer/merchant fraud.
8.1 Rogue Consortium Member
A single consortium member can't double-spend, reverse transactions, or forge blocks. The 2/3 signing threshold makes all of these impossible without majority collusion. The actual threats from a bad actor inside the federation are subtler.
Minting without reserves. A rogue treasury company issues ₿USD on the sidechain without purchasing the corresponding BTC on the base layer. They pocket the incoming fiat and skip the Bitcoin purchase. For some window of time, the circulating ₿USD supply exceeds the actual BTC in reserve. IDMA's monitoring cross-references every mint event on the sidechain against the base-layer deposit in real time. If a treasury company mints ₿USD and the corresponding BTC doesn't appear in their Ledger 1 wallet within a defined settlement window, the system flags it. The specification defines this window as a protocol parameter. The tighter the window, the less room for fraud.
Draining reserves. A member could attempt to move BTC out of their Ledger 1 or Ledger 2 wallets without a corresponding redemption event on the sidechain. Because the reserves sit in publicly addressable Bitcoin wallets, anyone can watch them. IDMA's monitoring triggers an alert the moment a reserve wallet's balance drops without a matching sidechain burn. When a discrepancy is detected, the protocol automatically freezes that member's minting capability until the discrepancy is resolved. The alert is public. Other consortium members and outside observers can verify the discrepancy independently using the base-layer wallet addresses.
Block production manipulation. When it's a rogue member's turn to propose a block, they could reorder transactions within the block or selectively exclude certain transactions. On most chains, transaction ordering manipulation is a serious concern because it can be exploited for price arbitrage (the MEV problem familiar from Ethereum). On ₿ridge, the attack surface is smaller: every ₿USD is always worth $1, so there's no price to manipulate through reordering. A member could still delay or censor specific transactions during their proposal round, but the next block proposer is a different member, and excluded transactions get included in the next block. Persistent censorship would require majority collusion. IDMA's monitoring of execution ordering patterns catches systematic exclusion by any single member.
Fake volume for fee harvesting. If sidechain transaction fees are distributed among federation members, a member could create addresses and circulate ₿USD between them to inflate volume and harvest fees. The defense is structural: commerce-layer transaction fees are set low enough that the cost of producing wash transactions roughly equals or exceeds the fee revenue. IDMA's monitoring also tracks per-member transaction patterns, and anomalous volume spikes from addresses associated with a single member's infrastructure are flagged automatically.
8.2 External Attacks
Coordinated short-plus-redemption. An attacker shorts BTC on external markets, then triggers mass ₿USD redemption to force the consortium to sell Bitcoin from reserves, crashing the spot price and profiting on the short position. The defensive programmability toolkit (defined in TBB) addresses this: BTC-default redemption eliminates concentrated forced selling, time-weighted fees make rapid mint-and-redeem cycles expensive, and velocity limits throttle the fiat exit under stress. ₿ridge's role in this defense is providing the sidechain data (UTXO timestamps, aggregate redemption velocity) that the defensive mechanisms read. The full threat analysis is in TBB Section 10.
DDoS against federation nodes. An attacker floods consortium members' nodes with traffic to disrupt block production. Federation nodes run on institutional-grade infrastructure with DDoS mitigation already standard practice for publicly traded companies operating financial services. The threshold model adds resilience: even if several members' nodes are temporarily degraded, the remaining members continue producing blocks as long as the 2/3 threshold is met. IDMA's monitoring detects sustained node unavailability and can escalate under the consortium's emergency procedures.
Key compromise of a single member. If an attacker obtains a member's federation signing keys, they can sign blocks on behalf of that member. The 2/3 threshold limits the damage: a single compromised key can't forge blocks alone. The federation governance section (Section 15) defines key rotation procedures, including emergency rotation triggered by suspected compromise. The compromised member's signing authority is revoked and re-established under new keys. IDMA coordinates the rotation and verifies that the new key set is secure before the member rejoins the signing rotation.
8.3 Buyer and Merchant Fraud
Double-spend at POS. A buyer broadcasts a payment to a merchant and simultaneously tries to broadcast a conflicting transaction spending the same UTXOs to their own address. On proof-of-work chains, this is a real risk at zero-conf because miners could include either transaction. On ₿ridge, the federation nodes receive both transactions and the first one accepted wins. The second is rejected as a conflict. Because block production is deterministic (no mining race, no competing chain tips), there's no window for a competing transaction to slip through. Successfully double-spending would require corrupting the current block proposer, a publicly traded company with a public reputation and regulatory obligations.
Counterfeit ₿USD. On ₿ridge, only consortium members can mint ₿USD. It's an issued asset with defined, authorized issuers. A buyer can't create fake ₿USD any more than they could create fake L-USDT on Liquid. The protocol rejects any mint transaction that doesn't come from a certified issuer. A merchant's wallet can verify that the ₿USD it received traces back to a valid issuance by a certified consortium member.
Non-receipt claims. A merchant receives ₿USD, delivers the goods, and then claims the payment never arrived. The buyer has an on-chain TX ID and, if pre-confirmations are used, a signed cryptographic receipt from a federation member. The proof of payment is independently verifiable. This fraud vector is harder to execute than in the cash world, where there's no receipt unless someone creates one.
Overcharging via compromised terminal. A compromised merchant terminal could display one price and submit a transaction for a different amount. The defense lives in the wallet layer: the buyer's wallet displays the exact amount being signed and requires explicit confirmation before broadcasting. The protocol can't prevent a terminal from showing a wrong price, just as Bitcoin can't prevent a fake QR code. But the buyer's wallet is the signing authority, and if the wallet is sound, the buyer sees exactly what they're authorizing.
Refund fraud. A buyer receives goods, then pressures the merchant for a refund, ending up with both the goods and the money. Because refunds are forward transactions initiated voluntarily by the merchant, no one can force the merchant to send ₿USD back. There's no chargeback mechanism a buyer can trigger unilaterally. The merchant decides whether a refund is warranted. The fraud surface is dramatically smaller than on credit card networks, where the card company can pull money from the merchant's account without the merchant's consent.
Sybil attacks on the FSP layer. Someone creates hundreds of fake merchant or buyer accounts through an FSP to access minting and redemption services at scale for money laundering. ₿ridge protocol doesn't know or care about user identities. FSPs are responsible for vetting their users within their regulatory frameworks, including KYC/AML compliance. The protocol layer and the identity layer are structurally separate by design.
The consistent principle: the protocol handles settlement integrity, the wallet layer handles user authorization, and the FSP layer handles identity and dispute resolution. Each layer defends against the threats appropriate to its scope. No layer attempts to do another layer's job.
Settlement Finality and Dispute Framework
9.1 Irreversibility
Transactions on ₿ridge are final at the protocol level. Once a transaction is included in a signed block, the UTXOs it consumed are permanently spent and the UTXOs it created are permanently part of the recipient's balance. The protocol has no mechanism for reversing, modifying, or unwinding a completed transaction. No consortium member, no IDMA directive, and no court order can cause the sidechain to move funds backward. The chain records what happened. It doesn't have an opinion about whether it should have happened.
For merchants, this eliminates chargeback risk entirely. The ₿USD a merchant receives in a transaction is theirs. No payment processor, card network, or financial intermediary can reach into their wallet and pull it back.
9.2 Refunds
A refund is a new forward transaction. The merchant constructs a ₿USD payment to the customer's address, signs it, and broadcasts it to ₿ridge. The protocol treats it identically to any other payment. New $1 UTXOs are created for the customer with fresh timestamps. The customer's holding period on those specific dollars resets to zero, because the refund is economically a new acquisition. The original payment's UTXOs remain spent. The two transactions are independent entries on the chain.
Partial refunds work the same way. A merchant refunding $7 on a $20 purchase sends $7 in new UTXOs to the customer. The merchant retains the other $13. The protocol doesn't know the two transactions are related, and doesn't need to.
9.3 Dispute Resolution
Consumer protection and dispute resolution live outside the protocol at three levels:
FSP-mediated disputes. Financial service providers (wallet apps, payment platforms) can offer buyer protection as a value-added service. If a consumer purchases goods through a payment app and the merchant doesn't deliver, the FSP can mediate the dispute and, if warranted, credit the customer from the FSP's own operational funds. The FSP then pursues recovery from the merchant through its own merchant agreement. This is structurally identical to how PayPal handles disputes on top of final bank transfers. The consumer protection is a business-layer offering funded by the FSP's fee revenue. The protocol is uninvolved.
Merchant-initiated resolution. Reputable merchants handle returns and complaints directly, issuing refunds via forward transaction when they determine a claim is valid. The merchant bears the decision authority. No third party can override it at the protocol level.
Legal recourse. For large transactions or irresolvable disputes, the legal system applies. If someone pays a contractor $50,000 in ₿USD and the contractor doesn't perform, that's a breach of contract case. Courts can order restitution. The enforcement happens through legal channels, not through the sidechain.
The protocol handles settlement. The wallet handles authorization. The FSP handles the customer relationship. The courts handle the law. Each layer solves the problems within its scope.
Issued Assets and Multi-Product Support
Elements supports the creation of multiple distinct asset types on a single chain. Each asset has a unique identifier, a designated issuer, and its own supply. Assets of different types can't be mixed in a transaction any more than you could accidentally deposit euros into a dollar account.
10.1 Three Products, One Chain
₿USD, ₿OND, and ₿ILL circulate on ₿ridge as three separate issued assets. Each has a unique asset ID assigned at issuance. The protocol enforces type separation: a transaction paying ₿USD can only consume ₿USD inputs and produce ₿USD outputs. ₿OND and ₿ILL outputs can't be substituted. Wallet software displays each product's balance separately and constructs transactions using only the correct asset type.
All three assets share the same sidechain infrastructure: the same federation, the same block production, the same Confidential Transaction privacy, the same IDMA monitoring. The shared infrastructure reduces operational overhead. If the consortium had to operate a separate chain for each product, every member would need to run three sets of nodes, maintain three signing key sets, and coordinate three upgrade cycles. A single chain with multiple issued assets is more efficient and easier to secure.
10.2 Reserve Separation
Shared sidechain infrastructure does not mean shared reserves. Each product's two-ledger system is completely independent, held in separate Bitcoin wallets on the base layer. A stress event on ₿USD (a surge in fiat redemptions during a bear market) can't touch ₿OND or ₿ILL reserves. The sidechain enforces asset type separation. The reserve architecture enforces financial separation. The firewall operates at both layers simultaneously.
10.3 Conversion Between Products
The ₿OND conversion mechanism (any ₿USD holder can convert to a ₿OND at the current ₿C entry price, at no cost, with no delay) is implemented on ₿ridge as an atomic asset swap. The holder's ₿USD UTXOs are consumed and ₿OND UTXOs are created in a single transaction. The conversion doesn't touch reserves: the BTC backing the original ₿USD moves from the ₿USD reserve pool to the ₿OND reserve pool in the consortium's accounting, but no Bitcoin moves on the base layer. The sidechain records the asset type change. The reserve rebalancing is a ledger entry on the consortium's books, verified by IDMA.
Section 11Peg Mechanics: Minting and Redemption
Unlike Liquid's user-facing peg, ₿ridge's peg is a consortium-internal operation. End users never peg in or peg out. They buy and sell ₿USD through financial service providers. The treasury companies handle the boundary between the base layer and the sidechain.
11.1 Minting
When demand for ₿USD arrives through an FSP, the process follows a defined sequence. Fiat enters the consortium through the FSP channel. The treasury company uses the incoming funds to purchase BTC at the current spot price on the open market. The purchased BTC is deposited into the company's Ledger 1 wallet on Bitcoin's base layer. Once the base-layer deposit is confirmed, the treasury company signs a mint transaction on ₿ridge, creating new ₿USD UTXOs. The minted ₿USD is credited to the end user's balance through the FSP.
The critical step is the verification between the base-layer deposit and the sidechain mint. ₿ridge defines a settlement window: the maximum time allowed between a sidechain mint event and the corresponding BTC deposit in Ledger 1. IDMA's monitoring cross-references every mint against the base layer within this window. If the BTC doesn't appear, the mint is flagged and the member's minting authority can be suspended pending resolution (see Section 08: Threat Model).
The settlement window is a protocol parameter, initially proposed at 6 hours. This allows for base-layer confirmation time (6 Bitcoin block confirmations take roughly 60 minutes) plus operational processing, while remaining tight enough to limit exposure from unbacked minting.
11.2 Redemption
Redemption is the reverse. The holder submits a redemption request through their FSP. On the sidechain, the holder's ₿USD UTXOs are burned (sent to a provably unspendable address). The consortium's protocol selects which reserve notes in the vault to liquidate using the Profit Burn Priority algorithm (defined in TBB). The holder receives their payout through the FSP.
Three exit paths are available, each with different sidechain mechanics:
BTC-default redemption. The consortium transfers BTC from Ledger 1 directly to the redeemer's Bitcoin wallet. On the sidechain, ₿USD UTXOs are burned. Separately, on the base layer, BTC moves from the consortium's Ledger 1 wallet to the redeemer's address. The two operations are performed independently by the consortium. The fee is calculated from sidechain UTXO timestamps (holding period) and the network's current reserve depth. BTC-default is instant for standard volumes.
Savings conversion. The holder converts ₿USD to ₿OND at the current ₿C entry price. On the sidechain, ₿USD UTXOs are consumed and ₿OND UTXOs are created in an atomic swap. No reserves are touched. No Bitcoin is sold. No fee applies. This is the escape valve that absorbs panic without absorbing outflow.
Fiat redemption. The consortium sells BTC from Ledger 1 on the open market and returns dollars to the redeemer through the FSP. On the sidechain, the ₿USD UTXOs are burned. This is the only exit path that generates selling pressure on BTC spot. Fees are higher than BTC-default at every holding period tier, and velocity limits apply as defined in TBB's defensive programmability framework.
11.3 Burn Mechanics
When ₿USD is burned on redemption, the UTXOs are sent to a provably unspendable address (an OP_RETURN output or a designated burn address derived from a hash with no known preimage). The burn is permanent and verifiable. Anyone can confirm that the burned UTXOs will never re-enter circulation. The total outstanding supply on the sidechain can be independently calculated at any time: total minted minus total burned.
Section 12Sidechain Transaction Fees
₿ridge has two distinct fee categories that serve different purposes. They should not be confused.
Commerce-layer transaction fees are charged on every ₿USD transfer on the sidechain: peer-to-peer payments, merchant transactions, salary deposits, any movement of ₿USD between addresses. These are the sidechain's operating fees, analogous to Bitcoin's miner fees. This section covers commerce-layer fees.
Redemption fees are charged when ₿USD is redeemed for BTC or fiat. These are part of the defensive programmability toolkit and are defined in TBB. The sidechain provides the data (UTXO timestamps, aggregate velocity) that the redemption fee algorithm reads, but the fee schedule itself is a monetary policy parameter governed by the IDMA charter, not a sidechain protocol parameter.
12.1 Fee Structure
Commerce-layer fees are set low enough to make everyday transactions frictionless. A coffee purchase, a salary payment, a merchant settlement: none of these should carry a fee that a user notices. The target is a fixed per-transaction fee in the range of fractions of a cent, not a percentage of the transaction value. ₿USD is a stablecoin for commerce. If fees make small transactions impractical, the commerce use case fails.
The specific fee level is a protocol parameter, adjustable through the governance process (Section 16). The initial proposal is a flat fee of $0.001 (one-tenth of a cent) per transaction, regardless of the number of UTXOs consumed or created. This is low enough to be invisible for any transaction above a few cents, while generating meaningful aggregate revenue at scale.
12.2 Fee Recipients
Commerce-layer fees are collected by the federation. The fee revenue is pooled and distributed among consortium members according to a formula defined in the consortium's operating agreement. The distribution formula is a governance decision, not a protocol decision. Options include equal distribution, distribution proportional to each member's share of outstanding ₿USD supply, or distribution proportional to each member's contribution to federation infrastructure.
IDMA monitors fee distribution for fairness. Anomalies in fee allocation (a member receiving a disproportionate share relative to the agreed formula) are flagged automatically.
12.3 Fee Revenue and the Demand Engine
Commerce-layer fee revenue is one input into the consortium's broader economics. TBB describes how fee revenue compounds the reserve system: a portion of fee revenue is used to purchase additional BTC, which deepens Ledger 2 over time. The sidechain doesn't enforce this allocation. It collects fees and distributes them to the federation. What the consortium does with the revenue after distribution is governed by the charter and the IDMA framework, not by the sidechain protocol.
Section 13IDMA Monitoring Interface
IDMA's monitoring role is described in the IDMA Charter. This section specifies how ₿ridge provides the data IDMA needs to perform that role.
13.1 Data Access
IDMA operates a dedicated monitoring node connected to ₿ridge. This node receives every block, every transaction, and every state update in real time. IDMA holds a master viewing key that unblinds all Confidential Transaction data: amounts, asset types, and sender/recipient addresses. IDMA sees everything the federation sees.
The monitoring node is read-only. IDMA can observe the network but cannot broadcast transactions, sign blocks, or modify state. IDMA has no spending keys, no signing authority, and no ability to censor or reorder transactions. The separation is absolute: IDMA watches, it doesn't act on-chain.
13.2 Monitored Metrics
IDMA's monitoring system tracks the following in real time:
Mint and burn activity. Every ₿USD minted or burned, by which consortium member, at what time. Cross-referenced against base-layer BTC deposits and withdrawals within the settlement window.
Outstanding supply. Total ₿USD, ₿OND, and ₿ILL in circulation, broken down by issuing member.
Redemption velocity. Rolling 24-hour, 7-day, and 30-day redemption volumes as a percentage of total supply, the inputs to the defensive toolkit's escalation thresholds.
Fee distribution. Per-block fee collection and distribution across federation members, checked against the agreed formula.
Transaction ordering. Per-member analysis of transaction inclusion patterns during each member's block proposal rounds. Flags for systematic exclusion, front-running, or ordering anomalies.
Node availability. Uptime and responsiveness of each federation member's functionary node. Sustained unavailability triggers an alert.
Reserve correspondence. Continuous comparison of sidechain outstanding supply against base-layer reserve wallet balances. Any discrepancy triggers an immediate alert.
13.3 Alert and Escalation
When IDMA's monitoring detects an anomaly, the response follows the escalation framework defined in the IDMA Charter. Minor anomalies (brief node downtime, a short delay in settlement window compliance) generate internal alerts to the affected member and to IDMA's oversight committee. Serious anomalies (reserve discrepancy, unauthorized mint, systematic transaction exclusion) trigger public alerts and can result in the affected member's minting authority being suspended or their certification being revoked.
IDMA doesn't enforce penalties on-chain. It publishes findings, issues certifications and revocations, and coordinates the consortium's response through the governance framework. The enforcement power comes from the consortium's charter: a member whose IDMA certification is revoked can no longer participate in the federation.
Section 14State Anchoring
₿ridge is a sidechain. Its security depends on the federation's integrity, not on Bitcoin's proof-of-work. To provide an external, tamper-evident record of ₿ridge's state, the federation periodically commits a cryptographic hash of the sidechain's state to Bitcoin's base layer.
14.1 The Commitment
At a defined interval (initially proposed at every 144 Bitcoin blocks, approximately once per day), the federation constructs a commitment transaction on Bitcoin's base layer. The transaction includes an OP_RETURN output containing a hash of ₿ridge's current state: the Merkle root of all unspent outputs, the total outstanding supply of each issued asset, and the block height of the sidechain at the time of commitment.
The commitment transaction is a standard Bitcoin transaction, visible to anyone, stored permanently in Bitcoin's blockchain. It doesn't reveal any information about individual transactions or balances on ₿ridge. It records a single hash that can be verified against the sidechain's state by anyone with access to a ₿ridge node.
14.2 Tamper Evidence
If the federation were to rewrite ₿ridge's history (altering past transactions, modifying balances, or inflating the supply), the altered state would produce a different hash than the one committed to Bitcoin. Any observer who recorded the sidechain's state at the time of commitment can detect the tampering by recomputing the hash and comparing it to the Bitcoin commitment. The base layer acts as a public notary: it doesn't know what the hash means, but it proves what the hash was at a specific point in time.
14.3 Verification
Independent verification requires two things: access to ₿ridge's state data (available through a ₿ridge node or through IDMA's published transparency reports) and access to Bitcoin's blockchain (available to anyone). The verification process is deterministic: recompute the state hash from the sidechain data and compare it to the OP_RETURN value in the corresponding Bitcoin transaction. A match confirms that the sidechain's state hasn't been altered since the commitment was made. IDMA performs this verification automatically as part of its monitoring function. Any external party can perform it independently.
Section 15Federation Governance
The federation is the consortium's operational layer. Governance decisions about the federation are a subset of the consortium's broader governance, subject to the IDMA charter. This section covers the federation-specific mechanics: who operates nodes, how membership changes, and what happens in emergencies.
15.1 Member Admission
A new consortium member seeking to join the federation must meet IDMA's published certification criteria (reserve requirements, audit standards, jurisdictional compliance). Once certified, the new member provisions a functionary node, generates signing keys, and undergoes a key ceremony coordinated by IDMA. The existing federation votes to admit the new member under the consortium's supermajority governance rules. Once admitted, the new member's node is added to the block production rotation, and the signing threshold is recalculated for the new federation size.
15.2 Member Removal
A member can be removed from the federation voluntarily (withdrawal) or involuntarily (revocation). Voluntary withdrawal follows a defined wind-down period during which the departing member's outstanding ₿USD obligations are transferred or redeemed. Involuntary removal is triggered by IDMA certification revocation, which can result from reserve discrepancies, audit failures, or governance violations as defined in the charter. In both cases, the departing member's signing keys are rotated out, and the threshold is recalculated for the reduced federation size.
15.3 Key Management
Each federation member's signing key is the member's responsibility. IDMA does not hold, manage, or have access to any member's signing keys. Key generation follows a defined ceremony with IDMA as a witness but not a participant. Members are required to use hardware security modules (HSMs) for key storage and to maintain geographically distributed backup keys under the operational requirements published by IDMA.
15.4 Key Rotation
Routine key rotation occurs on a scheduled basis (proposed: annually). The member generates new keys, coordinates with the federation to update the signing set, and the old keys are retired. Emergency key rotation is triggered by suspected compromise and follows an accelerated timeline. IDMA coordinates the emergency rotation, and the compromised key is immediately revoked from the signing set. The member cannot participate in block production until the new key is verified and admitted.
15.5 Emergency Procedures
Network partition. If the federation splits into groups that can't communicate with each other, no group can meet the 2/3 threshold alone (assuming the partition isn't extremely lopsided). Block production halts until connectivity is restored. The chain doesn't fork. When the partition heals, the federation resumes from the last signed block.
Member default. If a member's business fails (bankruptcy, regulatory shutdown), the consortium's charter defines how the member's ₿USD obligations, reserve holdings, and federation role are handled. The federation continues operating at reduced size while the default is resolved. If the reduced federation still meets the minimum membership threshold, block production continues uninterrupted.
Catastrophic key loss. If a member loses all copies of their signing key (primary and backups), they are effectively removed from the federation until new keys are generated and admitted through the standard key ceremony process. The federation continues without them.
Section 16Upgrade Path
₿ridge's protocol rules can be changed. The process for changing them is deliberately slow, transparent, and subject to independent review. The high-friction governance model described in the IDMA charter applies directly to sidechain upgrades.
16.1 Proposal
Any consortium member can propose a protocol upgrade. The proposal must include a technical specification of the change, a rationale, an impact assessment covering all three products (₿USD, ₿OND, ₿ILL), and a testing plan. Proposals are submitted to IDMA and published to the consortium's governance forum for review.
16.2 IDMA Certification
Before any upgrade reaches the live network, IDMA reviews the code change. The review verifies that the upgrade doesn't introduce asymmetric advantages for any member, doesn't alter fee distribution in ways that deviate from the agreed formula, doesn't modify consensus rules in ways that compromise the signing threshold or fault tolerance, and doesn't weaken the privacy architecture. IDMA publishes its review findings. No code ships to the live network without IDMA approval.
16.3 Federation Vote
After IDMA certification, the consortium votes on the upgrade under its supermajority governance rules. The vote requires the same threshold as other charter amendments (defined in the consortium's operating agreement). If approved, the federation coordinates a deployment window during which all members upgrade their nodes simultaneously.
16.4 Backward Compatibility
Upgrades that change transaction format, UTXO structure, or consensus rules require a hard fork of the sidechain. Because the federation is small and coordinated, hard forks are operationally simpler than on public blockchains, but they still require all members to upgrade within the deployment window. Upgrades that add new features without modifying existing rules can be deployed as soft forks, which are backward-compatible and don't require simultaneous adoption.
The specification version is incremented with every protocol change. The version number is included in each block header so that any observer can determine which protocol rules were in effect for any given block.
Section 17Privacy Architecture
17.1 What the Protocol Records
₿ridge records: transaction IDs (a unique hash for each transaction), the addresses involved (sender and recipient, pseudonymous by default), timestamps (when each UTXO was created), and Confidential Transaction commitments (cryptographic commitments to amounts and asset types that are opaque without a viewing key or blinding factor).
17.2 What the Protocol Does Not Record
₿ridge does not record: holder identity (names, documents, KYC data), transaction purpose (payment, refund, salary, gift), spending categories (groceries, rent, entertainment), geographic location, device information, or any metadata about why a transaction was made. This data doesn't exist on-chain because the protocol was designed not to collect it.
17.3 Privacy Properties
Three features of ₿ridge contribute to structural privacy:
Confidential Transactions hide amounts and asset types from outside observers. A third party scanning the blockchain sees that transactions occur but can't determine how much moved or which product was transferred.
The UTXO model means there are no persistent account balances visible on-chain. A holder's balance is the aggregate of their unspent outputs, which are spread across multiple transactions. Without a viewing key, an observer can't determine a specific address's total balance by summing visible amounts, because the amounts are blinded.
Pseudonymous addresses are not tied to real-world identity at the protocol level. A holder can use a different address for every transaction if their wallet supports it (and good wallet design should). Linking addresses to identities requires external information that the sidechain doesn't provide.
17.4 Where Identity Lives
Financial service providers distributing ₿USD operate within regulatory frameworks that may require user identification. KYC/AML compliance is an FSP obligation, not a protocol feature. The FSP knows who their customers are. The protocol doesn't. This separation means that the privacy architecture can't be weakened by a protocol change. The data simply isn't on-chain. An FSP can share customer information with regulators as required by their jurisdiction. That information came from the FSP's own onboarding process, not from ₿ridge.
17.5 Comparison to CBDC Architecture
A CBDC operates on a ledger controlled by the issuing central bank. The central bank sees every transaction, every balance, and every counterparty in real time. Programmable spending restrictions (expiration dates, category limits, geographic fencing) are architecturally possible because the issuer has complete visibility and control. The surveillance capability is built into the infrastructure.
₿ridge's architecture makes this kind of surveillance structurally infeasible. Amounts are blinded. Identities aren't recorded. Transaction purpose is unknown. Even IDMA, which holds a master viewing key and can see amounts, can't see who the holders are, because the protocol doesn't collect that information. The privacy gap between a CBDC and ₿ridge is architectural, not policy-dependent. A future government can't order ₿ridge to start collecting identity data, because the protocol has no mechanism for it. They could order FSPs to collect more data, but that data stays at the FSP layer. It never enters the chain.
₿USD offers substantially greater privacy than a CBDC. It does not replicate the privacy properties of holding Bitcoin directly. Bitcoin's base layer is pseudonymous with visible amounts. ₿ridge is pseudonymous with hidden amounts. Neither is anonymous. The privacy improvement over a CBDC is structural. The privacy gap relative to native Bitcoin is the cost of the federation trust model.
Open Questions
The following parameters and design decisions require empirical research, simulation, or implementation experience before they can be finalized. They are flagged here as open so that contributors, researchers, and eventually the consortium's engineering team can address them systematically.
Block time optimization. The proposed 30-second block time balances throughput against coordination overhead. Simulation under varying federation sizes and network latency conditions could identify a more optimal value. The tradeoff is between faster state updates (useful for IDMA monitoring and defensive toolkit responsiveness) and increased chain growth and signing load on functionaries.
Signing threshold calibration. The default 2/3 threshold follows Liquid's proven model. A higher threshold (3/4, 4/5) increases security against collusion but reduces fault tolerance. A lower threshold increases resilience but widens the collusion surface. The optimal threshold depends on the expected federation size and the consortium's risk tolerance. Game-theoretic modeling of collusion incentives across different threshold/membership combinations would inform this decision.
Settlement window duration. The proposed 6-hour window between sidechain mint and required base-layer BTC deposit needs calibration. Too tight, and legitimate operational delays trigger false alerts. Too loose, and a rogue member has hours to operate with unbacked ₿USD. Analysis of base-layer confirmation times, exchange settlement speeds, and operational workflows at publicly traded companies would help set this parameter.
Confidential Transaction performance at scale. CT transactions are larger than standard transactions due to range proofs. At high throughput, the computational cost of verifying range proofs could become a bottleneck for functionary nodes. Benchmarking CT verification performance on the target hardware (institutional-grade servers) at projected transaction volumes would determine whether the 4 MB block weight limit and 30-second block time are sustainable under full load.
Script extensions for defensive programmability. Can the time-weighted redemption fee calculation be implemented in Elements Script using existing relative timelock opcodes, or does it require custom opcodes? Can aggregate network metrics (rolling redemption velocity, coverage ratio) be made available to transaction validation scripts, or must the defensive logic live entirely in the application layer? These questions determine how much of the defensive toolkit is protocol-enforced versus application-enforced, which affects the system's trust model.
Commerce-layer fee level. The proposed $0.001 per-transaction fee is a starting point. Too high, and micropayments become impractical. Too low, and fee revenue doesn't contribute meaningfully to the demand engine. Modeling the relationship between fee level, transaction volume projections, and fee revenue contribution to Ledger 2 deepening would help calibrate this parameter.
Fee distribution formula. Equal distribution among members is simple but may not reflect each member's actual contribution to the network. Proportional distribution based on outstanding supply share creates an incentive to mint more, which aligns with the demand engine. Proportional distribution based on infrastructure contribution rewards operational investment. The right formula depends on the consortium's incentive design goals.
State anchoring frequency. The proposed daily commitment to Bitcoin's base layer (every 144 blocks) balances tamper evidence against base-layer transaction costs. More frequent anchoring provides tighter tamper evidence but costs more in Bitcoin transaction fees. Less frequent anchoring reduces costs but widens the window during which undetected tampering could occur. The cost-benefit depends on the base-layer fee environment at the time of deployment.
Minimum federation size. What is the smallest federation that provides adequate security and fault tolerance? A 5-member federation with a 2/3 threshold (4 of 5 must sign) is technically functional but leaves very little room for faults. A 15-member federation is more resilient but requires broader consortium adoption before launch. The minimum viable federation size determines when ₿ridge can go live.
Cross-product interaction mechanics. The ₿OND conversion (₿USD to ₿OND atomic swap) is described conceptually. The implementation details, including how the ₿C entry price is determined at the moment of conversion, how the atomic swap is constructed in Elements Script, and how the reserve rebalancing is communicated to the base layer, need specification at the implementation level.