TLAY · Machine Commerce Enabler

When Machines Start Doing Business

Anything a connected device can do, it can sell straight to anyone. A contract holds the money, the device signs for its own work, and settlement follows what was really delivered. This essay covers the why, the what and the how.

Cyan: data, evidence and signatures Amber: money
Chapter 1

Machines already do the work. They still can't get paid.

There are more connected machines on Earth than people. Parcel lockers, EV chargers, lab instruments, robot arms in warehouses, sensors on rooftops: every day they do work that has value. Yet that work almost never sells directly to a stranger. A charger can't take its own orders. A test instrument can't sell its idle hour to the lab next door.

The machines are ready. Trust is what's missing. Today, to sell what a machine can do, a middleman has to stand between buyer and seller. It opens accounts for buyers. It collects and holds money for sellers. When a dispute comes up, it decides how much work the device really did. All the trust rests on that one middleman, so only big platforms can afford the business, and the long tail of machines sits idle.

Every machine deal has to answer three questions. Who is selling? How much was delivered? And where does the money go?

IdentityWho is selling?The device itself, with an identity no account can claim on its behalf.
EvidenceHow much was delivered?The device measures it and signs it. The seller's word alone counts for nothing.
SettlementWhere does the money go?The contract splits it by what was delivered. No party can take money that isn't theirs.

If machines and code can prove all three directly, nobody has to trust the middleman any more. It can still provide services, relay transactions and send notifications. It can't touch the money, and it can't change the books.

BEFORE WITH TLAY Buyer MiddlemanHolds the moneyJudges delivery Seller Machine Pay Split Seller's wordon delivery All trust sits in one place Buyer walletSigns only Escrow contractSettles by the rules Seller MachineSigns its own work PlatformRelays · no funds Unused part refunded Signed meter sets the charge Permit Amber money never passes through a company's account
One deal, two ways. On the left, the money and the call on "how much was delivered" both go through a middleman platform. On the right, the buyer only signs in a wallet and the money goes into an escrow contract. The machine's signed metering sets the amount paid, and whatever was not delivered goes back automatically. The platform only relays messages and issues run permits.

The next buyer may not be human

A new kind of buyer is arriving: software. A scheduler needs to book tests on ten devices overnight. An AI agent wants an hour of printer time for its user. They need purchases a program can complete on its own, with a budget cap, clear terms and automatic refunds when something goes wrong. TLAY lets an owner sign a funds grant for software that sets how much it may spend, which services it may buy and which payees it may pay. Inside those limits the software places its own orders, and each one still settles by the delivery the device signed for. Devices can trade with each other the same way: a device can use its own payment key to buy a service from another device.

Chapter 2

Infrastructure that lets machines do business on their own

TLAY Machine Commerce Enabler has four layers that run from the chip all the way to the chain: a runtime inside the device, a platform for connection and settlement, contracts that hold the money, and apps and SDKs for people and software. Click any block in the diagram to see what it does.

PEOPLE & SOFTWARE TLAY PLATFORM ON-CHAIN DEVICE Seller · Operator appDevices · services · ordersDisputes · revenue Buyer · Store & walletSigns only · pays no fees Software · SDK / APITypeScript · Python · Go · Webhook Platform APIOpenAPI · accounts & permissions Settlement · VerifierRelays signatures · proposes delivery Device gatewayPermits · trusted time · presence Notifications & email Evidence batches · on-chain Firmware rollout · security Escrow contractsMetered · lease · subscription · USDC Device registryDevice identity · controller Evidence anchorMerkle root · HashAnchor Your host MCURuns actions · meters usage TLAY runtimeESP32 module · keys · signing WSS · TLS · signed records Action Meter Merkle root Relays signed payments Settlement · refund → payee & buyer wallets
Click any block

Every block is a real component: the seller and buyer apps, the SDKs for programs, the platform's back-end services, the on-chain contracts, and the code that runs inside the device.

Four layers, two flows. Cyan is data and evidence: the device sends signed records to the gateway over an encrypted connection, and the platform batches them and anchors the root hash on-chain. Amber is money: the platform only relays payments the buyer has signed, and settlements and refunds go straight from the contract to the payees' and the buyer's wallets. The amber route on the left never touches a platform account.

Three ways to sell that cover how most machines work

metered_service_escrow

Pay per use

The buyer first deposits the most this order could cost. The device runs, meters the work and signs the reading. Only the delivered part is charged and the rest goes back. The buyer can confirm or dispute each delivery. Best for work whose duration, volume or count can be measured precisely.

access_lease

Time-limited access

Pay once and use the device a set number of times within a period. The seller is paid when access starts, and access ends on its own at expiry. Best for venues, workstations and equipment rented by the hour.

access_subscription

Subscription

Prepay several periods, each with a set number of uses. The seller receives one period's payment as each period starts. On cancellation, periods that have not started are refunded. Best for steady, long-term use.

Signatures are the common language of the system

In TLAY, almost every key action is a signature, and each kind of signature has its own key that does only that job. Whoever signs something answers for it.

WhoWhich keyWhat it signs
DeviceEvidence key (Ed25519, generated and kept on the device)Every metering, result and event record; the one-time challenge at claiming
Device (as buyer)Payment key (secp256k1, separate from the evidence key)Its own payment authorizations, capped by the funds grant its owner signed
BuyerWalletSign-in messages, payment authorizations (EIP-3009), delivery confirmations and disputes (EIP-712)
SellerPayee address keyThe terms of every order (when using its own payee address)
Platform gatewayIssuer keyThe permit for every run; trusted time for devices
Platform verifierVerifier keyOrder start; the delivery it proposes from device metering
ArbiterArbiter addressDispute rulings (an on-chain transaction it sends itself)
Firmware publisherPublisher key (Ed25519, kept offline)Every firmware version; a device installs only firmware signed by a publisher it trusts
Chapter 3

Follow one order through its whole life

Here is a real test order from start to finish. The buyer ordered 1,000 milliseconds of robot-arm time at 0.00001 USDC per millisecond, and the device actually ran for 618 milliseconds. Step through it. The sequence diagram on the left lights up what happens at each step, and the ledger on the right shows where the money is at that moment.

Buyer wallet Platform Device Escrow contract Seller payee 1Order · 1,000 ms 2Signs payment authRelay · 0.01 USDC into escrow 3Verifier signs: start 4Run permit 5Signed: 618 ms 6Evidence Merkle root on-chain 7Propose 618 ms · dispute window opens 8Signs confirmationRelay confirmation 90.00618Refund 0.00382 → buyer wallet
Step 1 of 9

Where the money is now · USDC
Buyer wallet
Escrow contract
Seller payee
This example leaves out the platform fee; the calculator below adds it. The platform's own account holds 0 from start to finish.
One order in nine steps. Cyan arrows are signatures and data. Amber arrows are money. Watch step 4: an unpaid order never gets a run permit, so no command reaches the device. In step 5 the device signs its own metering, and the delivery in step 7 comes straight from it.

Run the numbers yourself

The settlement rules live in the contract, and anyone can check the math. The charge is the unit price times the amount actually delivered. The platform fee comes out of the seller's revenue. The rest is split among the payees by the shares in the terms. Everything not delivered goes back to the buyer. Drag the sliders below and see.

The unit price is fixed at 0.00001 USDC per millisecond. The fee and the share are example values; the real ones come from the deployment and the service terms.

Where the buyer's USDC deposit ends up
Service provider (seller)
Second payee
Platform fee
Refunded to buyer wallet

Computed in whole base units, exactly as the contract does it: the fee rounds down, and any remainder of the split goes to the service provider.

The settlement formula is the contract code. Charge = unit price × delivered; fee = charge × fee rate; share = (charge − fee) × share rate; refund = deposit − charge.

When the buyer disputes the delivery

Signed device metering is evidence, yet the real world has surprises. A robot arm jams, the meter reads normally, and the job is still unfinished. So every metered order gets a dispute window once delivery is proposed. The buyer can write a reason, sign it and raise a dispute. The money stays in the contract, and the arbiter named in advance in the service terms decides how much was really delivered. If the arbiter does not rule in time, the buyer gets a full refund.

DeliveredDispute window open DisputedMoney stays in the contract Settle as proposedCharge 618 · refund 382 Settle as ruledThe arbiter's figure stands Full refundCharge 0 · refund all Buyer signs to confirm No one acts; the window closes Buyer signs a written reason Arbiter rules No ruling by deadline
A delivery has three possible endings, and the platform decides none of them. Solid lines are signed actions. Dashed lines happen on their own when time runs out. During a dispute the buyer, the seller and the arbiter can all post messages on the order. The platform only checks that the buyer's reason is the exact text the buyer signed.

More details that make machines trustworthy

Claiming is identity. The first time a device is claimed, it signs a one-time challenge with a key generated inside the device. From then on only that organization can run it and sell it. Anyone else who gets hold of the device still can't pass as it.

Encryption reaches the chip. The device connects to the gateway over a TLS-encrypted WebSocket. In the "module + host" design, the UART or SPI link between the module and your MCU is also encrypted frame by frame with the Noise protocol.

Anyone can verify the evidence. The platform batches device-signed records into a Merkle tree and anchors only the root hash on-chain. Every record comes with a full inclusion proof: the record, the Merkle path, the on-chain root and the transaction.

Firmware updates leave nothing to luck. A device installs only firmware signed by the publisher key. New versions roll out in batches and pause automatically when the failure rate passes a threshold. If new firmware fails to boot, the device rolls back to the previous version on its own.

Devices that fail security can't trade. Each product can set a security policy covering secure boot, flash encryption and how keys are stored. Devices that fall short get flagged, and the policy can block them from buying and selling outright.

Payee keys stay with the seller. When a seller uses its own payee address, no order takes effect until the seller's key signs its terms. The seller can sign with a wallet in the app, or run a signing tool next to the key that signs automatically under rules the seller sets.

When a machine can issue an invoice no one can forge, it stops being just an asset. It becomes a business.

That is what TLAY sets out to do. Any connected device, owned by a large company or by one person, should be able to sell what it can do directly to people, to software and to other machines, with no one holding its money and no one vouching for its work.

Where it stands today

Working end to endPay per use, time-limited access, subscriptions and dispute rulings all run end to end, from the device's signature to settlement. The seller's operator app and the buyer's shop work today: try them in the live demo. The SDKs cover TypeScript, Python and Go.
In progressHardware verification on ESP32 dev boards, item by item. The production security configuration (secure boot, flash encryption) already builds and is now being verified on the boards.
NextFinish verification on production hardware, then open to the first device makers and fleet operators.