feat: add vibenet skill for EIP-8130 devnet, verified against live behaviour

[soheimam]

Description

Adds the vibenet skill for Base's EIP-8130 devnet, and corrects it against live behaviour.

Everything here was verified by building a Next.js app end to end against the devnet — creating 8130 accounts, drawing from the faucet, and sending both self-paid and sponsored transactions. Several of the original claims turned out to be wrong in ways that break working code, so this PR fixes them and adds the gotchas that cost real debugging time.

Endpoints (blocking — every hosted URL was dead)

vibes.base.org now 302-redirects to the chain.base.org/vibenet HTML page. viem's HTTP transport parses that as JSON and throws JSON Parse error: Unrecognized token '<', which reads like a code bug rather than a moved URL.

The API host is api.vibes.base.org; paths are unchanged. Also added faucet/status, chain-health, and the explorer. rpc.vibes.base.org serves access-control-allow-origin: *, so the browser proxy is now documented as optional rather than required (measured from a real browser origin, not curl).

New: account lifecycle

The most common point of confusion, and previously absent: an 8130 account has no deploy step. newSmartAccount8130 derives a CREATE2 address locally with zero RPC; the account is created as a side effect of its first transaction. Adds a lifecycle section covering both routes (sponsored needs no funding and is the shortest path), how to check deployment via eth_getCode, and why deployment state must be read from chain rather than tracked optimistically — it decides whether the next tx carries createChange.

Corrections, each reproduced live

• sendSponsoredCalls resolves with { transactionHash }. The previous text said emphatically not to destructure it. Following it feeds an object into waitForTransactionReceipt8130 and fails with invalid type: map, expected 32 bytes. The declared return type is also wrong, so the call needs a cast either way.
• A bad config sequence is rejected at broadcast, not silently applied. The previous text claimed a skipped authorize "still reports status: success". Measured: a stale or future sequence fails eth_sendRawTransaction with EIP-8130 validation failed: config change sequence mismatch and never lands. The real trap is the inverse — a config change can apply on a transaction reporting status: 0x0. Account changes are not atomic with the calls they ride along with, in either direction.
• The end-to-end example could not compile. It imported createPublicClient, http, parseEther, and toHex from viem/experimental/eip8130, which exports none of them.
• npm install of the fork needs --install-links. Without it npm symlinks outside the project root and Turbopack fails with Module not found: Can't resolve 'viem' for a package that is plainly present (tsc resolves it fine). The install section now leads with the path that works, instead of a bun add that yields an unbuilt monorepo.

New gotchas

• Payer validation lags ~1 block behind a deploy, so sponsoring immediately after one fails with actor is not bound. Retry across the lag.
• no backend is currently healthy to serve traffic means the devnet is halted, not that your code is wrong. Reads keep answering from the last block while sends fail, which disguises it. chain-health is the diagnostic.
• A value-bearing call to a never-funded address reverts (reproduced 4/4). The same call to a funded address succeeds and moves the exact amount, and zero-value to a fresh address is fine. Cause unconfirmed — documented as observed behaviour, and worth a look from whoever owns the devnet.

Type of change

• Base MCP plugin submission
• Update to an existing skill/plugin
• New skill
• Documentation
• Other (please describe):

Affected skill(s)

vibenet

Plugin checklist

• Plugin spec/manifest is accurate and tested
• (If Applicable) API endpoints and/or external MCP/CLI tested and functional
• Follows Contribution Scope

_{Not a Base MCP plugin, so the spec/manifest and contribution-scope items don't apply. Endpoints were tested live against the devnet.}

Verification

• Next.js 16 app built against the skill: create → faucet → self-paid deploy+batch → sponsored send, driven in a real browser with no console errors.
• Gasless onboarding confirmed at a zero balance from start to finish.
• Both skill code examples extracted verbatim and compiled — the accounts example previously did not build.
• Account-change semantics isolated across five cases (call-only, change-only, change+call at live/stale/future sequence).

Related issues

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01BHVyDbPh8A6ySYL7Q7HtnG

[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

[youssefea]

Broken link. Is this the new right link: https://github.com/base/eip-8130 ?

[youssefea]

We should use the official version of Viem that has 8130 access