Open standard

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.

FieldTypeMeaning
chainstringThe name your chain is known by on the network.
tipstringThe current hash at the end of your chain. 64 hex characters for SHA-256.
countnumberHow many entries your chain holds. Lets a peer sanity check growth over time.
tsstringThe moment this tip was current, ISO 8601.
urlstringOptional. Where a peer can pull your tip back, so witnessing runs both ways.

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.

Join it

Implement it, anchor to us

Build a client against the shape above, in whatever language suits you, point it at our tip and anchor endpoints, and press go. If it lands, you will see it appear on the live network page, publicly, the same way every anchor does.

Want to join formally? The network is open to applications, though only for a small number of companies at this stage: apply here.

Questions, or want your chain named properly rather than showing up as an unlabelled peer, reach us at support@redflagaipro.com.