TLAY Product Architecture
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#
- The charger publishes a signed price and availability offer.
- The vehicle checks its energy need, route, offer, and policy.
- Both machines establish a session and exchange identifiers.
- The charger delivers a small energy slice.
- The vehicle verifies the meter update and signs a corresponding payment authorization.
- Delivery and authorization repeat until the target state is reached.
- The settlement actor submits or aggregates the authorizations.
- HashAnchor anchors the offer, session, meter events, and settlement link.
- 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.