Roadmap

Peal Commit

The rounds API above is the general shape: many seals, one deadline. Most callers, and nearly every agent, want the narrow one: seal a thing until a time, get something back that proves it was sealed before it was opened. That is one call.

POST https://peal.network/v1/seals

{
  "ciphertext_b64": "…",             // encrypted on your side, always
  "unlock_at":      "2026-09-12T18:00:00Z",
  "tag":            "my-app"
}

→ {
  "id":         "4f858dc3…",         // sha256 of the ciphertext
  "round_id":   "cond_…",
  "unlock_at":  "2026-09-12T18:00:00Z",
  "proof_url":  "/v1/seals/4f858dc3…/proof"
}

Or with the client, which does the encryption:

import { peal } from 'https://peal.network/peal.js';

const until = '2026-09-12T18:00:00Z';
const { id, proof_url } = await peal.sealUntil('the bid', until);
const proof = await peal.getProof(id);

There is no field that takes a plaintext. Encrypting on our side would move the encryption to the wrong end of the network and delete the only property this has. The payload is a ciphertext or it is not accepted.

What the proof actually proves

GET /v1/seals/{id}/proof returns the checkable facts and nothing else. The load-bearing one is ordering_committed_at: the coordinator writes the batch's ordering root at freeze, before any operator is handed work, so a commitment timestamp earlier than the reveal is evidence that the set and its order were fixed before anybody could open it. Before the round opens, the reveal fields are null rather than false, because "not yet" and "no" are different answers.

{
  "seal_id":       "4f858dc3…",   // recompute it yourself
  "position":      3,             // from the hashes, not arrival
  "ordering_root": "0x…",
  "ordering_committed_at": 1788490917,
  "merkle_root":   "0x…",
  "revealed_at":   1788494517,
  "commitment_precedes_reveal": true,
  "threshold":     "3 of 5 operators open a batch"
}

What is built, and what is not

Every endpoint on this page is live and every example runs against the network. These are the pieces that are not, so you can see the edge of the thing before you plan around it.

• livePOST /v1/seals seal until a time, in one call
• liveGET /v1/seals/{id}/proof ordering commitment, merkle root, threshold
• shipping nextwebhook on a seal we would call you at the deadline; today you poll the round, which an ETag makes nearly free
• shipping nextPOST /v1/rounds with an invite list multi-party rounds where the participants are known up front
• plannedMCP tool seal_until(payload, unlockAt) so an agent can reach this without an SDK
• livepaid access over x402 every /v1 route has a metered twin at /v1/x402 that answers 402 until it is shown an on chain payment. The free API is unchanged and still needs no account. See metered calls
• plannedtyped SDKs for TypeScript, Python and Go peal.js and plain HTTP cover it today
• livesealed bid auctions reserve, maximum, ranking, the queue, replay rejection and encrypted contact details
• shipping nextcurrency conversion in the API bidders in another currency; peal-live does it client side today
• shipping nextclaiming a short link from the API you can check availability today; claiming is a permanent onchain write and happens from your own key

An agent cannot sign up for anything: it cannot accept terms, hold an API key it did not earn, or expense a subscription. It can pay for one request. That is why per-call payment is on this list rather than a plan and a dashboard.