What Are Confidential Transactions?

By Blockstream Engineering · Last updated June 2026

The Problem: Bitcoin's Public Ledger

Every Bitcoin transaction is recorded on a public ledger that anyone can audit. This open verifiability is what allows Bitcoin to function without a trusted third party. Anyone running a node can independently confirm that no bitcoin was created outside the rules, that no double-spend occurred, and that every transaction follows the consensus protocol.

But this transparency comes with a cost. Every Bitcoin transaction broadcasts its exact amount in the clear. When Alice sends 3.5 bitcoin to Bob, that amount is visible to every node on the network, every block explorer user, and every chain analysis firm watching the blockchain. The addresses involved, the amounts transferred, and the change outputs are all permanently recorded in plaintext.

For individuals, this means that anyone who learns your Bitcoin address can trace your entire financial history. For businesses, the problem is worse. A supplier who receives payment can see your wallet balance. A competitor watching on-chain activity can estimate your revenue. A trading desk executing a large order leaves a trail that other market participants can front-run.

This is the problem Confidential Transactions solve: preserving the auditability that makes Bitcoin trustworthy while removing the public exposure of sensitive financial data.

How Confidential Transactions Work

At its core, a Confidential Transaction replaces plaintext amounts with cryptographic commitments. Instead of broadcasting "Alice sends 3.5 bitcoin to Bob", the transaction says "Alice sends a committed value to Bob", where only Alice, Bob, and anyone they explicitly authorize can see the actual number.

The network still verifies that the math checks out and that no bitcoin was created from nothing, without ever seeing the underlying amounts.

Three cryptographic components make this possible: Pedersen commitments, blinding factors, and range proofs.

Pedersen Commitments: Hiding Values in Plain Sight

A Pedersen commitment is a way to lock a value inside a cryptographic envelope. The commitment reveals nothing about the value it contains, but it has a critical mathematical property: commitments can be added together, and the sum of the commitments equals the commitment of the sum.

Here is the intuition. Suppose you want to prove that two sealed envelopes contain numbers that add up to ten. With Pedersen commitments, you can hand someone the sealed envelopes, and they can verify the arithmetic without ever opening them. The commitment binds you to the value inside (you cannot change it later), and the commitment hides the value (no one can determine what it is by looking at the commitment).

The Math Behind Confidential Transactions

Formally, a Pedersen commitment to a value v looks like this:

C = v*G + r*H

Where:

• v is the actual transaction amount (the value being hidden)
• r is a randomly chosen blinding factor (a large random number known only to the sender and receiver)
• G and H are two generator points on the secp256k1 elliptic curve (the same curve Bitcoin uses for signatures), chosen so that no one knows the discrete logarithm relationship between them. The generator H is derived using a hash-to-curve operation on G, making the discrete log relationship provably unknown.
• C is the resulting commitment (a point on the elliptic curve that appears as a random-looking number)

The key property: given C, there is no computationally feasible way to extract v or r individually. But if you know r (the blinding factor), you can verify that C commits to the value v.

Blinding Factors: The Shared Secret

The blinding factor r is what gives the sender and receiver private access to the transaction data. When Alice creates a Confidential Transaction to Bob, she generates a blinding factor for each output. She shares these blinding factors with Bob (encrypted, as part of the transaction data), so Bob can verify the amounts he received.

The blinding factors serve a dual purpose:

• Privacy: Without the blinding factor, the commitment looks like a random point on the elliptic curve. An observer cannot distinguish a commitment to 0.001 bitcoin from a commitment to 1,000 bitcoin.
• Verification: Anyone who possesses the blinding factor can "open" the commitment and confirm the exact value. This is how the receiver knows what they received, and how authorized auditors can verify transaction details.

The blinding factors are also what allow the network to verify that a transaction balances. For a valid transaction, the sum of the input commitments must equal the sum of the output commitments plus the fee commitment. Since Pedersen commitments are additively homomorphic, this verification works on the commitments directly, without revealing the underlying values:

C_input1 + C_input2 + ... = C_output1 + C_output2 + ... + C_fee

This equation holds if and only if the underlying values balance. The blinding factors are constructed by the sender to guarantee this. If someone tries to create outputs that exceed their inputs, the commitment arithmetic fails, and the network rejects the transaction.

What CT Hides: Amounts and Asset Types

Confidential Transactions hide both transaction amounts and asset types. This second property is especially relevant on networks like Liquid that support multiple asset types. On the Liquid Network, a single transaction might involve LBTC, USDT, or any of the other assets issued on the network. CT conceals which asset type is being transferred alongside the amount.

This is accomplished through a mechanism called Asset Surjection Proofs. The commitment scheme extends beyond values to cover asset tags. On Liquid, this is what keeps the network's Issued Assets confidential: each output commits to both an amount and an asset type, and the cryptographic proofs ensure that the assets in the outputs match the assets in the inputs, without revealing which specific assets are involved.

From an outside observer's perspective, a Liquid transaction reveals almost nothing: they can see that a valid transaction occurred, that it was confirmed in a block, and which addresses were involved. The amounts, the asset types, and the relationship between inputs and outputs are all hidden behind cryptographic commitments.

CT Components at a Glance

Range Proofs: Verifying Without Seeing

Pedersen commitments have a subtle vulnerability. Because they operate in a mathematical group that wraps around (like a clock), a malicious user could commit to a negative number. If Alice could commit to an output of -5 bitcoin and another output of 15 bitcoin, the commitments would sum to 10 bitcoin (matching her inputs), but she would have effectively created 5 bitcoin out of nothing. The negative-valued output would be cryptographically valid but economically fraudulent.

Range proofs prevent this. A range proof is a zero-knowledge proof attached to each output that demonstrates the committed value falls within a valid range (specifically, between 0 and 2⁶⁴ - 1) without revealing the actual value. The network checks the range proof alongside the commitment, and any transaction with an output that fails the range proof is rejected.

Range Proof Size: Borromean Today, Bulletproofs Proposed

The CT protocol deployed on Liquid uses Borromean ring signatures for range proofs. They are functional but large: a single Borromean range proof adds roughly 4 KB per output, which makes a confidential transaction about ten times the size of an equivalent non-confidential transaction. This range proof data is the dominant size cost of Confidential Transactions.

Bulletproofs, introduced in a 2018 paper by Bünz, Bootle, Boneh, Poelstra, Wuille, and Maxwell (with Andrew Poelstra and Pieter Wuille from Blockstream Research), are a proposed improvement that would reduce range proof size substantially. A Bulletproof for a single 64-bit range is approximately 674 bytes, and when multiple outputs are aggregated into a single proof, the size grows only logarithmically. Blockstream Research is developing the next generation, Bulletproofs++, whose 64-bit range proof is about 416 bytes, roughly ten times smaller than Liquid's current Borromean range proofs. Bulletproofs++ is being implemented in libsecp256k1-zkp (a fork of Bitcoin's libsecp256k1 with zero-knowledge proof extensions), but it is research in progress and is not yet activated on Liquid mainnet.

If deployed, Bulletproofs++ would cut a typical confidential transaction from roughly ten times the size of an unblinded transaction down to about twice the size, reducing the bandwidth and storage overhead of Confidential Transactions without sacrificing the cryptographic guarantees.

How Range Proofs Work (Conceptual Overview)

A range proof works by decomposing the committed value into its binary representation and proving that each bit is either 0 or 1. If a 64-bit value is composed entirely of valid bits, it must fall within the range [0, 2⁶⁴ - 1]. The proof does this without revealing which bits are 0 and which are 1.

Bulletproofs improve on earlier approaches by using an inner-product argument. Instead of proving each bit individually (which produces a proof proportional to the number of bits), Bulletproofs compress the proof using a recursive halving technique. At each step, the proof is halved in size, resulting in a final proof that is logarithmic in the number of bits. This is what brings a 64-bit range proof down from thousands of bytes to hundreds.

Verifying a Bulletproof takes slightly more computation than verifying a Borromean proof, but the reduction in proof size more than compensates. Smaller proofs would mean more throughput, lower fees, and less storage overhead.

The Mathematics Behind CT

Confidential Transactions operate on elliptic curve cryptography, the same mathematical foundation that secures Bitcoin's digital signatures. Understanding the math at a slightly deeper level reveals why CT works and why it is considered cryptographically sound.

Elliptic Curve Points and the Discrete Log Problem

An elliptic curve, for cryptographic purposes, defines a set of points where you can perform a kind of addition. Given a point G on the curve, you can compute 2*G, 3*G, 1000*G, and so on. Going forward (multiplying a point by a scalar) is computationally easy. Going backward (given a point P = n*G, finding n) is computationally infeasible for large numbers. This is the elliptic curve discrete logarithm problem, and it is the bedrock of Bitcoin's security.

Pedersen commitments exploit this one-way property. The commitment C = v*G + r*H uses two independent generator points, G and H. The security assumption is that nobody knows the value x such that H = x*G. If someone did know x, they could forge commitments to arbitrary values. Because this discrete log relationship is unknown (and, under standard cryptographic assumptions, unknowable), the commitment scheme is both hiding and binding.

Homomorphic Addition: Why the Math Balances

The additive homomorphism of Pedersen commitments is what allows transaction verification without decryption. Consider a transaction with one input and two outputs:

• Input commitment: C_in = v_in * G + r_in * H
• Output 1 commitment: C_out1 = v_out1 * G + r_out1 * H
• Output 2 commitment: C_out2 = v_out2 * G + r_out2 * H

The transaction is valid if v_in = v_out1 + v_out2 (ignoring fees for simplicity). The network checks this by computing:

C_in - C_out1 - C_out2 = (v_in - v_out1 - v_out2) * G + (r_in - r_out1 - r_out2) * H

If the values balance (v_in - v_out1 - v_out2 = 0), the result simplifies to:

C_in - C_out1 - C_out2 = (r_in - r_out1 - r_out2) * H

The sender constructs the blinding factors so that r_in = r_out1 + r_out2, making this expression equal to the point at infinity (the elliptic curve identity element, equivalent to zero). The network can verify this equality without ever learning the individual values or blinding factors.

If the values do not balance, the leftover value component produces a point that is not a known multiple of H alone, and the verification fails. Forging a valid transaction without balancing values would require solving the discrete log problem between G and H, which is computationally infeasible.

Asset Commitments: Extending to Multiple Asset Types

On networks that support multiple asset types (like the Liquid Network), the commitment scheme extends to cover asset tags. Each output commits to both an amount and an asset type using a structure like:

C = v * A + r * H

Where A is itself a blinded asset tag derived from the asset's identifier. The Asset Surjection Proof then demonstrates that each output's asset type matches one of the input asset types, without revealing which one. This prevents an attacker from converting one asset into another (e.g., turning USDT into LBTC) while keeping the specific asset types hidden from outside observers.

Privacy vs. Transparency: How CT Maintains Network Integrity

A common concern with any privacy technology is that it might enable counterfeiting or inflation. If amounts are hidden, how can the network be certain that no one is printing money?

CT addresses this with mathematical guarantees. The combination of Pedersen commitments and range proofs creates a system where:

• Conservation is enforced: The homomorphic property of commitments ensures that inputs equal outputs. Any imbalance causes verification to fail.
• Negative values are impossible: Range proofs guarantee that every output is a non-negative value within bounds. There is no way to hide inflation behind negative outputs.
• The supply remains auditable: While individual transaction amounts are hidden, the total supply of LBTC is still verifiable. On the Liquid Network, the total LBTC supply can be confirmed by checking the peg-in and peg-out transactions, which interact with the Bitcoin mainchain where amounts are public.

CT provides privacy for individual transactions while maintaining the systemic guarantees that make a financial network trustworthy.

Confidential Transactions on the Liquid Network

The Liquid Network is the primary production deployment of Confidential Transactions. Every transaction on Liquid uses CT by default. Using CT requires no opt-in or special configuration, and Liquid wallets generate confidential addresses automatically. This is a deliberate design choice: when privacy is default, there is no metadata leakage from choosing to use it.

CT in Practice on Liquid

When you send LBTC or any Liquid asset, your wallet automatically generates the Pedersen commitments, blinding factors, range proofs, and (if multiple asset types are involved) asset surjection proofs. The recipient's wallet uses the shared blinding factors to decode the transaction and confirm the amount received.

For the sender and receiver, CT requires no extra steps. The Blockstream app handles all CT operations natively, generating Pedersen commitments, blinding factors, and range proofs automatically when constructing transactions. Users send and receive Liquid bitcoin and other Liquid assets without needing to understand the underlying cryptography. The amounts appear in their wallet as expected. The privacy happens at the protocol layer, invisible to the user but active on every transaction.

For hardware wallet users, Jade is the only Bitcoin hardware wallet that signs Confidential Transactions natively. When signing a Liquid transaction on Jade, the device verifies the Pedersen commitments and range proofs on the hardware itself, confirming that the transaction amounts shown on screen match the cryptographic commitments before producing a signature. This keeps the signing keys offline while still supporting Liquid's full CT privacy model.

What Block Explorers Show

Viewing a Liquid transaction on Blockstream Explorer reveals what CT looks like from the outside. Where a Bitcoin transaction shows exact amounts ("3.5 BTC"), a Liquid transaction shows "Confidential" in place of the amount and asset type for each output. The explorer displays the transaction structure (inputs, outputs, fees), the transaction ID, and the block it was confirmed in, but the financial details are cryptographically sealed.

Transaction fees on Liquid are an exception. Fees are unblinded so that the network can verify that block signers are collecting the correct amounts. This small transparency window does not compromise the privacy of the transacting parties, since the fee reveals only a tiny fraction of the transaction's value.

In January 2025, ELIP 200 activated on Liquid, reducing Confidential Transaction fees by up to 90%. A confidential USDT-Liquid transaction that previously cost ~250 satoshis now costs ~25 satoshis (~$0.03 USD). CT fees now cost roughly the same as public transaction fees, removing the privacy premium that had historically discouraged CT use for everyday payments.

Unblinding Keys: Selective Disclosure

CT does not make transactions permanently opaque. Each transaction output has an associated unblinding key (sometimes called a blinding key or viewing key), which is the blinding factor r from the Pedersen commitment along with the asset blinding factor. Given the unblinding key, a third party can reconstruct the commitment C = v*G + r*H and verify that it matches the on-chain commitment, confirming the exact value and asset type. The sender or receiver can share this key with any third party to reveal the amount and asset type of a specific output.

This selective disclosure model is what separates CT from all-or-nothing privacy systems. The user decides who can see their transaction data and when. Possible scenarios include:

• Auditors: A company shares unblinding keys with their accountant or auditor, who can verify transaction amounts without accessing the private keys that control the funds.
• Regulators: An institution provides unblinding keys to a regulatory body as part of compliance reporting.
• Business partners: A trading desk shares unblinding keys with a counterparty to prove that a payment was made.
• Personal records: A user exports unblinding keys for their own tax records.

The key distinction is that disclosure is always voluntary and granular. Sharing the unblinding key for one transaction does not expose any other transaction. The user retains full control over who sees what.

How CT Enables Compliance-Compatible Privacy

Financial regulations often require institutions to maintain records of their transactions and make those records available to regulators on request. This creates an apparent conflict with privacy: how can a system be private and compliant at the same time?

CT resolves this by separating privacy from secrecy. A Confidential Transaction is private from public observers (competitors, chain analysts, random block explorer users) while remaining auditable by authorized parties through unblinding keys. The institution maintains full records of its own transactions. Regulators can be granted access to specific transaction data on a need-to-know basis. The general public sees only that a valid transaction occurred.

This model maps naturally to existing financial infrastructure. Traditional bank transactions are not publicly visible, but they are auditable by regulators and internal compliance teams. CT provides the same information architecture for digital asset transactions.

Why CT Matters for Institutional Trading

For institutional trading desks and large-scale market participants, the privacy provided by CT addresses several specific risks:

• Front-running prevention: On a transparent blockchain, a large pending transaction is visible in the mempool. Other traders can see the size and direction of the order and trade ahead of it. On Liquid, the amount is hidden, eliminating this attack vector.
• Information leakage: When a fund moves bitcoin between wallets, the amounts and timing reveal portfolio strategy. CT prevents competitors from inferring trading positions or rebalancing activity from on-chain data.
• Counterparty confidentiality: In OTC (over-the-counter) trades settled on-chain, both parties prefer that the settlement amount remains between them. CT ensures that settlement details stay confidential, with selective disclosure available for auditing.
• Market impact reduction: Large orders on transparent blockchains can move markets before the trade is even completed. CT removes the visibility that allows other participants to price in pending large transactions.

CT's Role in Securities Issuance on Liquid

The Liquid Network supports issuance of security tokens, stablecoins, and other financial instruments through its Issued Assets feature. Confidential Transactions play a critical role in making this viable for regulated securities:

• Investor privacy: Shareholders' positions are not broadcast to the public blockchain. An investor holding security tokens on Liquid enjoys the same privacy as a traditional brokerage account holder.
• Issuer oversight: The issuer can retain unblinding keys or require them through the issuance terms, maintaining the ability to audit the cap table and verify holder identities for regulatory compliance.
• Transfer controls: Combined with Liquid's transfer-restricted assets feature, issuers can enforce who can hold and trade their securities. CT ensures that the transfer details (amounts, timing) remain confidential from public observers while the issuer retains full visibility.

This combination of default privacy with selective disclosure makes Liquid a viable platform for regulated asset issuance, where both investor privacy and issuer oversight are non-negotiable requirements.

How CT Differs From Other Privacy Approaches

Confidential Transactions are often mentioned alongside other Bitcoin privacy techniques. While they share the goal of improving financial privacy, they operate through fundamentally different mechanisms and offer different tradeoffs.

CT vs. CoinJoin

CoinJoin is a technique where multiple users combine their transactions into a single transaction with many inputs and many outputs. This makes it harder for an observer to determine which input corresponds to which output, breaking the transaction graph.

The key difference: CoinJoin hides who paid whom, but the amounts remain visible. An observer can still see that specific amounts were sent; they just cannot easily trace the flow from sender to receiver. CT hides how much was sent (and which asset type), but the addresses remain visible. The two techniques address different dimensions of privacy.

In practice, CT and CoinJoin are complementary. On the Liquid Network, a CoinJoin-style transaction with CT-blinded amounts would hide both the payment graph and the amounts, achieving stronger privacy than either technique alone.

CT vs. Mixing Services

Mixing services (also called tumblers) take bitcoin from multiple users, pool it, and redistribute it to break the link between sender and receiver. They address the same problem as CoinJoin (transaction graph privacy) but introduce a trusted third party: the mixer operator.

CT does not require any third party. The privacy is generated cryptographically by the sender's wallet and verified by the network. There is no pool of funds, no operator who could steal deposits, and no central point that could be compelled to reveal transaction history. The privacy guarantee is mathematical, not based on the operator's honesty or operational security.

CT vs. Zero-Knowledge Proofs (ZKPs)

Zero-knowledge proofs are a broad category of cryptographic techniques that allow one party to prove a statement is true without revealing any information beyond the truth of the statement. CT's range proofs are themselves a specific type of zero-knowledge proof. The distinction is in scope and tradeoffs.

Some privacy-focused systems use general-purpose ZKP systems (like zk-SNARKs) to hide all transaction data, including sender, receiver, amount, and asset type. These systems offer broader privacy but come with tradeoffs:

CT's reliance on the discrete logarithm assumption, the same assumption that secures Bitcoin itself, means that CT is exactly as strong as Bitcoin's core cryptography. If the discrete log problem is broken, Bitcoin itself has larger problems than CT. This is a meaningful advantage over systems that depend on newer, less battle-tested cryptographic assumptions or require a trusted setup ceremony where a compromise could undermine the entire system.

CT vs. PayJoin

PayJoin (also called Pay-to-Endpoint or P2EP) is a technique where both the sender and receiver contribute inputs to a transaction, making it look like a self-transfer. This breaks the common heuristic that all inputs to a transaction belong to the same entity.

Like CoinJoin, PayJoin addresses transaction graph privacy while leaving amounts visible. CT and PayJoin address different privacy dimensions and could be combined for stronger overall privacy.

Viewing Confidential Transactions

Understanding what different observers can and cannot see in a Confidential Transaction clarifies the privacy model.

What a Block Explorer Shows

A public observer viewing a Liquid transaction on Blockstream Explorer sees:

• Visible: Transaction ID, block height, timestamp, number of inputs and outputs, addresses (or scripts), transaction fee, confirmation status
• Hidden: Output amounts (displayed as "Confidential"), asset types (displayed as "Confidential"), the relationship between specific inputs and outputs

The observer can see that a transaction happened and read its structural metadata, but cannot determine the transaction's economic substance.

What the Sender and Receiver See

Both parties have the blinding factors and can decode the full transaction details in their wallets. The Blockstream app, for example, displays the exact amounts and asset types of Liquid transactions just as it would for on-chain Bitcoin transactions. The privacy layer is invisible to the participants; it only affects outside observers.

What an Authorized Auditor Sees

A third party who has been given the unblinding key for a specific output can decode that output's amount and asset type. They see exactly what the sender or receiver sees for that particular output. They cannot decode other outputs in the same transaction (unless those unblinding keys are also shared), and they cannot decode outputs in other transactions.

This creates a layered disclosure model:

Real-World Use Cases for Confidential Transactions

CT's privacy properties serve different users in different ways. Here are the scenarios where Confidential Transactions provide concrete value.

Exchange and Trading Desk Settlements

When exchanges settle trades between each other or with large OTC desks, the settlement amounts can move markets if visible. A 500-bitcoin settlement between two exchanges, visible on-chain, signals major trading activity that other market participants will trade on. On Liquid the settlement is confidential: the two exchanges see the amount and the network confirms the transaction is valid, while the rest of the market sees only that a transfer occurred.

Corporate Treasury Management

Companies that hold bitcoin on their balance sheet face a surveillance problem: their treasury movements are visible to anyone who identifies their wallet addresses. A transfer from cold storage to a hot wallet could be interpreted as selling pressure. CT allows corporate treasuries to manage their bitcoin on Liquid without broadcasting their internal operations to the public.

Individual Financial Privacy

For individuals, CT provides the same baseline financial privacy that traditional banking customers take for granted. When you pay a merchant, the merchant does not learn your bank balance. When you receive your salary, your employer does not see your spending history. On a transparent blockchain, both of these privacy expectations are violated, and CT restores them.

Stablecoin Transfers

USDT on Liquid benefits from CT just as LBTC does. A business making a $50,000 USDT payment to a supplier does not broadcast the amount or the fact that the asset is USDT. The payment is confirmed in approximately one minute with CT privacy applied by default.

Token Issuance and Securities

Issuers of security tokens on Liquid can distribute assets to investors with full privacy from public observers. An investor's holdings, their purchase price, and the timing of their transactions are all hidden from the public blockchain. The issuer retains the ability to audit through unblinding keys, satisfying regulatory requirements without sacrificing investor privacy.

Cross-Border Payments

Cross-border transactions on transparent blockchains reveal the exact amount being transferred across jurisdictions, which can create regulatory complications or security risks. CT removes the amount visibility from public view while maintaining the ability for the sender and receiver to produce proof of the transaction for their respective jurisdictions.

The History of Confidential Transactions

Confidential Transactions build on Adam Back's 2013 work on homomorphic value hiding ("Bitcoins with homomorphic value"). Gregory Maxwell, a Blockstream co-founder, formalized the CT scheme in 2015, adding Pedersen commitments and range proofs to prevent inflation while hiding amounts.

The core insight was that Pedersen commitments, which had been known in the cryptographic literature since 1991, could be applied to Bitcoin-style transaction outputs with the addition of range proofs to prevent inflation. Maxwell's formulation showed how to preserve Bitcoin's conservation rules (no inflation, no negative values) while hiding amounts.

Blockstream Research contributors implemented CT as part of the Elements platform, the open-source sidechain framework that would eventually become the foundation for the Liquid Network. The cryptographic primitives live in libsecp256k1-zkp, a fork of Bitcoin Core's libsecp256k1 library extended with Pedersen commitment operations, range proof generation/verification, and surjection proof support. When Liquid launched in 2018, it deployed CT as a default feature on every transaction, making it one of the first production networks to use Confidential Transactions at scale.

Subsequent work by Blockstream Research contributed to the development of Bulletproofs (published as a joint paper with Stanford and University College London researchers) and its successor, Bulletproofs++, proposed schemes that would substantially reduce the size of range proofs. This research is ongoing and has not yet been activated on Liquid mainnet, which continues to use Borromean ring signature range proofs.

Frequently Asked Questions

Can Confidential Transactions be used to create bitcoin out of thin air?

No. The combination of Pedersen commitments and range proofs mathematically guarantees that the sum of outputs cannot exceed the sum of inputs, and that no output is a negative value. Specifically, the homomorphic property of Pedersen commitments ensures that C_inputs - C_outputs = 0 only when the underlying values balance. Range proofs (Borromean ring signatures, the scheme currently deployed on Liquid) prove each output falls within [0, 2⁶⁴ - 1], preventing negative-value exploits via group wrapping. These are the same conservation rules that Bitcoin enforces, implemented through cryptographic proofs rather than plaintext verification. The network validates every Confidential Transaction against these rules before confirming it.

Are Confidential Transactions on the Bitcoin mainchain?

CT is not currently part of the Bitcoin mainchain protocol. It is deployed on the Liquid Network, a Bitcoin layer-2 sidechain. Implementing CT on Bitcoin mainchain would require a consensus change (a soft fork or hard fork), and there is ongoing research and discussion about whether and how this could be done. The Liquid Network is the production proving ground for CT technology.

If amounts are hidden, how do I know I received the right amount?

Your wallet holds the blinding factors for your transactions, which allow it to decode the committed amounts. When you receive a Confidential Transaction, the sender includes the blinding factor r and the value v in the transaction's rangeproof data, encrypted to the receiver's blinding public key. Your wallet decrypts this data and verifies that v*G + r*H matches the on-chain commitment, confirming the exact amount and asset type. The Blockstream app handles this decoding automatically. The amounts are only hidden from outside observers, not from the transaction participants.

Do Confidential Transactions make transactions slower?

CT transactions are larger than non-confidential transactions because they include range proofs and commitment data. A typical CT output adds roughly 4 KB for the Borromean ring signature range proof currently deployed on Liquid, plus 33 bytes for the Pedersen commitment and 33 bytes for the asset commitment, making a confidential transaction about ten times the size of an equivalent non-confidential one. (Blockstream Research is developing Bulletproofs++, a proposed scheme that would cut that overhead to roughly twice the size, but it is not yet activated on Liquid.) On the Liquid Network, this additional data is accounted for in the block size and fee structure. Transaction creation and verification require additional computation, but the overhead is minimal on modern hardware. Users of the Blockstream app or other Liquid-compatible wallets do not experience a noticeable difference in transaction speed.

Can law enforcement access Confidential Transaction data?

CT does not provide absolute secrecy. The sender and receiver always have the ability to disclose transaction details through unblinding keys. A court order or regulatory request directed at a user or institution can compel disclosure of these keys, at which point the transaction data becomes fully visible to the authorized party. CT prevents mass surveillance by the general public, not targeted investigation by authorities with legal process.

What is the difference between Confidential Transactions and a privacy coin?

CT is a cryptographic technique applied to transaction outputs, not a separate currency or token. On the Liquid Network, CT applies to LBTC (which is pegged 1:1 to bitcoin) and all other Liquid assets. Unlike standalone privacy coins, CT operates within the Bitcoin ecosystem, uses well-established cryptographic assumptions (the same discrete logarithm problem that secures Bitcoin), and provides selective disclosure through unblinding keys. The privacy is a feature of the transaction format, not a property of a distinct monetary system.