TrackOne Project

elkhatabibilal@gmail.com

General Independent Submission telemetry merkle timestamping iot This document specifies a verifiable telemetry ledger profile for resource-constrained sensing environments. The profile defines how a gateway accepts framed telemetry, applies anti-replay policy, projects accepted frames into canonical facts, builds deterministic daily Merkle commitments, and anchors daily artifacts with external timestamp proofs. OpenTimestamps (OTS) is the default anchoring mechanism; optional parallel attestation methods (RFC 3161 timestamp protocol and peer signatures) are also described. The goal is interoperability and independent auditability, not new cryptographic primitives.

Introduction Long-lived telemetry deployments such as environmental monitoring, heritage conservation, and infrastructure health need evidence that measurements were not silently altered after a collection. A coastal sensor array that reports temperature every six hours over a five-year deployment produces tens of thousands of records; stakeholders such as regulators, researchers, and insurers may need to verify, years later, that the data they rely on is the same data the sensors produced. Existing standards provide important building blocks:

• Deterministic CBOR encoding (),
• Timestamping via trusted timestamp authorities (),
• CBOR-based Merkle tree proofs (), and
• Supply-chain transparency architectures ().

However, none of these building blocks defines a complete operational profile for the constrained case: devices with intermittent uplinks, limited compute budgets, and no persistent Internet connectivity at the collection point. SCITT assumes a transparency service is reachable for receipt-oriented workflows. COSE Merkle proofs define proof encodings, but not batching policy or anchoring lifecycle. RATS addresses device identity attestation, but not telemetry commitment. The discussion below compares this profile directly with and because those documents define adjacent, but not identical, transparency and proof disclosure models. This document fills that gap. It specifies a practical profile that combines these building blocks for low-power telemetry systems:

1. Emit encrypted framed telemetry.
2. Ingest and validate frames with anti-replay.
3. Project accepted frames into canonical facts.
4. Build deterministic daily Merkle commitments.
5. Chain days with previous-day root linkage.
6. Anchor the day artifact using external timestamp proofs.
7. Verify independently from disclosed artifacts.

The profile is informed by TrackOne pre-production validation, including constrained uplink simulations, hardware-in-loop testing, and daily batching and verification workflows.

Relationship to Existing Work This document is complementary to, not a replacement for, the following work:

• SCITT (): SCITT defines architectures for transparent, append-only logs of signed statements with receipts. This profile differs in that it is optimized for disconnected, daily-batch operation where a transparency service is not assumed to be continuously reachable.
• COSE Merkle Tree Proofs (): COSE-MERKLE defines proof encodings. This profile defines a batching and commitment contract and may use COSE-based proof encodings in a future revision.
• RATS: This profile explicitly defers device identity, attestation, and key lifecycle to deployment-specific mechanisms.
• RFC 8949 (): This profile defines a TrackOne deterministic CBOR commitment profile for gateway-side commitments. It does not attempt to define a general-purpose CBOR profile beyond the commitment path described here.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Terms:

• Frame: One NDJSON telemetry unit containing header and AEAD fields.
• Fact: Canonical telemetry record projected from an accepted frame.
• Commitment profile: The serialization, hash, and Merkle rules that produce deterministic commitment outputs.
• Ledger set for day D (F_D): The set of accepted facts committed for day D.
• Day artifact: The authoritative canonical day record written as day/YYYY-MM-DD.cbor.
• Authoritative: Used for the canonical artifact that verifiers MUST treat as the cryptographic source of truth.
• Projection: A non-authoritative representation (for example JSON) derived from an authoritative artifact.
• OTS metadata sidecar: proofs/YYYY-MM-DD.ots.meta.json, linking an artifact digest to an OTS proof path.
• Replay unit: The pair (dev_id, fc), where fc is a frame counter for device dev_id.
• Day boundary: A UTC calendar day boundary. Day labels in this profile use YYYY-MM-DD in UTC.
• Disclosure class: The level of artifact disclosure associated with a verification claim.

System Roles

• Device (Pod): Produces framed telemetry.
• Gateway: Validates, decrypts, applies anti-replay, projects facts, batches, and anchors day artifacts.
• Verifier: Recomputes commitments and validates proofs from disclosed artifacts.
• OTS Calendar(s): Provides OTS attestations for day artifact hashes.
• Optional TSA: An RFC 3161 timestamp authority over the same digest.
• Optional Peers: Co-sign daily roots for short-term provenance.

Data and Commitment Model

Frame Contract A frame is transported as NDJSON with fields:

Gateways MUST validate header field presence, header ranges, and AEAD authentication before fact emission.

• hdr.dev_id MUST be an unsigned integer in the range 0..65535.
• hdr.msg_type MUST be an unsigned integer in the range 0..255.
• hdr.fc MUST be an unsigned integer in the range 0..(2^32-1).
• hdr.flags MUST be an unsigned integer in the range 0..255.
• nonce MUST be base64 text that decodes to exactly 24 bytes.
• tag MUST be base64 text that decodes to exactly 16 bytes.

Frames that fail parse, range, or AEAD validation MUST be rejected before fact commitment and MUST NOT produce committed facts.

Anti-Replay Semantics The replay unit is (dev_id, fc).

• A gateway MUST consume at most one frame per (dev_id, fc) into the ledger.
• Duplicate or out-of-window frames MUST NOT produce committed facts.
• The RECOMMENDED default replay window is 64 frame counter values per device.
• Frames arriving with fc more than window_size behind the highest accepted counter for a device MUST be rejected.
• Frames arriving with fc more than window_size ahead of the highest accepted counter for a device MUST also be rejected, because an excessive forward jump is treated as out of window by the current gateway profile.

Structured Rejection Evidence Gateways SHOULD produce structured rejection evidence for rejected frames. A rejection record SHOULD include at minimum:

• device_id,
• fc (or null if unavailable),
• reason,
• observed_at_utc, and
• frame_sha256.

Rejection evidence is an audit artifact and MUST NOT be hashed into ledger commitments. Replay State Persistence Gateways SHOULD persist replay state across restart. If replay state is lost, gateways SHOULD record a continuity break event and SHOULD NOT silently re-accept counters that could already have been committed. Scope Limitation This profile provides tamper-evidence for committed facts. It does not prove the absence of selective pre-commitment drops by a malicious gateway.

Frame-to-Fact Projection The frame-to-fact projection transforms a validated, decrypted frame into a canonical fact suitable for commitment. The committed fact is a structured record derived from the decrypted payload, not a copy of transport bytes.

1. The gateway MUST verify AEAD authentication.
2. The gateway MUST decrypt the ciphertext.
3. The gateway MUST parse the decrypted plaintext according to the frame's msg_type.
4. The gateway MUST construct a fact object.
5. The gateway MUST serialize that fact object under the gateway commitment profile.
6. The canonical fact bytes are then hashed for Merkle inclusion.

A committed fact MUST contain at minimum:

• device_id,
• timestamp,
• nonce, and
• payload.

Ciphertext, raw transport bytes, and the authentication tag MUST NOT be part of the committed fact object. The exact payload schema is deployment-specific; the deterministic projection contract is the normative requirement.

Deterministic CBOR Commitment Encoding This section does not define a new general-purpose CBOR variant. It records the narrow deterministic CBOR encoding used for commitment bytes in the current TrackOne gateway and ledger implementation. The identifier trackone-cbor-map-v1 names this commitment recipe so verifiers can tell which byte-level rules were used. The authoritative commitment artifacts, namely CBOR fact artifacts and the canonical day artifact, use a constrained subset of deterministic encoding under Section 4.2.1 of . For TrackOne commitment bytes, the following concrete choices apply:

• All commitment-path items MUST use definite-length encoding.
• Integers MUST use the shortest encoding width permitted by .
• Map keys MUST be CBOR text strings.
• Map keys MUST be sorted by encoded key length ascending, then by lexicographic order of the encoded key bytes.
• Finite floating-point values MUST be encoded using the shortest of float16, float32, or float64 that exactly preserves the value.
• NaN, positive infinity, and negative infinity MUST be rejected in commitment paths.
• CBOR tags MUST NOT appear in commitment bytes.
• Supported values are unsigned integers, negative integers, byte strings, text strings, arrays, maps, booleans, null, and deterministic finite floats.

Implementations MUST NOT accept generic CBOR serializers as authoritative commitment encoders. An encoder is acceptable only if it yields the same bytes as these rules. JSON projections of fact artifacts and day artifacts are optional and non-authoritative. They MUST NOT be used as commitment inputs. When produced, such projections SHOULD follow . Device-side or embedded components MAY use other internal encodings, including different deterministic CBOR layouts optimized for local constraints. Those encodings are not the authoritative commitment encoding described here unless they are explicitly identified by a distinct commitment_profile_id and verified under their own rules.

Deterministic Commitment Tree Calculation For a given day D, the current commitment profile computes a daily root from the canonical fact commitment bytes produced under . The following steps describe that calculation. Leaf Digests

• Each canonical fact byte string is hashed with SHA-256, yielding a 32-byte leaf digest.

Digest Ordering

• To make the daily root independent of file order or ingest order, leaf digests MUST be sorted in ascending byte order before reduction.
• Lowercase hexadecimal is a representation format for artifacts and examples only; internal Merkle computation operates on raw hash bytes.
• Sorting by lowercase hexadecimal is equivalent to bytewise ascending order over the raw digests.

Pairwise Reduction

• The sorted digests are reduced pairwise by computing SHA-256(left_child_bytes || right_child_bytes), where both operands are raw 32-byte digests.
• If a layer has an odd number of digests, the final digest is duplicated to form the last pair.
• The current commitment profile does not prepend domain-separation bytes to leaf or parent hashes.

Empty Day

• If no facts are committed for the day, the daily root is the SHA-256 digest of zero bytes: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.

The resulting daily root is deterministic for the set of committed facts. Because the leaf digests are sorted before reduction, the result depends on the committed fact set rather than on ingestion order. Any future change to this calculation that alters commitment bytes (for example, adding domain separation) MUST use a new commitment_profile_id.

Day Artifact Schema The authoritative day artifact is a CBOR-encoded day record produced under . The day record contains the following fields:

• version (uint): day-record schema version, currently 1.
• site_id (tstr): site identifier.
• date (tstr): UTC day label in YYYY-MM-DD form.
• prev_day_root (tstr): previous day root as 64 lowercase hexadecimal characters.
• batches (array): array of batch objects.
• day_root (tstr): deterministic day root as 64 lowercase hexadecimal characters.

Each batch object contains:

• version (uint): batch-record schema version, currently 1.
• site_id (tstr): site identifier.
• day (tstr): UTC day label in YYYY-MM-DD form.
• batch_id (tstr): batch identifier.
• merkle_root (tstr): batch Merkle root as 64 lowercase hexadecimal characters.
• count (uint): number of committed facts in the batch.
• leaf_hashes (array of tstr): sorted leaf hashes as lowercase hexadecimal strings.

day/YYYY-MM-DD.cbor is authoritative. The corresponding day/YYYY-MM-DD.json file is a projection only. This document uses normative field tables rather than CDDL. A future revision may add a formal CDDL appendix if broader independent implementations require it.

Day Chaining Day records include prev_day_root.

• The genesis day for a site MUST set prev_day_root to 64 ASCII zero characters, representing 32 zero bytes.
• Non-genesis days MUST set prev_day_root to the previous committed day's day_root.

Because day labels are UTC-based, chaining semantics are also defined on UTC day boundaries.

Artifacts and Verification Bundles Illustrative artifact layout:

• facts/<fact-id>.cbor — authoritative canonical facts
• facts/<fact-id>.json — optional projections
• day/YYYY-MM-DD.cbor — authoritative canonical day artifact
• day/YYYY-MM-DD.json — optional projection
• blocks/YYYY-MM-DD-00.block.json — block and batch metadata
• day/YYYY-MM-DD.cbor.sha256 — convenience digest
• day/YYYY-MM-DD.cbor.ots — OTS proof
• proofs/YYYY-MM-DD.ots.meta.json — OTS binding metadata

Deployments MAY store artifacts differently and MAY export them as bundles. The path shapes above are illustrative. At minimum, an OTS sidecar MUST bind:

• artifact,
• artifact_sha256, and
• ots_proof.

Verifiers MUST recompute the day artifact digest and compare it with the sidecar before accepting any proof validation result.

Anchoring and Verification

Anchoring Contract The generic anchoring contract is simple: a gateway computes the SHA-256 digest of the authoritative day artifact and submits that digest to one or more external timestamping channels. Verifiers MUST first recompute the day artifact digest locally; proof validation occurs only after digest binding validation succeeds. A deployment conforming to this profile MUST use at least one anchoring channel. OTS is the default channel described by this document; RFC 3161 and peer signatures are optional parallel channels.

OTS Anchoring Profile When is used, the gateway stamps SHA-256(day/YYYY-MM-DD.cbor) and stores an OTS proof plus an OTS sidecar.

OTS Anchoring Lifecycle

1. Submission: the gateway submits the day artifact digest to one or more OTS calendars.
2. Pending: a calendar may return an incomplete proof while awaiting Bitcoin commitment.
3. Upgrade: the gateway or a background process may later upgrade the proof to include completed attestations.
4. Verification: a verifier recomputes the artifact digest and validates the proof.

Gateways SHOULD submit to multiple independent calendars to reduce single-calendar unavailability risk.

Handling Delayed or Failed Anchoring

• Calendar unreachable: the gateway MUST still write the day artifact and SHOULD retry later.
• Upgrade delay: verifiers SHOULD treat pending proofs as unanchored and flag the condition, not as invalid.
• Proof retention: gateways MUST retain proof files for at least the operational retention period of the corresponding day artifacts.

Optional Parallel Attestation Deployments MAY also produce:

• An timestamp response over the same day-artifact digest.
• A peer signature quorum over (site_id, day, day_root, context).

When multiple channels are present, verifiers SHOULD validate all available channels independently and report per-channel results. If a verifier is configured in strict mode for optional channels, failure of those channels MUST cause overall verification failure.

Verification Verifiers SHOULD apply checks in the following fail-fast order:

1. Validate that disclosed artifacts are sufficient for the claimed disclosure class.
2. Recompute the Merkle root from canonical fact CBOR artifacts.
3. Compare the recomputed root to day_root.
4. Recompute SHA-256(day/YYYY-MM-DD.cbor) and compare it to the sidecar artifact_sha256.
5. Validate the OTS proof when OTS is required or present.
6. Validate optional RFC 3161 and peer attestations as configured.

Verifier implementations SHOULD expose machine-usable failure categories:

• malformed or missing artifacts,
• Merkle mismatch,
• missing or invalid OTS proof,
• sidecar mismatch or digest mismatch, and
• optional-channel failure.

Disclosure Classes Verification claims depend on what artifacts are disclosed. This profile defines three disclosure classes.

• Class A (Public Recompute): sufficient material for independent fact-level recomputation.
• Class B (Partner Audit): controlled disclosure with redacted or partitioned fact material.
• Class C (Anchor-Only): existence and timestamp evidence only.

A Class A bundle MUST include:

• all canonical fact artifacts required to recompute the claimed day root,
• the canonical day artifact,
• block and batch metadata, and
• the OTS proof plus its sidecar metadata.

A Class A bundle SHOULD also include a machine-readable verification manifest and SHOULD record the commitment_profile_id. A Class B bundle MUST include:

• the canonical day artifact,
• block and batch metadata,
• the OTS proof plus sidecar metadata, and
• cryptographic commitments to any withheld or partitioned fact material, and
• a policy statement describing withheld or partitioned fact material.

Class B outputs MUST NOT be represented as publicly recomputable. A Class C disclosure MUST be labeled as existence and timestamp evidence only and MUST NOT claim fact-level reproducibility. A Class C bundle MUST include:

• the canonical day artifact, and
• at least one timestamp proof artifact (for example, an OTS proof or an RFC 3161 response).

If a verification manifest is present, it SHOULD include:

• disclosure_class,
• commitment_profile_id,
• artifact path and digest entries,
• per-channel anchor status, and
• a list of checks executed.

Versioning This profile has several independent version surfaces:

• Document revision (for example -00, -01) is editorial and is not part of commitment output.
• Artifact schema versions are carried by the version fields in day and batch records.
• commitment_profile_id identifies the canonical CBOR, hash, and Merkle rules that define commitment outputs.

The commitment profile defined in this document is trackone-cbor-map-v1. If a verifier encounters an unsupported commitment_profile_id, it MUST reject the verification claim rather than silently using a fallback interpretation.

Conformance Vectors Determinism claims in this profile are testable. Implementations that claim conformance to trackone-cbor-map-v1 MUST be able to reproduce the published conformance vectors for that profile. Published vector sets SHOULD include coverage for:

• empty day,
• single fact,
• odd leaf count,
• power-of-two leaf count,
• duplicate leaf hashes,
• genesis chaining,
• non-genesis chaining, and
• a full Class A disclosure example.

Cross-implementation checks MUST verify byte-for-byte parity across independent implementations. Any mismatch in canonical bytes or roots is a conformance failure. Published vector bundles MUST include the commitment_profile_id.

Security Considerations This profile does not introduce new cryptographic primitives. Security depends on correct composition of existing primitives and on operational discipline. Replay and Duplicate Suppression The (dev_id, fc) replay unit enforces single-consumption: at most one committed fact per unique replay unit. Tamper Evidence Once a day artifact is anchored, mutation of that artifact changes its digest and invalidates the proof. Day chaining extends this property across days. Proof Substitution Sidecar metadata binds an artifact digest to a proof path. Verifiers MUST recompute the artifact digest independently. Calendar Trust and Withholding A compromised or unavailable calendar can delay or withhold proofs. Multi-calendar submission reduces single-calendar dependency but does not eliminate coordinated compromise risk. Operational Misuse Test or placeholder proofs MUST NOT be treated as production attestations. Confidentiality Boundary This profile addresses integrity and timing provenance only. Payload confidentiality remains the responsibility of the deployment's AEAD and key-management layers. Pre-Commitment Censorship This profile proves inclusion and timestamping of committed facts. It does not prove completeness of all observed or emitted frames.

Privacy Considerations Telemetry payloads may include sensitive operational data. Operators SHOULD:

• minimize personally identifiable data in committed artifacts,
• separate identity metadata from measurement payload when possible,
• apply retention and access controls, and
• publish only data appropriate for the chosen disclosure class.

Privacy-preserving disclosures remain valid, but they MUST NOT be described as publicly recomputable unless Class A conditions are met.

IANA Considerations This document has no IANA actions. In particular, this revision does not request:

• a CBOR tag allocation,
• a media type registration, or
• a new registry entry.

The current profile is identified by in-band version and profile fields, not by IANA allocation.

Implementation Status Note to RFC Editor: Please remove this section before publication. This section records implementation status at the time of posting, per . This draft reflects the TrackOne pre-production implementation snapshot at release 0.1.0-alpha.6. A pre-production reference implementation exists and is aligned with the current 0.1.0-alpha.6 release. It is suitable for interoperability review and validation, but it is not a production deployment.

• Repository: https://github.com/bilalobe/trackone
• License: MIT

Interoperability Notes and Open Questions

• Media type strategy for canonical CBOR day artifacts.
• Whether a future revision should define a formal CDDL appendix.
• Whether future disclosure bundles should adopt COSE-MERKLE proof encodings.
• Registry strategy for disclosure and anchor-status vocabularies.
• Whether a future commitment profile should introduce domain separation.

References Normative References Informative References OpenTimestamps Project

Example Day Record (JSON Projection) This appendix shows a non-authoritative JSON projection of a day artifact. The authoritative artifact is the corresponding CBOR file.

", "batches": [ { "version": 1, "site_id": "an-001", "day": "2025-10-07", "batch_id": "an-001-2025-10-07-00", "merkle_root": "9d1f...c2", "count": 10, "leaf_hashes": [ "01ab...", "7fe2..." ] } ], "day_root": "9d1f...c2" } ]]>

Example Conformance Vector Bundle The values in this appendix were generated by the Python gateway code path and cross-checked against trackone_core._native (Rust) for deterministic CBOR and Merkle parity. This vector bundle reflects the 0.1.0-alpha.6 implementation snapshot.

The full machine-readable vector set is maintained in the TrackOne repository alongside the reference implementation.

Acknowledgments Early structural drafts of this document were prepared with AI writing assistance. All technical content, design decisions, and normative requirements were reviewed against the TrackOne implementation. The author thanks the OpenTimestamps project for the public calendar infrastructure used during validation.