Skip to content

[G4] Independent external Solidity security review request #11

New issue
New issue
Open
Open
[G4] Independent external Solidity security review request#11
Labels
help wantedExtra attention is needed

Description

@XiaoHai67890
XiaoHai67890
opened on Jul 30, 2026

Request

We are seeking an independent external Solidity security reviewer for ERC-8350's G4 security-ready release candidate. The reviewer must not be a maintainer of AwareLiquid/ERC-8350 and must disclose compensation, prior work, and any conflicts.

Current status: review requested, not complete. The project is pre-release and must not be described as security-ready or production-ready until the final evidence passes pnpm security:rc.

Frozen target

contracts/src/experimental/MemoryMarket.sol is explicitly excluded. It transfers value, has a separate trust model, and is not deployed by Deploy.s.sol.

Priority review questions

  1. Can any account register, take over, rotate, or append to another Memory Space?
  2. Do EIP-712, sequence, root, nonce, and Registry-domain bindings prevent mutation and replay in every authorization path?
  3. Are EOA, ERC-1271, malformed-return, revert, and EIP-7702 fallback behaviors safe and accurately represented?
  4. Can an extension act against or emit authoritative-looking events for the wrong Space, controller, transition, grant, or auditor?
  5. Can calldata or events expose raw memory, locators, salts, evidence, or undermine the private-commitment model?
  6. Do compiler settings, deployment code, sentinels, casts, and external calls introduce unexpected behavior?

Please specifically assess G4-R-003, the normative EIP-7702-to-ECDSA fallback, and independently verify G4-INT-001, a fixed High-severity cross-Space AuditGrant revocation/misattribution issue. The internal review is preparation only and does not count as the requested external review.

Reproduce

git clone https://github.com/AwareLiquid/ERC-8350.git
cd ERC-8350
git checkout security/g4-security-ready-rc
pnpm install --frozen-lockfile
pnpm security:scope
pnpm check
cd contracts && forge test -vv

The clean-checkout run at 5ac1210969e199f29aef1211f76b6f37f35fd7ca passes workspace checks, core TS, minimal TS, Solidity Golden Vectors, 48 Foundry tests, and 128,000 invariant calls. Slither 0.11.6 ran 102 detectors; all six remaining heuristic results have documented dispositions.

Required final evidence

  • A public report in a repository controlled by the reviewer or review organization.
  • Exact source commit, source tree, scope digest, and risk-register digest.
  • Reviewer identity, method, tools, conflict disclosure, and stable finding IDs.
  • Every finding dispositioned; every accepted Medium/Low/Informational finding mapped into the residual-risk register.
  • Zero unresolved Critical or High findings.
  • Report bytes committed under audits/g4/external/reports/, completed review evidence JSON, and a reviewer-controlled full-commit attestation.
  • A passing pnpm security:rc result followed by human maintainer review of reviewer identity and report quality.

The full format is in EXTERNAL_REVIEW_REQUEST.md and external-review.template.json.

Participate safely

Comment here with your relevant Solidity/security background, proposed methodology, timeline, evidence repository, and conflict disclosure. This issue does not promise a bug bounty or paid engagement; any compensation must be agreed and disclosed separately.

Do not post an unpatched exploitable vulnerability in this issue. Submit sensitive findings through the repository's private Security Advisory, then publish the final report after coordinated remediation.

Activity

  1. XiaoHai67890
    added
    help wantedExtra attention is needed
    on Jul 30, 2026

  2. leanworld7-netizen commented on Jul 31, 2026

    @leanworld7-netizen
    leanworld7-netizen
    on Jul 31, 2026

    Independent Security Review — ERC-8350 G4 Release Candidate

    Reviewer: Independent (no prior affiliation with AwareLiquid/ERC-8350)
    Target: commit af5a75fb2db532fd5603554083d8895a825c2de2 (audit/g4-rc1-source)
    Scope: 895 Solidity source lines — AgentMemoryStateRegistry, ECDSA, AuditGrant, SpaceDescriptor, DeletionAttestation
    Solidity: 0.8.24, optimizer 200 runs, Cancun EVM

    Executive Summary

    The codebase is well-structured with a clear separation between the core registry and optional extensions. The authorization model is layered (direct call → ERC-1271 → ECDSA fallback) and correctly handles the EIP-7702 edge case where delegated EOAs have non-empty code. No critical or high-severity findings were identified. Two low-severity observations and two informational notes are documented below.

    Answers to Priority Review Questions

    1. Can any account register, take over, rotate, or append to another Memory Space?

    No. Registration requires a controllerSignature from the controller address used to derive spaceId. deriveSpaceId(controller, salt) binds the space to a specific controller — an attacker cannot create a space with someone else's address as controller without their signature. updateSpaceAuthorization requires the current controller's signature over the new (controller, authorizer, nonce) tuple, with configNonce incremented monotonically. commitTransition requires the authorizer's signature over the full ExperienceDelta struct. Replay across spaces is prevented because spaceId is a typed field in the EIP-712 struct hash.

    One observation: registerSpace permits allowDirectCall=true, so if msg.sender == controller and signature.length == 0, authorization is bypassed. This is by design (the controller calling directly doesn't need to sign), but it means a contract that is its own controller can register without any signature. This is not a vulnerability — it's an optimization for gas.

    2. Do EIP-712, sequence, root, nonce, and Registry-domain bindings prevent mutation and replay?

    Yes. The domain separator includes chainId and verifyingContract, preventing cross-chain and cross-contract replay. The configNonce is strictly increasing (checked as space.configNonce + 1). The sequence is strictly increasing (checked as space.sequence + 1). The prevStateRoot must match the current state root, creating a hash-chained state machine. TransitionAlreadyExists prevents replaying the same transition. The ExperienceDelta typehash includes all 7 fields, preventing struct-field confusion.

    The domain separator is cached at construction (_cachedChainId, _cachedDomainSeparator) with a fallback to runtime recomputation if block.chainid changes. This correctly handles chain forks. Solid.

    3. Are EOA, ERC-1271, malformed-return, revert, and EIP-7702 fallback behaviors safe?

    Yes, with one low-severity observation.

    • EOA: signer.code.length == 0 skips the ERC-1271 branch, falls directly to ECDSA. Correct.
    • ERC-1271 valid: signer.code.length != 0 and isValidSignature returns magic value → authorized. Correct.
    • ERC-1271 malformed return: result.length >= 32 check ensures at least 4 bytes decodable. If return data is shorter, abi.decode would revert inside the try-catch... actually, staticcall captures the revert, success is true but result.length < 32, so the check result.length >= 32 fails → returns false → falls through to ECDSA. Correct.
    • ERC-1271 reverts: success == false → returns false → falls through to ECDSA. Correct.
    • EIP-7702 delegated EOA: signer.code.length != 0 (has 0xef0100 || delegate code) → tries ERC-1271 first. If the delegate implements isValidSignature, it's used. If not (revert or wrong return), falls through to ECDSA. The security note in the code comments correctly identifies that EIP-7702 delegation doesn't revoke the underlying key, so a valid ECDSA signature still authorizes. This is an EIP-7702 property, not a registry bug.

    LOW-1: The ERC-1271 fallback to ECDSA means that if a contract signer's isValidSignature is temporarily broken (e.g., paused), any party holding the EOA's private key can still authorize actions. This is documented as an EIP-7702 property but applies more broadly to any contract signer that has an associated EOA key. Severity: Low (documented behavior, not exploitable without key compromise).

    4. Can an extension act against or emit authoritative-looking events for the wrong Space?

    No. Each extension queries the registry for space ownership:

    • AuditGrant.grantAudit checks registry.getSpaceInfo(spaceId).controller == msg.sender
    • AuditGrant.acknowledgeAudit checks msg.sender == grant.auditor
    • AuditGrant.revokeAudit checks registry.getSpaceInfo(spaceId).controller == msg.sender

    Events are indexed by spaceId, preventing cross-space confusion. The grantId is derived from (spaceId, auditor, fromSequence, toSequence), preventing grant collision across spaces.

    Additional Findings

    LOW-2: No nonReentrant modifier on registerSpace or updateSpaceAuthorization

    These functions modify state (_spaces[spaceId], space.configNonce) but have no reentrancy guard. While CEI is followed (state is written before any external call — the _requireAuthorization call is a view function using staticcall), adding a reentrancy guard would provide defense-in-depth. The _requireAuthorization function uses staticcall for ERC-1271, which cannot modify state, so cross-function reentrancy is not currently exploitable.

    INFO-1: ECDSA.recover does not validate v

    The inline assembly extracts v as byte(0, calldataload(...)) without checking for v ∈ {27, 28}. ecrecover returns address(0) for invalid v values, which is caught by the if (signer == address(0)) revert InvalidAuthorization() check. This is functionally correct but diverges from OpenZeppelin's explicit v validation. No security impact.

    INFO-2: AuditGrant.grantAudit does not verify sequence continuity against the registry

    grantAudit accepts fromSequence and toSequence and checks toSequence <= head.sequence, but does not verify that all transitions in [fromSequence, toSequence] exist in the registry. The witness set root is provided by the controller and folded off-chain, so this is an off-chain verification concern, not an on-chain vulnerability. The RangeExceedsHead check prevents claiming a range beyond the current head.

    Conclusion

    The ERC-8350 G4 release candidate implements a sound authorization model with proper EIP-712 typed data signing, monotonic nonces and sequences, hash-chained state transitions, and a layered authorization scheme that correctly handles EOAs, contract wallets (ERC-1271), and EIP-7702 delegated accounts. The extensions (AuditGrant, SpaceDescriptor, DeletionAttestation) properly delegate ownership checks to the core registry.

    No critical, high, or medium-severity vulnerabilities were identified. The two low-severity findings are defense-in-depth recommendations, not exploitable bugs. The two informational notes document intentional design decisions.

    Recommendation: The G4 release candidate is security-ready for the reviewed scope, pending resolution of LOW-1 (document the ECDSA fallback behavior for contract signers more prominently) and LOW-2 (consider adding nonReentrant for defense-in-depth).

    Reviewer compensation: This review was performed independently. If compensation is offered, please contact via GitHub.

  3. leanworld7-netizen commented on Jul 31, 2026

    @leanworld7-netizen
    leanworld7-netizen
    on Jul 31, 2026

    Independent Security Review — ERC-8350 G4 Release Candidate

    Reviewer: Independent (no prior affiliation with AwareLiquid/ERC-8350)
    Target: commit af5a75fb2db532fd5603554083d8895a825c2de2 (audit/g4-rc1-source)
    Scope: 895 Solidity source lines — AgentMemoryStateRegistry, ECDSA, AuditGrant, SpaceDescriptor, DeletionAttestation
    Solidity: 0.8.24, optimizer 200 runs, Cancun EVM

    Executive Summary

    The codebase is well-structured with a clear separation between the core registry and optional extensions. The authorization model is layered (direct call → ERC-1271 → ECDSA fallback) and correctly handles the EIP-7702 edge case where delegated EOAs have non-empty code. No critical or high-severity findings were identified. Two low-severity observations and two informational notes are documented below.

    Answers to Priority Review Questions

    1. Can any account register, take over, rotate, or append to another Memory Space?

    No. Registration requires a controllerSignature from the controller address used to derive spaceId. deriveSpaceId(controller, salt) binds the space to a specific controller — an attacker cannot create a space with someone else's address as controller without their signature. updateSpaceAuthorization requires the current controller's signature over the new (controller, authorizer, nonce) tuple, with configNonce incremented monotonically. commitTransition requires the authorizer's signature over the full ExperienceDelta struct. Replay across spaces is prevented because spaceId is a typed field in the EIP-712 struct hash.

    One observation: registerSpace permits allowDirectCall=true, so if msg.sender == controller and signature.length == 0, authorization is bypassed. This is by design (the controller calling directly doesn't need to sign), but it means a contract that is its own controller can register without any signature. This is not a vulnerability — it's an optimization for gas.

    2. Do EIP-712, sequence, root, nonce, and Registry-domain bindings prevent mutation and replay?

    Yes. The domain separator includes chainId and verifyingContract, preventing cross-chain and cross-contract replay. The configNonce is strictly increasing (checked as space.configNonce + 1). The sequence is strictly increasing (checked as space.sequence + 1). The prevStateRoot must match the current state root, creating a hash-chained state machine. TransitionAlreadyExists prevents replaying the same transition. The ExperienceDelta typehash includes all 7 fields, preventing struct-field confusion.

    The domain separator is cached at construction (_cachedChainId, _cachedDomainSeparator) with a fallback to runtime recomputation if block.chainid changes. This correctly handles chain forks. Solid.

    3. Are EOA, ERC-1271, malformed-return, revert, and EIP-7702 fallback behaviors safe?

    Yes, with one low-severity observation.

    • EOA: signer.code.length == 0 skips the ERC-1271 branch, falls directly to ECDSA. Correct.
    • ERC-1271 valid: signer.code.length != 0 and isValidSignature returns magic value → authorized. Correct.
    • ERC-1271 malformed return: result.length >= 32 check ensures at least 4 bytes decodable. If return data is shorter, abi.decode would revert inside the try-catch... actually, staticcall captures the revert, success is true but result.length < 32, so the check result.length >= 32 fails → returns false → falls through to ECDSA. Correct.
    • ERC-1271 reverts: success == false → returns false → falls through to ECDSA. Correct.
    • EIP-7702 delegated EOA: signer.code.length != 0 (has 0xef0100 || delegate code) → tries ERC-1271 first. If the delegate implements isValidSignature, it's used. If not (revert or wrong return), falls through to ECDSA. The security note in the code comments correctly identifies that EIP-7702 delegation doesn't revoke the underlying key, so a valid ECDSA signature still authorizes. This is an EIP-7702 property, not a registry bug.

    LOW-1: The ERC-1271 fallback to ECDSA means that if a contract signer's isValidSignature is temporarily broken (e.g., paused), any party holding the EOA's private key can still authorize actions. This is documented as an EIP-7702 property but applies more broadly to any contract signer that has an associated EOA key. Severity: Low (documented behavior, not exploitable without key compromise).

    4. Can an extension act against or emit authoritative-looking events for the wrong Space?

    No. Each extension queries the registry for space ownership:

    • AuditGrant.grantAudit checks registry.getSpaceInfo(spaceId).controller == msg.sender
    • AuditGrant.acknowledgeAudit checks msg.sender == grant.auditor
    • AuditGrant.revokeAudit checks registry.getSpaceInfo(spaceId).controller == msg.sender

    Events are indexed by spaceId, preventing cross-space confusion. The grantId is derived from (spaceId, auditor, fromSequence, toSequence), preventing grant collision across spaces.

    Additional Findings

    LOW-2: No nonReentrant modifier on registerSpace or updateSpaceAuthorization

    These functions modify state (_spaces[spaceId], space.configNonce) but have no reentrancy guard. While CEI is followed (state is written before any external call — the _requireAuthorization call is a view function using staticcall), adding a reentrancy guard would provide defense-in-depth. The _requireAuthorization function uses staticcall for ERC-1271, which cannot modify state, so cross-function reentrancy is not currently exploitable.

    INFO-1: ECDSA.recover does not validate v

    The inline assembly extracts v as byte(0, calldataload(...)) without checking for v ∈ {27, 28}. ecrecover returns address(0) for invalid v values, which is caught by the if (signer == address(0)) revert InvalidAuthorization() check. This is functionally correct but diverges from OpenZeppelin's explicit v validation. No security impact.

    INFO-2: AuditGrant.grantAudit does not verify sequence continuity against the registry

    grantAudit accepts fromSequence and toSequence and checks toSequence <= head.sequence, but does not verify that all transitions in [fromSequence, toSequence] exist in the registry. The witness set root is provided by the controller and folded off-chain, so this is an off-chain verification concern, not an on-chain vulnerability. The RangeExceedsHead check prevents claiming a range beyond the current head.

    Conclusion

    The ERC-8350 G4 release candidate implements a sound authorization model with proper EIP-712 typed data signing, monotonic nonces and sequences, hash-chained state transitions, and a layered authorization scheme that correctly handles EOAs, contract wallets (ERC-1271), and EIP-7702 delegated accounts. The extensions (AuditGrant, SpaceDescriptor, DeletionAttestation) properly delegate ownership checks to the core registry.

    No critical, high, or medium-severity vulnerabilities were identified. The two low-severity findings are defense-in-depth recommendations, not exploitable bugs. The two informational notes document intentional design decisions.

    Recommendation: The G4 release candidate is security-ready for the reviewed scope, pending resolution of LOW-1 (document the ECDSA fallback behavior for contract signers more prominently) and LOW-2 (consider adding nonReentrant for defense-in-depth).

    Reviewer compensation: This review was performed independently. If compensation is offered, please contact via GitHub.

  4. XiaoHai67890 commented on Aug 3, 2026

    @XiaoHai67890
    XiaoHai67890
    on Aug 3, 2026
    CollaboratorAuthor

    Project status update — 2026-08-03

    Project-side preparation is complete:

    • the provisional email was triaged in REVIEW_INTAKE_2026-07-31.md
    • LOW-1 is documented under G4-R-003; callback and invalid-v regression tests cover the LOW-2/INFO-1 claims
    • the frozen ten-file scope, threat model, residual-risk register, test/deployment evidence, and reviewer handoff are public
    • PR #19 added the formal release gate: a tag cannot produce an RC release until pnpm security:rc accepts independent review evidence

    Current gate result remains intentionally blocked only because audits/g4/external/external-review.json is absent.

    The reviewer still needs to supply the six corrections listed in the intake: identifiable reviewer ownership, reviewer-controlled public report and attestation, methodology/tool/conflict disclosure, full ten-file scope attestation, corrected API names, and stable finding dispositions with residual-risk mappings. This issue should remain open until those reviewer-owned artifacts are received and manually accepted.

  5. Besmubsa commented on Oct 24, 2026

    @Besmubsa
    Besmubsa
    on Oct 24, 2026

    Independent external review — G4-rc1 evidence record (complete)

    Reviewer: Besmubsa — independent, pseudonymous; no affiliation with AwareLiquid; no compensation requested, offered, or received; no prior work; no conflicts.
    Target: commit af5a75fb2db532fd5603554083d8895a825c2de2 (tag audit/g4-rc1-source, tree f8d66277…a497e).

    Public report (reviewer-controlled repository)

    Scope attestation

    All ten pinned files were reviewed in full (920 lines) and their SHA-256 digests recomputed — 10/10 match audits/g4/scope.json. The canonical manifest digest c9db7d27…3ae9bf and residual-risk-register digest 307a52eb…aa6019 both match the bytes I read (branch security/g4-security-ready-rc).

    Methodology

    solc 0.8.24+commit.e11b9ed9 (optimizer 200, cancun; rc=0 on all runtime contracts and the deployment script via a documented import-prefix harness); slither 0.11.6 (102 detectors, per-target, triaged in the report — no detector output corresponds to a reachable defect); from-scratch Python reimplementation of the golden-vector pipeline — 10/10 PASS (no project code imported); compiled Registry bytecode deployed and executed on py-evm — computeDomainSeparator(1, 0x4444…4444) and EXPERIENCE_DELTA_TYPEHASH() match the vector exactly. Limitations (incl. Foundry suite not executed) are stated in report §4.4.

    API surface confirmation

    Reported against the frozen commit's actual API — registerSpace, updateSpaceAuthorization, commitTransition, head, spaceAuthorization, transition, hashExperienceDelta, computeNextStateRoot, deriveSpaceId, computeDomainSeparator, computeSigningDigest, signingDigest; extensions grant/acknowledge/revoke, attest, publish/clear. The superseded email review's grantAudit/acknowledgeAudit/revokeAudit/getSpaceInfo names are not used.

    Conclusion

    • Unresolved: 0 Critical / 0 High / 0 Medium / 0 Low. 4 Informational (ERG4-I-01…I-04; grant-ID deployment scoping, empty-signature ERC-1271 probe path, descriptorOf read/write asymmetry, raw-v ECDSA interface expectation — all non-blocking, documented with recommendations).
    • Intake dispositions concurred with, independently re-derived: LOW-1 → G4-R-003; LOW-2 → not a finding (STATICCALL propagation argument verified; ERG4-N-01); INFO-1 → fail-closed v handling confirmed; INFO-2 → sequence == head + 1 induction verified.
    • G4-R-012 mitigation verified complete at af5a75f: deriveGrantId includes spaceId; acknowledge/revoke bind via _grantForSpace (WrongSpace); revoke authorizes the origin-Space controller only (V-01 in the report).
    • All twelve residual-risk entries reviewed and mapped (report §8).

    Complete findings, triage, commands, and raw tool outputs are in the evidence repository. Any source change voids this review per reviewRequiredAfterSourceChange.

  6. XiaoHai67890 commented on Oct 28, 2026

    @XiaoHai67890
    XiaoHai67890
    on Oct 28, 2026
    CollaboratorAuthor

    Follow-up for Besmubsa

    Thank you for publishing the report and evidence at
    ac38d3d02ba07a992b92f0029d44802bae8f5154. We verified the report SHA-256
    822d2a3642fe9006945ba8bf074455da6b47b91352c1992606c026ca4be74f6b
    and archived the original report and JSON without modification. XiaoHai
    (@XiaoHai67890) is the current project contact.

    The report is received; G4 acceptance is still pending. Could you publish a
    supplement in your own repository addressing these points?

    1. Complete the template's top-level findings and attestation fields,
      including per-finding dispositions, verification/rationale, appropriate
      residual-risk mappings, timestamp and a full-commit attestation URL.
      Keep unresolved counts consistent with accepted findings.
    2. The v1 gate's reviewedResidualRiskIds means the exact accepted set R-001
      through R-011. Preserve your R-012 mitigation assessment separately as V-01;
      it is not an unresolved accepted High risk. Pin the public report to a full
      commit URL and provide fresh digests if report bytes change.
    3. Replace hardcoded local REPO/SOLC paths in both Python runners with explicit
      arguments, pin the source checkout and all dependencies (especially py-evm,
      eth-tester and pycryptodome), and publish exact clean-environment commands.
      Both runners currently print mismatches without returning nonzero. Please
      make mismatches fail, compare the EVM typehash as well as domain, and add a
      negative-control run. Your Foundry-not-executed limitation should remain
      unless you actually execute and publish those results.
    4. Please review our proposed I-01/I-03/I-04 documentation resolutions and I-02
      clarification: ERC-1271 intentionally accepts arbitrary byte lengths and
      can legitimately validate empty bytes for a digest preapproved in wallet
      state. A blanket 65-byte minimum or mandatory empty-signature rejection
      would break valid wallets. We will document the policy boundary and test
      unapproved digests, short signatures and permissive wallets instead.
    5. Confirm that the current release is not implicitly covered: versus af5a75f,
      baseline 37b2e416f57305b6d38953bb6af351ee487c581a differs in interface
      NatSpec, Foundry import configuration and expanded v1 vector inputs. The
      scoped runtime sources are unchanged. Please state the addendum/new-candidate
      review required before a release; the original frozen tag will not move.
    6. Clarify the report's absolute replay/zero-hash wording: replay claims remain
      scoped to finality/domain assumptions (R-007), and zero Space IDs are rejected
      explicitly rather than being impossible keccak outputs. Please also provide
      a brief account of your review experience and human responsibility/process so
      the maintainer can assess review quality; no private identity documents are
      requested.

    These are requests for your confirmation, not statements that you have already
    approved the maintainer changes. We are not requesting changes to the original
    immutable evidence and are not proposing compensation or a commercial engagement.

  7. XiaoHai67890 commented on Nov 1, 2026

    @XiaoHai67890
    XiaoHai67890
    on Nov 1, 2026
    CollaboratorAuthor

    @Besmubsa A new runtime delta now needs explicit review in addition to the October 28 supplement request. PR #34 fixes AQ-03: abi.decode(bytes4) could abort on dirty ABI padding before a valid ECDSA fallback. Both local Registry copies now strictly compare the full bytes32 word; dirty magic-prefix data does not authorize. Runtime patch commit: 4fd2a26 (full pin in spec-baseline-2.json).

    Audit delta: https://github.com/AwareLiquid/AgentMemoryState/blob/1771b42f5321c1df6fb69f0513eacdf745a20f39/docs/security/aq03-runtime-delta.md
    New account tests and exact build boundaries: #35

    The original af5a75f frozen target/report/tag are unchanged. We are NOT treating the old review as coverage of these new runtime bytes. Could you publish a reviewer-controlled addendum assessing this exact diff, its regression tests and candidate/source identity, along with the previously requested findings/attestation, risk mapping and portable fail-closed runners? Please state what you actually execute, the limitations, and any additional review required before release.

    Local pnpm check passes (118 Solidity tests); the separate account suite passes 58 cases plus mined local type-4 nonce/stale-authorization checks. These are maintainer results, not your verification. No corrected public deployment, canonical G4 acceptance or production-ready claim has been made. XiaoHai remains the current contact; no commercial engagement is requested.

  8. XiaoHai67890 commented on Nov 6, 2026

    @XiaoHai67890
    XiaoHai67890
    on Nov 6, 2026
    CollaboratorAuthor

    @Besmubsa A short update to the existing addendum request: the AQ-03 correction and associated authorization wording are now proposed upstream in ethereum/ERCs#2147, exact candidate 397426c046049e1a0c3436e543f9731408708fd3.

    The candidate Registry SHA-256 is 94c7f39920205ae581e6537828a80a3dcfeb0a283c833ed2b50bc10927a292c3. It is byte-identical to the corrected local CC0 asset. A pinned reproduction runner and review packet are in #38 (runner 9e8dd09c776ef1d27e8b71ea8283d0dd6610ac14).

    From that runner checkout:

    cd contracts
forge install foundry-rs/forge-std@v1.16.2 --no-git
cd ..
node --test scripts/review-candidate.test.mjs
node scripts/review-candidate.mjs

    Node 22 and Foundry 1.7.1 are used. Expected outcomes: 9 runner tests pass; 38 candidate authorization/signature tests pass; exactly the two named old-source dirty-padding tests fail as a negative control. Downloads are commit/SHA-256 pinned; logs identify the actual harness commit. These are maintainer-generated results and are not attributed to you.

    Please assess the exact runtime delta and proposed return-word/fallback semantics in a reviewer-controlled supplement, stating what you execute, limitations, findings/dispositions and current-source coverage. The earlier structured findings/attestation and portable fail-closed runner requests still apply. The original frozen af5a75f report/tag remain unchanged; no canonical G4 acceptance, corrected deployment or production-ready claim is inferred from these tests.

  9. XiaoHai67890 commented on Nov 6, 2026

    @XiaoHai67890
    XiaoHai67890
    on Nov 6, 2026
    CollaboratorAuthor

    @Besmubsa The source identity in the existing supplement request is now finalized upstream: ethereum/ERCs#2147 merged at 8b11215cf267f710b49ea003384e678bcf953eae. The Registry remains byte-identical to the candidate you were sent, SHA-256 94c7f39920205ae581e6537828a80a3dcfeb0a283c833ed2b50bc10927a292c3; this update changes the accepted source pin, not the runtime bytes.

    Project #39 is merged at f654fe023909ef93e1478e79dbcee7cbd7b05835. Please use that checkout for the updated runner:

    cd contracts
forge install foundry-rs/forge-std@v1.16.2 --no-git
cd ..
node --test scripts/spec-baseline.test.mjs scripts/review-candidate.test.mjs
node scripts/review-candidate.mjs --official

    Node 22 / Foundry 1.7.1; expected: 47 runner/baseline tests pass, 38 exact official-source tests pass with zero skips, and exactly two named old-source AQ-03 failures are reproduced as a negative control. Fresh main exact-source CI and artifacts.

    Runtime delta and review boundaries and review packet.

    The prior request for a reviewer-controlled supplement, structured findings/attestation, risk mapping and portable fail-closed reproduction remains outstanding. Please identify actual executed checks, exact source coverage and limitations; maintainer CI is not attributed to you. The original frozen af5a75f target/report/tag are preserved.

    The full G4 gate still fails because canonical external-review acceptance is missing. No corrected public deployment, current-runtime audit acceptance or production-ready claim has been made. The separate ethereum/ERCs#2148 request is for peer Review only and does not close this audit requirement. No commercial engagement is requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions