From ec5f5dfaec5509f500f6ea663d98d1b6729dd4f0 Mon Sep 17 00:00:00 2001 From: Soheima M Date: Thu, 23 Jul 2026 14:00:43 +0200 Subject: [PATCH 1/6] updated native account abstraction docs --- .../specs/upgrades/beryl/eip-8130.mdx | 129 ++++++++++++++++++ .../specs/upgrades/beryl/overview.mdx | 7 + docs/docs.json | 4 +- 3 files changed, 139 insertions(+), 1 deletion(-) create mode 100644 docs/base-chain/specs/upgrades/beryl/eip-8130.mdx diff --git a/docs/base-chain/specs/upgrades/beryl/eip-8130.mdx b/docs/base-chain/specs/upgrades/beryl/eip-8130.mdx new file mode 100644 index 000000000..e56a4b080 --- /dev/null +++ b/docs/base-chain/specs/upgrades/beryl/eip-8130.mdx @@ -0,0 +1,129 @@ +--- +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. + + +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. + + +## 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 + + + + The full hands-on lab: session keys, policies, gas sponsorship, state reading, and known issues. + + + API reference for the experimental `eip8130` module: accounts, batching, sessions, payers, receipts. + + + `AccountConfiguration`, account implementations, and authenticators, with Foundry tests. + + + The EIP-8130 draft, and companion draft [ERC-8168](https://eip.tools/eip/8168) for payer services. + + diff --git a/docs/base-chain/specs/upgrades/beryl/overview.mdx b/docs/base-chain/specs/upgrades/beryl/overview.mdx index dba87a6b9..3ff77e873 100644 --- 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/docs.json b/docs/docs.json index 10d4e9b06..c47c8639f 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -102,7 +102,8 @@ "group": "Beryl Upgrade", "tag": "New", "pages": [ - "base-chain/specs/upgrades/beryl/overview" + "base-chain/specs/upgrades/beryl/overview", + "base-chain/specs/upgrades/beryl/eip-8130" ] }, { @@ -264,6 +265,7 @@ "pages": [ "base-chain/specs/upgrades/beryl/overview", "base-chain/specs/upgrades/beryl/b20" + ] }, { From 82ea512aaf7a0f134d4faa9b7338f0b39d6f79ca Mon Sep 17 00:00:00 2001 From: Soheima M Date: Thu, 23 Jul 2026 14:05:10 +0200 Subject: [PATCH 2/6] updated native account abstraction docs --- docs/base-chain/specs/upgrades/beryl/eip-8130.mdx | 6 ------ 1 file changed, 6 deletions(-) diff --git a/docs/base-chain/specs/upgrades/beryl/eip-8130.mdx b/docs/base-chain/specs/upgrades/beryl/eip-8130.mdx index e56a4b080..db38bce36 100644 --- a/docs/base-chain/specs/upgrades/beryl/eip-8130.mdx +++ b/docs/base-chain/specs/upgrades/beryl/eip-8130.mdx @@ -114,12 +114,6 @@ EIP-8130 moves the abstraction into the chain, so the features 4337 provides thr ## Go deeper - - The full hands-on lab: session keys, policies, gas sponsorship, state reading, and known issues. - - - API reference for the experimental `eip8130` module: accounts, batching, sessions, payers, receipts. - `AccountConfiguration`, account implementations, and authenticators, with Foundry tests. From fc56b0896abc4d4d59692eb88e95b186024e6ccf Mon Sep 17 00:00:00 2001 From: sohey Date: Thu, 23 Jul 2026 19:08:58 +0200 Subject: [PATCH 3/6] updated added cobalt --- .../specs/upgrades/{beryl => cobalt}/eip-8130.mdx | 0 docs/docs.json | 9 +++++++-- 2 files changed, 7 insertions(+), 2 deletions(-) rename docs/base-chain/specs/upgrades/{beryl => cobalt}/eip-8130.mdx (100%) diff --git a/docs/base-chain/specs/upgrades/beryl/eip-8130.mdx b/docs/base-chain/specs/upgrades/cobalt/eip-8130.mdx similarity index 100% rename from docs/base-chain/specs/upgrades/beryl/eip-8130.mdx rename to docs/base-chain/specs/upgrades/cobalt/eip-8130.mdx diff --git a/docs/docs.json b/docs/docs.json index c47c8639f..a80452b8f 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -102,8 +102,7 @@ "group": "Beryl Upgrade", "tag": "New", "pages": [ - "base-chain/specs/upgrades/beryl/overview", - "base-chain/specs/upgrades/beryl/eip-8130" + "base-chain/specs/upgrades/beryl/overview" ] }, { @@ -268,6 +267,12 @@ ] }, + { + "group": "Cobalt", + "pages": [ + "base-chain/specs/upgrades/cobalt/eip-8130" + ] + }, { "group": "Azul", "pages": [ From 6e5fced836d2ae463dc22db2edce0a2e28c896fc Mon Sep 17 00:00:00 2001 From: sohey Date: Thu, 23 Jul 2026 19:08:58 +0200 Subject: [PATCH 4/6] chore: regenerate docs/AGENTS.md, docs/llms-full.txt, docs/llms.txt (post-commit of fc56b08) --- docs/AGENTS.md | 3 ++- docs/llms-full.txt | 5 +++-- docs/llms.txt | 5 +++-- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/docs/AGENTS.md b/docs/AGENTS.md index a696801d9..ccd1c01ec 100644 --- 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/llms-full.txt b/docs/llms-full.txt index e0fe01537..a1c8c522f 100644 --- 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 index b1fd97cdf..cd61f56d0 100644 --- 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. From 898c15f40e37bff98d4835dc013af94874a062f1 Mon Sep 17 00:00:00 2001 From: sohey Date: Thu, 23 Jul 2026 22:40:36 +0200 Subject: [PATCH 5/6] updated added cobalt --- docs/llms.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/llms.txt b/docs/llms.txt index cd61f56d0..679a7cfb5 100644 --- a/docs/llms.txt +++ b/docs/llms.txt @@ -84,7 +84,7 @@ - [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): Transactions are ordered based priority fee and arrival time, which determines which Flashblock they are included in. +- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): This page outlines how Base transactions are ordered. - [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. From 92087eca57e3d8128ab35e14b1ec435569f9d104 Mon Sep 17 00:00:00 2001 From: sohey Date: Fri, 24 Jul 2026 15:12:22 +0200 Subject: [PATCH 6/6] updated to mention vibenet --- docs/base-chain/specs/upgrades/cobalt/eip-8130.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/base-chain/specs/upgrades/cobalt/eip-8130.mdx b/docs/base-chain/specs/upgrades/cobalt/eip-8130.mdx index db38bce36..bf4a66a6a 100644 --- a/docs/base-chain/specs/upgrades/cobalt/eip-8130.mdx +++ b/docs/base-chain/specs/upgrades/cobalt/eip-8130.mdx @@ -6,7 +6,7 @@ description: "Build with native account abstraction on Base. EIP-8130 smart acco [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. -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. +EIP-8130 is experimental and currently runs only on the [vibenet devnet](https://vibes.base.org/build). ## Build with EIP-8130