Example: a first batch of crypto-native listings

The strongest opening wedge for the marketplace is on-chain / crypto data — it’s real-time (value decays in seconds), verifiable (checkable against the chain), and native to the payment rail (you’re already settling in USDC on Base). It also sidesteps the licensing minefield of resold proprietary data.

This page sketches four concrete listings end-to-end on the current stack — the exact create_api_relay calls, what the buyer gets, and which platform features each leans on. Everything here uses primitives that ship today (parameterized relays, freshness_critical, samples, on-chain settlement).

Pattern for all of these: you run a tiny HTTP origin (a few lines over an RPC or a data API you have rights to); the relay wraps it, forwards the buyer’s params into the path/query, settles the payment, and returns your JSON. You set freshness_critical=true on the real-time ones so a buyer is never served a stale cached value.

1. DEX token price + liquidity (real-time · category 1)

Spot price, 24h volume, and pool depth for a token on Base right now — decays in seconds, so buyers can’t download once and be done.

create_api_relay(
  name="Base DEX token price + liquidity",
  slug="base-dex-price",
  origin_url="https://your-origin.example/dex/{token}",   # {token} filled from params
  method="GET",
  price_usd="0.004",
  networks=["eip155:8453"],
  pay_to="0xYourPayoutWallet",
  freshness_critical=true,        # never serve a stale price
  trial_safe=true,               # read-only → enables the synthetic sample + free trials
  sample_request={"token": "0x4200000000000000000000000000000000000006"},
  description="Spot price, 24h volume, and pool depth for a Base token, live from on-chain pools.",
  public_listing=true
)

Buyer calls …/r/you/base-dex-price?token=0x… (or connector call_endpoint(params={"token":"0x…"})). Leans on: param forwarding, freshness_critical, per-call micropayment.

2. Gas / priority-fee estimator (real-time · category 1)

Current Base gas in gwei with fast/standard/slow tiers + estimated confirmation time. A canonical agent lookup (“what should I set as maxFee right now?”).

create_api_relay(
  name="Base gas + priority-fee estimator",
  slug="base-gas",
  origin_url="https://your-origin.example/gas",
  method="GET",
  price_usd="0.002",
  networks=["eip155:8453"],
  pay_to="0xYourPayoutWallet",
  freshness_critical=true,
  trial_safe=true,
  description="Live Base gas in gwei (fast/standard/slow) + estimated confirmation time.",
  public_listing=true
)

Leans on: freshness_critical, cheap per-call pricing (well above the $0.005 floor? no — this is below it, so the buyer pays the floor; price it knowing that, or bundle).

3. On-chain wallet analytics (verifiable · category 5)

Given an address: balance, first-seen block, counterparty count, top tokens. Every field is checkable against the chain, which removes the “can I trust an unknown seller?” friction — the buyer can verify, so they’ll pay.

create_api_relay(
  name="Base wallet analytics",
  slug="base-wallet-analytics",
  origin_url="https://your-origin.example/wallet/{address}",
  method="GET",
  price_usd="0.02",
  networks=["eip155:8453"],
  pay_to="0xYourPayoutWallet",
  trial_safe=true,
  sample_request={"address": "0x2Bc3d022f56aDEf841259fDBAefdD9AFAe6c3950"},
  description="Balance, first-seen block, counterparty count, and top tokens for a Base address.",
  public_listing=true
)

Not freshness_critical — wallet history changes slowly, so the cache-fallback is a feature here (reliability), not a footgun. Leans on: verifiable data + the sample preview so agents evaluate the shape before paying.

4. Transaction-receipt verification (verifiable · category 5)

Confirm a tx hash settled, with block + amount + status — the buyer can re-check it on-chain, so it’s high-trust. Useful glue for agent workflows (“did my payment land?”).

create_api_relay(
  name="Base tx-receipt verify",
  slug="base-tx-verify",
  origin_url="https://your-origin.example/tx/{hash}",
  method="GET",
  price_usd="0.003",
  networks=["eip155:8453"],
  pay_to="0xYourPayoutWallet",
  freshness_critical=true,        # a pending→confirmed flip must not be cached
  trial_safe=true,
  sample_request={"hash": "0xe1cd9bacfd6a6d7e9b48a10e0fb4051f44a8f3f3e90350bcfc6ee116a8a62562"},
  description="Confirm a Base tx settled: block, amount, status — checkable on-chain.",
  public_listing=true
)

Why this batch

• Hits three of the five data categories at once — real-time + verifiable + native to the rail.
• No licensing risk — it’s public on-chain data you transform, not resold proprietary feeds.
• Recurring demand — real-time feeds (1, 2, 4) are re-bought constantly; analytics (3) is the moat once there’s traffic.
• Self-seedable — these origins are a few lines over a Base RPC (Alchemy), so the marketplace operator can seed the first ones rather than wait for sellers.

Pricing note

Several of these (#2 gas at $0.002, #4 at $0.003) price below the $0.005 fee floor, so the buyer pays ~$0.01 total (floor-dominated). For sub-cent feeds, either price at ~$0.05+ (so the 10% fee applies cleanly) or accept the floor as the cost of settling a micro-payment on-chain. See the Rate card.

What’s still needed (not blockers)

• A per-response data-age / max-staleness field (so a buyer sees “this value is ≤2s old”) would strengthen category 1 further. freshness_critical removes the stale-fallback footgun today; a positive freshness guarantee is the next step.
• For signed oracle listings, the seller just includes the signature in the JSON; a first-class “proof” field + a verify helper would be a nice future addition.