Releasing a seal

Releasing is deliberate: check status, satisfy the condition, then unseal.

`GET /v1/status/:id`

Returns the current state of a seal — its condition and whether it can open yet.

curl http://localhost:3300/v1/status/b9f1c3e2-…

Returns 404 Not Found for an unknown sealed_id.

Releases the plaintext if the condition is met. The actor names who is requesting release; it is recorded in the audit trail.

{ "actor": "alice" }

{
  "sealed_id": "b9f1c3e2-…",
  "data": "dG9wIHNlY3JldA==",
  "size": 10
}

data is base64-encoded plaintext. Decode it client-side.

Status	Meaning
`403 Forbidden`	`conditions not yet met` or `already unsealed`
`404 Not Found`	Unknown `sealed_id`

For quorum seals, each approver consents once. When required approvals land, the seal becomes releasable via unseal.

{ "approver": "bob" }

An approver not on the seal's list (or an unknown seal) is rejected with 403/404.

Time-locks release on sequential work, not on the wall clock. The client fetches a challenge, computes the required proof, and submits it.

{
  "sealed_id": "b9f1c3e2-…",
  "challenge": "9f86d081…",
  "iterations": 4000000
}

The client evaluates the sequential function over challenge for iterations steps — work that cannot be parallelized away.

Submit the resulting proof to release the seal. Verification is succinct; release is gated on the proof, not on trusting a timestamp.

Because the delay is enforced by computation, nobody — including the operator — can open a time-locked seal early, even with unlimited machines.