The Liquid Network's peg mechanism relies on the federation to observe Bitcoin mainchain transactions and create corresponding L-BTC on the Liquid sidechain. If the federation fails to process a peg-in—due to member downtime, signing key issues, or a software bug—the user's Bitcoin is effectively locked in the federation's multisig without the expected L-BTC being issued. A watchtower independently monitors the Bitcoin blockchain for peg-in transactions and verifies that each one results in a corresponding claim transaction on Liquid within an expected time window. This provides a critical second layer of assurance that does not depend on the federation's own monitoring.
Protocols
Running and Monitoring a Liquid Watchtower
An operational guide for infrastructure providers and large peg users to set up, run, and monitor a Liquid watchtower. Covers Bitcoin node requirements, federation activity monitoring, alerting for delayed pegs, and redundancy planning to ensure timely peg-in processing.
introduction
PEG-IN SECURITY AND OPERATIONAL ASSURANCE
Why Run a Liquid Watchtower?
A Liquid watchtower is an independent monitor that ensures peg-in transactions on the Bitcoin mainchain are correctly claimed on the Liquid sidechain, protecting users from federation liveness failures.
Running a watchtower requires a fully synced Bitcoin Core node and an Elements Core node connected to the Liquid network. The watchtower software continuously scans new Bitcoin blocks for transactions sending funds to the federation's peg-in addresses, records the expected amount and destination, then watches the Liquid chain for the matching claim_peg transaction. If a peg-in remains unclaimed beyond a configurable threshold—typically 10 to 20 Liquid blocks—the watchtower triggers an alert. This alerting capability is essential for exchanges, custody providers, and large L-BTC holders who need to detect peg processing delays before they escalate into extended fund lockups or require manual intervention.
The operational burden of a watchtower is moderate but non-trivial. It requires maintaining two full nodes with high uptime, managing storage for the Bitcoin and Liquid blockchains, and ensuring the alerting pipeline is reliable. Teams should implement redundancy by running at least two watchtower instances in different physical or cloud environments to avoid a single point of failure in their monitoring. The watchtower does not have the ability to unilaterally claim pegs—it is a read-only monitor—so there is no key material to protect. However, the Bitcoin node must be configured to index transaction outputs or maintain a sufficiently large UTXO set to reliably detect all peg-in patterns.
For infrastructure providers and large peg users, a watchtower transforms peg-in risk from a blind trust assumption into a measurable, alertable operational parameter. Chainscore Labs can assist teams in designing watchtower deployment architectures, integrating alerting with existing incident response pipelines, and conducting readiness reviews to ensure that peg monitoring covers all federation address types and edge cases such as reorgs or fee underpayment on the claim transaction.
OPERATIONAL DEPENDENCIES AND FAILURE MODES
Watchtower Quick Facts
A reference table for infrastructure teams to identify critical components, failure modes, and required actions for running a reliable Liquid watchtower.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Bitcoin Full Node | Must maintain a consistent, unpruned view of the Bitcoin mainchain to detect peg-in transactions to the federation multisig. | Watchtower operators | Provision a dedicated bitcoind node with txindex=1. Monitor for chain tips, re-orgs, and stale blocks. |
Federation Multisig Script | The composition of the Liquid federation multisig can change via a key ceremony. The watchtower must monitor the correct, current redeem script. | Watchtower operators, L-BTC holders | Implement a script to dynamically fetch the current federation multisig from the Liquid chain or a trusted source. Do not hardcode. |
Claim Transaction Broadcast | A peg-in is not complete until the corresponding claim transaction is confirmed on the Liquid sidechain. The watchtower is responsible for this broadcast. | L-BTC users executing pegs, exchanges | Automate the construction and broadcast of the claim transaction to a Liquid node. Implement retry logic with fee bumping for stuck transactions. |
Federation Activity Monitoring | If the federation is not signing blocks or processing peg-ins, the watchtower's claim transactions will not be confirmed, leading to a peg backlog. | Watchtower operators, all Liquid users | Monitor Liquid block production and the number of unconfirmed peg-in claims. Alert if block time exceeds 2 minutes or if a peg-in is unclaimed for more than 10 blocks. |
Redundancy and Failover | A single watchtower instance is a critical point of failure. If it goes down, user peg-ins will be delayed indefinitely. | Watchtower operators, exchanges, large peg users | Run multiple, geographically distributed watchtower instances. Use a coordination mechanism or leader election to prevent duplicate claim broadcasts. |
Alerting Logic | Delays in peg processing can be caused by Bitcoin congestion, Liquid federation issues, or watchtower software bugs. Undifferentiated alerts cause alert fatigue. | Watchtower operators, on-call engineers | Create distinct alerts for: 1) Bitcoin node out of sync, 2) Unclaimed peg-in detected, 3) Liquid node out of sync, 4) Claim transaction broadcast failure. Verify thresholds against canonical sources. |
Private Key Security | The watchtower's Liquid private key is used to sign claim transactions. Compromise could lead to theft of user funds during the peg-in process. | Watchtower operators, L-BTC users | Secure the key in a production-grade secrets manager (e.g., HashiCorp Vault) or an HSM. Restrict network access to the signing service. Do not store keys on the watchtower instance disk. |
technical-context
OPERATIONAL DEPENDENCY
Peg-in Lifecycle and the Watchtower's Role
The watchtower is the final, time-sensitive step in the Liquid peg-in process, converting a Bitcoin mainchain confirmation into a claim on the sidechain.
A Liquid peg-in is not a single transaction but a multi-stage lifecycle that begins on the Bitcoin mainchain and concludes on the Liquid Network. A user initiates the process by sending BTC to a federation-controlled multisig address. Once this transaction receives sufficient Bitcoin confirmations, the federation members observe it and collectively sign a corresponding Liquid transaction that issues an equivalent amount of L-BTC. The watchtower's role is to independently verify this entire chain of events and broadcast the final, federation-signed claim transaction to the Liquid Network, completing the peg-in.
The operational risk lies in the gap between the federation's signing event and the claim transaction's inclusion in a Liquid block. The federation signs the transaction but does not broadcast it; this responsibility is delegated to the watchtower. If a watchtower fails to broadcast the signed transaction, the peg-in stalls indefinitely, and the user's L-BTC remains unissued despite the BTC being locked on the mainchain. This design creates a hard dependency: a functioning, well-connected watchtower with an up-to-date view of the Bitcoin chain is required for peg-in finality. Operators must monitor for federation signing events and ensure their watchtower's Liquid node is synced and connected to successfully relay the claim.
For exchanges, custodians, and large peg users, this lifecycle demands active monitoring rather than passive trust. A delayed or missed broadcast can lock significant capital and erode user confidence. Infrastructure teams should implement redundancy by running multiple watchtower instances and configure alerting on the time delta between a federation peg-in signing event and the corresponding Liquid block inclusion. Chainscore Labs can review your watchtower architecture, assess failure modes in your broadcast relay logic, and help design monitoring systems that ensure timely peg processing.
ACTOR-SPECIFIC OPERATIONAL REQUIREMENTS
Who Should Operate a Watchtower?
Exchanges & Custodians
For platforms holding customer L-BTC, operating a watchtower is a critical risk control, not an optional optimization. A missed peg-in claim directly results in a liability for user funds that the platform must cover.
Operational Requirements:
- Run a dedicated, high-availability Bitcoin node with transaction indexing to ensure no peg-in transaction is missed.
- Maintain a hot wallet on the Liquid side with sufficient UTXOs to batch-claim pegs without delay.
- Implement multi-layer alerting: if a recognized peg-in UTXO remains unspent on Liquid after 1 confirmation, trigger an engineering escalation.
Chainscore Labs can review your peg-in monitoring architecture to ensure it meets the latency and reliability standards required for institutional custody.
implementation-impact
WATCHTOWER OPERATIONAL MODEL
Core Architecture and Workflow
A Liquid watchtower independently monitors the Bitcoin mainchain for peg-in transactions and broadcasts the corresponding claim transactions on the Liquid sidechain, ensuring users receive their L-BTC without trusting the federation to act promptly.
03
Claim Transaction Broadcasting
After detecting a valid peg-in, the watchtower must connect to a Liquid node to broadcast the claim transaction. This transaction requires specific fields from the Bitcoin transaction, including the block height, merkle proof, and raw transaction data. The watchtower must handle network latency, Liquid node availability, and transaction fee estimation to ensure timely confirmation. Redundant Liquid node connections are recommended to prevent broadcast failures during network congestion.
04
Reorg and Fork Handling
Bitcoin mainchain reorganizations can invalidate a previously confirmed peg-in transaction. The watchtower must detect reorgs by monitoring block depth and chain work, then re-evaluate the status of recent pegs. If a peg-in is orphaned, any corresponding claim transaction on Liquid may become invalid. Operators should configure a confirmation depth threshold before broadcasting claims to balance speed against finality risk, typically waiting 2-6 Bitcoin blocks.
05
Redundancy and Failover Planning
A single watchtower instance is a critical point of failure for peg-in processing. Infrastructure teams should deploy multiple geographically distributed watchtowers with independent Bitcoin and Liquid node backends. Each instance should have separate alerting and health-check endpoints. Coordination mechanisms must prevent duplicate claim broadcasts while ensuring at least one instance processes each peg. Consider running a watchtower in a different hosting environment than the primary Liquid infrastructure.
06
Alerting and Operational Metrics
Operators must configure alerting for: missed peg-in detections, claim transaction broadcast failures, Bitcoin node desynchronization, Liquid node connectivity loss, and unexpected federation multisig activity. Key metrics to monitor include peg-in detection latency, claim confirmation time, and the backlog of unprocessed pegs. Integrate these alerts into existing infrastructure monitoring stacks like Prometheus and Grafana. Delayed peg processing can erode user trust and signal federation operational issues.
WATCHTOWER FAILURE MODES AND MITIGATIONS
Operational Risk Matrix
Identifies key operational risks for Liquid watchtower deployments, their failure modes, affected stakeholders, and required actions to ensure timely peg-in claim processing.
| Risk Area | Failure Mode | Who is affected | Severity | Mitigation |
|---|---|---|---|---|
Bitcoin Node Sync | Watchtower falls behind the Bitcoin chain tip and misses a peg-in transaction in a newly confirmed block. | Peg-in users, exchanges, large L-BTC holders | High | Run redundant Bitcoin nodes with diverse network paths. Implement alerting on block height lag exceeding 2 blocks against multiple public explorers. |
Federation Multisig Monitoring | Watchtower fails to detect a new peg-in because the federation's multisig address derivation or script monitoring logic is incorrect. | Peg-in users, watchtower operators | Critical | Verify multisig script parsing against the canonical Liquid federation parameters. Run a periodic test peg-in of a dust amount to validate end-to-end detection. |
Claim Transaction Broadcast | Watchtower constructs an invalid claim transaction or fails to broadcast it due to insufficient fees, network partition, or node rejection. | Peg-in users, exchanges | Critical | Pre-validate constructed transactions against a local Elements node. Implement a dynamic fee bumping strategy and broadcast via multiple redundant Elements nodes. |
Federation Activity Lag | The Liquid functionaries are slow to sign the peg-in claim, and the watchtower does not escalate or alert on the delay. | Peg-in users, exchanges, custody providers | Medium | Monitor the time delta between peg-in detection and the appearance of the corresponding Liquid transaction. Alert if the delay exceeds a threshold (e.g., 10 minutes). |
Key Management | The watchtower's Liquid private key used to authorize claim transactions is lost or compromised. | Watchtower operator | Critical | Secure the key in an HSM or a robust KMS. Ensure the key is included in the operator's standard disaster recovery and backup procedures alongside other Liquid integration keys. |
Reorg Handling | A Bitcoin chain reorganization invalidates the block containing the peg-in transaction after the watchtower has already broadcast a claim. | Watchtower operator, peg-in user | Low | Implement a confirmation depth requirement (e.g., 6 blocks) before broadcasting the claim transaction. Monitor for deep reorgs and implement a reconciliation process. |
Resource Exhaustion | Watchtower runs out of disk, memory, or network resources, causing a silent failure in monitoring or broadcasting. | Watchtower operator, peg-in users | Medium | Implement system-level monitoring for CPU, RAM, disk I/O, and bandwidth. Set up automated restart procedures and a secondary standby watchtower instance. |
OPERATIONAL READINESS
Watchtower Deployment and Monitoring Checklist
A practical checklist for infrastructure teams to validate the deployment, redundancy, and monitoring of a Liquid watchtower. Each item defines the verification step, its operational significance, and the signal that confirms readiness.
What to check: Verify that the watchtower's backing Bitcoin Core node is fully synced with the Bitcoin mainchain and maintains a healthy peer count.
Why it matters: The watchtower must observe peg-in transactions on the Bitcoin chain to trigger the corresponding claim transaction on Liquid. A stalled or forked Bitcoin node will cause missed peg-ins and fund delays.
Confirmation signal: The node's getblockchaininfo RPC call returns "verificationprogress": 1.0 and "headers" equals "blocks". The getnetworkinfo call shows a stable peer count above the minimum configured threshold.
resource-links
OPERATOR REFERENCES
Canonical Resources
Use these sources to verify Liquid peg mechanics, deploy compatible node infrastructure, and distinguish independent monitoring from federation-authorized peg processing. Confirm production parameters and release requirements against current upstream documentation before changing automation.
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.
WATCHTOWER OPERATIONS FAQ
Frequently Asked Questions
Answers to common operational questions for teams running a Liquid watchtower to monitor Bitcoin mainchain peg-ins and ensure timely claim transactions on the Liquid sidechain.
A watchtower's core dependency is a fully synced, non-pruning Bitcoin Core node with transaction indexing enabled (txindex=1). This is required to efficiently look up any historical peg-in transaction by its txid and to rescan for missed transactions if the watchtower process restarts.
Key requirements:
- Full blockchain history: The node must store the complete chain to verify any peg-in, not just UTXOs.
- RPC access: The watchtower process needs consistent, low-latency JSON-RPC access. Avoid rate-limiting proxies.
- ZMQ notifications: Enable
zmqpubrawtxandzmqpubrawblockfor real-time push notifications instead of polling, which reduces the risk of missing a peg-in between block scans. - Redundancy: A single node is a single point of failure. Run at least two independent Bitcoin nodes, ideally on different hosts or cloud providers, to feed the watchtower logic.
Why it matters: If the Bitcoin node is pruned, lags behind the chain tip, or has indexing disabled, the watchtower may fail to detect a peg-in transaction. This directly risks a delayed or missed claim on Liquid, potentially locking user funds until manual intervention.
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.