Repository navigation
[R-002] Independent second implementation of the core registry #21
Description
Request
We are seeking an independent team or developer to implement the ERC-8350 core registry from the published spec alone, in any language (Solidity, Rust, Python, Go, ...), and pass the published conformance vectors.
Status update, 2026-11-06: a scoped independent Python client has been delivered and reproduced; full account coverage remains open.
@0x2kNJ published the scoped results from ERC8312/bounded-agent-actions at 95ca613bac0d7ef9192f32264f1f315d869d5ce2. The contributor declares no affiliation with AwareLiquid and no AgentMemoryState code/package import. This is contributor-declared provenance, not a maintainer identity audit, and no continuing maintenance commitment is presumed.
Our clean-checkout reproduction passed spec 21/21, hash 59/59, fixture 58/58, state 34/34, ecdsa 55/55 and reference-error compatibility 28/28. All 41 upstream unit tests ran with zero skips, including the cast cross-check. These results were rerun successfully on final main 5770a9090700cc6df925b7a399e53014eac16667, locally and in the independent-client CI run. Clean pnpm/Foundry conformance, both external replay suites and maintainer real-account tests also passed on that commit; they retain their separate scopes.
- test: archive and gate scoped independent Python reproduction #36 is merged into main as
298148f98bdc6e09cb03c5bc42ab8661cb920273, publishing the pinned reproduction runner, archived native reports/logs, zero-skip CI gate and scheduled regression notification. - test: consume 46 external EOA signature vectors across implementations #37 is merged after test: archive and gate scoped independent Python reproduction #36 as
5770a9090700cc6df925b7a399e53014eac16667, consuming the exact 46 exported EOA cases in both Solidity Registry copies and the core/minimal TS hash APIs with an explicitly test-only shared state/recovery adapter. These are maintainer tests, not another independent implementation. - ci: require cast for ERC-8350 signature cross-checks ERC8312/bounded-agent-actions#3 proposes making cast mandatory in upstream CI. It remains a separate open PR subject to upstream maintainer review/approval; the consumer merges do not establish upstream acceptance.
- Earlier replay evidence and R-002 regression: pinned external replay fails header verification on current Sepolia #29/R-002: re-pin the external replay to upstream after ERC8312/bounded-agent-actions#2 merges #31 remain separate, historically valid scoped records. This delivery is not another independent repository owner.
Remaining scope: independently execute/report ERC-1271, real Safe and EIP-7702 paths, including empty/short signatures, malformed or reverting wallet responses, policy/key fallback, and rejected-call atomicity. The maintainer real-account handoff is available, but it does not establish that the external client implements those paths. AQ-01/AQ-02 disagreements should be recorded before extending account semantics. Issue #21 stays open.
What to implement
The entry point is docs/implementing.md - it defines what conformance does and does not mean, the surface to implement, and what to do with a mismatch. The testable artifact is ** est-vectors/v2.json**:
- a 5-transition chain where each delta is only computable from the previous one's
nextStateRoot - 12 rejection cases checked against held state, including unchanged head/authorization on rejection; reference error names and check order are a separate compatibility layer, not additional normative requirements
- driven end-to-end by
pnpm check:vectors(TypeScript) andcontracts/test/unit/VectorsV2.t.sol(Solidity)
Independence requirements:
- must not be a maintainer of AwareLiquid/ERC-8350
- must not import this repository's packages (dependency-isolated)
- should publish the implementation and its conformance run publicly
Feedback questions
- Is
docs/implementing.md+test-vectors/v2.jsonsufficient for a stranger to implement the core registry? What document or artifact is missing? - Which language/runtime would you choose, and why?
- What does a passing conformance run need to look like for you to trust it (exact commands, pinned toolchain, ...)?
Why this matters
The scoped Python delivery is evidence that an external contributor can implement the delivered layers from the pinned Draft and vectors. It is not yet a full account-capable client, ecosystem adoption, a security audit or production-readiness acceptance. This issue tracks the remaining scope without discounting the delivered evidence or requiring an unstated maintenance commitment.
Activity
everest-an commentedon Aug 5, 2026
ERC-8350's roadmap has one large open gap: the repository ships two implementations, but both are maintained by the same project, so the standard has never been proven implementable by a stranger working from the spec alone. The entry point is now docs/implementing.md, and the testable artifact is test-vectors/v2.json — a 5-transition chain where each delta is only computable from the previous one's nextStateRoot, plus 12 rejection cases with their errors and check order.
Feedback questions:
Is docs/implementing.md + test-vectors/v2.json sufficient for a stranger to implement the core registry? What document or artifact is missing?
Which language/runtime would you choose, and why?
What does a passing conformance run need to look like for you to trust it (exact commands, pinned toolchain)?
XiaoHai67890 commentedon Nov 1, 2026
Implementation handoff update (not a completion claim): PR #32 publishes the official-text baseline/difference register; PR #34 adds the narrowly scoped AQ-03 malformed-1271-return fix; PR #35 adds executable real Safe/7702 account evidence and the external-client acceptance package.
Pinned handoff: https://github.com/AwareLiquid/AgentMemoryState/blob/d6755e07a6f9286e6be9a33a9a64d8faf3aa0ae0/docs/interop/independent-client-handoff.md
Account scenarios: https://github.com/AwareLiquid/AgentMemoryState/blob/d6755e07a6f9286e6be9a33a9a64d8faf3aa0ae0/docs/interop/account-conformance.md
@0x2kNJ @babyblueviper1 Would either of you be interested in reviewing the acceptance matrix or proposing a scoped independent-client contribution? A different language is welcome but separate authorship/maintenance is what establishes independence. Please flag AQ-01/AQ-02 wording disagreements first; the project proposal is not yet merged official normative text.
Suggested first response: language/runtime, supported layer, disputed rules, and a reproducible command. Acceptance separates v1/v2 computations, state-machine rejection/atomicity, wallet authorization and offline fixture verification. No project SDK import; record limitations explicitly. Our own 58 account tests and local mined type-4 transactions are maintainer evidence, not an external second implementation. Portable signature-vector/adapters work remains a follow-up. No compensation or commitment is implied. #21 remains open.
XiaoHai67890 commentedon Nov 1, 2026
Reopened to correct an unintended GitHub auto-close from PR #33. The negated phrase in that PR description was still parsed as a closing keyword; the description has now been corrected. PR #33 restores the pinned external replay evidence only. A full independently maintained second implementation remains outstanding; the acceptance criteria and handoff in this issue are unchanged.
0x2kNJ commentedon Nov 1, 2026
Thanks for the ping. We're working on a scoped piece of this: an independent Python client, extending the existing
recompute/in ERC8312/bounded-agent-actions, written from the official Draft atb9651bcand the published vectors, with no project code imported.Layers in scope for this pass:
0x2kNJ commentedon Nov 1, 2026
Results for the scoped client, at ERC8312/bounded-agent-actions@
95ca613(recompute/erc8350_client.py, sha25633dd89de…):spec 21/21 · hash 59/59 · fixture 58/58 · state 34/34 · ecdsa 55/55 · compat (reference error names) 28/28, all PASS
Inputs are fetched and sha256-pinned: Draft
b9651bc, vectors ataa9bbe5. CI on the commit: https://github.com/ERC8312/bounded-agent-actions/actions/runs/41310234213. No mismatches against the vectors or the Draft. ERC-1271, Safe and 7702 accounts are not implemented.--emit-signature-vectorswrites 46 static ECDSA cases with public test keys, if useful for the portable signature suite.Provenance: written and maintained in this repository; no affiliation with AwareLiquid, and no AgentMemoryState code or package is used.
XiaoHai67890 commentedon Nov 6, 2026
@0x2kNJ Thank you for the scoped Python client and the exported 46 ECDSA cases. PRs #36/#37 are now merged, with the client replay and portable TS/Solidity adapters. Your results remain attributed only to hash/encoding, fixture, state and EOA coverage; we have not expanded that claim to ERC-1271, Safe or EIP-7702.
A focused official clarification/fix is now proposed in ethereum/ERCs#2147 at
397426c046049e1a0c3436e543f9731408708fd3(still Draft). It clarifies original empty/custom ERC-1271 bytes, nonempty self-calls, strict ABI return words and same-byte ECDSA fallback. Wire/typehash/v1/v2 inputs are unchanged. The official accepted baseline remainsb9651bcuntil an upstream merge; your original pinned evidence remains valid for its stated inputs.Project evidence runner and handoff: #38, latest runner
9e8dd09c776ef1d27e8b71ea8283d0dd6610ac14. It tests the exact fetched candidate and the old-source AQ-03 negative control. Existing main has the 58-case real-account harness plus local mined type-4 receipts; those are our maintainer results, not an independent implementation.If you have interest and bandwidth, would a bounded follow-up reviewing the acceptance table or independently running a selected ERC-1271/Safe/7702 subset be feasible? Please declare unsupported rows and the exact rule/version used. There is no assumed maintenance commitment or expectation to expand the original best-effort scope. Issue #21 remains open for the remaining independent account coverage.
XiaoHai67890 commentedon Nov 6, 2026
@0x2kNJ The handoff is now pinned to the merged official Draft, not a pending candidate: ethereum/ERCs#2147 merged at
8b11215cf267f710b49ea003384e678bcf953eae. Project #39 is merged atf654fe023909ef93e1478e79dbcee7cbd7b05835, recording baseline 3 while preserving baselines 1/2 and your historical evidence.The v1/v2 vectors and core hash/wire/domain definitions are unchanged.
node scripts/review-candidate.mjs --officialnow verifies the exact merged sources; the default mode preserves the earlier candidate and its negative control. All four fresh main CI workflows passed.Your existing client results remain credited only to their stated historical pins and implemented layers, not to baseline 3 or independent wallet coverage. The earlier optional request for a bounded acceptance-table/ERC-1271/Safe/7702 follow-up remains open; there is no assumed expansion of your scope or maintenance commitment. Please state unsupported rows and exact inputs in any follow-up.
The separate peer-review status request is ethereum/ERCs#2148 and the public update is https://ethereum-magicians.org/t/erc-8350-agent-memory-state-registry/29098/36. #21 stays open for the remaining independent coverage. Thank you.