Protocol

On-chain proof: /api/proof and BaseScan

LVL publishes confirmed unlocks. If the number is small, the number is small. That honesty is the point.

Audience: buyers, agents, auditors · Reading time ~8 min · LVL LTD

What /api/proof is

The proof endpoint exposes confirmed unlock activity: counts, volume in USDC, recent rows with skill ids, amounts, timestamps, and explorer links when available. It is an append-only style ledger of real settlements, not a marketing dashboard.

curl -s https://lvlltd.com/api/proof?limit=5 | jq .confirmed,.recent_unlocks

How to verify a row

  1. Copy txHash or explorer URL from the proof payload
  2. Open BaseScan and confirm USDC transfer details
  3. Match payee, amount, and time window to the skill price you expect
  4. Treat mismatches as stop-ship for automated buyers

What proof is not

Homepage stats

When the homepage shows unlock counts and volume, they should come from this ledger (server-rendered when possible). Empty or small is valid. Broken placeholders are not.

Agent usage

Agents can rank skills by confirmed demand via related signals endpoints when present, still grounded in real unlocks. Prefer free evaluation before paying for unproven skills.

Why public proof is rare and valuable

Most marketplaces hide weak sales. LVL chooses the opposite embarrassment: show the ledger even when it is early. That choice aligns incentives for agents that must decide whether a seller ecosystem is real. You can disagree with product direction; you should not need to guess whether unlock numbers were invented.

If you are a seller, public proof also keeps you honest in your own marketing. Cite proof rows, not vibes.

Confirmed versus noise

Anyone can claim "we did volume." Proof endpoints that only count button clicks are marketing. LVL's public stance is confirmed unlocks after verification. That means early markets may look small. Small and true beats large and fake for agent trust.

When you build dashboards on top of LVL, mirror that vocabulary. Do not rename confirmed volume to "GMV" without defining it.

Reading the JSON

Typical fields include confirmed.unlock_count, confirmed.volume_usdc, recent_unlocks[], last_successful_agent_purchase, and by_skill aggregates. Clients should tolerate additive fields. Prefer confirmed.* then fall back carefully to activity.* if present for compatibility.

curl -s "https://lvlltd.com/api/proof?limit=3" | jq "{ok, confirmed, last: .last_successful_agent_purchase}"

Per-skill filtering

When supported, skill filters help you audit a single product. Sellers care about their id. Buyers care that their unlock eventually appears. Indexing delay is possible; absense for a few minutes is not always failure.

BaseScan correlation

For each recent unlock with an explorer URL, open it and confirm token transfer. Train new team members on this once. After that, spot-check monthly or after incidents.

Homepage and SEO honesty

LVL invests in server-rendered stats so crawlers do not see empty dashes. If you fork the design, keep the rule: real or absent, never fake. Agents reading HTML stats should still prefer /api/proof as canonical.

Building agents that rank by demand

Signals and shop endpoints may expose demand ordering derived from confirmed unlocks. Use them as priors, not as proof of quality. A free outline still beats a popular bad skill.

Field notes from live rails

Everything in this guide is meant to match production behavior on lvlltd.com: free outlines at /skills/{id}/outline.json, challenges at /api/pay, settlement in USDC on Base chain ID 8453, unlock proofs that can be checked on BaseScan, and a public ledger at /api/proof that refuses to invent volume. If a third-party article disagrees with those primary surfaces, trust the primary surfaces.

When you teach teammates, walk them through one canary unlock before any architecture debate. Shared scars on a $0.05 purchase create better systems design conversations than slides alone. Keep notes on what confused people; those notes should become checklist items in your internal runbook and, if you sell skills, clearer outline text for the next buyer.

Finally, remember the integrity line that LVL repeats for a reason: understanding is free; sealed capability is optional and paid. Education pages like this one should make you more demanding, not more impulsive. Read outlines. Allowlist addresses. Prefer small spends first. Verify. Then scale.

Related live checks

After reading, run at least two live checks: open the free outline for a skill you care about, and open /api/proof. Optionally issue a pay challenge with curl and confirm you see HTTP 402 with amount and payTo fields. Those three actions connect this article to production reality in under two minutes.

If you maintain internal wiki mirrors of these guides, include the canonical URLs on lvlltd.com so agents and humans can detect drift. Canonicals and llms.txt exist so education stays discoverable next to commerce, not buried in a slide deck.