Best of eips.ethereum.org on Kiwi News
Most upvoted by Kiwi News readers
16 stories from eips.ethereum.org have been shared on Kiwi News since 18 May 2023, with 36 upvotes and 1 comment in total. The latest was shared on 5 September 2026. They are listed below, most upvoted first.
Text under a title is an AI summary of the linked article.
- ERC-7512: Onchain Representation for Audits
ERC-7512 proposes a standard for an onchain representation of audit reports that smart contracts can parse to extract details such as who performed an audit and which ERCs were verified. Authors listed include Richard Meissner (Safe), Robert Chen (OtterSec), and Matthias Egli (ChainSecurity), among others. A signed audit summary would indicate that a specific contract instance, identified by its chainId and deployment address, underwent a security audit and correctly implements the listed ERCs. The draft states that it is not an attestation of a contract's security, and it leaves the findings of audits out of scope.
- EIP-7701: Native account abstraction
EIP-7701 proposes native account abstraction for Ethereum, splitting transaction processing into validation, execution, and post-operation steps, and it is now withdrawn as superseded by EIP-8141. The proposal, authored by Vitalik Buterin, Yoav Weiss, Alex Forshtat, Dror Tirosh and Shahaf Nacson and created on 2024-05-01, uses a new transaction type and a family of opcodes. It lets one contract pay gas for a transaction executed from another contract, and it introduces CURRENT_ROLE and ACCEPT_ROLE opcodes. The specification sets AA_BASE_GAS_COST at 15000 and charges an additional 2400 gas when a non-sender Paymaster or Deployer address is provided.
- EIP-7791: GAS2ETH opcode: direct conversion of gas into ether
EIP-7791 proposes a new EVM opcode, GAS2ETH, that lets smart contracts convert gas directly into ETH so that contract authors and public goods projects can be compensated in proportion to their contracts' usage. Authors Charles Cooper and pcaversaccio created the draft, dated 2024-08-13, which requires EIP-2929. Under the specification, each transaction has a global GAS2ETH budget equal to its gas limit, and each call frame receives a local allowance derived from the gas forwarded to it. The proposed opcode cost matches the recently proposed PAY opcode, and the draft's test cases and reference implementation are still marked TBD.
- EIP-5792: Wallet Call API
EIP-5792 is a Final Standards Track interface proposal that adds JSON-RPC methods for wallets to send batches of onchain calls and check their status, authored by Moody Salem and twelve other named contributors and created on 2022-10-17. The standard requires EIP-1193 and adds three batching methods, wallet_sendCalls, wallet_getCallsStatus and wallet_showCallsStatus, plus wallet_getCapabilities for discovering wallet features such as the atomic capability. Its stated motivation is that eth_sendTransaction and eth_getTransactionReceipt cannot batch calls or support features like ERC-4337 paymasters. Apps may use the new methods immediately, falling back to the older methods when they are unavailable.
- EIP-7212: Precompiled for secp256r1 Curve Support
- EIP-8141: Frame Transaction
EIP-8141 is a draft Core standards-track proposal, authored by Vitalik Buterin, lightclient, Felix Lange and others, that adds a Frame Transaction type (FRAME_TX_TYPE 0x06). The transaction is decomposed into a sequence of frames, which are contract calls that validate the transaction, approve gas payment, and execute user operations. The stated motivations include a native path to post-quantum secure systems, native key rotation, native batch call processing, and alternative fee payment without centralized relayers. The specification defines frame modes (DEFAULT, VERIFY, SENDER), signature schemes (ARBITRARY, SECP256K1, P256), gas constants, and a receipt format that records the payer and per-frame gas usage.
- ERC-8004: Trustless Agents
ERC-8004 proposes a blockchain-based protocol for agents to discover, choose, and interact with one another across organizational boundaries without prior trust. It defines three lightweight registries: an Identity Registry built on ERC-721 that gives each agent a portable identifier resolving to a registration file, a Reputation Registry for posting and fetching feedback signals, and a Validation Registry for requesting and recording independent validator checks. The text says trust models are pluggable and tiered, with security proportional to value at risk, and lists reputation systems, stake-secured re-execution, zkML proofs and TEE oracles as options. It notes that payments are not covered, though examples show how x402 payments can enrich feedback signals.
- EIP-7639 - Prune calldata
EIP-7639, authored by lightclient, proposes that Ethereum execution layer clients stop requesting or serving peer-to-peer block data from before the Paris upgrade, which activated proof of stake. The proposal adds an eth protocol version 70 under which clients must not make or respond to queries about block bodies or receipts before block 15537393. The text states that historical data in clients has grown to around 500 GB, with nearly 400 GB coming from pre-PoS block data. It also notes that nodes would no longer be able to full sync from the devp2p network after activation and would need to retrieve the data out-of-band.
- EIP-7773: Hardfork Meta - Amsterdam
This Ethereum Improvement Proposal lists the EIPs proposed, considered, declined, and scheduled for inclusion in the Glamsterdam network upgrade, and it is currently marked for review. The scheduled list includes EIP-2780 (resource-based intrinsic transaction gas), EIP-7732 (enshrined proposer-builder separation), EIP-7928 (block-level access lists), and EIP-8246 (removing the SELFDESTRUCT burn), among eighteen others. The document is authored by Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo, and Parithosh Jayanthi, and was created on 2024-09-26. Activation times for Sepolia are listed as epoch 353024 and timestamp 1791294816 (2026-10-06 13:53:36 UTC), while the Hoodi and Mainnet rows remain unfilled.
- ERC-3770: Chain-specific addresses
ERC-3770 is a draft Ethereum standard that proposes prefixing chain-specific addresses with a human-readable chain short name, such as "shortName:address". The proposal states that as EVM-compatible chains grow, the same address may refer to an externally owned account on one chain and a smart contract on another, which could cause users to lose funds through human error, for example by sending funds to a smart contract wallet address not deployed on that chain. It notes that EIP-155 chain IDs could serve as the prefix but were designed for developer interoperability rather than display to users. The short name must come from the ethereum-lists chains repository, and the address must be ERC-55 compatible. The draft also warns that similar-looking chain short names could confuse users.
- Intro to CCIP-Read: Secure offchain data retrieval
CCIP Read is an Ethereum standard, now at Final status, that lets a smart contract fetch external data without storing it all onchain. Under the specification, a contract reverts with an OffchainLookup error containing a gateway URL template, the callData to send, a callback function selector, and extraData. The client queries the gateway, then calls the callback on the contract, which decodes and verifies the response. The standard is authored by Nick Johnson (@arachnid) and was created on 2020-07-19. The text states that in many cases this can be done without trust assumptions beyond those needed for data stored onchain.
- Allow EOAs to send a one-time transaction which deploys code at their account.
EIP-7377 proposes a new one-time migration transaction type that lets an externally owned account (EOA) set its own code, converting it into a smart contract wallet at the same address. The authors, lightclient, Sam Wilson and Ansgar Dietrichs, argue that migrating each asset individually is too costly and time-consuming for users, so a protocol-level mechanism is needed. The transaction sets the sender's code to the code at a referenced address, applies specified storage values, and then executes a call into the account. The proposal is marked stagnant, and it notes risks such as blind signing and private keys that may still control migrated accounts.
- ERC-7806: Minimal intent-centric EOA smart account
ERC-7806 proposes a standard interface that lets externally owned accounts (EOAs) delegate contract code to a smart account implementation and sign intents that solvers or relayers can execute on their behalf. The draft builds on EIP-7702, which introduces SET_CODE_TX_TYPE=0x04 so EOAs can set contract code. It is presented as an alternative to ERC-4337, whose limitations the draft lists as complexity, upgrade compatibility, gas cost and reliance on centralized entities such as Paymasters. The standard defines an IStandard interface for validating intents and an IAccount interface for executing them, and a single account implementation can be shared across multiple EOAs.
- ERC-4527: QR Code transmission protocol for wallets
ERC-4527 proposes a standard process and data transmission protocol for transferring data via QR codes between offline signers, which hold private keys without network access, and watch-only wallets, which have network access. The proposal builds on the Uniform Resources (UR) protocol from BlockchainCommons, extending it with animated QR codes and CBOR encoding. It defines new UR types, eth-sign-request for sending unsigned data and eth-signature for returning signatures, along with reuse of the existing crypto-hdkey and crypto-keypath types for public key setup. The article argues QR codes offer better transparency, compatibility, user experience and a smaller attack surface than USB, Bluetooth or file transfer. The Test Cases and Reference Implementation are in the ur-registry-eth package released by the Keystone team.
- EIP-7503: Zero-Knowledge Wormholes
EIP-7503 proposes adding a minting function to Ethereum so users can re-mint Ethers they previously burned, using zero-knowledge proofs to keep the link between burn and mint private. The authors are Keyvan Kambakhsh, Hamid Bateni, Amir Kahoori, Nobitex Labs and 0xwormhole, and the proposal is listed as Stagnant on the Core track. Deposits are sent to an address derived from a secret, and withdrawals require a proof of knowledge of that secret, with change deposits hashed so original amounts cannot be recovered. The draft requires EIP-7708 and a proof-of-work requirement of 24 bits, and it caps deposits at 32 ETH to limit hash collision attacks. The reference implementation and ZK-SNARK design are marked TBD.
- ERC-6551: Non-fungible Token Bound Accounts
ERC-6551 proposes a system that assigns an Ethereum smart contract account to every non-fungible token, so NFTs can own assets and interact with applications without changes to existing NFT contracts. The proposal defines a singleton registry that computes and creates these token bound accounts, with each account permanently bound to one NFT and controlled by that NFT's holder. The registry is described as permissionless, immutable and ownerless, and it is to be deployed at a specified address using Nick's Factory. Each account is an ERC-1167 minimal proxy whose deterministic address derives from its implementation, salt, chain ID, token contract and token ID.