Discussion topic for EIP-8130
None as of yyyy-mm-dd.
8130 is an account abstraction protocol that is designed performant, flexibile, arbitrary account abstraction by enabling nodes to add native implementations of validation logic (ie k1, p256, webauth .. ) While keeping the allowed validation code permissionless to deploy.
Moved to an EIP here, the previous link will get more and more out of date.
Thanks for sharing this EIP.
After an initial read I have two questions for the start:
Why did you chose a self-call for execution rather than a dedicated entrypoint address? This would have allowed to distinguish this from a self call in contract methods.
Why did you chose to have the account authentication logic and gas payment logic in one EIP? From past experience I would say that this lowers the chances of adoption by the core team due to complexity. Separating this into multiple EIPs might make sense.
Thanks @rmeissner !
I can split this out into two EIPs, agree that would keep it much cleaner. Initially wanted to have ~parity for the things we cared about for AA and ERC20 payments was one of them.
As for the self call:
Any specific use case for the self call initiated from code vs from the initial transaction frame?
Changes to token balances should be understood as changes in storage (e.g., ERC20) rather than turning them into a transaction format attribute, as this increases protocol complexity. Additionally, a 2D nonce structure can be simplified to a nonceBitmap, as shown here: https://ethereum-magicians.org/c/web/70
Hey, sorry for the late reply,
regarding the self call I was mostly thinking about the requirements to make an account like Safe compatible to it. For config changes the Safe checks on self calls. Therefore it would be directly compatible to have an âentrypointâ.
Just to note: I donât mean that there should be an entrypoint contract, rather that tx.origin (or msg.sender) is set to a pre-defined address, to easily check that this flow is taken.
Edit:
can determine if msg.sender == tx.origin && msg.sender == address(this)
This would would be true for the initial invocation and any follow up calls, right? At least for Safe it would be interesting to differentiate these. That being said, this is also true for EIP-7702 and the solution most likely would be transient storage.
Yes that would be true for both initial invoke and follow up calls.
Yes seems like transient storage could be a solution here, I cant right now see how that breaks.
Initial frame: works (sets transient flag)
Initial frame to another address which calls into the wallet later (not this tx type): wouldnt be triggered, caller cant be msg.sender ?
The above is true for any other as well I think but havent thought too deeply on it.
âŚThe main tradeoff here is swapping out arbitrary code execution in validation which allows us to have no wasted/unpaid computation and performant inclusion checks (just nonce, payer balance, sig matches sig slot) and a performant mempool.
The solution is backwards compatible with ERC-4337 and allows existing smart accounts to migrate by registering their keys with the precompile.
Disabling arbitrary validation code enables us to have node optimizations for reasons mentioned above.
We believe this tradeoff is acceptable because the vast majority of wallets today verify a single key: secp256k1, P-256, or WebAuthn. These cover EOAs, hardware wallets, and passkeys. BLS enables signature aggregation where needed. Delegated keys provide subaccount functionality. The key type system is extensibleânew signature schemes can be added via protocol upgrades with clearly defined verification logic.
The primary capability lost by removing arbitrary validation is custom recovery logic. However, recovery flows remain fully supported through multiple pathways:
1. ERC-4337 compatibility: Accounts can still use EntryPoint-based recovery modules alongside native AA transactions
2. Relayer-assisted recovery: Guardians sign recovery authorizations off-chain; a relayer submits the transaction and pays gas (standard pattern used by Safe, Argent today)
3. Future protocol level recovery: ie. native multisig of trusted external accounts, potential zk implementation if performant enough
Allowing a chain to set a default verifier could make it easier to migrate from a previous account abstraction system (e.g. Celoâs CIP-64) without modifying the state of all user accounts.
Just so I understand correctly - The CIP-64 seems to still use secp256k1, but I guess you have non-standard fields to sign over? Would you be hoping to also sign over the CIP-64 feeCurrency or would you be moving towards 8130 flows for alternative token payments?
Yes, CIP-64 uses secp256k1, but the signed RLP includes feeCurrency on top of the EIP-1559 fields, so the signing hash isnât a regular EIP-1559 hash.
We havenât picked a direction yet. Two options are being discussed is a backwards-compatible CIP-64 over EIP-8130. Wallets keep signing CIP-64 (0x7b) as they do today, feeCurrency and all. An RPC shim repackages each CIP-64 tx as an EIP-8130 AA tx, and a CIP64Verifier contract validates the original CIP-64 signature inside the EIP-8130 verification framework: it reconstructs the CIP-64 signing hash, runs ecrecover, and cross-checks against TX_CONTEXT to bind the signed CIP-64 payload to the actual EIP-8130 execution. Fee payment shows up as a Phase 0 transfer(payer, maxFee) in the fee currency. This needs a chain-level default verifier in EIP-8130 so existing users donât each have to write an owner_config entry.
Two options are being discussed isâŚ
This should be âOne of two options being discussed isâŚâ obviously. Sorry for the noise. The other option would not require a default verifier and works with the current proposal. But it would require wallet changes, which make the migration path a lot harder. I can go into more details if thatâs of any help.
Would be helpful to hear the other option! Want to make sure its what Im thinking there as well
Thanks for the details
In Option 2, wallets stop signing CIP-64 and start signing native EIP-8130 txs, so what the user signs is what lands on chain. EOAs then work without an owner_config entry or any verifier registration. Fee abstraction is expressed in the call structure. Phase 0 is a single transfer(payer, maxFeeAmount) on the fee token; Phase 1 is the userâs actual call.
The payer is the sequencer itself, which makes the native token flow circular within a block: the protocol debits native token from the sequencer for gas, the user pays the sequencer in the fee token in Phase 0, and the sequencer periodically swaps the fee token back to native to top up its float. payer_auth is also a plain ECRECOVER_VERIFIER signature. The payer/sequencer enforces the off-chain checks itself before signing: fee token whitelisted in FeeCurrencyDirectory, user has the balance, fee amount covers gas_limit * max_fee_per_gas * oracle_rate. Oracle access moves out of the node (compared to current CIP-64 handling).
You could split payer and sequencer, but for brevity I donât want to go into all of the different variants of this proposal.
This is the cleaner option in the long run, but the migration would be slow since all wallets need to add support for it.
Option 2 is ideal eventually for sure and Iâd push to get there but heres an option during migration.
Since authenticators (recently renamed from verifiers) just verify a hash, on the 8130 transaction path you can compute whatever preimage you need for the old signature type and verify against that. So this is really just a preimage change and you keep using all the other 8130 machinery unchanged.
For feeCurrency, can use the new top-level metadata field on the 8130 tx as its signed over or inject the token transfer into its own call phase 0. I guess this depends how you would do gas accounting in the interim.
So flow is like:
Note that at hard fork 0x7b becomes 8130 txns and CIP-64 only exist at the RPC ingress layer
So you mean we could modify the execution client to detect that this is an 8130 wrapped CIP-64 tx and calculate the hash in the CIP-64 way? I was hoping to avoid changes to the execution client altogether, but that would be a possible intermediate step.
Note that at hard fork 0x7b becomes 8130 txns and CIP-64 only exist at the RPC ingress layer
Thanks for calling that out, I didnât pay attention to the AA_TX_TYPE. Is there a chance to convince you to go with a different number? That would spare us quite some confusion and I think it is generally desirable to have non-overlapping tx types in the OP-Stack ecosystem. Using the same tx type will prevent us from adding EIP-8130 support before we phased out CIP-64.
Yes, sounds good, exploring other numbers now.
Thinking that you already have a fork for the CIP-64 changes on OP stack so this change would be present in EL until that is deprecated.