Ethereum core dev @Nethermind · implementing Frame Transactions (EIP-8141/8250/8272) · author of ERC-8403 · co-author of EIP-7906 · Protocol Guild
Tbilisi
- Tweets 118
- Following 65
- Followers 47
- Likes 239
here is how my erc-8403 works. your account stores one hash, the root of a tree of your keys. add a key, revoke a key, the address stays. a 3 min demo on two live nethermind nodes, with a thief trying to get in
github.com/ethereum/ERCs/pul…
3
370
20 SIGNATURES. ONE PROOF.
Daisugi v0.3 aggregates 20 transaction signatures using LeanSPHINCS and LeanVM.
20 SPHINCS signatures are verified through a single aggregate proof.
For EL clients, verification requires the LeanVM verifier plus the LeanSPHINCS guest program.
Post quantum signature aggregation is live on Daisugi. Kudos to @Nethermind @Gianluca_Felli
AND THEN THERE WERE FRAMES.
Daisugi v0.2 now supports Frame Transactions.
SPHINCS signed transactions can run as native frames, with per frame execution and verification, alongside the existing ERC 4337 flow.
Same post quantum signatures. New transaction model.
Next: signature aggregation via LeanSPHINCS.
Believe in somETHing. Link and credits ⬇️
38
29
167
37,385
what does a post-quantum account look like on ethereum? eip-8288 makes the signature cheap, but not the key management.
wrote up how my erc-8403 fits: a pq key is one more leaf. and an optional next step, where the key tree sits inside a small leanvm program and the account stores its hash. i ran the proof side: ~0.2 s to prove, ~200 kB
ethresear.ch/t/erc-8403-an-a…
1
71
post-quantum accounts on frame txs, two things still in the way. the cheapest sphincs- verify is 94k gas against a 100k cap. and a 7702 delegated eoa can be taken back with the old ecdsa key. hackmd.io/@0Eo_JbIrQIKnf-o35…
50
measured MAX_VERIFY_GAS from 100k to 500k on nethermind. at equal gas per second of failing checks the harm is the same at every cap. the cap only multiplies what one peer can push. 300k holds against one attacker peer hackmd.io/@0Eo_JbIrQIKnf-o35…
1
3
211
Daniil retweeted
Nethermind Beacon Chain plugin ready and synced for the Sepolia fork 🚀
Nice bonus: running EL + CL as one app doesn't seem to add much memory overhead
8
22
110
14,969
lost the wallet? rebuild every key from account state, no backup. revoke a leaked key once, apply it on every chain. erc-8403 + 10 more frame tx flows as diagrams
hackmd.io/@0Eo_JbIrQIKnf-o35…
1
66
Daniil retweeted
A new transaction model is only part of native account abstraction.
ERC-8403 looks at another piece: how account authorities are managed 👇
Etherspot explains: ERC-8403 Account Authority Lifecycle
Native account abstraction needs a common way to manage the authorities that can act on behalf of an account.
ERC-8403 introduces a common lifecycle for account authorities, including signing keys and rules like spending limits or locks. It covers how they can be added, rotated, and revoked.
Each account keeps a verifiable set of approved keys and rules. A transaction includes proof that the authority it uses belongs to that set, and the account checks it before authorizing the action.
The proposal is designed to work with both EIP-8141 Frame Transactions and the EIP-8130 keystore approach, giving wallets and apps one authority model across different native AA implementations.
It can also make recovery more portable, since authority data can be reconstructed from on-chain state instead of relying only on wallet-side backups.
ERC-8403 complements ERC-8286, which focuses on modular account validation.
1
5
339
Daniil retweeted
🥷 Keyed Nonces (EIP-8250) and Recent Roots (EIP-8272) were just CFI'd in Hegota 🥷
One more step towards native privacy coming to Ethereum
Buckle up
❤️🔥
5
8
65
2,071
Daniil retweeted
native AA in ethereum ⚡
frame breakout #5 - tl;dr:
→ @ethrex_client testnet: 14 days, 3 clients, 400 frame txs from 21 senders
→ @weboftrees (ef) outlines multidimensional gas considerations
→ @_jxom (viem) feedback: gaps in JSON-RPC specs
→ @ox_shaman (@ethlabs_org) teases an ERC to combine many UX puzzle pieces
→ @Ankuinf (@Nethermind): proposes raising devnet tx gas limit to test complex scenarios
full call: forkcast.org/calls/aa/005/
since then:
✨ frames-devnet-0 is live! ✨
ethpandaops.io/networks/fram…
this is the first of hegota's devnets. focil will get its own feature devnet, and once satisfied with the fundamentals of each, a combined hegota-devnet-0 will follow
🚢
1
5
23
579
Daniil retweeted
EIP-8141 Frame Transactions and friends (8250 keyed nonces, 8272 recent roots, 7906 transaction assertions) merged to @Nethermind master github.com/NethermindEth/net… !
Only 40k lines of code - lot of tests and comments though.
Frame Transactions 40k 😉
4
8
47
3,474
native gas sponsorship, no bundler and no separate paymaster service, comes down to one question. how does a sponsor stay solvent when many pending txs draw on one balance.
my read is you can't get it for free in the public mempool. you end up needing one of three, escrow, a bond, or off-chain trust, and you can't dodge all three at once. 8141 takes the reserved-balance route, but that's a choice, not the only option. i wrote up the argument, would like people to find where it bends:
ethresear.ch/t/25995
2
4
123
right, that private mempool is one of the three corners, the off-chain trust one. the bundler gates exposure off-chain. 8141 picks the reserved-balance corner instead: every node reserves the worst-case against the sponsor's on-chain balance before admitting, so the same insolvency never reaches a block, but in the public mempool with no bundler. that's the point, sponsorship can stay in consensus if you pick that corner.
1
31
built @soispoke's matcha sender-width for keyed-nonce frame-txs. github.com/NethermindEth/net…
🍵 New post: Mempool Account Transaction Capacity from Historical Activity (MATCHA) 🍵
tldr: Frame transactions allow apps to define their own validation and gas payment logic.
But admitting many pending transactions from one sender creates a DoS risk: a malicious app could invalidate them all with one cheap state change, forcing nodes to repeat the validation work.
MATCHA bounds this risk by making each additional admission spend capacity earned through finalized onchain activity. Its goal is to let many users share one sender without having to whitelist applications, paymasters or proof systems.
1
11
432
Daniil retweeted
Institutions can run compliance controls on Ethereum without moving to a permissioned network. The controls sit in the institution's own node and routing, not in the network. Two proofs of concept with @UBS on Sepolia:
nethermind.io/blog/complianc…
3
7
21
1,818
the harder half of frame transactions is the public mempool. once one sender can keep many pending txs, every node has to bound the validation work each one costs before inclusion, or flooding gets cheap.
the shared rules that set those bounds are where review helps most, and where i'm least sure the numbers are right:
github.com/ethereum/EIPs/pul…
github.com/ethereum/EIPs/pul…
github.com/ethereum/EIPs/pul…
46
short update on frame transactions, this is how i've come to see it, not a settled fact, so push back.
8130 and 8141 look like two account models, and people worry the ecosystem splits down that line. i think they're actually one. the way i read it, 8130 is the clean profile of 8141, same validation rule, one reads the authority as data and the other stops on an empty record. one check, two wrappers.
if that holds, an 8130-first l2 reaches full 8141 as a superset, every account still valid, no user migration. an eoa becomes a smart account with one frame write, no setcode dance. a wallet renders what you're signing from the frame grammar, no per-account code on the signing path.
i wrote it up as spec changes, would like eyes from anyone in wallets, clients or l2s, especially where i've got it wrong:
github.com/ethereum/EIPs/pul…
github.com/ethereum/EIPs/pul…
github.com/ethereum/ERCs/pul…
1
52
