Rootstock Co‑Founder Urges Mandatory Time‑Delay Locks for Bitcoin Bridges

Sergio Lerner, co‑founder and chief scientist of Rootstock Labs, has called for Bitcoin bridge operators to adopt mandatory time‑delay locks on withdrawals. He argues that a delay would give bridge operators several hours to detect and halt unauthorized peg‑outs, preventing a single software bug from turning into a total loss.

Recent Liquid Network Incident

Approximately 4,000 BTC left the Liquid Network federation wallet after actors created unbacked L‑BTC and used SideSwap’s peg‑out service. SideSwap processed the request because the L‑BTC appeared valid. After Blockstream patched the affected bridge nodes, the actors returned about 3,400 BTC, leaving roughly 598 BTC still outstanding. Liquid resumed block production but did not restore peg operations as of September 10.

How a Time‑Delay Lock Works

Lerner explains that a mandatory delay would start after the first software validation, pausing the actual Bitcoin transfer for a set period. During this window, automated monitoring tools could compare the requested peg‑out with the BTC backing the L‑BTC and flag any imbalance before settlement.

Rootstock’s Existing Delay Mechanism

Rootstock already enforces a 4,000‑block (≈36 hours) delay on BTC withdrawals through its two‑way peg. The delay is enforced by specialized hardware security modules (PowHSMs) that keep private keys inside the device and only sign a peg‑out after the required number of Rootstock blocks have elapsed. Even if functionaries are compromised, they cannot force an early withdrawal; they can only pause the process.

Distributed Revocation Controls

Lerner stresses that no single entity should control the ability to pause withdrawals. Instead, independent functionaries should share revocation authority through a multiparty structure, with hardware‑enforced limits that prevent redirection of funds.

Potential Protocol‑Level Solutions

To move the delay control into Bitcoin’s consensus rules, Lerner points to draft BIP‑443, which proposes an opcode (OP_CHECKCONTRACTVERIFY) that would allow outputs to carry spending conditions, including time‑based restrictions. Such a change would require a soft‑fork and could enable native Bitcoin vaults to enforce withdrawal delays without relying on bridge‑specific hardware policies.

Balancing Security and Usability

A uniform 36‑hour delay may be unsuitable for routine payments. Lerner suggests that delay periods could be scaled based on transaction size or risk profile, with shorter windows for low‑value transfers and longer ones for high‑value bridge withdrawals.