base · soheimam · Jul 23, 2026 · Jul 23, 2026 · Jul 23, 2026 · Jul 23, 2026
diff --git a/docs/AGENTS.md b/docs/AGENTS.md
@@ -80,7 +80,7 @@ npx skills add base/base-skills
 |base-chain/api-reference/ethereum-json-rpc-api:eth_blockNumber,eth_call,eth_chainId,eth_estimateGas,eth_feeHistory,eth_gasPrice,eth_getBalance,eth_getBlockByHash,eth_getBlockByNumber,eth_getBlockReceipts,eth_getBlockTransactionCountByHash,eth_getBlockTransactionCountByNumber,eth_getCode,eth_getLogs,eth_getStorageAt,eth_getTransactionByBlockHashAndIndex,eth_getTransactionByBlockNumberAndIndex,eth_getTransactionByHash,eth_getTransactionCount,eth_getTransactionReceipt,eth_maxPriorityFeePerGas,eth_sendRawTransaction,eth_subscribe,eth_syncing,eth_unsubscribe,net_version,web3_clientVersion
 |base-chain/api-reference/flashblocks-api:base_transactionStatus,eth_simulateV1,flashblocks-api-overview,newFlashblockTransactions,newFlashblocks,pendingLogs
 |base-chain/flashblocks:faq
-|base-chain/network-information:base-contracts,base-solana-bridge,bridging-and-withdrawals,ecosystem-bridges,network-faucets,network-fees,throughput-and-limits,transaction-finality,transaction-ordering,troubleshooting-transactions
+|base-chain/network-information:base-contracts,base-solana-bridge,bridging-and-withdrawals,configuration-changelog,ecosystem-bridges,network-faucets,network-fees,throughput-and-limits,transaction-finality,transaction-ordering,troubleshooting-transactions
 |base-chain/node-operators:node-providers,performance-tuning,run-a-base-node,snapshots,troubleshooting
 |base-chain/quickstart:connecting-to-base
 |base-chain/security:avoid-malicious-flags,bug-bounty,report-vulnerability,security-council
@@ -95,6 +95,7 @@ npx skills add base/base-skills
 |base-chain/specs/upgrades/azul:exec-engine,node-upgrade,overview,proofs
 |base-chain/specs/upgrades/beryl:b20,overview
 |base-chain/specs/upgrades/canyon:overview
+|base-chain/specs/upgrades/cobalt:eip-8130
 |base-chain/specs/upgrades/delta:overview,span-batches
 |base-chain/specs/upgrades/ecotone:derivation,l1-attributes,overview
 |base-chain/specs/upgrades/fjord:derivation,exec-engine,overview,predeploys

diff --git a/docs/base-chain/specs/upgrades/beryl/overview.mdx b/docs/base-chain/specs/upgrades/beryl/overview.mdx
@@ -8,6 +8,7 @@ description: "Overview of the Beryl hardfork, introducing the B20 native token s
 - Introduce [B20](/base-chain/specs/upgrades/beryl/b20): Base's native token standard for stablecoin, real-world asset (RWA), and long-tail token issuers
 - Reduce the single-proof withdrawal finalization period from 7 days to 5 days for increased capital efficiency
 - Reth V2: up to 50% disk reduction and a rewritten state root pipeline delivering +33% throughput
+- Upcoming in a later Beryl phase: [native account abstraction (EIP-8130)](/base-chain/specs/upgrades/beryl/eip-8130), currently previewing on the vibenet devnet
 
 ## Activation Timestamps
 
@@ -40,6 +41,12 @@ B20 is Base's native token standard - ERC-20 compatible tokens implemented as Ru
 - [Mint & Burn](/base-chain/specs/upgrades/beryl/b20#mint)
 - [Variants](/base-chain/specs/upgrades/beryl/b20#variants)
 
+## Native Account Abstraction (EIP-8130)
+
+A later Beryl phase brings account abstraction into the protocol. Accounts configure authorized actors and signature validation onchain. Apps get portable smart accounts, scoped session keys, atomic batching, and native gas sponsorship without bundler or relay infrastructure. EIP-8130 is experimental and currently runs only on the vibenet devnet.
+
+- [Native Account Abstraction (EIP-8130)](/base-chain/specs/upgrades/beryl/eip-8130)
+
 ## Withdrawals
 
 The single-proof dispute game finalization window is reduced from 7 days to 5 days. The dual-proof fast path (TEE + ZK) introduced in Azul remains at 1 day.

diff --git a/docs/base-chain/specs/upgrades/cobalt/eip-8130.mdx b/docs/base-chain/specs/upgrades/cobalt/eip-8130.mdx
@@ -0,0 +1,123 @@
+---
+title: "Native Account Abstraction"
+description: "Build with native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers or relays."
+---
+
+[EIP-8130](https://eip.tools/eip/8130) builds account abstraction into the protocol. An account registers who can act for it, and how its signatures are checked, in an onchain system contract. The chain validates each transaction against that configuration, so smart accounts work without bundlers, relays, or a separate mempool.
+
+<Warning>
+EIP-8130 is experimental and activates in a later Beryl phase. It currently runs only on the [vibenet devnet](https://vibes.base.org/build). The spec is still changing and the reference contracts have not been audited. Do not use it in production.
+</Warning>
+
+## Build with EIP-8130
+
+EIP-8130 is live on vibenet (chain ID `84538453`, RPC `https://rpc.vibes.base.org`). Client support lives in an experimental viem fork:
+
+```bash
+bun add "viem@github:chunter-cb/viem#feat/eip-8130"
+```
+
+The example below performs the full flow:
+
+1. Creates an account.
+2. Funds it from the faucet.
+3. Sends a batch of calls that succeed or revert together.
+4. Verifies that every phase succeeded.
+
+```ts create-and-send.ts highlight={19,30-40,43-44}
+import { createPublicClient, http, parseEther } from "viem";
+import { privateKeyToAccount, generatePrivateKey } from "viem/accounts";
+import {
+  newSmartAccount8130, sendCalls8130, estimateGas8130,
+  encodeWalletCalls, waitForTransactionReceipt8130, allPhasesSucceeded,
+} from "viem/experimental/eip8130";
+
+const RPC_URL = "https://rpc.vibes.base.org";
+const chain = {
+  id: 84538453,
+  name: "vibenet",
+  nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
+  rpcUrls: { default: { http: [RPC_URL] } },
+};
+const client = createPublicClient({ chain, transport: http(RPC_URL) });
+
+// The account address is deterministic and exists before any deployment
+const signer = privateKeyToAccount(generatePrivateKey());
+const account = newSmartAccount8130({ signer });
+
+// Fund it from the vibenet faucet
+await fetch("https://vibes.base.org/api/vibenet/faucet/drip", {
+  method: "POST",
+  headers: { "content-type": "application/json" },
+  body: JSON.stringify({ address: account.address }),
+});
+
+// Estimate, then send a batch. Account creation rides along in the same transaction
+const calls = [{ to: "0x…recipient", value: parseEther("0.001") }];
+const gas = await estimateGas8130(client, {
+  sender: account.address,
+  accountChanges: [account.createChange],
+  calls: encodeWalletCalls({ account: account.address, calls: [calls] }),
+});
+const hash = await sendCalls8130(client, {
+  account,
+  accountChanges: [account.createChange],
+  calls,
+  gas: (gas * 120n) / 100n,
+});
+
+// An 8130 receipt reports per-phase results, so check all of them
+const receipt = await waitForTransactionReceipt8130(client, { hash });
+if (!allPhasesSucceeded(receipt)) throw new Error("a phase reverted");
+```
+
+One transaction creates the account, executes the batch, and pays for gas.
+
+## How it works
+
+Everything in the example maps to one of five concepts. An 8130 transaction names a sender account, proves the sender is authorized to act for it, and carries a batch of calls.
+
+### Account
+
+Account addresses are deterministic: viem computes them locally with `CREATE2`. That is why `account.address` exists before any deployment and `account.createChange` rides along in the first transaction. Each account is a small proxy contract that forwards calls to a shared implementation. `DefaultAccount` is the minimal building block and backs externally owned accounts (EOAs) upgraded via EIP-7702. A variant built for high transaction rates locks outbound ETH during execution in exchange for higher mempool rate limits.
+
+### Signer and Actor
+
+A **signer** produces the transaction's authorization (`privateKeyToAccount` above). An **actor** is the onchain identity that authorization resolves to, recorded in the `AccountConfiguration` system contract. An account can authorize many actors and revoke each independently.
+
+### Scope and Policy
+
+Each actor carries **scope** flags (`SCOPE_NONCE`, `SCOPE_POLICY`) that limit what it may do. It can also bind to an onchain **policy**: per-token spend limits and restrictions on which contracts and functions it may call. This is the native session-key model: an app gets an actor with exactly the permissions it needs, revocable at any time.
+
+### Authenticators
+
+Signature validation is pluggable. Authenticator contracts implement `IAuthenticator.authenticate(hash, data)`. The reference set covers secp256k1 (standard Ethereum keys), P-256, and WebAuthn. Passkeys therefore validate at the protocol level, not through wrapper contracts.
+
+### Payer
+
+A transaction can name a **payer** that covers gas on the sender's behalf. Draft [ERC-8168](https://eip.tools/eip/8168) standardizes the payer service flow: how apps discover and request sponsorship.
+
+## Why native account abstraction
+
+Smart accounts on Ethereum today are bolted on from outside the protocol. [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) requires an alternate mempool, bundlers, and an EntryPoint contract; every app inherits that infrastructure and its costs. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) delegates an EOA to contract code, but the account still validates against its single original key.
+
+EIP-8130 moves the abstraction into the chain, so the features 4337 provides through external services come built into ordinary transactions:
+
+| | ERC-4337 | EIP-7702 | EIP-8130 |
+|---|---|---|---|
+| Validation | EntryPoint contract via bundlers | One fixed key | Protocol, against onchain configuration |
+| Infrastructure | Bundlers + alternate mempool | None | None - standard transactions |
+| Session keys | Per-wallet plugin systems | Not native | Native actors with scoped policies |
+| Gas sponsorship | Paymaster contracts | Not native | Native payers ([ERC-8168](https://eip.tools/eip/8168)) |
+| Batching | Via account contract | Via delegated code | Native, atomic, per-transaction |
+
+## Go deeper
+
+<CardGroup cols={2}>
+  <Card title="Reference contracts" href="https://github.com/base/eip-8130" icon="github">
+    `AccountConfiguration`, account implementations, and authenticators, with Foundry tests.
+  </Card>
+  <Card title="Specifications" href="https://eip.tools/eip/8130" icon="file-lines">
+    The EIP-8130 draft, and companion draft [ERC-8168](https://eip.tools/eip/8168) for payer services.
+  </Card>
+</CardGroup>
diff --git a/docs/docs.json b/docs/docs.json
@@ -264,6 +264,13 @@
                     "pages": [
                       "base-chain/specs/upgrades/beryl/overview",
                       "base-chain/specs/upgrades/beryl/b20"
+
+                    ]
+                  },
+                  {
+                    "group": "Cobalt",
+                    "pages": [
+                      "base-chain/specs/upgrades/cobalt/eip-8130"
                     ]
                   },
                   {

diff --git a/docs/llms-full.txt b/docs/llms-full.txt
@@ -172,12 +172,12 @@ const client = createPublicClient({ chain: base, transport: http() })
 - [Network Fees](https://docs.base.org/base-chain/network-information/network-fees): Documentation about network fees on Base. This page covers details of the two-component cost system involving L2 execution fees and L1 security fees, and offers insights on fee variations and cost-saving strategies.
 - [Throughput and Limits](https://docs.base.org/base-chain/network-information/throughput-and-limits): Gas limits and throughput-related network parameters on Base.
 - [Transaction Finality](https://docs.base.org/base-chain/network-information/transaction-finality): Detailed information about transaction finality on Base.
-- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): This page outlines how Base transactions are ordered.
+- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): Transactions are ordered based priority fee and arrival time, which determines which Flashblock they are included in.
 - [Troubleshooting Transactions](https://docs.base.org/base-chain/network-information/troubleshooting-transactions): Guide to diagnosing and resolving transaction issues on Base.
 - [Node Providers](https://docs.base.org/base-chain/node-operators/node-providers): Documentation for Node Providers for the Base network. Including details on their services, supported networks, and pricing plans.
 - [Node Performance](https://docs.base.org/base-chain/node-operators/performance-tuning): Hardware specifications, storage requirements, client recommendations, and configuration settings for running a performant Base node.
 - [Run a Node](https://docs.base.org/base-chain/node-operators/run-a-base-node): A tutorial that teaches how to set up and run a Base Node.
-- [Node Snapshots](https://docs.base.org/base-chain/node-operators/snapshots): Download and restore Base node snapshots to significantly reduce initial sync time for both archive and pruned nodes.
+- [Node Snapshots](https://docs.base.org/base-chain/node-operators/snapshots): Download and restore Base node snapshots to significantly reduce initial sync time for nodes.
 - [Node Troubleshooting](https://docs.base.org/base-chain/node-operators/troubleshooting): Solutions to common issues when setting up and running a Base node, covering sync problems, networking, snapshots, and performance.
 - [Connecting to Base](https://docs.base.org/base-chain/quickstart/connecting-to-base): Network details and wallet setup for Base Mainnet, Base Testnet (Sepolia), and Base Vibenet.
 - [How to avoid getting your app flagged as malicious](https://docs.base.org/base-chain/security/avoid-malicious-flags): The Base bug bounty program and procedures for reporting vulnerabilities.
@@ -207,6 +207,7 @@ const client = createPublicClient({ chain: base, transport: http() })
 - [Node Upgrade Guide](https://docs.base.org/base-chain/specs/upgrades/azul/node-upgrade): Migrate your Base node to base-reth-node and base-consensus for Azul.
 - [Proof System](https://docs.base.org/base-chain/specs/upgrades/azul/proofs): Specification of the Azul multi-proof system, replacing the single output proposer with an AggregateVerifier contract for L2 checkpoint security.
 - [B20 Native Token Standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): B20 is Base's native token standard - designed for stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators.
+- [Native Account Abstraction](https://docs.base.org/base-chain/specs/upgrades/cobalt/eip-8130): Build with native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers or relays.
 - [Span-batches](https://docs.base.org/base-chain/specs/upgrades/delta/span-batches): Specification of span batches introduced in Delta, a new batch format that compresses sequences of L2 blocks for more efficient L1 data posting.
 - [Derivation](https://docs.base.org/base-chain/specs/upgrades/ecotone/derivation): Derivation changes in the Ecotone upgrade, extending the retrieval stage to support EIP-4844 blobs as an additional data availability source.
 - [Ecotone L1 Attributes](https://docs.base.org/base-chain/specs/upgrades/ecotone/l1-attributes): L1 attributes transaction changes in the Ecotone upgrade, updating calldata format to support the new blob-based fee calculation model.

diff --git a/docs/llms.txt b/docs/llms.txt
@@ -84,12 +84,12 @@
 - [Network Fees](https://docs.base.org/base-chain/network-information/network-fees): Documentation about network fees on Base. This page covers details of the two-component cost system involving L2 execution fees and L1 security fees, and offers insights on fee variations and cost-saving strategies.
 - [Throughput and Limits](https://docs.base.org/base-chain/network-information/throughput-and-limits): Gas limits and throughput-related network parameters on Base.
 - [Transaction Finality](https://docs.base.org/base-chain/network-information/transaction-finality): Detailed information about transaction finality on Base.
-- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): This page outlines how Base transactions are ordered.
+- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): Transactions are ordered based priority fee and arrival time, which determines which Flashblock they are included in.
 - [Troubleshooting Transactions](https://docs.base.org/base-chain/network-information/troubleshooting-transactions): Guide to diagnosing and resolving transaction issues on Base.
 - [Node Providers](https://docs.base.org/base-chain/node-operators/node-providers): Documentation for Node Providers for the Base network. Including details on their services, supported networks, and pricing plans.
 - [Node Performance](https://docs.base.org/base-chain/node-operators/performance-tuning): Hardware specifications, storage requirements, client recommendations, and configuration settings for running a performant Base node.
 - [Run a Node](https://docs.base.org/base-chain/node-operators/run-a-base-node): A tutorial that teaches how to set up and run a Base Node.
-- [Node Snapshots](https://docs.base.org/base-chain/node-operators/snapshots): Download and restore Base node snapshots to significantly reduce initial sync time for both archive and pruned nodes.
+- [Node Snapshots](https://docs.base.org/base-chain/node-operators/snapshots): Download and restore Base node snapshots to significantly reduce initial sync time for nodes.
 - [Node Troubleshooting](https://docs.base.org/base-chain/node-operators/troubleshooting): Solutions to common issues when setting up and running a Base node, covering sync problems, networking, snapshots, and performance.
 - [Connecting to Base](https://docs.base.org/base-chain/quickstart/connecting-to-base): Network details and wallet setup for Base Mainnet, Base Testnet (Sepolia), and Base Vibenet.
 - [How to avoid getting your app flagged as malicious](https://docs.base.org/base-chain/security/avoid-malicious-flags): The Base bug bounty program and procedures for reporting vulnerabilities.
@@ -119,6 +119,7 @@
 - [Node Upgrade Guide](https://docs.base.org/base-chain/specs/upgrades/azul/node-upgrade): Migrate your Base node to base-reth-node and base-consensus for Azul.
 - [Proof System](https://docs.base.org/base-chain/specs/upgrades/azul/proofs): Specification of the Azul multi-proof system, replacing the single output proposer with an AggregateVerifier contract for L2 checkpoint security.
 - [B20 Native Token Standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): B20 is Base's native token standard - designed for stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators.
+- [Native Account Abstraction](https://docs.base.org/base-chain/specs/upgrades/cobalt/eip-8130): Build with native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers or relays.
 - [Span-batches](https://docs.base.org/base-chain/specs/upgrades/delta/span-batches): Specification of span batches introduced in Delta, a new batch format that compresses sequences of L2 blocks for more efficient L1 data posting.
 - [Derivation](https://docs.base.org/base-chain/specs/upgrades/ecotone/derivation): Derivation changes in the Ecotone upgrade, extending the retrieval stage to support EIP-4844 blobs as an additional data availability source.
 - [Ecotone L1 Attributes](https://docs.base.org/base-chain/specs/upgrades/ecotone/l1-attributes): L1 attributes transaction changes in the Ecotone upgrade, updating calldata format to support the new blob-based fee calculation model.