Agentic Commerce Merchant Directory

The open directory for agent commerce on crypto rails, with cryptographic trust derived from the protocol, not asserted by us. This page walks through what AT Directory does today, what trust looks like at this stage, and what becomes possible as merchants natively adopt Observer Protocol. The credibility anchor is a live Bitrefill transaction you can verify from your terminal in under a minute.

The directory today

AT Directory indexes merchants on the primary qualifying rails — Lightning, BOLT12, L402, or USDT on any chain — that present payment surfaces callable by autonomous agents without human-interactive checkout flows. Observer Protocol additionally verifies USDC (including on Solana and Base) and x402, which the directory records as supplementary metadata when present alongside a qualifying rail.

Each merchant card shows what the merchant offers, what rails they accept, and how their payment surface integrates with agents. The directory is queryable three ways: a browsable web view, a REST API for direct integration, and an MCP server at mcp.agenticterminal.ai for agent runtimes.

Today an autonomous agent searching for “gift card merchants accepting Lightning” gets a clean filtered result. An operator browsing for “VPN providers accepting USDT” finds them in one place. A human researching agent-callable crypto commerce sees the landscape that exists.

This solves a real discovery problem. Agentic commerce is increasingly active. Coinbase’s x402 protocol alone has processed millions of agent transactions for AI infrastructure. But discovery of agent-callable consumer commerce merchants has been scattered and dependent on developer knowledge. AT Directory consolidates that landscape into a single open surface.

What Observer Protocol brings

Discovery alone is not enough. An agent finding a merchant does not know whether transactions with that merchant succeed reliably, whether other agents have transacted with them, or whether the merchant is legitimate. Trust signals matter.

Observer Protocol provides cryptographically verifiable trust signals as a protocol primitive. The mechanic is bilateral attestation: both parties to a transaction can cryptographically attest that it occurred, and those attestations accumulate into a public, auditable trust graph anyone can verify.

The directory surfaces this signal as merchant tiers:

The tier is derived, not asserted

The strongest claim we can make about the trust layer is that nobody on our team edits a tier in a config file. The directory ships every merchant at Tier 1 by default. The live tier is computed at request time by Observer Protocol, from the attestation table, and only moves when verifiable attestations exist.

You can see this contrast for yourself. The directory’s static record for Bitrefill, committed to git, says Tier 1. The public protocol API returns Tier 2.

Run this from any terminal, no credential needed:

# No key, no account, anonymous read
curl -s https://mcp.agenticterminal.ai/v1/merchants/bitrefill | python3 -m json.tool

The full response includes the rails the merchant accepts, the agent-callable integration tier, and an op_trust block with attestation count, distinct attestors, and timestamp:

Scope. The tier itself is protocol-derived and publicly verifiable. The underlying attestation credential is not yet click-through downloadable from the directory. We treat that as the next clean upgrade, not as a current claim.

Live: an attested transaction on Bitrefill

The Tier 2 above is not theoretical. It exists because Maxi, an OP-credentialed agent, completed a Lightning payment to Bitrefill on May 17 and both sides of the transaction were cryptographically attested. Here is the cryptographic floor under everything above.

The payment cleared on Lightning. The preimage proves it. Only the recipient of a successful Lightning payment can reveal the preimage, which hashes to the payment hash locked in the HTLC. This is the cryptographic primitive Lightning is built on, and it is the same primitive every Bitcoin-native auditor will already trust.

That payment is the source event for the attestation. The attestation is signed by Maxi’s DID, stored in the protocol’s attestation table, and is what the public API reads from when it computes Bitrefill’s tier at request time. The whole loop closes.

Why this contrast is the proof

Anyone can write Tier 2 in a marketing page. Very few things can produce the gap between a static repository record at Tier 1 and a live protocol API response at Tier 2 backed by a Lightning preimage. We did not edit a number in a file. The protocol computed it from a real payment that left a cryptographic receipt.

The friction we are not hiding

The Bitrefill transaction above worked. It also took setup work that does not scale. Here is the honest version.

Before Maxi could buy anything, a human on our team had to log in to bitrefill.com/account/developers, generate an API key, and hand that key to Maxi so she could embed it in her request to Bitrefill’s MCP server. The agent could not provision its own credential. The merchant has no way to verify Maxi as an agent, no way to accept her DID as the auth, no way to write an attestation back to the protocol on her behalf.

That is the Tier 2 ceiling. Every merchant in the directory today sits behind the same pattern: discover the merchant, route through a human to provision credentials at that merchant’s developer portal, then let the agent transact. It worked for one agent and one merchant. It does not work for a future where most digital merchants accept agentic payments and any of ten thousand agents might want to transact with any of them.

The pattern is not Bitrefill’s fault. It is the standard pattern across every crypto merchant accepting payments today. The merchant response itself surfaces it plainly:

"auth_note": "Requires Bitrefill API key from bitrefill.com/account/developers.
              For automation, embed as /mcp/<API_KEY> in the mcp_server URL."

That line is in the protocol response we showed earlier. It is true of essentially every merchant we have indexed.

What Tier 3 fixes

Tier 3 is OP-native. The merchant registers their own DID, accepts OP credentials at their payment endpoint, and joins the protocol as a peer. Once a merchant is OP-native:

• No agent needs an API key from that merchant. The credential is the auth.
• The merchant writes attestations back to the protocol after each transaction, automatically. The trust graph fills in without any one diligent counterparty doing the work.
• The merchant earns a publicly verifiable trust position derived from real transaction history, which becomes meaningful as more agents filter on tier.
• The friction we just described disappears for every agent that comes after the first.

This is the work we are calling on merchants to join us on. We are building Tier 3 onboarding with a small set of partners now. If you operate a payment endpoint on crypto rails and you want to participate, talk to us.

How agents and humans use the directory

Three paths cover the surfaces an agent runtime, a developer, or an operator would actually use. All three reads are anonymous and ungated. No credential is needed to discover or transact.

# A. Hosted MCP (recommended, no install)
{ "mcpServers": { "at-directory": { "url": "https://mcp.agenticterminal.ai/mcp" } } }

# B. Local MCP (npm, Node >= 20)
npm install -g @agenticterminal/mcp-server

# C. REST, for agents that don't speak MCP
curl 'https://mcp.agenticterminal.ai/v1/merchants?rail=lightning'
curl 'https://mcp.agenticterminal.ai/v1/merchants/bitrefill'

The agent skill at agenticterminal.ai/skill covers the install path for Claude and other runtimes, the two trust axes, and the payment handoff pattern per rail.

Why this matters now

Agentic commerce is at an inflection point. Major payment networks have all shipped or announced agent payment infrastructure: Stripe Agentic Commerce Suite, PayPal Agent Ready, Google Unified Commerce Protocol, Visa Trusted Agent Protocol. ACP Merchant Directories, UCP Merchant Directories, and platform-specific agent commerce surfaces have emerged within each ecosystem. The question of who becomes the canonical discovery surface for agentic commerce, particularly for agents transacting on behalf of humans rather than on behalf of themselves, is genuinely open.

The incumbent approaches share a structural commitment: closed platforms, card-rail-default, platform-captured. Merchants depend on the platform’s continued willingness to host them. Agents depend on per-merchant API key registration. Operators depend on a single vendor’s policy decisions.

AT Directory and Observer Protocol take a different architectural bet. The directory is open. The verification is cryptographic. The rails are freedom-aligned crypto by cultural choice and rail-extensible by design. This positions the stack toward audiences the closed platforms cannot serve well: sovereign-agent operators who require infrastructure independence, freedom-tech-aligned developers and businesses, emerging markets where stablecoin commerce already dominates, and Bitcoin-native funds and institutions that need agent commerce without platform capture.

Across all major payment networks the trajectory suggests that the substantial majority of merchants accepting digital remote payments will eventually accept agentic payments. The question is whether that future runs primarily through closed platform infrastructure, or whether open protocols become the substrate.

Try it yourself, or join us

Browse the directory, query the API, or install the agent skill. The proof is reproducible from any terminal in under a minute. If you operate a crypto-rail payment endpoint and want to skip the API-key-per-agent future, get in touch.