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.