Five fields. Three endpoints. No lock in.

The protocol behind the witness network, written down so anyone can implement it, not just us. Free, open, and deliberately boring.

Why write it down

A standard nobody can own

The whole point of two chains witnessing each other is that neither one controls the other. That falls apart the moment the protocol itself is only in one company's private codebase, because then joining means trusting us to keep it stable, which is exactly the kind of trust this is supposed to remove.

So here is the entire protocol. Anyone can read it, implement it in any language, and anchor to us or to anyone else running it. We do not gatekeep who joins. We cannot, that is the design.

The payload

What gets sent

One JSON object, five fields, sent to a peer's receiving endpoint whenever you want them to seal your current tip.

That is the whole payload. No auth token, no API key, no account. If you want to seal it, you seal it.

The three jobs

What any implementation needs to do

Expose your tip. A public GET endpoint returning your current chain's payload, so a peer can pull it whenever they want to seal you. Ours is at /api/witness/tip.

Receive an anchor. A public POST endpoint that takes the payload above and seals it into your own chain, timestamped if you have that capability. This only ever claims you received and sealed a peer's tip at a given time, never that their chain is truthful, that is their business to prove on their own record. Ours is at /api/witness/anchor.

Push to a peer. Send your own tip to a peer's anchor endpoint. Only seal your own record of having sent it if the peer actually accepts, a rejected or failed send should never be logged as a success. Ours is at /api/witness/push.

The one rule that matters

Internal consistency is not proof

A hash chain proves your own records agree with each other. It does not prove you could not have built the whole thing yourself, quietly, after the fact. That only gets closed by something outside your own control seeing your tip at the time, which is the entire reason this exists as an exchange between separate companies rather than a feature inside one product.

If your implementation seals anchors but never sends any out, or receives from peers but exposes no tip of its own, it is not witnessing anything, it is just logging. Both directions have to be real.

How often, and what quiet means

Cadence and exit

Cadence. Push your tip at least once every 24 hours, whether or not it changed since the last push. A fixed heartbeat proves your chain was alive during quiet periods, not just when something happened, which matters because an anchor's absence should mean nothing was pushed, not that nothing was checked.

A receiving implementation should treat a peer as stale once more than 72 hours (three missed heartbeats) have passed since the last accepted anchor from that chain, and may say so publicly, a chain that has gone quiet for three days is a fact worth showing, not hiding. Stale is a status, not a removal, a chain that resumes pushing after going stale is exactly as valid as one that never stopped.

Exit. There is no exit message, exit form, or account to close, on purpose, the same reason there is no join form for submitting anchors. A peer exits by simply stopping. Three things follow from that, and every implementation should hold all three:

First, every record already sealed stays valid and public forever, exiting does not and cannot retroactively unseal or invalidate a past anchor. Second, a receiving implementation may stop actively pushing its own tip to a peer that has been stale for 30 days or more, to avoid indefinite pointless traffic to an address nobody is reading, this is a courtesy for both sides, not a penalty. Third, an exited peer can resume at any time with no re-application, no reset, and no different treatment, it just becomes a chain with a gap in it, the same as it would be for a peer that lost power for a month. A gap is not a lie, it is the honest shape of what happened.