{"scope":"anchors","day":"2026-09-01","merkleRoot":"e90d58786ee53f06ceb0364a5a6351b81d6a3a3a376462d505fb83de404276b1","leafCount":2,"leavesStored":2,"leaves":[{"salonId":"cmj2w4mlb0004fti9apf9cftw","seq":8,"entryHash":"740ef0f493cee252172d1e3620f995d3624c3c43f418709657b00ce50f6b5d1f","leafHash":"8a7407b8d079bbe2742f05a468003e01bb26f201d86b6ef746d6ed2a1ae6ea94"},{"salonId":"cmmgouon00k01gpwkj57yah3i","seq":5,"entryHash":"6a8058eebb1d6c4625a06ae3a47a1203b71821cd95111843e9a6cd65fd49da6b","leafHash":"c8e94c919564034c4460278704a47f0d5f3fcda6e515ab21f466b3cb11227229"}],"leavesOmitted":false,"leafRule":"sha256(0x00 || canonicalJson({entryHash, salonId, seq}))","nodeRule":"sha256(0x01 || left || right); an odd node is PROMOTED to the next level, never duplicated (CVE-2012-2459); leaves sorted by salonId ascending","anchor":{"status":"SUBMITTED","calendar":"https://a.pool.opentimestamps.org","submittedAt":"2026-09-02T03:20:19.854Z","confirmedAt":null,"bitcoinBlockHeight":null,"bitcoinBlockHash":null,"bitcoinBlockMerkleRoot":null,"otsUrl":"https://primer.tech/api/public/reviews/anchors/2026-09-01/ots","otsBytes":237,"otsSha256":"31a24c025d068ccc88e48d66d4235414aa361a31b68a32cf973a0c2b7cf63878"},"endpoints":{"jwksUrl":"https://primer.tech/.well-known/jwks.json","anchorsUrl":"https://primer.tech/api/public/reviews/anchors","networkUrl":"https://primer.tech/.well-known/reviews-network.json"},"claimSources":{"leavesStored":"platform"},"disclosure":{"anchor":"Daily Merkle root over the per-salon chain heads, submitted to public OpenTimestamps calendars. SUBMITTED means a calendar accepted the digest; it is NOT a Bitcoin confirmation. CONFIRMED means the proof carries a Bitcoin attestation naming a block height. Note for anyone checking by hand: GET <calendar>/timestamp/<digest> returns 404 for genuine digests — the calendar indexes the commitment at the pending attestation, not the file digest — so verification is done from the proof, never by re-querying the calendar. TWO CALENDARS, TWO ROLES, because one word is doing two jobs: the calendar field published beside this note is the SUBMISSION endpoint the digest was handed to, which is a POOL address; the ATTESTING calendar is the one named inside the .ots proof at its pending attestation, and it is routinely a different host, because a pool answers from one of its members. A verifier that finds the two disagreeing has found an ordinary hand-off, not a contradiction. We publish the submission endpoint because that is the fact we hold; the attesting calendar is READ OUT OF THE PROOF, which is the checkable artefact and is served at the otsUrl beside this block. Neither name is evidence on its own: what a proof commits to is a Bitcoin block, never a calendar.","anchorTimestamps":"submittedAt and confirmedAt are OUR record of when the digest was handed to a calendar and when the Bitcoin attestation was first read out of the proof. They are platform assertions: an OpenTimestamps proof commits to a block, never to our clock, so nothing in the proof can corroborate either instant. What the proof DOES state — the block height and the merkle root it commits to — is published beside them and is checkable. The calendar is the one word here that names two different things, so both are labelled: the calendar field beside this block is the SUBMISSION pool the digest was handed to, OUR record like the two instants; the ATTESTING calendar is named inside the proof at its pending attestation, may be a different host, and is read out of the proof rather than from any field we publish.","signingKeySet":"This document is signed with the PLATFORM key on every origin it is served from, including a salon's own domain — a network-level fact does not become a salon's claim by being served there. So endpoints.jwksUrl points at the PLATFORM key set, which is the one that can check this signature; a salon origin's own /.well-known/jwks.json publishes the SALON key set and would answer UNKNOWN_KID for the kid below. The authoritative copy of this document, and the one a verifier should use, is the platform's: documentOrigin is inside the signed bytes, so the two origins are two different documents by design.","bitcoinBlockHash":"bitcoinBlockHash is recorded ONLY when a public block explorer corroborated the block height read out of the proof. NULL means \"not corroborated\", never \"no block\" — the proof itself is the evidence, the explorer is a second opinion, and a third party being unreachable is not evidence in either direction.","bitcoinBlockMerkleRoot":"bitcoinBlockMerkleRoot is the value the PROOF commits to, in OpenTimestamps internal byte order. Block explorers print it REVERSED. Reverse it byte by byte before comparing, or the comparison fails on a genuine proof.","leafCountVsLeavesStored":"leafCount is what the head row declared when it was written and is frozen at the database; leavesStored is how many leaf rows are on disk right now, counted over ALL of them and never capped. Both are published so a disagreement is visible to a reader rather than only to us. A THIRD number can differ from both: leaves[] is what this response publishes, and it stops at NETWORK_SALON_SCAN_LIMIT — so leaves.length < leafCount is a publication cap, while leavesStored != leafCount is a disagreement in the database.","leafSeq":"Each leaf carries seq: that salon's cumulative ledger position on the anchored day. It is REQUIRED — the leaf preimage is sha256(0x00 || canonicalJson({entryHash, salonId, seq})), so without it nobody outside this database could recompute the root published above. What it discloses, stated rather than glossed: for any salonId in the set, seq(day B) minus seq(day A) is that register's exact number of ledger entries between two anchored days — reviews, replies, response edits and withdrawals, removals and key anchors, added together. That is readable by anyone, for every salon in the set, on every origin this document is served from, including a competitor's. What it does NOT disclose: review text, ratings, which KIND of entry moved the counter, and any customer, staff or appointment identity."},"documentOrigin":"https://primer.tech","signedAt":"2026-09-02T19:44:34.691Z","signedBy":{"scope":"platform","custody":"platform","kid":"primer-network-2026-08-prod"},"signature":{"alg":"EdDSA","kid":"primer-network-2026-08-prod","origin":"https://primer.tech","signedAt":"2026-09-02T19:44:34.691Z","canonicalization":"sha256-canonicaljson-v2","sig":"k78uwUbuRlxGpuosxf4q_XqOIjpxda9FU38OI4xV1ORhCc_IWWyH1udWXesfZLIwOogr2ycLBQ_Ku0DJTanOCg"}}