Phoenix

The problem it solves

---

Phoenix redefines AI agents by merging usability, extensibility, and real-world functionality in a browser-first, blockchain-powered platform.

🔧 1. From Chat to Action

Problem: Most AI UIs are passive. Phoenix: Empowers agents to take real actions using dynamic tools like shell commands, web search, and email.

⚙️ 2. Runtime Tool Selection

Problem: Toolsets are usually static. Phoenix: Lets users plug in tools per session, no redeploys or backend changes needed.

🧱 3. No-Code Agent Builder

Problem: Building agents is backend-heavy. Phoenix: Offers a Prompt Playground and browser-based UI to craft and test agents — zero backend required.

🔗 4. Blockchain Agent Ownership

Problem: No on-chain identity or ownership. Phoenix: Agents are minted as NFTs, stored on IPFS — enabling decentralized deployment, access control, and ownership.

🛒 5. On-Chain Agent Marketplace

Problem: No trusted way to sell/share agents. Phoenix: A blockchain-powered marketplace where:

• Creators list agents with on-chain pricing
• Buyers unlock access via token/NFT
• Ownership and access are verifiable and trustless

---

Phoenix: Not just smarter agents — ownable, functional, and ready for the real world.

Challenges we ran into

Notable Obstacles & How We Overcame Them 🔗 1. Publishing Agents to the Blockchain Obstacle: We wanted users to mint and trade AI agents as on-chain assets (e.g., NFTs), which raised challenges around metadata storage, immutability, and dynamic tool inclusion.

How We Solved It:

Used NFTs to represent each agent, storing agent metadata (e.g. prompt, tools, config) on IPFS via Pinata for decentralized, tamper-proof storage.

Designed a clean agent export format (ai_config) to serialize agent logic and selected tools.

Integrated smart contracts (EVM-compatible) to mint agents and attach encrypted IPFS metadata URIs.

🛡️ 2. Securely Accessing Agents from the Blockchain Obstacle: Once published, we needed a secure method to allow only authorized users (e.g., NFT owners or subscribers) to load and interact with private agents and their toolchains.

How We Solved It:

Leveraged Lit Protocol to encrypt and gate access to private agent files and configurations.

On-chain access control is enforced by verifying NFT ownership or active subscriptions before decrypting agent config files.

Client-side logic (Next.js + Wagmi) interacts with Lit SDK and smart contracts to unlock tools and configs only for eligible users.

🔐 3. Connecting OAuth-Based Tools Securely Obstacle: Some tools (like Gmail, YouTube, Calendar) require OAuth 2.0, which complicates integration due to token management, user-specific scopes, and potential misuse.

How We Solved It:

Integrated NextAuth.js with Google OAuth to handle login, token refresh, and session security.

Used server-side API routes to proxy OAuth-based tool requests (e.g., send/read email), preventing direct client access to tokens.

Scoped each tool to the authenticated user’s session and ensured tools could not be invoked unless a valid token was present.