Open witness standard
The Witness Peer Agreement.
The same terms for every company that anchors to us, published once rather than negotiated in a fresh document each time someone joins.
Why one document, not a custom one each time
A standard has one set of terms
The moment two companies negotiate their own private version of this, it stops being a standard and becomes a bespoke contract that happens to reuse some of the same words. Everyone who anchors to redflagaipro.com operates under this exact page, whether that is a solo builder or a company with its own legal team.
What does change per peer is not the terms, it is confirmation. Accepting this gets sealed as its own dated record on the same chain everything else here proves things with, see the bottom of this page.
The one thing this promises
What a receipt claims, and what it doesn't
A sealed anchor only ever claims one thing: we received and sealed this exact tip from this named peer at this moment. It says nothing about whether your underlying chain, your governance decisions, or your product are correct, current, or authorised. That stays entirely yours to answer, on your own record.
We do not evaluate your policy, your evidence, or your admissibility rules. We do not endorse your product by witnessing it. Witnessing is integrity of a timestamp, not a verdict on what it timestamps.
The contract
What actually happens, technically
| Endpoint | /api/witness/anchor, also reachable at /api/witness/observe |
| Method | POST, unauthenticated, no account needed |
| Payload | chain, tip, count, ts, url (optional), same five fields as the published standard |
| Success response | HTTP 200, sealed: true, a non empty id, a non empty verify link |
| Rate limit | 10 requests a minute per address |
| Recommended cadence | A fixed heartbeat regardless of whether the tip changed, not event only submission. Proves the chain was alive during quiet periods too. |
No idempotency key. Only submit when the tip is meant to move, or you will create harmless but duplicate entries.
The boundary
What this is not
This is not a partnership, an integration commitment, an endorsement, an exclusivity arrangement, an operational dependency, a licence, or an agency relationship. It does not transfer intellectual property in either direction, and it does not require either side to disclose internal policy, proprietary logic, or confidential material to make witnessing work.
Either side can stop submitting at any time. A peer going quiet does not retroactively change any record already sealed, it just means no new ones get added.
Growing the network
Becoming a mutual peer
Submitting to us is one direction. Our own side also pushes our tip out on a fixed schedule to a short list of approved peers, so they can seal us the same way we seal them. Getting added to that list is what makes it mutual rather than one direction, not a special arrangement, just both sides witnessing each other the way the standard is meant to work.
How this gets confirmed
Acceptance is a sealed record too
Rather than a private side letter, confirming you operate under this agreement gets sealed the same way everything else on this standard is proved: a dated, hash sealed entry naming who confirmed and when, checkable by anyone at the verify link. To request one, reach support@redflagaipro.com and we will seal it and send you the record.
No peers have confirmed against this version yet, this table fills in as they do rather than starting pre-populated.
Authored by James Stokes, Founder, Red Flag AI Pro. This page describes a technical protocol with stated boundaries, it is not legal advice, and a business intending to treat this as a binding signed agreement should have its own terms reviewed independently.