The core and its routers

The single proxy that enforces your balance changes was not always safe. An early version had a hole that let an attacker spend other people's token approvals, and closing it forced ERC-8009 into the shape it has now: one small trusted core that enforces balances, with one replaceable router for each way a call can be paid. One of those routers is what finally covers a multisig like Bybit's. And even with all of it in place, the guarantee still has a limit worth knowing.

A proxy that stands between you and every contract you call is dangerous to get wrong, and early in ERC-8009's design it was wrong. The proxy let any caller pass in the target to call and the calldata to send, both chosen freely. It also held standing token approvals, because users approved it once so it could move their tokens for ordinary transactions.

Put those two facts together from an attacker's side. Call the proxy with a token contract as the target, and pass calldata that moves some victim's tokens to yourself. The victim had already approved the proxy. The token sees the trusted proxy asking to move the victim's balance, and it obeys. The proxy had become a confused deputy: a trusted component anyone could point at any target, spending approvals that were never meant for the caller.

The balance check did not save the victim. It runs against the changes the caller declares, and the attacker declared no requirement about the victim's account, so nothing was checked there. The enforcement was sound, and the design around it was still exploitable.

The fix was to split the one contract into two separate pieces. A minimal core does the single job that has to be trusted: it enforces the balance changes and holds no standing power of its own. Everything that arranges how a specific call gets paid for is moved out into a replaceable router that sits in front of the core. The caller can no longer aim a trusted, approval-holding component at an arbitrary target, because that combined component no longer exists.

The routers are where standing approvals stop being a liability. The permit router uses a per-transaction approval instead of a standing one. Remember permit from the gasless approvals lesson: the owner signs an EIP-712 message that grants a spend for one transaction only, so no lasting approval sits on the router or the core for an attacker to reach. A different way of paying for a call gets a different router, and the core beneath them stays the same small contract, audited once and deployed at one canonical address on each chain, so hardware wallet firmware can hardcode that address and trust it.

Bybit was a multisig, and that separates signing from execution. Several owners approve a transaction, then one executor submits it on-chain. That split is why a plain single-signer flow did not cover the case that mattered, and it is exactly what the Safe router, added in mid-2026, is built for.

The Safe router is added as one of the Safe's owners and takes up one slot of the signature threshold. The executor submits the transaction through the router on their hardware wallet, and sees the same clear-signed balance requirements a single signer would. The router runs the Safe transaction through the core, and the required changes are checked after the Safe executes, so any violation reverts the whole bundle. Bybit's setup, three owners approving and one executor submitting, is the flow this now covers.

One honest limit lives here. The standard defines what the executor sees at execution time. What each earlier co-signer sees when they add their signature is not part of the guarantee.

Balance requirements are a strong floor, and they are still only a floor. ERC-8009 constrains native ETH and ERC-20 balances, and nothing else. A transaction can satisfy every ETH and token requirement you set and still move an NFT you never thought to constrain, or change a lending or staking position that is not a plain balance. The screen tells you the truth about the balances you asked about, and stays silent about the rest.

Two narrower edges are worth remembering.

• An absolute-balance check ignores where funds came from. Someone could send you funds so the final number passes, hiding that your own call actually drained you. When the source matters, use the difference form, which measures the change your own call produced.
• The core is stateless. Any funds left sitting in it belong to whoever withdraws them next, so a correct transaction never leaves a balance behind.

ERC-8009 is a proposed standard, still in Draft. There is a working implementation, including the multisig router, and a demo with hardware wallets.

• Spec and demos: erc8009.xyz
• Formal proposal: ethereum/ERCs #1184
• Discussion: Ethereum Magicians

You now have two things to do at signing time, and they work together. Read the balance changes the screen shows you, and confirm they match what you meant to do. Then remember that those numbers are a floor. If a transaction touches something a balance does not capture, the screen stays quiet about it and the judgment is still yours. That includes an NFT, a debt position, or a change of ownership. The core enforces what you declared and nothing more, which is a firm guarantee about your ETH and tokens and an honest silence about everything else.