How TLAY Works

Economic Infrastructure for Autonomous Machines#

TLAY is building economic infrastructure for machines.

As AI moves from software into the physical world, machines are becoming more than tools controlled step by step by humans. Robots, vehicles, drones, energy devices, industrial equipment, sensors, and AI-operated systems are beginning to perceive demand, make decisions, provide services, purchase resources, and coordinate with other machines.

Intelligence alone, however, does not create a machine economy.

For machines to participate in commerce at scale, they need a trusted economic layer: a way to establish identity, receive limited economic authority, exchange value, produce verifiable records, and connect payment to actual delivery. In other words, the information flow, value flow, and business flow of machine activity must become digitally verifiable and programmable.

TLAY provides that layer through two core products:

• BoAT MER gives machines a secure economic runtime: identity, signing, authorization, payment, and commerce capabilities embedded close to the machine.
• HashAnchor turns machine events and transaction records into portable, tamper-evident proofs that can be independently verified.

Together, they form the foundation for programmable machine commerce.

TLAY turns physical machines into verifiable economic actors.

1. What TLAY Is—and What It Is Not#

TLAY is best understood as economic infrastructure for autonomous machines.

“Financial infrastructure” describes only part of the system. Payments and settlement matter, but machine commerce also requires identity, authorization, service delivery, evidence, policy, accounting, and coordination. “Economic infrastructure” is broad enough to describe the full stack while avoiding the implication that TLAY is a bank, custodian, or licensed financial institution.

TLAY does not aim to become a consumer bank for robots. Nor does it aim to put every sensor reading or machine action directly on a blockchain. Its role is to provide the protocol, software, and trust infrastructure through which machines can safely take part in economic activity.

The distinction is important. TLAY enables financial functions without reducing its strategic identity to finance. It supports payments, but also establishes the trusted context that makes a payment meaningful: who acted, under whose authority, for what service, under which conditions, and with what evidence of delivery.

2. Why Machines Need a New Economic Layer#

The internet gave people and companies a common information network. Cloud platforms gave software a common computing environment. Blockchains introduced programmable ownership and settlement. The next step is to connect these capabilities to machines operating in the physical world.

Today, most connected machines remain economically passive. They can sense, compute, and communicate, but commercial decisions are handled by centralized platforms or human operators. A charging station may deliver electricity, a robot may complete a task, or a sensor may produce valuable data, yet the machine itself usually cannot:

• prove its identity across organizational boundaries;
• demonstrate the authority under which it is acting;
• negotiate or accept a machine-readable commercial offer;
• authorize a payment within predefined limits;
• produce trustworthy evidence of delivery;
• settle frequently at very small transaction sizes;
• build a portable economic history;
• coordinate with counterparties that do not share the same database.

This becomes a structural bottleneck as the number of autonomous machines grows. Bilateral API integrations do not scale to an open economy. Each new relationship requires another account system, another commercial integration, another trusted intermediary, and another reconciliation process.

Machine commerce needs shared infrastructure.

The foundation is the convergence of three flows:

1. Information flow — what the machine observed, requested, decided, or reported.
2. Value flow — what was authorized, paid, escrowed, routed, or settled.
3. Business flow — what service was offered, accepted, delivered, and completed.

When these flows are isolated in separate private systems, counterparties must trust the platform that controls the records. When their critical states can be linked through cryptographic proofs and programmable settlement, machines can collaborate across companies and networks with much lower trust and reconciliation costs.

This does not mean publishing everything on a public ledger. It means placing the minimum trust-bearing state onchain—or anchoring it to a verifiable ledger—while keeping sensitive and high-volume data offchain.

3. Core Concepts#

3.1 Machine Account#

A machine account is the machine-economy equivalent of an internet account combined with a programmable wallet and an operational identity.

It allows a machine to:

• hold or reference a unique cryptographic identity;
• authenticate itself to services and counterparties;
• sign requests, events, and commercial authorizations;
• receive a limited spending or earning mandate;
• use supported payment methods;
• associate transactions with verifiable machine activity;
• accumulate an auditable economic history.

A machine account does not imply that the machine legally owns assets or acts without human responsibility. Legal ownership and ultimate accountability may remain with an individual, enterprise, operator, or protocol. The account is the technical vehicle through which delegated economic authority is expressed and enforced.

3.2 Controlled Economic Authority#

Machines should not receive unlimited control over money. They need constrained, programmable authority.

An owner or operator can define rules such as:

• maximum value per transaction;
• daily or monthly spending limits;
• approved assets, currencies, or payment rails;
• approved counterparties or service categories;
• geographic and time restrictions;
• price ceilings and service-quality thresholds;
• conditions requiring human or supervisory approval;
• automatic suspension after anomalous behavior.

This creates a hierarchy of authority:

The machine becomes autonomous within a clearly bounded economic envelope.

3.3 Three Economic Flows#

TLAY connects three flows that are often separated in traditional systems.

The system becomes powerful when one verifiable chain of evidence connects all three:

Machine A accepted offer X, Machine B delivered resource Y, the measured delivery state was Z, and payment P was authorized and settled under policy Q.

3.4 Onchain-Verifiable, Not Onchain-Everything#

Physical machines generate far more data than a blockchain should store. Raw video, continuous telemetry, sensor streams, private operational data, and proprietary algorithms generally belong offchain.

TLAY follows a selective-verifiability model:

• raw data can remain on the device, edge network, cloud, or enterprise database;
• critical events are normalized and cryptographically hashed;
• related events can be grouped into Merkle trees;
• compact commitments are anchored to a public or permissioned chain;
• a portable receipt lets any authorized party verify inclusion and integrity later.

This design preserves privacy and scalability while making the important parts independently auditable.

3.5 The Machine Commerce Loop#

A complete machine-commerce transaction usually follows six stages:

1. Discover — a machine finds an available resource, service, or counterparty.
2. Evaluate — it evaluates price, quality, identity, policy, and operational need.
3. Authorize — it verifies that the proposed action falls within its delegated authority.
4. Transact — the parties exchange service and value, potentially in real time or in small increments.
5. Prove — relevant events, state transitions, and transaction references are captured as verifiable evidence.
6. Settle and learn — value is settled, records are reconciled, and the outcome informs future policy or reputation.

BoAT MER primarily enables the machine-side identity, authorization, and transaction functions. HashAnchor primarily enables the proof, audit, and cross-system verification functions. The surrounding application or platform defines the commercial logic.

4. Architecture Overview#

TLAY is designed as a modular stack. Different industries can retain their existing hardware, applications, cloud systems, and payment partners while adding a common machine-economic layer.

The stack can be viewed in four layers:

The long-term network is created by the common identities, proofs, policies, and transaction patterns shared across these layers—not by forcing every participant into a single closed application.

5. BoAT MER: The Machine Economic Runtime#

5.1 What BoAT MER Is#

BoAT MER is an open-source embedded runtime that gives constrained devices and machines native economic capabilities.

It is written in C for environments where memory, computing power, connectivity, and energy may be limited. The current implementation targets ESP32-class hardware and provides a portability abstraction layer for additional platforms. Verified environments include ESP32-S3, ESP32-C3, Linux, and macOS development environments.

BoAT MER is not a blockchain node and is not a settlement backend. It is the machine-side runtime responsible for creating and protecting identity, signing messages, enforcing local policy, and interacting with commerce or payment protocols.

5.2 Why the Runtime Belongs Close to the Machine#

If every economic action must be signed by a remote cloud server, the machine has no independent economic integrity. A compromised cloud account could impersonate thousands of devices, while intermittent connectivity could stop local commerce entirely.

Placing a minimal runtime near the machine enables:

• device-bound identity;
• local cryptographic signing;
• offline or intermittently connected operation;
• lower-latency authorization;
• separation between fleet policy and device execution;
• more credible evidence that an action originated from a specific machine.

The runtime can use secure elements or hardware-backed key storage when available. The exact security model depends on the host device and deployment profile.

5.3 Functional Layers#

BoAT MER provides several composable capabilities.

Cryptographic foundation#

• SHA-256 and Keccak hashing;
• Ed25519 and secp256k1 signing support;
• key generation and key management interfaces;
• portable abstraction for hardware-specific cryptographic backends.

Machine identity#

• generation or import of device keys;
• decentralized identifier support;
• signing of challenges, requests, and events;
• binding between a physical device and a machine account.

Attestation and event signing#

• signing of machine-generated claims;
• creation of verifiable event envelopes;
• attachment of timestamps, counters, nonces, and device context;
• handoff of event commitments to HashAnchor or another verifier.

Payment authorization#

• construction and signing of machine payment instructions;
• enforcement of local spending or transaction policy;
• support for payment protocols appropriate to low-value, high-frequency commerce;
• separation of device authorization from back-end settlement.

Communication and commerce interfaces#

• BLE-based machine-to-machine interaction;
• compact message formats for constrained devices;
• integration points for HTTP and gateway-mediated workflows;
• modular adapters for payment and application protocols.

5.4 Buyer and Seller Roles#

A machine may act as a buyer, a seller, or both.

Buyer role

A buyer machine discovers a service, checks the offer, validates the seller, confirms that the purchase meets its local policy, and signs an authorization. Examples include:

• an autonomous vehicle buying energy;
• a drone paying for landing, charging, or data relay;
• a robot purchasing access to an elevator or workstation;
• an industrial machine buying maintenance or spare capacity.

Seller role

A seller machine advertises a resource, presents a machine-readable offer, delivers the resource, measures usage, and receives or verifies payment authorizations. Examples include:

• a charger selling electricity;
• a sensor selling authenticated data;
• a robot selling work by task or time;
• a machine selling spare compute, storage, bandwidth, or physical capacity.

5.5 Streaming and Micropayment Commerce#

Many machine services are continuous rather than discrete. Energy, bandwidth, compute, mobility, and equipment access can be consumed second by second. A single prepayment creates buyer risk; a single payment after delivery creates seller risk.

BoAT MER supports a streaming nanopayment pattern over BLE:

1. The seller broadcasts or exposes an offer.
2. The buyer validates the offer and establishes a session.
3. Service is divided into measurable slices.
4. The buyer signs an authorization for each slice or group of slices.
5. The seller verifies authorization before continuing delivery.
6. Signed authorizations are submitted or aggregated for off-device settlement.

The current BLE service uses the 0xEE00 service family. On supported EVM flows, per-slice authorizations can use EIP-3009-style transfer authorizations, allowing the device to sign while a gateway or settlement actor submits the transaction.

This creates a tighter link between delivery and payment without requiring a blockchain transaction for every millisecond of service.

For protocol-level details, see the BoAT MER BLE protocol specification.

5.6 Payment Profiles and Deployment Footprint#

Different machines require different capabilities. BoAT MER therefore supports build profiles such as:

• Full profile — buyer and seller capabilities;
• Buyer profile — optimized for purchasing services;
• Seller profile — optimized for offering and metering services.

Deployments can include only the required cryptography, protocols, and network adapters. This helps preserve a small footprint on constrained hardware and reduces the attack surface.

5.7 Current Payment Support#

The current open-source runtime includes integrations at different maturity levels.

The payment layer is intentionally modular. TLAY’s strategic value is not tied to a single chain or currency. It is the machine-side authority and protocol layer that can connect to multiple settlement systems.

5.8 What BoAT MER Does Not Do#

BoAT MER does not by itself:

• custody funds;
• operate a blockchain node;
• provide liquidity or foreign exchange;
• settle every payment on the device;
• determine legal ownership or liability;
• replace a fleet-management or business application;
• prove that every physical claim is true without an appropriate sensor and trust model.

It gives the machine the ability to participate securely in a larger economic system.

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:

1. Create the event record — the machine or application creates a structured record.
2. Canonicalize and hash — the record is normalized and converted into a deterministic hash.
3. Submit — the hash, or optionally supported content, is submitted to HashAnchor.
4. Batch — many event hashes are assembled into a Merkle tree.
5. Anchor — the Merkle root is committed to a blockchain or another tamper-resistant ledger.
6. 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:

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:

1. BoAT MER signs the machine event or payment authorization at the edge.
2. The application submits the event hash to HashAnchor.
3. HashAnchor batches and anchors the commitment.
4. The receipt preserves the device signature, event hash, and anchor reference.
5. 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:

• HashAnchor API reference
• Settlement envelope specification
• HashAnchor repository

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.

These boundaries make the system more credible. TLAY supplies verifiable evidence; applications, contracts, and institutions decide how that evidence is used.

7. Machine Commerce Enabler: From Physical Scenario to Live Commerce#

BoAT MER and HashAnchor are reusable infrastructure. Enterprises, however, usually start with a physical business problem rather than a protocol requirement. They need a fast path from an existing machine scenario to a functioning machine-commerce system.

The Machine Commerce Enabler is TLAY’s solution layer for that transformation.

It combines:

• machine identity and account provisioning;
• embedded runtime integration;
• pricing and service-definition logic;
• economic authorization policies;
• payment and settlement routing;
• event and proof schemas;
• fleet operations and monitoring;
• dashboards, reconciliation, and developer APIs.

It is not a third isolated product. It is the integrated implementation pattern through which BoAT MER and HashAnchor solve a complete customer problem.

7.1 Service Definition#

The first task is to express the physical resource as a machine-readable commercial service.

Examples:

The service definition includes price, availability, measurement method, quality conditions, cancellation rules, and dispute evidence.

7.2 Pricing and Market Logic#

Machine commerce can support fixed, dynamic, auction-based, subscription, or outcome-based pricing. The application may consider:

• current supply and demand;
• energy or network cost;
• location and urgency;
• machine reputation;
• service-level requirements;
• congestion or availability;
• owner-defined minimum and maximum prices.

TLAY does not need to control the pricing model. It provides a standard way for the machine to receive, evaluate, accept, and prove the offer.

7.3 Payment Policy#

The solution maps commercial rules into machine-executable policy:

• allowed payment assets and networks;
• authorization limits;
• prepaid, postpaid, streaming, or escrow mode;
• settlement frequency;
• fallback behavior when connectivity is unavailable;
• refund and dispute conditions;
• operator and platform revenue shares.

BoAT MER enforces the machine-local portion. Cloud or contract logic can enforce fleet-wide and settlement-level policy.

7.4 Control Adapter#

Commerce must connect to the actual device state. A control adapter maps commercial events to machine actions:

• valid authorization starts charging;
• expired payment pauses delivery;
• completed task triggers a signed completion record;
• safety event stops the session regardless of payment status;
• settlement failure invokes retry or operator policy.

Safety controls always take priority over commercial controls. Payment must never override a machine’s emergency stop, physical safety interlock, or regulated operating constraints.

7.5 Proof Schema#

The proof schema defines which events matter and how they are linked. A typical schema may include:

• machine and owner identifiers;
• offer version and price;
• policy decision;
• session start and end;
• metered delivery intervals;
• payment authorizations;
• anomalies or interruptions;
• completion state;
• settlement reference.

Only required fields or their commitments need to be anchored. Sensitive business data can stay encrypted or offchain.

7.6 Settlement and Revenue Routing#

The solution can connect machine authorizations to a selected settlement provider. Depending on the deployment, value may be routed to:

• the machine owner;
• a fleet operator;
• a service provider;
• a marketplace;
• an infrastructure host;
• a protocol or insurance pool;
• tax or compliance accounts.

The economic split can be programmed without requiring the machine itself to maintain complex treasury logic.

7.7 Fleet Operations#

A production deployment also needs operational controls:

• device enrollment and revocation;
• firmware and policy versions;
• spending and earning dashboards;
• anomaly detection;
• proof and settlement monitoring;
• key rotation and incident response;
• reconciliation exports;
• service analytics.

This is where TLAY moves from a protocol toolkit to an enterprise-ready solution.

8. The TLAY Network#

The long-term value of TLAY is not limited to two software products. It is the network that emerges when many machines and services use compatible economic primitives.

8.1 Identity Network Effect#

As more machine identities become recognizable across applications, the cost of onboarding and authenticating a new counterparty falls. A charger can accept a vehicle identity issued under one ecosystem, subject to its own policy, without creating a completely separate account for every commercial relationship.

8.2 Proof Network Effect#

As more applications accept common proof receipts, a single verifiable machine history becomes useful to multiple parties:

• marketplaces can assess service history;
• insurers can price risk;
• lenders or lessors can evaluate utilization;
• auditors can verify operations;
• customers can validate delivery;
• regulators can inspect required records.

The proof becomes more valuable because more institutions know how to interpret it.

8.3 Payment Acceptance Effect#

Every additional supported payment rail or settlement partner increases the number of machines and services that can transact. Every additional machine using the same authorization standards makes integration more attractive to payment providers.

8.4 Developer Platform Effect#

Open-source BoAT MER and the HashAnchor SDK reduce the cost of experimentation. Developers can create new machine-commerce applications without rebuilding identity, signing, payment authorization, and proof infrastructure from scratch.

Applications then generate demand for:

• managed proof services;
• settlement and routing;
• enterprise policy and fleet tools;
• compliance and audit services;
• industry-specific commerce modules;
• network-level discovery and reputation.

This supports a commercial model in which the core software can be open and free while usage, coordination, and enterprise services generate revenue.

8.5 Data and Reputation Effect#

TLAY should not create an opaque centralized data monopoly. Instead, the network can enable permissioned, portable reputation derived from verifiable history.

A machine or operator may selectively prove statements such as:

• more than 10,000 successful service sessions;
• a failure rate below a threshold;
• calibration within a required period;
• no revoked identity at the time of service;
• payment completion above a defined percentage.

The underlying records can remain private while proofs or attestations make economic reputation portable.

8.6 Platform Governance#

As the network grows, governance should distinguish between open standards and operated services.

Open layers may include:

• device runtime and protocol specifications;
• proof formats and verification logic;
• identity and policy interfaces;
• reference integrations.

Commercial layers may include:

• managed anchoring and high-availability APIs;
• enterprise fleet and policy management;
• settlement orchestration;
• analytics, compliance, and support;
• industry-specific deployment packages.

This creates adoption at the edge and monetization at the coordination layer.

9. End-to-End Commerce Flow#

The following sequence illustrates a machine buying a metered physical service from another machine.

Step 1: Delegation#

The owner or fleet controller assigns the buyer machine a budget and policy. The machine receives permission to buy a defined service from approved counterparties within price and risk limits.

Step 2: Offer#

The seller machine publishes a signed offer containing service type, unit price, measurement method, payment options, session rules, and validity period.

Step 3: Evaluation#

The buyer verifies the seller’s identity and offer signature, then evaluates price, quality, operational need, and local policy.

Step 4: Session creation#

The buyer signs an acceptance. Both parties derive or agree on a session identifier that will link service events, payment authorizations, and proofs.

Step 5: Delivery and payment#

The seller delivers measurable service. The buyer signs value authorizations at agreed intervals. Either party may pause according to timeout, safety, delivery, or payment rules.

Step 6: Proof#

The application submits commitments for the offer, acceptance, delivery intervals, relevant machine state, and payment references. HashAnchor returns receipts after batching and anchoring.

Step 7: Settlement#

The seller or a settlement service submits the payment authorizations. Multiple small authorizations may be aggregated when the payment protocol permits it.

Step 8: Completion#

The final event links the delivered quantity, total authorized value, settlement result, and completion status. Both parties retain evidence suitable for reconciliation or dispute handling.

10. Conceptual Data Model#

The following objects provide a useful conceptual model. Exact schemas may vary by implementation.

10.1 Machine Identity#

{
  "machineId": "did:tlay:machine:example-001",
  "ownerId": "did:tlay:org:operator-01",
  "publicKeys": ["..."],
  "capabilities": ["energy.purchase", "event.sign"],
  "status": "active",
  "policyRef": "policy:buyer-fleet-v3"
}

10.2 Service Offer#

{
  "offerId": "offer:charger-42:2026-08-27T10:00Z",
  "sellerId": "did:tlay:machine:charger-42",
  "serviceType": "energy.delivery",
  "unit": "kWh",
  "unitPrice": {
    "amount": "0.31",
    "currency": "USDC"
  },
  "measurement": "meter:v2",
  "paymentMethods": ["eip3009"],
  "validUntil": "2026-08-27T10:05:00Z",
  "signature": "..."
}

10.3 Economic Policy#

{
  "policyId": "policy:buyer-fleet-v3",
  "maxUnitPrice": "0.35",
  "maxSessionValue": "25.00",
  "dailyLimit": "100.00",
  "allowedServices": ["energy.delivery"],
  "allowedCurrencies": ["USDC"],
  "approvedNetworks": ["eip155:8453"],
  "requireProof": true,
  "humanApprovalAbove": "50.00"
}

10.4 Machine Event#

{
  "eventId": "evt:01J...",
  "sessionId": "session:01J...",
  "machineId": "did:tlay:machine:charger-42",
  "eventType": "delivery.slice",
  "sequence": 17,
  "timestamp": "2026-08-27T10:02:14.428Z",
  "payloadHash": "sha256:...",
  "previousEventHash": "sha256:...",
  "paymentRef": "auth:0x...",
  "signature": "..."
}

10.5 Proof Receipt#

{
  "recordHash": "sha256:...",
  "batchId": "batch:01J...",
  "merkleRoot": "0x...",
  "merkleProof": ["0x...", "0x..."],
  "anchor": {
    "network": "eip155:8453",
    "transactionHash": "0x...",
    "blockNumber": 12345678
  },
  "verificationVersion": "1.0"
}

These objects are linked by identifiers and hashes. The goal is not to impose one universal schema on every industry, but to establish common trust-bearing primitives.

11. Trust, Security, and Privacy#

Machine commerce connects cyber systems to physical consequences. Security must therefore be designed across the entire lifecycle.

11.1 Device Identity and Key Protection#

Recommended controls include:

• unique keys per machine;
• hardware-backed key storage where available;
• secure boot and signed firmware;
• key rotation and revocation;
• separation of identity keys and payment keys when appropriate;
• recovery procedures controlled by the owner or fleet operator.

11.2 Policy Before Payment#

Every machine payment should be preceded by an explicit policy decision. The policy engine should evaluate:

• counterparty identity;
• requested service;
• amount and cumulative exposure;
• location and time;
• service state and measured delivery;
• anomaly and risk indicators;
• whether human escalation is required.

The signed payment authorization should include sufficient context or references to prevent replay and misapplication.

11.3 Replay and Ordering Protection#

Machine events and payment messages should use combinations of:

• unique nonces;
• sequence numbers;
• session identifiers;
• expiration timestamps;
• domain and chain identifiers;
• previous-event hashes;
• idempotency keys.

These controls prevent a valid message from being reused in the wrong session or accepted multiple times.

11.4 Privacy by Design#

Onchain commitments should reveal as little as possible. A production design may use:

• hashes instead of raw records;
• salted or keyed commitments for low-entropy data;
• encryption of offchain event payloads;
• tenant-separated access control;
• selective disclosure;
• zero-knowledge proofs for qualified claims where justified;
• retention limits for operational data.

Public verification and data publication are not the same thing. TLAY’s architecture should make integrity public when useful while keeping sensitive content private.

11.5 Physical Oracle Risk#

The hardest problem is often not blockchain security but the truthfulness of the physical measurement. A secure architecture may combine:

• calibrated sensors;
• redundant measurement;
• signed firmware and attestation;
• independent counterparty readings;
• anomaly detection;
• periodic inspection;
• economic penalties or insurance;
• cryptographically linked audit trails.

HashAnchor preserves evidence. Deployment design determines how credible the evidence source is.

11.6 Compliance Boundary#

TLAY’s infrastructure can support regulated applications without presenting itself as a regulated bank. Responsibility depends on the deployment:

• custody may be handled by an owner, wallet provider, or regulated custodian;
• fiat conversion may be handled by licensed providers;
• identity verification may be performed at owner or organization level;
• transaction monitoring may be handled by the application or payment partner;
• industry-specific compliance remains with the relevant operator.

Clear boundaries let TLAY remain infrastructure while enabling compliant solutions.

12. Integration Paths#

12.1 Device-First Integration#

Use this path when the machine hardware and firmware can be modified.

1. Port or configure the BoAT MER platform abstraction layer.
2. Provision a device identity and keys.
3. Select buyer, seller, or full build profile.
4. Add the required communication and payment adapter.
5. Define local authorization rules.
6. Sign operational events on the device.
7. Submit event hashes to HashAnchor through a gateway or application.

This provides the strongest device-origin guarantee.

12.2 Gateway Integration#

Use this path for legacy machines that cannot run BoAT MER directly.

A trusted edge gateway can:

• communicate with the existing machine protocol;
• maintain a machine-scoped identity;
• translate machine state into signed events;
• enforce commercial policy;
• initiate payment or proof workflows.

The trust boundary moves from the device to the gateway, which should be clearly represented in receipts and identity metadata.

12.3 Cloud/Application Integration#

Use this path to test a business model before embedded deployment.

The application can integrate HashAnchor, payment APIs, and simulated machine identities. Once commercial logic is validated, signing and policy enforcement can move progressively closer to the physical machine.

This staged model reduces initial integration cost while preserving a route to stronger machine-native trust.

12.4 HashAnchor-Only Integration#

Existing platforms can adopt HashAnchor without adopting the full TLAY stack. Common use cases include:

• tamper-evident IoT logs;
• supply-chain milestones;
• AI-generated industrial decisions;
• maintenance and calibration records;
• energy and carbon data;
• payment and service reconciliation.

HashAnchor becomes an entry point into the broader TLAY network.

12.5 BoAT MER-Only Integration#

Developers can use BoAT MER for machine identity, signing, or payment authorization while using their own proof infrastructure. Open interfaces reduce lock-in and make the runtime useful before the full TLAY network is adopted.

13. Reference Pattern: Streaming Energy Commerce#

Consider an autonomous delivery vehicle that needs energy from an independently operated charging robot.

Participants#

• Vehicle owner — funds the fleet and defines purchasing policy.
• Buyer machine — the autonomous vehicle running BoAT MER.
• Seller machine — the charger running BoAT MER or a trusted gateway.
• Commerce application — manages discovery, pricing, and fleet operations.
• Settlement provider — submits or settles signed value authorizations.
• HashAnchor — anchors the service and payment evidence.

Policy#

The vehicle is allowed to:

• buy electricity only from approved or sufficiently reputable providers;
• pay no more than a defined price per kWh;
• spend no more than a session limit;
• use an approved stablecoin and network;
• require a verifiable delivery receipt.

Transaction#

1. The charger publishes a signed price and availability offer.
2. The vehicle checks its energy need, route, offer, and policy.
3. Both machines establish a session and exchange identifiers.
4. The charger delivers a small energy slice.
5. The vehicle verifies the meter update and signs a corresponding payment authorization.
6. Delivery and authorization repeat until the target state is reached.
7. The settlement actor submits or aggregates the authorizations.
8. HashAnchor anchors the offer, session, meter events, and settlement link.
9. Both operators receive a portable receipt.

Result#

The vehicle received energy without a human checkout flow. The charger received payment with bounded delivery risk. Neither operator had to trust only the other party’s private database. The business process was digitally represented, economically executable, and independently verifiable.

This pattern can be adapted to bandwidth, compute, physical access, robot labor, mobility, and machine-generated data.

14. Product Status#

TLAY is an evolving infrastructure stack. Documentation should distinguish current capabilities from the broader network vision.

BoAT MER#

• Open source under Apache 2.0.
• C runtime for constrained and embedded environments.
• ESP32 is the primary current hardware family, with portability abstractions for additional targets.
• Core identity, cryptography, event signing, BLE commerce, EVM/EIP-3009, x402, and micro-USDC workflows are available at varying maturity levels.
• Lightning/LNbits support is implemented but less exercised than the primary EVM path.
• The runtime does not operate settlement infrastructure itself.

Repository: github.com/TLAY-IO/boat-mer

HashAnchor#

• TypeScript client SDK is open source under Apache 2.0.
• Hash and supported-content submission, Merkle batching, status queries, portable receipts, and offline inclusion verification are current capabilities.
• x402 V2 settlement on EVM using USDC is a current shipped path.
• Some additional settlement capabilities are server-side, private, or roadmap features.
• The current multi-tenant server is a managed service rather than a self-hostable open-source package.
• The SDK is currently installed from the project source/versioned repository path rather than assumed to be available from a public npm release.

Repository: github.com/TLAY-IO/hashanchor

Strategic Direction#

The product direction is to make both products easy to adopt as open infrastructure and use them as entry points into a larger managed network. Monetization can concentrate on:

• managed HashAnchor usage;
• high-volume anchoring and verification;
• payment and settlement orchestration;
• enterprise identity and policy management;
• fleet operations and analytics;
• compliance and audit tooling;
• industry-specific Machine Commerce Enabler deployments;
• service-level agreements, support, and private infrastructure.

This aligns adoption with network growth: the easier it is to give a machine an account or create a proof, the more economic activity can enter the TLAY ecosystem.

15. Frequently Asked Questions#

Is TLAY a bank for robots?#

“A bank for robots” is a useful analogy because it helps a general audience understand that machines will need accounts, payments, and financial services. It should not be the precise category definition. TLAY is broader and more infrastructural: it provides identity, authority, transaction, and proof capabilities and does not necessarily custody funds or perform regulated banking activities.

The recommended framing is:

TLAY is economic infrastructure for autonomous machines—the account, payment, and proof layer for machine commerce.

Why use “economic infrastructure” instead of “financial infrastructure”?#

Financial infrastructure emphasizes money movement. Machine commerce also includes service definitions, operational permissions, physical delivery, data integrity, and cross-party coordination. “Economic infrastructure” describes the full system and gives TLAY room to support many payment and business models.

Does every machine need a blockchain wallet?#

Not necessarily. A machine needs a secure identity and a way to express economic authority. Depending on the architecture, it may sign blockchain-compatible authorizations, use an account managed by a fleet controller, interact through a payment channel, or delegate settlement to a gateway.

Must all machine data go onchain?#

No. Raw data should usually remain offchain. Critical events, state commitments, payment references, and business-process proofs can be anchored selectively. The principle is onchain-verifiable, not onchain-everything.

Why can’t an ordinary cloud database handle this?#

A cloud database works inside one trust domain. Machine commerce increasingly crosses companies, fleets, platforms, and jurisdictions. Portable cryptographic receipts reduce dependence on one platform’s database and make reconciliation and auditing easier.

What happens if the machine is offline?#

The deployment can define offline limits, local counters, delayed submission, channel-based payment, or gateway synchronization. Offline autonomy should be bounded by value, time, counterparty, and replay-protection policies.

Can TLAY support fiat payments?#

Yes, through integrated providers or account systems, provided the payment method can receive a valid machine authorization and return a settlement reference. TLAY’s core model is payment-rail agnostic, although current implementations focus on specific digital payment paths.

Who is legally responsible for a machine’s purchase?#

That depends on the legal and commercial arrangement. Typically, a person, company, fleet operator, or protocol owner delegates authority to the machine and remains accountable within the contract. TLAY supplies technical controls and evidence; it does not define legal personhood for machines.

Is the machine’s proof automatically true?#

The proof establishes integrity, origin, and ordering under the selected trust model. It does not guarantee that a compromised device or faulty sensor accurately represented the physical world. Secure hardware, calibration, redundancy, and operational governance remain essential.

Can developers use BoAT MER and HashAnchor separately?#

Yes. Each product creates standalone value. Their combined use creates a stronger end-to-end chain between machine identity, economic authorization, service delivery, and verifiable evidence.

What creates TLAY’s network effect?#

Every additional machine identity, accepted proof format, settlement integration, service provider, and developer application increases the number of possible economic relationships. Open products accelerate the edges of the network; managed coordination services capture value at scale.

16. Getting Started#

For embedded developers#

1. Review the BoAT MER repository.
2. Select a supported or portable hardware target.
3. Choose buyer, seller, or full capability profile.
4. Run identity and signing examples.
5. Test an EIP-3009, x402, or BLE commerce workflow appropriate to the use case.
6. Connect signed machine events to HashAnchor.

For application developers#

1. Define the physical service and its commercial unit.
2. Model the offer, acceptance, delivery, and completion events.
3. Define economic permissions and risk limits.
4. Integrate the HashAnchor client and API.
5. Verify portable receipts independently.
6. Add payment routing and link settlement references to the event chain.

For enterprises#

Start with one bounded workflow where cross-party trust or reconciliation is expensive. Good candidates have:

• a measurable physical service;
• repeat transactions;
• more than one organization or system of record;
• a need for automated payment or proof;
• clear economic value from reducing manual coordination.

The first deployment should prove one complete commerce loop before expanding across a fleet or marketplace.

Conclusion#

AI is moving from bits into atoms. The physical world is becoming instrumented, autonomous, and programmable—but it is not yet economically interoperable.

Robots and machines need more than intelligence. They need identity, bounded authority, payment capabilities, trustworthy evidence, and common rules for coordination. The critical information flow, value flow, and business flow must be connected through a verifiable digital layer.

BoAT MER gives machines the ability to act economically. HashAnchor gives their actions durable and portable proof. The Machine Commerce Enabler turns those primitives into deployable business systems. The TLAY Network connects them into an open economic environment for machines.

TLAY is building the economic infrastructure that makes the physical machine economy digital, verifiable, and programmable.