ENStrology
AI horoscopes from your ENS name's onchain birthday the agent writes, but can't rewrite you.
Demo
About
Every ENS name has an onchain birthday. ENStrology turns that real, verifiable date into a playful AI horoscope and uses it to demonstrate a serious problem: how do you let an AI agent create onchain content for someone without handing it control of their identity? A user signs in with Privy, links the wallet that controls their ENS name, and ENStrology verifies both the name's control and its real registration date. After paying 0.01 demo USDC on Sepolia, the ENStrology Oracle generates a horoscope and stores it in real, expiring ENSv2 subnames. The permission model is the point. Verified facts source name, creation date, owner, payment proof live on a name the Oracle has no rights to at all. The horoscope lives on a sibling name where the Oracle holds a single scoped role. It can write the reading. It cannot rewrite the facts, the owner, the resolver, or the expiry, and the user can revoke its access at any time. All three cases are demonstrated as real Sepolia transactions, including the one that reverts. Readings can stay private or be published to the Cosmic Feed, a discovery page built entirely from contract events and ENS records — no database. Every result clearly separates verified onchain facts from AI-generated entertainment. This is entertainment, not prediction or financial advice.
How it's made
ENStrology is a Next.js, React, TypeScript and Tailwind CSS app. Privy provides email and social sign-in, embedded wallets, and external-wallet linking, so a user with a mainnet ENS name can prove control of it from any linked wallet. viem handles all chain access: ENS ownership and registration data are read from mainnet via The Graph's ENS subgraph with an RPC fallback to registrar events, while every write happens on Ethereum Sepolia — the app never sends a mainnet transaction. A Solidity payment contract, built and tested with Foundry, accepts 0.01 demo USDC, prevents replay, and emits purchase and visibility events. The Cosmic Feed is built from those events plus ENS resolution, so the contract — not a database — is the source of truth for what is public. ENSv2 does the security work. Each reading is created as an expiring, non-transferable subname in the Oracle's own namespace using the Permissioned Registry, with records stored on a Permissioned Resolver. Because Enhanced Access Control scopes roles per name rather than per record key, verified facts and AI content are deliberately split across two sibling names: the Oracle is granted the Set Text role, as Manager only, on the horoscope name alone. It holds no role on the facts name and no Admin rights anywhere, so it cannot grant itself more. Attempting to write outside its scope reverts onchain, and the owner can revoke the role at any time. The Oracle publishes its own purpose and endpoint as agent-context and agent-endpoint records on its ENS name, following the ENS agent-record convention. Horoscope text is generated with the Vercel AI SDK from verified structured facts only — the model never chooses the name, the date, the payment, or the owner.