feat: EIP-7702 account, proxy delegation, and ERC-1271 without a Safe

[mfw78]

Stacked on #59. Merge that first.

An EIP-7702 delegate so an EOA can place conditional orders without deploying a Safe. Nothing is deployed by this PR.

The premise

ComposableCow never calls a Safe method. isValidSafeSignature takes one only as a typed address, and _auth reads the registry's own roots and singleOrders, so any address can own an order.

The repo already assumed this. test/ComposableCow.base.t.sol:318 has TestNonSafeWallet, an ERC1271Forwarder with no Safe, and ComposableCow._buildSignature (src/ComposableCow.sol:560) has a catch branch commented "Assume a non-Safe wallet" emitting exactly the payload the forwarder decodes. This contract is that branch's intended client.

Two contracts plus a proxy

Contract	Role
Account7702	generic: ERC-7821 batching plus ERC-7739 ERC-1271. No CoW or ComposableCow references. Usable as any 7702 implementation
CowAccount7702	extends it with the order-payload signature shape
Solady EIP7702Proxy	deployed unmodified as the delegation target

Batching is ERC7821 at its defaults. Empty opData requires msg.sender == address(this), which under 7702 only a self-sent transaction satisfies; non-empty opData reverts. No relayed path, so no nonce to maintain: the EOA's account nonce sequences the batch.

Signatures try ERC-7739 nested EIP-712 first, then fall through to the order payload. The two accounts use different EIP-712 domains, so a signature for one is not valid for the other.

Why the proxy

Delegating to the proxy rather than straight to an implementation means the implementation can be replaced without the EOA signing a second EIP-7702 authorisation. test_proxy_UpgradeChangesBehaviourWithoutRedelegating upgrades the proxy and asserts the EOA's behaviour changes while its delegation designator does not. Mutation-checked: upgrading to the same implementation makes that test fail, so it detects the swap rather than passing either way.

The trade, stated plainly. The proxy adds a second authority: whoever holds the proxy admin can change the code running on every delegated EOA that has not pinned its own implementation, so the account's security becomes the EOA key and the admin key rather than the EOA key alone. It also writes ERC-1967 slots into the EOA's storage, which the earlier stateless delegate avoided, and those slots persist if the EOA is later re-delegated elsewhere. Worth a multisig for the admin on anything real.

Three Solady defaults overridden, each non-obvious

• _erc1271CallerIsSafe to false. Solady skips ERC-7739 nesting entirely for MulticallerWithSigner, which would make any raw signature the EOA ever produced over any 32-byte value a valid ERC-1271 signature for that caller. No multicaller integration here, so it is pure attack surface on a contract holding the EOA's whole balance. Found by adversarial review, not by me.
• _erc1271IsValidSignatureNowCalldata recovers directly, requiring exactly 65 bytes with low s. The SignatureCheckerLib default would staticcall isValidSignature on this account (the delegation designator gives address(this) nonzero code) and re-enter instead of recovering. The length and low-s bounds give each accepted digest a single valid encoding, so a consumer keying a replay guard on signature bytes is not bypassable.
• _erc1271IsValidSignatureViaRPC to false. The default burns the whole gas budget on failed validation when tx.gasprice == 0, which is every foundry test and most eth_call simulations.

What is load-bearing and looks incidental

Solady's Receiver, which ERC7821 brings, answers only the ERC-721 and ERC-1155 receiver selectors and reverts FnSelectorNotRecognized otherwise. _buildSignature probes the owner with supportsInterface, and the payload the forwarder decodes is produced only from the catch branch, so that probe MUST revert. A fallback that answered it would break settlement silently. For the same reason the delegate declares no supportsInterface.

The one change to an audited contract

ERC1271Forwarder.isValidSignature, two tokens: bytes memory to bytes calldata, plus virtual. Same selector, same external ABI, body untouched. Solc forbids co-inheriting public functions whose data locations differ, and the function was not overridable.

Tested

21 new tests using the real signAndAttachDelegation cheatcode rather than vm.etch, TWAP as handler. 203 pass (182 pre-existing plus 21), forge fmt --check clean, descriptors still current.

The supportsInterface probe is asserted to revert through an actual getTradeableOrderWithSignature call, so the catch branch is exercised end to end rather than mocked. I mutation-checked the security fix myself: removing the _erc1271CallerIsSafe override makes test_multicallerCaller_RawSignature_NotAccepted fail.

Two consequences, asserted by tests rather than left implicit

• A direct ERC-7739 signature never touches ComposableCow, so registry authorization, handler verify and any swap guard are bypassed. That is what "the owner signed it" means, but test_erc7739_BypassesSwapGuard makes it visible.
• ERC-7739 requires the nested digest, so this does not make raw-digest ERC-1271 queries validate through the ECDSA path, including CoW's own eip1271 scheme over a plain order digest.

Note for reviewers using jj

lib/solady (v0.1.26) is a submodule. jj 0.43 carries existing gitlinks but will not create a new one from a working-copy submodule, so this commit's tree was assembled with git plumbing and pushed with git push. A plain jj git push would drop the gitlink and CI would fail on the missing import. Verified present on the remote at acd959a.

Open question, deliberately not resolved here

ERC1271Forwarder.isValidSignature still reverts rather than returning 0xffffffff on a bad payload. Returning a non-magic value would make the dispatch cleaner, but GPv2Signing.recoverEip1271Signer calls it directly rather than inspecting returndata, so today a settlement failure bubbles the specific error (OrderNotValid(0x...), SingleOrderNotAuthed) instead of collapsing to "GPv2: invalid eip1271 signature". Worth doing scoped by failure kind, in a follow-up.

[mfw78]

Superseded by #61. The account work moved to nxm-rs/nexum-account, which depends on this repository for ERC1271Forwarder. All that remains here is the two-token change making isValidSignature overridable, which #61 carries.