Copy English

Why

The split is not merely duplicate encoding. EIP-8130 structures authentication before execution around a keystore, actors, authenticators, and a canonical baseline intended to make validation predictable and portability easier. EIP-8141 exposes transaction frames that can separate and order verification, payment, and execution more flexibly, with corresponding mempool and validation complexity. A wallet that hides this behind if Base else Ethereum will leak chain-specific assumptions into sessions, sponsorship, recovery, simulation, and error handling.

The stable abstraction belongs one level above both transaction formats: user intent plus explicit capabilities. 'Batch these calls with this signer, this spending policy, and this payer' is the product request. Frames or Keystore Accounts are compilation targets. Capability negotiation must be semantic, not a Boolean named supportsAA: a chain may support batching and sponsorship but not the same validation order, authenticator, session policy, recovery path, or public-mempool behavior.

Compatibility does not mean pretending both rails behave identically. The adapter must either prove that the requested semantics survive translation or expose a downgrade before the user signs. A silent fallback from an atomic batch to sequential calls, from a scoped session key to a full-authority signature, or from a public mempool to a private relay is a security bug. The common layer should normalize intent, evidence, and receipts while preserving differences that affect authority or failure.

Both EIPs remain Draft. Ethlabs reports that the reconciliation effort ended and the approaches will proceed separately, but final specifications can still change. Therefore wallets should version capability manifests and adapter test vectors rather than freeze today's field layout into product logic.

How it works

Different rails, one wallet intent

Adapter boundary

user intent
  {calls, atomicity, signer, policy, payer, expiry, recovery}
                 │
      capability negotiation
          ┌──────┴──────┐
     8130 adapter   8141 adapter   → explicit 4337/7702 fallback
          └──────┬──────┘
      normalized simulation + receipt

Minimum capability manifest

chainId: 1
aaRail: eip-8141
specVersion: draft-2026-09-16
features: [atomic-batch, sponsorship, p256]
mempool: public-with-validation-prefix
fallback: erc-4337

The manifest must be authenticated, cached with an expiry, and checked against live RPC behavior. It is a routing input, not a source of authority.

Conformance test

Run the same vectors on both adapters: one call, atomic approve+swap, sponsored call, scoped session, expired authorization, invalid payer, recovery, replay, and simulation/state change. For each vector compare requested semantics, encoded transaction, pre-sign simulation, receipt, and failure reason. Fail closed when authority, atomicity, or payer semantics cannot be preserved.

Status and sources

Ethlabs' earlier comparison documents the simplicity/extensibility tradeoff and the attempted convergence. Reporting on Derek Chiang's September update says that work ended and the standards will proceed separately. The canonical EIP pages still mark both proposals Draft, so 'will ship' is direction, not proof of final deployment.

Sources: Ethlabs — 8130 vs Frame Transactions · EIP-8130 — Keystore Accounts · EIP-8141 — Frame Transaction · The Block — collaboration ends

Where it lands in Jayverse

• Rabbit: load a versioned capability manifest per chain instead of branching on chain ID. Sepolia, the Anvil devnet and any future OP-Stack L2 should each declare batching, sponsorship and session support explicitly, compiled through separate ERC-4337/7702/7715 adapters.
• Wallet: surface a downgrade before signing, not after. If a scoped session key would compile down to a full-authority signature on a given chain, the simulate-before-sign screen must show that semantic loss, not silently accept it.
• CI: run one conformance vector set against every AA adapter Rabbit ships. Atomic batch, sponsored call, scoped session, expired authorization and recovery should all be tested per adapter, gated in CI so a rail change can't quietly drop a guarantee.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

두 개의 네이티브 AA 표준 — 지갑에는 체인 이름 분기가 아니라 capability matrix가 필요하다

Ethlabs의 Derek Chiang에 따르면 Ethereum의 EIP-8141 Frame Transactions와 Base의 EIP-8130 Keystore Accounts를 하나의 설계로 조정하려던 작업은 합의 없이 끝났습니다. 지갑 계층의 해법은 서로 무관한 구현 두 개가 아닙니다. 하나의 user-intent model을 유지하고 체인별 capability를 협상한 뒤, 별도로 시험한 8141·8130 adapter로 번역해야 합니다.

authenticate·batch·sponsor·session·recover·execute를 표현하는 wallet-level AccountIntent를 정의합니다. 체인 ID만으로 분기하지 말고 체인마다 서명되고 version이 있는 capability manifest를 읽습니다. intent를 8141 Frames adapter, 8130 Keystore adapter 또는 ERC-4337 같은 명시적 fallback으로 compile합니다. 서명 전에 의미 차이를 보여주고 지원되지 않는 조합은 거부합니다. 모든 adapter에 같은 conformance vector를 실행하고, 선택된 rail·signer·payer·policy·downgrade reason을 담은 하나의 receipt 형식을 유지합니다.

왜

이 분리는 encoding 중복만의 문제가 아닙니다. EIP-8130은 keystore·actor·authenticator·canonical baseline을 중심으로 인증을 실행보다 먼저 구조화해 validation을 예측 가능하게 하고 portability를 쉽게 하려 합니다. EIP-8141은 verification·payment·execution을 더 유연하게 분리하고 배치할 수 있는 transaction frame을 노출하며, 그만큼 mempool·validation 복잡성이 따릅니다. 이를 if Base else Ethereum으로 숨기면 chain-specific assumption이 session·sponsorship·recovery·simulation·error handling으로 새어 나갑니다.

안정적인 추상화는 두 transaction format보다 한 단계 위인 user intent와 명시적 capability에 있어야 합니다. '이 signer·spending policy·payer로 이 call들을 batch하라'가 제품 요청이고, Frames와 Keystore Accounts는 compile target입니다. capability negotiation은 supportsAA라는 Boolean이 아니라 의미 단위여야 합니다. 체인이 batching과 sponsorship을 지원해도 validation order·authenticator·session policy·recovery path·public-mempool 동작은 같지 않을 수 있습니다.

호환성은 두 rail이 같다고 가장하는 것이 아닙니다. adapter는 요청한 의미가 번역 뒤에도 보존됨을 증명하거나 사용자가 서명하기 전에 downgrade를 드러내야 합니다. atomic batch를 sequential call로, scoped session key를 full-authority signature로, public mempool을 private relay로 조용히 바꾸는 것은 보안 버그입니다. 공통 계층은 intent·evidence·receipt를 정규화하되 권한이나 실패에 영향을 주는 차이는 보존해야 합니다.

두 EIP는 모두 Draft입니다. Ethlabs는 조정 작업이 끝나 두 접근이 별도로 진행된다고 전했지만 최종 명세는 계속 바뀔 수 있습니다. 따라서 지갑은 오늘의 field layout을 제품 로직에 고정하지 말고 capability manifest와 adapter test vector에 version을 붙여야 합니다.

동작 방식

서로 다른 rail, 하나의 wallet intent

Adapter 경계

user intent
  {calls, atomicity, signer, policy, payer, expiry, recovery}
                 │
      capability negotiation
          ┌──────┴──────┐
     8130 adapter   8141 adapter   → 명시적 4337/7702 fallback
          └──────┬──────┘
      정규화된 simulation + receipt

최소 capability manifest

chainId: 1
aaRail: eip-8141
specVersion: draft-2026-09-16
features: [atomic-batch, sponsorship, p256]
mempool: public-with-validation-prefix
fallback: erc-4337

manifest는 인증되고, expiry와 함께 cache되며, 실제 RPC 동작과 대조되어야 합니다. 이는 routing input이지 권한의 원천이 아닙니다.

Conformance test

두 adapter에 같은 vector를 실행합니다: 단일 call, atomic approve+swap, sponsored call, scoped session, 만료 authorization, 잘못된 payer, recovery, replay, simulation 이후 state change. 각 vector에서 요청 의미·encoded transaction·서명 전 simulation·receipt·failure reason을 비교합니다. authority·atomicity·payer 의미를 보존할 수 없으면 fail closed합니다.

상태와 출처

Ethlabs의 앞선 비교는 simplicity/extensibility tradeoff와 조정 시도를 기록합니다. Derek Chiang의 9월 업데이트를 인용한 보도는 그 작업이 끝나 표준들이 별도로 진행된다고 전합니다. 공식 EIP 페이지는 여전히 두 제안을 Draft로 표시하므로 '출시한다'는 방향이지 최종 배포의 증거는 아닙니다.

출처: Ethlabs — 8130과 Frame Transactions · EIP-8130 — Keystore Accounts · EIP-8141 — Frame Transaction · The Block — 협업 종료 보도

Jayverse에서의 위치

• Rabbit: 체인 ID로 분기하는 대신 체인별로 버전이 있는 capability manifest를 로드한다. Sepolia, Anvil devnet, 그리고 앞으로의 OP-Stack L2는 각각 배칭, 스폰서십, 세션 지원 여부를 명시적으로 선언하고, 별도의 ERC-4337/7702/7715 어댑터를 거쳐 컴파일되어야 한다.
• Wallet: 서명 전에 다운그레이드를 노출한다, 서명 후가 아니라. 범위가 제한된 세션 키가 특정 체인에서 전권 서명으로 컴파일된다면, simulate-before-sign 화면이 그 의미 손실을 보여줘야 한다. 조용히 받아들여서는 안 된다.
• CI: Rabbit이 지원하는 모든 AA 어댑터에 동일한 conformance 벡터 세트를 돌린다. 원자적 배치, 스폰서 호출, 범위 제한 세션, 만료된 승인, 복구를 어댑터별로 테스트하고 CI에 게이트로 건다. 레일 변경이 조용히 보장을 떨어뜨리지 못하게 한다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑