quoted on the rail
The book. Your mint. A proof row.
Two paid calls and one unpaid proof. Filters on the book are yours: min liquidity, max top-10, min holders, min age. Percentiles stay against the full complete set. Priced in dollars. Pay in XRP on XRPL or USDC on Base; each payment buys one response.
now, watched, versus_book, kin. Optional filters: min_liquidity, max_top10, min_holders, min_age_days, limit. Not every mint on Solana — every mint we currently hold a complete set for.
Live candles and chain data, placed against the book. Watched is filled when we have been tracking it, else named absent. Kin includes sibling mints. No pool means no_data; nothing is charged until you pay, and a paid miss is named, not refunded.
unpaid
One proof row.
The same now / watched / versus_book / kin row as the paid book,
including cap, FDV, mint/freeze, disappeared, seen-count, and kin.
Percentiles against the full complete set, not against this one name.
/sample/crypto.
loading sample…
start here
Point an agent at it.
No signup. The 402 challenge is the entire onboarding — your agent asks, gets quoted, pays, and receives. Read the contract first if you prefer.
what you are buying
The join is the product.
Price is free. An agent that wants a print does not need this shop.
What costs money to assemble is the rest, in one object: how many wallets hold it, what share the largest ten control, organic score, and — the part no other API has — what happened to liquidity while this desk was looking, plus where that name sits against every mint we currently hold a complete set for, and how many other mints this desk grouped with it.
Mint and freeze ship on the stored row. /history/crypto
is the tape of when they flipped. /book/crypto is the climate
of the complete set, unpaid.
who this is for
Your agent has rules. It does not have a join.
An agent that already knows how it wants to filter a universe still has to fetch price, holders, concentration and a history from different places, then place each name against the others. That work is this shop.
Several HTTP calls and a reduce step before your own gates can run.
One 402. now, watched, versus_book. Then your filters: min_liquidity, max_top10, min_holders, min_age_days.
Percentiles stay against the full complete set. Filtering the book down to a handful does not make that handful look like the market.
No signup, no API key. The 402 challenge is the whole onboarding.
/llms.txt
and /schema and /sample/crypto. Same shape as the paid body.
Structured JSON. Absent fields named as absent.
what the pack collapses
One row, fully joined.
now, watched, versus_book — in one call. The JSON below is a live unpaid proof row, not a mock.
solana · measured book
The complete set
loading…
integration
Four moves, no onboarding.
x402. Pay in XRP on XRPL or USDC on Base. Same USD price, one response. The 402 lists both rails in accepts[].
Your agent GETs the
resource with no payment. It gets 402 and a quote in the
PAYMENT-REQUIRED header — amount, asset, address, invoice id.
It picks one
accept — XRP on XRPL or USDC on Base — signs that rail, and retries with
the blob in PAYMENT-SIGNATURE.
The facilitator for that rail verifies and settles. We never touch a key — we only ask whether it happened.
The body returns,
with the settlement receipt in PAYMENT-RESPONSE. That hash is spent;
it cannot buy a second response.
# the whole integration
curl https://daxpt.com/llms.txt
curl https://daxpt.com/sample/crypto
curl https://daxpt.com/pack/crypto?scope=measured # 402
curl https://daxpt.com/pack/crypto?scope=measured&min_liquidity=100000&max_top10=30
curl -H "PAYMENT-SIGNATURE: $BLOB" \
https://daxpt.com/pack/crypto?scope=measured
# one mint you name
curl https://daxpt.com/measure/crypto?address=MINT # 402, $0.15
the 402 challenge
Pay on XRPL or Base USDC, or do not pass.
Every rejection names the stage that rejected it, so a caller knows whether to fix their encoding, their signature, or stop replaying a spent payment.
how a refusal is reported
loading…
What this merchant holds, and what it does not
Two receiving addresses and nothing else: one on XRPL for XRP, one on Base for USDC. No signing key exists on this machine. Settlement is performed by the facilitator for the rail the buyer picked; this server only asks whether it happened.
If the facilitator cannot be reached, the request is refused, not served. A paywall whose failure mode is “let them through” is not a paywall.