On September 17 at Arc Mainnet Launch Drone Show above the San Francisco Ferry Building, a small drone descended onto a charging station and began drawing power.

The station’s display woke. A live interface showed energy moving in one direction and payment authorisations moving in the other. There was no card reader, QR code, wallet pop-up or person approving each step. The two machines had established their own commercial session.

The visual was simple: a drone needed energy, and an energy device could provide it. The harder question was whether the two could measure the exchange, agree on a price and move value without turning every few seconds of usage into a separate blockchain transaction.

That is the problem this demonstration was built to explore.

What happened after the drone landed

The drone acted as the buyer. The eCandle acted as the seller.

After the devices established a Bluetooth Low Energy connection, the eCandle began supplying power and requesting payment based on measured usage. Every five seconds, the drone produced a signed EIP-3009 USDC payment authorisation using a secp256k1 key held on the device.

The key did not need to leave the hardware, and there was no human signing a wallet transaction every five seconds.

The eCandle collected the signed authorisations and grouped them into batches which were forwarded through TLAY HashAnchor for settlement using Circle Gateway.

One distinction is essential: each five-second usage slice was a signed payment authorisation, not an individual Arc transaction.

When the seller chose to move its cleared value on-chain, the eCandle signed a second, separate EIP-712 intent. That action produced verifiable USDC on Arc Mainnet and a public transaction hash that could be viewed on Arc Explorer.

The complete flow had four layers:

  1. measure a physical resource;
  2. authorise payment at the edge;
  3. settle frequent events efficiently in batches;
  4. move cleared value on-chain when doing so creates value.

Why not put every slice on-chain?

Physical machines can generate enormous numbers of small events: seconds of charging, bytes of sensor data, milliseconds of compute or fractions of a transport journey.

Making every event a separate blockchain transaction would introduce unnecessary cost, latency and operational complexity. Ignoring verifiability would create a different problem: devices and counterparties would have no reliable way to prove what they authorised. The demonstration separates those concerns.

The drone creates a cryptographically signed authorisation close to the physical event. The eCandle can accumulate those authorisations and settle them efficiently. On-chain liquidity remains available when it is useful, rather than being forced into every sensor tick.

This is also why we use the phrase “machine payment” more often than “on-chain nanopayment.” The five-second events are high-frequency, usage-based payment authorisations. The final move to Arc is a separate and verifiable on-chain action.

The private key stays with the machine

For a machine to participate economically, it needs a way to prove that an instruction really came from that device.

In the demonstration, the drone signs its authorisations using a key held on-device. The private key does not need to be copied into a browser wallet or exposed to a cloud application for each payment request.

That design matters beyond drones. A field sensor, robot, charger or edge-compute node may operate unattended and connect intermittently. Its economic identity must be able to survive outside a conventional user interface.

Embedded identity does not solve every security problem. Provisioning, recovery, firmware integrity and physical tamper resistance still need careful design. But keeping the signing action close to the device is an important starting point.

More than a drone show

The drone and eCandle make the architecture visible, but they are only one buyer and one seller.

The same pattern can apply whenever a machine needs to buy a measurable resource from another machine:

Each scenario needs different metering, pricing and commercial rules. The underlying primitives remain familiar: device identity, resource discovery, signed authorisation, efficient settlement and optional on-chain liquidity.

What builders can inspect

Following the event, TLAY is publishing the system in layers.

The Technical Deep Dive explains the BLE characteristics, EIP-3009 authorisations, batch structure, settlement path and separate EIP-712 mint intent.

The Builder Quickstart reproduces the buyer and seller flow with two ESP32 boards and a local demonstration interface.

The proof package contains publishable Circle UUID, the final Arc transaction hash, an architecture diagram and the corresponding source-code links.

The goal is not only to show that one drone can pay one eCandle. It is to make the architecture inspectable enough for someone else to build the next machine-payment scenario.