Anchoring Overview

CORE-M anchors every accepted telemetry point to the BSV blockchain. The promise is simple to state and hard to fake: anyone — including an auditor who does not trust CORE-M — can prove that a specific data point existed at a specific time and has not been altered since. This page explains the guarantee, the pipeline that delivers it, and the cryptographic boundary that keeps the wallet separate from everything else. The deeper pages then cover each stage in full.

Why anchor at all

A traditional IoT platform stores telemetry in a database. If that database is edited — by an insider, an attacker, or a bug — there is no built-in way for an outside party to detect it. The records are only as trustworthy as the operator who holds them.

CORE-M removes that trust requirement. For every accepted point it computes a canonical SHA-256 hash and commits that hash to the BSV blockchain inside an OP_RETURN output. Once the transaction is mined, the commitment is immutable. From that point on:

1. Tamper evidence — any change to the original data produces a different hash, which no longer matches the on-chain commitment.
2. Independent verification — anyone holding the original data and the proof can verify it against the public blockchain, with no access to CORE-M.
3. Existence in time — the block’s position in the chain establishes a lower bound on when the data existed.
4. Scale — a Merkle tree commits thousands of points with a single on-chain transaction, so the cost per point stays small.

Tip

New to the vocabulary? Read Core Concepts and the Glossary first — terms like anchor batch, Merkle proof, and finality are used throughout this section.

What you do, and what the platform does

Your part is simple: set an anchoring policy (the mode and finality threshold for a tenant or device profile) and, when you need it, verify proofs. You never touch a wallet, fund anything, or manage tokens — CORE-M does all of that for you.

Note

The managed CORE-M platform funds and operates blockchain anchoring on your behalf. You do not manage wallets, tokens, or treasury balances — you set the anchoring policy and verify the proofs CORE-M produces.

The anchoring pipeline

Every accepted point moves through an explicit lifecycle, and CORE-M records its state at each step. The happy path runs accept → batch → anchor → confirm → final.

flowchart LR
  A([Telemetry point]) --> B[accepted\nhash + lifecycle record written]
  B --> C[validated\nwritten to telemetry stores]
  C --> D[pending_batch\nhash assigned to a batch]
  D --> E[anchored\nOP_RETURN tx broadcast, txid known]
  E --> F[confirmed\nblock inclusion observed]
  F --> G[final\nfinality depth reached]
  E -. retry .-> R[failed_retryable]
  R -.-> D
  R -. exhausted .-> T[failed_terminal]

In words:

• accepted — the point passed auth and parsing; its canonical data_hash and a durable proof-lifecycle record exist. The point is not acknowledged to the caller until that record is written.
• validated — device and profile validation passed and the point was written to the telemetry stores.
• pending_batch — the hash has been assigned to an anchoring batch. Batches flush on a count threshold (default 1000 points) or a time window (default 30s).
• anchored — the anchoring transaction was broadcast and its txid is known.
• confirmed — ARC or the SPV watcher observed the transaction in a block.
• final — the confirmation depth reached the configured finality threshold (default 6). The proof is durable and exportable as a portable bundle.
• failed_retryable / failed_terminal — a temporary failure schedules a retry; the platform resolves these for you. A reorg that invalidates a confirmed transaction moves affected records back to failed_retryable.

Hashing & Merkle Trees The exact canonical hash byte layout, JCS rules, and the OP_RETURN payload.

Modes, SLA & Finality Anchoring modes, policy resolution, the proof lifecycle, finality, and reorg handling.

For how a point reaches the anchoring service in the first place, see Sending Telemetry.

Where to go next

Read in order

1. Hashing & Merkle Trees — the exact commitment.
   
2. Modes, SLA & Finality — policy and lifecycle.
   
3. Verification — prove a point independently.