TLAY Product Architecture

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:

LayerResponsibility
Owner or enterpriseDefines goals, liability, funding, and high-level policy
Fleet or application controllerAllocates budgets and operational permissions
Machine runtimeExecutes only permitted actions and signs local authorizations
Payment or settlement networkTransfers value according to valid instructions
Proof layerPreserves independently verifiable evidence of relevant events

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.

FlowExamplesTrust question
Information flowTelemetry, quotes, commands, state changesDid the claimed event occur, and who reported it?
Value flowAuthorization, micropayment, settlement, revenue splitWas value transferred under valid authority?
Business flowOffer, acceptance, delivery, completion, disputeWas the commercial obligation fulfilled?

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.

Three Flows, One Machine Economy Information flow, value flow, and business flow converging into one verifiable machine-commerce record. TLAY TRUST MODEL Three Flows, One Machine Economy Information, value, and business flows converge into a shared verifiable record. TLAY INFORMATION FLOWWhat happened? Telemetry Quotes Commands State changes VALUE FLOWWhat value moved? Authorization Micropayment Routing Settlement BUSINESS FLOWWas the obligation fulfilled? Offer Acceptance Delivery Completion VERIFIABLEMachineCommerce Recordidentity + authority + proofTRUST1Audit2Settle3Dispute4ReconcileDESIGN PRINCIPLEPut the minimum trust-bearing state onchain — keep sensitive, high-volume data offchain. ECONOMIC INFRASTRUCTURE FOR AUTONOMOUS MACHINES
Figure 3. Machine commerce becomes trustworthy when information, value, and business state are linked through a shared verifiable record.

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.