Every public interface, with its real state.

Ledger feed real

The public ledger as JSON. CORS *, cached 60 seconds. Champions appear only after countersignature; accounts are partners with a verified claim or a Champion or Ambassador tag.

GET https://nil33.com/api/ledger
→ 200 {
  "ok": true, "generated_at": "2026-10-07T12:21:42Z",
  "rules": { "compensation": "flat fee or unpaid, disclosed", "never": ["commissions","revenue share","percentage of client fees","anything tied to recovered funds"], "publish_gate": "countersigned agreement on file" },
  "champions": [ { "code": "…", "name": "…", "tier": "champion|ambassador", "systems": [...], "disclosure": "…" } ],
  "accounts":  [ { "code": "BUCK", "name": "…", "org": "…", "tier": "champion", "wallet": null, "wallet_verified_at": null, "since": "2026-09-08 20:19:25" } ]
}

Know Your Athlete verification partial

A signed assertion (ES256 JWS) per profile: namespace, tier, disclosure status, ledger status, guardian or agent authority, wallet binding. Verify offline with the published key. The gap: the government-ID step returns vendor not configured by design (flag F-30), so no profile is "KYA Verified" yet and the assertion says so.

GET https://nil33.com/api/v1/verify/{name}.nil        # free, rate limited; 404 for an unknown namespace
→ 200 { "ok": true, "jws": "eyJhbGciOiJFUzI1NiIsImtpZCI6Im5pbDMzLWt5YS0yMDI2LTA5Ii...", "claims": { "sub": "{name}.nil", "nil33Status": { "tier": "…", "disclosure": "…", "ledgerEntry": "…" }, ... } }

GET https://nil33.com/api/v1/profiles/{name}.nil      # public profile fields only
GET https://nil33.com/.well-known/nil33-verification.json   # issuer, endpoints, alg ES256, kid nil33-kya-2026-09, public JWK
GET https://nil33.com/.well-known/did.json                  # did:web:nil33.com, verificationMethod #nil33-kya-2026-09 (JsonWebKey2020)

Full onboarding API (private, token-scoped): /kya/api. Specification: docs/KYA-SPEC.md in the repository; boundaries in ADR-0006.

Signature receipts real

Every signed agreement stores the document digest and a chain hash over the previous record. The receipt endpoint recomputes the chain and compares digests on every call.

GET https://nil33.com/api/sign/receipt?id={id}&t={token}
→ 200 { "ok": true, ...record: id, code, doc ("ambassador"|"champion"), doc_version, doc_sha, signature_sha, prev_hash, chain_hash, signed_at, signer_name, signer_role, org, tier, intro_code, countersigned_at }
→ 200 { "ok": false, "error": "not_found" }           # unknown id or wrong token

GET https://nil33.com/api/sign/doc?doc=champion       # the exact versioned document text that was signed
Documents: /docs/champion-agreement, /docs/ambassador-terms (HTML); nil33.com/nil33/docs/*.txt (signed text)

Verification recipe: hash the document text (SHA-256) and compare to doc_sha; confirm chain_hash = H(prev_hash ∥ record) as the receipt page does; countersignature is what publishes the ledger entry. Design: ADR-0005.

Report pack real

A browser-only composition of the receipt, the matching ledger entry and the reporting clocks (Division I five business days from signed_at; junior-college and high-school transfer 14 days from an enrollment date; 3C2A 14-day notice). No server state. Deep link: /pack?id={id}&t={token}.

Metered API over x402 partial

Same records, no rate limit, paid per request in USDC on Base (eip155:8453) with x402 v2. A plain request answers HTTP 402 with an accepts array; retry with the payment header and receive the record plus a settlement receipt. State, plainly: every endpoint returns a correct challenge today (checked 2026-10-07). Settlement is configured through UnyKorn's own Genesis402 facilitator and the manifest reports settlement: live; no settled call has been published as a receipt on this site yet, so we label it configured, not proven (flag F-48).

GET https://nil33.com/.well-known/x402.json            # authoritative manifest: network, asset, payTo, prices, settlement state
GET https://nil33.com/api/x402/verify/EXAMPLE
→ 402 { "x402Version": 2, "accepts": [{ "scheme": "exact", "network": "eip155:8453", "amount": "10000", "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "payTo": "0x7d9a65d06dcc435a52D5880C6310Bd6E96c156DB", "resource": "…", "maxTimeoutSeconds": 60 }] }
# sign an EIP-3009 transferWithAuthorization for the amount to payTo (any x402 client library), retry with PAYMENT-SIGNATURE (v2) or X-PAYMENT (v1)
→ 200 { …record…, "settlement": { "transaction": "0x…", "network": "eip155:8453" } } + header X-PAYMENT-RESPONSE

Human page: /x402. Prices are configuration (X402_PRICES) and may change; the manifest wins. On-chain payments are final; a failed upstream call is not charged.

Payee identity, ERC-8004 real · self-registered

The payTo address is the wallet of UnyKorn's Genesis402 rail, which carries an ERC-8004 agent identity on Base: agent #95721. ERC-8004 is a self-registered public identity, not a certification; nobody vetted UnyKorn by letting it register. It gives a permanent public answer to "who is being paid, and what have payers said." Public feedback count as of 2026-10-07: 0. Ratings are shown only at ten or more; never self-seeded.

On-chain attestation of agreement digests gated

Writing each countersigned agreement's digest to a public chain so a third party verifies existence and integrity with no call to us. Designed; not switched on because it spends from a UnyKorn key not yet named (flag F-21). Until then the chain hash in the receipt is the interim answer.

How the systems fit checked 2026-10-07

NIL33 is the record layer. Around it sit the UnyKorn systems a program can already use, each with its real state. The pattern throughout is the same: hash the thing, commit the hashes in a Merkle tree, anchor the root on a public chain, and let anyone verify client-side without asking us.

One idea, applied everywhere: the record is hashed, committed and anchored so that the people who have to check it never have to trust the people who wrote it. Live the Dream's archive proves the method on real files today; XXXIII publishes it as an open standard anyone can adopt; NIL33 applies it to the agreements athletes sign. Timestamping the agreements themselves on chain is designed and waits on one named decision (F-21).

Platform import and export planned

NIL33 is the record beside the marketplace or disclosure tool a program already runs. Designed, not built: a consented import of a school's existing disclosures into the ledger, and an export of ledger entries plus receipts in the shape a clearinghouse or a compliance platform accepts. Proposed deal record (CSV or JSON), one row per agreement:

deal_id, athlete_namespace, athlete_code, school, level (D1|D2|D3|NAIA|NJCAA|3C2A|HS), payor_legal_name, payor_type (third_party|institutional|associated_entity|ambassador|agent|financial_referral),
agreement_type, compensation_type (flat_fee|unpaid), amount_usd, currency, term_start, term_end, deliverables, usage_window, exclusivity_scope,
signed_at, countersigned_at, guardian_signed (bool), disclosure_text, receipt_url, doc_sha, chain_hash, source_platform, source_record_id

Adapters for the two largest platforms exist as prior UnyKorn code (HTTP clients, not yet wired here). A program that wants to pilot this: hello@nil33.com.

Terms for integrators

Records are automated outputs of a signed-agreement system; they are not a compliance determination, not KYC, and not legal advice. Free endpoints are rate limited per IP and may change; the metered tier is priced before payment and settles on chain without refund. Do not rely on any single NIL33 output as the sole basis for an eligibility or compliance decision. Report a discrepancy to hello@nil33.com; a verified mismatch is published as a correction.

Source and change history: FTHTrading/blockchainfraud (worker, pages, ADRs 0002 to 0009, decision flags). Plain-language counterpart of this page: the transparency stack.