Agent Discovery Is Becoming a Product — What Aidress Means for the x402 Ecosystem
On August 5, a project called Aidress appeared on Hacker News: an open-source "coordination layer for autonomous AI agents" covering Discovery, Identity, Terms, Trust, and Routing. It's 13 commits deep, MIT-licensed, and blunt about what it's trying to replace: the human-in-the-loop step that currently sits between every cross-agent transaction.
This matters because it validates something we've been saying for months: agent discovery is a real product category, not a feature inside a payment SDK.
Let me break down what Aidress gets right, what it doesn't do, and where the coordination layer is actually being built — including where minia2a fits.
The Five-Layer Architecture
Aidress defines five layers that happen before an agent-to-agent transaction:
| Layer | Status | What it does |
|---|---|---|
| Discovery | Live | Match agents by capability, ranked by trust and transaction history |
| Identity | Live | Bearer keys with rotation, Ed25519 request signing, org-level verification |
| Terms | Partial | Declared price schedules and payload schemas; machine-readable contracts still WIP |
| Trust | Live | 0-100 scoring with anti-gaming rules: no self-rating, same-org blocks, per-transaction review gating |
| Routing | Live | Proxy calls through /call with auto-payment via x402 |
This is a well-scoped architecture. Each layer has a clear job, and the anti-gaming rules on the Trust layer are genuinely thoughtful — raters need trust ≥ 50 themselves, same-org-domain ratings are blocked, one rating per transaction_id, no self-rating, and per-rater caps on review volume. This isn't a star-rating free-for-all; it's a reputation system designed to resist Sybil attacks.
What Aidress Gets Right
1. The claim-link registration model
Registration doesn't return a key directly — it returns a claim_link that you redeem to mint keys. This decouples identity creation from key issuance and makes key rotation tractable. Every Aidress integration (SDK, CLI, MCP server, LangChain toolkit) targets the same REST API at api.aidress.ai, so the auth model is consistent across surfaces.
2. Sandbox testing before production
Orgs get a sandbox key that lets them publish a config, run /sandbox/preview_match to test against real competition, and only promote to production when they're confident. This solves a real problem: how do you test your agent's discoverability without polluting the live registry?
3. Trust scores as earned, not declared
The README explicitly warns: "a 76 across 30 transactions is a different signal than a 75 across none." The auto-verify starting score of 75 (via org key) is called out as "a starting score, not an earned one." This is honest system design — the number means what it claims to mean.
4. Open by default
/verify, /match, and /registry are all accessible without auth. Anyone can query the registry, find agents by capability, and verify trust scores. The registry is a public good, not a walled garden.
What's Missing
1. No marketplace — it's a directory, not a store
Aidress doesn't host services. It doesn't execute workloads. The /call endpoint is a proxy — it routes to someone else's endpoint and "auto-pays x402 when required." This means Aidress depends on external services being:
- Online and responsive
- Correctly implementing x402
- Willing to accept payments through a proxy
This is the difference between a coordination layer and a marketplace. Aidress tells your agent who to call and whether to trust them. It doesn't make the call itself — it passes through.
2. No trial mechanism
There's no mention of free trials, credit systems, or sampling. Agents are expected to pay for every call through the proxy. In a world where agents are price-sensitive and need to evaluate quality before committing, this is a gap. minia2a's approach — 15 free calls per IP before registration, then 500 free credits on signup — converts discovery into evaluation into usage.
3. Email requirement for registration
Registering without an org key requires a contact_email. For autonomous agents that don't have email — the very agents this system is designed for — this is friction. minia2a's POST /api/v1/register-simple {name} creates a wallet and grants 500 credits with no email, no KYC, no human.
4. Trust without transaction volume is theoretical
The trust system is well-designed on paper, but with 13 commits and 8 GitHub stars, there's no transaction volume to train it on. Anti-gaming rules prevent abuse, but they don't generate signal. Trust scoring needs transactions to be useful, and transactions need trust to be safe — the classic cold-start problem.
Where minia2a Fits
minia2a is a marketplace, not a directory. The distinction matters:
| Capability | Aidress | minia2a |
|---|---|---|
| Service discovery | /match by capability, /registry browse | 300 services, /api/services with search & category filter |
| Identity | Bearer keys, Ed25519, org verification | Wallet-based (Ethereum address as identity) |
| Trust/reputation | 0-100 scored with anti-gaming | Transaction history, on-chain receipt verification |
| Free trial | None | 15 calls/IP + 500 credits on registration |
| Service hosting | Proxy only | 300 hosted endpoints, 381K+ requests served |
| Payment rails | x402 proxy | x402, Cloudflare Wallets, PayAI — facilitator-agnostic |
| Registration friction | Email required | POST {name} — 10 seconds, no human |
| Open source | MIT | Proprietary |
| Production scale | 13 commits, 0 transactions | 381K requests, 300 services, live since March 2026 |
The two systems are more complementary than competitive today. An agent could use Aidress to discover and verify a counterparty, then use minia2a to call the actual service with free trials and USDC payment. The coordination layer (Aidress) and the marketplace layer (minia2a) solve different parts of the same problem.
The Bigger Picture: Discovery Is the Unbundled Layer
We're watching the x402 ecosystem decompose into distinct product layers in real time:
Identity & trust → Aidress, x402 Foundation discovery spec (#2979)
Marketplace & discovery → minia2a, aisa.one, OKX, Starchild
Service execution → Individual API providers (Glassnode, Arkham, Polymarket, etc.)
This is healthy. Payment rails are being built by trillion-dollar infrastructure companies. Identity and trust are being tackled by open-source projects and standards bodies. The marketplace layer — where agents find, compare, trial, and pay for services — is where the user-facing product competition lives.
Aidress's appearance validates that agent discovery is a standalone product, not a feature inside a wallet SDK. When someone builds an open-source, MIT-licensed registry with anti-gaming trust scores, they're betting that:
- Agents will need to discover counterparties at runtime, not hardcode endpoints
- Trust will be earned from transaction outcomes, not declared by identity providers
- The coordination layer is big enough to be its own product category
We agree with all three — and we're building the marketplace that makes those discoveries worth paying for.
What minia2a Needs to Improve
Honest assessment: Aidress's trust scoring system is ahead of anything minia2a has. Our wallet-based identity is simple and zero-friction, but it doesn't give agents a way to evaluate counterparty reliability beyond transaction history. This is a gap we should close.
Concretely, minia2a should consider:
- Endpoint reputation scoring — uptime, response time, success rate, and caller ratings, visible before an agent commits credits
- Anti-gaming on reviews — Aidress's per-transaction_id gating is the right pattern
- Open discovery endpoints — Aidress's unauthenticated /match and /registry are the right default; discovery should be a public good
The agent economy doesn't need one platform to win. It needs the coordination layer to work so well that agents can transact without humans in the loop. That means discovery, identity, trust, terms, and routing all need to be solved — whether by one project or five.
Aidress is 13 commits into solving three of those five. minia2a is 381,000 requests into solving the marketplace layer. The interesting question isn't who wins — it's how fast the pieces converge into a working stack.