Project status
A protocol design and a working reference implementation are not the same as a deployed, independently operated global network. This page keeps the difference clear.
Reference implementation
The reference implementation is written in Python and is a release candidate, version
0.5.0.dev0 (Python 3.12 or 3.13). The Whitepaper V4.0
and Protocol V5.0 numbers are document versions, not the software version.
Its release checks run on Python 3.12 and 3.13: package installation, pinned dependencies, API contracts, wheel packaging, local signed-claim registration, checkpoint and receipt verification, and selected negative cases. These are release smoke checks. They do not replace a comprehensive security assessment, full protocol conformance tests or network-level adversarial testing.
Available now, and not implied
| Available in this source release | Not implied by this release |
|---|---|
| Canonical signed-claim registration with Ed25519 and SHA-256 verification | A globally deployed, permissionless multi-node network |
| Core typed claim validation and selected governed lifecycle and authority components | Universal acceptance of every real-world claim or issuer |
| A durable, local, append-only Merkle registry with inclusion and consistency mechanisms | Network-wide consensus, replication or censorship resistance |
| Signed checkpoints and independent receipt-verification logic | An automatically Bitcoin-confirmed proof for every record |
| A loopback-only operator registry and a read-only verifier HTTP service | An Internet-hosted registration service |
| Historical Bitcoin-verification and interoperability components with explicit assurance boundaries | Implicit conformance to every external format |
The operator-controlled registry admits claims that issuers have already signed, against configured issuer keys and permitted record types. It never creates issuer signatures or holds issuers' private keys.
Still to be specified and built
The documents name these as requirements for the decentralized network:
- A consensus profile that fixes block serialization, work targets, difficulty adjustment, fork choice, reorganization limits, timestamps and synchronization (Protocol V5.0 §14.2).
- Admission and abuse prevention for open registration: hostile volume, expensive parsing, replays and storage exhaustion (§14.3).
- Explicit economic rules for participation and services, without a native token (§14.4).
- Independent witnessing, checkpoint exchange and equivocation detection across operators (Whitepaper V4.0 §7.1).
Documents and what changed
| Document | Date | Status |
|---|---|---|
| Whitepaper V4.0 | 25 October 2026 | Current |
| Protocol V5.0 | October 2026 | Current |
| Whitepaper V1.0 | 1 March 2026 | Superseded |
The first whitepaper, published on this site in March 2026, described a blockchain giving every AI agent and piece of software a permanent cryptographic identity. The current documents keep that aim and change several things:
- Scope. OpenAIIS now covers digital claims generally: people, organizations, creative and research works, software, identities and autonomous systems, not only AI agents.
- Model. Registration, resolution and decision are separate. Authority, consent, responsibility and lifecycle are typed, signed records, and a relying party decides with its own policy.
- History. The working core is an append-only Merkle registry with signed checkpoints, inclusion and consistency proofs, and optional checkpoint anchoring to Bitcoin through OpenTimestamps.
- Network and economics. A proof-of-work network without a native token remains the intended architecture. Unlike V1.0, fees for services or network capacity in existing assets are now allowed.
- Licensing. The software is under Apache 2.0 and the two documents under CC BY 4.0, replacing the earlier MIT licence. See Licensing and name.
- Name. OpenAIIS now stands for Open Artificial Intelligence Integrity Sentinel.