Keysingate

nam@keysingate.com https://github.com/keysingate

General journal seal anchoring Merkle tree blind anchor A Keysingate container keeps a work journal: pages without signatures, closed by one portable seal that covers every page before it and is moved forward by each new record. This document specifies the journal's pages, records and seals, the two forms of a journal (unanchored and anchored), the two exports a third party receives -- one page with its proof, or the whole journal once -- and how a verifier checks them without contacting anyone. It also specifies a profile for anchoring seals in Solana with a blind memo that shows outsiders only the fact of a write. The core documents, time format and anchor rule it relies on are those of draft-nam-ksg-core-00.

Introduction A page carries no signature; a record of up to 99 content pages and a service page is closed by one seal; the seal covers the whole chain of pages up to it; an anchor gives a record its time bound and its force. One verifier procedure reads both exports. The container itself -- how it is built, who presses what, how its keys are held -- is not specified here. A verifier sees only pages, seals and anchors.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The canonical form, document hash, signatures, time, limits and the Bound Rule are those of . All documents here carry "@context": "urn:keysingate:core:v3" and "v": 3; v is the journal format's version, which today equals the core's and may move separately.

Page:

Room for content, up to 2 048 bytes; no signature.

Record:

The unit of writing: content pages and, when there is more than one page, a service page; one time mark; one seal.

Seal:

A signed statement that closes a record and covers all pages before it.

Agent, owner:

The two parties of a journal, each known by keys pinned in the journal itself.

Layout A journal has 1 + 1000 + 100 + 2 places: page 0 (the opening); 1 000 working pages; 100 pages of the transfer zone (changes of owner); 2 coupling pages. All zones form one chain of pages in the order of writing.

Pages

• seq -- the page's place in the one chain; page 0 is the opening;
• zone -- opening, work, transfer or coupling; slot -- the place within the zone, from 1 (0 for the opening);
• batch -- the record the page belongs to: its number (id, the opening is record 0), the page's place in it (index) and the record's page count (of);
• offset_ms -- one value for the whole record;
• prev -- the hash of the previous page; for page 0, the container identifier .

The page hash is the core document hash of the page.

Bodies

Body	Content
opening	container, mode (the form the journal opens in), agent and owner as {id, keys} -- pins both parties' keys
content	kind (work, artifact_or_rights, shares_declared_lost, hash_binding), content (inline base64url bytes or digest), optional content_type URI
manifest	the service page of a multi-page record; always its last page
transfer	a hand-off between agents (work zone) or a change of owner (transfer zone)
coupling	one of the two coupling places
rule	the rule of two seals, set or lifted
form	to: the form after this page
repeat_confirmation	the journal's confirmation of ten identical records

A content piece commits as SHA-256("ksg:bound:inline:v1" || bytes) or SHA-256("ksg:bound:digest:v1" || digest) -- plain concatenation, the label being fixed. A record's hash is SHA-256(F("ksg:bound:record:v1") || F(c1) || ... || F(cn)) over the commitments of its pieces in order, with F (length-prefixed field) as in . A record is at most 99 content pages and 204 800 bytes.

Seals

• number -- the seq of the record's last page: every page written;
• head -- the hash of that page;
• root -- the Merkle tree head over all pages from page 0, each leaf being SHA-256(0x00 || page hash);
• prev -- the hash of the previous seal; absent only on the opening's seal;
• rule -- present while the rule of two seals is in force: its hash;
• signatures -- by the current agent, Ed25519: a seal passes only if it is present and valid under a key pinned in the journal (page 0 or the latest transfer page), never a key the presenter brings. The post-quantum signature is not on the seal: it is on the container as a whole, outside this export (see Security Considerations).

Every seal covers the whole chain before it, so a later seal confirms the pages of every earlier record.

Further Seals

• Transfer seal (TransferSeal: page, subject, signatures): a hand-off is sealed by both agents; a change of owner by agent and owner on both sides. Never removed. The new agent replaces the old one; the old one seals nothing afterwards.
• Co-seal (CoSeal: batch, subject, signatures): the owner's second seal on a record. Required in the anchored form for artifact_or_rights, and for every record while the rule of two seals is in force; a record that needs it waits, and nothing else is written meanwhile.
• Coupling: each of the two places is written once; place 2 names the coupled container and its last seal.

Forms

Form	Anchors
local	none; a seal MUST NOT be anchored
pro	every seal MUST be anchored

The form changes only by a form page sealed by the owner as well, in either direction, as long as pages last. Going to pro, the seal of that page is the first anchored one; an anchor made before the owner's seal on the change MUST be rejected. Without the owner, a journal stays local. Force. A record has force when its seal is anchored. Two records' link is confirmed when both are anchored and no unanchored record lies between them. A report names the runs of consecutive anchored records.

Exports

Final Export The whole journal, once; the container works no more after it. Empty arrays are omitted.

Pointwise Export One page with its inclusion proof under the current seal and, in the anchored form, the seal's anchor: At most 12 pointwise exports per journal.

Verification Input: the export, the container identifier, the class (or the channel it derives from, ), the agent's keys from the verifier's own source, a profile, network readers. Final export. The verifier replays the journal from page 0 by the same rules that wrote it:

1. limits, then strict parsing of every document;
2. page 0 is the opening, prev is the container identifier, its pinned agent keys equal the ones the verifier holds, its form agrees with the class;
3. every page links to the previous one; zones, slots and records are in place; every record's pages and service page agree;
4. every seal is recomputed from the pages (number, head, root, counts, parties, form, rule, prev) and its signatures verified under the pinned keys; transfer seals and co-seals where the rules require them;
5. in pro, every seal has an anchor, read by the Bound Rule; in local, no anchor is accepted;
6. the report: number of pages, the current agent and owner, the form, transfers, co-sealed records, each record with its seal and whether it is anchored, the anchored runs with their bounds, and an explicit list of what is not established.

Pointwise export. The page's hash is included under the seal's root at seq; the seal's signatures verify under the agent keys the verifier holds; in pro, the anchor is read by the Bound Rule. A pointwise export proves the page and its time bound; it does not prove the pages around it.

Solana Seal Profile A seal is anchored as the memo of an ordinary Solana transaction (the SPL Memo program). The anchor's type is urn:ksg:anchor:solana:seal:v1; its proof names the transaction signature, slot and cluster. The memo is blind and of fixed length: link = PRF(K, "ksg:bs:link:v1" || prev) commit = PRF(K, "ksg:bs:commit:v1" || seal) PRF(K, x) = HKDF-SHA256(salt = "ksg:bs:v1", IKM = K, info = x), 16 bytes, lowercase hex ]]> seal is the seal's hash (32 bytes); prev is the seal's own prev -- the previous seal's hash, whether or not that seal was anchored -- or the container identifier for the opening's seal, which has no prev. Scan key. K is the holder's scan key for the calendar month (UTC) in which the seal was made: with len64 the label's length as 8 bytes big-endian. A key handed out reads its month's seals and no other's. Scan keys are not part of any export or of this document's public material: the holder gives one to a verifier together with an export. Without it, an observer sees that a memo exists and nothing else. Reader. The reader recomputes the memo from the seal and the key and finds it in the named transaction; a different memo is a rejection. It asks the node for its genesis hash and accepts only the cluster the verifier named. The moment it returns is the block time -- a stake-weighted estimate at one-second grain -- and it says so. A fork (two memos with one link and different commit) is visible only to a holder of the key. Status records of are anchored with an open memo, because the status section is the part of a container that is meant to be read: link = SHA-256("ksg:st:link:v1" || prev) commit = SHA-256("ksg:st:commit:v1" || record hash) ]]> prev is the record's own prev; both values are written as multihashes. anchor type urn:ksg:anchor:solana:status:v1.

Security Considerations Signatures. Every seal carries Ed25519; a verifier MUST require it. Keys come from the journal's own pinned pages and the verifier's source, never from the presenter. The post-quantum signature (ML-DSA-65) is on the stored container as a whole, not on each seal: an export, once it has left the container, is protected by its recipient. Against a future forger able to break Ed25519, an anchored seal is held by its anchor: a page that differs from the anchored one does not hash to the anchored value. Time. Only an anchor read by the Bound Rule gives a bound; offset_ms and anchor statements are not evidence. In the local form a journal proves authorship and order, not time. Replay. A verifier replays the journal by the rules that wrote it; a journal accepted by a verifier is one the writing rules would have produced. Blind anchors. The blind memo hides the chain from outsiders and with it the visibility of forks: a fork is found only by someone holding the key. The paying account remains visible and groups its memos.

Privacy Considerations Pages may carry a digest instead of content, so an export can prove a record without revealing it. The blind memo keeps a journal's existence and pace from becoming a public time series; status memos are open by design.

IANA Considerations This document has no IANA actions. The anchor types urn:ksg:anchor:solana:seal:v1 and urn:ksg:anchor:solana:status:v1 and the memo tags ksg:bs:v1 and ksg:st:v1 are opaque, byte-compared strings; no URN namespace is registered by this document.

Normative References Informative References

Implementation Status Per . ksg-core-v2 (Rust) writes and verifies the journal; ksg-verify-v2 verifies both exports and reads seal and status anchors from Solana. The workspace runs 752 tests; the test vectors are regenerated and compared byte for byte by the reference build.