---
title: "Cobalt Upgrade Overview"
description: "Summary of the Cobalt hardfork — the upgrade that brings native account abstraction (EIP-8130) into the Base protocol."
source: https://basehub.org/specifications/cobalt-overview/
---
import { Aside } from '@astrojs/starlight/components';

Cobalt is the Base hardfork that follows [Beryl](/specifications/beryl-overview/), and it carries a single headline change: account abstraction stops being something applications assemble around the chain and becomes part of the chain. Under [EIP-8130](https://eip.tools/eip/8130) an account writes down, onchain, which identities are allowed to act for it and how their signatures get checked. Base then validates every transaction against that record, which is what lets a smart account send an ordinary transaction.

## What Cobalt ships

- **[Native account abstraction](/architecture/native-account-abstraction/) (EIP-8130)** — accounts hold their authorized actors and their signature-validation rules in an onchain system contract.
- **No supporting infrastructure** — accounts that travel between chains, keys scoped to a single session, batches that commit as one, and sponsored gas all land without a bundler, a relay, or a second mempool behind them.

## Activation timestamps

| Network | Timestamp | Date |
|---------|-----------|------|
| `mainnet` | TBD | TBD |
| `sepolia` | TBD | TBD |
| `vibenet` | Active | Available to preview today |

<Aside type="caution">
Cobalt has no date on Mainnet or Sepolia yet. EIP-8130 is still experimental, and the only network running it is the [vibenet devnet](https://chain.base.org/vibenet).
</Aside>

## Required software

Node requirements get published once Cobalt has a schedule, so there is nothing for operators to install ahead of time. To follow the work as it lands, point a client at [vibenet](/introduction/connecting-to-base/) instead.

## Native account abstraction (EIP-8130)

An account registers its actors and its validation rules once, and from then on the protocol enforces them on every transaction. Nothing sits in between — no bundler, no relay, no separate transaction pool.

What that buys an application is a set of behaviours that previously each needed their own machinery: accounts that a user carries between chains, session keys that expire and revoke as real permissions rather than blanket approvals, batches that succeed or fail as one unit, and gas that someone else can pay without a paymaster contract in the path.

The full model — accounts, signers and actors, scopes and policies, authenticators, and payers — plus a working vibenet example is in [Native Account Abstraction](/architecture/native-account-abstraction/).