Epistemic Temporal Integrity Protocol (ETIP) v1.2

Drafted by Y. Chen | Linkedin

1. Positioning & Intent

ETIP exists to solve a simple, stubborn problem: data can be quietly rewritten.

In systems like ESG reporting, numbers do not just exist — they evolve. What is often lost is not the latest value, but the history of how that value came to be.

"What did you say before — and did you change it later?"

ETIP is designed so that this question always has an answer. It does not try to prove truth, judge correctness, or enforce honesty. Instead, it does something narrower, but more reliable:

It makes it impossible to rewrite the past without leaving evidence.

Do not describe ETIP using market language (e.g., "token", "mint").

Do not treat ETIP as an asset system.

Do not treat ETIP as verification of "truthfulness" of content.

Do not treat ETIP as a consensus mechanism or blockchain.

2. Design Positioning

ETIP is a post‑blockchain system, and also post‑heavy infrastructure. It keeps what mattered — chaining, fingerprinting, external witnessing — and removes what didn't: consensus overhead, global coordination, and energy‑intensive operation.

ETIP takes what worked, and removes what didn't.

It is not designed for consensus, markets, or scale at any cost. It is designed for one thing only: preserving the temporal integrity of records.

3. Historical Lineage & Prior Art

ETIP stands on existing ideas rather than replacing them:

• Hash chaining — linking records so the past cannot be changed silently
• Merkle aggregation — compressing many records into a single proof
• Public witnessing — anchoring data outside the control of its creator
• SHA‑256 — collision‑resistant fingerprinting standard
• Ed25519 — efficient, verifiable digital signatures
• JSON Canonicalization (RFC 8785) — deterministic data representation

ETIP acknowledges the foundational "Digital Notary" work by Haber and Stornetta (1991). It utilizes RFC 8785 for serialization, SHA‑256 for fingerprinting, Ed25519 for signatures, and aligns with the principles of Epistemic Integrity — ensuring justified belief in data states over time.

4. Terminology

5. What ETIP Guarantees & Threat Model

ETIP provides the following positive guarantees, assuming correct implementation:

ETIP explicitly does not guarantee:

Threat model refinements:

• A malicious operator may attempt to back‑date a record after the fact by rebuilding the chain. This is prevented if a witness published a prior chain root before the back‑dated entry, because the newly‑computed chain root would conflict with the witnessed one.
• Collusion among witnesses could theoretically suppress evidence, but using multiple independent witness classes (see Section 10) mitigates this risk.
• Key compromise is the most severe failure mode; it breaks all checkpoint authenticity. ETIP therefore recommends that operator keys be rotated frequently, with each rotation event itself witnessed.

6. Core Mechanism & Canonicalization

Every record in an ETIP log is a JSON object. Before any hashing takes place, the record must be reduced to a deterministic byte sequence — its canonical bytes — following these rules:

• JSON artifacts: Serialize the record minus the record_fp key using the JSON Canonicalization Scheme (RFC 8785). JCS sorts object keys, encodes strings as UTF‑8, and omits insignificant whitespace, ensuring the same logical object always produces the same bytes.
• Non‑JSON artifacts: Treat the artifact body as raw bytes without any transformation. The artifact's content_type indicates how it should later be interpreted.
• Canonical bytes = a concatenation of:
  1. The JCS serialization of the record (without record_fp), for all record types.
  2. For commit records only, the artifact's raw canonical bytes are hashed separately to form artifact_fp; they are not embedded in the record's canonical bytes.

Self‑hash computation (record_fp):

1. Temporarily remove the record_fp key from the record object.
2. Apply JCS to the remaining object.
3. Compute SHA‑256 over the JCS output bytes.
4. Set record_fp to the hexadecimal representation of that digest.

This ensures each record's fingerprint is a sealed hash of its own content and its backward link (prev_record_fp).

Append‑only log & link continuity:

• Records MUST NOT be edited or deleted after being appended.
• The seq field starts at 1 and increments by 1 for each new record, scoped to log_id.
• Every record (except the very first) contains prev_record_fp set to the record_fp of the record with seq‑1. The first record uses null.

This hash‑chain guarantees that any tampering with a single record cascades into all subsequent fingerprints, breaking the chain.

Record creation & ordering:

The log operator accumulates commit records. Periodically (e.g., after a fixed count or time interval), a batch_marker record is appended to close the batch. Checkpoint records may be appended at any time to capture the current chain root and publish it to witnesses.

7. Merkle Tree Compression

Merkle tree compression reduces an ordered set of commit records into a single verifiable digest — the batch root — enabling compact inclusion proofs without storing the entire log. This section formalizes the construction.

7.1 Batch construction

The log operator groups consecutive commit records (type "commit") into a batch. The batch boundary is a local policy parameter, for example:

• A fixed number of commit records (e.g., every 1000 commits), or
• A fixed time window (e.g., every hour).

Every batch MUST contain at least one commit record; an empty batch is not permitted and, if no commits occurred during the window, no batch marker is produced.

For each batch, a binary Merkle tree is built:

Leaves:

Compute the record_fp of each commit record (as defined by the self‑hash rule). The tree's leaves are the SHA‑256 digests of these record_fp values: leaf_i = SHA‑256(record_fp_i).

Internal nodes:

For any pair of child node bytes left and right (each 32 bytes), the parent node is SHA‑256( left || right ).

Tree structure:

The tree MUST be balanced to the left. All leaves are placed at the same depth. If the number of leaves is not a power of two, the shortest tree is built by adding padding leaves with the value SHA‑256("") (the hash of empty bytes, i.e., 0xe3b0c44298fc1c14…) until the leaf count reaches the next power of two. This construction is the traditional balanced binary Merkle tree; alternative configurations (like an unbalanced tree with explicit leaf count) may be defined in extensions but are not part of this specification.

The batch root is the top‑most hash of this tree.

Batch marker record:

After the last commit record of a batch, the operator appends a special record of type "batch_marker" that seals the batch and links it to the chain root. The batch marker is a regular log record, subject to the same self‑hash rule and link continuity (prev_record_fp points to the preceding record, which will be the last commit record).

The batch marker carries the following fields in addition to the common record fields:

{
  "spec": "ETIP-2.1",
  "log_id": "string",
  "seq": 789,
  "type": "batch_marker",
  "prev_record_fp": "hex",
  "batch_root": "hex",
  "prev_batch_root": "hex",
  "chain_root": "hex",
  "record_fp": "hex"
}

• batch_root — the Merkle root of the batch being closed.
• prev_batch_root — the batch_root of the immediately preceding batch marker, or null for the first batch.
• chain_root — the running chain root after incorporating this batch. It is computed as SHA‑256( batch_root || previous_chain_root ), where previous_chain_root is the chain_root of the preceding batch marker (or null for the first batch, yielding SHA‑256( batch_root )).

The chain root is therefore a cumulative hash that anchors all batches up to this point.

7.2 Proof of inclusion

To prove that a specific commit record is contained in a given batch, a prover supplies:

1. The commit record itself (including its record_fp).
2. A Merkle authentication path — the ordered list of 32‑byte sibling hashes from the leaf up to the batch root.
3. The batch_root as published in the batch marker record.

Verification proceeds as follows:

• Compute leaf = SHA‑256(record_fp).
• For each sibling in the path (from leaf to root), compute the parent hash accordingly: if the leaf was the left child of a pair, compute parent = SHA‑256( leaf || sibling ); if it was the right child, parent = SHA‑256( sibling || leaf ). The path must indicate left/right ordering (commonly by appending a single flag per step).
• The result after consuming all siblings must match the given batch_root.

If the recomputed root matches, the commit record is proven to be part of that batch with the same integrity guarantee as if the entire log were present.

7.3 Chaining of batch roots (chain root)

Batch markers themselves form a linear chain through their prev_batch_root fields. This provides longitudinal integrity: any tampering with a batch root would change the batch_root of that batch's marker, which would change the chain root stored in that same marker and all subsequent chain roots. The chain root is therefore the definitive integrity snapshot of the entire log.

When the operator later creates a checkpoint record (Section 12), it records the current chain_root and publishes it to witnesses. Witness receipts bind that chain root to a point in time, thus sealing the entire log history up to that batch.

Because the chain root depends on all prior batch roots, it protects against deletion or reordering of entire batches. Any attempt to remove a batch marker (and its batch) would break the prev_batch_root link in the next marker, and the chain root computation would no longer reproduce the witnessed value.

8. Levels of Use / Conformance

ETIP defines two conformance levels. They are cumulative: the higher level requires all the capabilities of the lower one.

8.1 ETIP‑Compatible (Basic Integrity)

A log implementation is ETIP‑Compatible if it satisfies all of the following:

An ETIP‑Compatible log provides internal consistency, tamper‑evidence within its own sequence, and detection of any modification, but makes no time claims and does not involve external witnessing.

8.2 ETIP‑Conformant (Witnessed Integrity)

A log implementation is ETIP‑Conformant if it satisfies all requirements for ETIP‑Compatible and additionally:

An ETIP‑Conformant log guarantees "existed no later than" for any record whose batch is covered by a witnessed checkpoint. The witness receipts provide external, non‑repudiable evidence of the log's state at a point in time. Auditors can independently verify the full log history by recomputing the chain root and checking witness signatures.

9. Time Semantics

ETIP does not claim to prove an exact creation timestamp for any record. Instead, it provides two bounded temporal guarantees derived from sequential chaining and external witnessing.

9.1 Upper bound: "existed no later than"

A record's existence can be bounded above by the earliest witness receipt that covers its batch.

• Suppose commit record R belongs to batch B. Batch B is closed with a batch marker that updates the chain root to C.
• Chain root C is subsequently included in a checkpoint and published to an independent witness. The witness issues a receipt with a timestamp T.
• Then R must have existed no later than time T.

In other words, the data inside R cannot have been created after the moment the witness saw the chain root that incorporates that data. This is a forensic upper bound — it caps the latest possible creation time.

When multiple witnesses publish receipts at different times, the earliest receipt timestamp provides the tightest upper bound for all records covered by that checkpoint.

9.2 Lower bound: "could not have existed before" (informative)

Because records in a log are strictly ordered by seq and each record's fingerprint includes the fingerprint of its predecessor, the log also provides an implied lower bound on creation time.

• Suppose record R at seq = n has a predecessor record S at seq = n‑1.
• S belongs to an earlier batch, and its batch's chain root was witnessed at time T_earlier.
• Since R links backward to S, R cannot have been created before T_earlier — unless the operator had the ability to predict S's fingerprint before S was appended and witnessed, which is infeasible under SHA‑256 pre‑image resistance.

Thus, for two records A (earlier) and B (later), the time A was witnessed serves as a lower bound for B, and the time B was witnessed serves as an upper bound for A. Together, witnesses at regular intervals produce a tightening time window on the entire log.

Important caveat: The lower‑bound guarantee depends on trusting the log operator's internal ordering. A malicious operator could, in principle, delay publishing a checkpoint and later insert records with earlier sequence numbers if no prior witness publication had constrained them. For this reason, frequent checkpointing (every 24 hours or less) is strongly recommended.

9.3 Epistemic decay (informative)

While the cryptographic integrity of a record does not degrade over time — SHA‑256 and Ed25519 signatures remain valid indefinitely against today's adversaries — the epistemic value of old records may diminish in audit contexts.

• Epistemic value is the degree to which a record supports a justified belief about a fact at a past point in time.
• Over long periods, changes in context, regulatory frameworks, or the discovery of omission may reduce the relevance of an old record, even though its mathematical integrity is intact.

Implementers SHOULD define a decay horizon at the verification layer. A recommended default is 400 days from the date of the first witness receipt covering a record. After this horizon, the record should be flagged as stale during audit verification, prompting reviewers to consider its continued relevance. This is a policy decision, not a protocol enforcement, and may vary by use case (e.g., financial audits may require shorter horizons; academic archives may tolerate longer ones).

Witness class may influence decay: records witnessed by a Class C timestamp authority (RFC 3161) may carry a longer decay horizon than those witnessed only by a Class B participant, because the legal standing of the timestamp may extend the record's practical useful life.

10. Witnessing & Discovery

A record's integrity claim remains self‑contained as long as it stays inside the log operator's system. It becomes forensically meaningful only when an external, independent party attests to having seen it at a point in time.

10.1 Witnessing requirement

To achieve ETIP‑Conformant status, a log operator MUST:

• Publish the current chain root to at least two (2) independent witness channels within every 24‑hour period.
• Retain and reference each witness's receipt in the log's checkpoint records.

If no checkpoint has been witnessed within 24 hours of the prior checkpoint, the log's temporal guarantees are considered lapsed for records appended since the last witnessed checkpoint.

10.2 Witness classes

Witnesses are categorized into three classes based on their role, independence, and the epistemic weight they contribute.

Witnesses from Class C carry the highest individual epistemic weight due to legal and regulatory standing. Class A witnesses provide broad public visibility. Class B witnesses contribute distributed trust within a specific ecosystem.

Blockchain‑based witnessing services are not recommended unless they provide demonstrable unique value without introducing consensus overhead, energy waste, or economic token dependencies that conflict with ETIP's infrastructure philosophy (Section 11).

10.3 Recommended witness class combinations

To ensure high epistemic weight and resilience against single‑witness failure or collusion, the following combinations are recommended:

Using two witnesses of the same class is acceptable but provides lower epistemic diversity. The operator should select the combination that best matches their audit and regulatory context.

10.4 Witness communication interface

Every witness MUST expose a minimal HTTP API. The use of HTTPS (TLS 1.2 or higher) is REQUIRED for all witness communication to protect the integrity and confidentiality of submissions.

POST /witness

Submits a chain root for witnessing. The request body is a JSON object:

{
  "chain_root": "",
  "signature": ""
}

• chain_root — the current chain root that the log operator wishes to have witnessed.
• signature — the Ed25519 signature over the raw 32 bytes of the chain_root, produced by the log operator using the log's private key. The witness MUST verify this signature against the log's public key (obtained via the configuration methods in Section 10.5) before issuing a receipt. This prevents unauthorized parties from submitting fraudulent chain roots on behalf of the log.

On success, the witness returns HTTP 202 Accepted with a receipt body:

{
  "chain_root": "",
  "receipt_id": "",
  "witness_id": "",
  "witness_timestamp": "",
  "witness_signature": ""
}

• receipt_id — a unique identifier for this receipt, used for later retrieval.
• witness_signature — the witness's Ed25519 signature over the canonical bytes of the receipt object minus the witness_signature field, computed using the same self‑hash pattern as log records. Canonicalization uses JCS (RFC 8785). This ensures the receipt itself is tamper‑evident.

If the signature verification fails, the witness returns HTTP 403 Forbidden with an error message.

GET /witness/{chain_root}

Retrieves a previously issued receipt for the given chain root.

• Returns HTTP 200 OK with the receipt JSON if a receipt exists.
• Returns HTTP 404 Not Found if no receipt exists for the given chain root.

10.5 Witness configuration methods

There is no centralized global registry of witnesses. Implementors discover and configure witnesses using one or more of the following methods:

Static configuration is RECOMMENDED because it avoids external runtime dependencies and simplifies auditing. Regardless of discovery method, all witness public keys MUST be obtained through an independent, trusted channel before the first submission.

11. Infrastructure Philosophy

ETIP is designed to run in constrained environments. It does not require large data centers, continuous high‑performance compute, or specialized hardware. It can operate on edge workers, small devices, and low‑power systems.

11.1 Guiding principle

Integrity should not depend on heavy infrastructure.

Many data integrity systems have inherited the operational cost of blockchains — global consensus, proof‑of‑work, economically incentivized validators, continuous network participation. ETIP rejects these assumptions. Chaining, fingerprinting, and witnessing are computationally lightweight by design. SHA‑256 and Ed25519 are efficient on modern hardware, and even on constrained platforms (embedded ARM, low‑power SoCs, small‑footprint virtual machines), the cost of hashing and signing is negligible.

A system meant to improve accountability should not increase environmental cost. The Merkle tree compression ensures that even the smallest system‑on‑chip can participate without burden to water, air, nature, or the surrounding ecosystem. There is no mining, no staking, no continuous network chatter.

11.2 Operational characteristics

11.3 Deployment scenarios

ETIP is suitable for:

• Edge logging — IoT devices, remote sensors, or offline systems that record events in the field and later synchronize with witnesses.
• Embedded audit trails — Firmware update logs, configuration change trackers, and build‑process artifact chains.
• Low‑resource environments — Regions or organizations with limited internet connectivity, intermittent power, or minimal compute capacity.
• ESG and sustainability reporting — Where the energy footprint of the audit system itself is subject to scrutiny; ETIP avoids undermining the environmental goals it helps report on.

The operator can run ETIP on a Raspberry Pi, a cloud function, or a dedicated server — the protocol imposes no minimum hardware requirement beyond the ability to compute SHA‑256 and Ed25519.

11.4 Environmental and social responsibility

ETIP's design intentionally biases toward low‑impact operation. There is no token, no incentive to compete for block space, and no reason to increase computational expenditure beyond what is necessary for integrity. The protocol's carbon footprint is effectively zero per record.

This aligns ETIP with the broader goals of sustainable technology: tools that solve problems without creating new ones. If an audit system consumes more resources than the activity it audits, it has failed its own purpose. ETIP ensures that the integrity layer is never the environmental bottleneck.

12. Data Model (Schemas)

All fingerprints are SHA‑256 over canonicalized data. Signatures use Ed25519. The following schemas define the complete record types in an ETIP log.

12.1 Commit record

A commit record binds one artifact into the log. It is the most common record type.

{
  "spec": "ETIP-2.1",
  "log_id": "string",
  "seq": 123,
  "type": "commit",
  "prev_record_fp": "hex-or-null",
  "record_fp_alg": "sha-256",
  "artifact_fp": "hex",
  "meta": {
    "content_type": "string",
    "external_ref": "string"
  },
  "record_fp": "hex"
}

Self‑hash rule for commit records: Remove record_fp, apply JCS to the remaining object, compute SHA‑256, and set the result as record_fp.

12.2 Batch marker record

A batch marker closes a batch of commit records and anchors the batch root into the chain root.

{
  "spec": "ETIP-2.1",
  "log_id": "string",
  "seq": 789,
  "type": "batch_marker",
  "prev_record_fp": "hex",
  "record_fp_alg": "sha-256",
  "batch_root": "hex",
  "prev_batch_root": "hex-or-null",
  "chain_root": "hex",
  "record_fp": "hex"
}

The chain root stored in the batch marker is the post‑update value — it includes this batch's contribution. It becomes the previous_chain_root for the next batch marker.

12.3 Checkpoint Record

A checkpoint record captures the state of the log at a moment in time and attests that the chain root has been published to external witnesses. It is the evidence that moves the log from ETIP‑Compatible to ETIP‑Conformant.

{
  "spec": "ETIP-2.1",
  "log_id": "string",
  "seq": 1001,
  "type": "checkpoint",
  "prev_record_fp": "hex",
  "covers_seq": 1000,
  "chain_root": "hex",
  "operator_signature": "hex",
  "witness_receipts": [
    {
      "witness_id": "url",
      "chain_root": "hex",
      "receipt_id": "string",
      "witness_timestamp": "ISO8601",
      "witness_signature": "hex"
    }
  ],
  "checkpoint_fp": "hex"
}

Self‑hash rule for checkpoint records: identical to other record types — remove checkpoint_fp, apply JCS, hash with SHA‑256.

Inclusion of witness receipts: The receipts in the witness_receipts array are identical to the objects returned by the witnesses' POST /witness endpoint. By embedding them directly in the log record, the checkpoint becomes self‑contained: an auditor can verify the operator's signature, then verify each witness signature, and thereby confirm the chain root was observed externally at the recorded timestamps — all without retrieving separate witness archives.

13. ESG Context

ETIP does not stop companies from changing numbers. It makes those changes visible.

In sustainability reporting (ESG), data evolves: baselines are recalculated, methodologies change, errors are discovered and corrected. What matters for trust is not a single snapshot, but the timeline — the sequence of what was claimed, when, and how it was later revised.

ETIP provides the infrastructure for that timeline:

• An auditor can replay the log and see exactly when a number appeared, when it was superseded, and whether any record was retroactively altered.
• Witness receipts prove that a particular claim existed at a particular time, before any later scandal or restatement could have motivated its fabrication.
• Batch and chain roots allow auditors to verify an entire reporting history from a single chain root, without trusting the company's internal archiving.

Critically, ETIP itself does not interpret ESG data; it only preserves the historical record. The protocol is compatible with any reporting framework (GRI, SASB, ESRS, ISSB) and does not enforce any particular disclosure standard.

14. Mandatory Non‑Claims

All implementations of ETIP MUST prominently state that the protocol:

• Does not verify correctness of the data.
• Does not certify compliance with any regulation or standard.
• Does not adjudicate truth or falsity of statements.
• Does not ensure completeness of records.
• Does not issue assets or tokens of any kind.
• Does not protect against key compromise — a stolen operator key may allow forged checkpoints.
• Does not offer perpetual cryptographic security — future advances may weaken SHA‑256 or Ed25519.

ETIP only preserves temporal integrity: the order and existence of records, and the inability to alter them without breaking evidence.

These non‑claims must appear in documentation, on‑premise interfaces, and any public‑facing tools that consume ETIP logs. Auditors and users must understand exactly what ETIP can and cannot deliver.

Changelog

v1.2 (Revised)

• Clarified self‑hash computation with explicit key‑removal rule.
• Added formal batch_marker record schema and chain root definition.
• Removed misleading "superseded" language from deletion guarantee.
• Specified that the log operator signs the chain root before witness submission, and that witnesses verify this signature.
• Added explicit canonicalization rule for witness receipt signing (self‑hash pattern).
• Renamed conformance levels to ETIP‑Compatible and ETIP‑Conformant for clarity.
• Added lower‑bound time guarantee (informative).
• Expanded epistemic decay guidance with witness‑class influence.
• Updated checkpoint record schema to include operator_signature and inline witness_receipts.
• Added key compromise and crypto‑agility to threat model and non‑claims.
• Clarified that every batch must contain at least one commit record.