Protocol v1.6
Every claim on the wire is signed.
The protocol is the contract between a coordinator that places work, an operator who owns the machine, and a caller who has to believe the answer. None of the three has to trust the other two. What follows is the shape of that contract; the normative version lives in the repository, and where the two disagree the repository is right.
- Version
- 1.6
- Schema
- opengrid.proto
- Licence
- Apache 2.0
Four parties, and what each can see
Trust is assigned per role, never to the network as a whole.
- Consumer edge
- Terminates the API call, authorizes the route, reconciles usage and countersigns receipts.
- Prompt and output
- Coordinator
- Enrolment, catalog, scheduling, reputation, settlement. It places work; it does not perform it.
- Metadata and evidence
- Node or connector
- Provider-controlled. Runs the inference on hardware its owner can inspect.
- Prompt and output
- Relay
- A quota-enforcing byte forwarder for peers that cannot reach each other directly. It is not a scheduler.
- Ciphertext only
What the contract obliges
Four questions, in the order a session answers them.
01Who are you?
The node generates an Ed25519 keypair on the machine itself, from the operating system's CSPRNG, and stores it in Keychain, DPAPI, a restricted key file or a hardware keystore. It proves possession against a coordinator-signed challenge and receives a short-lived certificate. The private key never crosses the wire — not at enrolment, not at rotation. Retired keys stay verifiable after they can no longer open a session, so a receipt signed under an old key still checks years later.
02What can you run?
A model is not a name. A route binds to model ID, revision, quantization, artifact SHA-256 and tier, together with the digest of the runtime build that will execute it — so a curated model cannot quietly become a smaller quantization or a tampered engine. Throughput a node advertises is an untrusted hint; the figure the scheduler uses is averaged from completed, receipted work, and it is thrown away whenever the artifact or the runtime build changes.
03How does work reach you?
Every value on the wire is one signed envelope; bare messages are rejected. TLS 1.3 is mandatory in production, QUIC preferred and secure WebSocket the fallback. The edge opens a route bound to a single request — an authenticated direct QUIC session where the network allows it, an allocation through our relay where it does not — and inside either one runs the same peer session: Ed25519-authenticated X25519, HKDF-SHA-256 key separation, AES-256-GCM keyed per direction and per channel, gapless sequence numbers. Direct and relayed requests therefore carry identical sealed bytes.
04What did you do?
Acceptance is not authority. A node's signed receipt is written first to immutable staging, with no edge signature and no accounting effect. Only terminal output triggers finalization, which reconciles every staged receipt against the tokens and output digest the edge observed for itself, countersigns the whole set atomically, and posts balanced double-entry entries. A failed attempt stops at staged and is never countersigned. Receipts already finalized when an attempt later fails get append-only invalidations — receipt history is never edited or deleted. Days close under a signed Merkle root.
What encryption here does not mean
The peer session runs between our edge and the serving machine, so the relay forwards bytes it genuinely cannot read. It does not hide a request from the two parties that have to process it: the operator running the inference sees the prompt and the output, and so does the edge that terminates the call. OpenGrid claims no caller-to-operator end-to-end encryption and no confidential computing. What the protocol gives you instead is a name — which operator, which artifact, which build — signed, and checkable after the fact.
Decoding a field is not understanding it
Peers negotiate the highest common major, then the highest common minor. That alone is not safe: an additive field decodes perfectly well on a node with no idea what it means. So behaviour is gated by named feature floors instead, and the coordinator will not assign work depending on a feature until the negotiated session meets that feature’s floor. An old node stays connected for heartbeats and upgrade visibility, and is simply not given the work — which is what lets the coordinator be upgraded first.
1.1
Engine-build receipts, the encrypted relay, pipeline recovery, blind canaries, direct connectivity.
1.2
Edge-reconciled sampled-token evidence.
1.3
Indexed batch results, per-choice finish frames, bounded top-token logprobs.
1.4
Authenticated pipeline transport, and whole-model versus stage capability stated explicitly.
1.5
The aggregate deployment boundary — one enrolled identity for an entire managed cluster.
1.6
Conversation affinity on isolated slots, and bounded response fragments.
Write your own node
A third party can implement a compatible node without importing any of our Go. The schema is a single Buf module. Because signatures cover protobuf bytes rather than a text rendering of them, the rules narrow proto3’s encoding freedom — ascending field order, shortest varints, proto3 defaults omitted, and no maps anywhere in a signed structure — so an independent encoder reproduces our bytes exactly. Fixed cross-language vectors are published for envelope signatures, two-party receipts and the audit-ledger Merkle tree. Run them before trusting your implementation; they are the same ones our own conformance suite runs.
- Envelope 64 KiB – 16 MiB
- Nonce exactly 16 bytes
- Ed25519 32 / 64 bytes
- Hash 32 raw bytes, never hex
- Activation chunk 1 MiB
- Pipeline 2 – 8 stages
- Relay authorization ≤ 60 s
- Top logprobs 0 – 20
- Completion batch ≤ 128
- Embedding batch ≤ 256
A compatible node enforces these before it allocates anything — reject the declared size, then read the bytes.
One machine, or one cluster
Standalone node
One daemon per Mac, workstation or GPU host, driving its engine directly. Invite-only enrolment while the network is in developer preview.
Managed cluster
A whole deployment enrols once, as a single aggregate target behind its own scheduler. Cluster-local workers and GPUs are never federation identities, and placement inside the cluster stays the operator's. Same enrolment, same identity model, same signed receipts.
Either way
The hardware stays the operator's, the node key is generated on the machine and never leaves it, and enrolment can be revoked from the edge.
Routing to managed clusters is hard-disabled until usage can be derived from a catalog-trusted tokenizer and template. The protocol defines it; what is missing is evidence, not code.
Read it yourself
This page is a summary and summaries are lossy. The normative spec, the schema it is generated from, the signing vectors and the threat model are all Apache 2.0 — including the parts that say what we do not claim.
Pre-production. The contract above is implemented and exercised against deterministic simulators; the release gates still open are named in the repository rather than here.
See what a request looks like