Check this ledger yourself
Everything below runs on your machine, against bytes you fetch, with no dependency on this app’s code. That is the point: a verdict served by the issuer of the sashlings proves nothing to someone who does not already trust the issuer.
Check it right here
Fetches the sealed events and the realm key from this app, then re-derives everything from the signed bytes: seals verified with WebCrypto, each Sashling’s seed recomputed from its threshold signature, and ownership replayed from scratch.
It is code this site wrote and served. Anyone able to forge a Sashling could also serve you a verifier that says everything is fine. It is here because nobody installs Node to check a collectible — but if it matters, run the standalone script below and compare. Two independent implementations agreeing is evidence; one is not.
1. Fetch the ledger and the verifying key
curl -s http://localhost:3000/api/ledger > ledger.json curl -s http://localhost:3000/api/realm-key > realm-key.json
2. Run the standalone verifier
scripts/verify-ledger.mjs imports nothing but Node’s own crypto, so you can read all of it before you run it. It deliberately uses a different SHA-256 implementation from the app’s, because a verifier that shares the app’s hash function cannot detect a bug in that hash function.
node scripts/verify-ledger.mjs ledger.json realm-key.json
A hatchling’s parts, and where each came from
An egg-hatched Sashling takes each part from one of its two parents. Those parts are hashed into a small Merkle tree, so you can prove one part’s parentage without being handed the rest of the creature — sixteen parts means four hashes.
curl -s "$APP/api/lineage?id=<sashling id>" | jq .
# for any part, the leaf is:
# sha256("leaf|<index>|<part>|<value>|<fromParent>")
# then fold the proof path in, one step at a time:
# sha256("node|<left>|<right>")
# and compare the result with genomeRoot.why a tree rather than one big hash?
Hashing everything together would let you check the whole genome or nothing. A tree lets somebody prove these ears came from Pip on its own. Two details matter for that to be worth anything: leaves and internal nodes are hashed with different prefixes, so an internal node can never be passed off as a part; and a lone node at the end of a level is carried up rather than hashed with itself, which is the flaw that let two different sets of parts share one root.
Nothing extra is sealed for this. A Sashling’s id is its seed and the parents’ ids are on the mint event, so every value is recomputed from the chain — if this page disagreed with your own arithmetic, your arithmetic would be right.
Rarity is not inherited. It stays a fresh roll from the child’s own seed, so two legendary parents cannot pass that on, and every rarity on the ledger still means what it says.
What it checks, and what it cannot
- each envelope parses and its binary header agrees with the signed JSON inside it
- each seal verifies as a 64-byte Ed25519 threshold signature under the realm’s key
- each sashling really is the one its seal produced — the seed is re-derived from the signature, so a record cannot claim a legendary the network never minted
- the proof-of-work matches the difficulty each event declares
- every link — each event’s prevHash is the hash of the one before it, and heights and timestamps advance
- every trade was legitimate — the ledger is replayed from the start, so a swap of something the offering party did not own at that moment is rejected
- the readable records match the signed bodies — the convenience fields served alongside each event are cross-checked against what was actually sealed
The ORK network makes each event unforgeable: nobody can mint or trade in someone else’s name, backdate one, or complete a trade the other party did not approve. It cannot check whether a trader owned what they traded — a contract sees one request and no history. That is what replaying the ledger answers, and it answers it the same way for everyone, including someone who does not trust this app.
A signature binds bytes to a key, never to a human. The verifier can tell you that vuid X sealed a block; it cannot tell you that vuid belongs to the person in front of you. Closing that gap needs a live challenge — have them sign in, or sign a nonce you choose, while you watch. The verifier reports this as SKIPPED rather than quietly counting it as a pass.
/api/realm-key is served by this app — the issuer of the blocks you are checking. TideCloak does not publish the realm verifying key unauthenticated, so there is no independent source to fetch it from. Pin it on first use and corroborate it against another holder of the realm’s adapter before treating a verified signature as evidence against the issuer. And do not substitute the OIDC JWKS endpoint: it returns 200 with a valid key set containing entirely the wrong key.
Download the whole ledger — keep your own copy. Every seal in it verifies without trusting this server, which means copies in strangers’ hands are a safety net, not a leak.