Best of ethereum-magicians.org on Kiwi News
Most upvoted by Kiwi News readers
41 stories from ethereum-magicians.org have been shared on Kiwi News since 13 June 2023, with 99 upvotes and 14 comments in total. The latest was shared on 7 April 2026. They are listed below, most upvoted first.
Text under a title is an AI summary of the linked article.
- A maximally simple L1 privacy roadmap
The author's roadmap proposes practical privacy improvements for Ethereum users that require few consensus changes, covering onchain payments, partial anonymization within applications, RPC read privacy, and network-level anonymization. Key steps include adding privacy tools such as Railgun and Privacy Pools to existing wallets with a default "send from shielded balance" option, and moving toward one address per application by default. The roadmap also proposes implementing FOCIL and EIP-7701, using TEE-based RPC privacy as a short-term mitigation (with Automata's existing version to be verified and hardened), and eventually replacing TEEs with private information retrieval.
- Call for contributions: Ethereum Magicians
The Fellowship of Ethereum Magicians forum is seeking contributions to improve the forum, with a call for volunteers to help with curation and moderation. The post proposes more moderators, a dedicated home for AllCoreDevs and breakout calls, banners or pins for upcoming calls, and templates for each category. It also suggests using the Discourse AI plugin and generating newsletter or RSS-style updates so users can subscribe to specific categories. A one-month period is proposed for submitting logo and category icon designs, followed by a poll starting 2024-09-14T22:00:00Z.
- it's ok to allow stage 1 rollups shorter withdrawal windows (1-2 days)
The author argues that stage 1 rollups can safely use shorter withdrawal windows of 1-2 days, while stage 2 rollups should keep 7-day windows because they must resist a 51% attack like Ethereum itself. The 7-day figure comes from an assumed timeline in which a 51% censorship attack takes about six days to fork out, based on Ethereum's 2016 Tangerine Whistle fork. The author says 1-2 days covers fraud-proof timing against sleep periods and a 12-hour 2016 consensus failure, and proposes a security council switch that could extend the delay to 7 days or longer. For stage 2, the author expects 2-of-3 schemes with ZK or TEE proofs to deliver near-instant withdrawals in normal cases.
- Ethereum R1: The Neutral Rollup for Ethereum
Ethereum R1 is a proposed rollup project that its founders present as a public, neutral alternative to L2s they say have become controlled by small groups of insiders. The project is described as fully donation-funded with no token or private sales, relying only on public ETH contributions. It is said to launch as Stage 2 from day one, with permissionless proving, a long upgrade delay, and a multisig with broad representation across the Ethereum ecosystem. Proportions of base fees would fund R&D and app development until 2030, after which they would be burned. A draft roadmap is published, and discussion is taking place in Telegram channels.
- Multi chain deployment process for a permissionless contract factory
- Smart Bidding: Gas Pricing Automation Strategies
The author proposes replacing the usual Slow/Medium/Fast gas pricing labels with five named bidding strategies, arguing that those labels are meaningless because everyone picks Fast. The proposed strategies are MAX_SPEED for earliest inclusion, TARGET_CPI for staying under a user-defined maximum fee, MEV_ROI for searchers seeking a minimum return on gas, CENSORSHIP_RESIST for preferring neutral builders or relays, and MAX_VALUE for choosing the best net payoff across batched transactions. Each strategy comes with key parameters, such as a 3.0 ROI threshold for MEV_ROI and a 20 gwei targetFee for TARGET_CPI in the example scenarios. The proposal is described as a draft, and feedback is being solicited before any formal proposal.
- Addressing Ethereum value capture
Jerome de Tychey, Dean Eigenmann and Zak Cole propose that Ethereum stakers voluntarily enforce a temporary minimum priority fee for Type 3 (blob) transactions, so that rollups contribute more revenue to L1 security. Assuming 2.8Bn gas of daily blob use, a 5 Gwei minimum would generate 14 ETH daily for validators, or about 5110 ETH yearly (~$10.2M at ETH at $2k). A "25% Tax" on $200M of rollup onchain revenue would instead require a 24.5 Gwei minimum, generating 68.62 ETH daily, a 2.6% increase on total daily validator income of 2639 ETH. The authors also call for accelerated research into dynamic blob pricing.
- ERC-7777: Proposal for Human Robot Societies
OpenMind has submitted ERC-7777, a draft Ethereum standard proposing interfaces for managing identities and governance rules in societies of humans and robots. The proposal defines two core interfaces: IUniversalIdentity, which would let robots acquire on-chain identities so they can interact and transact with humans, and IUniversalCharter, which lets humans and robots create, join, update, leave, and terminate self-regulated societies under predefined rule sets. The authors, Jan Liphardt, Shaohong Zhong, Boyuan Chen and Paige Xu, present smart contracts on Ethereum as a way to provide security, transparency, and scalability for these interactions. The document is listed as created on 2024-09-29 with draft status.
- EIP-7805 Fork-Choice Inclusion Lists (FOCIL) as a candidate for Glamsterdam
Fork-Choice Inclusion Lists (FOCIL, EIP-7805) are proposed as a headliner for Glamsterdam, with the case that they would let validators enforce transaction inclusion and reduce builder censorship on Ethereum. The article says more than 80% of blocks are produced by two builders who can unilaterally include or exclude transactions, citing censorship.pics data. It states that FOCIL has been implemented by six client teams and runs on a local devnet with Prysm, Lodestar, Teku and Geth, with spec testing underway. The article also says that, if the two dominant builders excluded a transaction, users would face delays averaging about 7 blocks (roughly 84 seconds), which FOCIL would prevent unless the block is full.
- Reconfiguring AllCoreDevs
This Ethereum governance proposal argues that AllCoreDevs calls should focus on scoping the next hard fork rather than implementing the current one, with the testing and interop call renamed ACDT(esting) to handle implementation details. The author suggests using Glamsterdam as a trial for this process, with a review and feedback period and a go/no-go decision shortly after Pectra mainnet releases. The proposal makes network security the top priority (P0), followed by a roadmap "headline feature" (P1) and other EIPs (P2), and it calls for stakeholders such as application developers to submit higher-level proposals using a template.
- Status, ongoing changes to EthMag + proposal for more changes
The EthMagicians forum, a community-run Ethereum discussion space, is moving to a more resilient setup and the author proposes further transparency and access changes. After a weekend outage, the Ethereum Foundation's DevOps team joined the forum's infrastructure to handle hosting, daily offsite backups, and monitoring, with maintenance windows every Saturday morning CET. The forum was scheduled to go offline on April 3 from 5:30 to 7am UTC for performance optimization. The proposal calls for a public list of administrators and moderators with defined roles, at least two people with emergency access to the @EthMagicians Twitter account (one being the DevOps team), and vetted delegates who can post on the account, with requirements such as no phone number attached and hardware-key or app-based 2FA.
- Consequences of EIP-7623 for dapp builders
EIP-7623 proposes raising calldata costs for users who do not spend more than a certain threshold on EVM computation. Its stated goals include cutting the maximum possible block size from about 1.7 MB to 0.55 MB without affecting current throughput, reducing block size variance, and narrowing the gap between average and maximum block size. The proposal also aims to make room for a higher gas limit or blob count and to separate users who need calldata inside the EVM from those who use it purely for data availability, pushing the latter toward blobs. It does not cover consequences for dapp builders.
- ERC-7802: Crosschain Token Interface
- Why does Sign in With Ethereum have such bad UX?
The author asks why Sign In With Ethereum (SIWE) has much worse user experience than "Sign in with Farcaster" and calls for wallet providers to reach parity. After using Farcaster sign-in at ETHWarsaw, the author says the Ethereum flow requires separate Connect Wallet and SIWE steps, and that the SIWE request in Rainbow did not open by default and had to be found in the notifications tab. The author questions why these steps cannot be combined, automated, or shown as a readable message instead of an unformatted string, and asks whether security concerns explain the difference. The author notes being a dapp builder with limited power to change this and says Ethereum wallets will not be developers' choice for consumer dapps without parity.
- Open source alternatives to privy
The author, who runs the Ethereum-based social news site Kiwi News, is seeking open-source alternatives to embedded-wallet services like Privy, Web3Auth and Dynamic, because syncing temporary posting keys across devices is needed to improve engagement but handing key custody to a third party creates lock-in risk. Kiwi News currently stores temporary keys in local storage and delegates them on Optimism, and the author says asking users to send multiple delegation transactions causes drop-off. The author tried Passkeys with the largeBlob extension, but reported poor browser and OS support, including no support for Chromium-based browsers, and said fixes could take years. The post asks the community for self-administrable alternatives that would let users keep control of their keys.
- ETH Denver 2024 Rollcall
The Ops Team is considering an EIP Day with presentations, discussions, and workshops around ETH Denver this year, and will organize it only if enough people indicate interest in attending and presenting. Attendance and speaker interest are being collected through a vote, which closes on 15/01 at 00:00 UTC. Participants can also propose topics and sessions, tag friends who are going to ETH Denver, and optionally suggest a date.
- A simple L2 security and finalization roadmap
The author proposes a 2-of-3 proof architecture combining optimistic, ZK and TEE provers as a pragmatic route for EVM rollups to reach Stage 2 with faster finality. In this design, a state root approved by both a ZK prover and a TEE prover is finalized immediately, while a root approved by only one is finalized after 7 days only if the optimistic proof game also unambiguously favors it. The author argues the architecture is arguably the only way to satisfy these constraints, since ZK and OP bugs are far less likely to coincide than two ZK bugs. The piece also calls for standardized Ethereum-wide proof aggregation layers so that N applications can pay the roughly 500,000 gas proving cost once instead of N times.
- Blob-Parameter-Only (BPO) forks
Blob-Parameter-Only (BPO) forks are proposed as a framework for safely and continuously scaling Ethereum blobs, authored by Sam McIngvale, Mark Tyneway and Proto. BPO forks are simple Ethereum forks that change only the blob target and blob limit, aiming to scale in smaller, more regular increments and share the operational burden of hard forks across L1 and L2 teams. The authors propose three conditions for a BPO fork: solo staker minimum bandwidth requirements are agreed upon, the blob increase is provably shown not to increase solo staker reorgs, and blobs are sustainably congested. They cite growing consensus around 50Mbps download and upload for solo stakers not using MEV-boost, and suggest a blob increase is safe if the trailing 30-day p999 block size plus the new blob data fits within that bandwidth.
- ERC-8211: Smart Batching
ERC-8211 proposes Smart Batching, a batch encoding standard for smart accounts in which each parameter is resolved on-chain at execution time and checked against inline constraints, and assertions can be placed between steps so a batch can stop if chain state is unacceptable. The authors argue this addresses static batching (ERC-4337, EIP-5792), where parameters are fixed at signing time, so a swap returning less than estimated causes the batch to revert. The draft's example pairs a swap with an assertion that USDC balance is at least 2500e6 before a supply step, and a later assertion that aUSDC balance is at least 2400e6. The reference implementation, by Mislav Javor, Filip Dujmušić, Filipp Makarov and Venkatesh Rajendran, is described as audited with all findings remediated.
- Introducing *.getcode.eth: ENS based onchain metadata resolver
*.getcode.eth is an ENS wildcard resolver, built on ERC-3668, that extracts the metadata hash embedded in a contract's bytecode and resolves it as an ENS contenthash, making it fully onchain. It supports three modes: direct mode returns an IPFS contenthash of metadata.json, CBOR mode returns the raw dag-cbor CID, and proxy mode attempts to detect a proxy and resolve its metadata. The article lists limitations, including that old contracts lack embedded metadata, most contracts with Swarm metadata fail to resolve because they are not pinned in Swarm storage, and many contracts' IPFS metadata is not pinned to the IPFS network.
- PSE Roadmap: 2025 and Beyond
PSE, the Ethereum Foundation team, is refocusing from a cryptography explorations team into a problem-first team called Privacy Stewards for Ethereum, arguing that without strong privacy Ethereum risks becoming the backbone of global surveillance. The roadmap organizes work into three tracks: private writes, private reads, and private proving. Its highest-priority initiatives for the next three to six months include continuing PlasmaFold with a proof-of-concept targeted by Devconnect, kicking off the Institutional Privacy Task Force with the EF EcoDev Enterprise team, and developing TLSNotary as a production-ready zkTLS protocol.
- ERC-8004: Trustless Agents
ERC-8004 is an Ethereum standard that extends the Agent-to-Agent (A2A) protocol with a trust layer, letting participants discover, choose, and interact with agents across organizational boundaries without pre-existing trust. It introduces three lightweight on-chain registries, named Identity, Reputation, and Validation, while leaving application-specific logic to off-chain components. The text states that the proposal is under public discussion and that its authors will work with the Linux Foundation and A2A ecosystem stakeholders to refine the specifications. It also acknowledges technical feedback from contributors including Dayan Brunie (Consensys), Wilson Chen (TensorBlock), and Austin Griffith (Ethereum Foundation), among others.
- Oracle-Permissioned ERC-20 with ZK-Verified ISO 20022 Payment Instructions
EIP 7963, proposed by Ant International, extends ERC-20 tokens so that transfers succeed only when an external "Transfer Oracle" has pre-approved them, using off-chain payment instructions in a standardized JSON format proven on-chain with zero-knowledge proofs. Each approval is single-use and covers an inclusive amount range, and the oracle SHOULD consume the smallest matching range to preserve larger approvals. The payment instruction format is compatible with ISO 20022 pain.001, and the reference implementation uses RISC Zero as the proving system, though the standard permits any ZK proof system. The reference implementation reports 80 passing smart contract tests, 34 passing Rust unit tests and 11 passing integration tests.
- Long-term L1 execution layer proposal: replace the EVM with RISC-V
The post proposes replacing the EVM with RISC-V as the virtual machine that smart contracts are written for, arguing this would greatly improve Ethereum execution-layer efficiency and simplicity. It says accounts, cross-contract calls and storage would stay the same, with opcodes like SLOAD, SSTORE and CALL becoming RISC-V syscalls, and that Solidity and Vyper could add RISC-V as a backend. The author argues that replacing the ZK-EVM with RISC-V addresses bottlenecks in statelessness-related data availability and ZK-EVM proving, noting that block_execution makes up roughly half of prover cycles today. The post outlines three implementation routes: supporting two VMs, converting EVM contracts into calls to a RISC-V EVM interpreter, or enshrining a protocol-level VM interpreter, with the Nervos CKB VM cited as a precedent.
- Protocol research call
Ethereum's researchers, core developers, users and builders are launching a new Protocol research call to discuss short-term trade-offs that will shape the protocol's end state. The stated aim is to derive network goals, clarify the possibilities and trade-offs uncovered by recent Ethereum research, and align research with core development. The call's first topic is local building, which the text says much current discourse fails to separate as either a goal of Ethereum or a means to objectives such as censorship-resistance, security, scale or verifiability. A pilot call is scheduled for April 2, 2025, at 14:00 UTC for 90 minutes, hosted by the author's co-host adietrichs, covering protocol roles, node types, local building and validator duties.
- How can we steer Ethereum away from making income from memecoin trading?
The author argues that Ethereum is becoming dependent on memecoin trading for its fees and MEV, and that this is a risk to its reputation and a distraction from harder problems. They criticized Warpcast and Rainbow for adding memecoin trading features, saying they are not building products like Angellist, and they report receiving personal backlash for doing so. They estimate that memecoin trading may account for a large share of Ethereum's fee and MEV revenue, though they say they lack the data to confirm it. They attribute the problem to a broken social layer with no leader able to steer the ecosystem, citing Beylin's post on the same issue.
- Ethereum is turning into a labyrinth of unnecessary complexity with EOF
Ethereum's EOF upgrade is unnecessarily complex, and its benefits could be delivered through less invasive changes to the existing EVM. The article says EOF introduces two new contract creation semantics (EOFCREATE and TXCREATE) and removes and adds over a dozen opcodes. It argues that goals such as reducing compiler complexity, removing gas and code introspection, and removing codesize limits can each be met by validation rules or updated pricing in the current EVM. It also lists costs including the need to maintain the legacy EVM, tooling coordination, and a reentrancy issue with send() and transfer() noticed only a month before Osaka's scheduled finalisation.
- ERC@Devconnect meetup
ERC@Devconnect 2023 is an event in Istanbul, Turkey, held during Devconnect in November 2023 and organized by the Ethereum Cat Herders and AllERCDevs. The gathering is meant to let ERC authors and dApp builders learn, share, and advocate for open standardization, with a meetup at the Cowork on November 15 in the afternoon Turkey time. The program includes opening keynotes, hands-on workshops and panels on topics such as the role of ERCs in the evolving Web3 landscape, and a feedback opportunity for authors on their ERC proposals. The main event is scheduled to last about 2 hours, with 30 minutes before and after for preparation and cleanup.
- Numbered Accounts: proposal of a new address format & wallet contract interface
Numbered Accounts is a rough proposal for a new address format and wallet contract interface that would interoperate with existing Ethereum accounts while limiting each account to a single chain and, optionally, specific assets. Addresses take the form routing number plus account number, such as 1001-123, where a singleton RouteRegistry contract on mainnet maps each routing number to a bank contract on a chosen chain. The author argues this reduces wallet complexity and user error, since an account cannot receive unsupported assets or assets on the wrong chain. Bank contracts would support transfers in, out, and between numbered accounts, with the stated goal of integrating with ERC-4337.
- Protocol research call
Ethereum's community is launching a Protocol research call to discuss short-term trade-offs that will shape the protocol's end state, with the aim of setting network goals and aligning research with core development. The first topic is local building, which the text says is an important question on the path to further scaling and is unclear as to whether it is a goal or a means to objectives such as censorship-resistance, security, scale or verifiability. A pilot call is scheduled for April 2, 2025, at 14:00 UTC, lasting 90 minutes, and will cover protocol roles and types of nodes, highlighting local building and validator duties. The organizers, named as @adietrichs and the post's author, are open to agenda suggestions.
- EIP-7782: The case for 2x shorter slot times in Glamsterdam
EIP-7782 proposes targeting 6-second Ethereum slot times in the Glamsterdam upgrade, down from 12 seconds, on the argument that faster slots make Ethereum a better confirmation engine. The authors say shorter slots reduce transaction inclusion latency, speed up L1 finality and confirmations for interoperability protocols, and lower the staleness of onchain data. They also state that lower staking reward variability would reduce incentives to pool, and that smaller, more frequent messages would smooth bandwidth peaks. The main risk named is that slower, less well-connected validators could see their performance affected, provided gas and blob throughput stay at current levels.
- Multi chain deployment process for a permissionless contract factory
- Community Consensus, Fork Headliners & ACD Working Groups
A proposed process for choosing Ethereum hard fork headliners would have AllCoreDevs define a shared "Fork Focus" at the start of each upgrade cycle and select only one or, at most, two flagship features that align with it. It seeks structured input from the wider community beyond core developers, with headliner proposals written as Ethereum Magicians threads covering benefits, stakeholder impact, technical readiness and security. It also explains the decision to remove EOF from Fusaka, citing repeated difficulty reaching rough consensus and late opposition from the Reth team after it examined interactions with legacy contracts.
- Formalizing decentralization goals in the context of larger L1 gaslimits
Vitalik Buterin argues that raising the Ethereum L1 gaslimit, and the higher full-node hardware and bandwidth requirements that come with it, is likely a net good, and that Ethereum needs a clearer framework for its decentralization goals before doing so. He proposes three node types: light nodes that verify the chain and are easy enough to include in default wallets, medium nodes with an n/2-of-n trust assumption such as attesters and FOCIL participants, and heavy nodes with a 1-of-n assumption such as block builders and provers. Heavy requirements on block building are expected to be more controversial than those on proving, since a malicious dominant builder can cause harm. He also says bandwidth limits should be more conservative than hardware limits, and that the numbers remain to be filled in.
- Make Developer Relations in Ethereum Great Again
The article argues that Ethereum's developer relations need urgent attention, despite strong growth in its developer base, and proposes five areas for improvement: documentation, tooling, education, governance participation and community support. It cites Electric Capital's 2024 Developer Report, which says the number of established Ethereum developers grew 21% in 2024, and Alchemy's Web3 Development Report, which puts Ethereum SDK installs at 106.4 million in 2023, up 31% from 81.4 million in 2022. It also notes that the share of Ethereum ecosystem developers working on Layer 2 solutions rose from 25% in 2022 to 56% in 2024, adding complexity for newcomers.
- EIP-7917: Deterministic proposer lookahead
EIP-7917 proposes storing the proposer schedule for upcoming epochs in the beacon root at the start of each epoch, so the lookahead is deterministic. According to the summary, this removes unpredictable changes to the next epoch's lookahead caused by effective balance fluctuations, such as slashings, penalties, or increased validator balances, an issue made worse by EIP-7251's MaxEB increase. The text says this would let preconfirmation protocols rely on a stable schedule with less complexity, and give straightforward on-chain access to the lookahead via the beacon root. It also says the change removes a potential source of grinding attacks via effective balance changes. The update log shows the EIP was scheduled for Fusaka with a target of fusaka-devnet-1 as of 2025-05-29.
- Pectra Retrospective
This is a call for retrospectives on AllCoreDevs (ACD), the Ethereum core developer process, following the Pectra upgrade and recent criticism of the process. The post asks participants to share reflections and improvement proposals in a dedicated thread, with responses categorized by Client Teams, Infrastructure Providers & Developers, and Misc. Users / Community members. It suggests questions on what went better or worse than expected, what to start, stop or change, and which "legacy process debt" to rethink from first principles. It also cautions that efficiency gains, such as those from speed, can trade off against security, openness and reducing "unknown unknowns."
- All Core Devs - Execution (ACDE) call #192, July 18 2024
The All Core Devs - Execution call #192 on July 18, 2024 recorded decisions on Ethereum development. Devnet-1 is expected to launch by next Thursday. EOF remains in Pectra, with Geth not opposing its inclusion but not wanting to take responsibility for testing, while teams continue implementation and testing and should prioritize fuzzing once multiple complete implementations exist. EIP-7702's spec remains unchanged for now, and teams are asked to review logs for system contracts before next week's ACDC call.
- ERC-7646: Metadata Management for NFTsw
ERC-7646 proposes a standard for managing NFT metadata, letting a token's owner and authorized addresses update its metadata after minting. The author, identified in the article as Kureev, says updatable metadata would support use cases such as provenance tracking and game assets, and dynamic NFTs tied to IP, real estate, or supply chains. The proposed MetadataManager contract stores metadata per token, lets owners authorize or revoke other addresses, and can be used with any ERC721 or ERC1155 contract. The article lists its test cases as TBD and notes that the contract relies on the NFT contract's ownerOf function, which could create security issues if implemented incorrectly.
- Proposal to adjust issuance curve in Electra
The authors, @adietrichs and @caspar, argue for adjusting Ethereum's issuance curve in the Electra upgrade, using Anders' proposed curve, because the current policy could push most ETH into staking through liquid staking tokens. They say the current curve makes staking economically viable for all ETH, dilutes holders beyond what security requires, and could allow about 40,000,000 ETH of new stake inflow over two years if no change is made before Osaka. According to the text, the new curve caps dilution at about 0.4% compared with about 1.5% under the current curve, and reduces real total staking yield by about 30% at current staking levels of 30M ETH.
- Milestones for rollups taking off training wheels
The article proposes a three-stage milestone schema for rollups to categorize how heavily they rely on temporary "training wheels," meaning multisig controls that can force outcomes if the code has bugs. Stage 0 requires that all rollup transactions be posted on-chain, that an independently runnable full node exist, and that users can ensure withdrawals without operator cooperation, with a simple multisig allowed for posting state roots. Stage 1 requires a running fraud or validity proof system with practical authority over accepted state roots, and permits a security council override only if it is 6 of 8 or stricter with at least a quorum-blocking group outside the operating organization. Stage 2 requires that, if the code has no bugs, no group of actors can post a state root other than the code's output, with upgrades requiring a delay of at least 30 days.