Why transactions on Liquid Network get stuck and lost
In the Bitcoin sidechain Liquid Network, blocks are signed not by a miner but by a federation of signatories — a distributed group of nodes, each independently validating a set of transfers.
Until the required number of participants has signed, the block is not assembled, and the transfer remains in pending status: in the wallet it looks like a stuck transaction, although the network is formally operating.
There are usually three causes. Node desynchronization — some participants have fallen behind in block height and see a different set of transfers than the others.
Incomplete set of signatories — a node has dropped out of rotation or lost a key, and the vote threshold cannot be reached. Manual reconciliations — discrepancies are closed via correspondence and spreadsheets rather than automation, so the transfer hangs for hours.
Lost confirmations are a separate class of failures. The accounting system considers a transfer complete without waiting for finality, and when the block branch changes, the record changes.
The balance discrepancy between participants surfaces later, during reconciliation, and has to be sorted out manually.
The cost of an error is not only delay: a participant loses trust in the settlements, and the business process stalls while the incident is investigated.
Below we break down how these failures are closed at the level of node configuration, federation state monitoring, and the confirmation policy.
What asset issuance and settlements on a Bitcoin sidechain provide
Asset tokenization begins not with code but with issuance rules: who has the right to manage emission, what limits apply, under what conditions the holder exchanges the asset for base Bitcoin.
These rules are fixed in the asset itself, so partners no longer need to trust each other's statements — both sides read the same registry state.
Next, asset issuance on the Liquid Network sidechain fits into a predictable timeline. Emission, transfer of rights, and redemption are transactions with confirmation in several blocks, not instructions waiting for an operational window to open. Settlements run around the clock, so a trade closes on the same day the parties agree.
- Coordination — we describe the roles of signatories, issuance limits, and the procedure for exchanging the asset for base Bitcoin.
- Issuance — the asset is issued against collateral; the volume and recipient are visible to participants immediately.
- Settlement — the parties exchange the asset and collateral in a single transactional model, with no intermediary in the middle.
- Reconciliation and redemption — the registry state matches for both parties; manual reconciliations remain only for external accounting systems.
What this changes in the metrics: settlement time is reduced from days to hours, the share of automated reconciliations reaches one, and the failure class "settlement stuck due to participant unavailability" goes away — the network enforces the rules, not a duty operator.
Comparison of network modes: open and closed perimeter
The operating mode determines who sees operations, who has the right to issue assets, and on what set of nodes consensus rests. The choice depends on the number of participants, their willingness to disclose turnover to each other, and the need for external liquidity. Below are three operating modes of Liquid Network that are chosen between when connecting.
| Option | When it fits | Limitations |
|---|---|---|
| Open network mode | Public asset issuance, settlements with external counterparties, access to exchange liquidity | Amounts and asset type are hidden, but the fact, time, and address links are visible to an observer |
| Closed perimeter of signatories | Settlements within a group of companies or a club of participants where everyone is known and admitted | Consensus rests on a trusted set: unavailability of some signatories stops the network, and there is no external liquidity |
| Hybrid scheme | A private settlement perimeter plus a public one for market access | More expensive to maintain: accounting and balances are reconciled between two perimeters, and auditing is more complex |
The open mode is compatible with external wallets and custodial services with almost no modifications — it is suitable when settlements include counterparties you do not control.
The closed perimeter requires every participant to run a node and pass an admission procedure; but the perimeter is known, and operations do not leave the group.
We discuss confidentiality limitations before the start: in both modes, amounts and asset type are hidden, but the signatories of the perimeter see the fact of the operation itself and its participants.
If you need to hide that as well, a different architecture will be required — we analyze such requirements at the compatibility stage, not after launch.
Implementation stages: from requirements audit to launch
We structure the work so that infrastructure and issuance decisions are made before the first launch on the main network: first a requirements audit and a pilot on the test network, and only then access for real participants. Each stage is closed with an artifact that the customer can verify.
- Infrastructure audit — we inspect servers, network, and communication channels between sites, determine where to place nodes and what disk and bandwidth headroom is needed for growing transaction volume.
- Role and key scheme — we fix who signs issuance, who performs settlements, how keys are distributed among custodians, and what happens if one of them drops out.
- Node setup — we raise instances, connect them to peers, bring synchronization to a stable state, set up monitoring and a backup node so that one failure does not stop operations.
- Asset issuance preparation — we agree on asset parameters, decimal precision, lock and reissuance rules, and assemble the configuration for a specific settlement scenario.
- Asset issuance — we conduct emission in the test perimeter, verify distribution against the custodians' registry, then repeat on the main network.
- Settlement testing — we run receiving and sending, partial signing, locking and unlocking, recovery after a connection loss; we record the result for each scenario.
- Handover and training — we provide documentation and policies, train your team in routine operations, and stay in touch for incident analysis.
Access policies, keys, and asset issuance schemes
A project is considered delivered not at the moment the node has synchronized, but when the operations team issues an asset, adds a signatory, and restores access without us.
Therefore, along with the deployed infrastructure, the customer receives a set of artifacts — from configurations to policies.
- Access policies — a role matrix with separation into issuance, confirmation, and read access: what is available to the issuing node, what to the observer wallet, which operations require a second signature.
- Signatory key scheme — the signature threshold for issuance and reissuance, the set of holders, the procedure for issuing keys, and rules for storing backups offline.
- Asset issuance scheme — the step-by-step procedure for emission: wallet preparation, transaction formation, confirmation by holders, linking the reissuance token to subsequent emissions.
- Node configurations — settings files with comments: which parameters affect indexing, connection limits, and history retention depth.
- Maintenance policy — what is checked and how often, how scheduled updates are applied, how a restart is performed without stopping issuance.
- Backup and recovery — the composition of backups, the procedure for bringing up a node in a clean environment, and integrity verification of state after recovery.
- Key rotation and revocation — removing a signatory from the scheme and replacing a key upon compromise without rebuilding the asset.
- Node documentation — service map, network diagram, monitoring and alerting points, infrastructure change log.
Such a set removes dependence on the contractor: issuance, rotation, and recovery remain on your side.
Implementation case study: settlement metrics before and after
A settlement perimeter of four participants — a broker, a custodian, a market maker, and a clearing department — closed a trade in nine steps.
Limit confirmation, manual reconciliation of instructions, statements, repeated confirmation: from instruction to settlement took about two business days, and amount discrepancies surfaced only after clearing — up to 12 cases per month, each handled via email and spreadsheets.
We moved liability accounting into Liquid Network: assets are issued digitally, addresses are secured by multisignature, and trade amounts are unavailable to external observers.
Reconciliation was linked by a single trade identifier — the same one in the instruction, in the transaction, and in the statement, so a discrepancy is visible at the moment of recording, not a day later.
Metrics before and after
Settlement time was reduced from two business days to tens of minutes: confirmation arrives in one round instead of correspondence. Reduction in manual operations is about 90%: only exceptions remain, such as rejected limits and non-standard fees.
Discrepancies at the end of the quarter — zero versus the previous 12 per month, and analyzing each one no longer takes the settlement team's time.
We separately closed the audit issue: the log stores the identifier and recording time of the trade; counterparty amounts do not enter it. Such an implementation case study is repeatable — the logic transfers to new asset pairs without rewriting the settlement perimeter.
How is Liquid Network different from Bitcoin's main layer?
Bitcoin's main layer holds BTC itself and security through miners.
Liquid Network is an independent network with its own consensus that does not replace the main layer but extends it: the BTC collateral remains on Bitcoin's main layer, while operations take place in the sidechain via a two-way peg.
Settlement speed differs by an order of magnitude. Blocks in the sidechain are produced frequently and at a predictable interval, confirmation takes seconds, and the fee does not participate in an auction for block space when the main layer is congested.
For a stream of small operations — payouts, settlements between counterparties — this changes the architecture of the entire service.
Confidentiality is designed differently. Transactions hide the amount and asset type from third-party observers, but the sender's and recipient's addresses remain visible: this is settlement privacy, not participant anonymity. A fully hidden graph of links cannot be built on a single sidechain.
The composition of signatories is the main difference of the sidechain.
Blocks are produced by federation functionaries, BTC withdrawals are controlled by multisig custodians with linked collateral, meaning trust shifts from miners' computational power to a predetermined circle of operators. Hence the requirements for signature thresholds, rotation, and public reporting.
Asset separation is simple: issuance and circulation of tokenized assets, frequent trading, and emission move to the sidechain, while BTC itself and final settlement remain on the main layer.
Transferring assets between layers requires locking and issuance with federation confirmations, limits, and a withdrawal delay, so the return path is always longer than an internal transfer.
Technical questions: fees, confidentiality, rollbacks
Technical doubts about integration with Liquid Network usually come down to four questions: what an operation costs, who sees the amounts, what happens during a failure, and what backs issued assets. Below are short answers; we analyze the details at the design stage.
How are fees calculated in Liquid Network?
The fee is paid in L-BTC, tied to transaction weight, and does not depend on current load: blocks are produced by signatories at a constant interval. There is no auction for block space, so the cost of an operation is predictable and is built into the service tariff in advance.
How confidential are transactions?
Amounts and asset type are hidden — the chain shows inputs, outputs, and the fact of the transfer itself. The blinding key is passed to the counterparty and can be presented to an auditor to analyze a single operation without revealing the wallet's entire history.
Is a transaction rollback possible?
A confirmed transfer becomes irreversible. Therefore the address is validated before sending, limits and multisignature are set, and the exchange logic includes a time-lock branch — it returns funds if the second party has not completed the trade.
What backs issued assets?
Each such asset is emitted against the base asset and backed 1:1: the issuer holds a reserve, and the audit key allows verifying emission volume against actual coverage. L-BTC itself is backed by Bitcoin locked on the main network through the federation of signatories.
Let's discuss the task: we'll select the mode and node composition
Assessing the scope of work begins not with choosing technologies but with the system boundaries: what exactly is issued, who holds the keys, and what level of fault tolerance is needed.
Below are the inputs sufficient to discuss the task substantively and come back with an implementation plan, rather than general considerations.
- description of the asset and issuance logic: what is emitted, under what conditions, who confirms operations;
- desired node composition: your own full node, a light node, or only one observing network state;
- deployment perimeter: public network or an isolated environment with a predetermined circle of participants;
- key access model: hardware storages, multisignature, separation of roles between employees;
- availability and recovery requirements: acceptable downtime and the procedure for returning after a failure;
- integration points with existing systems: accounting perimeter, internal services, analytics;
- data disclosure constraints: to whom and to what extent the history of operations is visible.
From these answers, an implementation plan is assembled: first we bring up the Liquid Network perimeter and check synchronization, then we put the asset into circulation with a limited circle of participants, then integrations and monitoring.
We assess the scope of work for each stage separately, so the project can be paused at any step without losing what has already been done. Describe the task in free form — we will come back with an estimate and plan.