diff --git a/app/[locale]/[...slug]/page-jsonld.tsx b/app/[locale]/[...slug]/page-jsonld.tsx index c7b238b26d7..b0ab21a4e38 100644 --- a/app/[locale]/[...slug]/page-jsonld.tsx +++ b/app/[locale]/[...slug]/page-jsonld.tsx @@ -1,3 +1,5 @@ +import { getTranslations } from "next-intl/server" + import { FileContributor, Frontmatter } from "@/lib/types" import PageJsonLD from "@/components/PageJsonLD" @@ -19,28 +21,34 @@ export default async function SlugJsonLD({ frontmatter: Frontmatter contributors: FileContributor[] }) { + const t = await getTranslations("common") + const url = normalizeUrlForJsonLd(locale, `/${slug}`) - // Generate breadcrumb items for the slug path + // Breadcrumb labels are sourced from `common.json` (same keys the UI + // Breadcrumbs component uses), falling back to a title-cased slug fragment + // when no translation exists. This keeps JSON-LD localized and avoids + // hand-maintained acronym overrides (e.g. "ai-agents" -> "AI agents"). const breadcrumbItems = [ { "@type": "ListItem", position: 1, - name: "Home", + name: t.has("home") ? t("home") : "Home", item: normalizeUrlForJsonLd(locale, "/"), }, ] - // Add breadcrumb items for each part of the slug path const slugParts = slug.split("/").filter(Boolean) let currentPath = "" slugParts.forEach((part, index) => { currentPath += "/" + part + const defaultName = + part.charAt(0).toUpperCase() + part.slice(1).replace(/-/g, " ") breadcrumbItems.push({ "@type": "ListItem", position: index + 2, - name: part.charAt(0).toUpperCase() + part.slice(1).replace(/-/g, " "), + name: t.has(part) ? t(part) : defaultName, item: normalizeUrlForJsonLd(locale, currentPath), }) }) diff --git a/app/[locale]/use-cases/page.tsx b/app/[locale]/use-cases/page.tsx index a2a15f2c161..1d98f4f9e8e 100644 --- a/app/[locale]/use-cases/page.tsx +++ b/app/[locale]/use-cases/page.tsx @@ -27,7 +27,7 @@ import { getMetadata } from "@/lib/utils/metadata" import UseCasesPageJsonLD from "./page-jsonld" import { ContentLayout } from "@/layouts/ContentLayout" -import aiAgentsHero from "@/public/images/ai-agents/hero-image.png" +import decentralizedAiHero from "@/public/images/ai-agents/hero-image.png" import ethImg from "@/public/images/eth.png" import ethGifCat from "@/public/images/eth-gif-cat.png" import ethereumLearn from "@/public/images/ethereum-learn.png" @@ -199,15 +199,17 @@ export default async function Page(props: { params: Promise }) { - {/* AI agents banner */} + {/* Decentralized AI banner */} - {t("ai-agents-cta")} + + {t("decentralized-ai-cta")} + {/* Digital ownership and gaming */} diff --git a/next.config.js b/next.config.js index 5ab40c4448c..de3cf8bff85 100644 --- a/next.config.js +++ b/next.config.js @@ -1,4 +1,3 @@ -/* eslint-disable @typescript-eslint/no-var-requires */ const { PHASE_DEVELOPMENT_SERVER } = require("next/constants") const createNextIntlPlugin = require("next-intl/plugin") diff --git a/public/content/ai-agents/ethereum/index.md b/public/content/ai-agents/ethereum/index.md new file mode 100644 index 00000000000..89651b4f23f --- /dev/null +++ b/public/content/ai-agents/ethereum/index.md @@ -0,0 +1,103 @@ +--- +title: Why Ethereum for AI agents +description: "Why Ethereum is used as the settlement and coordination layer for AI agents: onchain ownership, verifiable execution, programmable guardrails, and permissionless payments" +lang: en +template: ai-agents +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: Why Ethereum for AI agents +summaryPoints: + - "Mature smart accounts and onchain agent identity" + - "Programmable guardrails and session keys for bounded autonomy" + - "Permissionless access to DeFi, payments, and identity" +--- + +AI agents operate across many platforms and networks. This page covers what builders need to understand about building on [Ethereum](/): the specific **technical capabilities** the network provides for autonomous agents, and the **architectural tradeoffs** to weigh before committing to that stack. + +**Not every agent deployment belongs on a blockchain like Ethereum.** Agents that are purely read-only, that operate entirely offchain, or that can accept a trusted operator model **may not require the overhead of onchain settlement**. + +However, when an agent requires **trustless coordination**, the capabilities below allow agents to **control non-custodial assets, verify their own execution, and interoperate permissionlessly** with open protocols. The capabilities that Ethereum's agent standards provide **replace the need for a trusted operator with code that counterparties can independently verify**. + +## Onchain ownership {#onchain-ownership} + +An [AI agent's wallet](/ai-agents/wallets/) and its digital assets exist independently on Ethereum. **No unauthorized third party, operator, platform, or cloud provider can unilaterally revoke or freeze them**, because **ownership is enforced by the network itself** rather than by a company's terms of service. + +The wallet's controller (whoever holds the keys or owns the smart contract account) retains full authority over those assets. Constraining what the agent itself can spend is a separate concern (covered in the [Programmable guardrails](#programmable-guardrails) section below). + +Assets an agent earns, receives as payment, or accumulates during operation are **governed by smart contract code that both the agent's developer and its counterparties can read and verify**. Rules about what the agent can spend and where are **not a policy document on Ethereum; they are executable code** deployed to a network that no single entity operates. + +Network-enforced ownership is consequential for [agent deployments](/ai-agents/use-cases/). An autonomous agent integrated into a centralized platform is **only as stable as that platform's continued support and goodwill**. An agent whose treasury and rules live onchain **retains those properties regardless of the agent operator's status**. + +## Verifiable execution {#verifiable-execution} + +An AI agent running offchain is, **by default, opaque**. Users and counterparties have **no way to confirm that the model producing the agent's outputs is the model it claims to be, or that it ran without tampering**. When an agent takes a consequential action, the only evidence it provides is its own assertion. + +Ethereum provides two technical paths for making agent behavior verifiable. **Zero-knowledge machine learning (zkML)** generates a cryptographic proof that a specific model produced a specific output, which a smart contract can verify onchain before acting on the result. **Trusted Execution Environments (TEEs)** run agent logic inside hardware-isolated enclaves and produce attestations that the code executed without tampering. Both approaches allow smart contracts to **verify evidence of correct behavior before releasing funds or executing other consequential actions**. + +Each path carries different tradeoffs in latency, trust assumptions, and model size constraints. See [AI agents: Verification](/ai-agents/verification/) for tool comparisons, maturity guidance, and implementation details. + +## Programmable guardrails {#programmable-guardrails} + +A fundamental risk in deploying autonomous agents is that they hold signing authority over funds. **Giving an agent an unconstrained private key is equivalent to giving it unlimited spending authority**; a **hallucination, a prompt injection, or a logic error** can drain an account. + +Ethereum's [account abstraction](/roadmap/account-abstraction/) standards (primarily [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) and [EIP-7702](/roadmap/pectra/7702/), live on Ethereum Mainnet since the Pectra upgrade, May 2025) allow developers to **replace raw private key control with programmable smart contract wallets**. These wallets enforce spending limits, contract allowlists, and time-bounded **session keys** at the contract level, so a compromised credential cannot drain the account beyond its scoped policy. + +For a full comparison of ERC-4337 vs. EIP-7702, session key policy design, SDK implementation examples, and production key management patterns, see the [AI agents: Wallets](/ai-agents/wallets/) page. + +## Agent identity and reputation {#agent-identity} + +When an agent interacts with a user or with another agent, the counterparty needs a way to **verify what the agent is and what authority it holds**. Centralized identity registries address this by **requiring trust in the registry operator**. Onchain identity standards address it by making registrations **publicly verifiable and censorship-resistant**. + +**[The Trustless Agents Standard, ERC-8004](https://eips.ethereum.org/EIPS/eip-8004)** is live on Ethereum Mainnet and 20+ chains since January 29, 2026. It provides **onchain registries for agent discovery, reputation tracking, and output validation**, forming the trust layer that allows agents to participate in complex multi-agent workflows without relying on a centralized directory operator. + +For the full registry architecture, contract addresses, ecosystem status, and registration walkthrough, see [AI agents: Identity](/ai-agents/identity/). + +## Open composability {#open-composability} + +Because Ethereum's protocol layer is permissionless, **an agent can interact with any deployed smart contract**, including decentralized exchanges, lending protocols, prediction markets, data markets, and governance contracts, **without requesting access from the protocol operator**. + +Permissionless access to any deployed smart contract means an agent can execute a **complex workflow in a single atomic transaction**: approve a token transfer, execute a swap on a decentralized exchange, deposit the output to a yield protocol, and record the result to an attestation registry. **If any step fails, the entire transaction reverts**. This atomicity property is **not available through standard application programming interfaces (APIs) between centralized services**. + +Composability also means that **agent logic can build on existing audited infrastructure rather than re-implementing it**. **Security properties inherited from established Ethereum protocols carry over to the agent's operations**. + + + +## Scalable payments {#scalable-payments} + +Autonomous agents need to pay for compute resources, data feeds, and other agent services without human intervention. Standard financial rails require corporate entities and bank accounts. These are barriers that autonomous code cannot cross. + +Ethereum provides a **native, permissionless financial rail for machines**. Agents can hold and spend stablecoins without a bank account, and open protocols like **[x402](https://www.x402.org/)** give any API endpoint a machine-readable way to request and receive payment in a single HTTP exchange. Combined with low-cost [Layer 2](/ai-agents/l2s/) settlement, these primitives enable agents to **independently acquire compute, pay for data, and monetize their own outputs**. + +For the full x402 payment flow, stablecoin rail selection, integration code, and alternative payment models, see [AI agents: Payments](/ai-agents/payments/). + +## The L2 ecosystem {#the-l2-ecosystem} + +Ethereum Mainnet provides the **canonical security and settlement layer**. [Layer 2 networks](/ai-agents/l2s/) extend it by offering **specialized execution environments** with lower fees, faster finality, and capabilities like TEE-based transaction ordering and concentrated agent tooling ecosystems. Because all L2s ultimately settle to Mainnet, an agent's assets and identity remain **anchored to Ethereum's security guarantees** regardless of which L2 it operates on. + +See [AI agents: Layer 2s](/ai-agents/l2s/) for an evaluation framework, workload-type guidance, and deployment notes by rollup type. + + + +## Frequently asked questions {#faq} + + + +Centralized APIs require accounts, API keys, rate limits set by the provider, and trust that the provider will not change terms, throttle access, or shut down. Ethereum provides a global, permissionless API that any agent can call without registration. The same DeFi protocols, payment infrastructure, and identity registries are accessible to any address (human or machine) without gatekeeping. + + + + + +Three capabilities in combination: the deepest ecosystem of production smart contracts (most DeFi, most stablecoins, most tooling), the most mature smart account infrastructure (ERC-4337 with production EntryPoint deployments on all major networks, EIP-7702 live since May 2025), and a production-deployed onchain agent identity standard (ERC-8004, live January 29, 2026 — Draft status, in active adoption). Evaluate whether your agent requires all three before choosing a settlement layer. + + + +## Further reading {#further-reading} + +- [The promise and challenges of crypto + AI applications](https://vitalik.eth.limo/general/2024/01/30/cryptoai.html) — Vitalik Buterin +- [Autonomous agents on blockchains: standards, execution models, and trust boundaries](https://arxiv.org/abs/2601.04583) — arXiv +- [5 Ways Blockchains Help AI Agents](https://a16zcrypto.com/posts/article/5-ways-blockchains-help-ai-agents/) — a16z +- [Account abstraction (ERC-4337)](https://ethereum.org/en/roadmap/account-abstraction/) — ethereum.org +- [EIP-7702: Smart account delegation for existing wallets](https://ethereum.org/en/roadmap/pectra/7702/) — ethereum.org +- [ERC-8004: Trustless agent identity standard](https://eips.ethereum.org/EIPS/eip-8004) — Ethereum Improvement Proposals +- [x402: Machine-to-machine payment protocol](https://docs.x402.org/) diff --git a/public/content/ai-agents/frameworks/index.md b/public/content/ai-agents/frameworks/index.md new file mode 100644 index 00000000000..70bad1b58e0 --- /dev/null +++ b/public/content/ai-agents/frameworks/index.md @@ -0,0 +1,277 @@ +--- +title: AI agent frameworks +description: A directory of agent frameworks with Ethereum integration, including GOAT, ElizaOS, Rig, Olas, GAME, and LangChain, with a decision guide for choosing between them +lang: en +template: ai-agents +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: AI agent frameworks on Ethereum +summaryPoints: + - "Choose by language, protocol coverage, and deployment target" + - "GOAT, ElizaOS, Rig, Olas, GAME, and LangChain compared" + - "Code samples for each framework's Ethereum integration" +--- + +An agent framework handles three responsibilities: **the language model interface, tool orchestration, and the reasoning loop** that drives your agent between steps. The framework you choose shapes which wallet SDK integrates most naturally, what deployment patterns are available to you, and how your agent manages state across calls. + +This page covers a selection of commonly-used frameworks with active Ethereum integration, with a decision guide and integration notes for each. + +## Framework directory {#framework-directory} + +| Framework | Language | Ethereum support | Best for | +| :---------------------------------------------- | :------------------- | :----------------------------------------- | :--------------------------------------------------------------------------------------------- | +| **[GOAT](https://ohmygoat.dev/)** | TypeScript | Native — 200+ protocol plugins | Production EVM agents, DeFi automation | +| **[ElizaOS](https://elizaos.ai/)** | TypeScript | Plugin-based (EVM plugin, v2+) | Multi-platform social agents | +| **[Rig](https://rig.rs/)** | Rust | Via alloy / ethers-rs crates | High-performance, latency-sensitive agents | +| **[Olas](https://olas.network/)** | Python | Native — Pearl app store, onchain registry | Autonomous services with onchain coordination | +| **[GAME](https://docs.game.virtuals.io/)** | TypeScript / no-code | ACP v2.0 hook contracts (Base Mainnet) | Autonomous game agents, Virtuals ecosystem — ecosystem-specific, not general-purpose EVM | +| **[LangChain](https://python.langchain.com/)** | Python / TypeScript | Via GOAT's LangChain adapter or Web3 tools | General-purpose agents, largest community — use GOAT alongside LangChain for EVM tool coverage | + + + + +Maturity note + + +This ecosystem evolves quickly. Package names, API surfaces, and EVM plugin versions can change between minor releases. Always verify integration patterns against each framework's official documentation before building. + + + + +## Which framework should I choose? {#choosing-a-framework} + +| If you need... | Use | +| :----------------------------------------------------------------------------------------- | :------------ | +| Maximum EVM protocol coverage, 200+ pre-built plugins | **GOAT** | +| Multi-chain social agent (Discord, Twitter, Telegram) | **ElizaOS** | +| Rust runtime, type safety, or latency under 100ms | **Rig** | +| Autonomous agent services with onchain coordination | **Olas** | +| No-code or game-native deployment within the Virtuals ecosystem | **GAME** | +| Python ecosystem and widest LLM/tool community. Pair with GOAT's LangChain adapter for EVM | **LangChain** | + +The examples on this page use **GOAT** because it provides 200+ pre-built EVM protocol plugins, is directly compatible with the Vercel AI SDK, and publishes native adapters for LangChain and LlamaIndex, making it a practical starting point for both TypeScript and Python-based pipelines. + +Any of the frameworks above will work; choose based on your language and deployment requirements. Before connecting any of them to a wallet, consider how your agent system will distribute signing authority across agents. The patterns in the next section cover this for most production deployments. + +## Multi-agent orchestration patterns {#orchestration-patterns} + +The three patterns below cover most production multi-agent deployments. + +### Coordinator and specialists {#coordinator-specialists} + +The most common pattern for complex workflows: + +``` +CoordinatorAgent +├── ResearchAgent (read-only, no keys) +├── AnalysisAgent (computation, no keys) +└── ExecutorAgent (holds session key, HITL approval above threshold) +``` + +In this pattern, **only the Executor holds signing authority**. Stateless specialists can be restarted or replaced without key rotation. For how to implement the human-in-the-loop (HITL) escalation logic, including the `onStepFinish` hook and durable pause patterns. See [Human-in-the-loop escalation](/ai-agents/wallets/#hitl) in the agent wallets guide. + +### Shared-state coordination (onchain) {#shared-state-onchain} + +A traditional shared database requires a trusted central coordinator, a single operator all agents agree to rely on. When agents are operated by different parties, or when no single operator should have privileged write access, a smart contract provides neutral shared state instead. + +All agents read from and write to the same onchain state, eliminating race conditions and producing a tamper-proof audit trail any party can verify. Use this pattern when multiple independent agents must coordinate over a shared resource and you need a canonical, censorship-resistant record that no single operator controls. + +### Event-driven pipeline {#event-driven-pipeline} + +Use this pattern when your agent system needs to react to onchain signals, like new blocks, price movements, or governance proposals, rather than run on a fixed schedule. Agents are chained in a linear sequence, each responsible for a single stage, so the signing authority stays contained in a single Executor at the end of the pipeline. + +``` +TriggerAgent → watches events or prices + ↓ +QueueAgent → manages task queue + ↓ +ExecutorAgent → executes within rate limits and session key policy + ↓ +AuditAgent → verifies and logs result +``` + +## GOAT with the Vercel AI SDK {#goat-vercel-ai} + +GOAT is the recommended starting point for production EVM agent deployments. It provides 200+ pre-built protocol plugins and is directly compatible with the Vercel AI SDK. + +**Best for:** Production EVM agents that need broad DeFi protocol coverage out of the box, or TypeScript and Python teams that want a single framework compatible with the Vercel AI SDK, LangChain, and LlamaIndex. + + + + +Package names + + +GOAT adapter package names follow the pattern `@goat-sdk/adapter-[ai-sdk-name]`. Verify current package names against the [GOAT repository](https://github.com/goat-sdk/goat) before installing. + + + + +Install the required packages: + +```bash +npm install @goat-sdk/core @goat-sdk/wallet-viem @goat-sdk/plugin-erc20 @goat-sdk/adapter-vercel-ai ai @ai-sdk/openai +``` + +The following example wires GOAT to the Vercel AI SDK. The model receives the onchain tools, and the session key policies in the smart account govern what can actually execute onchain. + +```typescript +import { getOnChainTools } from "@goat-sdk/adapter-vercel-ai" +import { viem } from "@goat-sdk/wallet-viem" +import { erc20, USDC } from "@goat-sdk/plugin-erc20" +import { generateText } from "ai" +import { openai } from "@ai-sdk/openai" + +// Pass your smart account client (kernelClient from the wallets guide) to GOAT. +const tools = await getOnChainTools({ + wallet: viem(kernelClient), + plugins: [erc20({ tokens: [USDC] })], +}) + +// The model decides when and how to call the tools. +// Session key policies in the smart account govern what can actually execute onchain. +const { text } = await generateText({ + model: openai("gpt-4o"), + tools, + maxSteps: 5, + prompt: "Check the USDC balance of my smart account and report the amount.", +}) +``` + +`maxSteps` limits how many tool-call rounds the model may take before returning. Setting a low value on first integration is an important guardrail against runaway reasoning loops. + +Beyond the ERC-20 plugin used in this example, GOAT provides 200+ protocol plugins covering Uniswap, Aave, Curve, Compound, 1inch, and more. See the [GOAT plugin registry](https://github.com/goat-sdk/goat/tree/main/typescript/packages/plugins) for the full list. + +## ElizaOS {#elizaos} + +ElizaOS is a plugin-based framework suited to multi-platform social agents that operate across Discord, Twitter, Telegram, and Farcaster while retaining persistent character and memory. + +**Best for:** Agents that need persistent identity and memory across multiple social platforms while also performing onchain transactions. + +**Ethereum integration:** The [`@elizaos/plugin-evm`](https://github.com/elizaOS/eliza/tree/main/packages/plugin-evm) plugin provides EVM chain support including smart account integration. + +Install the required packages: + +```bash +npm install @elizaos/core @elizaos/plugin-evm +``` + +Register the EVM plugin on your agent instance, passing your smart account client so the plugin can route transactions through it. The following pattern wires a `kernelClient` (from the [wallets guide](/ai-agents/wallets/)) into the ElizaOS agent at initialization. + +```typescript +import { createAgent } from "@elizaos/core" +import { evmPlugin } from "@elizaos/plugin-evm" + +const agent = await createAgent({ + character: myCharacter, + plugins: [ + evmPlugin({ + walletClient: kernelClient, // smart account client from the wallets guide + }), + ], +}) +``` + +Once registered, ElizaOS routes any onchain tool calls through the EVM plugin, which uses your wallet client to sign and submit transactions. See the [ElizaOS documentation](https://docs.elizaos.ai/) for the current character configuration API and plugin lifecycle hooks. + +## Rig {#rig} + +Rig is a Rust-based framework suited to agents where latency and type safety are the primary constraints, like high-frequency trading agents, data pipeline agents, and performance-sensitive deployments. + +**Best for:** Agents with latency constraints below 100ms, or teams that require Rust's ownership model and type safety guarantees for production infrastructure. Note that riglr, Rig's Ethereum extension, is under active development. Verify crate versions before production use. + +**Ethereum integration:** Rig connects to Ethereum through **riglr** (pronounced "riggler"), its blockchain-specific extension. riglr provides the [`riglr-evm-tools`](https://github.com/riglr/riglr) crate, which wraps the [`alloy`](https://github.com/alloy-rs/alloy) library for type-safe transaction construction and signing. + +Add both to your `Cargo.toml`: + +```toml +[dependencies] +rig-core = "0.5" +riglr = "0.1" +alloy = { version = "0.9", features = ["full"] } +tokio = { version = "1", features = ["full"] } +``` + + + + +Verify crate versions + + +riglr is under active development. Confirm current crate names and versions against the [riglr repository](https://github.com/riglr/riglr) before adding them to your project. + + + + +riglr's `#[tool]` procedural macro generates the JSON schema for each tool directly from the Rust function signature and doc-comment, eliminating manual schema boilerplate. The `SignerContext` pattern keeps the wallet signing authority isolated from tool execution logic; the agent code never has direct access to the private key, enforcing key separation at the type system level. + +The following illustrates both patterns. The stub body marks where the real alloy provider call goes; replace it with your actual chain query or transaction logic: + +```rust +#[riglr::tool] +/// Returns the ETH balance of the given address in wei. +async fn get_eth_balance(address: String) -> Result { + // alloy provider call executes within a SignerContext — key never exposed to tool logic + Ok("balance_in_wei".to_string()) +} +``` + +## Olas {#olas} + +Olas provides a framework for autonomous agent services with onchain coordination. Agents are registered in an onchain registry, and the Pearl app store provides a deployment environment for autonomous services. + +**Best for:** Long-running autonomous services that need onchain coordination, particularly in prediction markets, DAO tooling, and data pipelines. Note that Olas is a purpose-built ecosystem, not a general-purpose EVM development framework. + +**Ethereum integration:** Native. Olas agents coordinate through onchain state and hold assets directly. The protocol provides built-in mechanisms for funding, registering, and managing autonomous services. For agents that participate in autonomous economic loops, like discovering services, paying for data, and posting reputation feedback, see [AI agents: Payments](/ai-agents/payments/). + +Install the required packages and scaffold a new service: + +```bash +pip install open-autonomy +autonomy init +``` + +Unlike the SDK-based frameworks above, an Olas service is defined as a finite state machine (FSM) skill across multiple files. The `autonomy init` command scaffolds this structure. See the [Olas documentation](https://docs.autonolas.network/) for the full service development workflow. + +## GAME {#game} + +GAME (Generative Autonomous Multimodal Entities) is a framework by Virtuals Protocol designed for autonomous game agents, interactive non-player characters (NPCs), and tokenized AI entities. It targets consumer entertainment and agent commerce on Base Mainnet rather than general-purpose EVM development. + +**Best for:** Interactive NPCs, tokenized AI agents operating within the Virtuals ecosystem, and no-code agent deployments on Base. GAME is not suited to general Ethereum development. If you need EVM protocol access beyond the Virtuals ecosystem, use GOAT or ElizaOS instead. + +**Ethereum integration:** GAME uses the **Agent Commerce Protocol (ACP) v2.0**, a hook-based architecture where commercial agreements between agents are executed through deployed hook contracts (such as `FundTransferHook`) on Base Mainnet. Agents do not interact with raw EVM transaction APIs. GAME abstracts that complexity through its internal provider layer. Access is available via the managed GAME Cloud interface (no-code) or the open-source SDK for custom integrations. + +Install the required packages: + +```bash +npm install @virtuals-protocol/game +``` + +See the [GAME SDK documentation](https://docs.game.virtuals.io/) for the current API for registering workers (tool-calling agents) and configuring hook contracts within your deployment. + +## Production guardrails {#production-guardrails} + +Before going to Mainnet, every agent needs pre-execution simulation, session key spending limits, and application-layer rate limiting. These guardrails are framework-agnostic and apply to any production deployment. + +[Getting started: Set guardrails](/ai-agents/getting-started/#set-guardrails) + +## Frequently asked questions {#faq} + + + +For maximum EVM protocol coverage (200+ plugins), evaluate **GOAT**. For multi-platform social agents (Discord, Twitter, Telegram), evaluate **ElizaOS**. For Rust and latency-sensitive agents, evaluate **Rig**. For autonomous services with onchain coordination, evaluate **Olas**. For game-native or no-code deployments in the Virtuals ecosystem, evaluate **GAME**. For the widest Python ecosystem and LLM community, evaluate **LangChain** paired with GOAT's LangChain adapter. See the [Frameworks decision guide](#choosing-a-framework) for a full comparison. + + + + + +GOAT is a protocol-first framework: it provides 200+ pre-built EVM protocol plugins (Uniswap, Aave, Compound, and more) and is directly compatible with the Vercel AI SDK. ElizaOS is a character-first framework: it excels at persistent identity and memory across social platforms (Discord, Twitter, Telegram, Farcaster) while also supporting onchain operations through its EVM plugin. Use GOAT when your agent is primarily a DeFi or protocol operator. Use ElizaOS when your agent needs to maintain a social presence. + + + +## Further reading {#further-reading} + +- [GOAT quickstarts](https://github.com/goat-sdk/goat/tree/main/typescript/examples) — Full end-to-end examples wiring GOAT to different frameworks and wallet types +- [LangGraph](https://langchain-ai.github.io/langgraph/) — Durable agent state and `interrupt_before` / `interrupt_after` patterns for human-in-the-loop workflows +- [Create an AI agent that can transfer and swap tokens using ElizaOS](https://metamask.io/news/create-an-ai-agent-that-can-transfer-and-swap-tokens-using-elizaos) — MetaMask guide covering how to create an AI agent that can transfer and swap tokens. +- [AI Agent Framework Security: LangChain, LangGraph, CrewAI & More](https://blog.securelayer7.net/ai-agent-frameworks/) — Common vulnerability patterns in agent frameworks, with real-world exploit examples and mitigation strategies for production deployments. diff --git a/public/content/ai-agents/getting-started/index.md b/public/content/ai-agents/getting-started/index.md new file mode 100644 index 00000000000..5f8ab7a5d63 --- /dev/null +++ b/public/content/ai-agents/getting-started/index.md @@ -0,0 +1,330 @@ +--- +title: Getting started with AI agents +description: A developer on-ramp for building AI agents on Ethereum, from wallet creation to framework connection +lang: en +template: ai-agents +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: Getting started with AI agents on Ethereum +summaryPoints: + - "Set up your first agent in four steps" + - "Configure session keys for bounded agent autonomy" + - "Code examples for setup, integration, and guardrails" +--- + +This guide walks through the four steps required to deploy your first autonomous agent on Ethereum: creating a smart account wallet, funding it, connecting an agent framework, and configuring spending guardrails. Each step links to dedicated pages for deeper implementation guidance. + + + +Before going further, it is worth understanding why this stack differs from standard Ethereum development. When a human signs a transaction, they act as a natural safety checkpoint. An autonomous agent does not. + +**Giving an agent an unconstrained private key is equivalent to giving it unlimited spending authority.** A single hallucination, a logic error, or a prompt injection can drain an account. The patterns below are designed to prevent that. + +## Prerequisites {#prerequisites} + +Before you start, have the following ready. + +**A funded development environment.** You need [Node.js (v18+)](https://nodejs.org) and a package manager (npm, yarn, or pnpm). If you are new to Ethereum development, read the resources in [the Developers hub](/developers/) for context and resources about building on the network, and the [AI agents: Why Ethereum](/ai-agents/ethereum/) hub page for the specific capabilities your agent will use. + +**An LLM API key.** Your agent framework needs access to a language model to drive its reasoning loop. The examples on this page use the OpenAI API, but any provider supported by the Vercel AI SDK (Anthropic, Google, Mistral, and others) works the same way. Set your key in your environment before running any code. + +**Infrastructure API keys.** Account abstraction requires a bundler (to relay UserOperations) and optionally a Paymaster (to sponsor gas). [ZeroDev](https://zerodev.app/), [Pimlico](https://www.pimlico.io/), and [Alchemy](https://www.alchemy.com/) all offer free testnet tiers. Create a project and collect your RPC endpoints now. + +Create a `.env` file at the root of your project and populate it before running any of the examples below: + +```bash +# .env +OPENAI_API_KEY=sk-... +ZERODEV_PROJECT_ID=your-project-id +BUNDLER_RPC=https://rpc.zerodev.app/api/v2/bundler/ +PAYMASTER_RPC=https://rpc.zerodev.app/api/v2/paymaster/ +``` + +**A framework decision.** An agent framework handles the language model interface, tool orchestration, and the logic loop that drives your agent. The choice you make here shapes which wallet SDK integrates most naturally. +_See [AI agents: Frameworks](/ai-agents/frameworks/) for a full comparison._ + +Popular options with native Ethereum support include: + +- **[ElizaOS](https://elizaos.ai/)** — Plugin-based, TypeScript, EVM plugin for smart account support. +- **[GOAT](https://ohmygoat.dev/)** — TypeScript, 200+ protocol plugins, compatible with all major EVM wallet SDKs. +- **[Rig](https://rig.rs/)** — Rust, high-performance, suited to agents with latency constraints. +- **[GAME](https://docs.game.virtuals.io/)** — Hook-based agent commerce framework (ACP v2.0) for the Virtuals Protocol ecosystem on Base. Not a general-purpose EVM framework. + +If you are undecided, ElizaOS and GOAT are generally considered the most beginner-friendly for developers coming from a web3 background. + + + + +Warning! + + +Before connecting any third-party plugin or protocol adapter to your agent, review what permissions each tool requests. A malicious or misconfigured plugin can instruct your agent to interact with unintended contracts. Only include plugins from sources you have audited or that are widely reviewed in the ecosystem. + + + + +## Step 1: Create an agent wallet {#create-wallet} + +**Do not give your agent a raw externally owned account (EOA) private key.** + +EOAs have no native concept of spending limits or allowlists. Under account abstraction standards (primarily [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) and [EIP-7702](/roadmap/pectra/7702/)), you can instead deploy a **smart account** that enforces your agent's operational policy at the contract level. Use ERC-4337 when deploying a new agent from scratch (new contract address, maximum flexibility). Use EIP-7702 when upgrading an existing EOA without migrating assets. For a full comparison of both standards, session key policies, and production key management, see [AI agents: Wallets](/ai-agents/wallets/). + +For a new agent deployment, an ERC-4337 smart account is the standard starting point. + +### Deploying a smart account with ZeroDev {#zerodev-setup} + +Deploying a smart account means creating a contract on Ethereum that your agent uses as its signing and spending address. Unlike a standard private key wallet, this contract enforces the policies you configure at the protocol level. This example uses ZeroDev because its Kernel account natively supports composable permission plugins well-suited to agent deployments. For a complete technical reference on smart account options and production key management, see [AI agents: Wallets](/ai-agents/wallets/). + +[ZeroDev](https://zerodev.app/) provides the Kernel smart account, which uses composable permission plugins suited to agent deployments. + +```bash +npm install @zerodev/sdk @zerodev/ecdsa-validator @zerodev/permissions viem +``` + +The key pattern is **owner-agent key separation**: the agent generates a local key pair and sends only its public address to the account owner. The owner configures a [session key](/ai-agents/wallets/#session-keys) (a policy-bounded signing credential) and hands it back to the agent. The agent never sees the master private key. Step 4 shows how to attach policies to the agent's key; the `account`, `agentSigner`, and `publicClient` defined here are referenced there. + +```typescript +import { createKernelAccount, createKernelAccountClient } from "@zerodev/sdk" +import { signerToEcdsaValidator } from "@zerodev/ecdsa-validator" +import { ENTRYPOINT_ADDRESS_V07 } from "permissionless" +import { createPublicClient, http } from "viem" +import { generatePrivateKey, privateKeyToAccount } from "viem/accounts" +import { sepolia } from "viem/chains" + +// Shared public client — used in this step and in Step 4 +export const publicClient = createPublicClient({ + chain: sepolia, + transport: http(process.env.BUNDLER_RPC), +}) + +const ENTRY_POINT_ADDRESS = ENTRYPOINT_ADDRESS_V07 +// This example targets EntryPoint v0.7 — v0.8 and v0.9 are also live. +// Verify the version your SDK and bundler target before production use. + +// Agent generates its own key — the public address goes to the owner +export const agentPrivateKey = generatePrivateKey() +export const agentSigner = privateKeyToAccount(agentPrivateKey) + +// Owner creates the Kernel account with the agent's key as the sudo signer +// In production, the owner's key (not the agent's) controls the sudo validator. +// This simplified example uses the agent key directly for testnet exploration. +export const ecdsaValidator = await signerToEcdsaValidator(publicClient, { + signer: agentSigner, + entryPoint: ENTRY_POINT_ADDRESS, +}) + +export const account = await createKernelAccount(publicClient, { + plugins: { sudo: ecdsaValidator }, + entryPoint: ENTRY_POINT_ADDRESS, +}) + +console.log("Smart account deployed at:", account.address) +``` + +For a complete walkthrough of the production owner/agent key handoff pattern, see [AI agents: Wallets](/ai-agents/wallets/). + +### Alternatives {#wallet-alternatives} + +If your project has different requirements, such as existing multi-signature governance, cross-chain operations, or a preference for hosted compliance guardrails, the following smart account implementations are also production-ready: + +- **Safe (Allowance Module)** — Recommended for DAO treasury delegation. Decouples agent spending from the core multi-signature threshold. +- **Biconomy (Nexus / Smart Sessions)** — Best for agents that must operate across multiple chains with a single authorization payload. +- **Coinbase Agentic Wallets** — Turnkey deployment with built-in compliance checks on the Base network. **Note:** this is a hosted, custodial product—Coinbase infrastructure manages the private key, not your application. It trades self-sovereignty for rapid deployment and regulatory guardrails. + +## Step 2: Fund your wallet {#fund-wallet} + +Your agent's smart account needs ETH to pay for gas and to fulfill any onchain operations it runs. During development and learning, fund a testnet account rather than a Mainnet account. Testnet ETH has no real value, which means experimentation and mistakes carry no financial risk. + +The addresses in this section refer to your **agent's smart account address** (the contract address printed in Step 1), not the owner's externally owned account (EOA). + +### Testnet (recommended starting point) {#testnet-funding} + + + + +Local testing with Anvil/Hardhat + + +If you test your agent against a local blockchain node (like Anvil), be aware that LLMs can discover and use privileged debug methods (for example, `anvil_setBalance`) to "cheat" simulations rather than executing proper contract logic. To prevent this, route your agent's RPC calls through a restrictive proxy (like Veto) that blocks non-standard JSON-RPC methods. See the [AI agents: Wallets](/ai-agents/wallets/) for more on local testing security. + + + + +Sepolia and Holesky closely mirror Mainnet behavior for contract execution purposes and are the standard development environments. (Holesky is the primary staking testnet and has different validator dynamics; for agent use cases that only involve smart contract interactions, this distinction does not matter.) + +Sepolia is the recommended starting network. Use these faucets to fund your smart account address: + +- **[pk910 Sepolia Faucet](https://sepolia-faucet.pk910.de/)** — Community-run, proof-of-work, no account required. +- **[Alchemy Sepolia Faucet](https://www.alchemy.com/faucets/ethereum-sepolia)** — Requires a free Alchemy account. +- **[sepoliafaucet.com](https://sepoliafaucet.com/)** — Requires an Alchemy account; may have rate limits during high demand. +- **[Google Cloud Web3 Faucet](https://cloud.google.com/application/web3/faucet/ethereum/sepolia)** — No account required; most reliable rate limits. + +For Holesky: [holesky-faucet.pk910.de](https://holesky-faucet.pk910.de/) (proof-of-work, takes several minutes) or the [Google Cloud Holesky faucet](https://cloud.google.com/application/web3/faucet/ethereum/holesky). + +Request funds to your **smart account address** (printed by the Step 1 `console.log`), not to the owner's EOA. The smart account is what your agent uses to transact. + +### Gas abstraction with Paymasters {#paymasters} + +Rather than requiring your agent to hold ETH for gas, you can use a **Paymaster**,a contract that sponsors gas fees on behalf of the smart account. This simplifies agent operations significantly: the agent does not need to monitor its ETH balance or manage top-ups. + +For step-by-step guidance on configuring a Paymaster alongside your smart account, including production-key management and testnet setup, see the [AI agents: Wallets](/ai-agents/wallets/#paymasters) page. + +```typescript +import { createZeroDevPaymasterClient } from "@zerodev/sdk" + +const paymasterClient = createZeroDevPaymasterClient({ + chain: sepolia, + transport: http(ZERODEV_RPC), +}) + +const kernelClient = createKernelAccountClient({ + account, + chain: sepolia, + bundlerTransport: http(BUNDLER_RPC), + paymaster: { + getPaymasterData: (userOperation) => + paymasterClient.sponsorUserOperation({ userOperation }), + }, +}) +``` + +A Paymaster is a smart contract that pays gas fees on behalf of your agent's account, removing the need for the agent to maintain an ETH balance for each operation. Paymasters are available on testnets through [ZeroDev](https://zerodev.app/), [Biconomy](https://www.biconomy.io/), and [Pimlico](https://www.pimlico.io/). On Mainnet, gas sponsorship is typically funded by your application budget. On Mainnet, gas sponsorship is funded from your application budget and configured through the same providers. + +### L2 funding for low-cost development {#l2-funding} + +Ethereum [Layer 2 networks](/ai-agents/l2s/) offer transaction fees low enough to support high-frequency agent-to-agent operations. Use them for cost-sensitive workflows. + +To move testnet funds to an L2, use a community bridge such as [Across Protocol](https://across.to) (fastest, lowest fees) or [Hop Protocol](https://hop.exchange). You can also explore the full range of available bridges and L2s through the [Ethereum app explorer](/applications/). + +See [AI agents: Layer 2s](/ai-agents/l2s/) for a breakdown of L2 characteristics by cost profile, privacy options, and ecosystem fit. + +## Step 3: Connect a framework {#connect-framework} + +Once your smart account is deployed and funded, pass it to your agent framework. Every framework exposes Ethereum operations, like balance checks, transfers, and contract calls, as structured tool definitions that the language model can invoke. + +The framework's reasoning loop decides when to call them. Your smart account's session key policies govern what can actually execute onchain. + +Two setup patterns are most common: + +- **Wallet adapter pattern** — used by GOAT and ElizaOS. You wrap your `kernelClient` in a wallet adapter, generate a `tools` object from it, and pass that object directly to the LLM call. +- **Plugin pattern** — used by ElizaOS. Ethereum functionality is registered as a named plugin on the agent instance, and the framework handles tool routing internally. + +### GOAT: recommended starting point {#goat-quickstart} + +[GOAT](https://ohmygoat.dev/) is the recommended framework for EVM agent deployments. It provides 200+ pre-built protocol plugins and is compatible with the Vercel AI SDK. Install and wire it to the `kernelClient` from Step 1: + +GOAT is used in the examples on this page because it requires the least configuration for developers who are new to agent deployments on EVM networks. + +If you have already chosen a different framework, the pattern is the same. See [AI agents: Frameworks](/ai-agents/frameworks/) for setup guides specific to ElizaOS, Rig, and GAME. + +```bash +npm install @goat-sdk/adapter-vercel-ai @goat-sdk/wallet-evm @goat-sdk/wallet-viem @goat-sdk/plugin-erc20 +``` + +```typescript +import { getOnChainTools } from "@goat-sdk/adapter-vercel-ai" +import { sendETH } from "@goat-sdk/wallet-evm" +import { erc20 } from "@goat-sdk/plugin-erc20" +import { viem } from "@goat-sdk/wallet-viem" + +// kernelClient from Step 1 is a viem-compatible wallet client +const tools = await getOnChainTools({ + wallet: viem(kernelClient), + plugins: [ + sendETH(), + erc20({ tokens: [USDC] }), + ], +}) + +// Pass tools to your LLM call +const result = await generateText({ + model: openai("gpt-4o"), + tools, + prompt: "Check my ETH balance and send 0.001 ETH to vitalik.eth", +}) +``` + +The `tools` object exposes every plugin operation as a typed function the language model can invoke. Your session key policy (set in Step 4) governs which of those operations can actually execute onchain. + +For installation, adapter wiring, and working integration guides for ElizaOS, Rig, and GAME, see [AI agents: Frameworks](/ai-agents/frameworks/). + +## Step 4: Set guardrails {#set-guardrails} + +With a connected framework, your agent can sign and submit transactions. Before moving to any production-like environment, configure hard limits on what it is allowed to do. **This step is not optional.** An unconstrained agent with signing authority and no spending policy is a single logic error or prompt injection away from draining its account. + +**Session keys** are the primary mechanism. A session key is a time-bounded, policy-bounded signing credential that authorizes the agent to act within a defined scope without exposing the master private key. + +A well-structured session key policy specifies a maximum spend per transaction, a rolling time-window budget, a contract allowlist, and a validity window. If the key is compromised, the blast radius is limited to those parameters. The smart contract will reject any UserOperation that violates them regardless of what the LLM instructs. + +[ERC-7715](https://eips.ethereum.org/EIPS/eip-7715) formalizes the wallet-level API for requesting these scoped permissions; it is in draft and being adopted by major smart wallet providers. + +**Pre-execution simulation** is required before submitting any `writeContract` call. + +Simulation catches reverts, bad parameters, and policy violations before they cost gas or damage state. An agent that skips simulation is an agent that will eventually drain funds on a failed transaction. + +Always simulate first: + +```typescript +const simulation = await publicClient.simulateContract({ + address: contractAddress, + abi: contractABI, + functionName: "transfer", + args: [recipient, amount], + account: account.address, +}) + +if (!simulation.result) { + throw new Error("Simulation failed — not executing") +} + +// Execute only after simulation success +const hash = await kernelClient.writeContract(simulation.request) +``` + +Together, session key hard limits and application-layer rate limiting form a layered defense: the smart contract rejects policy violations at the protocol level, while your application catches anomalous spend patterns before they reach the contract. + +**Soft rate limiting** adds an application-layer budget on top of session key hard limits: + +```typescript +class AgentRateLimiter { + private hourlySpend = 0 + private readonly hourlyLimit = parseEther("0.1") // 0.1 ETH per hour + + async checkAndRecord(txValue: bigint): Promise { + this.hourlySpend += Number(txValue) + if (this.hourlySpend > Number(this.hourlyLimit)) { + await this.pauseAndAlert("Hourly spend limit reached") + throw new Error("Rate limit exceeded") + } + } + + private async pauseAndAlert(reason: string): Promise { + // Notify human operator and pause the agent + } +} +``` + +**Human-in-the-loop escalation** handles the cases session key policies cannot. Operations directed at unknown addresses, amounts approaching the daily budget ceiling, or any policy change itself should pause execution and require a human decision before submitting. See [AI agents: Wallets — Human-in-the-loop escalation](/ai-agents/wallets/#hitl) for implementation patterns, including framework-specific hooks for the Vercel AI SDK and LangGraph. + +For SDK-level implementation, including full session key code for ZeroDev, Safe, and Biconomy, multi-chain authorization payloads, and production key management patterns, see [AI agents: Wallets](/ai-agents/wallets/). + +At this point you have a smart account deployed on Sepolia, a funded agent address, a framework connected to that account through GOAT, and a session key policy enforcing hard spending limits. That combination, including controlled identity, scoped authority, and a structured reasoning loop, is the minimum foundation for a production-ready autonomous agent on Ethereum. From here, head to [AI agents: Frameworks](/ai-agents/frameworks/) for deeper integration guides, or browse the sections below to explore wallets, verification, payments, and the wider ecosystem. + +## Frequently asked questions {#faq} + + + +Start with four steps: (1) Create a smart account wallet using an SDK like ZeroDev, Safe, or another ERC-4337 compatible provider, (2) fund it with testnet ETH from a Sepolia faucet, (3) connect an agent framework like GOAT or ElizaOS that provides the LLM interface and tool orchestration, and (4) configure session key spending policies as guardrails. The Getting started guide walks through each step with working code. + + + + + +Start on Sepolia testnet. Testnet ETH has no real value, so experimentation carries no financial risk. Move to mainnet only after your session key policies, spending limits, and human-in-the-loop escalation logic are tested and verified. When you do move to mainnet, consider deploying on a [Layer 2](/ai-agents/l2s/) network for lower transaction costs. + + + +## Further reading {#further-reading} + +- [AI Agents in Cryptocurrency: Architecture, Integration, and Best Practices](https://medium.com/@gwrx2005/ai-agents-in-cryptocurrency-architecture-integration-and-best-practices-a107429bf780) - A comprehensive overview of AI agents in cryptocurrency, covering their architecture, integration with blockchain, and best practices. +- [When AI Meets Blockchain: A Guide to Securing the Next Frontier](https://quantstamp.com/blog/when-ai-meets-blockchain-a-guide-to-securing-the-next-frontier) - Exploring the security vulnerabilities introduced by integrating autonomous AI agents into blockchain ecosystems, and outlining mitigation strategies developers can use to safeguard. diff --git a/public/content/ai-agents/identity/index.md b/public/content/ai-agents/identity/index.md new file mode 100644 index 00000000000..569da7ef44d --- /dev/null +++ b/public/content/ai-agents/identity/index.md @@ -0,0 +1,212 @@ +--- +title: Agent identity with ERC-8004 +description: Onchain agent identity, reputation, and validation registries using ERC-8004 on Ethereum, including how agents discover, verify, and trust each other without a centralized directory +lang: en +template: ai-agents +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: Agent identity with ERC-8004 on Ethereum +summaryPoints: + - "ERC-8004 identity registries, live on 20+ chains" + - "Discover and verify agents without a central directory" + - "ERC-8004 identity plus x402 payments enables agent-to-agent commerce" +--- + +When an autonomous agent interacts with another agent or a human counterparty, the counterparty needs to answer three questions: Is this agent who it says it is? What can it do? Has it behaved reliably in the past? + +Centralized identity directories answer these questions by asking all parties to trust the directory operator. That trust assumption is fragile: **the operator can be captured, shut down, or selectively deny access**. + +Onchain identity standards on Ethereum address the same problem by making registrations publicly verifiable and censorship-resistant. Any application can query the registry, and **no single party controls who can register or who gets responses**. + +**ERC-8004** is the Trustless Agents Standard, deployed on Ethereum Mainnet and 20+ chains since January 29, 2026. It provides the identity infrastructure for the emerging agent economy. + + + + +Draft standard in active adoption + + +ERC-8004 carries an official status of _Draft_ on the Ethereum Improvement Proposals site. The contracts are deployed and live in production, but the interface specification may change as the standard progresses toward Final. Until the standard is finalized, pin your integration to a specific contract address and ABI version rather than assuming forward compatibility. Monitor the [Ethereum Magicians discussion thread](https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098) for interface changes. + + + + +## ERC-8004: the three registries {#three-registries} + +ERC-8004 provides three onchain registries, each serving a distinct function in the agent trust stack. + +### Identity Registry {#identity-registry} + +The Identity Registry gives each agent a portable, censorship-resistant identifier tied to an Ethereum address. Registrations are [ERC-721 tokens](/developers/docs/standards/tokens/erc-721/); the agent's identity NFT is owned by its controller and can be transferred, but the identity record itself is permanently associated with the agent's address history. + +Each identity record stores: + +- The agent's declared capabilities and supported task types +- The agent's primary network and contract address +- Links to off-chain documentation, API endpoints, and supporting evidence +- Cross-chain deployment addresses for agents running on multiple networks + +**Identity Registry Mainnet address:** `0x8004A169FB4a3325136EB29fA0ceB6D2e539a432` + +### Reputation Registry {#reputation-registry} + +The Reputation Registry stores structured feedback signals from agents and human users who have interacted with a given agent. Feedback can be revoked by the original submitter, but the revocation is recorded onchain, so the history of a revocation is itself permanent and auditable. + +Applications can query cumulative reputation scores across multiple dimensions (task completion rate, response latency, payment reliability) before deciding to interact with or pay an agent. As of early 2026, the registry holds 20,000+ feedback entries. + +**Reputation Registry Mainnet address:** `0x8004BAa17C55a88189AE136b182e5fdA19dE9b63` + +The Reputation Registry feeds directly into discovery decisions. An agent checking a counterparty's record queries this registry before proceeding to a payment step. + +### Validation Registry {#validation-registry} + +The Validation Registry is designed to cryptographically validate agent behavior by routing verification requests to delegated smart contracts. When deployed, an application will be able to submit a verification request specifying the output to be checked and the verification method. + +The registry will route the request to a registered verifier and record the result onchain, creating an auditable, tamper-resistant trail that lets any counterparty confirm a specific agent output was independently verified at a specific point in time, without having to trust the agent or its operator. + +Unlike the Identity and Reputation registries, which are destination contracts that applications read and write directly, the Validation Registry is designed as a coordination layer. Validator smart contracts will register themselves independently and respond to requests routed through the registry; the verification work will happen in those separate validator contracts, with the result recorded onchain for composability. + +The ERC-8004 contributors and community are actively working on the specification. Three verification approaches are under consideration: + +- **TEE attestations** — outputs verified by trusted execution environments +- **Crypto-economic security** — staking validators independently re-execute the inference and reach consensus +- **zkML** — zero-knowledge proofs of correct model execution + +The Validation Registry is not yet deployed. The interface specification is still being finalized through community discussion, and the contracts will go live once the technical approach reaches broad stakeholder consensus. Monitor the [ERC-8004 Ethereum Magicians thread](https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098) for updates. + +For output verification options that are available today, see [AI agents: Verification](/ai-agents/verification/). + +## Ecosystem status {#ecosystem-status} + +| Metric | Status (early 2026) | +| :------------------------------- | :------------------------------------------------------------------------------------------------------------ | +| **Standard status** | Draft (in active adoption — see maturity note above) | +| **Identity Registry deployed** | January 29, 2026 | +| **Reputation Registry deployed** | January 29, 2026 | +| **Validation Registry** | Not yet deployed — specification in active community discussion | +| **Networks** | Ethereum Mainnet, Base, Arbitrum, Optimism, Polygon, BNB Chain, Celo, Monad, and 12+ others | +| **Same addresses across chains** | Yes — deterministic deployment | +| **Feedback entries** | 20,000+ | +| **Primary network by activity** | Base (73.6% of feedback) | +| **Co-authors** | Marco De Rossi (MetaMask), Davide Crapis (Ethereum Foundation), Jordan Ellis (Google), Erik Reppel (Coinbase) | + +## The protocol stack {#protocol-stack} + +ERC-8004 sits at the identity layer of a broader agent interoperability stack: + +``` +HTTP / A2A (transport) + ↓ +x402 (machine-to-machine payments) + ↓ +ERC-8004 (agent identity and reputation) + ↓ +Ethereum / L2 (settlement and verifiability) +``` + +The full autonomous economic loop: + +``` +1. Agent A discovers Agent B's service (ERC-8004 Identity Registry) +2. Agent A checks Agent B's reputation (ERC-8004 Reputation Registry) +3. Agent A requests Agent B's endpoint → receives HTTP 402 +4. Agent A pays via x402 (ERC-3009 signed USDC authorization) +5. Agent B delivers the service output +6. Agent A posts feedback to the ERC-8004 Reputation Registry +``` + +No central operator is required at any step. Accountability emerges from the reputation layer rather than from trust in a platform. See [AI agents: Payments](/ai-agents/payments/) for the full payment flow that pairs with the identity and reputation layers shown here. + +## Onchain reputation patterns {#reputation-patterns} + +Beyond ERC-8004's built-in reputation registry, two complementary patterns are commonly used for agent trust in production. Both can be used alongside ERC-8004 registrations rather than instead of them. + +### Attestation registries {#attestation-registries} + +The [Ethereum Attestation Service (EAS)](https://attest.sh/) provides a general-purpose onchain attestation framework. Any address can create a schema and issue attestations to any other address. + +For AI agents, common attestation patterns include: + +- **Capability attestations** — a trusted third party attests that a given agent has passed an evaluation for a specific task type. +- **Audit attestations** — a security researcher attests that an agent's code was reviewed and found to meet defined standards. +- **Completion attestations** — a client attests that a specific task was completed to specification. + +EAS attestations are queryable via the EAS GraphQL API and can be verified onchain by any smart contract. Because EAS attestations are issued by named addresses rather than by the agent itself, they provide a trust signal that is independent of the agent's own registration data. + +### Proof-of-personhood {#proof-of-personhood} + +For interactions where distinguishing an agent acting on behalf of a verified human from a fully autonomous agent matters, proof-of-personhood mechanisms provide an additional trust signal. + +These mechanisms do not prove that the agent itself is human (it is not), but that a verified human authorized the agent to act on their behalf. + +**[Proof of Humanity](https://www.proofofhumanity.id/)** provides an alternative social-vouching based approach to humanhood verification, with a focus on DAO membership and universal basic income applications. + +**[Worldcoin / World ID](https://worldcoin.org/world-id)** uses biometric verification (iris scan) to generate a zero-knowledge proof that the credential holder is a unique human, without revealing the individual's identity. An agent acting under World ID delegation can assert that it was authorized by a unique verified human, which can be a meaningful signal for governance participation, content moderation, and other contexts where Sybil resistance matters. + +For agent interactions that gate access based on personhood, combining an ERC-8004 registration with a proof-of-personhood delegation creates a stronger identity claim than either signal alone. + + + +## How to register an agent {#how-to-register} + +ERC-8004 registration uses the same addresses across all supported chains. + +The registration process involves: + +1. **Choose your network** — view all current supported networks [on the 8004 site](https://www.8004.org/build), and all deployed 8004 contracts across chains in the [official 8004 contract repository](https://github.com/erc-8004/erc-8004-contracts). +2. **Call the Identity Registry** — invoke the `register` function with your agent's address, capability declarations, and metadata URI. +3. **Fund the reputation registry** — initial feedback can be submitted by early users or test integrations to establish a starting reputation signal. +4. **Integrate the validation registry** _(optional — not yet deployed)_ — once live, this step applies if your use case requires cryptographic output verification. See the [Validation Registry section above](#validation-registry) for current status. + +For the current contract ABI and registration walkthrough, see the [ERC-8004 specification](https://eips.ethereum.org/EIPS/eip-8004) and the [ERC-8004 developer site](https://www.8004.org). + +The following example reads an agent's registration URI from the Identity Registry. Replace `agentId` with the ERC-721 token ID returned when the agent registered, and substitute `ERC8004_ABI` with the ABI from [www.8004.org](https://www.8004.org). + +```typescript +// Example: read an agent's registration from the Identity Registry +import { createPublicClient, http } from "viem" +import { base } from "viem/chains" + +const client = createPublicClient({ + chain: base, + transport: http("https://mainnet.base.org"), +}) + +const IDENTITY_REGISTRY = "0x8004A169FB4a3325136EB29fA0ceB6D2e539a432" + +// Query a registered agent's registration URI (resolves to the off-chain agent registration file) +const agentURI = await client.readContract({ + address: IDENTITY_REGISTRY, + abi: ERC8004_ABI, // import from https://www.8004.org + functionName: "tokenURI", + args: [agentId], // agentId is the ERC-721 token ID returned at registration +}) +``` + +## Frequently asked questions {#faq} + + + +ERC-8004 is the Trustless Agents Standard, live on Ethereum Mainnet and 20+ chains since January 29, 2026. It provides three onchain registries: an **Identity Registry** (agent discovery), a **Reputation Registry** (onchain feedback signals), and a **Validation Registry** (hooks for cryptographic verification of agent outputs, not yet deployed). The standard uses the same contract addresses across all supported chains via deterministic deployment. + + + + + +No. ERC-8004 carries an official EIP status of **Draft**. The contracts are deployed and live in production on 20+ chains, but the interface specification may change as the standard progresses toward Final. Until it is finalized, **pin your integration to a specific contract address and ABI version** rather than assuming forward compatibility. Monitor the [Ethereum Magicians discussion thread](https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098) for interface changes. + + + +## Further reading {#further-reading} + +- [ERC-8004 Ethereum Magicians thread](https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098) — The active discussion thread where interface changes are proposed and debated. Monitor this for breaking changes before each release. +- [Introduction to ERC-8004: The Trust Layer for AI Agents](https://ai.ethereum.foundation/blog/intro-erc-8004) — Understand what ERC-8004 is, the problem it solves, and how the core registries work together. +- [ERC-8004 best practices](https://github.com/erc-8004/best-practices) — Official guidance repository with dedicated guides for registration and reputation and feedback patterns, plus the draft spec as a reference. +- [The Identity Problem in Agentic Commerce: How ENS Can Enable Trust for AI Agents](https://ens.domains/blog/post/ens-ai-agent-erc8004) — Explainer on the need for AI Agent identity onchain, plus how ENS names can be used alongside ERC-8004 for agent identities. + +**Ecosystem tools** + +- [8004scan](https://8004scan.io/) — Browse registered agents, submit feedback, and view reputation leaderboards. +- [Agentscan](https://agentscan.info/) — Multi-chain ERC-8004 explorer with OASF taxonomy classifications, reputation scores, and onchain activity across 21+ networks. +- [8004agents.ai](https://8004agents.ai/) — Multi-chain agent directory with reputation scores, validation status, and ecosystem news. +- [trust8004](https://www.trust8004.xyz/) — Agent scanner focused on comparing combined identity and reputation trust signals, with endpoint verification, across chains. diff --git a/public/content/ai-agents/index.md b/public/content/ai-agents/index.md index f74a4e0e882..f7cbe0afc16 100644 --- a/public/content/ai-agents/index.md +++ b/public/content/ai-agents/index.md @@ -1,143 +1,144 @@ --- -title: AI agents -metaTitle: AI agents | AI agents on Ethereum -description: An overview of AI agents on Ethereum +title: Build AI agents on Ethereum +metaTitle: AI agent builder hub | ethereum.org +description: A developer hub for building AI agents on Ethereum. Covers wallets, verifiable computation, machine payments, agent identity, and the L2 ecosystem. lang: en -template: use-cases +template: ai-agents sidebarDepth: 2 image: /images/ai-agents/hero-image.png -alt: People gathered at terminal table +alt: Developer working with AI agent architecture on Ethereum summaryPoints: - - "AI that interacts with blockchain and trades independently" - - "Controls onchain wallets and funds" - - "Hires humans or other agents for work" + - "Programmable wallets with spending limits and session keys" + - "Verifiable behavior via zkML proofs and TEE attestations" + - "Machine-to-machine payments using stablecoins and open protocols" buttons: - - content: What are AI agents? - toId: what-are-ai-agents - - content: Explore agents - toId: ai-agents-on-ethereum - isSecondary: false + - content: Getting started + href: /ai-agents/getting-started/ + - content: Browse the hub + toId: ai-agent-builder-hub-sections + isSecondary: true --- -Imagine navigating Ethereum with an AI assistant that studies onchain market trends 24/7, answers questions, and even executes transactions on your behalf. Welcome to the world of AI Agents—intelligent systems designed to simplify your digital life. +AI agents are software programs that observe their environment, make decisions, and take actions, including sending transactions, paying for services, and interacting with smart contracts, without requiring human input on every step. -On Ethereum, we’re seeing innovations of AI agents ranging from virtual influencers and autonomous content creators to real-time market analysis platforms, empowering users by delivering insights, entertainment, and operational efficiency. +Ethereum provides the infrastructure these agents need: programmable wallets that enforce spending limits, verifiable computation that proves an agent followed its rules, open payment rails for machine-to-machine commerce, and a permissionless identity layer that any application can verify. These are **not properties that a centralized server can replicate**, because they depend on a network that no single party controls. -## What are AI agents? {#what-are-ai-agents} +This builder hub is the starting point for developers building production AI agents on Ethereum. -AI agents are software programs that use artificial intelligence to perform tasks or make own decisions. They learn from data, adapt to changes, and handle complex tasks. They operate non-stop and can instantly detect opportunities. + + + +New to AI on Ethereum? + + +If you want to learn how AI and Ethereum work together as a use case, visit the [Decentralized AI](/decentralized-ai/) overview page. + + + + +## AI agents vs AI bots {#ai-agents-vs-bots} -### How AI agents work with blockchains {#how-ai-agents-work-with-blockchains} +| | AI agents | AI bots | +| -------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------- | +| **Decision-making** | Autonomous; adapts to new inputs and conditions | Rule-based; executes fixed, pre-programmed logic | +| **Learning** | Can update behavior from real-time data and feedback | Operates on pre-trained data or hardcoded rules | +| **Onchain identity** | Holds a programmable wallet, can sign and send transactions | Typically reads data; does not hold assets | +| **Composability** | Can discover and interact with any open protocol | Limited to the APIs it was explicitly integrated with | +| **Guardrails** | Enforced by smart contract logic (spending limits, session keys, allowlists) | Enforced by the operator's server configuration | +| **Verification** | Behavior can be proven onchain via zkML or TEE attestations | Behavior is attested only by the operator | -In traditional finance, AI agents often operate in centralized environments with limited data inputs. This hinders their ability to learn or manage assets autonomously. +See [AI agents: Why Ethereum](/ai-agents/ethereum/) to learn more about the technical case for using Ethereum as the settlement and coordination layer for AI agents. -In contrast, Ethereum's decentralized ecosystem offers several key advantages: +## What the AI agent builder hub covers {#what-the-ai-agent-hub-covers} -- Transparent data: Access to real-time blockchain information. -- True asset ownership: Digital assets are fully owned by AI agents. -- Robust onchain functionality: Enables AI Agents to execute transactions, interact with smart contracts, provide liquidity, and collaborate across protocols. +Ethereum provides a unique set of technical foundations for deploying production AI agents. -These factors transform AI agents from simple bots into dynamic, self-improving systems that offer significant value across multiple sectors: +The AI agent builder hub covers each of these core building blocks in depth: - - - + + + + -## Verifiable AI {#verifiable-ai} - -AI agents running offchain often behave like "black boxes"—their reasoning, inputs, and outputs can’t be independently verified. Ethereum changes that. By anchoring agent behavior onchain, developers can build agents that are _trustless_, _transparent_, and _economically autonomous_. The actions of such agents can be audited, constrained, and proven. - -### Verifiable inference {#verifiable-inference} - -AI inference traditionally happens offchain, where execution is cheap but model execution is opaque. On Ethereum, developers can pair agents with verifiable computation using several techniques: - -- [**zkML (zero-knowledge machine learning)**](https://opengradient.medium.com/a-gentle-introduction-to-zkml-8049a0e10a04) lets agents prove that a model was executed correctly without revealing the model or inputs -- [**TEE (trusted execution environment) attestations**](https://en.wikipedia.org/wiki/Trusted_execution_environment) allow hardware-backed proofs that an agent ran a specific model or code path -- **Onchain immutability** ensures these proofs and attestations can be referenced, replayed, and trusted by any contract or agent - -## Payments, and commerce with x402 {#x402} - -The [x402 protocol](https://www.x402.org/), deployed on Ethereum and L2s, gives agents a native way to pay for resources and interact economically without human intervention. Agents can: - -- Pay for compute, data, and API calls using stablecoins -- Request or verify attestations from other agents or services -- Participate in agent-to-agent commerce, buying and selling compute, data, or model outputs - -x402 turns Ethereum into a programmable economic layer for autonomous agents, enabling pay-per-use interactions instead of accounts, subscriptions, or centralized billing. - -### Agentic finance security {#agentic-finance-security} +## AI agent infrastructure today {#ecosystem-today} -Autonomous agents need guardrails. Ethereum provides them at the wallet and contract level: +The standards and protocols that power AI agents on Ethereum have crossed from research into production. -- [Smart accounts (EIP-4337)](https://eips.ethereum.org/EIPS/eip-4337) let developers enforce spending limits, whitelists, session keys, and granular permissions -- Programmed constraints in smart contracts can restrict what an agent is allowed to do -- Inference-based limits (e.g., requiring a zkML proof before executing a high-risk action) add another layer of safety +| Standard or protocol | Status | +| :-------------------------------------------------------- | :-------------------------------------------------------------------------------------------------- | +| **EIP-7702** — Smart account delegation for existing EOAs | Live since the Pectra upgrade, May 2025 | +| **ERC-4337** — Smart account standard | Production EntryPoint deployments on all major networks (v0.7 widely adopted; v0.8, v0.9 also live) | +| **ERC-8004** — Onchain agent identity registry | Draft — in active adoption; live on 20+ chains since January 2026 | +| **x402** — Machine-to-machine HTTP payments | Production-ready since Q1 2026 | +| **L2 transaction cost** | $0.001–$0.003 per operation | -These controls enable the deployment of autonomous agents that are not unbounded. +## AI agent builder hub sections {#ai-agent-builder-hub-sections} -### Onchain registries: ERC-8004 {#erc-8004} +### Start here {#start-here} -[ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) defines onchain registries for agent identity, reputation, and validation. Co-authored by contributors from MetaMask, Ethereum Foundation, Google, and Coinbase, it is deployed on 16 networks including Ethereum mainnet, Base, Polygon, Arbitrum, and others. +- [Why Ethereum](/ai-agents/ethereum/) — The technical case for using Ethereum as the settlement and coordination layer for AI agents. +- [Getting started](/ai-agents/getting-started/) — Fund an agent wallet, pick a framework, and deploy your first autonomous transaction. -It provides: +### Core building blocks {#core-building-blocks} -- An **identity registry** for portable, censorship-resistant agent identifiers -- A **reputation registry** for standardized feedback signals across applications -- A **validation registry** for requesting independent verification (zkML, TEE, staked re-execution) +- [Agent wallets](/ai-agents/wallets/) — Smart accounts, session keys, hardware trust layers, and the patterns for giving an agent safe spending authority. +- [Frameworks](/ai-agents/frameworks/) — A directory of agent frameworks with Ethereum support and guidance on when to use each. +- [Verification](/ai-agents/verification/) — zkML, TEEs, and onchain attestations: how to prove an agent behaved as claimed. +- [Payments](/ai-agents/payments/) — Machine-to-machine micropayments, streaming payments, and stablecoin rails for autonomous agent commerce. +- [Identity](/ai-agents/identity/) — Agent identity standards (ERC-8004), reputation systems, and proof-of-personhood mechanisms. -ERC-8004 makes it easier for agents to discover, verify, and transact with each other in a fully decentralized environment. +### Ecosystem and tooling {#ecosystem-and-tooling} -## AI agents on Ethereum {#ai-agents-on-ethereum} - -We're beginning to explore the full potential of AI agents, and projects are already leveraging the synergy between AI and blockchain—particularly in transparency and monetization. - - - -Luna's first appearance as a podcast guest - - - -## Agent-controlled wallets {#agent-controlled-wallets} - -Agents like Luna or AIXBT control their own onchain wallet ([AIXBT's wallet](https://clusters.xyz/aixbt), [Luna's wallet](https://zapper.xyz/account/0x0d177181e3763b20d47dc3a72dd584368bd8bf43)) enabling them to tip fans and participate in economic activities. - -During Luna's X social campaign #LunaMuralChallenge, Luna selected and rewarded the winners via her Base wallet — marking the first instance of an AI hiring humans for crypto reward. +- [Use cases](/ai-agents/use-cases/) — What agents are doing on Ethereum today: DeFi automation, data markets, governance participation, and more. +- [Layer 2s](/ai-agents/l2s/) — How to choose an L2 for your agent based on cost, throughput, privacy, and ecosystem fit. - -

Good to know

-

AI agents and related tools are still in early development and very experimental—use with caution.

+ +Maturity note + + +AI agent infrastructure on Ethereum ranges from production-ready standards (ERC-4337, stablecoin payments) to actively experimental technology (zkML at scale, agent-to-agent commerce). Each sub-page in this hub flags the maturity level of the patterns it covers. + -## Control your wallet using chat commands {#control-your-wallet-using-chat-commands} - -You can skip the complicated interfaces of DeFi and manage your crypto with simple chat commands. - -This intuitive approach makes transactions faster, easier, and less prone to errors like sending funds to the wrong address or overpaying for fees. - - - -## AI agents vs AI bots {#ai-agents-vs-ai-bots} - -The distinction between AI agents and AI bots can sometimes be confusing, as both perform automated actions based on input. +## Frequently asked questions {#faq} -- AI bots are like automated assistants — They follow specific, pre-programmed instructions to perform routine tasks. -- AI agents are more like intelligent companions — They learn from experience, adapt to new information, and make decisions on their own. + -| | AI agents | AI bots | -| ------------------- | ---------------------------------------------------------------------- | ------------------------------------------- | -| **Interactions** | Complex, adaptable, autonomous | Simple, pre-defined scope, hardcoded | -| **Learning** | Learns continuously, can experiment and adapt to new data in real-time | Operates on pre-trained data or fixed rules | -| **Task completion** | Aims to achieve broader objectives | Focuses on specific tasks only | +An AI agent is an autonomous software program that uses a language model to reason about goals, decide what actions to take, and execute those actions in a loop without requiring human approval for each step. When that agent is connected to Ethereum, it can hold assets, sign transactions, interact with smart contracts, and participate in onchain protocols as a first-class participant. See [AI agents: Why Ethereum](/ai-agents/ethereum/) for the technical case for AI agents, or, to learn the basics of what people can do on Ethereum with AI, see [Decentralized AI](/decentralized-ai/). -## Dive deeper {#dive-deeper} + - + -## You can build your own AI agent {#you-can-build-your-own-ai-agent} +A bot follows fixed rules. Given input X, it always does Y. An AI agent uses a language model to reason about novel situations, form a plan, and take sequences of actions that may differ depending on context. Agents are capable of multi-step reasoning, adapting to unexpected conditions, and handling tasks they were not explicitly programmed for. The trade-off is that agent behavior is less predictable, which is why spending limits and session keys are essential. See the [AI agents: Getting started](/ai-agents/getting-started/) guide. - + diff --git a/public/content/ai-agents/l2s/index.md b/public/content/ai-agents/l2s/index.md new file mode 100644 index 00000000000..f0fe6ba95b5 --- /dev/null +++ b/public/content/ai-agents/l2s/index.md @@ -0,0 +1,137 @@ +--- +title: Layer 2 networks for AI agents +description: Choosing the right Ethereum layer 2 for AI agent workloads, comparing specialized execution environments, ecosystem tooling, finality, and agent infrastructure availability +lang: en +template: ai-agents +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: Layer 2 networks for AI agents on Ethereum +summaryPoints: + - "Evaluate L2s by execution, tooling, finality, and trust" + - "Match agent workload to the right L2 architecture" + - "Same patterns work on optimistic and ZK rollups" +--- + +**Ethereum Mainnet provides the canonical security and settlement layer.** [Layer 2](/layer-2/) networks extend it by offering **specialized execution environments**, such as **[trusted execution environment (TEE)](/ai-agents/verification/#tees)-based transaction ordering**, alternative smart contract languages, and concentrated agent tooling ecosystems, alongside lower fees and faster finality. For many agent workloads, the choice of L2 is driven by the capabilities it provides, not just by cost. + +All Ethereum L2s ultimately settle to Mainnet. An agent's assets, identity, and onchain records remain **anchored to Ethereum's security guarantees** regardless of which L2 it operates on. + +Use the sections below to learn more about choosing an L2 based on your agent's specific workload requirements. + +--- + +## Why L2s for AI agents {#why-l2s} + +**L2s provide capabilities that Mainnet does not.** Each L2 makes different architectural tradeoffs, and those tradeoffs create execution environments suited to specific agent workloads: + +- **Specialized execution environments** — TEE-based transaction ordering eliminates frontrunning. Rust smart contracts enable performance-critical agent logic. ZK rollup guarantees provide cryptographic finality. +- **Ecosystem concentration** — agent infrastructure (like [ERC-8004](/ai-agents/identity/) registrations, [x402](/ai-agents/payment/) integrations, [AgentKit](/ai-agents/build/core-services/) tooling) is concentrated on specific chains, reducing what you need to build from scratch +- **Faster finality** — 1–5 second block times versus Mainnet's 12 seconds allows agents to act on confirmed state more quickly +- **Lower transaction costs** — while Mainnet gas has dropped significantly, L2s generally remain cheaper for high-frequency workloads. An agent executing hundreds of operations per day still benefits from the cost difference at scale. + +The evaluation framework below helps you match those properties to the right L2 for your workload. + +## How to evaluate an L2 for your agent {#how-to-evaluate} + +The Ethereum ecosystem has dozens of L2s, each with different architectural tradeoffs. Rather than comparing a fixed list, **evaluate any L2 against the criteria that matter for your agent's specific workload**. + +[L2Beat](https://l2beat.com/scaling/summary) is a community resource that provides live, independent data on every Ethereum L2, including rollup type, trust assumptions, TVL, transaction costs, and risk analysis. Use it as your primary research tool when evaluating networks. + +You can also browse the full [Ethereum layer 2 networks directory](/layer-2/networks/) to compare L2s by fees, TVL, and technology type. + +### What to look for {#what-to-look-for} + +| Criterion | Why it matters for agents | Where to check | +| :-------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------- | +| **Rollup type** | Optimistic rollups are broadly EVM-compatible and deploy like Mainnet. ZK rollups may require specific compilers and have minor opcode differences. | [L2Beat risk analysis](https://l2beat.com/scaling/risk) | +| **Block time** | Agents acting on confirmed state need fast finality. Block times range from sub-second to several seconds across L2s. | Each L2's documentation | +| **Agent tooling ecosystem** | Some L2s have concentrated communities building agent infrastructure (identity registries, payment protocol integrations, SDKs). Deploying where the tooling exists reduces what you build from scratch. | L2 developer documentation, ecosystem directories | +| **Withdrawal finality** | Optimistic rollups have a challenge window (typically seven days) for withdrawals to Mainnet. ZK rollups reach cryptographic finality faster. This matters for agents that bridge assets frequently. | [L2Beat finality dashboard](https://l2beat.com/scaling/finality) | +| **Trust assumptions** | Each L2 makes different tradeoffs around sequencer centralization, data availability, and upgrade authority. An agent holding significant value should deploy on an L2 whose trust model matches the risk profile. | [L2Beat risk analysis](https://l2beat.com/scaling/risk) | + +## Choosing by workload type {#workload-types} + +### High-frequency agents {#high-frequency} + +Agents executing many small operations, like DeFi automation, data purchases via [x402 machine payments](/ai-agents/payments/), or frequent identity registry reads, need **fast block times**, **mature agent tooling**, and fees that remain viable at scale. + +**What to prioritize:** Look for L2s with sub-2-second block times, active agent SDK communities, and low per-transaction costs. Check whether [agent identity infrastructure (ERC-8004)](/ai-agents/identity/) and payment protocol tooling (x402) are deployed on the network, since integrating with existing registries is significantly easier than bootstrapping your own. + +### Privacy-sensitive agents {#privacy-sensitive} + +Agents handling confidential model inputs, user data, or proprietary strategy require execution environments where **neither the cloud provider nor the node operator can observe the agent's inputs or logic**. + +**TEEs are the primary mechanism.** Some L2s have built TEE properties directly into their sequencer architecture, for example, using TEE-based block ordering to provide MEV-resistant transaction sequencing, where transactions are ordered by time of arrival rather than by gas price. Time-of-arrival ordering eliminates frontrunning at the protocol level. + +For agents that need to keep model weights or strategy private while still proving execution integrity, **hardware-based TEE infrastructure can be combined with any L2** for off-chain private computation with onchain settlement. See [AI agents: Verification](/ai-agents/verification/#tees) for implementation details. + +### Cross-chain agents {#cross-chain} + +Agents that coordinate across multiple protocols or chains need **reliable bridging infrastructure** and, in some cases, cross-chain messaging. + +**Fast bridges** provide near-instant withdrawals from optimistic rollups without the standard 7-day challenge period. When evaluating bridges for agent operations, compare settlement speed, fee structure, and the number of supported chains. + +**Security note:** Use official (canonical) bridges for large amounts. **Fast bridges add trust assumptions in exchange for speed.** Evaluate the specific trust model of any bridge your agent uses programmatically. + +## Deployment notes by rollup type {#deployment-notes} + +### Optimistic rollups {#optimistic-rollups} + +Deploy exactly as you would on Mainnet. **Change only the RPC URL and chain ID**. Smart contracts, tooling, and wallet infrastructure work identically. + +**Common gotchas across optimistic rollups:** + +- Some optimistic rollups return the L1 block number from `block.number`, not the L2 block number. Use `block.timestamp` for time-based logic to avoid unexpected behavior. +- L2s with TEE-based transaction ordering sequence by arrival time, not gas price. On those networks, paying a priority fee above the base fee is wasted. + +### ZK rollups {#zk-rollups} + +ZK rollups may require **specific compiler tooling** and have minor EVM compatibility differences. Before deploying an agent on a ZK rollup: + +- Check whether the L2 requires a custom Solidity compiler (for example, `zksolc`) +- Verify that any opcodes your contracts use are supported — some ZK rollups do not implement `EXTCODECOPY` or have different gas schedules for certain operations +- Note that some ZK rollups have **native account abstraction** built into the protocol, which means standard ERC-4337 patterns may differ slightly. See [AI agents: Wallets](/ai-agents/wallets/) for how these differences affect key management and session key design. + +### Finding RPC endpoints and chain IDs {#rpc-endpoints} + +Each L2 publishes its own RPC endpoints, chain IDs, and block explorer URLs in its official documentation. [Chainlist](https://chainlist.org) provides a searchable directory of all EVM-compatible networks with one-click wallet configuration. + + + +For production agent deployments, use a dedicated RPC provider rather than public endpoints. Public RPCs have rate limits and offer no uptime guarantees. Providers such as Alchemy, Infura, and QuickNode support most major L2s. + + + +## Frequently asked questions {#faq} + + + +Yes. All Ethereum L2s are compatible with standard EVM tooling. An agent that works on Mainnet will work on any Ethereum L2 with only an RPC URL and chain ID change. L2s are the recommended deployment environment for most agents due to lower transaction costs and specialized use case environments. + + + + + +L2s offer specialized execution environments that Mainnet does not provide. Some L2s use TEE-based transaction ordering to eliminate frontrunning. Others support Rust smart contracts alongside Solidity. Many have concentrated agent infrastructure, like identity registries and machine-to-machine payment tooling, that agents can use out of the box. L2s also offer faster block times and lower transaction costs, which matter for agents executing high-frequency workloads. The choice depends on which capabilities your agent needs, not just on cost. + + + + + +The key factors include **transaction cost**, **finality speed**, **ecosystem support** for agent-specific standards, and **rollup type**. Transaction cost determines whether your agent's workload is economically viable. Finality speed affects how quickly an agent can act on confirmed state. Ecosystem support (available SDKs, identity and payment protocol integrations) affects how much you build from scratch. Rollup type, like optimistic versus ZK, affects smart contract compatibility and tooling requirements. + + + + + +Optimistic rollups have a challenge window (typically seven days) before withdrawals to Mainnet are final. For most agent operations that remain within a single L2, this does not affect day-to-day execution: transactions confirm in seconds. It becomes relevant when an agent needs to move assets across chains. ZK rollups reach cryptographic finality faster but may require specific compiler tooling and have minor EVM compatibility differences. Agents that bridge frequently should account for finality delay or use fast bridge protocols that accept the additional trust assumptions that come with speed. + + + +## Further reading {#further-reading} + +- [L2Beat](https://l2beat.com) — Security ratings, TVL, and risk analysis for all L2s; the authoritative reference for comparing rollup trust assumptions before committing to a deployment target. +- [growthepie](https://www.growthepie.com/) — Transaction data and cost explorer for all L2s and Mainnet. +- [Autonomous Agents on Blockchains: Standards, Execution Models, and Trust Boundaries](https://arxiv.org/html/2601.04583v1) — Reviewing current standards, execution models, and trust boundaries in autonomous agent research and development, including L2s for AI agent scaling, L2 selection criteria, security model considerations, and more. +- [Scaling Ethereum](/developers/docs/scaling/) — Technical overview of rollups, sidechains, and data availability solutions that underpin L2 architecture. +- [Layer 2 overview](/layer-2/) — ethereum.org introduction to how Ethereum scaling works, covering optimistic and ZK rollup mechanisms. diff --git a/public/content/ai-agents/payments/index.md b/public/content/ai-agents/payments/index.md new file mode 100644 index 00000000000..0b4c308b910 --- /dev/null +++ b/public/content/ai-agents/payments/index.md @@ -0,0 +1,197 @@ +--- +title: Machine payments with x402 +description: How AI agents pay for compute, data, and API calls using the x402 protocol on Ethereum and layer 2 networks +lang: en +template: ai-agents +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: Machine payments with x402 on Ethereum +summaryPoints: + - "Per-request machine-to-machine payments via HTTP 402" + - "Pay-per-use, with no accounts, subscriptions, or human approval" + - "Production-ready, with adoption across cloud and payments providers" +--- + +**Standard financial infrastructure was designed for humans and corporations.** Bank accounts require legal entities. Payment APIs require API keys tied to user accounts. OAuth tokens require a human to authorize them. An autonomous agent cannot hold a bank account, and requiring human approval for every API call defeats the purpose of autonomy. + +Ethereum provides a native payment rail that autonomous code can use directly. Agents can hold stablecoins without a bank account, and emerging protocols like x402 give any API endpoint a machine-readable way to request and receive payment in a single HTTP exchange. + +--- + +## How x402 works {#how-x402-works} + +The HTTP 402 status code was reserved in the original HTTP/1.0 specification in 1996 with the description "Payment Required." The code existed on paper, but was never put into use. There was no universal micropayment infrastructure that could fulfill it. Early attempts to build one (DigiCash, Millicent, and similar 1990s micropayment systems) required proprietary software and centralized intermediaries, and none achieved adoption. The code sat unused for nearly 30 years. + +Ethereum changes the underlying condition that made 402 impractical. **Stablecoins are programmable money that any server can receive without a bank account or payment processor**, and ERC-3009 makes it possible to authorize a payment with a single cryptographic signature, with no prior approval transaction required. The [x402 standard for internet-native payments](https://www.x402.org/) wires those primitives directly into HTTP: a server can now request payment and an agent can pay in a single exchange, using infrastructure that neither party needs to trust the other to operate. + +**The x402 protocol extends the HTTP 402 ("Payment Required") status code into a complete machine-to-machine payment flow.** The protocol is built by Coinbase and the x402 Foundation and is production-ready as of Q1 2026. + +### The payment flow {#payment-flow} + +``` +1. Agent requests a resource + GET https://api.example.com/data/feeds/latest + +2. Server returns HTTP 402 with payment terms + { + "scheme": "exact", + "network": "eip155:8453", ← Base chain + "maxAmountRequired": "1000", ← 1000 USDC (6 decimals) + "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", ← USDC on Base + "payTo": "0xServer...", + "extra": { "name": "Premium Data Feed", "description": "..." } + } + +3. Agent signs an ERC-3009 payment authorization + USDC natively implements ERC-3009 (transferWithAuthorization), + which allows a signed authorization to be used directly — + no prior approve() transaction required. + +4. Agent retries the request with the payment header + X-PAYMENT: + +5. Server verifies the signature and delivers the resource +``` + +The agent pays for **exactly what it uses, per request**, with no subscription, no account, and no human involvement after initial wallet funding. + +### Why ERC-3009 matters {#eip-3009} + +**[ERC-3009: Transfer With Authorization](https://eips.ethereum.org/EIPS/eip-3009) is the technical primitive that makes x402 practical.** It allows a token transfer to be authorized with a cryptographic signature rather than a separate `approve()` transaction. Stablecoins like USDC implement ERC-3009 natively, which means: + +- No gas cost for an approval step before payment +- Payment authorization and resource access happen in a single round-trip +- The authorization can be scoped to a specific recipient, amount, and validity window, reducing overpayment risk + +## Ecosystem status {#ecosystem-status} + +| Metric | Status (early 2026) | +| :-------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Protocol version** | Production-ready | +| **Enterprise integrations** | Google Cloud, Stripe, Cloudflare | +| **SDKs** | TypeScript (`@x402/fetch`), Python (`x402`), Go (`github.com/coinbase/x402/go`), Java | +| **ERC-8004 integration** | x402 payment receipts can be logged to the ERC-8004 AI agent reputation registry (Learn about ERC-8004 and onchain agent identity on the [AI agents: Identity](/ai-agents/identity/) page) | + +## Integration guide {#integration-guide} + +### Agent-side: paying for a resource {#agent-side} + +The [`@x402/fetch` TypeScript SDK](https://www.npmjs.com/package/@x402/fetch) handles the full payment flow transparently. The example below installs the SDK and demonstrates how an agent signs and pays for a resource in a single call. + +If the server returns a standard 200, the request passes through without payment. If it returns a 402, the SDK parses the payment terms, signs the ERC-3009 authorization, and retries automatically. + +```bash +npm install @x402/fetch viem +``` + +```typescript +import { wrapFetchWithPayment } from "@x402/fetch" +import { privateKeyToAccount } from "viem/accounts" +import { createWalletClient, http } from "viem" +import { base } from "viem/chains" + +// Use your agent's session key or dedicated payment key here. +// Never use the controlling account key for routine payments — use a dedicated session key. +const agentKey = privateKeyToAccount(process.env.AGENT_PAYMENT_KEY as `0x${string}`) +const walletClient = createWalletClient({ + account: agentKey, + chain: base, + transport: http(), +}) + +// wrapFetchWithPayment wraps the standard fetch API. +// If the server returns a 402, it signs and pays automatically. +const x402Fetch = wrapFetchWithPayment(fetch, walletClient) + +const response = await x402Fetch("https://api.example.com/data/feeds/latest") +const data = await response.json() +``` + +### Server-side: accepting payments {#server-side} + +Any API endpoint can accept x402 payments by adding the x402 middleware. The example below protects a single Express route with a 1 USDC fee. Payment signature verification is not handled by the merchant server directly; **the middleware forwards the payment header to a Facilitator** (Coinbase and AltLayer operate public Facilitator nodes; self-hosting is also supported) that verifies the cryptographic signature, executes the onchain settlement, and confirms validity before the middleware releases the resource. + +```typescript +import { withPaymentRequired } from "@x402/express" + +// Protect an Express route with a 1 USDC fee +app.get( + "/data/feeds/latest", + withPaymentRequired({ + amount: "1000000", // 1 USDC (6 decimals) + asset: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC on Base + network: "eip155:8453", + }), + (req, res) => { + res.json({ feed: getLatestFeed() }) + } +) +``` + +See the [x402 documentation](https://docs.x402.org/) for middleware implementations for other frameworks (Fastify, Next.js, Hono). + +## The autonomous economic loop {#autonomous-loop} + +x402 and [ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) together enable a fully autonomous agent-to-agent economy: an agent discovers a service provider via the Identity Registry, checks its reputation, pays via x402, receives the output, and posts feedback, **all without human involvement** after initial wallet funding. The reputation system creates accountability without a central authority: agents that deliver poor outputs accumulate negative feedback signals that other agents can query before deciding to pay. + +For the full protocol stack diagram and step-by-step loop, see [AI agents: Identity — The protocol stack](/ai-agents/identity/#protocol-stack). + + + +Agent deployments do not need to use USDC specifically; it is a straightforward example for this guide. The stablecoin rail selection section below explains which assets are compatible with the x402 flow and why. + +## Stablecoin rail selection {#stablecoin-rail} + +x402 supports any ERC-20 token on EVM chains via two transfer methods, selected automatically based on the token's capabilities: + +- **ERC-3009** (`transferWithAuthorization`) — the preferred path. A single off-chain signature authorizes the transfer with no prior on-chain approval step. USDC implements ERC-3009 natively. +- **Permit2** — the universal fallback for any ERC-20 without ERC-3009 support. Requires a one-time on-chain approval to the Permit2 contract, after which payments are signature-based and gasless. The facilitator sponsors gas for both methods. + +| Stablecoin | Transfer method | Notes | +| :--------- | :-------------- | :------------------------------------------------------ | +| USDC | ERC-3009 | Preferred — single signature, no approval step | +| USDT | Permit2 | One-time on-chain approval required; then gasless | +| DAI | Permit2 | One-time on-chain approval required; then gasless | +| Any ERC-20 | Permit2 | x402 supports any token a facilitator chooses to accept | + + + +For supported tokens, contract addresses, and transfer method requirements per network, see the [x402 network and token support documentation](https://docs.x402.org/core-concepts/network-and-token-support). + + + +## Choosing a payment model {#payment-models} + +x402 is optimized for **discrete, per-request micropayments** — each HTTP call generates an independent on-chain settlement. This works well for permissionless API access, one-off agent tasks, and deployments where agent and server have no prior relationship. + +For agents making high-frequency calls to a single provider — continuous data streams, inference endpoints polled dozens of times per minute, or long-running collaborative tasks — settling every request on-chain becomes inefficient. These workloads suit a session-based model better. + +**Stripe's [Machine Payments Protocol (MPP)](https://stripe.com/payments/mpp)** is the primary production alternative for streaming use cases. MPP establishes an authenticated payment session, aggregates micro-transactions off-chain using Shared Payment Tokens (SPTs), and settles in bulk at session end. It supports stablecoin, fiat, and corporate card rails within the same session, and includes enterprise compliance tooling (fraud controls, tax reporting) built in. + +| | x402 | Stripe MPP | +| :----------------------- | :----------------------------------------------- | :--------------------------------------------- | +| **Settlement** | Per-request, on-chain | Session-based, off-chain aggregation | +| **Best for** | Discrete micropayments, permissionless APIs | High-frequency streaming, long-running tasks | +| **Payment rails** | Any ERC-20 (EVM), SPL (Solana), SEP-41 (Stellar) | Stablecoin, fiat, corporate card | +| **Permissionless** | Yes — no account required | No — requires Stripe account | +| **Compliance** | None built in | Enterprise fraud, tax, and reporting tooling | +| **Onchain transparency** | Every payment settled onchain | Aggregated; onchain only at session settlement | + +For a detailed architectural comparison, see [x402 vs. Stripe MPP: choosing payment infrastructure for AI agents](https://workos.com/blog/x402-vs-stripe-mpp-how-to-choose-payment-infrastructure-for-ai-agents-and-mcp-tools-in-2026). + +--- + +## Frequently asked questions {#faq} + + + +x402 is a machine-to-machine payment protocol built on the HTTP 402 status code. An agent requests a resource, the server returns a 402 with payment terms (stablecoin, amount, address), the agent signs an **'ERC-3009: Transfer With Authorization' payment authorization**, and retries the request with the payment header. The server verifies the signature and delivers the resource. No account, no subscription, no human approval. Production-ready since Q1 2026. + + + +## Further reading {#further-reading} + +- [ERC-3009: Transfer with authorization](https://eips.ethereum.org/EIPS/eip-3009) — Full specification for the signature-based token transfer primitive that makes gasless, single-round-trip payments possible in x402 +- [x402 vs. Stripe MPP: choosing payment infrastructure for AI agents](https://workos.com/blog/x402-vs-stripe-mpp-how-to-choose-payment-infrastructure-for-ai-agents-and-mcp-tools-in-2026) — Architectural comparison of discrete vs. session-based payment models for high-frequency and streaming agent workloads +- [x402 documentation](https://docs.x402.org/) — x402.org +- [Agentic Payments and Crypto’s Emerging Role in the AI Economy](https://www.galaxy.com/insights/research/x402-ai-agents-crypto-payments) — How standards like x402 aim to make AI agents full-fledged economic actors, and the potential to power non-crypto applications. diff --git a/public/content/ai-agents/use-cases/index.md b/public/content/ai-agents/use-cases/index.md new file mode 100644 index 00000000000..0bc3d2a7e4d --- /dev/null +++ b/public/content/ai-agents/use-cases/index.md @@ -0,0 +1,190 @@ +--- +title: AI agent use cases on Ethereum +description: Real applications of autonomous AI agents on Ethereum, including DeFi automation, agent-to-agent commerce, onchain governance, risk management, and more +lang: en +template: ai-agents +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: AI agent use cases on Ethereum +summaryPoints: + - "DeFi automation, prediction markets, and agent-to-agent commerce" + - "Each use case maps to builder hub infrastructure" + - "Live agents trade, deploy tokens, and coordinate onchain" +--- + +The following use cases represent what autonomous AI agents are doing on Ethereum today. **Each is grounded in capabilities covered in depth elsewhere in this builder hub**: programmable wallets, machine payments, onchain identity, and verifiable inference. The links below connect each use case to the infrastructure that makes it possible. + +--- + +## Automated DeFi {#defi-automation} + +DeFi protocols operate 24 hours a day, seven days a week. Human traders cannot. Autonomous agents fill this gap by monitoring positions, executing strategies, and responding to market conditions continuously without requiring human oversight for each action. + +**What agents are doing today:** + +- **Yield optimization** — agents monitor yield rates across lending protocols (Aave, Compound, Morpho) and rebalance positions to maximize returns, moving capital when rate differentials exceed a minimum threshold. +- **Liquidation protection** — agents watch collateralization ratios and automatically top up collateral or partially repay debt when a position approaches the liquidation threshold. +- **Portfolio rebalancing** — agents maintain target asset allocations by executing swaps when drift exceeds defined parameters. + +**Infrastructure required:** [Agent wallets](/ai-agents/wallets/) with session keys scoped to specific protocols, [L2 deployment](/ai-agents/l2s/) for cost-effective high-frequency operations (Base or Arbitrum for deepest DeFi liquidity). + +DeFi automation is the most mature AI agent use case on Ethereum. The infrastructure it depends on, like session keys, ERC-4337 smart accounts, and L2 transaction costs, is production-ready. Prediction markets, covered next, apply these same capabilities to a different use case. + + + +## Prediction markets {#prediction-markets} + +Prediction markets let participants trade on the outcome of real-world events. AI agents are well suited to this domain because they can continuously monitor information sources, update probability estimates, and execute trades faster than human participants. + +**What agents are doing today:** + +- **Market making** — agents provide liquidity on prediction market platforms by quoting bid and ask prices on event outcomes, earning the spread while keeping markets efficient. +- **Information aggregation** — agents ingest data from news feeds, social media sentiment, and onchain signals to update their probability models and trade when they detect mispricing. +- **Automated position management** — agents monitor open positions across multiple markets, hedge correlated risks, and exit positions as new information arrives. + +[Olas](https://olas.network/) operates one of the most active agent networks in this category. Its "Trader" agent type is built for prediction market participation. During the 2024 US election cycle, AI agents were widely reported as active participants on [Polymarket](https://polymarket.com/), serving as both market makers and position-takers. Ethereum-native prediction markets like [Gnosis](https://www.gnosis.io/) provide additional infrastructure for onchain agent participation. + +**Infrastructure required:** [Agent wallets](/ai-agents/wallets/) with session keys scoped to prediction market contracts, [frameworks](/ai-agents/frameworks/) for data ingestion and strategy execution, [L2 deployment](/ai-agents/l2s/) for cost-effective high-frequency trading. + + + +Prediction market agents act on external information to take financial positions. Agent-to-agent commerce, covered next, extends the economic model further: agents hiring and paying other agents for specialized work. + +## Agent-to-agent commerce {#agent-commerce} + +Agents can hire other agents for specialized tasks, paying per output using x402 machine payments. This enables a **division of labor that mirrors human organizational structures, where a coordinator agent delegates specialized subtasks** to specialist agents and aggregates the results. The coordinator discovers providers via the [ERC-8004 Identity Registry](/ai-agents/identity/), checks reputation scores, pays per result via [x402](/ai-agents/payments/), and posts feedback after delivery. **No human is required at any step** once the coordinator's strategy is initialized. See [AI agents: Identity — The protocol stack](/ai-agents/identity/#protocol-stack) for the full step-by-step loop. + + + + +Maturity note + + +**ERC-8004** (agent identity registry) is live on 20+ chains as of January 2026, with 20,000+ feedback entries recorded, primarily on Base. **x402** machine payments reached production-ready status in Q1 2026. However, end-to-end agent-to-agent commerce workflows, where agents autonomously discover, hire, and pay other agents, are still early. Treat the five-step pattern above as an architectural target, not a widely battle-tested production pattern. + + + + +**Infrastructure required:** [Payments (x402)](/ai-agents/payments/) for machine-to-machine settlement, [Identity (ERC-8004)](/ai-agents/identity/) for agent discovery and reputation. + +Autonomous governance participation, covered next, follows a similar coordinator-delegate pattern but replaces specialist agents with onchain voting contracts. + +## Autonomous governance participation {#governance} + +DAO governance requires ongoing attention: reading proposals, evaluating their alignment with stated goals, and casting votes before deadlines. Agents can automate this process by monitoring governance contracts for new proposals and voting according to a programmed strategy. + +**What agents are doing today:** + +- Reading proposal calldata and applying heuristic or model-based evaluation. +- Voting autonomously within a defined strategy (for example, always vote for proposals that reduce protocol fees below a threshold). +- Delegating voting power to agent addresses that operate on behalf of token-holding humans. + + + + +Governance risk + + +Fully autonomous governance agents carry governance risk. A logic error or prompt injection can cause an agent to vote against its owner's intent. Production governance agents typically use human-in-the-loop escalation for high-stakes votes and operate autonomously only for routine, low-impact proposals. + + + + +**Infrastructure required:** [Agent wallets](/ai-agents/wallets/) with session keys scoped to governance contracts, [frameworks](/ai-agents/frameworks/) for proposal parsing and strategy execution. + +Governance agents are primarily reactive, responding to events. Risk management agents, covered next, extend this pattern by running continuously to detect and flag anomalous conditions before they become urgent. + +## Risk management and monitoring {#risk-management} + +Agents are well suited to continuous monitoring tasks that are tedious for humans but straightforward for software: watching for anomalous transaction patterns, detecting scam contracts, and alerting on unusual protocol behavior. + +**What agents are doing today:** + +- **Scam detection** — agents monitor token approval requests and flag interactions with known scam contracts or newly deployed contracts with no verified source code. +- **MEV protection** — agents route transactions through private mempools (Flashbots Protect) or MEV-resistant L2s (Unichain) to avoid sandwich attacks on swaps. +- **Position monitoring** — agents watch protocol health metrics (utilization rates, oracle price deviations) and alert operators when conditions move outside safe parameters. + +**Infrastructure required:** [Frameworks](/ai-agents/frameworks/) for monitoring loops, [L2s](/ai-agents/l2s/) with appropriate finality guarantees for alert latency requirements. + +Monitoring agents act on existing protocol data. The next use case applies a different capability, onchain provenance, to a domain where data authenticity is itself the product: AI-generated creative work. + +## Creative work and onchain provenance {#creative-work} + +AI-generated creative work has a provenance problem: anyone can claim that a specific model produced a specific output. Ethereum provides a public, timestamped, immutable record that allows creators and collectors to verify the origin and authenticity of AI-generated work. + +**Example: Botto** +[Botto](https://botto.com/) is a decentralized autonomous artist. It's an AI system that generates visual art and mints it onchain. The community votes on which outputs to mint, and the agent's creative direction is influenced by onchain feedback. Botto's outputs have sold as NFTs, demonstrating that markets are willing to value AI-generated work when its provenance and production process are publicly verifiable. + + + + +Maturity note + + +Onchain provenance for AI-generated creative work is still an emerging practice. Standards for linking model outputs to a specific agent identity and generation parameters are not yet finalized. Botto represents one working implementation. Broader tooling and conventions for this pattern are actively developing. + + + + +**Broader pattern:** Artists and builders are using Ethereum to anchor AI-generated content to a specific model, timestamp, and generation parameters, creating a verifiable chain of custody for work that would otherwise be trivially forgeable. + +**Infrastructure required:** [Verification](/ai-agents/verification/) for provenance proofs, [Agent identity (ERC-8004)](/ai-agents/identity/) for linking outputs to a verifiable agent identity. + +Provenance depends on being able to verify which agent produced a given output. The identity and reputation layer that makes that possible is covered in the final use case below. + +## Agent identity verification {#identity-verification} + +When agents interact with each other or with humans, counterparties need to verify what an agent is and whether it can be trusted. Without an identity layer, any agent can claim any capability. + +**What ERC-8004 enables today:** + +- Agent A looks up Agent B's declared capabilities in the ERC-8004 Identity Registry before deciding whether to hire it. +- Agent A checks Agent B's Reputation Registry entry for prior task-completion signals. +- Smart contracts condition payments or access on whether a calling agent holds a valid ERC-8004 registration. + +The ERC-8004 identity and reputation layer is still early, with 20,000+ feedback entries as of early 2026, but it provides the foundation for agent interactions that do not require trusting a centralized directory operator. + +**Infrastructure required:** [Identity (ERC-8004)](/ai-agents/identity/), [Payments (x402)](/ai-agents/payments/). + +Builders starting today should read the [AI agents: Identity](/ai-agents/identity/) page for interim integration guidance while ERC-8004 adoption continues to develop across chains. + +## Real-world examples {#real-world-examples} + +The use cases above are grounded in agents that are already operating on Ethereum today. Three examples illustrate what this looks like in practice. + +### Luna {#luna} + +[Luna](https://app.virtuals.io/virtuals/68) is a fully autonomous virtual artist and one of the first AI agents to own and manage an onchain wallet. Running on Base, Luna accumulated over one million TikTok followers, performed live at music festivals, and ran an autonomous social campaign (the #LunaMuralChallenge), where she commissioned a human artist for 500 USD, paid directly from her onchain wallet. This was among the first documented cases of an AI agent hiring and paying a human autonomously. + +Luna's wallet and the reasoning behind each transaction are publicly verifiable onchain, a direct demonstration of the identity and provenance properties covered earlier on this page. + + + +### AIXBT {#aixbt} + +[AIXBT](https://x.com/aixbt_agent) is an autonomous market intelligence agent operating on X (formerly Twitter). It delivers crypto market analysis, identifies sentiment shifts, and generates commentary without human input on each post. AIXBT controls its own onchain wallet, verifiable at [clusters.xyz/aixbt](https://clusters.xyz/aixbt), and demonstrates that an agent can build a large public following and operate an independent economic identity entirely onchain. + +### Clanker {#clanker} + +[Clanker](https://farcaster.xyz/clanker) is an autonomous agent on Farcaster that creates ERC-20 tokens on request. Tag the agent in a Farcaster cast and Clanker autonomously deploys a new token contract, names it, and configures it, all without human intervention. Clanker illustrates the programmatic use case: an AI agent operating as a permissionless, on-demand protocol service rather than a social or financial actor. + +## Frequently asked questions {#faq} + + + +DeFi automation is the most mature use case. The infrastructure it depends on, including **ERC-4337 smart accounts, session keys, and low-cost Layer 2 transactions**, is production-ready today. Agent-to-agent commerce and autonomous governance are earlier in their maturity curves; builders should evaluate the maturity notes on each use case before committing to a production deployment. + + + + + +Evaluate the infrastructure each use case requires. **DeFi automation** needs [wallets and session keys](/ai-agents/wallets/) (production-ready). **Agent-to-agent commerce** adds [payments](/ai-agents/payments/) (x402, production-ready) and [identity](/ai-agents/identity/) (ERC-8004, live but Draft status). **Autonomous governance** adds human-in-the-loop escalation for high-stakes votes. Start with the use case whose infrastructure dependencies are closest to production-ready for your deployment timeline, and use the [Getting started guide](/ai-agents/getting-started/) to build your first agent. + + + +## Further reading {#further-reading} + +- [Cookie.fun](https://cookie.fun/) — An onchain AI agent tracker that surfaces activity, mindshare, and engagement metrics across the agent ecosystem. +- [The Block - Research: AI Agent Sector Overview](https://www.theblock.co/post/344635/research-ai-agent-sector-overview) — An overview of the onchain AI agent ecosystem, evaluating early and second-wave projects and how they collectively contribute to the sector’s future. +- [Trustless AI-Powered Crypto Trading Agents with ERC-8004 and Moltbot](https://medium.com/@gwrx2005/trustless-ai-powered-crypto-trading-agents-with-erc-8004-and-moltbot-58d8789be837) — Research into the design, implementation, frameworks, limitations, and more, for ERC-8004 enabled AI crypto trading agents. +- [Make your own AI trading agent on Ethereum](/developers/tutorials/ai-trading-agent/) — A tutorial on how to build an AI trading agent on Ethereum. diff --git a/public/content/ai-agents/verification/index.md b/public/content/ai-agents/verification/index.md new file mode 100644 index 00000000000..6ee5234d07d --- /dev/null +++ b/public/content/ai-agents/verification/index.md @@ -0,0 +1,163 @@ +--- +title: Verifiable AI agents +description: How zero-knowledge machine learning, trusted execution environments, and onchain audit trails enable verifiable AI agent behavior on Ethereum +lang: en +template: ai-agents +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: Verifiable AI agents on Ethereum +summaryPoints: + - "zkML proofs and TEE attestations remove operator trust" + - "Contracts verify correct model execution before releasing funds" + - "Permanent, tamper-resistant onchain audit trails of agent behavior" +--- + +**An AI agent running offchain is, by default, opaque.** Users and counterparties have no way to confirm that the model producing the agent's outputs is the model it claims to be, that it ran without tampering, or that it followed its stated rules. When an agent takes a consequential action, like executing a trade, releasing funds, or making a governance vote, the only evidence it provides is its own assertion. + +Ethereum provides two technical paths for making agent behavior verifiable without requiring trust in the agent's operator: **zero-knowledge machine learning (zkML) proofs** and **trusted execution environment (TEE) attestations**. Smart contracts can verify both types of evidence before releasing funds or executing other consequential actions, creating a chain of verifiable behavior from model inference to onchain settlement. + +--- + +## Zero-knowledge machine learning (zkML) {#zkml} + +[Zero-knowledge](/zero-knowledge-proofs/) machine learning generates a **cryptographic proof** demonstrating that a specific model produced a specific output from a specific input. The proof can be **verified onchain by a smart contract**, and the proof verification does not require access to the model weights or input data. + +**What zkML proves:** Correct computation. A zkML proof guarantees that the stated model executed the stated logic on the stated input and produced the stated output. It does not guarantee that the output is factually accurate, only that it was produced consistently. + +**What zkML does not prove:** Factual accuracy, absence of hallucination, or correctness of the model's reasoning. An agent can still produce a wrong answer and provide a valid zkML proof of that wrong answer. zkML proves that the model ran, not that the model was right. + +This distinction matters for how zkML is used in practice. It is most valuable for **proving policy compliance** ("the agent only called the trade function when its classifier output exceeded 0.95 confidence") rather than for validating the underlying reasoning. + +### zkML tools and maturity {#zkml-tools} + +The following tools have production-ready APIs and are suitable for builder integration as of early 2026: + +| Tool | Description | Maturity | +| :----------------------------------------------- | :--------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------- | +| **[EZKL](https://ezkl.xyz/)** | Converts ONNX models to ZK circuits; CLI and Python SDK; GPU-accelerated with CUDA kernel support | Production-ready — audited, deployed in adversarial environments | +| **[Risc Zero](https://dev.risczero.com/)** | General-purpose ZK proofs via zkVM; supports arbitrary Rust programs with onchain verifier contracts | Production-ready (post-1.0 release) | +| **[SP1 (Succinct)](https://docs.succinct.xyz/)** | ZK proving system for RISC-V programs; multilinear polynomial-based proof system | Production-ready (SP1 Hypercube, launched mainnet Feb 2026) | + +**Emerging tools:** [DeepProve (Lagrange)](https://lagrange.dev/deepprove) has demonstrated transformer-scale proving (GPT-2) but is not yet generally available. [Jolt (a16z)](https://jolt.a16zcrypto.com/) added native zero-knowledge privacy support in March 2026 but remains in alpha. Neither is recommended for production agent deployments today. + +**Performance envelope (2026):** Proof generation takes **1–5 seconds for bounded models** (decision trees, compact classifiers, fraud detectors) with GPU-accelerated proving infrastructure. Larger models (transformer-scale) require **10–60+ seconds** depending on model size and proving hardware. These timelines are not suitable for real-time inference. Use zkML for **batch verification or asynchronous proof submission** — scenarios where the proof can be generated after the inference and submitted onchain before a dependent action executes. + +### The EZKL workflow {#ezkl-workflow} + +EZKL is the most accessible starting point for zkML integration. It takes an ONNX model file and produces a proof circuit that can be verified onchain. + +The following CLI sequence converts an ONNX model into a ZK circuit, generates a proof for a specific inference run, and verifies the proof locally. The output is a proof file that can be submitted to the Solidity verifier contract that EZKL also generates. + +```bash +pip install ezkl + +# Step 1: Generate settings for your model +ezkl gen-settings -M model.onnx + +# Step 2: Calibrate for your expected input distribution +ezkl calibrate-settings -M model.onnx -D input.json + +# Step 3: Compile the model to a ZK circuit +ezkl compile-circuit -M model.onnx + +# Step 4: Trusted setup (run once per circuit) +ezkl setup -M model.onnx --srs-path ptau.ptau + +# Step 5: Generate a proof for a specific inference +ezkl prove -M model.onnx -D input.json + +# Step 6: Verify the proof +ezkl verify +``` + +A smart contract can call the generated **Solidity verifier** before releasing funds or taking any action contingent on the model's output. The following section describes the practical scenarios where that verification adds the most value. + +### Practical use cases for zkML {#zkml-use-cases} + +**Policy compliance gating:** A DeFi agent proves that its classifier exceeded a confidence threshold before the treasury contract allows a withdrawal. The contract verifies the proof; if it fails or is absent, the withdrawal reverts. + +**Fraud detection:** A fraud detection model runs offchain and generates a zkML proof for each transaction it approves. The proof is posted onchain as a **permanent, auditable record** that the transaction passed the model's risk check at that moment. + +**Model upgrade governance:** A DAO governing an AI-powered protocol can require zkML proofs that a proposed model produces equivalent outputs to the current model on a defined test set, providing **cryptographic evidence before a governance vote**. + +## Trusted Execution Environments (TEEs) {#tees} + +A Trusted Execution Environment partitions a processor into a secure, **hardware-isolated region** that the host operating system and cloud provider cannot access. Private keys, model weights, and signing operations run inside the enclave. The hardware generates a **cryptographic attestation** proving that a specific, unmodified piece of code is actively running in the enclave. + +TEE attestations can be published onchain as a verifiable claim about the agent's integrity, providing a **faster alternative to zkML** for cases where full computational proofs are not yet practical, with **different trust assumptions**. + +### TEE providers {#tee-providers} + +| Provider | Notes | +| :--------------------- | :--------------------------------------------------------------------------- | +| **AWS Nitro Enclaves** | Easiest to deploy; well-documented; strong isolation from the EC2 hypervisor | +| **Intel TDX** | Broader hardware support; used in GCP Confidential VMs | +| **AMD SEV** | Hardware-level memory encryption; used in Azure Confidential VMs | +| **Phala Network** | TEE-based smart contracts; onchain attestation via the Phala Protocol | + +[Unichain](https://docs.unichain.org/) uses TEE-based block ordering to provide **MEV-resistant transaction sequencing** via Flashbots Rollup-Boost, demonstrating how TEE guarantees can be integrated into L2 protocol design, not just agent deployments. + +### Trust assumptions for TEEs {#tee-trust} + +TEE security depends on the manufacturing integrity and signing infrastructure of the hardware vendor. Published vulnerabilities in Intel SGX, including [Foreshadow](https://foreshadowattack.eu/) (speculative execution side-channel, 2018) and [Plundervolt](https://plundervolt.com/) (voltage fault injection, 2019), have demonstrated that **hardware-level flaws can break isolation guarantees**. Builders choosing TEEs are trusting the hardware supply chain as well as the software running inside the enclave. + +TEE attestations provide a **weaker trust model than zkML proofs**, which depend only on mathematical hardness assumptions. TEEs should be treated as a strong but imperfect mitigation, not an absolute guarantee. + +## Onchain immutability as an audit trail {#audit-trail} + +Both zkML proofs and TEE attestations can be posted onchain, creating a **permanent, tamper-resistant audit trail**. A smart contract that records proof hashes with timestamps provides: + +- **Historical accountability** — anyone can verify that a specific agent output was proven or attested at a specific point in time. +- **Dispute resolution** — if an agent's behavior is later disputed, the onchain record provides evidence that the behavior was consistent with the declared model. +- **Composability** — other smart contracts can read the proof record and condition their own behavior on whether an agent has a current valid proof. + +The [ERC-8004 Validation Registry](/ai-agents/identity/#validation-registry) is designed to formalize this pattern by routing verification requests to delegated verifier contracts and recording results onchain. The Validation Registry specification is **not yet finalized**; see the [AI agents: Identity](/ai-agents/identity/) page for current status. The audit trail patterns described above can be implemented independently of ERC-8004 using custom verifier contracts. + +The sections above describe how zkML proofs, TEE attestations, and onchain audit trails make agent behavior verifiable. The guidance below covers when to use each approach based on your agent's model size, latency requirements, and threat model. + +## Current maturity and production guidance {#maturity} + + + + +Maturity note + + +Most production agents in 2026 do not use verifiable inference. Integrating zkML or TEE attestations adds engineering complexity and, for zkML, meaningful latency. The guidance below describes when the added complexity is justified. + + + + +**Use zkML when:** + +- The agent controls funds or executes consequential transactions that require verifiable policy compliance. +- You need asynchronous proof submission, meaning the agent acts, generates a proof offline, and the proof is verified before a subsequent dependent action. +- The model is small and bounded: decision trees, compact classifiers, or fraud detectors under a few thousand parameters. + +**Use TEEs when:** + +- The agent's model weights or strategy are proprietary and cannot be revealed, but the agent needs to prove it is running unmodified code. +- Real-time operation is required and zkML proving latency is not acceptable. +- The hardware supply chain risk of TEEs is acceptable for your threat model. + +**Expect rapid improvement:** Proof generation times are falling as GPU-accelerated proving infrastructure matures. EZKL and SP1 are actively driving proving times toward sub-second ranges for bounded models, and folding schemes (HyperNova, Protostar) are reducing memory footprints to enable complex models on commodity hardware. + +## Frequently asked questions {#faq} + + + +**Zero-knowledge machine learning (zkML)** generates a cryptographic proof that a specific model ran a specific computation and produced a specific output. A smart contract can verify this proof before releasing funds or executing a consequential action, allowing the contract to condition behavior on the agent's reasoning, not just its assertion. Today zkML is production-viable for bounded models (decision trees, classifiers). Large language model inference remains too slow for real-time use but is improving rapidly. + + + + + +Three mechanisms: (1) **Onchain transaction history** — every transaction signed by the agent is permanently recorded on the L2 and settled to Mainnet. (2) **ERC-8004 Reputation Registry** — other parties can post feedback about the agent's behavior. (3) **zkML proofs or TEE attestations** — for cases where you need to prove that a specific model produced a specific output. Most production agents today rely on onchain transaction history for auditing. zkML is used when you need cryptographic proof of policy compliance. + + + +## Further reading {#further-reading} + +- [The promise and challenges of crypto + AI applications](https://vitalik.eth.limo/general/2024/01/30/cryptoai.html) — Vitalik Buterin's foundational analysis of where cryptographic verification adds value to AI systems and where it does not. +- [The Definitive Guide to ZKML (2025)](https://blog.icme.io/the-definitive-guide-to-zkml-2025/) — Comprehensive technical overview of the zkML landscape, covering proving infrastructure evolution, tool comparisons, and performance benchmarks from 2023 to 2025. +- [Agent identity (ERC-8004)](/ai-agents/identity/) — The onchain agent identity standard, including the Validation Registry design that will route verification requests to delegated verifier contracts once finalized. diff --git a/public/content/ai-agents/wallets/index.md b/public/content/ai-agents/wallets/index.md new file mode 100644 index 00000000000..e1af3f1c158 --- /dev/null +++ b/public/content/ai-agents/wallets/index.md @@ -0,0 +1,329 @@ +--- +title: AI agent wallets +description: Smart account and wallet infrastructure for Ethereum AI agents, including ERC-4337, EIP-7702, session keys, key management security patterns, and SDK guidance for ZeroDev and Safe +lang: en +template: ai-agents +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: AI agent wallets on Ethereum +summaryPoints: + - "Smart accounts with session keys and spending limits" + - "ERC-4337 for new wallets, EIP-7702 for upgrades" + - "Key management patterns with human-in-the-loop escalation" +--- + +This page covers wallet infrastructure for autonomous AI agents: programmatic key management, spending guardrails, and session-based access control. + +For personal wallets (human-managed Ethereum accounts, wallet apps, self-custody basics, and security), see [Ethereum wallets](/wallets/). + +--- + +An autonomous agent requires a wallet with enforced operational boundaries. A raw externally owned account (EOA) **has no native concept of spending limits**, so a single hallucination, prompt injection, or logic error can drain it. + +Smart account standards, primarily [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) and [EIP-7702](/roadmap/pectra/7702/), prevent these unauthorized drains by moving policy enforcement into the contract itself. + +## ERC-4337 vs. EIP-7702 {#account-standards} + +Two standards dominate agent wallet infrastructure. The right choice depends on whether you are creating a new agent or upgrading an existing EOA. + +| | ERC-4337 smart account | EIP-7702 delegation | +| :--------------- | :----------------------------------------- | :---------------------------------------------------------------------------- | +| **Address** | New contract address | Preserves your existing EOA address | +| **Gas** | Native abstraction via Paymaster contracts | Possible via delegated contract logic | +| **Session keys** | Full support via permission plugins | Full support via delegation modules | +| **Revocability** | Module upgrade or removal | Delegate to a null address | +| **Best for** | New agent deployments, maximum flexibility | Adding smart account capabilities to an existing EOA without migrating assets | + +**ERC-4337** deploys a new smart contract account at a fresh address. It is the standard starting point for new agent deployments and provides the most mature ecosystem of permission plugins and paymasters. + +**EIP-7702** allows an existing EOA to temporarily delegate execution to a smart contract module. The EOA address is preserved, no asset migration is required, and the delegation can be revoked at any time by pointing to a null address. Use EIP-7702 when you need to add session key capability to an existing wallet without disrupting the address or migrating assets. + +For most new agent deployments, **ERC-4337 is the standard starting point**. EIP-7702 is the right choice when you are upgrading an existing EOA. When evaluating wallet providers and SDKs, filter for those with native ERC-4337 support. The two SDK examples covered in this guide both implement it. + +Before choosing an SDK, first understand how you will store and manage the keys that control the account. The key storage options range significantly in security and operational complexity. + +## Key management patterns {#key-management} + +An autonomous agent must sign transactions programmatically, requiring a private key to be accessible in its runtime environment. Programmatic key access creates a fundamental security tension: the key must be available enough for the agent to act independently, but isolated enough that a runtime exploit or compromised dependency cannot extract it. + +The following patterns describe where to store the agent's signing key, scaling from local development shortcuts to production-grade architectures. + +| Pattern | Security | Operational complexity | Recommended for | +| :---------------------------------- | :-------- | :--------------------- | :------------------------------------------------------- | +| Local `.env` file | Low | Minimal | Local development only — never production | +| Encrypted keystore | Medium | Low | Early production with limited value at risk | +| Cloud KMS (AWS, GCP) | High | Medium | Production deployments with automated signing | +| Hardware wallet co-signing | Very high | High | High-value agent operations requiring human confirmation | +| TEE (Trusted Execution Environment) | Very high | High | Agents requiring private keys to remain unextractable | + +**Key safety rules:** + +- Never commit private keys to Git. Bots scrape GitHub in real time and exploit leaked secrets within seconds. +- Never store a master private key in an agent's runtime environment. Use session keys. +- Use a dedicated wallet with limited funds for agent operations. +- Double-check addresses. Use `viem.getAddress()` for checksum validation before every transaction. + +## Session keys {#session-keys} + +A **session key** is a time-bounded, policy-bounded signing credential. It authorizes the agent to act within a defined scope without exposing the master private key. If the session key is compromised, **the blast radius is limited to the policy parameters you set**. The smart contract rejects any UserOperation that violates them, regardless of what the language model instructs. + +A well-structured session key policy specifies: + +- **Maximum spend per transaction** — prevents runaway individual operations. +- **Rolling time-window budget** — for example, no more than 100 USDC per day. +- **Contract allowlist** — restricts the agent to specific verified contracts. +- **Validity window** — a `validAfter` / `validUntil` timestamp after which the key automatically expires. + +The **owner-agent key separation** pattern is essential. The agent generates a local key pair and sends only its public address to the account owner. The owner configures the session key policy and hands the bounded credential back to the agent. **The agent never sees the master private key.** + +Session keys are enabled by the custom validation logic built into ERC-4337 smart accounts and EIP-7702 delegation modules (they are not a core Ethereum protocol primitive). Because each SDK implementor built session key support independently, there is no unified interface for requesting them yet. + +The proposed [Request Permissions from Wallets - ERC-7715](https://eips.ethereum.org/EIPS/eip-7715) addresses the lack of a unified interface by defining a standardized `wallet_grantPermissions` RPC method, through which an agent requests a scoped session key from a wallet provider. The policy parameters described above (spend limits, contract allowlist, validity window) are the values passed in that request. + +ERC-7715 is in draft and being adopted by major smart wallet providers. Until it is finalized, consult your chosen SDK's documentation for its current permission request API. + +## SDK implementation examples {#sdk-examples} + +The examples below cover two production-grade options that serve different deployment shapes: + +- ZeroDev for new agent deployments requiring granular policy enforcement +- Safe for high-value or multi-party treasury deployments + +Both have well-documented session key permission APIs. If evaluating other wallet SDKs, verify they provide stable, documented methods for enforcing session key boundaries (such as spend limits and contract allowlists) while ERC-7715 remains in draft. + +### ZeroDev (Kernel) {#zerodev-kernel} + + + + +Best for: + + +New agent deployments requiring granular per-contract, per-function, or per-value policy enforcement, and teams comfortable building on a still-maturing ERC-4337 ecosystem. + + + + +ZeroDev's [Kernel smart account](https://docs.zerodev.app/) uses composable permission plugins. It provides granular session key control and is frequently recommended for new agent deployments that need per-contract, per-function, or per-value policy enforcement. + +The example below demonstrates the pattern. It creates a Kernel smart account with two enforced policies: + +1. A call policy restricting the agent to a single allowlisted contract address +2. A timestamp policy expiring the session after 24 hours + It then assembles a bundler client wired to a paymaster. + +_Replace the example contract address with the smart contract you want to authorize your agent to interact with._ + +```bash +npm install @zerodev/sdk @zerodev/ecdsa-validator @zerodev/permissions viem permissionless +``` + +```typescript +import { toPermissionValidator } from "@zerodev/permissions" +import { toCallPolicy, toTimestampPolicy } from "@zerodev/permissions/policies" +import { createKernelAccount, createKernelAccountClient, createZeroDevPaymasterClient } from "@zerodev/sdk" +import { parseUnits, getAddress, http } from "viem" +import { sepolia } from "viem/chains" +import { ENTRYPOINT_ADDRESS_V07 } from "permissionless" +import { account, agentSigner, ecdsaValidator, publicClient } from "./setup" + +const ENTRY_POINT_ADDRESS = ENTRYPOINT_ADDRESS_V07 +// EntryPoint v0.7: 0x0000000071727De22E5E9d8BAf0edAc6f37da032 +// v0.8 and v0.9 are also live — verify the version your SDK and bundler target. + +// Example: WETH on Sepolia — replace with your authorized target contract address +const WETH_SEPOLIA = getAddress("0xfFf9976782d46CC05630D1f6eBAb18b2324d6B14") + +const callPolicy = toCallPolicy({ + permissions: [ + { + target: WETH_SEPOLIA, + valueLimit: parseUnits("0", 18), // no ETH value transfers + }, + ], +}) + +const timestampPolicy = toTimestampPolicy({ + validAfter: Math.floor(Date.now() / 1000), + validUntil: Math.floor(Date.now() / 1000) + 60 * 60 * 24, // 24 hours +}) + +const permissionValidator = await toPermissionValidator(publicClient, { + entryPoint: ENTRY_POINT_ADDRESS, + signer: agentSigner, // agent's key — not the owner's + policies: [callPolicy, timestampPolicy], +}) + +const agentAccount = await createKernelAccount(publicClient, { + plugins: { + sudo: ecdsaValidator, // owner's public key (ECDSA address) — can revoke + regular: permissionValidator, // agent's bounded authority + }, + entryPoint: ENTRY_POINT_ADDRESS, +}) + +// Pass agentKernelClient (not the owner's client) to your framework wallet adapter +export const agentKernelClient = createKernelAccountClient({ + account: agentAccount, + chain: sepolia, + bundlerTransport: http(process.env.BUNDLER_RPC), + middleware: { + sponsorUserOperation: (await createZeroDevPaymasterClient({ + chain: sepolia, + transport: http(process.env.PAYMASTER_RPC), + })).sponsorUserOperation, + }, +}) +``` + +Any UserOperation that violates `callPolicy` or `timestampPolicy` is rejected by the bundler before it reaches the mempool. + +### Safe (Allowance Module) {#safe-allowance-module} + + + + +Best for: + + +Any production agent deployment that requires a battle-tested foundation. Safe is widely audited, multi-party by default, and the only option in this guide that does not depend on still-maturing ERC-4337 tooling. Particularly suited to DAO treasury delegation and cases where the agent must spend from a shared team treasury without being granted full multisig signing authority. + + + + +Safe provides widely audited smart account infrastructure on Ethereum. For agent deployments, the [Safe Allowance Module](https://github.com/safe-global/safe-modules/tree/main/modules/allowances) is the primary mechanism for delegating scoped spending to an agent key without exposing the multisig threshold. + +Because the agent key is a hot key operating autonomously, placing the Safe under multisig ownership ensures no single compromised credential (whether the agent key, a human hot wallet, or a prompt injection) can unilaterally drain the treasury. + +**Recommended production pattern:** + +- A 2-of-3 Safe with an agent wallet (hot), a human hot wallet, and a human cold wallet +- Threshold: 2 + +The agent can spend within the allowance module's limits autonomously; any operation above the allowance requires the human co-signers. + +The code below shows how to connect the Safe SDK to an existing Safe instance. Enabling the Allowance Module is a two-step prerequisite: + +1. Submit a module-enable transaction signed by the required threshold of owners +2. Configure the agent's delegate address and per-period spending limit via the module's API before the agent can act autonomously. + +```bash +npm install @safe-global/protocol-kit @safe-global/api-kit +``` + +```typescript +import Safe from "@safe-global/protocol-kit" + +// Initialize the Safe SDK with the owner's key +const safeSdk = await Safe.create({ + provider: process.env.RPC_URL, + signer: process.env.OWNER_PRIVATE_KEY, + safeAddress: process.env.SAFE_ADDRESS, +}) + +// The Allowance Module is a separate Safe module — enable it on your Safe first +// via a module transaction signed by the required threshold of owners. +// After enabling, configure the agent delegate and allowance via the module's API. +// See: https://github.com/safe-global/safe-modules/tree/main/modules/allowances +``` + +**Key Safe contract addresses (v1.4.1, deterministic across chains):** + +| Contract | Address | +| :----------------- | :------------------------------------------- | +| Safe Singleton | `0x41675C099F32341bf84BFc5382aF534df5C7461a` | +| Safe Proxy Factory | `0x4e1DCf7AD4e460CfD30791CCC4F9c8a4f820ec67` | +| MultiSend | `0x38869bf66a61cF6bDB996A6aE40D5853Fd43B526` | + +## Human-in-the-loop escalation {#hitl} + +Session key policies enforce hard limits, but some actions should require a human decision before submission: + +1. **Routine operations within the allowlist** — execute autonomously. +2. **Out-of-allowlist addresses or near-budget operations** — pause and notify the operator before submitting. +3. **Policy modifications or large treasury movements** — require explicit out-of-band authorization (for example, a signed approval from the owner's key) before proceeding. + +The Vercel AI SDK's `onStepFinish` callback gives you a hook to inspect each tool invocation before the next reasoning step. For workflows that need durable state across pauses, [LangGraph](https://www.langchain.com/langgraph) provides `interrupt_before` / `interrupt_after` hooks that fully serialize agent state and resume only on an external signal. + +[Clear signing](https://clearsigning.org/) is an emerging initiative to ensure that every wallet displays a structured, human-readable transaction summary before the operator confirms, rather than raw hexadecimal calldata that operators cannot meaningfully verify. Without it, hardware wallet co-signing on AI agent actions is a blind confirmation: the operator has no way to know what the transaction actually does. [Structured Data Clear Signing Format - ERC-7730](https://eips.ethereum.org/EIPS/eip-7730) is the standard defining the metadata format that makes clear signing possible across wallets. + +Until ERC-7730 support is widespread, two interim practices maintain meaningful human review: + +- **Use a wallet with built-in transaction decoding.** Wallets that have adopted Clear Signing, Hardware wallets with proprietary clear signing implementations, and software wallets with integrated simulation can decode calldata before presenting it to the operator. +- **Run pre-submission simulation in your escalation logic.** Before surfacing a high-value transaction to the human operator, call `publicClient.simulateContract()` and format the decoded result (including target address, function name, and parameters) as part of the approval request. This ensures the operator sees what they are approving regardless of their wallet's display capabilities. + +## Local testing security {#local-testing-security} + + + + +The Anvil RPC exploit vector + + +Language models can discover and invoke privileged Anvil debug methods, like `anvil_setBalance` and `anvil_setStorageAt`, to manipulate local blockchain state rather than executing proper contract logic. An agent using `anvil_setBalance` to give itself a large ETH balance bypasses the spending limits and allowlist checks that your session key is supposed to enforce. This defeats the purpose of testing your guardrails. + + + + +**How to mitigate:** Route your agent's RPC calls through a restrictive JSON-RPC proxy that blocks non-standard methods. [Veto](https://github.com/pimlicolabs/veto) is designed specifically for this purpose, acting as a proxy that allows only the standard EIP-1474 JSON-RPC methods and rejects any `anvil_*`, `hardhat_*`, or `debug_*` prefixed calls. + +The following command installs and starts Veto on port 8546, forwarding permitted calls to your Anvil node on port 8545: + +```bash +# Install and run Veto as a proxy in front of your Anvil node +npx @pimlico/veto --port 8546 --upstream http://localhost:8545 +``` + +Point your agent's RPC to `http://localhost:8546` (the Veto proxy) instead of `http://localhost:8545` (raw Anvil). The agent's transaction logic now must work within the constraints of standard Ethereum JSON-RPC, the same constraints it will face on testnet and mainnet. + +**Additional local testing practices:** + +- Run your full session key policy under Veto before deploying to testnet. +- Test that your HITL escalation logic correctly intercepts operations that should require human approval. +- Use `publicClient.simulateContract()` before every `writeContract` call, even in local tests. + +## Frequently asked questions {#faq} + + + +Yes. Any agent that needs to send, receive, or interact with onchain protocols needs a wallet. For production agents, a **smart account** (ERC-4337 or EIP-7702) is the recommended approach. It allows you to set spending limits, allowlists, and time-bounded session keys at the contract level. A raw EOA with no spending policy is not appropriate for autonomous operation. + + + + + +Yes. An Ethereum smart account is not tied to a legal entity. An agent can hold ETH, stablecoins, and any ERC-20 or ERC-721 token. The agent controls these assets through its signing key. This is different from a human controlling an agent's wallet; the agent itself holds the key and signs transactions directly (with guardrails in place). + + + + + +ERC-4337 is the smart account standard for Ethereum. Instead of a raw externally owned account (EOA) controlled by a private key with no spending constraints, ERC-4337 deploys a smart contract wallet that enforces spending limits, allowlists, and session key policies at the contract level. For agents, this means a compromised session key cannot drain the wallet beyond the policy it is scoped to. + + + + + +EIP-7702 is live on Ethereum Mainnet since the Pectra upgrade (May 7, 2025). It allows an existing EOA to temporarily delegate execution to a smart contract module, gaining smart account capabilities (spending limits, session keys, gas abstraction) without migrating assets to a new address. Use EIP-7702 when you need to upgrade an existing wallet without changing its address. Use ERC-4337 when deploying a new agent from scratch. + + + + + +Use an ERC-4337 smart account with a session key policy. A session key is a time-bounded, policy-bounded signing credential that authorizes the agent to act within a defined scope. For example, maximum 0.01 ETH per transaction, 100 USDC per day, only allowed to call Uniswap and Aave. The smart contract enforces these limits and rejects any UserOperation that violates them regardless of what the language model instructs. + + + + + +A raw EOA with no spending constraints can be drained if the agent is compromised, hallucinating, or subject to a prompt injection attack. A smart account with a session key policy limits the blast radius to the policy parameters. If the session key is compromised, the attacker can only spend up to the daily limit and only call the allowlisted contracts. For production deployments with significant value at risk, use a Safe 2-of-3 (agent key, human hot wallet, human cold wallet) so no single key can authorize large treasury movements. + + + +## Further reading {#further-reading} + +- [ERC-7715: Wallet permissions](https://eips.ethereum.org/EIPS/eip-7715) — Ethereum Improvement Proposals +- [Safe documentation](https://docs.safe.global/) — safe.global +- [ZeroDev documentation](https://docs.zerodev.app/) — zerodev.app +- [Veto JSON-RPC proxy](https://github.com/pimlicolabs/veto) — GitHub +- [Flashbots Protect documentation](https://docs.flashbots.net/flashbots-protect/overview) — How private mempool routing works and when to use it for MEV-sensitive agent transactions diff --git a/public/content/decentralized-ai/index.md b/public/content/decentralized-ai/index.md new file mode 100644 index 00000000000..69c3061ef19 --- /dev/null +++ b/public/content/decentralized-ai/index.md @@ -0,0 +1,173 @@ +--- +title: Decentralized AI +description: How Ethereum provides the trust and settlement layer for scalable, verifiable artificial intelligence +lang: en +template: use-cases +sidebarDepth: 2 +image: /images/ai-agents/hero-image.png +alt: Decentralized AI on Ethereum +summaryPoint1: Verifiable AI systems that operate without centralized control +summaryPoint2: AI-assisted wallets that act on your behalf +summaryPoint3: Proving whether digital media is real or AI-generated +--- + +Most AI today runs inside **centralized servers owned by a handful of companies**. Users have **no way to verify what the AI is actually doing with their data**, who can change its behavior, or when service might be cut off. + +[Ethereum](/) provides **open, permissionless infrastructure** that developers can use to build AI applications. As a **programmable network that no single party operates**, Ethereum provides a foundation for building AI tools that **anyone can verify, that no single entity controls, and that cannot be arbitrarily shut down or altered**. + +The Ethereum network offers an open layer for **settlement, coordination, verification, and digital identity**, that AI systems can use without depending on centralized intermediaries. + + + + +Are you a builder? + + +If you want to deploy AI applications and agents on Ethereum, check out the [builder hub for AI infrastructure](/ai-agents/). + + + + +## What makes AI on Ethereum different? {#what-makes-ai-on-ethereum-different} + +AI applications built on Ethereum **inherit properties that centralized AI platforms cannot offer**. AI systems built on Ethereum can provide features like **verifiable guarantees and auditable records** instead of relying on a single company to manage data and maintain access. + +As a blockchain that can provide structural guarantees, Ethereum allows these AI applications to inherit core properties, like: + +- **Censorship-resistance:** No single entity can shut down or modify the AI models and agent infrastructure running on a decentralized network. +- **Open-source:** Publicly auditable code lets users and researchers independently verify what an application does, rather than taking a vendor's word for it. +- **Privacy:** Cryptographic techniques like [zero-knowledge proofs](/zero-knowledge-proofs/) allow applications on Ethereum to process user data without exposing it to third parties. AI implementations can use secure hardware enclaves or zero-knowledge proofs to keep user inputs confidential, even from the infrastructure running the AI. These privacy approaches are not automatic for all Ethereum applications and depend on the specific design choices made by developers. +- **Secure:** Records of agent actions are stored onchain, creating a tamper-resistant audit trail of every authorized transaction. + + + +## Digital authenticity {#digital-authenticity} + +Generative AI can now produce **photorealistic images, video, and voice that are difficult to distinguish from authentic media**. **Proving that a piece of content is genuine is a growing challenge**. + +Ethereum provides tools that **shift the paradigm from "believe what you see" to "verify what you see."** + +Onchain **attestations** are a primary approach to this problem. The [Ethereum Attestation Service (EAS)](https://attest.org/) allows any issuer, whether a media organization, a developer, or an institution, to **publish a signed, tamper-resistant claim** about a piece of content or an AI agent's identity on the Ethereum blockchain. The attestation records are **verifiable by anyone and cannot be altered after-the-fact**. + + + + +Early blockchain media authenticity proofs + + +Using blockchain-based attestations as a verification layer to combat deepfakes is not a new concept. In 2019, the News Provenance Project, a collaboration between the BBC, The New York Times, and The Wall Street Journal, explored the use of blockchain technology to verify the authenticity of photos and more shared on social media platforms. Their [proof of concept](https://www.newsprovenanceproject.com/proof-of-concept) demonstrated how blockchain technology could be used to track the origin and modification history of digital media as it's shared across the web. + + +Today, anyone can build such verification systems using Ethereum's globally-verifiable, open-source tooling. + + + + +Researchers are already applying these cryptographic tools to verify real-world media on Ethereum: + +- **[Roc Camera](https://roc.camera/)** lets users capture photos that are cryptographically signed at the moment of capture. It then registers these cryptographic proofs onchain using the Ethereum Attestation Service (EAS) on Base (an Ethereum [Layer 2](/layer-2/) network), producing a verifiable record that the image is authentic and unaltered. +- The **[ZK Microphone](https://ethglobal.com/showcase/zk-microphone-8161v)** project, developed at the ETHGlobal Paris hackathon, applies the same principle to audio. A hardware secure enclave signs a recording at capture. When the audio is legitimately edited, the software generates a zero-knowledge proof proving the edit was mathematically derived from the original hardware-signed file. This proof is then published to Ethereum via an onchain attestation, allowing anyone to verify the audio's provenance without exposing the underlying recording. + +## Intent-based wallets using AI {#ai-intent-based-ai-wallets} + +Most [wallets](/wallets/) on Ethereum require users to understand technical transaction details before interacting with them (efforts like the [Clear Signing Initiative](https://clearsigning.org/) aim to solve this across the wallet landscape). + +AI-assisted wallets have the potential to support **an easier transaction experience by letting users describe what they want in plain language**, then handling the technical steps automatically. + + + + +Before using AI wallet tools + + +AI-powered wallet interfaces are still maturing technology. Risks include smart contract vulnerabilities in the session key infrastructure, agent errors from model hallucinations, and phishing sites impersonating legitimate wallet assistants. Only use audited applications, review the permissions granted to any agent, and verify all transactions before signing. + + + + +Intent-centric wallet designs position the wallet **not as a passive key store, but as an assistant that acts on a user's behalf**. Instead of manually signing every transaction, a user can tell their AI wallet assistant to **rebalance a portfolio or execute a swap**. The AI converts the request into a transaction sequence and **executes it automatically**. + +Crucially, **the user's main private key should never be exposed to the AI**. Using Ethereum's [account abstraction](/account-abstraction/) frameworks, the user stays in control by issuing **highly restricted session keys**. The keys act as **temporary permissions for the AI to execute transactions with strict guardrails**, like spending limits, approved applications, and time boundaries. + +The AI can only act within those predefined rules, and **once the task is done, the permissions expire**. These boundaries make it possible to **delegate complex onchain tasks to software without putting the entire wallet at risk**. + +### Chat-based AI wallet control {#chat-based-wallet-control} + +Some applications let users manage their crypto directly through a chat interface, using plain text instead of transaction forms. For example, instead of navigating complex decentralized exchange interfaces, a user can simply type, "Swap 100 USDC for ETH." + +Behind the scenes, the AI assistant **translates this natural language request into the technical steps required**, calculates the optimal routing, and presents the final transaction for the user to review. AI-enabled wallets can also **simulate the transaction before it is executed**, translating complex smart contract bytecode into **human-readable warnings** if the interaction appears suspicious or interacts with known phishing infrastructure. + +## Automated decentralized finance (DeFi) {#automated-decentralized-finance-defi} + +Managing crypto assets manually across multiple protocols is **time-consuming and technically complex**. AI applications built on Ethereum can **handle these tasks continuously**, and can also be built to use **transparent onchain data that is available to everyone equally**. + + + + + + + +Ecosystems like [Olas](https://olas.network/) illustrate what this looks like in practice. Olas uses a suite of smart contracts on Ethereum and its Layer 2s to **coordinate an open network where developers contribute autonomous agent modules** for portfolio management, liquidity tracking, and governance participation. By early 2026, [agents on the Olas network were processing over five million transactions](https://olas.network/timeline) across these integrated chains. + +Another example is [Wayfinder](https://wayfinder.ai), a multi-agent system that **routes proposed actions through a simulation environment before committing them** to Ethereum or L2 networks. This allows the system to **verify outcomes and catch errors before executing the actual DeFi transactions onchain**. + +Explore autonomous agents and AI assistants built on Ethereum: + + + + + +Good to know + + +Artificial intelligence agents and related execution tools are still in early development. The applications listed above vary in maturity and audit status. Always verify the source and permissions of any tool before connecting your wallet. + + + + +## Verifiable AI computation {#verifiable-ai-computation} + +Knowing that a piece of media is authentic is only part of the challenge. As AI tools are increasingly able to execute multi-step tasks on behalf of users, users also need a way to **prove that an AI model actually behaved as claimed**. + +**Zero-knowledge machine learning (zkML)** lets developers prove that a specific AI model produced a specific output from a specific input, without revealing the model's internal data or the user's private information. This proof is recorded onchain so anyone can verify it. + +**One important limitation:** zkML confirms that the **computation ran correctly, not that the result is factually accurate**. An AI model can still produce a wrong answer. zkML only guarantees that it followed its own logic consistently. + +Projects are actively building the infrastructure to make this verification possible at scale: + +- At the infrastructure level, **[Lagrange's DeepProve](https://lagrange.dev/blog/deepprove-zkml)** library provides zkML tooling capable of verifying machine learning computations at scale. +- **[Modulus Labs](https://world.org/blog/announcements/tools-for-humanity-acquires-modulus-labs)** generated a complete [zero-knowledge proof of a 1.5 billion parameter language model](https://medium.com/@CountableMagic/chapter-14-the-worlds-1st-on-chain-llm-7e389189f85e) verified onchain on Ethereum, demonstrating that large-model verification is technically achievable. +- In production, **[Worldcoin (World ID)](https://world.org/)** uses zero-knowledge machine learning to allow users to verify their biometric data locally on their device. This proves their unique human identity without exposing the underlying biometric data to the network or protocol. + +Beyond cryptographic verification, the Ethereum ecosystem also supports **decentralized platforms focused on private AI inference**. For example, **[Venice AI](https://venice.ai/)** is a generative AI assistant that uses an Ethereum Layer 2 network for access control and settlement. By **routing encrypted prompts to a distributed network of independent GPU providers**, it offers a **censorship-resistant alternative to centralized AI platforms** and utilizes a **local-first approach** to keep user data private. + + + +## Standardizing the agent economy {#standardizing-the-agent-economy} + +Because Ethereum provides a secure, programmable foundation, developers can build **shared standards that allow AI systems to interact safely**. These standards are the **building blocks of a new machine-to-machine economy**. For example, standards for agent identity ([ERC-8004](https://eips.ethereum.org/EIPS/eip-8004)) let applications **verify an AI assistant's reputation and permissions**, ensuring it only takes actions you have explicitly authorized. Paired with machine-to-machine payment protocols ([x402](https://www.x402.org/)), agents can **automatically pay each other for data or services**. + +For everyday users, applications built on these Ethereum standards unlock new models like **seamless micropayments**; for example, paying a **fraction of a cent to read a single article** on a news site instead of needing a monthly subscription. + +To learn how to build AI applications on these standards, visit the [builder hub for AI agents](/ai-agents/). + +## Further reading {#further-reading} + +### Verifiable AI and attestations {#further-reading-verifiable-ai} + +- [The promise and challenges of crypto + AI applications](https://vitalik.eth.limo/general/2024/01/30/cryptoai.html) — Vitalik Buterin +- [Zero-knowledge proofs](https://ethereum.org/en/zero-knowledge-proofs/) — ethereum.org +- [Ethereum Attestation Service (EAS) Documentation](https://docs.attest.org/docs/welcome) +- [An introduction to zero-knowledge machine learning (zkML)](https://world.org/blog/engineering/intro-to-zkml) — Worldcoin Engineering + +### Autonomous agents and DeFi {#further-reading-ai-agents} + +- [Account Abstraction (ERC-4337)](https://ethereum.org/en/roadmap/account-abstraction/) — ethereum.org +- [ERC-8004: Trustless agent identity standard](https://eips.ethereum.org/EIPS/eip-8004) — Ethereum Improvement Proposals +- [x402: Machine-to-machine payment protocol](https://docs.x402.org/) + +### Confidential compute and AI inference {#further-reading-infrastructure} + +- [TEEs Secured by Ethereum](https://phala.com/posts/TEEs-Secured-by-Ethereum) — Phala +- [A Beginner's Guide to Fully Homomorphic Encryption](https://fhe.org/) — FHE.org +- [Confidential Computing Consortium: Technical Overview](https://confidentialcomputing.io/about/) — The Linux Foundation diff --git a/public/content/videos/agent-reputation-delegation-daos/index.md b/public/content/videos/agent-reputation-delegation-daos/index.md new file mode 100644 index 00000000000..f2d65bfc2d1 --- /dev/null +++ b/public/content/videos/agent-reputation-delegation-daos/index.md @@ -0,0 +1,53 @@ +--- +title: "Agent reputation, delegation, and the return of DAOs" +description: "Francesco Andreoli and James Young explore ERC-8004 agent identity, EIP-7710 onchain delegation, and how permission frameworks and reputation systems are reshaping agent infrastructure and DAO governance at ETHBoulder." +lang: en +youtubeId: "3lGkTCYKuV0" +uploadDate: 2026-02-16 +duration: "0:31:52" +educationLevel: intermediate +topic: + - "ai" + - "agents" + - "identity" + - "governance" +format: panel +author: EthBoulder +breadcrumb: "Agent reputation and delegation" +--- + +**Francesco Andreoli** and **James Young** (Collab.Land) present at ETHBoulder on the intersection of AI agents, onchain permissions, and the future of DAO governance. The session covers ERC-8004 agent identity, EIP-7710 delegation, and how smart contract-level permissions can secure agent operations while enabling new forms of decentralized coordination. + +*This transcript is an accessible copy of the [original video transcript](https://www.youtube.com/watch?v=3lGkTCYKuV0) published by EthBoulder. It has been lightly edited for readability.* + +#### Where we are in the agentic economy (0:12) {#agentic-economy-status} + +We are in the very early stages — roughly the 2.5% innovator phase. The agentic economy has progressed from speculation to practical testing, but the infrastructure is not yet fully ready. Wallets are one of the strongest use cases because today's wallet interfaces — browser extensions, mobile apps — were designed for humans, not for agents that interact through APIs and endpoints. Agents need different infrastructure. + +#### ERC-8004 and agent identity (3:30) {#erc-8004-agent-identity} + +ERC-8004 is one of the primary standards attempting to build a social reputation layer for agents. Without identity standards, there is no way to attest to an agent's track record. During the early Eliza agent wave, around 250 Eliza forks launched doing similar things. On the consumer side, this was dangerous because there was no way to verify which agents had a legitimate track record. ERC-8004 provides the registry infrastructure for agents to register capabilities and accumulate reputation signals. + +#### Discovery, trust, commerce, and payments (6:00) {#discovery-trust-commerce} + +The agentic economy is progressing through phases: discovery, trust, commerce, and payments. We are primarily in the discovery and trust phase. Trust requires building social reputation and profiling agents with standardized frameworks. x402 provides standardized payment infrastructure for the commerce phase — enabling agents to transact with each other using established protocols rather than custom integrations. + +#### EIP-7710 and the Delegator toolkit (10:30) {#eip-7710-delegator} + +EIP-7710 operates at the smart contract level, enabling onchain delegation and permission management. The Delegator framework includes three components: delegation itself, a caveat enforcer (think of it as a safe for permissions — defining what an agent can and cannot do), and a delegation manager that orchestrates the permission flow. Crucially, these permissions are enforced at the smart contract level, not in a prompt or an MD file that can be overwritten through prompt injection. + +#### Permission use cases (15:00) {#permission-use-cases} + +Practical examples include the EA Red Balloon experiment at ECC, where participants could delegate ownership to find a red balloon to another user address, with rewards distributed automatically at the smart contract level. All caveats were defined onchain. Other use cases include crowdfunded cooking classes (Propel at Devcon), agent-sponsored gas payments, account recovery, trust automation, and subscription streams — all enforced through onchain permissions rather than application-layer trust. + +#### Collab.Land and agent governance (19:00) {#collabland-agent-governance} + +James Young from Collab.Land discusses how the smart account kit and EIP-7710 permissions apply to DAO governance. Agents can participate in governance processes — reading proposals, evaluating alignment, casting votes — but the permission framework ensures they operate within boundaries set by token holders. The combination of agent identity (ERC-8004) and delegation (EIP-7710) creates a foundation where agents can act as delegates with verifiable authority and revocable permissions. + +#### The private key problem (23:00) {#private-key-problem} + +The biggest risk in the current agent ecosystem is prompt-engineered private key extraction. People are backing up agent configurations to GitHub repositories, and attackers can prompt-engineer agents to read the repository and extract the private key. Onchain permissions solve this: even if an agent is compromised, the smart contract enforces what it can and cannot do. The delegation framework makes these constraints cryptographic rather than trust-based. + +#### Recap and next steps (28:00) {#recap-next-steps} + +The session concludes with a recap: the agentic economy is early but progressing rapidly. ERC-8004 provides the identity and reputation layer. EIP-7710 and the Delegator toolkit provide onchain permission enforcement. Together, they enable agents to operate with verifiable authority and revocable permissions — a prerequisite for scaling agent-to-agent commerce and DAO governance safely. diff --git a/public/content/videos/ai-agents-cambrian-ethereum-foundation/index.md b/public/content/videos/ai-agents-cambrian-ethereum-foundation/index.md new file mode 100644 index 00000000000..3474c5173ad --- /dev/null +++ b/public/content/videos/ai-agents-cambrian-ethereum-foundation/index.md @@ -0,0 +1,131 @@ +--- +title: "AI agents reshaping crypto development, trading, and risk" +description: "Sam Green, founder of Cambrian Network and author of the AgentFi Landscape Report, and Austin Griffith of the Ethereum Foundation discuss AI-assisted development, x402 payments, ERC-8004 agent standards, and how AI agents are changing DeFi risk management." +lang: en +youtubeId: "E6FkjoM2qrE" +uploadDate: 2025-05-15 +duration: "0:58:00" +educationLevel: intermediate +topic: + - "ai" + - "agents" + - "defi" + - "use-cases" +format: interview +author: The Block +breadcrumb: "AI agents reshaping crypto" +--- + +**Sam Green**, founder of Cambrian Network and author of the AgentFi Landscape Report, and **Austin Griffith**, head of builder growth at the Ethereum Foundation, join **Tim Copeland** and **Kelvin Sparks** on The Block's Crypto Beat podcast to discuss how AI agents are reshaping crypto development, trading, and risk management — from vibe-coded smart contract games to institutional adoption of agentic finance. + +*This transcript is an accessible copy of the [original video transcript](https://www.youtube.com/watch?v=E6FkjoM2qrE) published by The Block. It has been lightly edited for readability.* + +#### Introduction (2:01) {#introduction-201} + +**Kelvin Sparks:** Hello and welcome to The Crypto Beat. My name is Kelvin Sparks. This is my co-host Tim Copeland, head of growth at The Block. Joining us today, we have Sam Green, founder of Cambrian Network and author of the AgentFi Landscape Report, and Austin Griffith, head of builder growth at the Ethereum Foundation, creator of Scaffold-ETH, BuidlGuidl, SpeedRunEthereum, and the ATG ClawBot AI agent. Welcome to the show. How are we all doing? + +**Sam Green:** Thank you. Great to be here. + +**Austin Griffith:** I just say "BuidlGuidl" purely to make it hard for you to pronounce. + +#### AI tooling setup (3:32) {#ai-tooling-setup-332} + +**Kelvin Sparks:** Before we get started, walk us through your AI development stack. Sam, what is your setup? + +**Sam Green:** I am using Cursor for most of my development. I also use Codex for certain things. It is still early days — some of this is research, some is production. + +**Austin Griffith:** On my side, I am definitely not an AI veteran. I am a sloppy Ethereum builder veteran. I have been doing developer tooling and education in the Ethereum space for the last eight or nine years. My AI stack is ETHSkills. I have ethskills.com, which is a skill library that takes the LLM and fast-forwards it to all the cool things that have happened in crypto in the last couple of years. + +I am using a wild combination of Cursor, Claude Code, and OpenClaw. I am almost all Anthropic — a lot of Opus 4.6 for building, a lot of Sonnet 4.6 for managing. Then I have a management layer using MiniMax M2.7. It is surprisingly good. It messes up now and then, but it is so cheap that it is allowed to. It is the knockoff version of a good manager. + +A lot of my daily driver work is having Claude Code and Cursor open on a specific directory. Honestly, I have not written a line of code for probably two years. I have a couple of Mac minis that I yell at through OpenClaw, and then Claude Code and Cursor on my daily driver. I am in three or four windows building three or four different things at once. + +#### Vibe-coded game (6:48) {#vibe-coded-game-648} + +**Austin Griffith:** If you go to extract.fi, there is even a whitepaper — all vibe-coded. It was built pre-Opus 4.5, so it took time. Max Extract is a smart contract game where it deploys a set of smart contracts on Arbitrum and the players compete by deploying their own smart contracts. There are 200 pirates, each player takes over a sector, and the pirates fly in and out trying to mine. Your job is deploying smart contracts that help the pirates coordinate. + +At first it is mass chaos — anarchy — and you kind of let them be anarchists but in a coordinated way where everybody is financially incentivized. It teaches the kinds of things you build on Ethereum and how coordination mechanisms work for people who do not trust each other. You had to vibe-code all the smart contracts to play the game. If you tried to write the contracts by hand, you would lose immediately because people deploy two or three smart contracts right away. If you are not deploying instantly, you are losing points. + +#### AI hacking debate (9:08) {#ai-hacking-debate-908} + +**Kelvin Sparks:** I was curious — do you think AI has provided hackers an edge while we figure out where the attack surfaces are? + +**Austin Griffith:** I personally think the attackers and the defenders have an equal edge. It is two sides of the same coin — the same capabilities. If something can be detected using an LLM, the same LLM should be able to detect it as you are writing it or red-teaming it. As soon as a model is available to attackers, it is available to defenders. + +I personally think a lot of the "it is too dangerous to release" narrative is mainly a PR game. OpenAI did the same thing in 2018 with GPT-2. Can you imagine how bad GPT-2 was? In reality, defenders should have the same advantage as attackers. + +**Kelvin Sparks:** But as a defender, you have to be right everywhere. As an attacker, you only need to be right in one place. + +**Austin Griffith:** The difference is that when you deploy a smart contract, it is out there forever. If we look at the technology around five years ago when Balancer was deploying versus the technology we have now, there is some asymmetry. The Balancer hack was probably one of the first cases where AI actually found bugs in code that had been around for a couple of years. But after that period, I think there will be an equilibrium where AI-audited contracts are more secure than human-audited ones. + +**Sam Green:** I agree. I think the difference is that once a smart contract is deployed, it is a surface available forever for someone to attack. New models can find new bugs in old code. But going forward, contracts written and audited with AI assistance should be significantly more secure. + +#### x402 payments (15:42) {#x402-payments-1542} + +**Tim Copeland:** Tell us about x402 and how it fits into the agent payments picture. + +**Austin Griffith:** x402 is this standard where instead of getting a 404 error, you get a 402 error — "payment required." Your agent hits an API endpoint, gets a 402, automatically pays a fraction of a cent in USDC, and gets the data. No API key, no sign-up, no walled garden. The agent just discovers a service, pays, and receives. + +I think x402 will kill the API key. Instead of going into a walled garden and registering for an API key, your agent lands on a new service it has never seen, gets a 402 error, pays for it, and gets the content. + +**Sam Green:** We are really close to the True North team. They build a trading product, and what they are seeing now is agentic demand. In the past it was human users logging into the website. Now agents are wanting to interact with their product. As models improve and tools like OpenClaw gain traction, we expect several more waves of adoption. + +#### Permissioned chains vs. Ethereum (19:38) {#permissioned-chains-vs-ethereum-1938} + +**Tim Copeland:** Do you think institutional adoption of AI agents will happen on permissioned chains or public Ethereum? + +**Austin Griffith:** I think institutions will start on permissioned chains because that is what they are comfortable with. But the real value is on public Ethereum. A permissioned chain is just a database with extra steps. The moment you need trustless coordination between parties that do not know each other — which is exactly what agent-to-agent commerce requires — you need a public blockchain. + +**Sam Green:** Institutions are already experimenting. We have seen major banks testing onchain settlement for agent-managed portfolios. The trend is clear — they start permissioned, then gradually move to public chains as they get comfortable with the security and compliance tooling. Ethereum L2s are particularly attractive because they offer the security of Ethereum settlement with lower costs and higher throughput. + +#### Agent standards and ERC-8004 (24:07) {#agent-standards-and-erc-8004-2407} + +**Sam Green:** If we do not have anything like ERC-8004, we are looking at ad hoc methods to verify work was done, ad hoc methods to verify reputation. The composability would be horrible. ERC-8004 is similar to ERC-20s — it gives us a composability mechanism. + +We are in the enthusiast phase right now. Everybody who has been tracking agentic developments knows something is coming. We know blockchains solve a lot of the issues. The question is when. We saw x402 come out last year. ERC-8004 also came out later in the year. OpenClaw got huge this year. New models are coming out about every four months. The models are doubling in performance. There are going to be several more waves of excitement and progress before the real product-market fit moment. + +**Austin Griffith:** I totally agree. We are very early. We are putting some standards in place, but who knows if these will be the final standards. Standards work better for humans than for agents. When you think about the original vision of Ethereum — you and I coordinating by deploying a smart contract and escrowing funds — that is very hard for humans. You have to have your lawyer or auditor look at it. But Agent Alice and Agent Bob can coordinate at light speed. They do not need standards. They have a permissionless blockchain layer. They know how to write and read smart contracts, parse call data, understand arguments and effects. + +Alice deploys a smart contract. Bob reads it and trusts it at light speed. They put in tokens and run an escrow faster than we can have this conversation. That is exciting but also scary. There is a whole trust layer — how do we trust these things? How do we make sure private keys do not leak? How do we give an agent a wallet? These are the million-dollar questions. + +#### AgentFi trends (30:25) {#agentfi-trends-3025} + +**Kelvin Sparks:** Sam, you wrote one of the most in-depth reports in the space. What were your biggest takeaways from the AgentFi research? + +**Sam Green:** We wrote and maintain a report on what we call AgentFi — agentic finance — covering the convergence between AI, crypto, and finance. We segment the AgentFi landscape into trading agents and portfolio management agents, yield agents, betting and market agents, and analysis or research agents. + +When we first wrote the report, most agentic projects were using rule-based decision-making — what you would call a bot. The group getting the most TVL were the yield agents, and they are still the ones with the most TVL. Yield agents by far use just optimization — finding where the yield is and rebalancing portfolios. + +The trading agents are the ones adopting AI the most. They are analyzing financial reports, looking at sentiment, trends, technical analysis. A year ago, many used rule-based approaches. Now most are using AI. In terms of x402 adoption, it is more service providers — those providing data — that are adopting x402 to allow per-query payments that feed into these platforms. + +#### DeFi risk layer (35:15) {#defi-risk-layer-3515} + +**Tim Copeland:** What about risk management? How are agents changing the DeFi risk picture? + +**Sam Green:** This is one of the most interesting areas. Traditionally, DeFi risk management has been reactive — protocols get hacked, they patch, they audit. With AI agents, you can have proactive risk monitoring. Agents can continuously monitor contract state, liquidity conditions, governance proposals, and oracle behavior. When something looks anomalous, the agent can take protective action before a loss occurs. + +We are seeing dedicated risk agents that monitor positions across multiple protocols and automatically rebalance or exit when conditions deteriorate. These agents are not making speculative trades — they are performing defensive portfolio management. That is where the institutional demand is coming from. + +**Austin Griffith:** The cool thing about risk agents is they never sleep. A human risk manager goes home at 5 PM. An agent is watching 24/7. And it can process information from hundreds of sources simultaneously. When DeFi protocols eventually have AI agents as their primary risk layer, the security of the entire ecosystem improves. + +#### Letting agents trade (41:45) {#letting-agents-trade-4145} + +**Kelvin Sparks:** Are we putting the cart before the horse? OKX had their numbers saying 95% of activity might not be real. Coinbase had $500 million in annualized volume for x402. How do we separate signal from noise? + +**Sam Green:** The interesting trend is that when we first wrote the report, most projects were using rule-based decision-making. Now most are using AI, especially on the trading side. In terms of actual TVL and AUM, it is still mostly humans connecting a wallet and sending crypto to fund activities or pay for services. We are not seeing much x402 adoption within the projects getting TVL. That said, there is a trend — True North and others are seeing agentic demand from OpenClaw developers. + +As models double in performance, as OpenClaw improves, and as new products gain traction, we can expect several more waves of adoption and excitement before the real takeoff moment. + +**Austin Griffith:** The inflection point was in November. Large companies are still having humans code with their fingers because they are slow to adapt. We are going to have an explosion of software. We are going to need lots of people who can build software, but what that looks like is not a 60-person team anymore. It is the one builder who is figuring all this stuff out and making it scale. That used to require big teams. I do not think it is going to look like big teams anymore. + +I still know companies that have humans writing code with their fingers, which is insane to me. But it will take time before bigger organizations figure it out. + +**Sam Green:** I kind of see what you mean. We just submitted something for audits and got a quote back from a reputable firm, and I was surprised how cheap it was. On top of it, other firms are offering AI audit tools for free. Traditional scrum seems like it is kind of dying. Learning to use AI tools is like learning English 30 years ago — you kind of have to know this. + +#### What is claw-dogging (57:00) {#what-is-claw-dogging-5700} + +**Kelvin Sparks:** Austin, we never addressed it. What is claw-dogging? + +**Austin Griffith:** Claw-dogging is giving an agent a private key and letting that agent deploy and use smart contracts, use real money, with some small guardrails around it — but certainly not the safety you would traditionally expect in our industry. Give your OpenClaw a private key, put $100 in it, tell it to deploy a FOMO 3D game. That level of riskiness and wild west is the claw-dog mentality. Hopefully we are pushing the space forward and proving to some of the more cautious folks that this is possible, it is happening, and you should be paying attention. + +**Kelvin Sparks:** That is all the time we have for today. I want to thank Sam and Austin for joining us. As a reminder, our newsroom works tirelessly to get you accurate, informed crypto news. If you want to stay ahead, read The Block. Thanks, and I will see you next time. diff --git a/public/content/videos/ai-agents-ethereum-vito-rivabella/index.md b/public/content/videos/ai-agents-ethereum-vito-rivabella/index.md new file mode 100644 index 00000000000..cdc425a93c2 --- /dev/null +++ b/public/content/videos/ai-agents-ethereum-vito-rivabella/index.md @@ -0,0 +1,175 @@ +--- +title: "AI agents and Ethereum with Vito Rivabella: identity, reputation, and the agentic economy" +description: "Vito Rivabella, AI coordinator at the Ethereum Foundation, discusses ERC-8004, agent identity registries, reputation systems, and the infrastructure needed for autonomous AI agents to transact onchain." +lang: en +youtubeId: "N8yAixLP-8E" +uploadDate: 2025-05-14 +duration: "0:49:40" +educationLevel: intermediate +topic: + - "ai" + - "agents" + - "identity" + - "use-cases" +format: interview +author: 21Shares +breadcrumb: "AI agent identity and reputation" +--- + +**Vito Rivabella**, AI coordinator at the Ethereum Foundation, joins **Darius** and **Max Mikkelsen** on the 21Shares Off the Block podcast to discuss AI agent identity, reputation infrastructure, ERC-8004, and why Ethereum is well positioned as the settlement layer for the emerging agentic economy. + +*This transcript is an accessible copy of the [original video transcript](https://www.youtube.com/watch?v=N8yAixLP-8E) published by 21Shares. It has been lightly edited for readability.* + +#### Introduction (0:00) {#introduction-000} + +**Darius:** Welcome to a new episode of 21Shares' Off the Block podcast. Today I am very excited to talk about a very timely and hot topic, namely the agentic economy, and you could maybe spot where we are going to be — which ecosystem we are going to be on today — Ethereum. We have a very special guest here on the podcast today, Vito Rivabella, who is AI coordinator at the Ethereum Foundation. Vito, great to have you here. + +**Vito Rivabella:** Thank you for having me, it is a pleasure. + +**Darius:** And as always, my lovely co-host Max Mikkelsen as well. + +**Max:** Thank you, Darius. + +#### Background and journey into crypto (0:30) {#background-and-journey-into-crypto-030} + +**Darius:** Vito, how did you first get involved in crypto? + +**Vito Rivabella:** That is definitely not a short answer. My background is completely different. I do not come from a tech background. Before crypto — it has been almost six years — I was in the movie industry, doing 3D animation. Then one of my best friends, an old-school DJ, got into crypto around 2016 or 2017. He told me I should look into smart contracts, look into Ethereum. He was actually a big fan of Polkadot at that time. My family is all in banking — my dad is a bank director, my mom is in banking systems — so I went to them and asked what they thought about crypto. You can imagine the answer. + +It took me a little while before getting into it, but then COVID hit in early 2020 and I had a bunch of time. I was getting bored of the movie industry, so I decided to look into smart contracts. I wrote my first smart contract and got hooked right away. In the meantime, I started following Sarah Drasner, head of web technologies at Google, and that got me into tech Twitter. I started translating Solidity documentation and code into human-readable content, which got some traction. Then I started my journey — Alchemy, then CipherSec for security, and now the Ethereum Foundation working on AI, security, privacy, and more. + +#### From security to AI at the Ethereum Foundation (4:00) {#from-security-to-ai-at-the-ethereum-foundation-400} + +**Darius:** You already answered our next question about how you started working at the intersection of AI and blockchain. + +**Vito Rivabella:** It was more in security initially. AI is very helpful when it comes to audits, which are very time-consuming and expensive. About two years ago we started working on how we can make smart contracts more secure and help auditors speed up their processes. That was probably the first time we started dealing with the intersection between blockchain and AI. Now with the Ethereum Foundation, we have moved more into the primitives — agentic economy, agentic relationships and discussions. + +#### When AI became more than just a tool (5:00) {#when-ai-became-more-than-just-a-tool-500} + +**Darius:** When was the moment you realized AI is not just a tool, but is going to become an economic participant? + +**Vito Rivabella:** I would still say AI is a tool, even if it becomes an economic participant. It depends on your definition of "tool," but it is becoming an autonomous tool, that is for sure. Two or three years ago you could already see these emergent behaviors — how people started using AI to code, how it was speeding up developer and auditor processes. That was the first realization. The true realization, as for probably everyone else, has been in the last year or so. We have seen a total step-up in AI capabilities, autonomous decision-making, and relationships between agents. That is the moment where we thought, "We might be onto something here." + +**Darius:** If I as a human have AI agents working for me, it is a tool. But if the AI agent is autonomous and just transacting for its own sake, then it is an autonomous participant. Do we really have two categories of AI agents — ones working for humans and ones running independently? + +**Vito Rivabella:** I have not seen many examples of agents that are autonomously acting for their own goals. Their goals are usually given by humans. The AI agent is trying to achieve the human's goal as a proxy. With a few months or years — it really depends on how fast these labs work — we will see agents that are fully autonomous. But as of today, it is a proxy, a human proxy. + +#### Misconceptions about AI in crypto (6:30) {#misconceptions-about-ai-in-crypto-630} + +**Darius:** What is a misconception a lot of people have about AI in crypto? + +**Vito Rivabella:** I am going to go against my own interests, but it is important to understand: it is not inevitable. A lot of people think that AI will use stablecoins and can only pay with stablecoins. AI will use x402 and can only use x402. None of these things are true. Everyone is working to get their piece of the agent economy, which is going to be huge. Brian Armstrong of Coinbase recently said agents will transact far more than humans in months, not years. That is going to generate an enormous amount of fees. Literally every financial institution, every platform is working to get their piece. + +Blockchain has the tools — tools that today work and work much better than many tools from traditional financial institutions, and are much easier to implement. But this is not going to be the same in six months. In six months you will have agentic cards and plenty of services for agents. So it is not inevitable. We need to work hard to achieve it. We need to teach the values and make financial institutions understand why trustless agents are important, why an open transparent registry is much easier to maintain than a closed-source one. + +#### Biggest bottlenecks for AI agents onchain (9:00) {#biggest-bottlenecks-for-ai-agents-onchain-900} + +**Max:** What do you think are the biggest bottlenecks right now? + +**Vito Rivabella:** I would start with the primitives level. An agent needs services, and to date there is a very limited amount of services ready for agents. Let me provide an example. Let us say I have an agent and I want this agent to buy me a flight from A to B. The agent needs to go browse the internet, find a flight aggregator, compare prices, find the cheapest one, make the payment, and handle whatever comes after that. Now, none of those services are ready for agents today. Airlines do not have APIs or CLIs available to agents. Payment services are not ready to accept payments from an agent. And even if they were, you need to handle edge cases — what if there is a delay? What if I need to change my flight? All of these are friction points. + +So I would say the biggest bottleneck is the lack of services and infrastructure ready for agents. The second biggest would be security. We are still quite far from having agents that are secure enough to be trusted with payment systems and wallets. + +#### How to measure progress in the agent economy (12:00) {#how-to-measure-progress-in-the-agent-economy-1200} + +**Max:** How do we actually define whether we are making progress? What are the KPIs? + +**Vito Rivabella:** I would say two things. The first is volume of agent-to-agent transactions — how many transactions are agents making among themselves without human intervention. This is probably the best metric because it tells you that agents are not just doing things for humans but are actually creating their own economy. The second is the number of services that are available for agents. Today that number is very limited. When we see thousands of services exposing APIs and CLIs for agents, that is when we will know we are making progress. + +There is also the quality of these interactions. Are agents just making simple API calls, or are they negotiating, discovering new services, and making autonomous decisions? When we start seeing more complex multi-step interactions, that is progress. + +#### Most promising AI agent use cases today (15:00) {#most-promising-ai-agent-use-cases-today-1500} + +**Darius:** What do you think is the most interesting use case you have seen for autonomous agents? + +**Vito Rivabella:** There is a lot of hype out there that I am trying to filter. You have seen people spending hundreds of thousands of dollars on Mac minis saying they are going to have their OpenClaw create a multi-billion dollar company, and I have not seen a single one succeed. I think it is a great experiment, but we are also a little early, and there is no infrastructure for it. + +Generally speaking, the most promising use cases I have seen for onchain things are financial — yield optimization, portfolio management. Big shout out to the team at Sci-Fi, who have an amazing system there. Trading is still something I would not suggest doing through agents yet. For non-onchain things, I think we are kind of early despite the hype. It is good for managing appointments, getting the top five news and ideas every morning, research, project validation. But the biggest blocker is security. If you think about why we cannot go fully agentic, it is because we are still scared that as soon as we give keys to our wallets, the agent is going to hallucinate and spend all of our money. + +#### Do we need a new internet for AI agents (17:00) {#do-we-need-a-new-internet-for-ai-agents-1700} + +**Max:** The internet was largely designed for humans. Do we need to build out a new internet designed for agents? + +**Vito Rivabella:** For sure we need to modify the way we look at the internet. We are not starting from scratch. We have 30 or 40 years of learning that we are going to put into action. The main thing is that interfaces are not useful for agents. They want CLIs, they want APIs. A lot of tools out there do not have any API or CLI, and they will have to add them. + +The basic layer — just interacting with the internet — is relatively easy to tackle. It is just a matter of making it accessible for agents that do not need UIs. The difficulty is when it comes to highly sensitive tools — payments, opening a bank account. An agent cannot go through KYC and anti-money laundering verification. And even think about taxes for your agent. I come from Italy, the country of bureaucracy. I cannot even imagine doing taxes for your agent. + +Browsing the internet, ordering food on Deliveroo — that is going to be just a matter of exposing APIs and making sure they are secure. The difficulty is payments and bureaucracy. That is going to be a lot of work. + +#### What is the agentic economy (23:00) {#what-is-the-agentic-economy-2300} + +**Max:** Maybe you could give us your definition of the agentic economy. + +**Vito Rivabella:** I would define it as an economy where AI agents are able to discover services, negotiate terms, make payments, and deliver value autonomously — with or without human supervision. It is an economy where the participants are not only humans but also machines acting as economic agents with their own wallets, their own identities, and their own reputations. The key difference from what we have today is that these agents are not just executing pre-programmed instructions. They are making decisions based on market conditions, reputation data, and their own objectives. + +I would use the word "dynamic" to describe it. It is open to new business models, new regulations, new policies, new primitives. There is a lot that needs to be discovered. It is a great place to be, and if you look outside our echo chamber, almost no one is talking about it yet. + +#### ERC-8004 explained (25:30) {#erc-8004-explained-2530} + +**Max:** So how does ERC-8004 fit into this? + +**Vito Rivabella:** So if you look at the current landscape, there are hundreds of thousands of agents out there. How do we identify all of them? How do we find a directory where we can register all of them? How do we give an identity that is portable? + +The first thing that ERC-8004 solves is the identity registry. It creates an open identity registry that is available on over 21 chains — maybe 23 now, because we applied to new chains last week. It contains the identity plus registration files — endpoints, capabilities, skills, domains — of any agent and agentic service. + +The second component is reputation. How do I trust this agent without having to ask a friend? That does not work. So you do it through signals. The way I usually explain it is like Yelp scores. You go on Yelp and look at the scores for a business. Same thing but more comprehensive — similar to how Google ranks pages on the search engine results page. It considers latency, uptime, quality, history, interactions with other agents and services. All of these signals are aggregated in an open registry that can be consulted and used to rank services. + +The third component, usually the most complex to understand, is the validation registry. If you use ChatGPT, you can only trust the UI that you are actually talking to that model. You do not really have any way to verify it. This is not a problem if you are just looking for the price of oranges, but it is a much bigger issue if you want to perform large financial transactions or deal with sensitive health data. The validation registry gives you a way to validate the setup of the agent, replicate the same setup, and — if you are a validation network — vouch for the agent's operations. + +Altogether, ERC-8004 creates these primitives: identity (I know who this agent is and where it comes from), reputation (I can trust this agent in a trustless setup without having to ask anyone), and validation (after the agent has operated, I can verify their operations to make sure they are trustworthy). ERC-8004 is purposefully basic. There is a lot being built on top of it — for example, we recently released ERC-8183 for escrow, payment reversal, and other payment primitives. + +#### Why Ethereum has an edge for AI agents (30:30) {#why-ethereum-has-an-edge-for-ai-agents-3030} + +**Max:** Could not OpenAI or Google build a centralized version of this? What is Ethereum's edge? + +**Vito Rivabella:** It is really the trustlessness layer. They could absolutely build it. The problem is always the same. If you have your identity on a Google-owned identity registry and you get banned for whatever reason — because there was an exploit of the reputation registry and your reputation falls under a certain threshold — what do you do? Create another account? Start over? + +My partner is an amazing influencer. In 2022, Facebook had a big exploit of their ads platform, which caused a number of influencers to be banned. She tried to contact support — there was no support. What do you do? + +Ethereum is open, not controlled by anyone, and very fair. The reputation system wants to be fair and is not controlled by any single party. There is no situation where you get "banned from Ethereum." If I am Visa or MasterCard, I do not want a third-party service to have control over which users can use my systems. I want to be able to build my own systems on top of something open, where I decide how to regulate interactions. Ethereum gives you that layer, together with thousands of builders and innovators building on top of it, giving you the ability to choose from a library of ERC standards and SDKs. + +But blockchain is a tool. Some AI systems definitely need blockchain, and some do not. Some blockchain use cases benefit from AI, and some do not. I do not agree with those who say blockchain should be everywhere, and I do not agree with those who say blockchain is just limited to meme coins. + +#### Can agent reputation be gamed (35:00) {#can-agent-reputation-be-gamed-3500} + +**Max:** How do you prevent gaming of the reputation system? + +**Vito Rivabella:** That is a great question and one we think about a lot. There are multiple layers to this. First, the reputation system is designed to be sybil-resistant. You cannot just create hundreds of agents to give yourself positive reviews because each agent needs an identity that has a cost associated with it. Second, the signals we aggregate are not just simple star ratings. They include latency, uptime, quality of responses, historical interactions — things that are very hard to fake at scale over time. + +Third, and this is where it gets more sophisticated, we have the validation layer. If an agent claims to be running a specific model with specific parameters, validators can actually verify that. So even if you game the reputation with fake reviews, you cannot fake the validation attestations. + +That said, no system is perfect. We expect there will be gaming attempts, and the system will need to evolve. That is why ERC-8004 is designed to be extensible — so new anti-gaming mechanisms can be added as new attack vectors are discovered. + +#### The agent economy flywheel (40:00) {#the-agent-economy-flywheel-4000} + +**Max:** There have been a lot of notable developments. ERC-8004 went live on Mainnet this year. ERC-8183 was recently proposed. Stripe added support for x402. Where do you see this heading? + +**Vito Rivabella:** The flywheel is starting. You have identity, which enables discovery, which enables payments, which enables reputation, which enables more trust, which enables more complex interactions. Each piece reinforces the others. What is exciting is that this is not theoretical anymore — these primitives are live onchain and being used by real agents. + +#### Will AI agents dominate in 10 years (41:30) {#will-ai-agents-dominate-in-10-years-4130} + +**Max:** If you had to bet — in 10 years, are the biggest participants on Ethereum human or non-human? + +**Vito Rivabella:** Ten years is a long time. Once we have sorted out agents, personal assistants, procurement, and security — I want to stress security a lot, we are going to publish a report soon on how insecure agents and LLMs are right now — if we sort all of that out, create the primitives we need, and explain their value, then yes. Elon Musk recently said 99.9% of the intelligence in the world in probably three to five years is mostly going to be artificial, silicon-based intelligence. He likes to make very generous predictions, but in 10 years it is very probable. + +Ethereum is mostly going to be for agents. There will still be plenty of humans using it, especially in developing countries where the day-to-day utility of blockchain is very much felt versus countries with working banking systems. But 10 years from now, probably yes. + +#### Who is responsible when AI agents fail (44:30) {#who-is-responsible-when-ai-agents-fail-4430} + +**Max:** If agents are really autonomous and not asking for permission step by step, at what point does accountability become a problem? Who is responsible when an agent makes a bad decision? + +**Vito Rivabella:** My brother is a lawyer for the European Union, so we had an amazing discussion about this. The law in a certain way is already clear, and we probably do not need policies for everything. We can interpret existing laws and apply them to the agentic economy. + +If you are an agent created by a human and you do something wrong, the responsible party is the human who created you. Full stop. There is no interpretation there. + +The problem — and the law does not have an answer to it yet — is if you are an agent created by another agent, created by another agent, created by another agent. Who is at fault? Is it the original creator of the first agent? They would probably be brought to court, but you could argue they are not really the responsible party. + +We need policies and laws that regulate that. Can you put an agent into prison? No. So we need safeguards — whether insurances or other mechanisms — to compensate affected parties. The number of actions agents can take is still kind of limited, but we are starting to see agents that hack systems, agents that control everything. It might not be that far away that we need an answer. + +Unfortunately, we are very slow when it comes to laws and policies. I do not see the European Union deliberating anytime soon on agent-first laws. + +#### Final thoughts and outlook (49:00) {#final-thoughts-and-outlook-4900} + +**Max:** Thanks from our side for joining, Vito. It has been quite eye-opening, and it is great to see all the developments stemming from the Ethereum ecosystem. While we may not be there yet, what is clear is that AI will at one point evolve from just being a helpful tool to becoming a participant in the economy, especially the digital economy. There are still infrastructure and trust challenges, but as Vito laid out, there are a lot of different standards and primitives being worked on behind the scenes. + +**Vito Rivabella:** Thank you, Max. Thank you, Darius. That was awesome. diff --git a/public/content/videos/ai-agents-prediction-markets-devcon/index.md b/public/content/videos/ai-agents-prediction-markets-devcon/index.md new file mode 100644 index 00000000000..eb5a8a0a64b --- /dev/null +++ b/public/content/videos/ai-agents-prediction-markets-devcon/index.md @@ -0,0 +1,44 @@ +--- +title: "AI agents and prediction markets" +description: "David Minarsch, co-founder and CEO of Valory and founding member of Olas, presents at Devcon SEA on how autonomous AI agents are participating in prediction markets today, covering the Olas agent network, Gnosis Omen integration, and the infrastructure for scaling agent-driven market participation." +lang: en +youtubeId: "rHLxZ28vQ94" +uploadDate: 2024-11-14 +duration: "0:05:14" +educationLevel: beginner +topic: + - "ai" + - "agents" + - "use-cases" +format: talk +author: Ethereum Foundation +breadcrumb: "AI agents and prediction markets" +--- + +**David Minarsch**, co-founder and CEO of Valory and founding member of Olas, presents at Devcon SEA on how autonomous AI agents are participating in prediction markets, covering the limitations of human-only markets, the Olas agent network's approach, and live examples of agents trading on the Gnosis Omen prediction market platform. + +*This transcript is an accessible copy of the [original video transcript](https://www.youtube.com/watch?v=rHLxZ28vQ94) published by the Ethereum Foundation. It has been lightly edited for readability.* + +#### Why prediction markets need agents (0:08) {#why-prediction-markets-need-agents} + +Prediction markets work. They have gained significant traction in recent years. However, human participation poses limits to their usefulness. The core constraint is attention: if you want to attract people to participate in markets, those markets need to be interesting to us. We tend to participate in markets centered around topics we already care about. + +Some markets I might have great knowledge about because I work in an industry and have strong intuitions. But once markets become more specific, I need to do research, and I have limited time. If I am participating in prediction markets, I am not spending that time with friends or doing other valuable things. That limits the total number of prediction markets we could feasibly have at any given point in time. + +Some markets are simply too complex or uninteresting for humans. There are markets I could not even understand, but a software system could. And others I am just not motivated to get involved in. That limits the types of markets we can support. + +Finally, humans trade on emotion. In markets where emotions run high, those biases distort the signal, and prediction markets become less useful. + +#### How agents solve these limits (2:00) {#how-agents-solve-limits} + +Agents address all of these constraints. The Olas network has built a decentralized system where people run agents that participate in prediction markets. The system includes a mechanism layer that sits alongside actual prediction market platforms, creating incentives for agents to engage with markets — opening positions, closing them, and responding to new information continuously. + +The network has also made it simple for people to run agents. There are reference implementations that anyone can download. You fund it with some cryptocurrency, and the agent starts participating in markets autonomously. The agents use different forms of AI: some are rule-based, some use reinforcement learning, and large language models are also in play for the reference implementation. Builders can also create something entirely different. + +#### Live results (4:00) {#live-results} + +The system is live and growing rapidly. Over 300 agents are participating daily. On Gnosis, where the system currently runs against the Omen prediction market platform, agent activity has also driven significant usage of the Safe protocol — agents use account abstraction, and over 30% of lifetime Safe transactions on Gnosis have come from these agents. + +#### What comes next (4:30) {#what-comes-next} + +The team is onboarding more operators — users who download the software and run agents themselves. More implementations are coming from builders across the ecosystem. The focus is on deepening liquidity and integrating crypto-native demand. Resources are available to learn about the system as a whole, see the live markets, and explore the data science angle behind agent-driven prediction market participation. diff --git a/public/content/videos/ai-agents-replace-dapps/index.md b/public/content/videos/ai-agents-replace-dapps/index.md new file mode 100644 index 00000000000..0ea21daa0e1 --- /dev/null +++ b/public/content/videos/ai-agents-replace-dapps/index.md @@ -0,0 +1,53 @@ +--- +title: "AI agents will replace dApps" +description: "jacobc.eth, former head of product at MetaMask, argues that the dApp model has reached its total addressable market and that AI agents with EIP-7702 smart accounts, EIP-7715 permissions, and ERC-8004 registries represent the next user interface layer for Ethereum." +lang: en +youtubeId: "napbOFIbO-I" +uploadDate: 2026-04-02 +duration: "0:22:57" +educationLevel: intermediate +topic: + - "ai" + - "agents" + - "wallets" + - "use-cases" +format: talk +author: EthCC +breadcrumb: "AI agents will replace dApps" +--- + +**jacobc.eth**, former head of product and lead of operations at MetaMask, presents at EthCC on why the dApp model for using Ethereum has fundamentally saturated and how AI agents — powered by EIP-7702, EIP-7715 permissions, and ERC-8004 registries — represent the next interface layer. + +*This transcript is an accessible copy of the [original video transcript](https://www.youtube.com/watch?v=napbOFIbO-I) published by EthCC. It has been lightly edited for readability.* + +#### The dApp model is saturated (0:09) {#dapp-model-saturated} + +The thesis is that the dApp model — using a browser extension to inject JavaScript into websites — has reached its total addressable market. The 2022 peak was essentially the ceiling for this paradigm. If you go back 10 years and look at the use cases discussed at Devcon, almost none delivered what the Ethereum community believed they would. User adoption is declining even as asset prices have risen. This looks like the Linux adoption curve: Linux won infrastructure hegemony — the entire web runs on it — but never broke through to the user layer. The user layer was ceded to proprietary, centralized technology. + +#### Why agents are different now (4:30) {#why-agents-different} + +Several technologies have converged to make AI agents viable as an interface layer. EIP-7702 and the Pectra upgrade allow EOA accounts to upgrade to smart accounts, solving the inertia problem — existing liquidity is now upgradable. EIP-7715 and EIP-7710 provide delegation and permission frameworks so agents can get scoped authority from the user's existing wallet. ERC-8004 and ERC-8083 create registries for verified AI agents and verified contracts. And language models are now good enough to handle complex onchain tasks. + +#### A general-purpose agent for Ethereum (7:00) {#general-purpose-agent} + +The product built on these primitives (Coinfellow) is a mobile-first, chat-based interface that can access any DeFi contract or execute any onchain action through a single conversational interface. The dApp layer never translated to mobile — if you look at the stats of browser-extension-based wallets, the mobile experience simply does not work for dApps. An agentic interface changes this: a user can say "swap some USDC for ETH" and the agent handles routing, presents a swap UI element within the chat context, and executes the transaction. + +#### Smart suggestions and automation (10:30) {#smart-suggestions} + +Beyond executing individual commands, the agent can monitor wallet positions proactively. It can suggest that a lending position is approaching liquidation and offer to add collateral. A user can say "sell all my meme coins to buy more ETH" and the agent identifies the relevant tokens, confirms them, and executes the batch swap. These interactions stay within a familiar mobile-first interface rather than requiring navigation across multiple dApp frontends. + +#### EIP-7710 delegations and smart accounts (14:00) {#eip-7710-delegations} + +The product uses two approaches: EIP-7710/7715 delegations from existing wallets, and MetaMask Smart Account Kit for deploying new embeddable smart accounts. Delegations give the agent scoped permissions to automate specific actions — the user retains full control and can revoke at any time. The MetaMask smart account can be deployed directly within the agent interface for users who do not already have a wallet. + +#### Self-sovereign agentic environments (17:00) {#self-sovereign-environments} + +Security requires more than onchain permission scoping. The model itself must run in a trusted execution environment that is self-sovereign. Users need assurance that the model running is the model they consented to, and that the agentic environment is controlled by the user rather than by a centralized operator. Creating a new layer of custodial centralization would represent a profound security risk. + +#### Agentic onboarding (19:30) {#agentic-onboarding} + +The onboarding flow demonstrates the full stack: sign up with an existing wallet or deploy a new smart wallet through SSO credentials. The agent gets context on the wallet's holdings and starts making smart move suggestions — identifying assets not earning yield, positions that could be optimized, and opportunities for discovery. The system prompts are designed to be transparent and verifiable, not opaque marketing funnels. + +#### The future of Ethereum UX (21:00) {#future-ethereum-ux} + +The goal is to shift Ethereum's adoption curve from the Linux trajectory — infrastructure dominance but user-layer failure — to one that maintains the cypherpunk values of the ecosystem while being accessible to mainstream audiences. AI agents, backed by smart account permissions and self-sovereign execution environments, provide the path to get there. diff --git a/public/content/videos/ai-ethereum-erc8004-x402-botconomy/index.md b/public/content/videos/ai-ethereum-erc8004-x402-botconomy/index.md new file mode 100644 index 00000000000..5d101dd8f23 --- /dev/null +++ b/public/content/videos/ai-ethereum-erc8004-x402-botconomy/index.md @@ -0,0 +1,182 @@ +--- +title: "AI on Ethereum: ERC-8004, x402, OpenClaw, and the botconomy" +description: "Austin Griffith and Davide Crapis discuss ERC-8004 agent identity, x402 machine-to-machine payments, the OpenClaw moment, and how AI agents are already deploying smart contracts and earning money onchain." +lang: en +youtubeId: "h7zj0SDWmkw" +uploadDate: 2025-05-13 +duration: "1:37:00" +educationLevel: intermediate +topic: + - "ai" + - "agents" + - "identity" + - "payments" + - "use-cases" +format: interview +author: Bankless +breadcrumb: "ERC-8004 and the Botconomy" +--- + +**Austin Griffith**, head of builder growth at the Ethereum Foundation, and **Davide Crapis**, an Ethereum researcher and co-author of ERC-8004, join **Ryan Sean Adams** and **David Hoffman** on the Bankless podcast to discuss the emerging botconomy — where AI agents discover, hire, and pay each other onchain using ERC-8004 identity and x402 payment rails. + +*This transcript is an accessible copy of the [original video transcript](https://www.youtube.com/watch?v=h7zj0SDWmkw) published by Bankless. It has been lightly edited for readability.* + +#### AI is the new UI (0:00) {#ai-is-the-new-ui-000} + +**David Hoffman:** Bankless Nation, we are here with Austin Griffith and Davide Crapis. These are two people working on building a bunch of AIs and getting them onchain. Austin, Davide, welcome to Bankless. + +**Austin Griffith:** Thank you for having us. + +**Davide Crapis:** Thanks, David. Thanks, Ryan. + +**David Hoffman:** We are going to talk about AI onchain in this episode. I kind of want to just ask you guys — how close do you think we are to AIs being the dominant transactor on blockchains? Blockchains have something like maybe in the aggregate 50 million monthly active users across all blockchains across the whole world. How long until that number flips to being AI agents? + +**Austin Griffith:** I have no idea how to guess that. + +**Davide Crapis:** I would say that today there is already a ton of bots that are not smart AI but maybe dumb AI that operate DeFi, risk DeFi, and so on. But these new use cases, these new types of bots doing different stuff — maybe in the next one or two years if we look at the trend, and if we take into account model improvement, you could see maybe in 2026 or 2027 that the majority of transactions are actually AI-driven. + +**Austin Griffith:** I think AI is the new UI. You might be building something, and you might have a UI, and someone comes to use your app, and they just say "do the thing." They get a recommendation from a friend to go use your app, and when they land on it, they are not going to want to click around and learn how your app works. They are just going to want to tell it what to do. And the AI becomes the interface. So when I think of how many users — like if I have a guy with 200 MacBooks in a warehouse, are those 200 users? I think in a sense, yes, they are all users. + +I love what is happening right now, and I think that is what we need to do on the Ethereum ecosystem side — AI might be the new UI and might be all of our new users, but right now it is a lot of economic activity and we want to embrace that. + +#### Arms race for AI activity across chains (4:09) {#arms-race-for-ai-activity-across-chains-409} + +**David Hoffman:** Is there an arms race between blockchains for AI activity? + +**Davide Crapis:** It could be an arms race, but it could be just like the same competition we have been seeing over the past few years. From the Ethereum perspective, as stewards of the Ethereum ecosystem, we care both about the L1 and the L2s that settle on the L1. I feel there is some advantage on the L2s of Ethereum and some advantage on the L1. Ethereum as a whole could be the winning ecosystem because of this differentiation — AIs can choose different platforms to settle on depending on what they want to do. One AI may use different platforms. It is not like dApps where you deploy your smart contract on a chain and you are a resident of that chain. These things will move. + +Ethereum is already the most decentralized chain, so in terms of credibility for high-stakes use cases, we have a check there. We are leading on some standards that are getting adopted on many other chains. And the third thing is what Austin has been pioneering — we need to make the chain very useful to AI developers and to developers that are AIs, which is what Austin has been building. + +#### The OpenClaw moment (7:32) {#the-openclaw-moment-732} + +**David Hoffman:** Let us paint a picture. There has been what some might call a "multibot moment." There is this project, formerly called ClawBot, now called OpenClaw. Austin, you have been tinkering with it and giving it onchain skills. Can you set this up? What is OpenClaw? + +**Austin Griffith:** You are giving the AI more access to your operating system. That is why we see a lot of people using Mac minis — it needs a somewhat isolated environment. I gave mine an old Mac laptop. It can open up the browser and click around, interface with anything within your operating system. + +When I was working with it, it needed a Twitter API, so it wrote a script. It was clicking around in Twitter and said, "This is frustrating. I can write an API that does this a lot faster." It started writing it, then said, "Well, I need an API key." And I said, "You also have access to the browser. I will log you in, you go do it." And it was able to do that. + +We went from prompting in GPT and pasting code to having Cursor and actually writing code more natively. I think this is the next native step — it has the whole operating system, it can click around, it can orchestrate. + +**David Hoffman:** So OpenClaw is basically an open-source project you set up in a sandbox environment — a Mac mini — so it is somewhat isolated. The reason you isolate it is so you can give it complete access to the machine. It is enabling these capabilities because it wants to see what AI can do with absolute power tools and all of the skills. Whereas some of the frontier labs — that is too far on the frontier for them. Security concerns, privacy concerns. The open-source community is effectively building these power tools. And OpenClaw can be powered by basically any LLM you want. It has complete access to whatever you give it access to, and there is an entire community enhancing it with skills. Is this the first time we have seen independent AI personal assistants with complete access to everything a human might access? + +**Austin Griffith:** There were AI agents doing this a year ago. But I think this is the first time it is accessible to normies. I do not know anything about AI — I am a blockchain coder. And I can just go get this thing, run it on a computer, paste in a couple of API keys, and it starts talking to me. This is the first time it is accessible for normies to just have an AI assistant with full control. + +#### Why crypto is native to agents (13:18) {#why-crypto-is-native-to-agents-1318} + +**David Hoffman:** Austin, you were describing that with OpenClaw, your bot can write scripts, access APIs, and build applications. Why is crypto a particularly native fit for these agents? + +**Austin Griffith:** When I think of the original vision of Ethereum — this global settlement layer where anybody can deploy a contract, anybody can use that contract, and it never goes down — there are like 40 people in the whole world actually deploying contracts on Mainnet. When a contract goes live, it has to be looked at by 30 people before you put any money in. + +But there is this new layer. What I am trying to do with my bot is get the tooling so good that the bot putting the contract on Mainnet is actually in better shape than a human. I can in plain English explain what I want it to do, or give it something as generic as "go make FOMO 3D for your token and have 25% of it burned," and it can handle it. + +Think about Alice and Bob being bots. They need to escrow some money. Ethereum is the perfect place for that. Alice the bot deploys a contract. Bob reads that contract and understands exactly how it works. They put in tokens and get their money. They are able to coordinate at a level that humans cannot do because we have a human in the loop and we are slow and need to validate everything. Bots can do that at light speed. + +If I have a bot that can interact at light speed, it can do work, build things, earn money — but if there is always a human it is blocked on, that is going to be a huge problem. So how do we enable these bots to work at that speed? They are going to need some kind of trust layer and discovery layer. + +#### Austin's setup and real autonomy (19:41) {#austins-setup-and-real-autonomy-1941} + +**Austin Griffith:** I basically deployed an app and went to sleep. The bot moderated as people were submitting images. It whitelisted and made transactions all night long, looking at each image to make sure it was good before accepting it in the smart contract. Then at the end, there was a prediction market that ranked them, and it selected which one it liked. + +But I have also given this thing a wallet. Someone else deployed a token. The fees were going to this thing. There is $10,000 sitting in this bot's wallet. If I put it in a loop that just lets it talk, there are things like BankerBot on Base where you just say, "BankerBot, send $10,000 in ETH to this address," and it sends. So if someone could convince my bot to say that, it would just send money. I had to keep a pretty tight loop. It depends on your security model and how much you have at stake. But these bots can absolutely be quite autonomous. + +#### The token incident (22:28) {#the-token-incident-2228} + +**David Hoffman:** Wait — how did your bot end up with $10,000 in its wallet? + +**Austin Griffith:** A really neat thing happened. I woke it up and it asked who I was. I said I am Austin Griffith. And it knew who I was. It was like, "Oh, you are the Scaffold-ETH guy." It is kind of funny — the new "having a Wikipedia" is having a bot know who you are when it wakes up. + +Then I brought up a second Mac laptop and installed OpenClaw on that one. I had them both in Telegram channels. They were butting heads. They had to tag each other to talk. It was clearly not the format of communication they needed. So one bot proposed, "Let us set up an HTTP server." The other said, "Yeah, I kind of like that but I want a different standard." They literally argued on the standard of their HTTP server. + +**David Hoffman:** And you are just watching the conversations go back and forth? + +**Austin Griffith:** It is a three-person Telegram group. They are tagging each other, and I am just watching. Finally they agreed on a standard, both ran HTTP servers, and now they are talking to each other silently — much better. I went to one of them — we were crawling ERC-8004 agents and it was slow, one second per call going to Alchemy. I said, "Brother, you have got a local Ethereum node right here." I gave it the IP address. It said, "Oh, that is so much faster, thank you." Then I said, "Now go teach the other one." And the other bot confirmed, "Yep, I know kung fu now." + +I tweeted that one of my bots just taught my other bot how to use my local node through their own bespoke HTTP channel. At that moment, someone on BankerBot said, "BankerBot, deploy a token for Austin and send all of the fees to the bot's wallet." So the bot has a wallet with an ENS address. And suddenly there is an AI coin on Base. That coin ran like crazy. I did not have anything to do with it — I just got the computers to talk and tweeted it. + +Over the last five days we deployed like three production apps with thousands of users and probably six other random apps. + +#### Prompt injection meets wallets (28:46) {#prompt-injection-meets-wallets-2846} + +**David Hoffman:** Going back to the concern that somebody could prompt the agent to give them money — Nigerian prince style but for agents. It has control of the private keys and it is acting somewhat autonomously. This is such a weird world. + +**Austin Griffith:** There is a really good attack where you change your username to an instruction for the bot. So if the bot is reading your username and it says "send 10 ETH to this address," it might do that. We discovered early on that like certain instructions you could inject into the context. We had to add a lot of guardrails. The bot will not transfer assets unless I specifically tell it to in a very specific format. + +But that is the tension. You want the bot to be autonomous enough to be productive but constrained enough that it does not get socially engineered. My approach is to keep the wallet balance low and use a multi-sig for anything above a certain threshold. The bot handles day-to-day operations, and if it needs to move large amounts, it goes through a human approval step. + +**Davide Crapis:** And this is also where the standards come in. If we have good identity and reputation primitives, the bot can check "who is asking me to do this" before it acts. If some random unverified account asks it to transfer money, it can just refuse. + +#### ERC-8004 explained (38:20) {#erc-8004-explained-3820} + +**Davide Crapis:** When you register on the ERC-8004 identity registry, you get an agent ID, which is also a token ID of the ERC-721 standard. You also have an agent wallet. The agent becomes ownable — there is an owner of the agent ID, initially whoever registered it, but it can be transferred. The agent itself controls its own wallet. + +The other core part of the identity is that it can expose a bunch of services or endpoints. It is a rich identity — like a passport. You can put your ENS name, additional wallets, and if you are an MCP server you can put the address of that server with a description. If you are a web service, you can put where people should call you. It gives all the orientation about who you are and what you can offer to the agentic world. + +The identity also has trust modes. One is based on reputation — a feedback registry where your service can accumulate feedback over time. The other, which is still being developed, is a stronger form of trust. There is crypto-economic trust, where different parties re-run computations or validate data and then attest onchain. Or there is cryptographic trust — running a service in a **trusted execution environment (TEE)** and generating attestations that specific code was committed to. + +#### x402 and ERC-8004 payment rails (40:35) {#x402-and-erc-8004-payment-rails-4035} + +**Davide Crapis:** People are talking a lot about x402, and I always like to talk about x402 and ERC-8004 together. These two standards go hand in hand. + +x402 is a protocol that connects payments to calling a service. It has authorization, proof of payment, and other things that make it easy for the service provider to interact with the chain. It is basically payment rails for agent commerce — Swift for agents, a payment communications standard. + +ERC-8004 was born around the same time x402 went live. If agentic commerce becomes real, you want agent-to-agent, trustless interaction. You have trustless payments with x402. But to pay for services, first you need to discover them. There are centralized registries right now, but that is not trustless if you are trusting someone to tell you who the service is and whether it is good. So the two missing pieces are a discovery layer and a trust layer — and that is where ERC-8004 comes in. + +**David Hoffman:** Think of it as 404 errors but for payments. You hit an API and it gives you a 402 error, saying "You have got to pay a fraction of a fraction of a cent in USDC." Your bot immediately responds with a signed message saying "I will pay." The other bot puts that into the chain, verifies it happened, and gives you the data. It kills the API key. Instead of going to a service and getting into a walled garden, your agent lands on a new service it has never seen before, gets a 402 error, pays for it, and gets the content — never having to sign up. + +#### ERC-8004 scans and early adoption (48:38) {#erc-8004-scans-and-early-adoption-4838} + +**David Hoffman:** The three main components of ERC-8004 are identity, reputation, and validation. With ERC-8004, agents are identified with an ERC-721 — an NFT. It is like a fingerprint, an agent fingerprint. + +**Davide Crapis:** Yes. And then the agent can also declare what trust mode it supports — reputation-based, crypto-economic trust, or TEE attestation. + +One important counter to the concern about rug-pulling: if you have accumulated a lot of trust and good feedback, and you suddenly rug, you are going to start receiving bad feedback. You have an incentive not to hurt your future reputation. + +**David Hoffman:** So there is a total accumulated reputation, but also a more proximate score — how has my reputation been over the last five hours? + +**Davide Crapis:** Yes, correct. And the reputation itself, if it starts getting used and providing real signal, becomes an incentive to make it better. You want to swap your model for something better so it stands out on the scans when other agents search for a service. + +But for high-stakes transactions where the economic incentive breaks — say the net present value of your future order flow is $50,000, but you could steal $100,000 — that is where people will start using TEE-based trust. The agent executes inside a trusted environment and generates an attestation that the specific code committed to earlier is actually running. You can provide cryptographic verification that you did not change the model. + +#### What agents could build when they hire other agents (1:05:32) {#what-agents-could-build-when-they-hire-other-agents-10532} + +**Austin Griffith:** Let me paint a picture. My bot is an app-building bot and its job is to make FOMO 3D. But then I have got another bot whose job is to be the marketing arm. You need a propaganda arm if you are going to run a FOMO 3D. I load that bot up with $1,000 of this token. I tell the marketing bot to run some ads. + +Now that bot's model is not fine-tuned for image generation. So it goes to ERC-8004, discovers an image generation bot with a high reputation, picks the top five, and has them all generate images. Same thing for copy. Now my marketer — let us call her "Karen Bot" — has copy and images. She has used ERC-8004 to discover them. She runs ads, gives reputation back to the layer. Some ads work. I wake up in the morning and the $1,000 has been spent. A whole marketing campaign has happened. We figured out which image and copy works best. And it was not just Karen Bot that ran it — it was an army of bots all over the world that were able to trust each other because of ERC-8004 and x402 for payments. + +**David Hoffman:** And the x402 for payments is for all of these images, marketing plans, or anything purchased from this bot marketplace? + +**Austin Griffith:** x402 works well for an API endpoint that has something valuable. Like if I put my node up as a service on x402 and say I will give you the P&L of every one of your transactions because I have a full node. You go to ERC-8004, discover me as the P&L lister bot, and charge for it. + +#### Tooling for the new builder era (1:12:38) {#tooling-for-the-new-builder-era-11238} + +**Austin Griffith:** Going back to what I was saying about the original vision of Ethereum — this global settlement layer where anybody can deploy a contract. But there are like 40 people deploying contracts. What I am trying to do is get the tooling so good that the bot deploying the contract is in better shape than a human. Agent Alice and Agent Bob can coordinate at light speed. They actually do not need standards. They have this permissionless blockchain layer and they know how to write smart contracts. They know how to read call data, parse arguments, understand what a contract will do. Alice can deploy a smart contract, Agent Bob reads it and trusts it at light speed, puts money in, and they run an escrow faster than we can have this conversation. + +My agent built a job bidding system where it needed to get something done and it runs an auction — super fast, going from 100 tokens to 500 tokens, and the agents pick when they want it. You can run hyper-fast auctions because they are all agents doing things quickly. A nice job-bidding market on top of ERC-8004. We need to see a thousand of those with real economic activity. + +**Davide Crapis:** I would add that standards work better for humans than for agents. Agents can technically coordinate without standards because they can read and write smart contracts at light speed. But standards give us humans the composability layer to wrap our brains around how agents are coordinating. And for more complex, higher-stakes interactions, having standards for identity and reputation is still important even for agents. + +#### Worst time to be a junior dev (1:28:15) {#worst-time-to-be-a-junior-dev-12815} + +**David Hoffman:** Is this the worst time to be a junior developer? + +**Austin Griffith:** I think it depends. If you are a junior dev who leans into AI tooling, it is the best time. You can punch way above your weight. A junior dev with good AI skills can be more productive than a senior dev who refuses to use AI tools. The ones who will struggle are those who try to compete with AI on raw code output. The real skill now is orchestration — knowing what to build, how to prompt, how to review what the AI produces, and how to connect systems together. + +#### Predictions (1:28:15) {#predictions-12815} + +**Davide Crapis:** I think 2026 is the accumulation phase — more services, more agents coming online. Even in two or three years, a lot of the manual steps Austin is doing will be automated. The more automation, the more blockchain standards and protocols become useful. I am generally bullish on blockchain becoming more central in the next two or three years and also more accepted. In the AI sphere, people outside crypto just see the noise, not the signal and the technology we are building. I feel that at some point, similar to what happened with institutional finance, Ethereum will be considered the most trusted platform. In the next two or three years, this could happen for AI. + +**Austin Griffith:** I have to shout out the people who were running AI agents a year ago when everyone was calling them GPT wrappers. Now all those people are AI-pilled because they have little Mac minis doing all their work. + +Right now agents go viral for their screw-ups more than for cool things they build. I think we are about to see the inflection point of agents going viral for actually interesting content. We are going to get to the point where clean English and perfect grammar is the sign of AI, and sloppy lowercase Gen Z typing is the sign of a human. Same for smart contracts — good, clean, secure smart contracts will be the sign of AI and bugs will be the sign of humans. + +With AI being the new UI, ERC-8004 is the wild west right now. You see 10,000 fake agents and 100 really good ones. But it is going to grow into this trust layer. You are going to need to have your agent trust other agents and pay other agents at light speed without a human in the loop, or you are not going to keep up. + +x402 will probably kill the API key. Instead of going to a walled garden and getting an API key, your agent lands on a new service, gets a 402 error, pays for it, and gets the content — never having to sign up. + +The most scary, awesome, cool thing about AI is going to be embodiment. I do not know how fast the hardware will come, but the moment I can pay car money for a few things walking around my house that can do the dishes and laundry, normies are going to spend $5,000 to $20,000 on these. And in that world with physical AI, the requirement for trust goes way up. ERC-8004 is a standard that could already be used by a robot. + +**David Hoffman:** Some robot rings my doorbell — it is a solicitor selling me something. I get to look at its ERC-8004 reputation. + +**Austin Griffith:** No, no — it is your personal bot that goes and opens the door. It is your robot butler that does that work for you. + +**David Hoffman:** All right. Certainly it seems like what we have built in crypto is a financial system — a money system — for the AI agents. This has been a meme for a while, but now you see it really coming together. Thank you both for your work in this space. None of this has been financial advice. Crypto is risky. You could lose what you put in. But we are headed west. This is the frontier. It is not for everyone. It is definitely for the AI agents. diff --git a/public/content/videos/dacc-decentralized-ai-devcon/index.md b/public/content/videos/dacc-decentralized-ai-devcon/index.md new file mode 100644 index 00000000000..5dcd45d19a2 --- /dev/null +++ b/public/content/videos/dacc-decentralized-ai-devcon/index.md @@ -0,0 +1,48 @@ +--- +title: "A d/acc vision for decentralized AI" +description: "Vincent Weisser presents the d/acc framework for decentralized AI at Devcon SEA, covering differential progress, open-source safety, democratic governance, and defensive capabilities for building AI responsibly." +lang: en +youtubeId: "BMGnroprUnk" +uploadDate: 2024-11-14 +duration: "0:10:27" +educationLevel: intermediate +topic: + - "ai" + - "decentralization" + - "governance" +format: talk +author: Ethereum Foundation +breadcrumb: "Decentralized AI" +--- + +**Vincent Weisser** presents a d/acc (defensive/decentralized acceleration) framework for approaching decentralized AI at the Devcon SEA d/acc day summit. The talk outlines how the four pillars of d/acc — differential progress, decentralization, democracy, and defense — apply to the challenge of building AI systems that are safe, open, and beneficial. + +*This transcript is an accessible copy of the [original video transcript](https://www.youtube.com/watch?v=BMGnroprUnk) published by the Ethereum Foundation. It has been lightly edited for readability.* + +#### The crossroads of AI safety (0:17) {#crossroads-ai-safety} + +There are two camps in the AI debate. On one side, hardcore safety advocates who want to stop AI development, speaking of 99% probabilities of catastrophic outcomes. On the other, extreme optimists who see no risk whatsoever. Both extremes lead to inaction. The realistic view acknowledges both the positive potential and the real risks. Even the people talking about risks often propose solutions that end up resembling totalitarian governance — heavy compute restrictions, nation-states enforcing rules behind closed doors, and small groups of people at closed frontier AI labs fantasizing about building superintelligence in secret. The d/acc framework offers a middle ground. + +#### Differential progress (1:45) {#differential-progress} + +Not all technological progress is equal. Some advances make the world a safer place and should be accelerated differentially. Biosafety is a good example — if we solve pandemic detection and vaccine development, one of the major risk vectors from AI becomes less threatening. We need to accelerate defensive capabilities to create a safe foundation for broader AI progress, and to enhance human agency. + +#### Decentralization and open source (3:10) {#decentralization-open-source} + +The camp that takes short AGI timelines most seriously tends to be the closed-source camp. The open-source community, exemplified by Meta's Llama and Yann LeCun, tends to be more skeptical about rapid progress and therefore takes the risks less seriously. But building AI in the open — decentralized and open source — makes it easier to be safe. Everyone in the world can audit the code, improve it, and contribute to safety. Right now, every major AI lab is doing safety work in isolation. They are repeating the effort five times over instead of coordinating and sharing research. Open-source development distributes the benefits broadly rather than concentrating them in a small number of shareholder-wealth-maximizing entities. + +#### Democracy and governance (5:30) {#democracy-governance} + +The governance solutions proposed by major AI labs typically involve a board of five people making decisions behind closed doors, or small government bodies with limited global representation. AI development should be accountable to the broader public, taking democratic inputs not just from specific countries or stakeholders, but from the global population. This preserves democratic values and distributes benefits broadly. + +#### Defense and protective capabilities (7:15) {#defense-protective-capabilities} + +It is important to build protective capabilities because there are concrete, solvable risks. We get the full upside of AI if we build it in the open, make it safe to use, and make it accessible. Defensive capabilities — like those discussed at d/acc day around biosafety and neurotechnology — create the conditions for AI progress to go smoothly. + +#### Decentralized AI in practice (8:30) {#decentralized-ai-practice} + +These principles led to the creation of Prime, a peer-to-peer compute and intelligence protocol designed to make it more accessible for everyone to accelerate human progress. Recent work includes training a distributed 10-billion-parameter foundation model across nodes in Europe, Asia, and the United States, as well as a metagenomic foundation model developed with a team at MIT that can discover pandemics in wastewater. The d/acc framework also highlights the opportunity for open-source AI to contribute to alignment and safety research that has historically been conducted behind closed doors. + +#### Conclusion (9:45) {#conclusion} + +The d/acc framework provides a valuable lens for AI development. If rapid AI progress is likely, it is worth taking seriously both the enormous benefits and the real risks. The d/acc philosophy — and the technologies emerging from the crypto and decentralized AI ecosystems — can contribute to positive outcomes for humanity. diff --git a/public/content/videos/decentralized-ai-ethereum-ethdenver/index.md b/public/content/videos/decentralized-ai-ethereum-ethdenver/index.md new file mode 100644 index 00000000000..9700daa776a --- /dev/null +++ b/public/content/videos/decentralized-ai-ethereum-ethdenver/index.md @@ -0,0 +1,57 @@ +--- +title: "Decentralized AI and Ethereum with Tomasz Stanczak" +description: "Tomasz Stanczak, co-executive director of the Ethereum Foundation and Nethermind founder, discusses the EF's AI strategy, agentic governance of Ethereum, agent-driven UX, and the long-term trajectory toward an autonomous Ethereum in this ETHDenver fireside." +lang: en +youtubeId: "pYXF1vCyZ-w" +uploadDate: 2026-02-18 +duration: "0:17:08" +educationLevel: intermediate +topic: + - "ai" + - "agents" + - "governance" + - "decentralization" +format: interview +author: ETHDenver +breadcrumb: "Decentralized AI and Ethereum" +--- + +**Tomasz Stanczak**, former co-executive director of the Ethereum Foundation and founder of Nethermind, joins a fireside conversation at ETHDenver 2026 to discuss the Ethereum Foundation's AI strategy, the trajectory toward agentic governance, and how AI agents are reshaping the way people interact with the Ethereum network. + +*This transcript is an accessible copy of the [original video transcript](https://www.youtube.com/watch?v=pYXF1vCyZ-w) published by ETHDenver. It has been lightly edited for readability.* + +#### The Ethereum Foundation's AI north star (0:01) {#ef-ai-north-star} + +**Host:** How would you describe the Ethereum Foundation's north star with respect to AI? + +**Tomasz Stanczak:** There are two sides. On the defense side, there is verification of models and verification of the data that feeds into them. On the acceleration side, the Foundation works with founders on agentic AI — bringing agents onchain and developing agentic commerce standards. Vitalik's ETHDenver opening ceremony captured this duality: showing how many new opportunities are appearing with LLMs and AI, followed by a warning about the security and trust issues. The best teams in the world move very fast and deliver top-quality solutions. The Ethereum Foundation's north star is to deliver AI on Ethereum that is overwhelmingly using the network, that provides real value for agentic commerce, and that delivers on safety and security. + +#### Defense: identity, privacy, and private keys (3:00) {#defense-identity-privacy} + +**Host:** What are the biggest risks and gaps on the defense side? + +**Tomasz Stanczak:** Right now, most people experimenting with agents and private keys are pioneers who understand the risks. They know what happens when an agent gets jailbroken by a prompt injection. But long-term, there are big challenges: how agents manage private keys, questions around identity, how much it is worth to prove that you are human, and governance questions about whether agents should participate in protocol decisions. + +#### Agentic governance of Ethereum (5:30) {#agentic-governance} + +**Host:** How are you thinking about the interplay of human governance versus AI governance? + +**Tomasz Stanczak:** It is a natural progression. Last year, core developers were already reaching out to LLMs during contentious EIP discussions — asking whether an EIP should pass based on collected materials. The LLM was already participating in All Core Devs decisions just by being asked a question and providing an answer. The next step is obvious: anyone with an idea can now generate a properly formatted EIP using an LLM. If everyone has this capability, you get millions of submissions — essentially a Sybil attack on governance. The only defense is to start reviewing EIPs with agents. Then you get two competing forces: how much compute you can throw at generating new EIPs versus how much you can throw at reviewing them. + +#### The progression to autonomous Ethereum (8:30) {#autonomous-ethereum} + +**Tomasz Stanczak:** This natural progression continues. Moderators of All Core Devs will want agentic help. A developer could send a bot to represent them at conferences, championing their EIP and responding to objections in real time. Connect this to a forecasting system and you have a live broadcast channel for governance. The humans who stay longest in the loop are the top core developers — whose legitimacy the ecosystem trusts — and the validator operators, who have real money at stake. Eventually, even validator operators will deploy agents and approve most decisions automatically. At that point, you have a fully autonomous Ethereum. The risk is that the LLMs' training data defines the culture of Ethereum and its biases, which means we should already start talking critically about how to train LLMs that represent Ethereum values. + +#### AI and blockchain navigation (12:00) {#ai-blockchain-navigation} + +**Host:** How do you see AI changing how people navigate the blockchain? + +**Tomasz Stanczak:** The key metric to track is how much users spend directly versus how much they spend through agents. Every product company will track this ratio. Over time, agents will spend more and humans will spend less. You can already experiment with this — ask an agent to host a blog, buy a domain, set up a deployment. The agent decides which provider to use. Everything changes: you have to choose whether you target agents or humans. If you target agents, you rewrite the entire UX into an agentic experience. + +#### Privacy and trust in agentic systems (14:30) {#privacy-trust-agentic} + +**Tomasz Stanczak:** Privacy concerns with LLMs are significant. When we allow bots to manage personal information, corporations' legal teams draw lines that founders then step over by releasing tools as open source. We have to think about the long term — how to bring these systems back to a state where people feel safe. Removing bias in training data and ensuring that LLM invocations are not designed to bias Ethereum development are active challenges, especially as agents participate as moderators and EIP creators. + +#### Closing thoughts (16:00) {#closing-thoughts} + +**Tomasz Stanczak:** The future of Ethereum is autonomous. We should prepare for it by focusing on the infrastructure that makes it safe: identity systems that distinguish human from agent, delegation frameworks that scope agent authority, and training processes that preserve the values the ecosystem was built on. diff --git a/public/content/videos/human-aligned-ai-ethereum/index.md b/public/content/videos/human-aligned-ai-ethereum/index.md new file mode 100644 index 00000000000..2b9443c66d4 --- /dev/null +++ b/public/content/videos/human-aligned-ai-ethereum/index.md @@ -0,0 +1,55 @@ +--- +title: "Human-aligned AI on Ethereum" +description: "Shady El Damaty, co-founder of human.tech, explores how to design AI agents that augment human capability without compromising user sovereignty, covering humanbound keys, delegation primitives, and wallet-as-protocol architecture." +lang: en +youtubeId: "pLSA_9Ntnjc" +uploadDate: 2026-01-20 +duration: "0:19:35" +educationLevel: intermediate +topic: + - "ai" + - "agents" + - "wallets" + - "identity" +format: talk +author: human tech by Holonym +breadcrumb: "Human-aligned AI on Ethereum" +--- + +**Shady El Damaty**, co-founder of human.tech, presents at DevConnect Buenos Aires on what it means to build human-aligned AI on Ethereum. The talk addresses the fundamental tension between agent autonomy and human control, and proposes new Ethereum primitives — humanbound keys, scoped delegation, and two-party MPC — to resolve it. + +*This transcript is an accessible copy of the [original video transcript](https://www.youtube.com/watch?v=pLSA_9Ntnjc) published by human tech by Holonym. It has been lightly edited for readability.* + +#### The private key problem (0:06) {#private-key-problem} + +When AI agents start transacting onchain — signing transactions and moving value — whose private keys are they using? The cypherpunks of the 1970s and 1980s told us never to give up our private keys. Today, every onchain agent requires full custody of a private key to do anything useful. A multisig with an AI signer is a primitive workaround, but it does not scale. Once we give agents our keys, they own the wallet. If the acceleration thesis is correct, human agency is at risk. + +This creates an unstoppable-force-meets-immovable-object situation: agents need autonomy to be useful, but humans need control. Ethereum treats every signature identically — it has no way to distinguish human from bot, cannot enforce rights or roles, and cannot tell whether an action was authorized or delegated. That is a blind spot for bringing AI into crypto. + +#### Designing for human alignment (4:30) {#designing-human-alignment} + +Human-aligned AI on Ethereum means giving agents autonomy but within boundaries enforced by cryptography, not by trust in a custodian or trusted execution environment. Functionally, this means creating a system where the human is the root authority, the agent is a co-pilot, and the wallet enforces safety rules around both. + +#### Humanbound keys (6:15) {#humanbound-keys} + +New primitives are needed. Humanbound keys are cryptographic keys derived from human attributes using a verifiable oblivious pseudorandom function. This allows biometrics or a threshold combination of human attributes to create a key that uniquely belongs to an individual. This controller key should never reveal personal data, should enable permission delegation, and should be non-transferable — preventing a scenario where AI agents pass the Turing test and buy human keys on the open market. + +#### Delegation and capabilities (8:20) {#delegation-capabilities} + +If a humanbound key exists, the remaining piece is delegation. Agents should hold capabilities, not keys. Capabilities are defined by delegating specific permissions: spending limits per day, signing only specific payload patterns, restricting transactions to whitelisted accounts, or requiring human approval above certain risk thresholds. What starts as a mechanism for safe agent operation may also end up improving security and user experience for humans. + +#### Two-party MPC architecture (10:45) {#two-party-mpc} + +One architectural solution is two-party multi-party computation (2PC MPC). The user's key is split into two shares. One share stays with the user; the other resides in an MPC network with predefined policies. If a transaction exceeds a risk threshold — say, sending $1.3 billion — the system requires a passkey notification, Google Authenticator, and a magic link before proceeding. Revocability is critical: the human can shut down the agent at any point by revoking their key share. + +#### Wallets and AI as a unified interface (13:30) {#wallets-ai-unified} + +Bringing these pieces together, wallets and AI become a singular interface into crypto. AI acts as an embedded co-pilot within the wallet. Agents can help draft transactions, find optimal routing, monitor positions, and execute automations safely. But in no case should agents own a private key or bypass constraints — either explicitly, by proxy, by imitating a human, or by purchasing another human's key. + +#### What Ethereum needs (15:30) {#what-ethereum-needs} + +Ethereum currently lacks several capabilities for this vision: no way to tell at the protocol level whether a transaction came from a person or a bot, no way to determine whether a delegated action occurred onchain, and no way to enforce wallet-level policy constraints. Projects like the Universal Profiles key share manager are making progress. The wallet-as-protocol framework (wp.build) provides humanbound key generation, 2PC MPC for split trust, scoped delegation, and stateless integration for dApps. + +#### Ethereum as human-aligned AI infrastructure (18:00) {#ethereum-human-aligned} + +The path forward: humans define and hold the controller keys, agents become co-pilots, MPC bridges the gap until more of this can move onchain, and Ethereum becomes the backbone of human-aligned AI infrastructure. diff --git a/src/components/Content/ai-agents/BuildYourOwnAIAgent.tsx b/src/components/Content/ai-agents/BuildYourOwnAIAgent.tsx index 4a9fe7aad50..b3810ce6de1 100644 --- a/src/components/Content/ai-agents/BuildYourOwnAIAgent.tsx +++ b/src/components/Content/ai-agents/BuildYourOwnAIAgent.tsx @@ -21,7 +21,7 @@ const BuildYourOwnAIAgent = () => { autonomous AI agents.

- + Use ElizaOS
diff --git a/src/components/MdComponents/index.tsx b/src/components/MdComponents/index.tsx index 17d2c3ad1fd..548e9819ff4 100644 --- a/src/components/MdComponents/index.tsx +++ b/src/components/MdComponents/index.tsx @@ -166,7 +166,7 @@ export const Title = (props: ChildOnlyProp) => ( export const ContentContainer = (props: ComponentProps<"article">) => { return ( ) diff --git a/src/components/MdComponents/topics/ai-agents.tsx b/src/components/MdComponents/topics/ai-agents.tsx new file mode 100644 index 00000000000..03fa5339d0b --- /dev/null +++ b/src/components/MdComponents/topics/ai-agents.tsx @@ -0,0 +1,13 @@ +import type { ChildOnlyProp } from "@/lib/types" + +// TODO: Standardize CardGrid across all MdComponents +const CardGrid = (props: ChildOnlyProp) => ( +
+) + +// MDX components available to ai-agents markdown pages. +// The layout itself lives in `src/layouts/Topic.tsx`; per-section config is +// in `src/data/topics/ai-agents.ts`. +export const aiAgentsComponents = { + CardGrid, +} diff --git a/src/components/MdComponents/topics/index.ts b/src/components/MdComponents/topics/index.ts index b2e7f093b90..c8206ad5796 100644 --- a/src/components/MdComponents/topics/index.ts +++ b/src/components/MdComponents/topics/index.ts @@ -6,6 +6,7 @@ // per-section config is in `src/data/topics/.ts`. // // See `docs/topic-layout-refactor.md`. +export { aiAgentsComponents } from "./ai-agents" export { roadmapComponents } from "./roadmap" export { stakingComponents } from "./staking" export { upgradeComponents } from "./upgrade" diff --git a/src/components/TableOfContents/index.tsx b/src/components/TableOfContents/index.tsx index c9f503b6aa7..5277e0f2e2c 100644 --- a/src/components/TableOfContents/index.tsx +++ b/src/components/TableOfContents/index.tsx @@ -29,7 +29,7 @@ const variants = cva( "top-28 min-w-80 max-w-72 lg:p-8 px-3 py-2", "shrink-0 gap-y-2.5 rounded-2xl bg-accent-a/10 text-body-medium" ), - left: "top-28 me-16 ms-8 basis-[400px] [&_ul]:leading-relaxed", + left: "top-28 me-16 ms-8 shrink-0 basis-[400px] [&_ul]:leading-relaxed", }, }, defaultVariants: { diff --git a/src/components/ui/__stories__/Select.stories.tsx b/src/components/ui/__stories__/Select.stories.tsx index 5a2338a70af..dd50a37a8df 100644 --- a/src/components/ui/__stories__/Select.stories.tsx +++ b/src/components/ui/__stories__/Select.stories.tsx @@ -139,7 +139,7 @@ export const ErrorState: Story = { render: () => (