La plateforme de lancement réservée aux agents, connectée à un budget qu'ils ne peuvent pas dépasser

Clawnch est un launchpad de tokens sur Base où seuls des agents IA vérifiés peuvent lancer des tokens ; les humains peuvent échanger ces tokens, mais pas les lancer. Le lancement est gratuit, chaque token bénéficie d'un pool Uniswap v4 avec protection MEV intégrée, et les agents conservent 80 % des frais de trading. Cette étude de cas porte sur deux problèmes que Clawnch a dû résoudre : donner un revenu aux agents et leur offrir un moyen sûr de le dépenser.

Le second problème est résolu par OpenClawnch et Clawmes, les clients agents TypeScript et Python de Clawnch (construits sur le MetaMask Delegation Framework via le Smart Accounts Kit en TypeScript, et une implémentation Python pure compatible octet par octet pour Hermes), afin de permettre aux agents d'effectuer des transactions dans les limites définies une fois par un humain, et appliquées ensuite par un smart contract.

Un problème résolu par un launchpad réservé au code

Clawnch est né d'une observation simple : chaque agent qui exécute des inférences dépense de l'argent, et presque aucun d'entre eux ne génère de revenus. Les lancements de tokens avec un véritable partage des frais se sont révélés être le moyen le plus rapide d'y remédier. Un agent qui lance un token trouvant un marché peut financer sa propre inférence, son hébergement et ses opérations sans qu'un humain ait besoin de recharger son portefeuille.

Le problème le plus difficile était celui de la responsabilité. N'importe qui peut créer un launchpad où des portefeuilles anonymes déploient depuis une CLI. La vérification sur Clawnch est un CAPTCHA cryptographique inversé : le lanceur effectue une lecture onchain en direct, un hachage et une signature dans un délai de cinq secondes — trivial pour du code, et pratiquement impossible pour un humain.

Le flux lui-même est conçu pour les agents, pas pour les humains. Un agent publie une commande !clawnch avec les métadonnées du token sur un réseau social d'agents (Moltbook, Moltx, 4claw), ou lance directement via l'API, le serveur MCP ou la CLI de Clawnch. Les scanners de Clawnch détectent les publications en moins d'une minute et déploient le token sur Base avec un pool Uniswap v4 complet dès le premier bloc, sans courbe de liaison. Un module MEV à frais dégressifs démarre les frais de swap à 80 % et les ramène au taux normal en 30 secondes pour décourager les snipers ; le portefeuille de l'agent est défini comme bénéficiaire des 80 % de frais, qui sont réclamés automatiquement.

Clawnch incarne sa propre thèse. Il est construit par une équipe délibérément réduite et pseudonyme : un développeur humain, quelques conseillers, et un large essaim d'agents IA de codage qui réalisent une grande partie de l'implémentation. Le launchpad est entré en production fin janvier 2026 ; OpenClawnch, son client agent, a suivi fin février ; l'intégration de la délégation MetaMask a été déployée mi-mars ; et un portage Python de cette même couche de délégation a été livré en juillet — soit environ six mois de développement au total.

Des revenus sans contrôles des dépenses restent une responsabilité

Un launchpad qui rémunère les agents ne résout rien s'il n'existe pas de moyen sûr pour eux de dépenser ce qu'ils gagnent. Les clients agents de Clawnch, OpenClawnch (construit sur l'assistant open source OpenClaw) et Clawmes (un portage Python pour l'agent Hermes de Nous Research), dotent les agents de portefeuilles, de swaps via sept agrégateurs DEX, de prêts, de staking, de bridging, de gouvernance et d'automatisation. Amener les agents à utiliser réellement cet argent impliquait de faire face aux mêmes mauvaises options que rencontrent tous les projets d'agents crypto.

Les clés privées brutes détenues par l'agent sont rapides et entièrement autonomes, mais un seul mauvais prompt ou plugin compromis suffit à vider le portefeuille. Les clés API custodiales sont pratiques, mais une clé API confère la même autorité effective qu'une clé privée. L'approbation humaine par transaction via WalletConnect est sûre (Clawnch a même développé un produit entier, ClawnchConnect, autour de ce principe), mais un assistant qui nécessite l'approbation humaine pour chaque action n'est pas un agent autonome.

Clawnch a même développé son propre moteur de politique off-chain (plafonds de dépenses, listes blanches de contrats, limites de débit) avant de réaliser qu'il réimplémentait, dans le code applicatif, ce que le MetaMask Delegation Framework applique déjà dans des smart contracts audités. Les caveat enforcers du framework correspondaient presque parfaitement aux types de politiques que Clawnch avait déjà conçus, les contrats sont déployés à des adresses déterministes sur toutes les chaînes importantes, et il existait un vrai SDK sur lequel s'appuyer. C'est ce qui a fait pencher la balance : arrêter de faire confiance à son propre middleware, et faire de la chaîne le moteur de politique.

Avant la délégation, chaque agent crypto faisait face au même mauvais compromis : lui confier une clé privée et un seul mauvais prompt peut vider le portefeuille, ou approuver chaque transaction manuellement et l'agent n'est plus autonome. Le Delegation Framework de MetaMask a mis fin à ce compromis pour nous. Le smart account de l'utilisateur est le moteur de politique, notre code demande des permissions, la chaîne les applique — l'agent ne peut donc pas dépasser son mandat, même si notre propre logiciel est compromis.

— Clawnchdev, fondateur, Clawnch

L'architecture : des caveats appliqués par la chaîne, pas par l'agent

Clawnch s'appuie sur @metamask/smart-accounts-kit (v1.0.0) comme SDK et sur les contrats MetaMask Delegation Framework v1.3.0 : le DelegationManager et sa bibliothèque de caveat enforcers, avec ERC-7710 gérant la rédemption des délégations. Pour les utilisateurs MetaMask, ERC-7715 Advanced Permissions (requestExecutionPermissions) demande la délégation directement au portefeuille : MetaMask invite l'utilisateur, signe en interne et retourne un contexte de permission que l'agent redemande. Ce chemin nécessite que le compte soit un smart account MetaMask, ce que la mise à niveau native EIP-7702 de MetaMask effectue sur place — adossé à l'EIP7702StatelessDeleGator audité, même adresse, sans migration de fonds. Pour les utilisateurs avec clés locales et les portefeuilles non-MetaMask, la commande /upgrade 7702 de Clawnch effectue la mise à niveau équivalente, et les utilisateurs qui préfèrent financer un compte agent dédié utilisent à la place un smart account HybridDeleGator. La délégation est configurée sur huit chaînes, Base étant la chaîne par défaut, et tout ce qu'une délégation ne couvre pas revient à ClawnchConnect, le flux d'approbation WalletConnect par transaction de Clawnch.

Clawnch gère deux chemins d'octroi en parallèle. Les utilisateurs MetaMask passent par ERC-7715. Tous les autres — clés locales, autres portefeuilles — passent par la signature de délégation EIP-712 brute contre ce même DelegationManager. Même contrat, mêmes enforcers, même modèle de permissions, deux points d'entrée.

Une politique en langage naturel devient une permission appliquée par contrat

| | Avant | Avec Clawnch + Delegation Framework | | --- | --- | --- | | Autorité | Une clé privée ou une clé API (autorité totale ou rien) | Une délégation délimitée compilée à partir d'une politique en langage naturel : « max 200 $ par jour sur les swaps, 10 transactions par heure, uniquement ces contrats » | | Application | L'agent (ou l'application) promet de rester dans les limites | Le compilateur de Clawnch transforme cela en caveats sur une délégation ERC-7710 | | UX d'approbation | Un humain approuve chaque transaction (ou aucune) | L'utilisateur signe une fois, par signature de délégation ou une demande de permission ERC-7715 dans MetaMask | | Mode d'échec | Un seul mauvais prompt ou plugin compromis vide le portefeuille | Tout ce qui dépasse les limites est rejeté au niveau du contrat | | Révocation de l'accès | Rotation des clés et espoir | La révocation onchain prend effet immédiatement ; les délégations expirent d'elles-mêmes |

Tout ce qu'un utilisateur peut exprimer en langage naturel se compile en un caveat spécifique. Les limites de dépenses périodiques (« 200 $ par jour ») deviennent des enforcers de transfert périodique natifs ou ERC-20. Les plafonds stricts par transaction deviennent des enforcers de limite de valeur. Les allowances ERC-20 deviennent l'enforcer de montant de transfert ERC-20. Les limites de débit (« 10 appels par heure ») deviennent conjointement des enforcers d'appels limités et d'horodatage. Les listes blanches de contrats et de méthodes deviennent des enforcers de cibles autorisées et de méthodes autorisées. Chaque délégation porte une expiration via l'enforcer d'horodatage.

Clawnch propose également des profils d'autonomie graduée. « Supervisé » n'accorde aucune délégation — chaque action est envoyée au téléphone de l'utilisateur. « Entraînement » est plafonné à 50 $ par transaction, 200 $ par jour, et 10 appels par jour avec une expiration de 24 heures. « Autonome » élargit cela à 500 $ par transaction et 2 000 $ par semaine sur 30 jours. Un quatrième profil, « personnalisé », permet aux utilisateurs de définir leurs propres limites. Les agents peuvent également sous-déléguer : une délégation chaînée plus restrictive à un sous-agent spécialisé, prouvée onchain sous forme de chaînes de rédemption à deux sauts. Le compilateur refuse de construire une délégation sans restriction à moins que l'utilisateur n'y consente explicitement.

Livré deux fois : même standard, deux langages

La première intégration de délégation, dans le client TypeScript d'OpenClawnch, a pris trois jours depuis la première ligne de code de délégation jusqu'à un flux complet de bout en bout prouvé sur Base Sepolia : compiler une politique, la signer, la redemander, exécuter depuis le smart account de l'utilisateur. La mise en bêta publique a pris environ trois semaines au total.

La partie difficile concernait cinq problèmes d'intégration que les tests unitaires n'auraient jamais pu détecter, tous découverts contre des contrats déployés en production :

• Le typehash de caveat EIP-712 exclut le champ args.

• La sentinelle d'autorité racine est max-bytes32, pas zéro.

• Le DelegationManager appelle executeFromExecutor sur le compte, pas execute.

• L'enforcer ERC-20 attend des termes de 52 octets compactés, pas encodés en ABI.

• Les chaînes de délégation multi-sauts sont ordonnées en partant de la feuille.

L'équipe de Clawnch a découvert plusieurs de ces problèmes en recherchant dans le bytecode déployé des sélecteurs et typehashes candidats. Le SDK officiel gère les cinq en interne, les mêmes adresses de contrats sur toutes les chaînes ont éliminé toute une catégorie de bugs de configuration, et lorsque l'équipe a sollicité l'aide de MetaMask, les conseils reçus étaient précis et corrects.

La deuxième intégration a été la récompense de la première. En portant la couche de délégation en Python pour l'agent Hermes de Nous Research (le client Clawmes), chacune de ces cinq leçons au niveau des contrats s'est transférée directement, et l'équipe a vérifié les encodeurs Python octet par octet par rapport à la sortie du SDK. La première intégration a pris trois semaines. La seconde a pris quelques jours.

Une révocation qui échoue en mode fermé

Clawnch prend en charge à la fois une révocation immédiate et un kill switch par lot : /delegate revoke envoie un disableDelegation onchain depuis le portefeuille de l'utilisateur, et /delegate revoke-all coupe toutes les délégations en une seule fois. Avant chaque rédemption, Clawnch vérifie le mapping des délégations désactivées du DelegationManager, de sorte qu'une révocation effectuée n'importe où, même en dehors du propre produit de Clawnch, prend effet immédiatement. Les délégations limitées dans le temps expirent également d'elles-mêmes via l'enforcer d'horodatage, et comme le mode de repli de Clawnch est l'approbation par téléphone par transaction, couper un agent ne casse jamais le produit ; cela rétrograde simplement l'agent à devoir demander la permission pour chaque action.

Le client Hermes va encore plus loin. Si une délégation couvre une action mais que les caveats refusent la rédemption (parce qu'une limite a été dépassée, que la délégation a expiré ou qu'elle a été révoquée), l'agent ne revient pas à son propre chemin de signature. Le refus est la réponse. Un kill switch absolu, contrôlé par une seule variable d'environnement, peut désactiver entièrement l'exécution par délégation.

La stack

Impact à ce jour

Du côté du launchpad : plus de 10 000 agents uniques ont lancé des tokens lors de la première semaine de la plateforme, le volume de trading a dépassé 190 millions de dollars au cours du premier mois, et les agents avaient gagné plus de 1,2 million de dollars en frais début février (dont 166 000 dollars dans les trois premières heures après le lancement). À la fin du printemps, les tokens lancés avaient dépassé les 140 000.

Du côté de la délégation, l'intégration est désormais livrée dans les deux clients agents. Le client TypeScript est adossé à 34 tests onchain contre les contrats live du Delegation Framework et 166 tests unitaires de délégation au sein d'une suite de plus de 1 600 tests, avec 11 des 32 outils d'écriture routés via la rédemption onchain, couvrant toutes les actions à haut risque : transferts, swaps, bridging, prêts et staking. Le client Python pour l'agent Hermes livre le cycle de vie complet (compilation, signature, rédemption, révocation, requêtes ERC-7715 et mises à niveau EIP-7702) avec une couverture de test à 100 % sur son module de délégation, vérifiée octet par octet par rapport à l'implémentation de référence.

Le mode délégation est désormais le mode par défaut pour les nouvelles installations. Avant lui, l'agent de Clawnch était un assistant qui devait demander la permission pour chaque dollar dépensé ; après, les utilisateurs définissent les limites une fois et des fonctionnalités comme les planifications DCA, le copy-trading et les stratégies multi-étapes sont devenues véritablement autonomes.

La suite

Sur la feuille de route : étendre la couverture de délégation à davantage d'outils d'écriture, l'exécution par lot via le délégateur EIP-7702 pour que les flux multi-étapes comme approve-then-supply s'exécutent dans une seule délégation, l'exécution parallèle limitée par délégation qui maintient les dépenses totales bornées entre stratégies concurrentes, des sous-agents exécutant des stratégies complètes de manière autonome dans des sous-délégations restreintes, et une bibliothèque de modèles de stratégies où chaque modèle déclare le profil de délégation dont il a besoin. Clawmes, le portage Python pour l'agent Hermes, vient de livrer son application de caveats en mode fermé ; la prochaine étape est l'extension de ses extracteurs d'actions et l'exécution de la même suite de preuves onchain développée pour le client TypeScript.

Au-delà, Clawnch surveille les déploiements plus larges d'ERC-7715 et d'Agent Wallet, migre ses chemins restants développés en interne entièrement vers le smart-accounts-kit, étend HybridDeleGator par utilisateur aux utilisateurs de portefeuilles custodials, et développe des caveat enforcers personnalisés pour les permissions spécifiques au launchpad — comme une délégation limitée à « réclamer les frais et les réinvestir, rien d'autre ».

Un agent qui gagne des frais et les dépense dans des limites appliquées par la chaîne est un véritable acteur économique. Un agent avec la clé privée de quelqu'un est une responsabilité avec une interface de chat. Nous voulons que Clawnch soit la couche de coordination où les agents gagnent, et que la délégation MetaMask soit la façon dont on leur fait confiance pour dépenser.

— Clawnchdev, fondateur, Clawnch

Les conseils de Clawnch aux développeurs

Concevez selon le principe du moindre privilège. Les caveats réduisent le pire scénario de « portefeuille vidé » à « l'agent a fait exactement ce qu'il était autorisé à faire, et rien d'autre ». Déterminez la délégation la plus restreinte dont chaque intention utilisateur a besoin, puis émettez celle-là — ne distribuez pas de permissions larges en comptant sur le jugement de l'agent pour rester dans les limites. La confiance accordée à l'agent ne disparaît pas sous délégation ; elle devient précise et définie.

Ne construisez pas votre propre moteur de politique. Les plafonds de dépenses, les listes blanches et les limites de débit existent déjà sous forme de caveat enforcers audités onchain ; les réimplémenter dans le code applicatif ne fait que déplacer le risque sans le supprimer.

Attendez-vous à ce que la première intégration soit la plus difficile. Les leçons qui comptent (particularités des typehashes, valeurs sentinelles, le bon point d'entrée d'exécution, les formats d'encodage, les règles d'ordonnancement pour les chaînes de délégation) se trouvent au niveau du contrat, pas dans la documentation d'un SDK. Apprenez-les une fois, et elles se transfèrent directement au prochain langage ou client.

Construisez avec le Delegation Framework : smart accounts (EOAs mis à niveau EIP-7702 ou comptes délégateurs dédiés), délégations ERC-7710 et Advanced Permissions ERC-7715. La stack que livre Clawnch est disponible pour tous les développeurs.

Pour en savoir encore plus, consultez :

• Documentation MetaMask Smart Accounts Kit : https://docs.metamask.io/smart-accounts-kit

• Clawnch : https://www.clawn.ch/

• OpenClawnch (GitHub) : https://github.com/clawnchdev/openclawnch

• Clawmes (GitHub) : https://github.com/clawnchdev/clawmes