/vibenet

name: vibenet
description: >-
  Build on vibenet — Base's devnet for native account abstraction (EIP-8130),
  payer gas sponsorship (ERC-8168), and Cobalt 200ms native blocks. Use
  whenever the user mentions vibenet, EIP-8130, ERC-8168, 8130 accounts, native
  account abstraction, session keys, actors, policies, payers, gas sponsorship
  on Base, 200ms blocks, Cobalt, BaseTime, timestampMs / blockTimestampMs,
  sub-second or millisecond block timestamps, migrating from Flashblocks, or
  newHeads / WebSocket streaming on vibenet — or is writing code that creates
  or operates 8130 smart accounts, authorizes session-key actors, sends batched
  calls, sponsors gas with a payer, queries or streams vibenet blocks, times a
  transaction's inclusion, or wires a frontend/script against the vibenet
  devnet or Base Sepolia.

Vibenet

Vibenet is Base's devnet for **EIP-8130 native account abstraction**: account abstraction in the protocol itself. Accounts are portable across EVM chains, support multiple signer types (secp256k1, P-256, WebAuthn), key rotation without changing address, scoped session-key actors, on-chain policies, and native **ERC-8168** gas sponsorship. The tooling lives in viem's `eip8130` module (fork branch — not yet in npm `viem`). Vibenet is also the first Base network running **Cobalt 200ms native blocks** (five canonical blocks per second, with a millisecond `timestampMs` on every block) — that part needs no fork, stock `viem` works. See [references/200ms-blocks.md](references/200ms-blocks.md).

Network

| Endpoint | Value | |----------|-------| | Chain ID | `84538453` | | Public execution RPC | `https://rpc.vibes.base.org` — 8130-capable (`AA_TX_TYPE` / `0x79`), serves `access-control-allow-origin: *` | | WebSocket RPC | `wss://rpc.vibes.base.org/ws` — `newHeads`, `logs`, `transactionReceipts` subscriptions (the `/ws` path is required) | | Block time | **200ms** (Cobalt); blocks carry `timestampMs`, BaseTime predeploy at `0x4200000000000000000000000000000000000030` | | Browser RPC proxy | `https://api.vibes.base.org/api/vibenet/account/rpc` — passes through all `eth_*`, including `0x79` broadcasts and receipt polling | | Hosted payer (ERC-8168) | `https://api.vibes.base.org/api/vibenet/account/payer` | | Faucet | `POST https://api.vibes.base.org/api/vibenet/faucet/drip` with `{ "address": "0x…" }` | | Faucet status | `GET https://api.vibes.base.org/api/vibenet/faucet/status` — drip size, cooldowns, USDV/NFV token addresses | | Chain health | `GET https://api.vibes.base.org/api/vibenet/chain-health` — key off `healthy` + `headAgeSecs`; `stuckSecs` is not actionable on its own (seen at 19000 on a healthy chain) | | Landing page / explorer | `https://chain.base.org/vibenet`, `https://chain.base.org/vibenet/explorer` | | Base Sepolia (also 8130-enabled) | `https://sepolia.base.org`, chain id `84532` |

**The API host is `api.vibes.base.org`, not `vibes.base.org`.** The bare host 302-redirects to the `chain.base.org/vibenet` HTML page; viem's HTTP transport then tries to parse that as JSON and throws `Unrecognized token '<'`, which reads like a code bug rather than a wrong URL.

All `api.vibes.base.org` endpoints (RPC proxy, payer, faucet) send permissive CORS headers, and so does `rpc.vibes.base.org` — so browser apps can talk to either. Prefer `rpc.vibes.base.org` for execution and reserve the `account/rpc` proxy for when you specifically want the hosted path. The public RPC is method-allowlisted: `eth_getHeaderBy*`, `eth_getBlockReceipts`, `eth_sendRawTransactionSync`, `eth_simulateV1` and `txpool_*` answer `rpc method is not whitelisted`.

**Only 8130 / 8168 code needs the fork below.** Querying blocks, streaming `newHeads`, and sending plain EOA transactions on vibenet work with stock `npm install viem`.

The 8130 modules are additive to viem itself, proposed upstream in [wevm/viem#5004](https://github.com/wevm/viem/pull/5004) (open, out of draft — not yet merged or released to npm). Until it ships, they have to be built from the fork branch the PR is opened from: `chunter-cb/viem` `feat/eip-8130-production`.

**Use the bundled installer** — it does the whole clone→build→link dance, which is error-prone by hand:

scripts/setup-viem-8130.sh [APP_DIR] [BUILD_DIR]   # APP_DIR defaults to the current directory

`BUILD_DIR` defaults to `<APP_DIR>/.viem-8130-src` — a full viem monorepo checkout with its own `node_modules` (~500 MB). The script appends `.viem-8130-src/` to the app's `.gitignore` so a `git add .` can't commit it; for several apps, pass one shared `BUILD_DIR` outside them (npm records the `file:` path in `package.json`). Node 22 works despite the fork's `node >=24.5` engine warning.

When PR #5004 merges and a viem release ships the modules, this collapses to `npm install viem@latest` — the imports (`viem/eip8130`, `viem/eip8168`) and APIs are unchanged, so no code moves.

<details><summary>What the script does, and why each step is needed</summary>

The tooling is **not installable from git directly**: viem's workspace uses pnpm's `catalog:` protocol, so `npm install "viem@github:…"` fails outright, and `bun add "viem@github:…"` "succeeds" but leaves you an unbuilt monorepo with no `exports` field. So you clone, build, then depend on the built package (which lives in viem's `src/`):

git clone -b feat/eip-8130-production https://github.com/chunter-cb/viem viem-fork
cd viem-fork && npx pnpm install --ignore-scripts && npx pnpm run build

# then in your app — --install-links is required:
npm install --install-links "viem@file:../viem-fork/src"

**`--install-links` is required.** Without it npm symlinks `node_modules/viem` to a path outside the project root, and Turbopack/Next.js then fails with `Module not found: Can't resolve 'viem'` for a package that is plainly there (`tsc` resolves it fine, which makes it look like a bundler bug). </details>

Then import from `viem/eip8130` (and `viem/eip8168` for payers). Core helpers like `