Vibenet

Vibenet est le devnet de Base pour l'abstraction de compte native EIP-8130 : l'abstraction de compte au niveau du protocole. Les comptes sont portables entre les chaînes EVM, supportent plusieurs types de signataires (secp256k1, P-256, WebAuthn), la rotation de clés sans changement d'adresse, les acteurs de session-key scoped, les politiques on-chain, et le parrainage de gaz natif ERC-8168. Les outils se trouvent dans le module eip8130 de viem (branche fork — pas encore dans npm viem).

Réseau

L'hôte API est api.vibes.base.org, pas vibes.base.org. L'hôte seul effectue une redirection 302 vers la page HTML chain.base.org/vibenet ; le transport HTTP de viem essaie ensuite d'analyser cela en JSON et lève Unrecognized token '<', ce qui ressemble à un bug du code plutôt qu'à une mauvaise URL.

Tous les endpoints api.vibes.base.org (proxy RPC, payeur, robinet) envoient des en-têtes CORS permissifs, tout comme rpc.vibes.base.org — les applications navigateur peuvent donc se connecter à l'un ou l'autre. Préférez rpc.vibes.base.org pour l'exécution et réservez le proxy account/rpc pour quand vous voulez spécifiquement le chemin hébergé.

Les modules 8130 sont additifs à viem lui-même, proposés en amont dans wevm/viem#5004 (toujours un brouillon ouvert — pas encore publié sur npm). Jusqu'à sa publication, ils doivent être construits à partir de la branche fork sur laquelle la PR est ouverte : chunter-cb/viem feat/eip-8130-production.

Utilisez l'installateur fourni — il effectue toute la danse clone→build→link, qui est sujette aux erreurs à la main :

scripts/setup-viem-8130.sh [APP_DIR]   # par défaut le répertoire courant

Quand la PR #5004 fusionnera et qu'une version viem sortira les modules, cela se réduit à npm install viem@latest — les imports (viem/eip8130, viem/eip8168) et les APIs restent inchangés, donc aucun code ne se déplace.

<details><summary>Ce que fait le script et pourquoi chaque étape est nécessaire</summary>

Les outils ne sont pas installables directement à partir de git : l'espace de travail de viem utilise le protocole catalog: de pnpm, donc npm install "viem@github:…" échoue carrément, et bun add "viem@github:…" « réussit » mais vous laisse un monorepo non construit sans champ exports. Donc vous clonez, construisez, puis dépendez du package construit (qui se trouve dans src/ de viem) :

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

# puis dans votre app — --install-links est requis :
npm install --install-links "viem@file:../viem-fork/src"

--install-links est requis. Sans cela npm crée un lien symbolique node_modules/viem vers un chemin en dehors de la racine du projet, et Turbopack/Next.js échoue alors avec Module not found: Can't resolve 'viem' pour un package qui est clairement là (tsc le résout bien, ce qui le fait ressembler à un bug du bundler). </details>

Puis importez à partir de viem/eip8130 (et viem/eip8168 pour les payeurs). Les helpers essentiels comme createPublicClient / parseEther viennent de viem simple — le module 8130 ne les ré-exporte pas.

Si votre build TypeScript rejette les littéraux BigInt du module, définissez "target": "ES2020" ou plus tard dans tsconfig.json. La config générée de Next.js 16 fonctionne déjà telle quelle, puisque sa lib inclut esnext.

Les Comptes N'Ont Pas d'Étape de Déploiement

Créer un compte dérive une adresse CREATE2 localement — synchrone, zéro RPC, eth_getCode toujours 0x. Il devient réel comme effet secondaire de sa première transaction, qui porte account.createChange aux côtés de vos appels réels. Il n'y a rien d'autre à appeler. Le plus court chemin de rien à un compte déployé est une première tx parrainée (pas de robinet, pas de financement) ; la route auto-financée a besoin que l'adresse soit d'abord financée. Lisez l'état du déploiement à partir de eth_getCode, jamais à partir de l'état local optimiste — cela détermine si la tx suivante porte createChange. Cycle de vie complet : references/eip8130-accounts.md.

Garde-fous de Sécurité

• Ne commitez jamais les clés privées — générez des clés jetables pour les scripts devnet, lisez les vraies à partir de variables d'env.
• key.k1(...) construit une identité d'acteur, pas un signataire — la passer (ou une clé privée brute en hex) en tant que signer échoue avec un pad() TypeError opaque. Utilisez privateKeyToAccount(pk).
• Vérifiez les changements de config par relecture on-chain (isActor / getConfigSequence), jamais par les logs de reçus ou status: success — une autorisation sautée est silencieuse.
• Lisez la séquence de config live juste avant de signer — une séquence en dur cause des no-ops silencieux.

Routage des Tâches

Lisez la référence pour votre tâche :

Procédure Opérationnelle

1. Classifiez la tâche à l'aide du tableau ci-dessus et lisez la référence pertinente avant d'implémenter.
2. Choisissez le bon RPC : rpc.vibes.base.org fonctionne depuis Node et le navigateur ; api.vibes.base.org/api/vibenet/account/rpc est le proxy hébergé vers la même chaîne. Jamais vibes.base.org — cet hôte n'est pas une API.
3. Implémentez avec l'id de chaîne explicite, l'installation scripts/setup-viem-8130.sh, et la vérification par relecture pour tout changement de config du compte.
4. Livrez du code exécutable, des commandes d'installation et tout étape manuelle (variables d'env, financement du robinet).

Pour les Cas Limites et les Derniers Changements d'API

• Spec EIP-8130 : eip.tools/eip/8130 (standard payeur : eip.tools/eip/8168)
• Fork viem : chunter-cb/viem feat/eip-8130-production (PR en amont : wevm/viem#5004 ; surface API : src/eip8130/index.ts ; docs : site/pages/eip8130)
• Guide complet (en chapitres) : github.com/chunter-cb/eip-8130-web (/guide/*)
• Walkthrough session-key : gist.github.com/chunter-cb/bf70c53a5ab6d8361ce7f4215b776114

Installation

npx skills add base/skills --skill vibenet