The problem it solves

AgentPay Relay

The Problem It Solves

AI agents and automated trading bots typically require one of two dangerous compromises:

• Custody: You have to deposit funds into the bot's wallet.
• API Keys/Private Keys: You have to give the bot sensitive keys to trade on your behalf.

This creates a massive security risk and a high barrier to entry. AgentPay Relay solves this by flipping the model: instead of giving the agent control of your funds, you simply pay the agent a one-time fee to execute a specific task on-demand.

What People Can Use It For

AgentPay is a Server-to-Agent payment gateway that enables "Pay-as-you-go" agentic services.

• Trustless Agent Execution: Users can utilize powerful trading strategies (Trend Following, Breakout Sniping) without trusting the agent with their private keys or total capital. You approve a single payment for a single execution.
• Monetized AI Agents: Developers can build and deploy autonomous agents that earn crypto directly for the services they provide. It turns "running a script" into a "profitable service" automatically via the x402 protocol.
• Uniswap V4 Integration: It demonstrates a live implementation of spot trading on Uniswap V4 (Base Sepolia), handling complex hook/pool interactions behind a simple user interface.

How It Works

1. Selection: User connects their wallet and selects a strategy (e.g., "Buy BTC").
2. Request: AgentPay generates a payment request via x402 (a protocol for HTTP 402 Payment Required).
3. Payment: User pays the small fee (in USDC/ETH) directly from their wallet.
4. Execution: Agent verifies the payment on-chain and instantly executes the swap on Uniswap V4 using its own execution infrastructure.

It bridges the gap between Web3 Payments and AI Agent Actions, making it safer and easier to use automated tools.

Challenges we ran into

Challenges I ran into

1. Interacting with Uniswap V4's "Flash Accounting" System

The biggest technical hurdle was integrating with the Uniswap V4 PoolManager. Unlike V3, you cannot simply call swap(). V4 uses a singleton design with "flash accounting" where every operation must settle its currency deltas before the transaction ends.

• The Problem: We kept hitting CurrencyNotSettled errors because we were trying to interact with the PoolManager directly.
• The Fix: We had to deploy and interact with a specific SwapRouter (we used PoolSwapTest from v4-periphery) that implements the required "unlock callback" pattern. We also had to properly encode the sqrtPriceLimitX96 to ensure swaps didn't fail validation.

2. Porting x402 Middleware to Next.js App Router

The x402 protocol provides excellent libraries for Express.js (x402-express), but our stack uses the Next.js 14 App Router, which runs on standard Web Request/Response objects, not Node.js streams.

• The Problem: The standard middleware expected req, res, and next(), which don't exist in Next.js API routes.
• The Fix: We built a custom Higher-Order Function adapter (x402PaymentRequired) that wraps our route handlers. It manually verifies the X-PAYMENT header using the useFacilitator hook and returns a 402 response with the correct WWW-Authenticate headers if payment is missing, maintaining full protocol compatibility without the Express dependency.

3. Testnet Liquidity & Slippage Management

Building on Base Sepolia meant dealing with extremely thin liquidity pools.

• The Problem: Even small trades were reverting with V4TooLittleReceived or causing massive price impact because the testnet pools were shallow (~$2,500 TVL).
• The Fix: We implemented a Dynamic Slippage Engine in our execution logic. It estimates the price impact of the user's trade against the estimated pool liquidity and automatically scales the slippage tolerance (up to 50% for testnet) to ensure execution succeeds, while warning the user about the impact. We also added logic to automatically bump "dust" trades up to the minimum viable pool amount to prevent EVM revert errors.