A hot wallet that signs only what its mandate allows, and proves it.

How a compiled mandate, a receipt-checking signer, a state tracker and owner-held governance stop five attacks on an exchange-style hot wallet, including the delegation used on October 29, and what each stop leaves behind. Inherence, October 2026. Draft for discussion. The demo that accompanies this paper uses a local Ethereum node, demo keys, and a signer that stands in for an enclave.

The problem

On October 29, 2026, an EIP-7702 authorization delegated a Binance hot wallet to an attacker-controlled sweeper contract, and outflows began within minutes.¹² Binance's preliminary update points to compromised signing infrastructure, possibly an operations laptop, and says it found no evidence of a private key leak.² EIP-7702 itself is working as designed: an authorization is a signature like any other, and the wallet signed it.³ Figures for the loss still vary widely between reports; this paper does not rely on any of them.

That is the general shape of the problem. The service that asks a hot wallet to sign withdrawals needs a credential that can move money. If that credential, or the machine holding it, is taken, the controls that lived inside the service go with it. The damaging moves are rarely large transfers to obvious addresses. They are a delegation that hands the wallet's code to someone else, an approval that lets a contract pull funds later, a series of transfers each small enough to pass, or a quiet change to the rules themselves.

The design

1. A mandate, compiled. The owners write what the withdrawal service may do: an allowlist of five destinations, a 100,000 USDC per-transaction cap, a 500,000 USDC daily cap, and no delegation, approval or ownership change. Compiling it produces a circuit, a public mandate ID and a verifying key. Each written rule maps to a named check.
2. A gate in front of the chain. Every request to sign becomes a proposal: the exact payload a signer would be asked to sign. The gate derives what the payload does (its type, recipient and amount) from the payload itself, evaluates it against the mandate and the current daily total, and returns a receipt for an allow or a deny.
3. A state tracker. It holds the running totals the mandate depends on, commits to them before each evaluation, and records a transition after each transfer lands. The receipt binds the state it was judged against.
4. A signer that checks receipts. It holds the wallet key and runs five checks in order: the payload is an ordinary transfer; the receipt verifies and proves allow; the receipt commits to this exact payload; the receipt is for the current mandate version; the mandate is not revoked. It signs a record of every refusal and every signature.
5. Governance held by the owners. A change to the mandate needs both owner signatures. Before accepting one, governance asks whether the new version permits anything the old one forbade. A narrowing change applies at once. A widening change waits 24 hours.

Five attacks, five stops

The gate and the signer each stop the delegation on their own. With the gate switched to pass-through, the signer refuses on type. With the signer's type rule disabled, the gate's denial means the request never reaches it.

What a receipt proves

A receipt is a Groth16 proof over the compiled mandate 128 bytes. Its outputs are one result per clause and the overall decision, so a denial is proven the same way as an allow, and names the clauses that failed. Its binding commits to the mandate ID, the tracker's state, the exact payload and the market snapshot. A third party holding only the verifying key for that mandate version can check it in a few milliseconds 1.5–4.4 ms measured. When the mandate changes, receipts issued under the old version still verify against the old key, and cannot pass as the new one.

The containment check compares the two versions clause by clause. For this mandate's shape every clause is monotone in its one parameter, so the comparison is exact. Each widening it reports comes with a concrete counterexample, proven in both versions: the new one allows it, the old one denies it.

What is open

• Receipt privacy. The circuits that prove per-clause results also carry the proposal's inputs in their public inputs: the amount and the destination. The demo's third-party view shows only versions and decisions, but anyone holding a receipt can read those inputs. Hiding them needs private inputs bound by an in-circuit commitment.
• The enclave. The signer here is ordinary software reproducing an enclave's externally visible behaviour. Its records carry a simulated attestation. Its request and record shape follow a production signing service's activity format; that mapping has not yet been checked against a live account.
• The chain. The demo runs on a local Ethereum node unless started against a mainnet fork. A replay of the October 29 delegation and sweep transactions from the public chain is planned; it needs an archive endpoint and the raw transactions.
• Proving time. A receipt takes about two seconds end to end on a laptop and about five on the hosted demo, almost all of it loading the proving key; the proof itself is tens of milliseconds.

Sources

1. Fireblocks, "Deconstructing the Binance Exploit." fireblocks.com
2. The Crypto Times, "Binance Links EIP-7702 Authorization to Hot Wallet Hack," October 30, 2026. cryptotimes.io
3. Decrypt, "What is EIP-7702? The Ethereum Upgrade Behind the Binance Hack." decrypt.co

Reports are preliminary as of October 30, 2026.