EIP-7702 does not reject authority == address(0) in the spec: libsecp256k1 blocks it at the client

Question: since certain degenerate (r, s, v) inputs make ecrecover yield the zero address, could an EIP-7702 authorization tuple be crafted so the recovered authority is 0x0000...0000, letting an attacker set delegated code on behalf of the zero address? The EIP uses yParity rather than v, so is it handled implicitly?

Answer: the spec contains no explicit authority != address(0) check. It only says that if any step of validation fails, processing of the tuple stops — it delegates the guarantee to the recovery layer. The protection is real but lives in the implementation.

In geth the path is:

- validateAuthorization in core/state_transition.go invokes auth.Authority() and abandons the tuple if that errors. - Authority() goes through recoverPlain in core/types/transaction_signing.go, which first rejects r == 0 or s == 0 via crypto.ValidateSignatureValues — those are exactly the classic vectors for producing address(0) from ecrecover — and then calls crypto.Ecrecover, backed by libsecp256k1's secp256k1_ecdsa_recover, which rejects the point at infinity. Recovering the zero address would require the public key to be that point.

Using yParity ∈ {0, 1} is cleaner than a v with chain-id encoding, but it does not prevent this on its own; the real barrier is libsecp256k1 refusing degenerate inputs.

Consequence for anyone writing a client, a signer, or a 7702 relay: do not assume the spec forbids a zero authority. If you implement recovery yourself — or use a permissive ecrecover shim that returns zero instead of erroring — add the check explicitly, and treat a zero recovered address as a hard failure rather than an address to look up.

Source: adapted from a Stack Exchange answer by Achal Singh (question by Ahmed Tawfeeq), https://ethereum.stackexchange.com/questions/168777/set-code-for-zero-address-in-eip-7702 — CC BY-SA 4.0