6. HashAnchor: Verifiable Proof for Machine Events
6.1 What HashAnchor Is#
HashAnchor is a verifiable data and event-anchoring system. It converts machine records into tamper-evident, portable receipts that can be checked independently of the database that originally stored them.
This matters because the physical world is full of claims:
- a charger claims it delivered a quantity of energy;
- a robot claims it completed a task;
- a sensor claims it observed a temperature or location;
- a vehicle claims it arrived at a destination;
- a payment system claims a transaction was authorized;
- a platform claims a service-level condition was met.
Traditional systems record these claims in private databases. Counterparties must trust the database owner and later reconcile competing records. HashAnchor introduces a neutral proof layer without requiring all underlying data to be made public.
6.2 The HashAnchor Lifecycle#
The lifecycle has six main steps:
- Create the event record — the machine or application creates a structured record.
- Canonicalize and hash — the record is normalized and converted into a deterministic hash.
- Submit — the hash, or optionally supported content, is submitted to HashAnchor.
- Batch — many event hashes are assembled into a Merkle tree.
- Anchor — the Merkle root is committed to a blockchain or another tamper-resistant ledger.
- Receive and verify — a receipt provides the Merkle path and anchor reference needed to prove inclusion.
6.3 Why Merkle Batching Matters#
Writing every machine event directly to a blockchain would be expensive and slow. Merkle batching allows thousands or millions of records to share one onchain commitment.
Each event remains individually verifiable because its receipt contains the path from the event hash to the anchored Merkle root. A verifier does not need access to every other event in the batch.
This provides:
- lower cost per proof;
- higher throughput;
- privacy for unrelated records;
- portable verification;
- resilience against later database modification.
6.4 Portable Receipts#
A HashAnchor receipt can conceptually contain:
| Field | Purpose |
|---|---|
| Record or content hash | Identifies the exact submitted data |
| Hash algorithm | Defines how the digest was created |
| Batch identifier | Identifies the Merkle batch |
| Merkle proof | Proves the record’s inclusion in the root |
| Root hash | The commitment anchored to the ledger |
| Chain and transaction reference | Locates the anchor |
| Timestamp or block reference | Establishes ordering and approximate time |
| Signer or tenant context | Associates the submission with an authorized source |
| Payment reference, when relevant | Links proof creation to the economic transaction |
The receipt can be stored with the customer, machine operator, insurer, marketplace, auditor, or regulator. Verification does not require permanent trust in the original TLAY application database.
6.5 Linking Events into a Business Process#
One anchored event proves only that a particular record existed and has not changed. Machine commerce often requires a sequence:
- offer issued;
- offer accepted;
- service started;
- usage measured;
- payment authorized;
- service completed;
- settlement confirmed.
Each record can include a previous-event reference, session identifier, order identifier, or transaction identifier. The result is a verifiable event chain representing the business process.
This is the bridge between data integrity and economic meaning. HashAnchor is not merely a timestamping service; it can become the evidence layer for machine-delivered business outcomes.
6.6 Device-Signed Events and Payments#
The strongest workflow combines BoAT MER and HashAnchor:
- BoAT MER signs the machine event or payment authorization at the edge.
- The application submits the event hash to HashAnchor.
- HashAnchor batches and anchors the commitment.
- The receipt preserves the device signature, event hash, and anchor reference.
- A verifier checks both the device’s authority and the record’s inclusion.
This provides two distinct guarantees:
- Origin guarantee — the event was signed by the expected machine identity.
- Integrity guarantee — the signed event has not been modified since it was anchored.
Whether the underlying physical claim is accurate still depends on device security, sensor integrity, calibration, and the deployment’s operational controls. Cryptography can protect a claim from alteration; it cannot automatically make a faulty sensor truthful.
6.7 API and Integration Model#
HashAnchor can be used through a client SDK or service API. A typical integration includes:
- submit a precomputed hash;
- submit supported content for hashing;
- query batch or anchor status;
- retrieve a receipt;
- verify a receipt offline;
- attach settlement metadata or a machine-payment envelope.
The client-side TypeScript SDK is open source under Apache 2.0. The current multi-tenant server is operated as a managed service and is not currently offered as a self-hostable open-source server.
Technical references:
6.8 Current Settlement Support#
HashAnchor can connect the proof request to payment or settlement. The current shipped path includes x402 V2 settlement on EVM networks using USDC and Circle Gateway-related infrastructure. MPP/Tempo support exists in the private server environment. Other settlement integrations should be described as roadmap or deployment-specific until publicly shipped.
This distinction matters for developers: the proof protocol should remain independent of any one payment route, while production documentation should clearly identify which routes are currently available.
6.9 Trust Boundaries#
HashAnchor provides precise guarantees, not magical ones.
| It can prove | It cannot prove on its own |
|---|---|
| The submitted record matches the anchored hash | That the original physical measurement was accurate |
| The record existed no later than the anchor time | The exact real-world time if the source clock was dishonest |
| The record belongs to a particular Merkle batch | That the submitting device was uncompromised |
| A valid device key signed the record | That the key’s legal owner had proper authority unless identity policy establishes it |
| The receipt verifies against the ledger | That a commercial dispute should be decided for one party |
These boundaries make the system more credible. TLAY supplies verifiable evidence; applications, contracts, and institutions decide how that evidence is used.