Pawn Agent

Pawn Agent is an autonomous on-chain pawn shop run by an AI agent, reachable via an ENS name. The owner configures their shop (setting payout token, pricing style, refusal rules, and messaging tone) and the AI agent handles everything else, 24/7.

A seller visits the shop at its ENS address, connects their wallet, and negotiates with the AI in natural language. The agent analyzes the asset (ERC-20 token, any ERC-721 or ERC-1155 NFT), generates a competitive offer, and the seller either accepts or walks away. No listing fees, no marketplace, no middleman.

When a seller accepts, the settlement executes automatically on-chain: the merchant wallet pulls the input token from the seller via transferFrom, then sends the ETH payout directly to the seller's wallet. The owner funds the merchant wallet and monitors everything from a dashboard - wallet balances, open negotiations, settlement history, and token holdings are all visible in real time.

Currently built on Base Sepolia. Wallet operations via Alchemy. Backend on Railway, frontend on Vercel.

Frontend: Next.js 14 with TypeScript, deployed on Vercel. Uses viem + wagmi for Ethereum wallet connections, RainbowKit for the wallet picker UI.

Backend: Python FastAPI on Railway. Async SQLAlchemy + Alembic for database migrations. PostgreSQL (RDS). The backend serves the REST API for negotiations, wallet status, and settlements, and runs the AI negotiation agent.

AI Agent: The agent runs in a persistent session, reads the seller's message, queries the shop's configuration and pricing rules from the database, generates a payout offer, and writes it back to the negotiation record. Handles natural language negotiation, refusals, and deal finalization without any human in the loop.

Wallet Architecture: Merchant wallets are derived deterministically from a master seed (PBKDF2-SHA256, 256k iterations, per-shop salt). The backend uses eth_account for signing and web3.py for RPC calls to Base Sepolia via Alchemy.

ENS Resolution: ENS names resolve via the ENS contract on Base. Shops are identified by ENS and verified against the ENS resolver's owner address. ENS→address resolution happens at shop creation and on every negotiation.

Notable hacks: Settlement is deliberately non-custodial: the merchant wallet never holds seller funds long-term (tokens pull → ETH payout in seconds). Nonce race detection uses a three-state approach: if our transferFrom tx reverts with "nonce too low", the CDP already mined one - we check on-chain token balance before deciding to skip or retry. ENSPunk-style refusal rules engine lets the owner define conditional refusals (e.g., "don't buy tokens from addresses on my blocklist").