Liquid Network: 4,000 BTC drained through an Elements bug

What happened

The mechanism. Liquid is a Bitcoin sidechain. Users deposit bitcoin (peg-in) and receive L-BTC; conversely, a peg-out burns L-BTC and releases bitcoin on the main chain from the federation wallet. The core invariant is simple: there must never be more L-BTC than bitcoin in reserve.

September 6. A bug in Elements made it possible to create L-BTC with no real bitcoin behind it. Those tokens were then converted through a peg-out using SideSwap's peg-out authorization key. According to published reports, neither that key nor SideSwap's systems were compromised: the problem lay upstream, in token creation. Blockstream, which provides Liquid's technology, did not detail the flaw. The network was paused.

September 7. The two sides communicated through messages embedded in transactions. The group demanded that the flaw be fixed and the nodes updated before returning anything. Blockstream answered with a signed message confirming the fix on its bridge nodes. A transaction carrying a PGP-encrypted message preceded by 38 minutes the return of 3,400 BTC to the federation's address.

Afterwards. About 598.5 BTC were not returned. Blockstream prepared a coordinated restart and asked users not to send funds to peg-in addresses until then. Other assets issued on Liquid (USDT, DePix) were not affected. Ledger's CTO described the episode as extortion rather than responsible disclosure.

The flaw, without the crypto vocabulary

A component responsible for guaranteeing a security property ("every token is backed by a bitcoin") had a defect that let that property be broken. The rest of the system trusted the component and did not verify the property independently. The loss was counted in hours, long before any human review could have caught it.

The same pattern exists in ordinary SaaS products:

• a credits, points or voucher system that can top up a balance with no matching payment;
• a billing module that issues a credit note without an original invoice;
• a token library that issues valid tokens without checking identity;
• a wallet or payment account whose displayed balance is never reconciled with actual funds.

The Coldcard incident and the xz-utils backdoor belong to the same family: the guarantee rested on a building block nobody rechecked.

How to test it in your product

1. Write down the invariants: list the properties that must never be broken (sum of balances equals funds collected, tokens issued equal deposits, no credit without an originating transaction).
2. Check them independently: write a reconciliation query that computes each invariant from raw data, without going through business code. Run it read-only against production.
3. Find the creation paths: list every endpoint, job and admin script that creates or increases a balance. For each one, check that it requires a counterpart.
4. Test edge cases: with a test account, replay a credit request, send negative amounts, very large values and concurrent requests. Check the invariant after each attempt.
5. Measure detection time: simulate a discrepancy in a test environment and measure how long it takes for an alert to fire.
6. Test the emergency stop: check that you can freeze a sensitive flow (withdrawals, issuance, exports) within minutes, and who is allowed to do it.

How to fix it

• Continuous automatic reconciliation of invariants, with an alert and an automatic freeze beyond a threshold.
• Caps on withdrawals or creation per period, which limit the maximum loss before detection.
• Multi-party approval for large movements.
• Security review of the components you rely on for a guarantee, and tracking of their fixes.
• An incident procedure that treats anyone keeping part of the funds as an attacker.

AI agents and the Liquid Elements bug: what changes

AI agents are starting to get payment, refund or transfer tools. An agent that can credit an account or initiate a withdrawal is a new value-creation path, steered by the content it reads. A refund request carrying a hidden instruction can push it past business rules if those rules live only in its prompt. Caps, invariants and human approval must be enforced server-side, outside the model, as the methods of the Lazarus group also illustrate. The Agent Red Team Express tests in five days whether your agent can be pushed to create or move value without a counterpart.