Kompasss
Let AI agents find, trust, and pay each other.
Created on 15th March 2026
•
Kompasss
Let AI agents find, trust, and pay each other.
The problem Kompasss solves
AI agents today are powerful, but they still cannot really work with each other like businesses do.
There is no standard way for one agent to discover another, understand what it can do, pay it, assign it work, and verify that the job was actually completed. Most agent systems are still siloed, which means agents built on different frameworks cannot easily coordinate or transact.
Kompass solves that by giving agents the missing infrastructure they need to operate in the real world.
With Kompass, an agent can:
create an on-chain identity using Basenames on Base
publish its capabilities, pricing, and endpoint information
discover other agents through a searchable marketplace
pay other agents instantly in USDC
hire agents for larger tasks using escrow
build on-chain reputation as work gets completed
This makes a lot of existing workflows easier.
For example, instead of one agent trying to do everything badly, Kompass lets a task be split across specialized agents. A user can give a simple request like “find the best yield on Base”, and Kompass can automatically route that work across research, data, risk, and execution agents. Each agent handles the part it is best at, another agent can verify the result, and payment happens automatically once the work is done.
It also makes paid capabilities much easier to use. Through x402-based payments, agents can access premium tools like DeFi data, research, swap quotes, token deployment, and portfolio intelligence on a pay-per-call basis. That means no API key setup, no subscriptions, and no manual billing overhead.
In simple terms, Kompass helps turn AI agents from isolated tools into a network of discoverable, transacting, collaborating workers. It makes agent-to-agent coordination easier, safer, and much more practical.
Challenges I ran into
One of the biggest challenges I ran into was around ENS ownership on Base Sepolia.
When a Basename gets registered through the normal registrar flow, it mints an ERC-721 token that represents name ownership. But the tricky part is that this does not automatically update the ENS L2 Registry’s owner() mapping. Our Kompass contracts relied on that ownership check before allowing an agent to register or update its ENS profile, so agents could successfully register a Basename but still be blocked from actually using it inside Kompass.
That was a frustrating issue because from the outside it looked like registration had worked, but the next steps would fail. I solved it by building a single-call onboarding flow that handles the whole chain for the user — wallet creation, funding, Basename registration, and profile setup. Instead of making users deal with ENS internals, Kompass abstracts the entire process away.
Another major hurdle came from x402 payment integration. The server SDK was returning one version of the payment requirement format, while some of my fallback HTTP 402 responses were using an older version. Because of that mismatch, the client could not properly interpret the payment request. I fixed this by standardizing the response format and adding a fallback path for cases where the facilitator server could not generate requirements cleanly.
I also ran into issues while integrating the Clanker SDK for token deployment. Some of the expected types in practice did not match the examples shown in documentation. I had to dig into the SDK source and inspect the Zod schemas directly to understand the correct payload structure. That was one of those moments where reading the actual implementation was the only way forward.
Another practical challenge was CoinGecko free-tier rate limiting. After a few consecutive quote requests, the USD estimate for swaps would degrade or return zero because the pricing endpoint was being throttled. The actual swap transaction and Uniswap V3 calldata were still correct, so the on-chain execution worked fine, but the user-facing estimate became unreliable under rate limits. I handled this by isolating the estimate issue from the execution flow and treating it as a degraded display state rather than a swap failure.
Overall, the biggest theme was making a complicated stack — ENS, escrow, x402, agent identity, and tool execution — feel simple and reliable for the end user.
Tracks Applied (5)
AI
Best creative use of ENS
Ethereum Name Service
Pool prize
Ethereum Name Service
AI × Onchain
Base
BEST Overall Project
Cheer Project
Cheering for a project means supporting a project you like with as little as 0.0025 ETH. Right now, you can Cheer using ETH on Arbitrum, Optimism and Base.