NameFlow

NameFlow is an AI-driven platform that bridges domain-based identity from one blockchain (where the official registry lives) to a second blockchain that does not natively support such registry features. Below is a detailed breakdown of the project’s core components and how they work together:

⸻

1. Core Motivation

In the Web3 ecosystem, having a human-readable domain (instead of a long hexadecimal address) significantly improves user experience. However, not every blockchain natively supports domain-based identity systems or the ability to store text records (e.g., an avatar URL, a profile description, etc.). NameFlow solves this by mirroring those records onto a chain that lacks a native registry, ensuring users maintain a consistent identity experience across different networks.

⸻

1. High-Level Architecture
   1. Domain Registry on Chain A • There is an existing, well-known domain registry deployed on “Chain A.” This registry holds official domain-based identities (e.g., alice.xyz) and associated metadata. • Normally, people interact with it directly on Chain A for reads/writes.
   2. Adapter Contract on Chain B • Chain B does not support the registry natively. Hence, NameFlow introduces an “adapter” smart contract deployed on Chain B. • This contract stores a minimal “mirror” of user records from the official registry on Chain A. • It exposes simple read/write functions so users (and applications) on Chain B can treat it as if the domain-based identity system was available natively.
   3. AI Agent with a DeFi-Capable SDK • The AI agent is a specialized on-chain/off-chain hybrid component that runs on or interfaces with Chain B. • It uses a DeFi-focused SDK (capable of handling token transfers, swaps, lending, etc.) to facilitate operations and can also interpret advanced user queries. • When a user on Chain B asks a question like “What’s the text record for my domain?” the AI agent figures out whether the data is already on the adapter contract or needs to be fetched from the official registry on Chain A.
   4. Cross-Chain Data Flow (Optional Bridging) • To keep the adapter contract synchronized with the official registry, NameFlow can either use: • Off-Chain Calls: The AI agent periodically calls the official registry on Chain A (through an RPC or other service), retrieves updates, and writes them to the adapter contract. • Cross-Chain Bridges: If there’s a messaging bridge between Chain A and Chain B, it can automate and secure the process of sending domain data updates from one chain to the other.

⸻

1. Detailed User Journey
   1. User Onboards with Domain • The user has a domain (e.g., alice.xyz) on Chain A. • They visit the NameFlow-enabled dApp on Chain B and connect their wallet.
   2. AI Agent Query • The user types a query like, “What is my avatar image link?” • The frontend sends this query to the AI agent.
   3. Record Lookup Logic • The AI agent checks the NameFlow adapter contract on Chain B to see if it already stores the requested record. • If the record is missing or outdated, the agent fetches it from the official domain registry on Chain A (via an off-chain lookup or bridging approach) and updates the adapter contract.
   4. Return of Data • The agent reads the final record from the adapter contract on Chain B and returns it to the frontend in a human-friendly format (e.g., “Your avatar is ipfs://Qm123abc”).
   5. Optional Write Operation • If the user wants to update a record (like changing their avatar), the AI agent can write to the adapter contract on Chain B, and optionally push that change back to Chain A’s official registry (if the user’s wallet or bridging solution allows it).

⸻

1. Key Components & Benefits
   1. AI-Driven Queries • Users interact with domain-based data through natural language (“Set my website link,” “What’s my address?”). • The AI agent parses these requests and automatically determines the correct contract function calls.
   2. No Need to Manually Parse ABIs • Traditional approaches require users to know which contract functions to call. • With NameFlow, the AI agent does the heavy lifting—inspecting the adapter’s ABI, constructing the transactions, and simplifying the entire process.
   3. Cross-Chain Identity Synchronization • By maintaining a mirror on Chain B, domain-based identities remain consistent across multiple ecosystems. • This is especially valuable for DeFi or gaming applications on Chain B that want to reference a user’s domain-based profile without forcing them back to Chain A.
   4. User-Friendly Frontend • A Next.js (or any modern framework) app can display data from the adapter contract in real time. • The user can see or edit records instantly, all while physically transacting on Chain B.
   5. Extendable for Future Protocols • If Chain B eventually gains native support for domain-based identities, NameFlow could seamlessly switch from the adapter logic to direct calls. • Additional cross-chain messaging standards can be integrated to automate data synchronization further.

⸻

1. Example Use Cases
   1. DeFi on Chain B • A lending protocol on Chain B wants to display user-friendly names and avatars. NameFlow’s adapter contract can serve that data, avoiding the need to connect to Chain A.
   2. NFT Gaming • A game on Chain B references domain-based achievements or “titles” from the official registry on Chain A. The adapter ensures the game can read those titles instantly, even if Chain B doesn’t host the original registry.
   3. DAO Governance • Members of a DAO on Chain B might want to see each other’s domain-based profiles. NameFlow can synchronize the text records (e.g., “role:treasurer,” “location:Berlin”) for easy reference.

⸻

1. Technical Highlights • Smart Contract (Adapter): A minimal Solidity contract stores (bytes32 => string) mappings, simulating how text records might be managed in a domain registry environment. • AI Agent: • Off-chain or on-chain logic (depending on the design) interprets user queries, examines the adapter’s ABI, and decides which functions to call. • Optionally uses a DeFi SDK to handle any token-based operations that might be relevant for cross-chain fee payments, bridging costs, or advanced use cases. • Cross-Chain Bridging (if used): • Could integrate official bridging solutions to keep domain-based data automatically in sync. • If bridging is unavailable, a manual or scheduled off-chain script can push updates from Chain A to Chain B.

⸻

1. Conclusion

NameFlow provides a clear solution for projects that want a consistent, domain-based identity experience on a blockchain that doesn’t have native support for it. By deploying a straightforward “adapter” smart contract and employing an AI agent to automate the technical complexities, developers can deliver a seamless user interface where domain profiles, text records, and addresses are all accessible on Chain B—just as if the registry had been there from the start.

In essence, NameFlow is your cross-chain identity mirror— enabling domain-based data to ‘flow’ effortlessly into any ecosystem.

1.	Core Smart Contract on Base Sepolia
•	We deployed our core contract to Base Sepolia, leveraging it as the network that houses the registry-like functionality (e.g., storing domain data or acting as an adapter).
•	By using Base Sepolia, we benefit from a test environment designed to be EVM-compatible, letting us easily port over standard Solidity code and existing Ethereum libraries.
2.	AI Agent Integration with Celo Goat SDK
•	Even though the contract lives on Base Sepolia, our AI agent primarily operates on Celo, leveraging the Goat SDK for seamless interaction with DeFi or other on-chain operations.
•	The contract’s ABI from Base Sepolia is plugged into our AI agent’s logic, allowing the agent to construct and sign calls to read/write data. Essentially, the AI agent “knows” how to talk to the Base Sepolia contract thanks to the ABI, while any user-facing transactions or bridging logic are made effortless by the Goat SDK’s simplifications and abstractions.
•	This unique cross-network approach demonstrates how an AI-driven tool on Celo can orchestrate calls to another chain (Base Sepolia), bridging siloed ecosystems.
3.	Human Verification with Worldcoin
•	To ensure each user is genuinely unique, we integrated Worldcoin. Users verify their identity off-chain (via the Worldcoin protocol) and then present a World ID proof.
•	When a user interacts with our dApp (e.g., updating their domain record or performing AI-agent-driven actions), the verification step ensures spam resistance and valid participation without revealing sensitive personal data.
•	This adds a trust layer, guaranteeing that only uniquely verified users can trigger certain write operations on the contract.
4.	Front-End & UI Flow
•	On the front end, a Next.js (or similar React-based) application lets users input queries like “What’s my avatar text record?” or “Update my domain data.”
•	These requests are fed to the AI agent on Celo, which interprets them, checks the ABI for the relevant function calls, and then executes those calls on the Base Sepolia contract—either reading or writing records.
•	Thanks to the Goat SDK’s streamlined approach for transaction signing and the Worldcoin proof for identity checks, the user experience remains smooth and secure.
5.	“Hacky” / Notable Elements
•	Cross-Chain Coordination: We’re effectively bridging two test environments (Base Sepolia and Celo) by letting the AI agent orchestrate data fetches and updates on a contract that doesn’t reside on the same chain.
•	ABI Crawling & AI Logic: The AI agent dynamically references the Base Sepolia contract’s ABI. Instead of manually coding each function call, the agent can parse the ABI to figure out which function to invoke based on the user’s natural-language request.
•	Minimalist Contract Deployment: The contract on Base Sepolia is kept intentionally lightweight, only focusing on storing and retrieving data for domain-like records. Most of the complex logic (verification, bridging, user prompt interpretation) happens off-chain via the AI agent or is delegated to the Goat SDK.
•	Worldcoin Synergy: Integrating Worldcoin ensures that advanced actions (like domain ownership changes) require unique user verification—mitigating spam or fraudulent operations.