this encompasses all I am saying, Frame TXs offer fake abstraction/are more expensive at the verification layer so might as well just admit abstraction at the verification layer is moat and move on.
Oh btw, this will become obsolete anyways. idk why we are talking about ecrecover when it is going to be abandoned. yes, transition will be slow. almost noone uses 7702 today still with wallets after all (around 1%< of activity) so this is always going to be the case
The point is not about ecrecover but about the use of signatures in applications running on the EVM. You need to propose an analogue for non-ECDSA accounts. Normally this is done via ERC-1271, which “Schemed Accounts” don’t support.
1 Like
you send over public key for those as well. sig has info about public key in ecdsa, just obscure by elliptic curve math
The mechanics are clear, but the EIP needs to package it up in a precompile or something so smart contracts can authenticate signatures for these accounts in a scheme-agnostic way. It’s not scalable any other way.
ah yes thats an extra detail ofc
I agree that the NTT precompile approach doesn’t work for PQ verification in practice. Sharing my experience, in my EIP-8141 PoC, I couldn’t get the VERIFY frame cost under 1M gas with the NTT precompile, which confirms that we need dedicated PQ precompiles (Falcon/ML-DSA) rather than generic building blocks.
However, the ~30,000–48,000 “smart wallet overhead” figure in the post seems to be based on ERC-4337 EntryPoint dispatch costs, not EIP-8141’s native VERIFY frame. The VERIFY frame runs in a constrained STATICCALL-like context with no bundler infrastructure, so it’s much lighter than a full 4337 UserOp flow.
Based on my PoC with a dedicated ML-DSA precompile, the actual gap between native SchemedTransaction and Frame TX is likely closer to ~10K, not ~33K as implied.
2 Likes
Some of the signatures are quite large, would you consider adding a floor fee for them?
i did. there is a surcharge. but this is just a framework
No, I mean the floor fee is calculated per byte of the signature, following EIP-7976. This looks similar to EIP-7981 or EIP-8131.
thats what the supercharge is for. but we can make it flexible
I’m not sure if the impact of each byte of calldata is similar to that of each byte of signature; if so, the block would be filled with underlying transactions before reaching the maximum block gas limit expected by EIP-7976.
EIP-7932 comes with a precompile (sigrecover), and is fully upgradeable without any direct changes to the EIP. That’s why I am pushing for this so hard, it’ll significantly reduce the complexity in these scenarios.
Couldn’t existing accounts use 7702 for this? They could:
- Deploy a forwarder contract that only accepts transactions from an account that uses a new crypto scheme.
- Delegate to that contract.
Assuming something like permanent delegations is eventually added, they could later delegate forever.
Yes they can use 7702, but they won’t be able to originate transactions as today or use FOCIL in the future.
btw ST is actually better for FOCIL I just realised. less complicated and same synergy to integrate
it doesn’t allow smart accounts to use FOCIL though. So yes, it is simpler for FOCIL, but provides less functionality.
1 Like
yes it does? you can implement rest of frames later anyways, just not verify ones
Feels like this is less about PQ and more about where validation logic should live long term.
Schemed tx are simpler but hardcode signature schemes, which doesn’t scale well for hybrid or migration use cases. Frame tx add complexity, but give real crypto agility and align better with where account abstraction is heading.
Main concern: how do we avoid fragmenting the ecosystem between “simple schemed EOAs” and “frame-based accounts” during transition?
Reading both proposals back-to-back as a docs engineer, not a protocol researcher, three
things would help implementers regardless of which direction wins:
1. Terminology drift between the two specs. scheme_id and validation frame are
overlapping concepts with different vocabularies. Anyone reading both specs in sequence,
wallet devs especially, will trip on this. A shared glossary in the specs would save
hours.
2. Migration semantics are absent. Both EIPs describe the new transaction shape but
neither covers the actual flow: how does an existing EOA owner rotate to a new scheme?
What does the wallet UX look like? What are the failure modes during migration? The gas
tables don’t answer “what does this cost a user once they want to upgrade.”
3. “Implementer summary” sections are missing. Both specs would benefit from a stanza at
the top distinguishing what node implementers need from what wallet implementers need,
since they’re two audiences with different priorities. Right now the specs read as
protocol-first, which makes them dense for the people building on top.
The hybrid direction @Giulio2002 sketched (immediate PQ security via SchemedTransactions,
Frame Transactions deferred) is reasonable from a shipping standpoint, but the migration
docs story becomes even more important in that world because implementers will span two
transaction shapes over time.
Happy to contribute a “reading both specs as a wallet implementer” companion doc if it
would help the authors pressure-test the current drafts.