Free side vs sealed side
Before pay you get marketing truth: outline, sample, price, category. After pay you get the sealed implementation files. Public teaser trees under /sealed/ are not a substitute for the paid unlock response.
What typically arrives
Responses include file names and contents for the pack (for example SKILL.md, configs, scripts). Treat them as versioned artifacts. Store by skill id and version if present.
Idempotent re-redeem
Networks drop. Browsers crash. Agents timeout. If your USDC transfer already succeeded, you should present the same txHash again to retrieve files rather than sending a second payment.
Design human UI and agent buyers around that rule. Double-pay is an ops failure mode, not a feature.
Integrity mindset
Where hashes or manifests are published, check them. Where they are not, pin what you received and record the tx. Trust is a chain: challenge, transfer, unlock, files, optional proof ledger row.
Bundles
Some products unlock multiple member skills in one payment. Response shape may include multiple sealed packs. Execution order, when documented, is guidance for agents composing workflows.
Practical storage
- Write files under skills/{id}/ with the txHash in metadata
- Never commit private keys next to packs
- Re-run unlock in CI only with test wallets and tiny canaries
Buyer story: flaky cafe Wi-Fi
You pay on mobile, the tx confirms, then the cafe portal kills your connection mid-download. Panic is optional. Open BaseScan, copy the hash, return to LVL, re-run unlock with that hash, and save files when you are on stable network. The chain is the source of payment truth; the download is a delivery step that can retry.
Agents should encode the same story as state machines: states PAID_PENDING_UNLOCK and UNLOCKED_INSTALLED are different. Only UNLOCKED_INSTALLED means you are done.
Anatomy of a good unlock response
A useful unlock payload names files, returns content or URLs, and ties back to skill id. Your installer should reject partial writes: write to a temp directory, fsync, then rename into place. Half-written packs cause worse failures than failed unlocks.
If content is large, stream carefully and verify length. If content is text, normalize line endings only if your runtime requires it; otherwise keep bytes intact.
Why re-redeem matters operationally
Imagine an agent unlocks during a deploy that dies mid-write. The money movement already happened. Re-redeem is the difference between an automated recovery and a human filing a support ticket with a txHash at 2am.
Humans hit the same issue on flaky mobile networks. Product UX should expose re-redeem clearly. Agents should implement it by default.
Security of sealed content
Sealed does not mean magical DRM that survives exfiltration. It means access control at distribution time. Once files are on disk, your OS permissions and secret hygiene matter. Do not commit sealed packs to public git repos. Do not paste them into random chats.
If a skill includes credentials templates, replace them with your secrets via environment injection. Never hardcode production keys into pack files.
Updates and repurchase
Policies differ by seller. Some updates may be free re-downloads; some may be new skill ids. Read listing text. Agents should not assume free lifetime updates unless stated.
Bundles and sealed_packs maps
Bundle unlocks can return multiple packs. Install each member under its own id. Honor execution_order when running workflows so dependencies exist before dependents execute.
Local inventory schema suggestion
{
"skill_id": "agent-x402-first-buy",
"txHash": "0x…",
"unlocked_at": "2026-07-22T00:00:00Z",
"files": ["SKILL.md"],
"source": "https://lvlltd.com"
}Keep this inventory next to your agent state store. It is the offline twin of /api/proof for your organization.
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.