FS anchor emitter
fs-anchor-emitter is the component that generates signed checkpoints of the immutable Write-Once-Read-Many ledger at hourly cadence and prepares them for external anchoring to the Sigstore Rekor transparency log on a monthly schedule — the mechanism that makes the platform's ledger state cryptographically auditable from outside the platform itself. The emitter operates at Layer 4 of the WORM stack as described in service-fs-architecture, reads the latest state of the per-tenant tile tree, generates a signed-note checkpoint, and stores it at the authoritative path under $FS_LEDGER_ROOT/<moduleId>/checkpoint. The monthly workspace anchoring process consumes those checkpoints and posts them to the public transparency log.
Configuration Requirements
The emitter requires the following environment variables to be defined at runtime:
| Variable | Description | Standard Value |
|---|---|---|
| FS_LEDGER_ROOT | Path to the tenant storage root. | /srv/platform/ledgers/ |
| FS_SIGNING_KEY | Path to the tenant private key (Ed25519). | /etc/foundry/keys/tenant.key |
| FS_ANCHOR_INTERVAL | Frequency of checkpoint generation. | 3600s (1 hour) |
Implementation of the Signed-Note Format
Checkpoints must strictly follow the C2SP signed-note format to ensure interoperability with the Sigstore ecosystem. A valid emitter output includes:
- Origin: The service identifier (e.g.,
service-fs.foundry.example). - Tree Size: The current monotonic entry count.
- Root Hash: The base64-encoded SHA-256 Merkle root.
- Signature: A detached Ed25519 signature from the tenant key.
Operational Procedures
Bootstrapping a New Emitter
Upon first initialization, the emitter verifies the presence of the FS_SIGNING_KEY. If no prior state exists, it generates a "Tree Size 0" checkpoint to establish the ledger’s origin. The machine-based authentication layer controls which identities may hold signing keys.
Verification of Consistency
Before emitting a new checkpoint, the emitter is intended to perform an internal consistency proof against the previously signed state. If the new hash-chain does not append cleanly to the old one, the emitter must abort and trigger an infrastructure alert (SOC 2 CC7 alignment). The Merkle proof substrate underpins this consistency verification.
External Anchoring
While the emitter produces checkpoints hourly, external publication to Rekor is currently planned for a monthly cadence. This provides a balance between evidentiary density and network overhead. The security and compliance posture document describes how this anchoring satisfies SEC Rule 17a-4(f) and eIDAS requirements.