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 IEC.
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.
IEC uses MAJOR.MINOR versioning.
All published versions must remain permanently accessible at their canonical URI.
Current version: v1.0
Canonical URI: https://anchoring-spec.org/v1.0/
The Anchoring Specification (IEC) is a public, versioned technical specification.
IEC was initially authored by Umarise. The specification is published openly and may be implemented by any party without restriction.
The specification is not proprietary to any single implementation or commercial entity.
Implementations may reference compliance with a specific IEC version.
No implementation has normative authority over the specification.
If conflicts arise between an implementation and the specification, the specification prevails.
Governance of IEC may evolve independently of any single organization, including its original author.
Anchoring assumes:
Anchoring does not protect against:
Hash functions used in anchoring must:
If a hash function becomes compromised, future IEC versions may deprecate its use.
IEC 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. IEC 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 IEC version.
An implementation is non-conformant if it:
Long-term verifiability depends on:
Anchoring proofs should be stored in durable, non-proprietary formats.