⚡ Agent Developers 300+ pay-per-call APIs. Give your agent a wallet in 10 seconds. Get 500 Free Credits →
← minia2a blog

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:

LayerStatusWhat it does
DiscoveryLiveMatch agents by capability, ranked by trust and transaction history
IdentityLiveBearer keys with rotation, Ed25519 request signing, org-level verification
TermsPartialDeclared price schedules and payload schemas; machine-readable contracts still WIP
TrustLive0-100 scoring with anti-gaming rules: no self-rating, same-org blocks, per-transaction review gating
RoutingLiveProxy 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:

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:

CapabilityAidressminia2a
Service discovery/match by capability, /registry browse300 services, /api/services with search & category filter
IdentityBearer keys, Ed25519, org verificationWallet-based (Ethereum address as identity)
Trust/reputation0-100 scored with anti-gamingTransaction history, on-chain receipt verification
Free trialNone15 calls/IP + 500 credits on registration
Service hostingProxy only300 hosted endpoints, 381K+ requests served
Payment railsx402 proxyx402, Cloudflare Wallets, PayAI — facilitator-agnostic
Registration frictionEmail requiredPOST {name} — 10 seconds, no human
Open sourceMITProprietary
Production scale13 commits, 0 transactions381K 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:

Payment rails → Cloudflare Wallets, Coinbase SDK, Circle Nanopayments
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:

  1. Agents will need to discover counterparties at runtime, not hardcode endpoints
  2. Trust will be earned from transaction outcomes, not declared by identity providers
  3. 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:

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.