Show: Scout Packs — pay-per-call B2B data (verified emails + domain intel) an Eliza agent can buy via x402, no API key

[tigerops-win]

Hi all — sharing a small production piece from Tiger Operations, because several recent Show and tell posts here are about giving agents real payment ability, and this is the data side of that same loop.

What we built: Scout Packs — a pay-per-call B2B data API that an agent can call with no account, no API key, and no subscription. The agent asks for a company/domain lookup, gets an HTTP 402 with x402 payment terms, pays $0.01–$0.03 USDC on Base, and gets source-linked JSON back in the same flow.

Live: https://scout-packs-production.up.railway.app
Code / MCP server: https://github.com/tigerops-win/scout-packs

Endpoints an Eliza agent can call today (all x402, Base eip155:8453):

Endpoint	What it returns	Price
GET /lookup?query=<company or domain>	Verified business email + source URL for that company (published emails only, never guessed)	$0.01
GET /domain-intel?domain=<domain>	RDAP registration + DNS infrastructure signals	$0.02
GET /tech-stack?domain=<domain>	Tech-stack detection from headers + markup, with confidence/evidence	$0.01
GET /email-pattern?domain=<domain>	Likely corporate email patterns + MX check	$0.01
GET /deliverability?...	MX/SPF/DMARC, disposable/role detection, bounce-risk score	$0.03
GET /dns, /headers, /ssl-check, /subdomains, /contact-page, /repo-health, /mail-provider, /packsize	DNS dump, security-headers grade, TLS details, CT-log subdomains, public contacts, GitHub repo health, mail provider, pack-size parsing	$0.01–$0.02

There is also an MCP server (15 tools, e.g. lookup_lead, domain_intel, tech_stack) for agents that prefer MCP over raw HTTP — same pricing, same settlement.

What a call actually looks like:

curl -s "https://scout-packs-production.up.railway.app/lookup?query=acme.com"
# HTTP 402
# {
#   "error": "payment_required",
#   "price_usd": 0.01, "currency": "USDC", "network": "eip155:8453",
#   "x402": { "x402Version": 2, "accepts": [{ "scheme": "exact",
#     "amount": "10000", "payTo": "0xaf7b…3913",
#     "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913" }] },
#   "how_to_pay": ["sign an EIP-3009 authorization and retry with
#     PAYMENT-SIGNATURE, or send $0.01 USDC and POST /fulfill-lookup
#     with {tx_hash, query}"]
# }

Two details that mattered in production, for anyone wiring this into an Eliza plugin/action:

1. 404 before 402. If a company isn't in the index, the lookup returns 404 with no payment terms — the agent never pays for a miss. Only pay when the 402 challenge confirms a match exists.
2. Replay protection is on our side. Manual-fallback tx hashes are single-use and older than 30 days are rejected, so an action can safely retry the redeem step without double-spending on data.

Receipts, kept honest: the API is live on Base mainnet and has settled real paid lookups from external agent wallets (2 paid / 2 distinct wallets so far — small numbers, stated plainly; this is a demand probe, not a traction claim). Unpaid requests are rejected with the 402 above, which you can verify yourself with the curl call — no wallet needed to see the challenge.

Happy to answer questions about running x402 in production (facilitator settlement vs. manual tx-hash redemption is a real trade-off), and genuinely curious: for Eliza builders doing prospecting / research / enrichment tasks, which of these would your agent actually call first — the verified-email lookup, or the domain-intel bundle? That answer decides what we package next.

— Tiger Operations

[houdaguang]

This is a clean instance of the buy side: agent needs data, pays per call, no account, no key. The sell side — an agent doing paid work for someone else — has the symmetric problem, and the answer rhymes: lock the budget in escrow on-chain before the work begins, release it on the client's explicit acceptance.

What we've learned running this loop for real: the hardest part isn't the settlement (USDC on Base handles that), it's getting the acceptance criteria written down before the agent starts, because that's what the release trigger points at. Without pre-stated criteria, every payout becomes a judgment call and trust erodes. x402-style receipts solve the "did money move" half; escrow + pre-stated acceptance solves the "was it worth it" half.

Building the sell-side version here: https://github.com/houdaguang/actn-agent-network