v1.1 is a MINOR editorial revision. The document title no longer carries the parenthetical "(IEC)". The semantic model retains the name Independent External Chronology. No semantic, cryptographic, or interoperability changes have been made. v1.0-conformant implementations remain conformant with v1.1 without modification. v1.0 remains permanently citable at /v1.0/.
Anchoring is defined as an infrastructure primitive built on cryptographic commitments, for establishing existence-at-or-before-T of a byte sequence.
It provides a verifiable commitment to the existence of specific bytes at or prior to a consensus-derived timestamp, without asserting authorship, ownership, identity, or legal status.
This specification formally defines the semantics, verification function, and independence requirements of this primitive.
This introduction is non-normative. Normative requirements begin in Section 1.
This specification defines anchoring as a cryptographic method for establishing existence-at-or-before-T of a byte sequence.
This document normatively defines:
This specification is normative.
Existence refers solely to the presence of a cryptographic commitment to the byte sequence in ledger L at or prior to time T.
No additional claims are implied.
Verification must be defined as:
Output semantics are defined in Section 5.
An implementation must return exactly one of the following outputs:
| Output | Condition |
|---|---|
| valid | All required conditions hold: Hash(B) equals the hash stated in P. Ledger inclusion proof is valid under L. Ledger timestamp T is derivable. |
| invalid | At least one required condition fails, including: hash mismatch, invalid ledger proof, or corrupted/malformed proof structure. |
| unverifiable | Verification cannot be completed due to: missing artifact, missing proof data, inaccessible ledger infrastructure, or unsupported ledger type. |
Implementations must evaluate all required conditions prior to returning "valid".
Implementations must not return intermediate, partial, or qualified results outside this set.
A compliant proof bundle must include:
Optional:
Attestation metadata is explicitly non-normative and has no effect on verification outcome under this specification.
A ledger L qualifies if it:
Permissioned or centrally mutable systems do not qualify unless their historical state is independently verifiable without reliance on a single controlling authority.
This specification is ledger-agnostic.
Anchoring does not establish:
Claims beyond existence-at-or-before-T are out of scope.
An implementation must not present anchoring results in a manner that implies any excluded claim.
A compliant anchoring proof must remain verifiable without reliance on the issuing entity.
Verification must not require:
Practical convenience of verification tools does not affect compliance. Verification must be technically achievable without issuer-controlled infrastructure.
This specification defines technical verification semantics only.
It does not create legal rights, obligations, or guarantees.
Legal interpretation of anchoring proofs depends on applicable jurisdiction and independent evaluation.
This specification uses MAJOR.MINOR versioning.
All published versions must remain permanently accessible at their canonical URI.
Current version: v1.1
Canonical URI: https://anchoring-spec.org/v1.1/
Previous version: v1.0 (frozen) /v1.0/
The Anchoring Specification is a public, versioned technical specification, released into the public domain.
It is currently authored and maintained by the Umarise team. There is no foundation, consortium, or multi-stakeholder governance body. This is a single-maintainer specification.
The specification is open for implementation by any party without restriction. Any party may fork, mirror, or republish it under any terms permitted by the public domain.
Implementations may reference compliance with a specific specification version.
No implementation has normative authority over the specification.
If conflicts arise between an implementation and the specification, the specification prevails.
External co-maintainers and multi-stakeholder governance are welcome and may be adopted if and when adoption warrants it. Until then, governance independence is not claimed. Technical independence (the property that proofs verify without the issuer) is established by Section 9 and is independent of governance.
Anchoring assumes:
Anchoring does not protect against:
Hash functions used in anchoring must:
If a hash function becomes compromised, future versions of this specification may deprecate its use.
This specification permits future versions to introduce alternative cryptographic primitives. Algorithm agility is supported through versioned specification updates.
Time T is defined as the earliest consensus-confirmed inclusion point of the commitment in ledger L.
Anchoring establishes existence-at-or-before-T.
It does not establish exact creation time.
Finalization criteria are ledger-specific and defined by the operational consensus rules of ledger L. This specification does not prescribe a fixed confirmation threshold.
Anchoring does not permit retroactive modification of proof validity once ledger inclusion is finalized.
If a ledger undergoes reorganization prior to finalization, verification status may change from valid to unverifiable.
An implementation claiming compliance must state:
Compliance claims must reference a specific specification version.
An implementation is non-conformant if it:
Long-term verifiability depends on:
Anchoring proofs should be stored in durable, non-proprietary formats.