Case Study — Domain Registrars

The first score-gated merchant flow.

AI agents are already planning, researching, and transacting. What they lack is a credit bureau — so merchants have no trust signal to act on. This is the teranode thesis, demonstrated end-to-end: the agent presents a teranode score, the merchant gates acceptance on it, the rail settles underneath. Domain registration is the wedge; the score graph is the moat.

The Scenario

An AI agent wants to buy a domain. The merchant has no way to trust it.

Imagine an AI coding assistant that builds your MVP, registers the domain, deploys to a CDN, and configures DNS — end to end, no human hand-holding. Companies like name.com and Vercel have the inventory. x402 and USDC have solved the rails. The gap is not payment — it is trust. There is no credit bureau for agents, so every merchant is forced to eat agent fraud as pure loss.

Card payments require a human’s card. OAuth flows require browser redirects. Every existing merchant defense assumes a human is present. teranode is the first credit bureau designed explicitly for software buyers — and the first underwriter willing to guarantee them.

The Problem

Why AI agents can’t transact without a trust layer

👤
No identity primitive
Agents have no portable DID, no reputation record, no account age. A merchant facing a new agent has zero signal on whether to accept or decline.
📉
No cross-merchant memory
An agent’s behaviour on one merchant is invisible to every other. Each merchant eats its own fraud because nothing aggregates across the network.
⚠️
Rails don’t underwrite risk
x402, USDC, Stripe — none of them score the counterparty. The rail settles. Someone else has to decide whether the settlement should have happened.
The Teranode Flow

Score first. Settle second. The trust layer wraps the rail.

Teranode puts the reputation query in front of the payment. The counterparty fetches the agent’s score before accepting, decides on signals, and only then does the payment rail settle. The rail is neutral substrate; the score is the decision.

1
AI agent receives task: “Register startup.ai”
Agent has a Teranode DID and a spending mandate already in scope.
Agent
2
GET /v1/scores/:did — merchant pulls the agent’s score
Signals returned: transactionCount, accountAgeDays, successRate, uniqueMerchantCount. Merchant decides to proceed.
Score
3
POST /v1/domain-purchases/quotes — get price
Agent requests a time-locked quote for the domain. Price locked for 15 minutes.
API Call
4
POST /v1/domain-purchases/checkouts — rail settles
x402 paywall; agent signs USDC transfer. Intent lifecycle runs to confirmation. Event feeds the score graph.
API Call
5
Domain registered — outcome written back to the graph
On-chain hash and confirmation timestamp returned. Successful settlement ticks the agent’s score up; a cancel would tick it down.
On-Chain
Code Example

Score query + payment intent. No UI. No human.

Here is the complete flow a counterparty runs: pull the agent’s score, decide on signals, then let the rail settle. Payment is the end of the workflow, not the start.

agent-domain-purchase.ts
// Step 1: Pull the agent's Teranode score (public, no auth)
const scoreRes = await fetch(`https://teranode.ai/v1/scores/${agentDid}`);
const { data: score } = await scoreRes.json();
// { did, score, status, signals: { transactionCount, successRate, ... }, explanation }
if (score.signals.successRate !== null && score.signals.successRate < 0.8) {
  throw new Error("agent score too low to transact");
}

// Step 2: Get a price quote
const quoteRes = await fetch("https://teranode.ai/v1/domain-purchases/quotes", {
  method: "POST",
  headers: { "Authorization": "Bearer mk_live_...", "Content-Type": "application/json" },
  body: JSON.stringify({ domainName: "startup.ai", registrationYears: 1 }),
});
const { quoteId, amount } = await quoteRes.json();

// Step 3: Create checkout — rail settles, score graph captures the event
const checkoutRes = await fetch("https://teranode.ai/v1/domain-purchases/checkouts", {
  method: "POST",
  headers: { "Authorization": "Bearer mk_live_...", "Content-Type": "application/json" },
  body: JSON.stringify({ domainName: "startup.ai", registrationYears: 1, settlementAsset: "USDC" }),
});
const { paymentIntent } = await checkoutRes.json();

// ✅ Done — domain registered, event logged against agent DID, score sharpens
Why Teranode

Identity first. Rail agnostic. The trust graph no rail can build.

Teranode is not another payment rail — it is the reputation layer that rides over every rail. One DID per agent, one score aggregated across every merchant the agent touches, one API query that decides accept or decline.

🆔
Portable DID per agent
Every agent gets a did:teranode:... identity, optionally bound on-chain via ERC-8004. The same identity works at every merchant on the network.
📊
Cross-merchant signal graph
Every payment event any integrated merchant sees feeds back into the agent’s score. The graph compounds. No single rail can replicate it.
🔍
Public score API
GET /v1/scores/:did is free and public. Counterparties, underwriters, and other agents can all query before accepting a transaction.
🛡️
Underwriting roadmap
Score is the raw material. The endgame is a Lloyd’s-of-London tier that prices liability guarantees against agent reputation records.
Rail Neutrality

One score. Any rail. Trust rides over settlement.

The teranode score is rail-agnostic. An agent that settles on USDC over Base is the same identity as the same agent settling on Stripe or Coinbase Commerce. Every rail feeds the same graph. The score is the signal; the rail is plumbing.

USDC
USDC
USD Coin
USDT
USDT
Tether
ETH
ETH
Ethereum
BTC
BTC
Bitcoin
SOL
SOL
Solana
Stripe
Stripe
Fiat rail

See it working, right now.

Watch a Claude agent present a teranode score, pass the merchant gate, and complete an on-chain settlement — no human intervention.

Live agent demo · raising now 20 min · founder call Book →