Do not take our word for it. Recompute it.

Recompute our receipt chain

Our deploy receipts are hash-chained. The endpoint publishes the algorithm alongside the data, so you never have to run our code to check our claim — write your own, which is the point.

# 1. Fetch the feed.
curl -sS https://steadywrk.app/api/public/receipt-chain -o chain.json

# 2. Rebuild the head. chain.json.algorithm states the rules in full:
#      leaf   receipt_hash = SHA256(canonical_json(receipt))
#      link   chain_n      = SHA256(chain_{n-1} | n | ts | receipt_hash)
#      order  sorted by (ts, phase, receipt_hash) ascending
#    Then verify the head signature against the LITERAL pin below —
#    never against the key the response hands you. Rebuild the payload
#    as  count + '|' + head  and call:
#      crypto.verify(null, payload, spkiKeyFromPin, sig_b64)

# 3. Confirm the DID advertises that same key.
curl -sS https://steadywrk.app/.well-known/did.json
#    base58btc-decode the #receipt-chain-ed25519-v1 multibase, strip the
#    leading 0xed 0x01, and compare those 32 bytes to the last 32 bytes
#    of the SPKI pin.

# 4. A credential — once one exists. Nothing to check here yet.
#      crypto.verify(null, utf8(content_sha256), pinnedKey,
#                    base64url(ed25519_signature))
#    The fingerprint is signed as raw UTF-8, with no domain prefix.

An independent checker given only these URLs — and no access to our code — did this on 2026-08-11 and reproduced our published head exactly, with all links agreeing.

Step 2 says never against the key the response hands you, and that is the whole discipline. A signature checked with a key fetched from the same response proves only that the response agrees with itself. Pin the key first — from this page, from an earlier run, from anywhere you already had it — and check against that.

Check the signature — and know what it buys

The chain head is signed with Ed25519 over the exact string `${count}|${head}`, key id receipt-chain-ed25519-v1. The public half:

MCowBQYDK2VwAyEAs7p9TfaWI8zE21UVGE2nF1y1puZuRF2lHV2Fa7VRcJY=

The same key appears in /.well-known/did.json as #receipt-chain-ed25519-v1, encoded as multibase. You can confirm they are the same key without trusting either page: take the last 32 bytes of the base64 SPKI above, prepend the ed25519-pub multicodec bytes 0xed 0x01, base58btc-encode, prefix z.

A signature binds a key-holder to a head. It does not bind a head to a history, and it does not say the work described was done well. Read the next section before you count it for more than that.

What you cannot check yet

This section is not a disclaimer. It is the part of the page we would remove if we were optimising for how we look, so it is the part worth reading first.

That the key signing our chain is really ours.

You can only get that key from us today. Our repository is private and our verifier is not published to a package registry, so every copy you can reach is served by steadywrk.app. Checking our signature with our key proves our response agrees with itself — which is worth less than it sounds. This is the single biggest gap on this page and we are not going to describe it as anything smaller.

That our history was never rewritten.

A chain served next to the data it commits to proves internal consistency at this moment. We timestamp each head with two unrelated time-stamp authorities, but those tokens live in a private repository and you cannot download them yet. Until you can, record a head yourself and re-check it later — you holding an old head is currently the strongest check that exists.

That an issued Trust Rail credential is verifiable by a third party.

Signing has been armed since 2026-08-10 and the first signed credential is still pending. Separately, there is no public feed of issued credentials — /verify answers per-serial for someone already holding a serial and PIN, so you cannot enumerate or independently recompute the set.

That our published metrics are audited.

They are not. They are self-reported and estimated from our own telemetry, traced to a single source with a build gate that fails on drift. That is consistency, not an auditor’s stamp. See /proof/attestation, which also lists the claims we have retracted.

Every public surface, in one list

No account, no key, no permission. If one of these stops answering, that is itself a finding.

• /api/public/receipt-chain

  The signed, hash-chained deploy receipts. Carries its own algorithm description, so you can rebuild the head without our code.

• /.well-known/did.json

  The DID document. Publishes the public key that signs the chain, in multibase form.

• /api/public/trust-rail/key-registry

  Which signing keys are registered, when they were activated, and whether any were revoked — the state that decides whether issuance signs at all.

• /api/public/audit-receipts

  The same receipts, unsigned and openly saying so. It defers to the chain above rather than offering a second thing to trust.

• /sijill

  The human-readable register the chain commits to.

Looking for something else?

• Holding a STEADYWRK document with a serial and a PIN? /verify checks that specific instrument.
• Want to know where a published number came from? /proof/attestation traces every metric to one source, and lists the claims we retracted.