ledger integrity

Chain replay

Every claim has its own append-only chain. Replay recomputes each seal from the genesis rather than trusting a stored flag, so an edited or removed row is caught here. Tombstones are retained on purpose: deleting a claim must not break the history of the claim that existed.

genesis

8d9fb932a27d3851dc94fd9272980918345a9deb1427fe7b5eedd2df40122cdf4224c9c5fcaf1de0809f04decd861123

SHA-384 of a fixed salt

chains replayed

events verified

no broken links

per-claim replay

Replay result for every visible origin claim
claim	status	events	head seal	replay
USD Coin EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v	registered	1	272987cd…1dcac1	verified
Jupiter JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN	registered	1	705f705d…a008f6	verified
dogwifhat EKpQGSJtjMFqKZ9KQanSqYXRcF8fBopzLHYxdM65zcjm	registered	1	00179ebb…87fdb6	verified
Bonk DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263	registered	1	c3c250f7…2d2a77	verified
Raydium 4k3Dyjzvzp8eMZWUXbBCjEvwSkkk59S5iCNLY3QrkX6R	registered	1	0b4d034a…3b05e4	verified

the rule

genesis    = SHA-384(UTF-8("mintline/genesis/v1"))
seal(n)    = SHA-384( UTF-8(seal(n-1)) || canonicalJson(event(n)) )

canonicalJson  recursive key sort, stable arrays, ISO-8601 UTC,
                undefined dropped, non-finite numbers rejected

Because every seal commits to its predecessor, changing event 1 invalidates every seal after it. Replay stops at the first sequence number whose stored canonical form, prevSeal or seal does not reproduce, and names it.

Replay every chain over HTTP →