OIP v0.6 is now public. The Oracle Interoperability Protocol governs how state, including regulatory orders, moves between domains. Its repository on GitHub now holds the v0.6 specification, the Rust reference implementation and the Go message layer under the Apache-2.0 license, and the OIP v0.6 proofs have joined our public formal verification repository. When we wrote OIP v0.6 in Development, the rules and the code were still private. Now anyone can run the code and check the proofs.
Two Public Repositories
In the OIP repository, one Protocol Buffers schema generates both the Rust and the Go bindings. The Go implementation covers the message layer through admission, and the Rust reference continues past admission, through the operations on the service that owns the state, to durable records and recovery after a crash. Shared test vectors hold both implementations to the same results, and the README lists the commands that run the checks.
The formal verification repository, under the BSD-3-Clause license, already held our earlier proofs, such as the cross-domain state preservation proofs. The OIP v0.6 proofs add nine Isabelle/HOL sessions to it, with a guide for rebuilding them and rerunning the comparisons described below.
How Far the OIP v0.6 Proofs Go
A theorem about a model says nothing about code on its own. Refinement is the relation that carries a model's guarantees to an implementation: every run of the code corresponds to a run of the model. The OIP v0.6 proofs work on that step in three ways:
- Conditional theorems. Isabelle/HOL results about the modeled product, the reference configuration, record reopening, recovery and message handling, each under named assumptions.
- Source correspondence. Named correspondence statements, maintained by hand next to the source, tie selected Rust operations to those models.
- Executable comparison. The message model is exported from Isabelle as executable code, and the Rust and Go implementations must agree with it on 673 fixed and seeded inputs, down to the bytes they keep and sign. A second comparison checks how the Rust reference builds signed responses and how a client admits them.
The correspondence covers selected operations and the comparisons cover the listed inputs, so a refinement proof from the model to every run of the compiled code remains open research. The prototype is unaudited and not for production.
What Changed Since v0.5
OIP v0.6 is a new wire contract that keeps the protocol's vocabulary: its 31 operations in seven families retain their v0.5 numbers and names.
- One message format. A canonical Protocol Buffers schema with fixed field numbers defines every message, and every operation has an exact operand layout.
- Registered identities. Domains, principals and assets are registered 64-bit handles instead of CAIP-2 identifiers and display addresses. Time is counted in UTC seconds, and the protocol version is the integer 6, negotiated per channel.
- Effects bound to signed state. A request that changes state runs only if the state revision and authority epoch it was signed against are still current. A successful parse never authorizes an effect, and a caller that loses a response must learn what happened to the original request before it sends new financial work.
The v0.5 pages remain on the documentation site behind a version switcher, and the migration guide maps each change. The OIP v0.6 pages now show the code they describe, as excerpts from a fixed commit linked to the same lines on GitHub.
What Comes Next
Later editions take up what v0.6 leaves open, as recorded on the Open Issues page and in the migration guide:
- Threshold signatures. The format has a scheme code for signatures by a quorum of signers, but the repository has no adapter that checks them, so the reference refuses those requests.
- The remaining operations. The reference configuration accepts 25 of the 31 operations and refuses the other six before admission.
- Routing and conditions. Multi-hop relaying and peer discovery are outside this edition, and the Restricted DSL condition expressions of v0.5 are not defined in it.
- Canton and shared authority. The Canton driver attestation and party mapping fields are not yet defined, and neither is an authority field for several signatories.
OIP defines the rules and describes no deployment. The Oracle State Synchronizer, which synchronizes state under these rules, is a separate product in development. In the meantime, the code and the OIP v0.6 proofs are public and can be checked against each other.