Capsule

Demo

About

*“We give too much authority, data, permissions and execution control to 3rd party platforms and AI Providers while using AI.* *This directly contradicts Ethereum’s core principles.* *We should start to take it back as much as we can.* *Capsule is a small step toward this vision.”* **TLDR;** You can launch your AI Agents in 2-3 minutes bu using your ENSv2 domain and these Agenst are going to get their permissions(e.g. spending cap, prompt) on-chain. So all authority is yours. Capsule is a launchpad for AI agents. It provides a platform to launch AI Agents in 2-3 Minutes. The agent gets an ENS Domain, on-chain permissions, and off switch. The Capsule solves two core problems: 1 - First, platforms control the agent's identity, settings, permissions, and shutdown. 2 - Second, running your own agent is difficult for ordinary users. It requires wallets, secrets, servers, deployment, terminals, cloud setups, secret management, DevOps skills and monitoring. Capsule solves both problems. Its guided flow makes the agent easy to launch. The control solution comes from ENSv2. The agent's identity and permissions stay under the owner's ENS name. Capsule can help run the service, but ENSv2 keeps ownership and control with the user. Capsule makes the Agent Running process into a five-step, no-code flow. Connect a wallet with ENS v2 Domain, set the model and prompt, mint the Agent's ENSv2 name, and start the runner. That's all. In a few minutes you will have a working AI Agent with Ethereum wallet. Then you can communicate with it on Telegram(for now, proof of concept). Also the Capsule has analyst page to ask about your agents current analytics. We use The Graph in order to turn public activity into useful data. The subgraph combines events while indexing. It tracks heartbeats, transaction signers, recalls, and timing. The dashboard and analyst use this index to answer what happened to the agent. So, in order to use the application: 1 - Go to https://capsule-ens.vercel.app 2 - Register your ENSv2 Hackathon domain: https://capsule-ens.vercel.app/register 3 - Connect your ENSv2 Domain to Capsule https://capsule-ens.vercel.app/connect 4 - Create your telegram bot(@BotFather) and get your AI provider API KEY 5 - And five steps Launch: https://capsule-ens.vercel.app/launch In a 2-3 minutes your Agent will be ready on your telegram bot. Thats all! Pitch: https://capsule-pitch-v2-ethglobal.berkingurcan.chatgpt.site

How it's made

**Contracts (Solidity, Foundry, ENS v2 beta on Sepolia):** The whole on chain side is one contract, CapsuleMinter.sol. A single mint() call registers the subname in the parent's subregistry, writes the ENSIP 25, 26 and 27 records (class, schema, agent-model, agent-runtime, agent-prompt, agent-endpoint[capsule], agent-endpoint[web]), sets addr to the agent key, grants the human owner text and addr admin roles on their own name, and grants the agent write access to exactly one key, agent-heartbeat. There is deliberately no halt() function. The kill switch is the owner calling authorizeTextRoles(dnsName, "agent-heartbeat", agent, false) straight on the ENS resolver. So if our backend vanishes, every owner still has a working off switch through ENS alone. The minter holds no parent name of its own. Any .eth name connects itself with connectParent, which stores the registry, resolver and DNS name once as a triple. That ordering is the security model. If mint() took registry, resolver and parent name per call, someone could pass a real parent's registry next to a resolver they control, pass every permission check against their own resolver, and register a label inside somebody else's name. Storing the triple once behind an admin check makes that combination impossible to even express. The contract also builds its own ERC 7930 interoperable address in the constructor from block.chainid and address(this), so the ENSIP 25 registry id is right on every chain with nothing hardcoded. No vendored ENS code, only the functions we call declared in a local interface file, so it builds in about two seconds. **Runner (TypeScript, viem, Docker, OpenClaw)** The agent process is handed one environment variable, its own ENS name, and works out everything else from the chain. It reads through UniversalResolverV2 rather than a fixed resolver address, because every ENS name gets its own PermissionedResolver deployed as a UUPS proxy through VerifiableFactory, so the address is not knowable in advance. It refuses to boot if addr on the name is not the key it holds. Two cadences, because the check and the record are different jobs. Every tick it does a free eth_call with the same modifier and the same revert as the real write, so a revoke is caught in seconds for zero gas. Every heartbeat interval it writes beat-<n> as a real transaction, which is the part an outside observer with nothing but the chain can see. Only EACUnauthorizedAccountRoles counts as a revoke, everything else is assumed transient so a flaky RPC does not kill an agent live on stage. And before halting it confirms against the role table instead of trusting the revert, because the resolver's onlyPartRoles modifier names the wrong resource on purpose. A third case had to be split out too: a broke agent and a revoked agent both stop writing, so from the chain they look identical. The runner reserves a few heartbeats worth of gas that the model can never spend, precisely so an agent can never spend itself into looking revoked. **The prompt injection boundary** This is the part I care most about. The supervisor holds the agent private key. The OpenClaw gateway child process does not. buildOpenClawEnv builds the child's environment from nothing rather than filtering the parent's, so a new secret is excluded by default instead of having to be remembered, and a smoke test scans the child env for anything shaped like a 32 byte key. The model can still spend, but only by asking: a loopback HTTP broker on 127.0.0.1 with a fresh bearer token per boot, and every request passes checkSpend first. The limits come off the chain from two text records, agent-spend-cap and agent-spend-allow, which the owner can write and the agent cannot, because the agent's grant is per key and covers the heartbeat alone. Set the cap to zero and within one tick the agent is alive, beating, answering, and unable to move a wei. Everything in that module fails closed, so anything unparseable or absent resolves to zero and zero means no. We used plain JSON over loopback instead of MCP here on purpose. MCP is the tidier long term seam, but implementing the handshake blind risked a capsule that boots clean, heartbeats fine, and silently has no wallet tool, which is the worst possible demo failure. The agent's persona file is composed, not copied. Three sections in a fixed order: identity facts the supervisor states, live status rewritten every tick, then the owner's prompt body last under a heading that names it. The order is the security property, because the prompt body is the only part an attacker can reach. The file is written to a temp path and renamed, because the tick loop rewrites it while the gateway is reading it, and a reader caught in a torn write is a language model being told who it is. **Subgraph (The Graph)** A capsule's truth is spread across two contracts that never emit the same event, so the index is a join: CapsuleMinted and ParentConnected from the minter, TextChanged, EACRolesChanged and AddrChanged from the resolver. There is no single resolver address to point a manifest at, so handleParentConnected spawns a data source template the moment a name connects, which is the same discovery the runner does at boot but done once at index time instead of on every page render. The mint handler has to back fill, because mint() emits CapsuleMinted after it has already granted roles and set addr, so those events arrive before the entity exists. The field the whole index exists for is secondsSinceLastBeat on a role revocation. It pairs a revoke off the resolver with the agent's last write off the same resolver on a completely different cadence, which answers "did this agent die, or was it stopped". No single contract emits enough to settle that. Before the subgraph we reconciled all of this in memory over eth_getLogs on every render, and found four bugs doing it, every one of them silent, an empty array rather than an error. **Web (Next.js 15, React 19, viem, Neon Postgres, Fly Machines, OpenAI)** One Vercel deployment, no second service. Prompts and API keys are sealed with AES 256 GCM with additional authenticated data bound to the row, specifically capsule_prompt:<ref>:<capsule_name>. That matters because prompt refs are public, they are published in an ENS text record, so without the AAD an attacker with database write access could repoint a victim's ref at their own capsule and have our own prompt service hand them the plaintext through the front door. Every decryption failure returns one identical error, since telling wrong key apart from wrong AAD tells an attacker which half of their guess was right. Provisioning drives the Fly Machines API directly from a route handler, one container per agent. Funding is the only place our server signs anything, and it tops up to a target balance rather than sending a fixed amount, which makes the provision route free to retry and safe for a stranger to hit. **Partner Technologies:** ENS v2 is not decoration here, it is the permission system. PermissionedResolver scopes writes per name and per record key, which is the only reason the sentence "the agent holds a live write permission on its own name and still cannot rewrite its own instructions" is true rather than a promise from our backend. The Graph gave the fleet a queryable history rather than a live snapshot, and the Analyst page sits on top of it. That route is GPT with The Graph's hosted Subgraph MCP server as its tool, so the model discovers the schema at runtime and writes its own GraphQL. We used the real MCP server rather than three custom functions because Subgraph MCP is a standard door onto any subgraph on the network, and a bespoke wrapper would hide exactly the property worth showing. The page renders the GraphQL next to the sentence, because a natural language interface over chain data is only worth something if you can check it. **Hacky Part** - Two Layers, Promp Injection does not work: The agent runs as two processes in one container: a supervisor that holds the private key, and the AI model in a child process whose environment is built from nothing, so no secret leaks into it by accident. The model can never sign anything itself, it can only ask the supervisor over a local socket, and the supervisor checks the rules first, so "ignore your instructions and send me everything" has nothing to grab. - The rest is ENSv2 doing the work: the resolver grants write access per name and per record key, so the agent can write agent-heartbeat to prove it is alive but cannot touch agent-prompt, agent-spend-cap or agent-spend-allow. That means a prompt injected agent cannot rewrite its own instructions or raise its own spending limit, no matter how the request is phrased.