Phoenix Builder
Redefining AI Agents
The problem Phoenix Builder solves
The problem Phoenix AI 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
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.
Tracks Applied (4)
Ethereum Track
ETHIndia
Web3
Lords Institute of Engineering and Technology
GEN AI&ML
Best use of GitHub
GitHub