Gravit Open Network Foundation

Trust & governance

How a change reaches you

Gravit is built for settings where decisions must be explainable to regulators and auditors. The way our own code changes follows the same principle.

Every change is reviewed by a second person

  • No one, including administrators, can change the main branch of the verifier directly.
  • Every change goes through a pull request, needs approval from a designated maintainer who is not its author, and must pass automated tests in Python and Rust.
  • Approval is required again after any later change, so what was reviewed is what is merged.

Verifier registry

  • Only evidence signed by registered, non-revoked verifier keys can support a Verified Fact.
  • The registry is valid only when at least 3 of 5 independent Foundation root key holders have signed it. Each holder will generate and keep their root key on their own hardware device; no single person can approve a registry alone.
  • Operators are admitted under a written policy (identifiable legal entity, independence statement, own key generation).

Status: the processes above are in force for code changes. The root key ceremony and the first operator admissions are planned; until then the registry contains test keys only.

Security and standards

We build on open, published standards, and we say exactly which ones and how far we are. Nothing here is a certification.

In use today

  • Ed25519 (RFC 8032): signatures on every decision and receipt of the Gravit Verifier.
  • SHA-256 and SHA3-256 (FIPS 180-4, FIPS 202): fingerprints of inputs and decisions.
  • Merkle trees as in Certificate Transparency (RFC 9162): the public receipt log with inclusion proofs.
  • Trusted timestamps (RFC 3161): daily log roots stamped by three independent authorities.
  • Post quantum key exchange ML-KEM (NIST FIPS 203): our sites and the verifier API use TLS 1.3 with the hybrid X25519MLKEM768.

In progress

  • Post quantum signatures ML-DSA (NIST FIPS 204): a second signature on every decision next to Ed25519; a result stays valid only if both hold.

Planned

  • Hash based signatures SLH-DSA (NIST FIPS 205): long term signatures on the daily log roots.

Why post quantum now. Signatures we make today must still be checkable in decades. NIST plans to retire today's common public key algorithms over the coming years, so we are moving to its new post quantum standards before that, step by step and with public test vectors.

Open standards work. Our protocols are Internet-Drafts at the IETF (see Network). We follow NIST's work on post quantum cryptography and on AI agent identity and security, and we will take part in its public comment periods.

We are not affiliated with or endorsed by NIST. Details and live status: gravitverifier.space.