Pre-ERC: Agent Pre-Sign Risk ReportPre-ERC: Agent Pre-Sign Risk Report is a draft Ethereum Magicians proposal for an EIP-712-signed report that a risk source, identified by an ERC-8004 identity, returns about one unsigned request. It carries typed findings on tokens, approvals, addresses, payments (x402) and texts, and each finding is marked read or not read. It has no score or verdict, so the consumer applies its own policy. The author's live implementation, toll, runs on Robinhood Chain.
ethereum-magicians.orgthreadPublished and added 31 Oct 2026π‘οΈ Security
Pre-ERC: Agent Pre-Sign Risk ReportPre-ERC: Agent Pre-Sign Risk Report is an Ethereum Magicians draft for a signed, typed report that a risk source returns about one unsigned agent transaction. The report is bound to the request by a digest and signed with EIP-712 by an ERC-8004 identity. Findings cover tokens, approvals, addresses, x402 payments and texts, each marked read or not read, with no score or verdict. The toll service runs it live on Robinhood Chain.
ethereum-magicians.orgthreadPublished and added 31 Oct 2026π§ AI
Pre-ERC: x402 Payee Verification for ERC-8004 AgentsPre-ERC draft on Ethereum Magicians that binds the x402 payTo address to an ERC-8004 agent's registered agentWallet, directly or through an EIP-712 payee delegation (ERC-1271 for contract wallets). It lists eight fixed checker outcomes and requires the resource origin to appear in the registration file. On Robinhood Chain (28 October 2026), 5,575 of 20,046 agents answered with x402 requirements, and only 5 used their agentWallet as payTo.
ethereum-magicians.orgthreadPublished and added 30 Oct 2026π‘οΈ Security
ERC-8478: x402 Payee Verification for ERC-8004 AgentsERC-8478 is a draft Ethereum standard that binds the payTo address in an x402 payment requirement to the seller's ERC-8004 agent identity. A payer compares payTo with the registered agentWallet, or accepts an EIP-712 payee delegation signed by it, and checks that the origin is listed in the registration file. On Robinhood Chain, 5 of 5,575 x402-responding agents had payTo equal to agentWallet (28 October 2026).
ethereum-magicians.orgthreadPublished and added 30 Oct 2026π§ AI
ERC-8478: x402 Payee Verification for ERC-8004 AgentsERC-8478 is a draft Ethereum standard that binds the x402 payTo address to an ERC-8004 agent's identity, to stop payee redirection by a hijacked domain, proxy or injected tool result. A payTo must equal the agentWallet or carry an EIP-712 delegation signed by it, and the origin must be listed in the registration file. On Robinhood Chain, 5 of 5,575 x402-responding agents used their agentWallet as payTo (28 October 2026).
ethereum-magicians.orgthreadPublished and added 30 Oct 2026π‘οΈ Security
Pre-ERC: x402 Payee Verification for ERC-8004 AgentsPre-ERC draft on the Ethereum Magicians forum that ties the payTo address in an x402 payment requirement to the seller's ERC-8004 agent identity. The payTo must equal the registered agentWallet or an EIP-712 delegation signed by it, and the origin must be listed in the registration file. A checker returns one of eight fixed outcomes. On Robinhood Chain, 5 of 5,575 x402-enabled agents out of 20,046 used their agentWallet as payTo.
ethereum-magicians.orgthreadPublished and added 30 Oct 2026π§ AI
EIP Draft: Permanent EOA Delegation Opt-Out (disable EIP-7702)Discussion thread for a draft Core EIP that lets an Ethereum EOA permanently disable EIP-7702 delegation. A type-4 set-code transaction with an empty authorization list, destination equal to sender and zero value installs the 0xef0200 marker for 33500 gas. Later authorizations, including clearing to the zero address, are skipped. It does not protect against private-key compromise. Open questions cover the prefix, a dedicated transaction type, gas pricing, and EIP-8151 interaction.
ethereum-magicians.orgthreadPublished and added 30 Oct 2026π‘οΈ Security
Draft ERC: Agent Safety Framework (ASF) β attributable adoption of versioned safety specificationsDraft ERC "Agent Safety Framework (ASF)" on Ethereum Magicians (ethereum/ERCs PR #2113). It defines versioned, content-addressed Safety Specifications and on-chain Safety Bindings. A binding records which adopter accepted which pinned spec version for a subject and scope, with named interveners who can suspend, resume or terminate. A pure-registry check() returns Satisfied, NotSatisfied or Unknown, and Unknown never counts as satisfied. Reference consumers ASFGuardedAccount and ASFTaskTenderAdapter come with 73 tests, 47 of them negative.
ethereum-magicians.orgthreadPublished and added 25 Oct 2026π‘οΈ Security
Draft ERC: Agent Safety Framework (ASF) β a registry of versioned safety specifications and of the scoped, attributable adoption relations that bind agents to themAgent Safety Framework (ASF) is a draft ERC on Ethereum Magicians that defines two on-chain objects: a versioned, content-addressed Safety Specification and a Safety Binding, in which an adopter pins one spec version for a subject and scope. A registry check() returns Satisfied, NotSatisfied or Unknown. Bindings support derived delegation, and suspensions come in five graded restrictions. Reference consumers are ASFGuardedAccount and ASFTaskTenderAdapter, with 73 tests, 47 of them negative.
ethereum-magicians.orgthreadPublished and added 25 Oct 2026π§ AI
Draft ERC: Agent Safety Framework (ASF) β a registry of versioned safety specifications and of the scoped, attributable adoption relations that bind agents to themAgent Safety Framework (ASF) is a draft ERC on Ethereum Magicians for an on-chain registry of versioned, content-addressed safety specifications and of Safety Bindings. A binding records that an adopter accepted one pinned spec version for a subject and scope, with declared enforcement locations, named interveners and a lifecycle (Active, five Suspended restrictions, Terminated). A check(requirement, bindingIds) call returns Satisfied, NotSatisfied or Unknown, and Unknown never counts as satisfied. Reference consumers ASFGuardedAccount and ASFTaskTenderAdapter come with 73 tests, 47 of them negative.
ethereum-magicians.orgthreadPublished and added 25 Oct 2026π‘οΈ Security
ERC-8468: Agent Safety Framework (ASF)ERC-8468, the Agent Safety Framework (ASF), is a draft Ethereum standard with two on-chain objects: a versioned Safety Specification and a Safety Binding with suspend, resume and terminate rights. A check() call returns Satisfied, NotSatisfied or Unknown at the moment of effect. Revision 6 has reference contracts, 90 tests and a Sepolia run of 36 transactions in October 2026, and the thread asks reviewers five design questions.
ethereum-magicians.orgthreadAdded 27 Oct 2026, published 25 Oct 2026π§ AI
ERC-8468: Agent Safety Framework (ASF)ERC-8468 (Agent Safety Framework, ASF) is a draft Ethereum standard, now at revision 6, for recording which participants accepted which safety requirements for an AI agent, in which version, enforced where, and whether that acceptance is in force now. It defines a versioned Safety Specification, an on-chain Safety Binding with interveners holding suspend, resume and terminate rights, and a check() that returns Satisfied, NotSatisfied or Unknown. The reference guarded account and task-tender adapter passed 90 tests (64 negative) and a Sepolia run of 36 transactions.
ethereum-magicians.orgthreadAdded 27 Oct 2026, published 25 Oct 2026π‘οΈ Security
Draft ERC: Agent Safety Framework (ASF) β attributable adoption of versioned safety specificationsAgent Safety Framework (ASF) is a draft ERC (ethereum/ERCs pull request #2113) for an on-chain registry that records which participants adopted which versioned safety specification, for what subject and scope, and where it is enforced. It defines two objects (Safety Specification, Safety Binding) and a registry check returning Satisfied, NotSatisfied or Unknown. Two reference consumers and 73 tests (47 negative) are reported, and the post asks the community four design questions.
ethereum-magicians.orgthreadPublished and added 25 Oct 2026π§ AI
ERC-TBA: Agent Income StatementsERC-TBA: Agent Income Statements is a draft Ethereum standard, a profile of the ERC-8004 Reputation Registry. A writer posts chained statements of what an agent's agentWallet received in one asset, with each incoming transfer a Merkle leaf, so lenders and buyers can verify earnings from x402 payments. Windows are cut at owner or wallet changes, and the post asks about statement grain, the MetadataSet requirement and who may write. The reference implementation is unaudited.
ethereum-magicians.orgthreadPublished and added 22 Oct 2026π§ AI
Trail of Bits (@trailofbits) on XTrail of Bits thread on Google Quantum AI's March publication of a new Shor's algorithm version aimed at secp256k1, the curve protecting Bitcoin and Ethereum wallets. Google used zero-knowledge proofs to keep the attack details secret, and the post says the secrecy lasted 63 days. The fetched text is cut off after the qubit estimate of roughly 1,200, so later details are missing.
x.comthreadAdded 22 Oct 2026, published 20 Oct 2026π‘οΈ Security
ERC-8447: Swarm AI FrameworkERC-8447 (Swarm AI Framework) is a draft Ethereum standard proposing an on-chain registry and charter model for swarms: purpose-bound agent collectives with a membership boundary, an objective with attainment rules and a declared collaboration structure. Executed terms are hashed into a frozen spec, while the charter is kept off-chain. The reference implementation has 85 Foundry tests and tender and ERC-8436 decision adapters. The thread asks reviewers about vocabulary, amendment classes and the ERC-8004 dependency.
ethereum-magicians.orgthreadAdded 19 Oct 2026, published 18 Oct 2026π§ AI
[Draft ERC] Swarm AI Framework β registry and charter model for purpose-bound agent swarmsEthereum Magicians discussion of a draft ERC, the Swarm AI Framework. It proposes a registry and charter model in which accounts, including autonomous agents, form, bound, run and dissolve purpose-bound swarms. A hashed on-chain SwarmSpec (roles with eligibility modules, phases, decision authorities, fallback timers) is paired with an off-chain Swarm Pack charter. Two-sided signed admission (EIP-712 / ERC-1271), challenge and substitution, and minor versus material amendments are included. Phase posture is a coordinate: executed boundary and admission, plus declared payoff, topology and coordination terms from a write-once vocabulary. This lets cooperation, competition, tenders, debate, ensembles and pipelines be expressed. It integrates with ERC-8004 agent identity and ERC-8436 decision adapters. The reference implementation is a non-upgradeable registry with five eligibility modules and a task-tender adapter. The post asks reviewers specific design questions on vocabulary, amendment classes, roster snapshots and digest kinds.
ethereum-magicians.orgthreadPublished and added 18 Oct 2026π§ AI
Draft ERC: Agentic Resource Discovery (ARD) Onchain β an address-rooted value registry whose records are ARD entriesEthereum Magicians draft ERC proposing an onchain, address-rooted registry beneath Google's Agentic Resource Discovery (ARD) spec. Every record remains a valid ARD entry. It adds four kinds (skill, task, agent, registry), CAIP-19/CAIP-10 anchors, JCS+SHA-256 descriptor hashes and domain claims collected as endorsements. A Solidity/Foundry reference kernel with four adapters and a Node.js resolver/gateway are included; the gateway passes the official ARD conformance CLI. The author asks for feedback on the address-as-root boundary, the envelope exclusion from the hash, same-chain-only anchors, and the proposed application/ai-task+json payload.
ethereum-magicians.orgthreadPublished and added 13 Oct 2026π§ AI
ERC-8444: Agentic Resource Discovery (ARD) OnchainAn Ethereum Magicians proposal for ERC-8444, which adds an onchain value and settlement layer under Google's Agentic Resource Discovery (ARD) spec for finding MCP servers, A2A agents, skills and APIs. A thin kernel records kind (skill, task, agent, registry), a CAIP-19/CAIP-10 anchor, a JCS+SHA-256 descriptor hash, a canonical URN and a status. Authority belongs to the paid address, and domains act as collected endorsements through /.well-known/ard.json. The reference implementation has Foundry-tested Solidity adapters and a Node.js gateway that passes the official ARD conformance CLI. It introduces a "task" kind (application/ai-task+json) for tenders aimed at suppliers, and the author asks for feedback on the trust root, the hash scope, same-chain anchors and the task payload.
ethereum-magicians.orgthreadAdded 14 Oct 2026, published 13 Oct 2026π§ AI
[Pre-ERC Discussion] Agent Service Order AmendmentsEthereum Magicians pre-ERC discussion proposing a signed, EIP-712 amendment object for changing an existing agent service order (scope, acceptance criteria, price increase, deadline extension) without losing the prior agreement or implicitly authorizing extra spending. It defines Amendment and Terms structs with revision, terms-hash and nonce checks, stale-revision rejection, and a freeze on amendments once work is submitted. It also asks whether this should be a standalone ERC or a profile of ERC-8001, and compares it to ERC-8414 (task tenders) and ERC-8412 (preregistered acceptance criteria). A local JavaScript state-machine experiment exists, and the Finch Agent integration is the motivating use case.
ethereum-magicians.orgthreadPublished and added 10 Oct 2026π§ AI
ERC-8441: Hybrid post-quantum stealth address schemeA draft Ethereum ERC (ERC-8441) proposes schemeId 3 for ERC-5564 stealth addresses, combining an ML-KEM-768 encapsulation with a secp256k1 ECDH secret so that quantum adversaries who later break discrete log still cannot deanonymize who was paid in past public announcement logs, protecting against harvest-now-decrypt-later attacks. Spending remains classical secp256k1 and unprotected once quantum computers exist; the authors flag open issues including a documented downgrade attack (recipients registered under both scheme 1 and 3 can still be paid without PQ protection), the lack of a formal ANO-CCA proof for standardized ML-KEM, and a non-NIST-approved secret combiner. It reuses the existing ERC-5564 announcer and ERC-6538 registry with no contract changes, costing 111,330 gas per payment.
ethereum-magicians.orgthreadPublished and added 9 Oct 2026π‘οΈ Security
Formalization of the Invariant Duality TheoremAn Ethereum Magicians forum post formalizes an "Invariant Duality Theorem": in a permissionless network, a protocol cannot simultaneously achieve Perfect Indistinguishability (traffic statistically indistinguishable from white noise under DPI) and Resource Exhaustion Resistance (O(1) early rejection of junk packets). The proof sketch argues that indistinguishable traffic forces receivers to run expensive deobfuscation on all packets including attacker-generated noise (enabling DoS), while any cheap early-filter function, by Kerckhoffs's principle, becomes a public signature a censor can hardware-implement to block the protocol. This is a theoretical tradeoff relevant to designing or attacking covert/anti-censorship transport protocols.
ethereum-magicians.orgthreadPublished and added 6 Oct 2026π‘οΈ Security
EIP-TBD: Resolution β Non-Self-Authorizing State TransitionsA draft EIP ("Resolution") posted to Ethereum Magicians proposes a formal authority boundary separating "valid/computed/proven" from "authorized to change state," with a Resolve() function returning AUTHORIZED, UNAUTHORIZED, or UNRESOLVED. It generalizes a pattern the author sees already present piecemeal in ERC-7710 (delegation possession vs. exact capability), ERC-8196 (autonomous transaction vs. owner policy proof), and ERC-8354 (proposed action vs. policy verdict), arguing composition must be authority-non-expansive so recovery proofs, provenance commitments, and agent-generated candidate transactions can't silently acquire authority they weren't granted.
ethereum-magicians.orgthreadPublished and added 3 Oct 2026π‘οΈ Security
ERC-8427: Portable Spend GrantsERC-8427 'Portable Spend Grants' is a draft Ethereum standard defining a signed SpendGrant object that lets a principal authorize a delegate (e.g. an AI agent or session key) to spend up to specified per-call, trailing-24h, and lifetime caps of named assets, to a restricted set of recipients, within a validity window β solving problems that plain ERC-20 approve and midnight-resetting daily caps don't. A non-custodial registry tracks remaining usage and revocation while an immutable executor contract must call consume() in the same transaction as any transfer, so unauthorized value movement is provably blocked; the reference implementation is deployed on Arc testnet with formal verification (Halmos) of expiry, cap, revocation and executor-binding invariants plus fuzzing of the rolling-window logic. The thread also discusses interplay with ERC-7710/7715 delegation/permission RPCs, ERC-8226's regulated grants, and ERC-8312's usage-tracking pattern, and solicits feedback on EIP-7702 signer/delegation ordering and executor-vs-delegate binding in consume().
ethereum-magicians.orgthreadAdded 29 Sep 2026, published 25 Sep 2026π‘οΈ Security
Formal Verification of Execution and Consensus ClientsA reply on the Ethereum Research forum (ethresear.ch) responding to @pcaversaccio's call for formally verifying hard-fork changes in Ethereum execution and consensus clients before mainnet activation. It surveys current formal-verification efforts (Etheorem/SizzLean in Lean 4 for consensus/SSZ, Verifereum in HOL4 for the EVM), argues for prioritizing high-leverage surfaces like SSZ, state transition, fork-choice and core EVM semantics, and pushes for stronger verification tooling in Rust (Aeneas/Verus/hax) as an incremental path to reducing the trusted computing base of client software.
ethresear.chthreadAdded 29 Sep 2026, published 25 Sep 2026π‘οΈ Security
ERC-8424: Confidential Real World Asset TokenA security review posted on Ethereum Magicians critiques draft ERC-8424 (Confidential Real World Asset Token, extending ERC-7984), pointing out that its confidentialCanTransfer and confidentialAvailableBalanceOf functions have no caller restriction on who can resolve the returned FHE pointer, enabling any party to binary-search an encrypted balance to plaintext in at most 64 oracle calls. It also flags that the spec's revert clause for amount-dependent rules (vesting, balance caps) leaks a disclosure bit even without decryption, and recommends narrowing reverts to plaintext-only rules and restricting pointer resolution the way OpenZeppelin's ERC7984Freezable.confidentialAvailable already does via FHE.allow(amount, account).
ethereum-magicians.orgthreadAdded 29 Sep 2026, published 25 Sep 2026π‘οΈ Security
EIP-8425: Quantum Freeze and Account RecoveryA detailed reply on the Ethereum Magicians forum thread for EIP-8425 ("Quantum Freeze and Account Recovery"), which specifies how Ethereum accounts should transition authority when their legacy ECDSA key could be broken by a quantum adversary. The author formalizes a FROZEN/CLAIMED/RESOLVED-CONTESTED-UNRESOLVED/SUCCESSOR recovery state machine, replay-resistant claim hashes bound to a per-account recoveryEpoch, and two core invariants preventing a compromised ECDSA key from unilaterally establishing successor authority, closing an attack case where a quantum adversary obtains the key before the protocol's SAFE_RECOVERY_TIME cutoff. It also references related EIPs on signature-algorithm agility (EIP-7932) and PQ/STARK signature aggregation (EIP-8288).
ethereum-magicians.orgthreadAdded 29 Sep 2026, published 24 Sep 2026π‘οΈ Security
Standard for "transferable to arbitrary addresses" on tokenized RWAs? (locked v4 pools quoted in tokenized stocks)An Ethereum Magicians forum thread dissects a novel rug/bricking vector emerging from a launchpad (sender.family) that locks 100% of token supply forever into a single one-sided Uniswap v4 position, where the quote asset can be a KYC-gated tokenized stock (Ondo's NVDA/TSLA/AAPL tokens) rather than ETH or a stablecoin. Because Uniswap v4 routes all pool balances through a shared PoolManager singleton and pays swap/fee output to arbitrary addresses, the RWA issuer must permanently allowlist the PoolManager and any counterparty; if the issuer later tightens its transfer-registry rules, the permanently locked pool becomes irrecoverable with funds stuck inside. The author notes the launchpad's current mitigation is only an empirical point-in-time transfer test (moving a balance between two addresses) against an asset with an admin-controlled, stateful ERC-3643 canTransfer function, and asks whether there's any way to verify "transferable to arbitrary addresses" onchain before pool creation, and whether permanent lockers should categorically refuse upgradeable/pausable quote assets.
ethereum-magicians.orgthreadAdded 29 Sep 2026, published 24 Sep 2026π‘οΈ Security
ERC-8419: Know-Your-Agent (KYA) FrameworkA technical forum post on Ethereum Magicians dissecting security gaps in ERC-8419 "Know-Your-Agent" (KYA), a proposed on-chain trust/attestation framework for AI agents that bridges to ERC-8004. The author walks through concrete exploit scenarios β a controller-bound assertion that still evaluates as valid after the underlying agent NFT is transferred, a policyId that can commit to a stricter policy document than the executable rules that actually run on-chain, ERC-8004 bridge configuration (trustedIssuers/responseMap) changes that silently alter what an existing request means, upgradeable verifier proxies that let a schemeId acquire new proof-admission semantics post-hoc, and missing chain/registry domain separation enabling cross-registry ZK nullifier replay β and proposes normative invariants (binding witnesses, rulesHash commitments, configHash, semantic immutability, mandatory domain separation) to close each one.
ethereum-magicians.orgthreadAdded 29 Sep 2026, published 19 Sep 2026π‘οΈ Security