Walk the Log

Signed receipts are appended to a public, append-only transparency log. The log publishes a signed checkpoint naming its size and root hash — so the history of what was minted is something you can hold us to, not something you take on trust.

Fetch the checkpoint

bash

curl -s https://api.bluefoxedge.ai/v1/transparency/checkpoint

The response lists each log with its latest checkpoint — a signed note in the C2SP checkpoint format: the log's origin line, the tree size, the root hash, and a signature line. It also prints the operational cadence config (checkpoint interval, batch bounds, the per-IP proof cap) so the numbers you plan against are the served ones, not copied ones. The receipt log's id is reliance/v1, origin edge.bluefox.ai/transparency/reliance/v1.

Find the published sizes

Consistency proofs run between published sizes — the sizes the log actually folded at — and which sizes those are is one GET, never a guess:

bash

curl -s "https://api.bluefoxedge.ai/v1/transparency/checkpoints/history?log_id=reliance/v1&limit=100"

Newest first, paged with before=. The values in that list are unsigned conveniences and the response says so in its own bytes: the signed artifact is the checkpoint note, one GET away at /v1/transparency/checkpoints?log_id=&size= — take a proof's numbers from a note, never from a list.

Check consistency between checkpoints

Append-only means a later checkpoint must extend an earlier one — never rewrite it. RFC 6962 consistency proofs let you check exactly that between any two published sizes, and the whole first-day walk is four commands — list the sizes (above), pick two, fetch the proof, run the published checker offline against a key set you pinned yourself:

bash

curl -s "https://api.bluefoxedge.ai/v1/transparency/consistency?log_id=reliance/v1&from=<older>&to=<newer>" > consistency.json
curl -sSo pinned-jwks.json https://api.bluefoxedge.ai/.well-known/jwks.json
curl -sS -O https://api.bluefoxedge.ai/verify_consistency.py
python3 verify_consistency.py --jwks pinned-jwks.json --file consistency.json

Exit 0 means the newer tree contains the older one as an unchanged prefix — the response carries both signed checkpoint notes and the checker verifies them before it trusts a single number. Keep the earlier note: if a later checkpoint ever fails consistency against it, you hold the evidence. from == to is the defined trivial case (an empty proof path, trivial: true).

Pinning the log's key, and which door the pin names. The key set above is what the checker reads. The log's verification key also has a canonical one-line form — the C2SP vkey — served at its own door: https://edge.bluefox.ai/transparency/reliance/v1/vkey (the API host serves the same bytes). A published sha256 pin of this log's key is taken over that door's response body exactly as served — all 95 bytes, the vkey line together with its trailing newline. Hash the bytes, never a copy of them:

bash

curl -sSf https://edge.bluefox.ai/transparency/reliance/v1/vkey -o vkey.txt \
  && shasum -a 256 vkey.txt

Two ways to get a different answer, both easy to reach by accident. First, strip the newline — with tr -d, or by capturing the body in a shell $(…), which drops trailing newlines — and you hash 94 bytes, not 95. The -o above writes the bytes as served, and -f keeps a refusal out of the file: without it a 404 problem document would be hashed like any other body, and a wrong digest looks exactly like a right one.

Second, reach for /.well-known/jwks.json. The key set publishes the same 32 key bytes under bfx:purpose: "log", so it is the same key — but the pin is not a digest of that key set or of any member of it. Its kid is a sha256 of the raw key, not of the vkey line. You can rebuild the vkey line from those bytes — key name, algorithm byte, key hash, base64 — and hashing it does give the pin, because it is the same line. But that means reconstructing, correctly, exactly what this door already serves. Take the bytes from the door.

Any non-servable ask — an unknown log, an unpublished size, an inverted range — returns one identical 404 by design: the error shape leaks nothing about interior activity.

What the log does and does not publish

The log publishes checkpoints, the size index, and consistency proofs — enough for anyone to hold the operator to an append-only history. It deliberately publishes no browse-everyone's-receipts index: receipt contents stay with the account that minted them, and the per-receipt inclusion proof at /v1/transparency/inclusion is fenced by possession — it answers only to a caller presenting that receipt's own chain_self (or its receipt id), so a holder can prove their own entry without anyone browsing anyone else's. Verifying a receipt you hold never needs the log at all — see Verify a Receipt.

Paid for a receipt? The payment count at /v1/transparency/payments answers how many entries in the log are bound to one settlement transaction — the number you want to be 1. It takes the transaction hash and a receipt-derived key together, because a transaction hash is public on its own chain and must open nothing alone; the answer is a count plus a membership assertion, never a list of receipts. What a count of 1 proves: exactly one entry in this append-only log binds your payment, as of the read. What it does not prove: the count is scoped to receipts admitted to the log — the response itself publishes how many receipts predate admission and can never be counted — and it says nothing about the payment's validity on chain, which the chain answers directly.

Back to Quickstart →