His comments followed an incident in which actors created unbacked L-$BTC and used SideSwap’s peg-out service to withdraw nearly 4,000 $BTC from the Liquid Federation wallet. Liquid described the actors as purported white-hat hackers, while SideSwap said its service processed the request because the L-$BTC appeared valid.
The actors later returned 3,400 $BTC after Blockstream confirmed that affected bridge nodes had been patched. About 598 $BTC remained outstanding, while Liquid resumed block production without restoring transactions or peg operations as of Sep. 10.
A time-delay lock could have created an intervention window
Lerner said a mandatory delay between the creation of the unbacked L-$BTC and the release of real $BTC could have reduced the damage.
Under such a system, software approval would start a waiting period rather than complete the withdrawal. Automated monitoring tools could compare the requested peg-out with the $BTC backing L-$BTC and flag any imbalance before settlement.
“If Liquid had possessed a time-delay lock — where funds cannot move for a specified period regardless of what the software or operators say — the bug would have resulted in a manageable incident rather than an immediate, full-scale catastrophe.”
According to Lerner, the delay would have given operators a multi-hour response window after the unbacked tokens were created. Monitoring systems running around the clock could have detected that the peg-out passed the first software checks despite lacking corresponding collateral.
Functionaries could then have paused the peg before the hardware signed the transaction or released $BTC from the federation wallet, he added.
Liquid’s system did not report a stolen Peg-out Authorization Key. SideSwap said a customer sent 4,000 L-$BTC to its peg-out service, which handled the request under its normal process because the tokens could not be distinguished from backed L-$BTC. The federation paid 3,996 $BTC to the supplied Bitcoin address about 23 minutes later.
Lerner’s proposal would place an additional control after the first validation stage. Even if software mistakenly approved a withdrawal, the delay would prevent the corresponding $BTC from leaving immediately.
Rootstock enforces a 4,000-block Bitcoin withdrawal delay
Rootstock already uses a delay mechanism for $BTC withdrawals through its two-way peg, although Bitcoin’s consensus rules do not enforce the waiting period.
The system relies on specialized hardware security modules called PowHSMs. Before signing a peg-out, the devices independently verify that 4,000 Rootstock blocks have passed, representing about 36 hours of cumulative proof-of-work.
Private keys remain inside the devices, according to Lerner, and functionaries cannot instruct the hardware to bypass the required period. Rootstock combines the HSM rules with merge-mining, through which Bitcoin miners contribute proof-of-work to the sidechain.
“Even a colluding majority of pegnatories cannot steal the funds, because the private keys never leave the PowHSMs, and the HSMs independently verify that 4,000 Rootstock blocks have elapsed before they will sign,” Lerner said.
Rootstock’s model assumes that a majority of the Bitcoin hash rate participating through merge-mining and the federation functionaries will not work together to halt the network. Lerner said compromised functionaries could interrupt peg operations, creating a liveness problem, but the HSM rules would prevent them from forcing an unauthorized early withdrawal.
When monitoring tools identify suspicious activity, functionaries can switch off their HSMs so that the pending peg-out receives no signature. Lerner described the pause as a way to protect the underlying $BTC while operators examine the problem and decide how to proceed.
“A colluding majority can, at worst, halt the peg, but they cannot force an unauthorized withdrawal,” he said.
Distributed revocation controls could limit freezing powers
Stopping a pending withdrawal introduces another risk because the same power could be used to delay legitimate users. Lerner said no single company, operator, or administrator should control the revocation mechanism.
Instead, independent functionaries should share the authority through a multiparty structure, with hardware rules limiting what they can do. Under his proposed model, functionaries could pause processing but could not redirect the $BTC to another address or confiscate it.
“To prevent single points of failure or centralized censorship, revocation controls should be distributed among independent, multi-party functionaries using hardware-enforced rules rather than centralized administrative keys.”
Such controls would still allow a group of functionaries to interrupt withdrawals if enough participants acted together. Lerner’s distinction rests on the scope of that authority: operators could temporarily withhold signatures while an anomaly is reviewed, but they could not create a valid transaction that transfers the collateral to themselves.
Time delays would also need to account for the value and purpose of each transaction. A 36-hour wait may be unsuitable for routine payments, while a bridge holding large amounts of $BTC has a different risk profile.
Lerner said high-value settlement systems should treat time as a security control, similar to the delay mechanisms used by physical bank vaults. Withdrawal periods could vary by transaction size or require different cumulative proof-of-work thresholds according to the collateral at risk.
A shorter period could apply to smaller transfers, while a longer delay could give automated systems and human responders more time to inspect an unusually large request. Lerner did not prescribe one delay for every bridge, but cited Rootstock’s 4,000-block requirement as an effective period for infrastructure securing large $BTC balances.
Native Bitcoin vaults could place safeguards in consensus
Rootstock’s current protection depends on its HSMs and federation rather than rules enforced by the Bitcoin network. Lerner said native Bitcoin vaults and revocation keys could move comparable controls into the base protocol.
One possible building block is BIP-443, a draft proposal for an opcode called OP_CHECKCONTRACTVERIFY, or OP_CCV. The proposal would let a Bitcoin output carry data and restrict how its funds may move through future transactions.
BIP-443 describes OP_CCV as a consensus change requiring a soft fork. Its listed uses include state-carrying Bitcoin outputs, sidechains, and two-step withdrawal structures that allow reactive security. The proposal remains in draft status, and its activation process has not been determined.
Lerner cited OP_CCV and BIP-443 as examples of how native vaults could give users or designated parties time to cancel a withdrawal after detecting stolen credentials, altered software, or another abnormal event.
Moving the mechanism into Bitcoin consensus would reduce reliance on bridge-specific HSM policies, according to Lerner. Miners, functionaries, or administrators would have to follow the spending conditions attached to the Bitcoin output rather than apply a discretionary pause after funds had already moved.
For large bridge withdrawals, Lerner said the delay should last long enough for automated alerts and human operators to identify the problem, stop processing, and examine the affected software before the $BTC becomes permanently spendable by the recipient.
