OpenAIIS — A Decentralized Trust, Governance and Safety Protocol for the Digital World

5.1. Record Envelope

The core profile identifier is openaiis-universal-registry-v1. A signed record is a canonical JSON object containing exactly the following fields:¶

The record body is the same object without signature. Its field names MUST NOT be extended or omitted under this profile. The four reference arrays each contain zero to 64 sorted, unique values of the form sha256: followed by exactly 64 lowercase hexadecimal digits. The same digest syntax applies to issuer_key_id, content_sha256, and payload_sha256.¶

record_type matches [a-z][a-z0-9_]{2,63}. issuer_id, subject_id, and payload_schema match [a-z][a-z0-9_-]{1,31}:[a-zA-Z0-9._:/-]{1,160}. claimed_at is an integer from zero inclusive to 2^63 exclusive; JSON booleans are not integers for this purpose. Complete signed-record length MUST be between 1 and 65,536 bytes inclusive.¶

A record's asserted issuer name is not itself proof of a legal or institutional identity. Relying parties MUST independently select the expected issuer-key binding before accepting issuer authority.¶

5.2. Canonical Encoding

A canonical record is serialized as JSON [RFC8259] with:¶

• object keys sorted lexicographically;¶

• no nonessential whitespace;¶

• comma and colon as separators;¶

• ASCII escaping of non-ASCII characters;¶

• no NaN, infinity, or non-JSON numeric values;¶

• exact key sets and field types for the selected schema; and¶

• no duplicate object member names.¶

The signed bytes MUST equal the byte-for-byte canonical re-serialization of the parsed object. Implementations MUST reject malformed encodings, duplicate keys, unknown fields, unsupported profile values, incorrect array ordering, and alternate noncanonical representations. The complete canonical serialization is encoded as ASCII bytes.¶

5.3. Cryptographic Signature

The universal signed-record profile uses Ed25519 [RFC8032], with the following exact signing domain:¶

OPENAIIS/UNIVERSAL-REGISTRATION/v1\0

The displayed \0 denotes a single NUL byte (0x00), not two printable characters. Let C be the canonical body without signature, and let D be the ASCII bytes of the signing domain including the NUL byte. The signing message and signature are:¶

m       = D || CanonicalJSON(C)
sigma   = Ed25519.Sign(issuer_private_key, m)
key_id  = "sha256:" || HEX(SHA256(raw_32_byte_public_key))

signature MUST be the padded, canonical Base64 encoding [RFC4648] of the 64-byte Ed25519 signature. The signer serializes the completed object using the same canonical JSON rules.¶

A verifier MUST reconstruct m from the exact version-specific body, verify sigma with the independently established issuer public key, and compare issuer_key_id with key_id. Where issuer identity is a trust condition, the verifier MUST compare issuer_id to an independently established expected identifier. Signature validity alone does not imply permission to issue the signed type of claim.¶

5.4. Content Commitments

For original content bytes B, the ordinary profile uses:¶

content_sha256 = "sha256:" || HEX(SHA256(B))

For canonical typed-payload bytes P:¶

payload_sha256 = "sha256:" || HEX(SHA256(P))

The validator MUST bind record_type, payload_schema, the embedded payload profile, and the actual canonical payload bytes. It MUST check all required and forbidden references and typed validation constraints. When the original content is unavailable, content-byte verification is unevaluated, not successful by assertion.¶

The private artifact profile openaiis-artifact_registration-private-v1 uses a separately generated 32-byte salt and the domain:¶

OPENAIIS/PRIVATE-ARTIFACT-COMMITMENT/v1\0

Its content commitment is:¶

"sha256:" || HEX(SHA256(domain || salt || B))

The typed payload identifies visibility as blinded_digest. A verifier claiming private-content integrity MUST obtain both salt and B and recompute this exact commitment. Neither B nor salt is required in registry history or a Bitcoin transaction.¶

5.5. Historical Signature Profiles

A signed record retains the signature domain and payload-schema rules selected by its authenticated profile identifier. Historic candidate-v1 encodings cannot be renamed or silently reinterpreted as a new profile. An existing Bitcoin proof MUST NOT be attached to re-signed or re-serialized bytes with a different identity.¶

7.1. Admission

The registrant signs locally, then submits the exact signed record and required typed payload. The registry MUST validate canonical encoding, issuer signature, configured issuer admission rules, record type, payload hash, and profile-specific constraints before accepting it.¶

An accepted record MUST be durably stored as its original signed bytes and assigned a stable, zero-based log position. Its public record digest is:¶

record_sha256 = HEX(SHA256(exact_signed_record_bytes))

The same signed record submitted again to the same registry MUST be idempotent and MUST NOT create a second history entry. A successful registration response commits the registry to the automatic Bitcoin anchoring obligation described in Section 8. The operator MUST preserve sufficient durable state to continue the obligation across crashes, outages, and restarts.¶

7.2. Domain-Separated Merkle Leaves

The log kind for universal registered claims is registry_record. For a record at zero-based index i, compute:¶

r_i = HEX(SHA256(exact_signed_record_bytes_i))
p_i = "0000...0000"  (64 zero hexadecimal characters), if i = 0
p_i = entry_digest_(i-1), otherwise

J_i = CanonicalJSON({
  "profile": "openaiis-anchor-log-v1",
  "kind": "registry_record",
  "index": i,
  "record_sha256": r_i,
  "prev_entry_digest": p_i
})

E_i = ASCII("OPENAIIS-ANCHOR-LEAF-v1") || 0x00 || J_i

entry_digest_i = HEX(SHA256(E_i))
leaf_i         = SHA256(0x00 || E_i)
node(L,R)      = SHA256(0x01 || L || R)

The entry_digest and the Merkle leaf hash are distinct byte commitments. The receipt's prev_entry_digest binds each entry to the previous accepted entry commitment. A verifier MUST NOT hash the raw record bytes directly as its Merkle leaf.¶

For a tree of size one, the root is leaf_0. For larger trees, split the ordered leaf sequence at the largest power of two strictly less than the number of leaves and hash the left and right subtree roots using node(L,R). Inclusion and append-only consistency proofs use the left-balanced Merkle algorithms of [RFC9162] with these OpenAIIS leaf inputs. The root is a commitment to both exact record content and registry order.¶

7.3. Inclusion Receipt

The profile openaiis-universal-inclusion-v1 contains the following exact keys:¶

A verifier reconstructs the leaf input, checks index < tree_size, reproduces the inclusion path, and compares the resulting root with the same signed checkpoint's root. An inclusion proof under one root MUST NOT be transferred to a different checkpoint without proving inclusion under that target tree state.¶

7.4. Signed Checkpoints

A checkpoint authenticates the registry origin, tree_size, and 32-byte Merkle root using a key distinct from the claim issuer's signing key. Its core note body consists of exactly three ASCII lines, each terminated by LF (0x0A):¶

<registry_origin>\n
<decimal_tree_size>\n
<canonical_base64_of_32_byte_merkle_root>\n

The displayed \n is an ASCII LF byte, not the literal two-character sequence. The note follows the signed checkpoint structure described by [C2SP-CHECKPOINT]: one empty line separates the body from the signature line or lines.¶

The registry signs the exact three-line body with Ed25519. The operator signature line contains its origin and the canonical Base64 of:¶

key_id || Ed25519_signature

key_id = first_4_bytes(SHA256(
             ASCII(origin) || 0x0A || 0x01 || raw_public_key))

The complete signed note, including its body, separator, and signature line or lines, is the object committed through Bitcoin. A verifier MUST obtain the expected checkpoint origin and public key independently of an untrusted receipt or bundle and MUST validate the operator signature.¶

Two accepted signed checkpoints for the same origin MUST describe a consistent append-only history. An operator MUST produce the applicable [RFC9162] consistency proof between distinct authenticated tree sizes. A checkpoint monitor, when deployed, MUST reject an inconsistent later checkpoint under the same origin and signing identity relative to the checkpoints it has retained. The registry's signature and Bitcoin commitment do not depend on a monitor cosignature or a separately operated witness quorum.¶

7.5. Authenticated Lifecycle Index

The index identifiers are openaiis-lifecycle-index-v1 and openaiis-lifecycle-index-proof-v1. The signed index note binds its index root to the registry origin, tree size, and log root. Index keys are derived from record and subject scope and issuer-key identity using versioned domain-separated commitments.¶

A verifier evaluating current governance state MUST establish an adequately current authenticated registry checkpoint, the bound index note, necessary membership and non-membership proofs, and the relevant signed lifecycle records. Index evidence MUST be reconstructible from the authenticated log history. A missing index proof MUST NOT be taken as proof that no revocation, withdrawal, transfer, or dispute exists.¶

8.1. Exact Checkpoint Commitment

Let N be the exact UTF-8 bytes of the complete signed checkpoint note. The detached timestamp has file-hash type SHA-256 and digest:¶

d = SHA256(N)

An OpenTimestamps commitment [OTS] preserves the cryptographic path from this digest through its permitted operations to a Bitcoin block attestation. Aggregation can bind multiple checkpoints to one Bitcoin transaction, avoiding the need to place each individual claim or original artifact on Bitcoin. The original documents, confidential evidence, and typed payload bodies do not need to be revealed on-chain.¶

The Bitcoin attestation is valid for the exact signed checkpoint bytes. A claimed block height, pending calendar receipt, or proof for a different checkpoint does not establish this checkpoint's Bitcoin confirmation.¶

8.2. Automatic and Durable Processing

Every successfully registered claim at index i MUST be covered by a signed checkpoint of size n where i < n. The registry MUST initiate and persist a Bitcoin-commitment obligation automatically. A registry MAY aggregate multiple consecutive accepted records in a single checkpoint, provided every accepted record remains covered.¶

The anchoring workflow MUST perform, without further manual action by the registrant:¶

1. Generation and durable retention of a signed covering checkpoint.¶

2. Submission of a commitment to the approved OpenTimestamps calendar path or paths and retention of returned detached proof material.¶

3. Subsequent retrieval and merging of authentic timestamp upgrades.¶

4. Verification of Bitcoin mainnet inclusion and required confirmations.¶

5. Publication or retrievable export of the corresponding portable proof and a verifiable status.¶

A registry MUST preserve unfinished obligations and retry them with bounded work after transient network, calendar, or verification-source failures. Repeated attempts MUST be idempotent for the exact checkpoint or produce a different, separately signed checkpoint consistent with accepted history. It MUST NOT silently abandon an accepted record, substitute an unrelated historical Bitcoin proof, or present a calendar's pending response as confirmed Bitcoin inclusion.¶

Network availability cannot force a particular time to Bitcoin confirmation. Successful registry admission is therefore durable and retrievable while the externally anchored evidence is still pending. The mandatory anchoring obligation persists throughout that interval.¶

8.3. State Separation

Registration state is distinct from Bitcoin historical evidence state. REGISTERED establishes successful durable admission, not Bitcoin confirmation. The checkpoint evidence state has these meanings:¶

ANCHOR_RETRY_PENDING, ANCHOR_UNVERIFIABLE, and ANCHOR_INVALID describe processing or verification conditions, not successful finality. The registry and verifier MUST distinguish unavailability from an invalid cryptographic proof and preserve previously authenticated evidence. A record MAY obtain historical confirmation from any later covering checkpoint when its membership in that later checkpoint is independently demonstrated.¶

8.4. Mainnet Confirmation and Assurance

The core Bitcoin confirmation policy requires a minimum of six Bitcoin mainnet confirmations. For an attested block at height h and accepted active-chain tip at height H:¶

confirmations = H - h + 1
BITCOIN_CONFIRMED only if confirmations >= 6

The verifier MUST validate the detached timestamp's exact-note digest, permitted operations, Bitcoin block Merkle commitment, block-header hash and proof of work, linked confirming headers, applicable mainnet work constraints, and accepted active-chain evidence under the declared verification assurance class. Verification of six block confirmations does not require contact with six independent node operators.¶

The assurance classes are:¶

A result MUST report its actual class and MUST NOT represent provider-reported chain selection as independently executed full-node consensus validation. Bitcoin reorganization can alter current confirmation depth or accepted-chain membership; a verifier rechecks current-chain status when its policy requires current confirmation. A provider outage yields UNVERIFIABLE, rather than INVALID, unless cryptographic inconsistency is actually established.¶

A checkpoint confirmed in Bitcoin inherits the historical resistance to modification of Bitcoin's cumulative proof-of-work chain. To replace the committed checkpoint history while presenting a valid accepted Bitcoin chain, an adversary would need to establish a competing chain with the necessary proof of work. Altering an OpenAIIS database, compromising an AI agent, or replacing a registry operator cannot by itself produce an alternative valid proof for the original Bitcoin-anchored history. The exact signed checkpoint binds the authenticated registry state, including claims of authorization, responsibility, release and security evidence, to an independently verifiable historical commitment.¶

This is computational and consensus-based protection rather than an unconditional guarantee against every chain reorganization. Six confirmations express the core policy for accepting that protection; relying parties can require stronger assurance using the same Bitcoin commitment. The proof establishes that the committed checkpoint data existed by the attesting block's historical bound. Whether a person's identity, an AI agent's delegation, or a real-world assertion is accepted follows from the separately authenticated governance and evidence rules.¶

9.1. Universal Proof Bundle

The exact bundle schema is openaiis-universal-bitcoin-bundle-v1. A canonical JSON bundle contains exactly the following keys:¶

The complete bundle MUST NOT exceed 2 MiB. The verifier MUST reject unknown or duplicate top-level keys, malformed Base64, incompatible record/receipt/bundle profiles, an altered signed note, a mismatched timestamp digest, and a false inclusion path. The bundle does not implicitly confer trust on the issuer, record content, or current lifecycle state.¶

9.2. Verification Algorithm

An independent verifier processing a universal Bitcoin bundle MUST:¶

1. Obtain an expected registry origin, checkpoint signing key, issuer identity/key binding, accepted type profile, and Bitcoin assurance policy independently of the untrusted bundle.¶

2. Parse and verify the exact canonical record, profile-specific signing domain, Ed25519 signature, and expected issuer key identifier.¶

3. Reconstruct the domain-separated Merkle leaf and verify the receipt's index, size, and inclusion path under the exact signed checkpoint.¶

4. Verify the checkpoint origin/key, signature and root; check relevant historical consistency against independently retained checkpoints.¶

5. Require that the detached proof's SHA-256 digest is exactly SHA256(UTF8(complete_signed_checkpoint_note)) and independently evaluate its permitted commitment operations.¶

6. Verify the claimed Bitcoin block and the six-confirmation minimum under the selected assurance method, reporting that method and current-chain evidence.¶

7. If a governance decision is requested, obtain and verify the typed payload, supporting authority, consent, evidence, responsibility and lifecycle records under a sufficiently current authenticated head.¶

8. Return distinct integrity, inclusion, historical confirmation, governance and policy results with reproducible evidence references.¶

Checks 1 through 6 establish historical Bitcoin confirmation when all of their conditions hold. Operational authorization additionally requires the applicable governance checks. A relying party MUST NOT infer the absence of later revocation from an older, even Bitcoin-confirmed, registry checkpoint.¶

10.1. Scoped Delegation and Accountable Operations

Authority is expressed as an authenticated, typed relation between a principal, a grantee, a scope and the action that scope permits. To authorize a consequential action, a verifier MUST establish all required links among trusted principal, authenticated delegation, operation scope, applicable current lifecycle, request authentication, and any required responsibility acceptance.¶

For accountable software publication, the relationship includes an organization, operator, responsible principal, agent, exact signed release and signed supporting evidence. A principal approval MUST bind the intended action, release identity, code commitment, and relevant delegation. Where an approval-before-release policy applies, its authenticated log position MUST precede that of the release; claimed_at is an issuer assertion and cannot replace authenticated ordering.¶

A private key's possession is not self-authorization. Key replacement, revocation and recovery require a separately trusted and applicable signed authority; a replacement key named in an untrusted claim cannot inherit a revoked principal's rights.¶

10.2. Consent-Governed Identity Attestations

An identity attestation subject to consent MUST reference separately signed identity_consent from the independently recognized controller of that identity. The consent intent commits to the precise intended attestation with consent_refs excluded to avoid circular reference, under the domain:¶

OPENAIIS/IDENTITY-CONSENT/v1\0

The verifier MUST confirm the subject-control key, exact consent intent, attestation issuer and subject, content and typed commitments, references and authenticated record order. An issuer's attestation and the subject's consent are separate signatures with separate functions.¶

Identity attestations are non-transferable. Subject withdrawal and issuer revocation are separate events governed by their authorized roles. Where a declared identity assurance profile requires k-of-n independent issuers, the verifier MUST authenticate the selected issuer set, applicable independence requirements, threshold and required consent. Unknown or self-declared keys do not satisfy issuer independence. No automatic expiry applies unless the selected profile defines one.¶

10.3. Artifact Holders and Transfers

A transferable artifact attestation has a holder state derived from its authenticated history. Transfer requires a valid signed offer by the current holder and a distinct signed acceptance by the intended recipient, referencing the same exact offer and predecessor state. A verifier MUST reject a cancelled, mismatched, replayed, conflicting or out-of-order offer, as well as an offer signed by an actor other than the current recognized holder.¶

artifact_transfer_cancel cancels the referenced offer according to the extension profile. The transfer-offer extension's expires_at_tree_size, where selected, is evaluated against the associated authenticated tree position. An attestation holder's change does not in itself establish legal transfer of underlying property.¶

10.4. Disputes, Withdrawal, and Lifecycle Resolution

An issuer revocation, subject withdrawal, dispute, dispute settlement, transfer offer, transfer acceptance and offer cancellation remain distinct signed lifecycle events. An authorized settlement references the particular unresolved dispute and its qualified arbiter; merely signing a settlement does not confer arbitration authority.¶

Current-state verification MUST account for relevant events in the accepted authenticated order and apply the declared actor, scope and policy rules. An open dispute can produce a REVIEW decision without erasing the earlier signed assertion. A missing or stale current-state proof MUST NOT silently become a positive authorization.¶

18.1. Normative References

[C2SP-CHECKPOINT]

Project, C. C. S., "Transparency Log Checkpoints", n.d., <https://c2sp.org/tlog-checkpoint>.

[OTS]

Project, O., "OpenTimestamps: A Timestamping Proof Standard", n.d., <https://opentimestamps.org/>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

18.2. Informative References

[BITCOIN]

Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", 2008, <https://bitcoin.org/bitcoin.pdf>.

[C2PA]

Authenticity, C. for C. P. and., "C2PA Technical Specifications", n.d., <https://spec.c2pa.org/specifications/>.

[RFC9942]

Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, <https://www.rfc-editor.org/rfc/rfc9942>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

[VC-DM]

Consortium, W. W. W., "Verifiable Credentials Data Model v2.0", 2025, <https://www.w3.org/TR/vc-data-model-2.0/>.