§ verify · example

what a receipt looks like.

every time a site records something you did, it produces one of these. this one is an example — run the verifier on it, then read your own at /verify.

§ this is an example

nobody earned these sats. the site, the identity and the moment are invented, and example.invalid is a reserved name no integrator can ever hold. what is real: the split below comes from the same pricing function a live event uses, the bytes come from the same canonical encoder, and the signature comes from the same me.ochk.io envelope key. the cryptography you are about to run is the production cryptography.

§ the receipt

Example Notes · example.invalid

authorized a scoped action · publish a note

what the site recorded

Tue, 01 Sep 2026 14:02:11 GMT

when

did:oc:example

paid to which identity

240 sats

the site paid

48 sats

orangecheck's platform fee

168 sats

the person earned

24 sats

rebated to the site

the four add up: the site's price is the whole of it, and the split is orangecheck's, inside published bounds. no sat appears from nowhere.

§ live verifier · oc-me-example-receipt

01 · fetch /api/envelope/[id] (canonical bytes)
idle
02 · sha256(bytes) — content digest (informational)
idle
03 · fetch envelope JWKS from /.well-known/oc-envelope-jwks.json
idle
04 · ed25519.verify(sig, bytes, public_key)
idle

> every byte you see here is on your machine. the canonical envelope bytes come from /api/envelope/[id], the JWK is fetched live from /.well-known/oc-envelope-jwks.json, the hash is computed by @noble/hashes in your browser, and the Ed25519 signature is verified by @noble/curves — no OC server is in the verification path beyond serving the static bytes.

§ what step 02 checks, and what it does not

a billable event's id is a routing id assigned when the event is recorded, not a hash of its contents — so step 02 reports the digest of the bytes and has nothing to compare it against. step 04 is the one that binds: it checks the signature over those exact 358 bytes against the key the JWKS publishes under oc-me-envelope-4dc2f420. content-addressed envelopes — rebinds, payout bindings, distributions — do get the equality check, and /verify renders it for them.

§ envelope · canonical json

{
  "v": 1,
  "kind": "oc-me-event",
  "class": "B",
  "subtype": "scoped_action_authorization",
  "identity": "did:oc:example",
  "site": "example.invalid",
  "gross_fee_sats": 240,
  "platform_fee_sats": 48,
  "user_earned_sats": 168,
  "site_rebate_sats": 24,
  "occurred_at": "2026-09-01T14:02:11.000Z",
  "context": {
    "kind": "B",
    "subtype": "scoped_action_authorization",
    "action_label": "publish a note"
  }
}

these are the bytes the signature covers, in the order they were signed. fetch them yourself at /api/envelope/oc-me-example-receipt — the response body is the bytes, with no wrapper to strip.