[youssefea]

What changed? Why?

Adds a short "Relationship to EIP-8130" section to docs/specifications/base-transactions.mdx. It explains that EIP-8430 is a separate transaction-type proposal split out of EIP-8130, not a rename. EIP-8130 now specifies Keystore Accounts and describes an integration with the EIP-8430 transaction type. The section also notes that earlier EIP-8130 drafts defined type 0x79, which is why older material calls these "EIP-8130 transactions". It states that EIP status does not tell you whether Base Transactions are live on Base.

This closes Base Knowledge Base gap gap-20261013-eip-8430-everest-transactions-vs-eip: "How does EIP-8430 (Base Transactions, Everest) relate to EIP-8130 (native account abstraction on vibenet)? Is 8430 a successor/rename of 8130 or a separate transaction type?" In an agent evaluation, web-search agents answered "EIP-8130" when asked which EIP defines Base Transactions in Everest.

• Gaps log: https://bdocs.cbhq.net/d/base-knowledge-gaps-log
• Linear: DEVREL-859

Notes to reviewers

Primary sources for each fact:

• EIP-8430 is an independent transaction type split out of EIP-8130, with no Keystore dependency; type 0x79; EIP-8130 specifies an integration: Add EIP: AA Transaction Type ethereum/EIPs#12385 (open), PR description and EIPS/eip-8430.md.
• EIP-8130 is now "Keystore Accounts" with Draft status and specifies the AA Transaction Type integration: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8130.md and Update EIP-8130: scope to the Keystore, move the transaction type to a new EIP ethereum/EIPs#12386 (merged, "scope to the Keystore, move the transaction type to a new EIP").
• Earlier EIP-8130 drafts defined AA_TX_TYPE = 0x79: EIPS/eip-8130.md at ethereum/EIPs commit 16390e1f, before the split commit 1a1f470f.

SME confirmation is not required. The section does not claim that either EIP has been accepted, or give an Everest activation date or Mainnet availability.

Out of scope, flagged for follow-up:

• docs/build-on-base/run-a-local-devnet.mdx still says "EIP-8130 transactions", matching the base/base devnet README. The new section explains that legacy name.
• node scripts/validate-docs-structure.js already fails on master because of the /upgrades/denim/eip-8130 redirect chain to the missing /specifications/native-account-abstraction. This PR doesn't touch docs.json.

How has it been tested?

• node scripts/lint-mdx.js --files-from=<changed files>: 0 errors. There are 2 warnings, both on an existing code block.
• node scripts/validate-docs-structure.js: the same 2 redirect errors appear with and without this change, so they come from master.
• New external link https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8130.md returns HTTP 200.

Screenshots

N/A (text-only change)

Generated with Toshi

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
base	🟢 Ready	View Preview	Oct 19, 2026, 8:42 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[linear]

DEVREL-859

[github-actions]

Docs review

Risk: High (one human reviewer (the tab owner), with an AI pre-review) · risk: high · shadow mode, not enforced

• adds key-handling text in docs/specifications/base-transactions.mdx

Verdict: Fits, with changes · reviewed 91189fb with claude-sonnet-5-5

The change adds a short section to the live Base Transactions spec page explaining how EIP-8430 relates to EIP-8130. The page is the right home, and the facts match the PR's cited sources. The section is mostly well placed, but it sits above the Transaction Format and reads as explanation rather than normative spec. The last paragraph also mixes several ideas, and the page now links EIP-8430 and EIP-8130 inconsistently.

Suggestions

1. Split the overloaded closing paragraph (writing, docs/specifications/base-transactions.mdx L29) — suggestion posted inline
   The paragraph covers legacy naming, EIP status, and activation in one block, and ends with an extra activation sentence that repeats the Warning above. Split it into two ideas and drop the duplicate activation line. Keep one sentence per idea, in active voice.
   Evidence: Content guidelines: one concept per section, concise sentences, lead with behavior; the Warning at lines 18-20 already states Everest activation.
2. Link EIP-8430 where it is first named (consistency, docs/specifications/base-transactions.mdx L24)
   EIP-8130 is linked in the new section, but EIP-8430 is not. The page's own intro and Go Deeper card link EIP-8430 to the PR URL. Link EIP-8430 here for symmetry, and reconsider mixing a blob/master URL for 8130 with a PR URL for 8430, since the PR URL may change once merged. Fix any link target in the PR itself.
   Evidence: Line 8 and line 224 link EIP-8430 to https://github.com/ethereum/EIPs/pull/12385; the new section links only EIP-8130.
3. Consider moving the section below the normative content (placement, docs/specifications/base-transactions.mdx L22)
   Spec pages should lead with behavior, and this background section now sits before the Transaction Format. Consider moving it near the end, before Go Deeper, or shortening it to a Note near the top so that readers reach the format first.
   Evidence: Content guidelines: "Be normative, not tutorial" and "Lead with behavior, not motivation"; pages should open with status, introduction, then key concepts.
4. Tighten the EIP-8130 bullet and define terms (writing, docs/specifications/base-transactions.mdx L27) — suggestion posted inline
   The bullet is long and introduces "authenticator contracts" and "Keystore" without defining them. It also capitalizes "Keystore" inconsistently with "keystore" in line 24. Shorten it and use one form of the term.
   Evidence: Writing rules: define terms when first used, maintain consistent terminology, concise sentences.

What the reviewer checked

Page	Placement	Index section	Neighbors read
docs/specifications/base-transactions.mdx	Live in navigation	not in llms-full.txt	0

Advisory review from the Docs PR review workflow (run). It does not approve, block, or edit this PR. Add the skip-ai-review label to turn it off for this PR.

[github-actions]

Suggested edits from the docs review. Each one is optional; apply it with "Commit suggestion" if you agree.

[github-actions]

Split the overloaded closing paragraph

The paragraph covers legacy naming, EIP status, and activation in one block, and ends with an extra activation sentence that repeats the Warning above. Split it into two ideas and drop the duplicate activation line. Keep one sentence per idea, in active voice.

Suggested change

	Earlier drafts of EIP-8130 defined the `0x79` transaction type themselves, so older material may call these "EIP-8130 transactions." EIP-8430 is an open proposal in the Ethereum EIPs repository, and EIP-8130 has Draft status. A proposal's EIP status does not tell you whether Base Transactions are live on Base. Activation follows the Everest network upgrade.
	Earlier drafts of EIP-8130 defined the `0x79` transaction type, so older material may call these "EIP-8130 transactions."
	EIP-8430 is an open proposal in the Ethereum EIPs repository, and EIP-8130 has Draft status. A proposal's status does not tell you whether Base Transactions are live on Base.

[github-actions]

Tighten the EIP-8130 bullet and define terms

The bullet is long and introduces "authenticator contracts" and "Keystore" without defining them. It also capitalizes "Keystore" inconsistently with "keystore" in line 24. Shorten it and use one form of the term.

Suggested change

	- **EIP-8130** now specifies Keystore Accounts, an onchain keystore that authorizes account actors through authenticator contracts. It also describes how the Keystore can integrate with the EIP-8430 transaction type.
	- **EIP-8130** now specifies Keystore Accounts, an onchain keystore that authorizes account actors through authenticator contracts. It also describes how a keystore integrates with the EIP-8430 transaction type.