Hedera HCS Anchoring and Manual Backfill

Automatic hash-only HCS anchors on upload plus manual APIs for files, bulk batches, versions, and library folders — immutable on consensus, mirror-verified.

Turn on the Trust Stack with Content Policy anchor = Hedera: uploads, shares, data rooms, transfers, GDPR erasure milestones, retention, compliance exports, and trace seals publish to HCS while Arweave stays the mandatory primary. Proof Receipts embed policy snapshots and HCS attestations for auditors — separate from the Trust & Compliance GRC module.

Hedera HCS gives regulators an independent, signed timeline — automatic on upload and manual when you need backfill.

When policy.anchor is hedera and the plan permits, Evercore publishes to anchorRequests after settlement. Operators can also queue manual anchor.content messages for files, version txIds, and library folders. hederaAnchorWorker submits hash-only JSON to Hedera Consensus Service; auditors verify on any mirror node.

Value

Independent audit chain

HCS messages reference sourceRef and payloadHash — Arweave permanence plus an ordered public log.

Manual backfill APIs

POST /files/anchor, /versions/anchor, and /library/nodes/:id/anchor let you anchor legacy locators without re-uploading.

Multi-anchor verify

POST /proofs/multi-anchor/verify runs Arweave, IPFS, and Hedera checks in parallel with mirrorVerified per anchor.

Use cases

Regulated evidence

Legal, healthcare, and finance workflows where a second public timeline strengthens defensibility.

Backfill before policy

Anchor matter folders or version chains uploaded before anchor: hedera was enabled — no re-upload.

Audit export milestones

Pair compliance exports and notary milestones with mirror-verified HCS receipts auditors can fetch independently.

Security guarantees

Evercore off the trust path

Verification uses public mirror nodes and network signatures — not vendor assertions.

Arweave still authoritative

HCS references the settled locator; it does not replace permanence, encryption, or Parent-TX versioning.

Immutable on HCS

There is no un-anchor API. Messages are append-only; force only re-queues another anchor.content when you need it.

For operators

  • Automatic: set anchor: hedera on ContentPolicy — publishAnchorRequest runs after primary settlement.
  • Manual: POST /files/anchor/:locator, bulk POST /files/anchor (≤80), POST /versions/anchor, POST /library/nodes/:id/anchor (recursive folder).
  • Scope storage:hedera:anchor (plus library:write for folder anchors). Console Files, Versions, and Library expose the same workflows.

For buyers

  • Answer regulator requests for a second-chain attestation without replacing Arweave.
  • Backfill anchors for matter folders or version chains that predated Hedera policy — no re-upload required.
  • HCS messages are append-only: there is no un-anchor API; use force only to re-queue when you intentionally need another message.

What is in the HCS message?

Canonical JSON with sourceRef, payloadHash, kind, and tenantId — no keys, no plaintext file body.

Can I remove or un-anchor a message?

No. Hedera HCS is append-only. Evercore does not expose delete or un-anchor. Use force: true on bulk or folder requests only when you intentionally need another anchor.content message.

What if a locator is already anchored?

Manual endpoints return status: skipped with reason: already_anchored unless force is true. Upload still succeeds when Hedera is not configured — anchors are simply skipped.