the five-step act that turns an unsigned node template into a SignedNode - serialize, name, frame, sign, staple - about fifteen microseconds of notarization at the moment evidence crosses a trust boundary.
Steps two through four of the seal - the name computed once, framed with its protocol tag, signed flat at any size; serialization precedes, assembly follows.
Hand-authored SVG for this glossary, 2026. Domain string per sign.rs SIG_DOMAIN (lines 13-20).
Etymology and backstory
the paper says sealing rather than signing because signing is only step four of five. The metaphor earns its keep: a wax seal identified the sender, made opening evident, and was pressed at the moment of sending - three jobs in one gesture. Digital signing traditions usually name only the middle job; this operation deliberately binds all three at once.
Ecosystem
the same composite appears wherever records are notarized in flight - certificate transparency's signed timestamps, git's commit signing, TLS's CertificateVerify - but rarely under one name and rarely on a microsecond budget.
In codexproof
the mechanization, function by function. SERIALIZE via canonical_bytes (node.rs line 133) - sorted keys and links, length-prefixed fields, one deterministic layout. HASH with BLAKE3 to the 32-byte cid - the node gains its name, one or two microseconds. FRAME via signing_message (sign.rs line 15) - "prov-sig:v1" plus newline plus cid, domain separation pinning protocol and version. SIGN with Ed25519 over the frame, about 11 microseconds, flat at any payload size because it signs the name. ASSEMBLE via sign_node (sign.rs line 72) into SignedNode - node, cid, signer, signature. The seal binds bytes, author, and ancestry in one motion, because the typed links carrying parent cids ride inside the sealed bytes. Not encryption (nothing hidden), not validation (sealed garbage is authentic garbage), not storage (the proxy seals what it is handed or answers 403). The remaining ~74 microseconds of the 88.6 total is loopback transport, not crypto.