The Asset Peg-Out and Burn Proofs standard specifies a verifiable method for permanently removing an issued asset from circulation on the Liquid Network. This is not a simple balance decrement; it is a cryptographic proof-of-burn embedded in an OP_RETURN output, creating an immutable on-chain record that a specific quantity of an asset has been destroyed. For bridge operators managing wrapped tokens, this proof is the canonical trigger to release native assets on a counterpart chain, making it the foundational security primitive for any two-way peg involving Liquid-issued assets.
Protocols
Asset Peg-Out and Burn Proofs
Standard for verifiably destroying an issued asset on Liquid, essential for sidechain bridge withdrawals and wrapped token systems. Details the OP_RETURN-based proof format. Bridge operators and wallets must generate and verify these proofs correctly.
introduction
VERIFIABLE DESTRUCTION OF ISSUED ASSETS
Introduction
The Asset Peg-Out and Burn Proofs standard defines how to provably destroy an issued asset on Liquid, a critical primitive for sidechain bridge withdrawals and wrapped token systems.
The standard defines a precise OP_RETURN-based proof format that commits to the asset ID, the burned amount, and a destination identifier on the target chain. Bridge operators, wallets, and exchanges must implement both the generation and verification of these proofs correctly. A failure in proof generation can permanently lock user funds, while a failure in verification can lead to double-spend exploits where a single burn event is used to claim native assets multiple times. The operational integrity of any wrapped asset system on Liquid depends on the deterministic and correct handling of this proof format.
For engineering teams integrating Liquid-based wrapped tokens, the burn proof standard introduces specific reconciliation and monitoring requirements. Operators must track every burn transaction, verify the proof structure against the canonical specification, and maintain a strict one-to-one mapping between burn events and outbound releases. Chainscore Labs can audit burn proof generation logic, review bridge reconciliation systems for race conditions and replay vulnerabilities, and assess the end-to-end security of the peg-out workflow to ensure that asset destruction on Liquid is cryptographically bound to asset release on the target chain.
ASSET PEG-OUT AND BURN PROOFS
Quick Facts
Operational and technical facts about the standard for verifiably destroying an issued asset on Liquid, essential for sidechain bridge withdrawals and wrapped token systems.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Proof Format | A verifiable burn is created using an OP_RETURN output with a specific commitment to the destroyed asset and amount. | Bridge operators, wallet developers, and exchanges. | Implement the exact OP_RETURN parsing and construction logic as defined in the specification. |
Asset Supply | The total circulating supply of an issued asset is permanently reduced by the verifiably burned amount. | Asset issuers, data analytics teams, and investors. | Update supply tracking systems to recognize burn proofs as authoritative supply reduction events. |
Bridge Reconciliation | A burn proof on Liquid must be matched with a corresponding mint or release transaction on a counterpart chain. | Bridge operators and wrapped token issuers. | Build automated reconciliation logic that pairs Liquid burn proofs with external chain events to prevent double-spends. |
Wallet Integration | Wallets must be able to construct burn transactions and display burn proof confirmations to users initiating withdrawals. | Wallet providers and custody platforms. | Add support for constructing OP_RETURN burn outputs and interpreting burn proof confirmations in user interfaces. |
Verification Logic | Third parties must be able to independently verify a burn proof against the Liquid blockchain without trusting the bridge operator. | Auditors, risk teams, and independent watchtowers. | Deploy independent verification services that check burn proof validity and flag any discrepancies in real-time. |
Reissuance Interaction | A burn proof must be checked against the asset's reissuance status to confirm the supply reduction is permanent and cannot be reversed. | Asset issuers and compliance teams. | Verify that the asset's reissuance token has been destroyed or that the issuer's governance prevents reissuance after a burn. |
Confidentiality | Burn proofs for Confidential Assets must commit to the blinded asset and amount, requiring specific zero-knowledge proof validation. | Bridge operators and wallet developers integrating confidential assets. | Implement the confidential burn proof verification logic, ensuring range proofs and blinding factors are correctly handled. |
Emergency Response | An invalid or fraudulent burn proof could lead to an unbacked mint on a counterpart chain, creating a solvency risk. | Bridge operators, security teams, and risk managers. | Establish circuit breakers and multi-signature controls that halt bridge operations if an invalid burn proof is detected. |
technical-context
BURN PROOF CONSTRUCTION AND VERIFICATION
Technical Mechanism
How Liquid asset burn proofs are constructed using OP_RETURN outputs and verified by bridge operators to authorize sidechain withdrawals.
Asset peg-out on the Liquid Network requires a verifiable on-chain proof that issued tokens have been permanently destroyed. The standard mechanism encodes a burn commitment into an OP_RETURN output within a Liquid transaction, creating an immutable record that a specific amount of a specific asset was removed from circulation. This proof is then consumed by bridge operators, watchtowers, or wrapped-token systems to authorize a corresponding release on another chain—most critically, the Bitcoin mainchain for L-BTC peg-outs, but also for any cross-chain asset bridge built on Liquid's Issued Asset standard.
The burn proof format relies on a structured OP_RETURN payload that includes the asset ID being burned, the amount destroyed, and a nonce or commitment to prevent replay attacks. Because Liquid uses Confidential Transactions, the burn transaction must handle both blinded and unblinded data correctly: the OP_RETURN explicitly reveals the burn amount and asset type, while the transaction's confidential outputs prove that the burned tokens are not being redirected elsewhere. Verifiers must check that the sum of inputs and outputs for the burned asset is negative by exactly the committed burn amount, confirming destruction without requiring full balance disclosure. This cryptographic binding is what makes the proof trustless for bridge operators.
Bridge and wallet implementations face several operational risks. A malformed OP_RETURN payload can produce a burn proof that is valid on Liquid but unparseable by the destination chain's verifier, locking funds. Race conditions between burn confirmation and peg-out authorization require careful handling of Liquid's 2-block finality window. Additionally, any bridge system that aggregates multiple burns into a single withdrawal must maintain a strict reconciliation ledger mapping each Liquid burn proof to its corresponding external release. Chainscore Labs can audit burn proof generation logic, verify that reconciliation systems correctly handle edge cases like reorgs or malformed payloads, and assess the end-to-end security of bridge architectures that depend on Liquid asset destruction proofs.
PEG-OUT AND BURN PROOF IMPACT
Affected Actors
Bridge Operators
Bridge operators are the primary implementers of the burn proof standard. They must generate valid OP_RETURN outputs that provably destroy the wrapped asset on Liquid before releasing the native asset on the destination chain.
Critical actions:
- Implement exact OP_RETURN proof format as specified
- Ensure burn transactions are confirmed with sufficient finality before releasing native assets
- Maintain reconciliation systems that match each burn proof to a corresponding native-chain release
- Monitor for reorgs or chain halts that could invalidate burn proofs
Failure modes: Incorrect proof format leads to unverifiable burns. Releasing native assets before Liquid finality exposes the bridge to double-spend attacks. Missing reconciliation gaps can result in insolvency.
Chainscore can audit your burn proof generation pipeline, reconciliation logic, and multi-chain release coordination to prevent these failure modes.
implementation-impact
BURN PROOF VERIFICATION
Implementation Impact
Correct implementation of the Asset Peg-Out and Burn Proof standard is critical for bridge operators, wallets, and exchanges to prevent double-spends and ensure accurate supply reconciliation for wrapped assets.
01
Bridge Operator Reconciliation
Bridge operators must implement deterministic verification of the OP_RETURN burn proof before releasing funds on the counterparty chain. The proof must be validated against the canonical asset id and the exact amount committed to the burn. Failure to verify the nullifier or the asset commitment can lead to double-spend vulnerabilities where a single burn event is processed multiple times. Operators should maintain a strict, append-only registry of processed nullifiers to prevent replay attacks.
02
Wallet Transaction Construction
Wallet software must construct burn transactions that strictly conform to the proof format, including the correct OP_RETURN script structure and the explicit destruction of the asset. Incorrectly setting the output value to zero instead of using a provably unspendable script can result in a transaction that is not recognized as a valid burn by bridge indexers. Wallet developers need to ensure their fee selection logic accounts for the additional OP_RETURN output when building these specific transaction types.
03
Exchange and Custody Monitoring
Exchanges and custody providers integrating wrapped Liquid assets must monitor for burn events to adjust their internal liability ledgers. A peg-out is not complete until the burn proof is confirmed on Liquid and the corresponding release transaction is finalized on the host chain. Integration teams should implement a reconciliation engine that cross-references Liquid burn proofs with inbound transactions on the host chain to detect discrepancies in supply or unauthorized minting events.
04
Indexer and API Data Integrity
Block explorers and data indexers must parse the OP_RETURN output to correctly label burn transactions and update circulating supply metrics. Misinterpreting a burn as a standard transfer will corrupt supply data for asset issuers and DeFi protocols. Indexers should expose a dedicated endpoint for verified burn events, providing the asset id, burned amount, and the nullifier to allow downstream services to efficiently consume and verify peg-out events without re-indexing the entire chain.
05
Audit and Proof Verification
Chainscore can audit the full lifecycle of a burn proof implementation, from the wallet's transaction construction logic to the bridge operator's verification and release module. This includes a review of nullifier uniqueness enforcement, cryptographic validation of the asset commitment, and the resilience of the reconciliation logic against reorgs. A formal verification of the bridge's state machine ensures that a burn proof cannot be processed without a corresponding release or processed more than once.
BURN PROOF VERIFICATION AND BRIDGE OPERATIONS
Risk and Compatibility Matrix
Evaluates the operational risks, failure modes, and integration requirements for systems that generate, verify, or rely on Liquid asset burn proofs for cross-chain bridge withdrawals.
| Area | Failure Mode | Who is affected | Severity | Mitigation and Action |
|---|---|---|---|---|
Burn Proof Generation | Incorrect OP_RETURN payload format or missing required metadata fields | Bridge operators, asset issuers | Critical | Validate output against the canonical burn proof specification. Chainscore can audit proof generation logic. |
Proof Verification Logic | Failure to validate the proof against the Liquid chain state, accepting a forged or replayed burn | Wallets, exchanges, receiving chain bridge contracts | Critical | Implement full SPV or Elements Core-level verification. Do not rely on block explorer APIs. Chainscore can review verification implementations. |
Reissuance Token Handling | Burning an asset without also provably destroying its reissuance token, leaving supply control active | Asset issuers, investors, bridge operators | High | Verify that the burn transaction includes the reissuance token if a permanent supply cap is intended. Audit supply auditability. |
Confidential Transaction Blinding | Inability to independently verify the burned amount due to blinding factors, requiring trust in the bridge operator | Receiving chain validators, independent verifiers | Medium | Require the bridge operator to share the blinding factor or use unblinded outputs for burn transactions. Assess privacy vs. auditability trade-offs. |
Bridge Reconciliation | Discrepancy between burned supply on Liquid and minted supply on the receiving chain due to a race condition or bug | Bridge operators, DeFi protocols using wrapped assets | Critical | Implement continuous on-chain reconciliation monitoring with circuit breakers. Chainscore can design reconciliation logic and alerting systems. |
Peg-Out Interaction | Confusing an asset burn proof with an L-BTC peg-out, leading to incorrect processing by federation members | Exchanges, custody providers | High | Ensure systems distinguish between L-BTC peg-out transactions and Issued Asset burn proofs. Verify transaction types before processing. |
Wallet Integration | Wallet UI incorrectly displays a burn transaction as a standard transfer, misleading users about token destruction | End users, wallet providers | Medium | Parse OP_RETURN outputs to identify burn transactions and display a clear, distinct confirmation screen. Review UI for accurate transaction semantics. |
Compliance Rule Conflicts | An asset with active transfer restrictions preventing the burn transaction from being included in a block | Issuers, compliance teams, bridge operators | Medium | Verify that burn addresses or OP_RETURN outputs are exempt from issuer-enforced whitelist/blacklist rules. Test compliance interaction in a staging environment. |
BURN PROOF VERIFICATION
Operator Implementation Checklist
A technical checklist for bridge operators, wallet providers, and exchange teams to correctly generate, verify, and reconcile Asset Peg-Out and Burn Proofs on the Liquid Network. Each item identifies a critical integration point, the operational risk it mitigates, and the signal that confirms readiness.
Verify that the burn transaction contains a valid OP_RETURN output with the exact asset identifier and a zero-value commitment. The proof must cryptographically commit to the specific asset being destroyed, preventing replay or misidentification of the burned asset.
- What to check: Parse the
OP_RETURNdata to extract the 32-byte asset ID and confirm it matches the expected issued asset. Validate that the output value is provably zero using the range proof or explicit value field. - Why it matters: An incorrect asset ID in the proof allows an attacker to claim a peg-out for a different asset. A non-zero value indicates a flawed burn, breaking the supply peg on the destination chain.
- Readiness signal: Your parser correctly rejects a burn proof with a mismatched asset ID and a proof with a non-zero amount commitment.
resource-links
LIQUID NETWORK REFERENCES
Source Resources
Canonical resources for implementing and verifying Asset Peg-Out and Burn Proofs on Liquid. Teams should confirm the applicable LIP status, proof encoding, transaction behavior, and confirmation policy before accepting a burn as authorization for a cross-chain release.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
BURN PROOF IMPLEMENTATION
Frequently Asked Questions
Common questions from bridge operators, wallet developers, and auditors implementing and verifying asset burn proofs on Liquid.
A burn proof is a standard Liquid transaction that provably destroys an issued asset. The canonical format requires:
- OP_RETURN output: Contains a protocol-specific marker and the asset ID being burned.
- Zero-value output: The burned asset amount is sent to an unspendable script or a provably burned output, reducing the total supply.
- No reissuance: The transaction must not create new tokens of the same asset.
Bridge operators should verify the exact OP_RETURN payload structure against the LIP specification. A common pattern is OP_RETURN <burn_marker> <asset_id>, but the marker byte and encoding must match the canonical standard. Incorrect formatting can cause the burn to be rejected by downstream verifiers or indexers.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.