ERC-8350 update: authorization revision merged; Review requested
The focused authorization revision has merged into the official ERC repository in ethereum/ERCs#2147, at commit 8b11215c.
A separate, status-only Draft → Review request, #2148, is now open. The official status remains Draft until that request is accepted and merged. This requests peer review, not Final status or production certification.
What changed
- ERC-1271 receives the original signature bytes, including empty or non-65-byte signatures, before EOA-specific length checks.
- Required authorization accounts and the optional direct-empty path are explicit for registration, authorization updates, and transitions. Non-empty signatures from the required account still undergo validation.
- Malformed ERC-1271 responses are handled strictly. An ERC-1271 failure can still fall through to canonical ECDSA validation. In particular, a 7702 delegated account retains its underlying key authority; wallet-policy rejection is not necessarily a final rejection.
- The core hash definitions, wire format and signing domain are unchanged.
Reproducible evidence and its limits
The pinned review packet and baseline 3 link the exact official source, authorization decision table, historical baselines, commands and CI artifacts.
Maintainer checks passed: a clean checkout with 155 TypeScript and 120 Solidity tests, byte-for-byte v1 conformance across core TS, minimal TS and Solidity, and 47 baseline/source-runner tests. The exact official-source and preserved candidate-source suites each pass 38 tests; each old-source negative control reproduces the two expected failures. The real-account suite passes 58 tests, with additional actual local EIP-7702 type-4 transaction checks.
These are maintainer results, not independent wallet validation. The independent Python client report remains scoped to its historical pins and hash/fixture/state/EOA coverage; it excludes ERC-1271, Safe and 7702. Independent wallet coverage and acceptance of an external audit addendum for the current runtime remain open. The full G4 release gate is not yet passing.
Feedback is especially welcome on:
- Whether the required-account roles, direct-empty path and retained-key fallback are unambiguous for implementers.
- Wallet-policy, gas and state-dependent validation behavior.
- The boundary between an authorized, ordered commitment history and the truth or completeness of private memory.
The latter distinction remains important: ERC-8350 commitments do not themselves prove that an agent’s memories are true or that a committed computation actually occurred.
Thank you to everyone reviewing or independently reproducing the proposal.