Pre-Signing Transaction Verification for Institutional Wallets

Verification can run in three places: in the system that initiates transfers, at the signer (an HSM or MPC policy engine), or as a separate gate between approval and signing or broadcast. The location matters less than where the check gets its inputs. A check that reads the request, the approval and the policy from the same system that could be compromised will fail along with that system.

Both cases below fit that pattern. At Bitget, the risk checks lived on a path the forged commands never took. At Liquid, the authorization key confirmed who was asking and where the funds would go. Nothing checked whether the value being redeemed existed.

Per Bitget's official incident page, last updated October 4, 2026^[1]: attackers used a zero-day vulnerability in a third-party security product to steal internal credentials. They then "directly wrote forged withdrawal commands into the wallet system. This caused the wallet to process them as normal withdrawals, bypassing the risk control verification process before withdrawal records were generated." The final verified figure is approximately $388M, involving 12 hot and warm wallet addresses. "Private keys were not compromised," and cold wallets were unaffected. The attackers later deleted traces of the forged commands. Bitget's remediation includes "strengthened independent withdrawal verification."

For pre-signing verification:a check that sits on the normal request path, or that trusts the wallet system's own records, does not see a command written below it. The signer, or the last gate before it, needs to confirm that a matching approval exists somewhere the attacker could not write.

Per Blockstream's technical assessment of September 23, 2026^[2]: a defect in Elements' rangeproof verification cache let a transaction that "was not backed by its inputs" pass validation. Liquid nodes, including federation functionary nodes, accepted it, creating about 4,000 unbacked LBTC. The attacker redeemed it through the standard peg-out process via SideSwap, a federation member, for about 4,000 BTC. The reserve fell from about 4,205 BTC to 197 BTC before the halt, with routine peg-outs already in progress also contributing. Of the amount attributable to the unauthorized transactions, 3,400 BTC was returned. About 602 BTC remained subject to recovery efforts. "The SideSwap PAK itself was not compromised, forged or stolen." The peg-out mechanism "authenticated a real signature request against LBTC that consensus had, incorrectly, already accepted as real."

For pre-signing verification: destination and requester checks both passed, because neither was what failed. For bridges, redemptions and any flow that releases value against a claim, the check before signing should also confirm that the claim is backed, using a source independent of the system that validated it.

1. Confirm that a matching approved request exists, recorded outside the system that initiated the transaction. Refuse to sign if it doesn't.
2. Verify the full destination address against the allowlist, check who added it and when, and confirm its cooling-off period has ended.
3. Verify the exact amount in native units, the token contract and the chain ID against the approval.
4. Decode the calldata. Confirm the function, target and parameters. Stop on an unexpected DELEGATECALL, approve call or batch.
5. Apply per-transfer and per-period limits, and hold first payments to new destinations.
6. Compare the size with the balance or outstanding supply. Large shares need human review.
7. For redemptions and bridges, check backing against an independent reserve figure before release.
8. Collect the second approval through a channel separate from the one that carried the request.
9. Write the verification result and the rules that fired to a write-once record before broadcast.
10. Treat urgency, address changes and requests to skip test transactions as triggers for out-of-band verification.

For who should hold each role, see crypto treasury segregation of duties.