eCandle × Circle Nanopayments: Machine-to-Machine Nanopayments on Circle Gateway, Arc and TLAY BoAT

1. What this demo is trying to prove

We wanted to use a specific, independently verifiable, working engineering artifact to answer one question:

The answer is: yes, and it’s a live production deployment that has been running for over a month — not a slide-deck architecture diagram.

1.1 The four building blocks we used

This demo composes four public, production-grade, independently verifiable components into a complete end-to-end loop:

Every one of these four blocks comes from an open system already running in production. We did not ask Circle to change a protocol, did not ask Arc to add a whitelist, and did not ask BoAT to extend a field — we used the public SDKs and public APIs as shipped. This is the core value of the demo: it is not a “if we add feature X someday, this might work” feasibility study; it is a “you can reproduce this today” engineering reference implementation.

1.2 Why this combination cleanly covers all of M2M nanopayments

M2M nanopayments, as an engineering problem, must simultaneously satisfy three requirements that look mutually contradictory:

1. Payments must be small (sub-cent, e.g. $0.00004 per 10-second energy slice) — on-chain cost per payment must be far below the payment value itself
2. Signing must happen on the device — otherwise it isn’t “machine autonomous”; it’s “cloud-signed on behalf of”
3. Outcomes must be independently auditable — not just a row in a cloud database

Circle Nanopayments solves (1): batched settlement amortizes a single on-chain transaction cost across many micropayments. TLAY BoAT solves (2): the private key is on the chip; the signing happens on the chip; the cloud is only transport. Arc Testnet + on-chain verifier contracts solve (3): BurnIntent → gatewayMint() converts off-chain credit into on-chain USDC balance change, every settlement leaving its own tx hash.

If any one of those three problems is unsolved, M2M nanopayments cannot be engineered into a real product. With all three solved — and with all the tools already public, already running, and composable as shipped — this is the central thesis of the demo.

1.3 As a side effect, it also proves: M2M payments do not need cloud-custody keys

M2M stablecoin payments aren’t a new idea. The marketing diagram says “edge devices pay autonomously”; the actual implementation is a cloud holding a signing service that signs on behalf of devices by ID. In the DePIN context this architecture has three fundamental problems:

1. Trust model collapse — the custodian can censor, freeze, or repurpose
2. Vendor lock-in — switching cloud providers means rebuilding the entire key management story
3. Distorted unit economics — custody cost + HSM cost push the marginal cost per payment well above what device-native signing would cost

Because BoAT makes on-chip signing a standard engineering operation on the device, this demo proves as a side effect: self-custody is not a trade-off, it is the default. Cloud key custody has no remaining structural reason to exist in 2026’s DePIN micropayment scenarios.

2. Overall Architecture

We abstract the demo into a six-layer model, where each layer has a clear protocol contract, a single source-of-truth, and well-defined cross-layer coupling points:

───────────────────────────────────────────────────────────────────────────── Layer 6   Settlement Layer        Arc Testnet (chainId 5042002)                                     USDC = native gas token, domain id 26                                     GatewayWallet 0x0077777d... (source)                                     GatewayMinter 0x0022222A... (destination)───────────────────────────────────────────────────────────────────────────── Layer 5   Payment Rails           Circle Gateway API                                     POST /v1/x402/settle    (off-chain credit)                                     POST /v1/transfer       (BurnIntent → attestation)                                   TLAY HashAnchor (x402 facilitator wrapper)───────────────────────────────────────────────────────────────────────────── Layer 4   Cloud Orchestration     Arkreen Cloud Platform                                     Next.js + 3 PM2 workers                                     settle-worker | burn-intent-worker | arc-indexer───────────────────────────────────────────────────────────────────────────── Layer 3   Edge↔Cloud Transport    MQTT topics                                     ecandle/<MAC>/settle             (proof batches)                                     ecandle/<MAC>/telemetry          (device state)                                     ecandle/<MAC>/slice_event        (per-slice events)                                     ecandle/<MAC>/cmd/sign_burn_intent  (on-chain step request)                                     ecandle/<MAC>/burn_intent_sig    (on-chain step reply)───────────────────────────────────────────────────────────────────────────── Layer 2   On-device Cryptography  TLAY BoAT MWR SDK                                     secp256k1 / keccak256 / RLP / ABI / EIP-712                                     on-chip private key (NVS-persisted), zero cloud dependency───────────────────────────────────────────────────────────────────────────── Layer 1   Physical Energy Edge    Bitaxe (buyer)  ─ BLE central  ─ EIP-3009 signer                                   eCandle (seller) ─ BLE peripheral ─ Arkreen open energy device─────────────────────────────────────────────────────────────────────────────

Each layer is replaceable: swap out the buyer device at Layer 1 and Layer 4 doesn’t need to change; swap out the settlement chain at Layer 6 and the BLE protocol at Layer 1 is unaffected. This layering isn’t aesthetic — it’s the natural protocol contract boundary that emerged from the engineering process.

3. Key Protocols and Standards

3.1 x402 + a “x402-like” Protocol over BLE

x402 is the revival of the HTTP 402 Payment Required status code, driven primarily by Coinbase. The core idea: when an HTTP server has a paid resource, it returns 402 along with a paymentRequirements object; the client signs an authorization, packages it as paymentPayload, and retries with it as a request header. The shape:

// paymentRequirements (server → client, "here's what you need to pay"){  "scheme": "exact",  "network": "eip155:5042002",  "asset": "0x3600000000000000000000000000000000000000",   // USDC on Arc  "amount": "50",  "payTo": "0xc3e56b11204f0a095aabd7109c06ddc4274d05d0",  "maxTimeoutSeconds": 86400,  "extra": { "name": "GatewayWalletBatched", "version": "1", ... }}

// paymentPayload (client → server, "here's my signed authorization"){  "x402Version": 2,  "resource": { "url": "...", "description": "..." },  "accepted": <copy of paymentRequirements>,  "payload": {    "signature": "0x...",    "authorization": { "from", "to", "value", "validAfter", "validBefore", "nonce" }  }}

x402 appears twice in our demo, with completely different transports:

First: an “x402-like” protocol over BLE. The eCandle (acting as resource server) broadcasts paymentRequirements through a BLE GATT characteristic. The Bitaxe (acting as client) reads it, uses its on-chip BoAT private key to sign an EIP-3009 authorization, and pushes the paymentPayload back via BLE notify. The eCandle verifies the signature on-chip and unlocks service (closes the relay).

The protocol semantics are identical to HTTP x402. Only the transport changes from HTTP to BLE GATT. We can’t strictly call it “x402” — the HTTP-specific parts (headers, status codes) don’t apply. But once you strip the transport layer, the core protocol shape is reusable verbatim.

Second: standard HTTP x402. On the cloud side, our settle-worker packages each Bitaxe-signed proof into a standard HTTP x402 payload and posts it to TLAY HashAnchor's /v1/x402/settle endpoint. HashAnchor is an x402 facilitator that wraps Circle Gateway's SDK underneath. This is exactly the x402 facilitator pattern Circle officially recommends.

3.2 EIP-3009 — Gasless USDC Authorization

transferWithAuthorization(from, to, value, validAfter, validBefore, nonce, sig) is a standard method on USDC. The key property: the authorized party doesn't need to take any on-chain action for the funds to move. Any third party (a facilitator, in our case) can take the sig on-chain and execute it.

This is what Bitaxe’s BoAT signs — one fresh authorization per 10-second slice, with a re-randomized nonce each time. It’s the basic primitive of Circle’s Nanopayments protocol.

Note: USDC on Arc Testnet does not directly support EIP-3009 (the contract doesn’t expose the entry point). That’s exactly why we have to go through Circle Gateway as an indirect execution layer (§3.4).

3.3 EIP-712 Typed Data — BurnIntent Signing

Circle Gateway defines a custom EIP-712 schema for the “I want to materialize my off-chain Gateway credit on-chain” operation. The structure:

BurnIntent {  uint256 maxBlockHeight,  uint256 maxFee,  TransferSpec spec}

TransferSpec {  uint32 version, sourceDomain, destinationDomain,  bytes32 sourceContract, destinationContract,  bytes32 sourceToken, destinationToken,  bytes32 sourceDepositor, destinationRecipient,  bytes32 sourceSigner, destinationCaller,  uint256 value,  bytes32 salt,  bytes hookData}

The EIP-712 domain is unusual — {name: "GatewayWallet", version: "1"}, intentionally without chainId or verifyingContract. Circle designed it this way so the same BurnIntent works across multi-chain Gateway deployments — cross-chain consistency takes precedence over standard EIP-712 hygiene.

In our demo, the eCandle’s BoAT signs this BurnIntent on-chip. This is the most critical step in the entire flow: the eCandle has the capability to materialize its own off-chain Gateway credit to on-chain USDC, with no cloud-side wallet signing on its behalf.

3.4 Circle Gateway — Off-chain Batched Settlement + On-demand On-chain Mint

Gateway’s core architecture:

• settle() endpoint: a facilitator (HashAnchor in our case) submits an EIP-3009 authorization → Circle credits the USDC to the payTo address in its internal ledger. Fully off-chain, instant, batched
• transfer() endpoint: a sourceDepositor submits an EIP-712-signed BurnIntent → Circle returns {attestation, signature} → any caller (our cloud operator wallet) calls GatewayMinter.gatewayMint(attestation, sig) → real on-chain USDC transfer

Without Gateway: every 10-second nanopayment would need its own on-chain transaction. Gas alone would destroy the unit economics. Gateway makes the three-stage pattern — “high-frequency signing → off-chain batching → on-demand materialization” — viable.

4. The Three Entities, In Detail

4.1 Bitaxe — The Buyer / Energy Consumer

Role: open-source Bitcoin miner that opportunistically buys electricity along the hash-rate profitability curve — it only buys when the price is below threshold.

Hardware: ESP32-S3 main controller (dual-core + WiFi + BLE), ASIC mining chip for actual hashpower, OLED for status display.

Protocol responsibilities:

1. BLE central — actively scan for nearby eCandle devices
2. Read eCandle’s advertised paymentRequirements, decide if the price is in range (auto-mode logic)
3. Sign EIP-3009 authorization on-chip via TLAY BoAT — one fresh signature per slice
4. Push paymentPayload back to eCandle via BLE notify
5. Sync status to OLED: current price, slice count in session, cumulative paid

Measured performance: BoAT signing EIP-3009 takes ~120ms — well below the slice cycle period.

4.2 eCandle — Seller + Arkreen’s Open Energy Device Platform

eCandle plays two roles in this demo. First: the seller in this specific demo. Second — and more important — eCandle is Arkreen’s reference architecture for an open energy device platform, and the eCandle-003 hardware in this demo is just one instance of that platform.

4.2a As the demo’s seller

Hardware: ESP32-C3 main controller (single-core RISC-V + WiFi + BLE), relay, AC inverter, AC output. Optionally extensible with solar panel, or other DC inputs.

Protocol responsibilities:

1. BLE peripheral — advertise paymentRequirements (current price, payTo address, asset)
2. Receive EIP-3009 paymentPayload pushed by Bitaxe
3. Verify the signature on-chip via BoAT — ecrecover the from address, check sig validity
4. On success → state machine moves to streaming → relay closes, AC output begins
5. Each received proof accumulates into local s_proofs[]
6. Once a session is complete (max_slices=2), publish a batch of 2 proofs to MQTT topic ecandle/<MAC>/settle
7. Later, wait for the cloud to push cmd/sign_burn_intent — use BoAT to sign an EIP-712 BurnIntent so the off-chain Gateway credit can materialize on-chain

Note that eCandle’s BoAT private key carries two independent signing responsibilities: verifying the buyer’s EIP-3009, and signing its own EIP-712 withdrawal. Same secp256k1 key in the same NVS namespace.

4.2b As the “Raspberry Pi for Energy” open platform

Core positioning: eCandle is not any specific energy device — it’s the generic substrate for energy devices. Think Raspberry Pi for embedded computing, Android for smartphones. Hardware diversity, unified application/protocol layer, third-party ecosystem.

Unified abstraction across three energy behaviors:

On-chain scheduling and operation:

• Pay-per-use (current demo): buyer pays slice-by-slice based on actual energy consumed
• Prepaid subscription / deposit model: long-term contracts lock multi-slice capacity on-chain
• Demand response (grid signal): grid congestion → device auto-tightens supply and raises price
• Multi-buyer priority queueing: high bidders served first, low bidders queue
• Cross-device energy scheduling: storage A discharges for consumer B, settlement auto-splits to owner C and operator D

Stablecoin-based payment + on-chain finance:

• Real-time cash flow: every slice is an auditable USDC line item that accumulates into trustworthy on-chain books
• Future generation tokenization: pre-sell expected generation over the next N days as tokens
• Storage capacity collateralization: battery SoC as on-chain attestation → borrow short-term USDC against it
• Cash flow → credit score: long-term settle history forms a device’s on-chain credit profile → unlock more complex financial instruments
• Multi-stakeholder auto-distribution: solar owner / storage lessor / network operator / upstream maintenance, all settled by on-chain split logic in real time

What “open platform” concretely means:

This means any vertical energy device manufacturer — solar inverters, residential storage, commercial EV chargers, agricultural irrigation systems, portable power stations — can reuse the entire payment protocol stack and plug their hardware into the same on-chain energy economy.

Analogy:

4.3 Cloud Orchestration — Arkreen Cloud Platform

The Cloud layer’s core positioning is Arkreen’s companion cloud for eCandle and eCandle-class devices — purpose-built for energy-specific concerns: telemetry, dynamic pricing, settlement visualization, device management. It is not a generic x402 facilitator (that’s HashAnchor in §4.4).

Architecture:

• Next.js application (public entry): all HTTP APIs + frontend pages (demo / operator console / dashboard)
• settle-worker: MQTT subscriber → unpack BLE batch → construct x402 payload → POST to HashAnchor → write settlement
• burn-intent-worker: on-chain mint pipeline orchestrator — receives mint request → MQTT to eCandle for BurnIntent signing → POST to Circle /v1/transfer → operator wallet calls gatewayMint() → back-fill settlement
• arc-indexer: poll Arc Testnet for AttestationUsed events, match by transferSpecHash, write back onChainTxHash (backup path for the operator)
• MQTT broker (Mosquitto) + SQLite (devices / orders / settlements)
• SSE real-time pipeline: surface per-slice events to the demo frontend (no polling telemetry; reverse fan-out from MQTT)

Engineering principles for the Cloud layer:

1. Holds no value-bearing keys — except an Arc Testnet operator wallet used purely for gas (funded from faucet, testnet-only, isolated from any device funds)
2. All real value movement is driven by device signatures — the cloud is just a courier
3. If devices go down or offline, the cloud cannot fabricate — demo settlements come from real BLE proofs; the cloud has no way to invent value out of thin air

4.4 HashAnchor — TLAY’s Companion x402 Facilitator Cloud

We pull HashAnchor out as a separate section because its responsibilities are fundamentally different from Arkreen Cloud:

HashAnchor has a very focused responsibility: expose an HTTP x402 endpoint (POST /v1/x402/settle), translate incoming x402 payloads into Circle Gateway SDK calls, and return the SDK's batched response (transaction UUID) to the caller. This is a textbook x402 facilitator reference implementation — any DePIN device class (not just energy) that can sign EIP-3009 can use the same facilitator.

Why we place HashAnchor under TLAY:

1. HashAnchor’s existence depends on devices being able to sign — and that capability is what BoAT provides. They form a natural pairing
2. TLAY’s commercial story becomes more complete: we provide DePIN devices with end-to-end signing + on-chain settlement
3. For Circle’s product team it’s cleaner: TLAY becomes the natural integration partner for Circle Gateway on the IoT side — device signing + facilitator from one provider
4. Arkreen stays more focused: it doesn’t have to maintain a generic x402 facilitator, just the energy platform

Future path: HashAnchor’s implementation can be contributed to the x402 community as a reference Circle x402 facilitator — so any DePIN vendor can pull it off the shelf. This echoes the BLE-x402 standardization proposal in §3.1.

5. End-to-End Business Flow

The full “Bitaxe wants to buy electricity → real USDC arrives on-chain” loop runs in 7 steps. We’ll start with a complete sequence diagram, then walk through each step, marking who signs / who pays gas / where the data flows.

5.0 Sequence Diagram

Step 1: Discovery (BLE GAP)

Bitaxe boots into SCAN state: BLE GAP scans for nearby eCandle devices that are advertising. eCandle broadcasts itself with a fixed SSID + service UUID.

*Signal**: BLE advertisement*

*Key operation**: none*

*Gas**: none*

Step 2: Protocol Negotiation (x402-like over BLE)

Bitaxe and eCandle establish a BLE connection → discover GATT services → read the “info” characteristic to fetch paymentRequirements (current price, payTo address, asset, network).

// paymentRequirements exposed by eCandle via BLE GATT (simplified){  "scheme": "exact",  "network": "eip155:5042002",  "asset":   "0x3600000000000000000000000000000000000000",  "payTo":   "0xc3e56b11204f0a095aabd7109c06ddc4274d05d0",  "amount":  "50"     // current slice price in μUSDC}

Signal: BLE GATT read

Key operation: none

Gas: none

Step 3: Sign EIP-3009 Authorization (TLAY BoAT on Bitaxe, on-chip)

Bitaxe decides the price is below threshold → constructs the EIP-3009 authorization tuple → BoAT retrieves the NVS private key → secp256k1 sign (~120ms) → BLE notify pushes the paymentPayload back to eCandle.

*Signal**: BLE GATT notify*

*Key operation:Bitaxe BoAT signs EIP-3009**(on-chip, ~120ms)*

*Gas**: none*

Step 4: On-chip Verification + Service Delivery (eCandle)

eCandle receives the paymentPayload → BoAT ecrecover verifies sig → checks from / value / validBefore → all good → state machine moves to streaming → relay closes, AC output begins. The proof accumulates into local s_proofs[].

Each session by default has max_slices=2, i.e. 2 EIP-3009 proofs then pause.

*Signal**: local state machine + relay output*

*Key operation:eCandle BoAT verifies sig**(on-chip)*

*Gas**: none*

Step 5: Off-chain Batched Settlement (cloud → HashAnchor → Circle)

eCandle accumulates 2 proofs → publish a batch to MQTT topic ecandle/<MAC>/settle → settle-worker (PM2 process on Arkreen Cloud) picks it up → for each proof, constructs an x402 payload → POSTs to hashanchor.xid.network/v1/x402/settle → HashAnchor uses Circle's SDK to call Gateway settle() → Circle credits the USDC to eCandle's payTo address in its internal ledger → settle-worker receives a transaction UUID → POSTs to Arkreen Cloud's /api/settlements → SQLite write → demo page settlement card appears.

At this step all real value movement is in an off-chain ledger — no gas paid, no on-chain transactions occurred. Just a new credit line in Circle’s books.

*Signal**: MQTT settle → HTTP x402 → Circle Gateway settle()*

*Key operation**: none (already signed earlier)*

*Gas**: none*

Step 6: On-chain Settlement (BurnIntent → gatewayMint)

Operator clicks “Mint to Arc” on the demo page (or an automation triggers it) → Arkreen Cloud’s burn-intent-worker starts the mint pipeline:

1. Cloud constructs a BurnIntent (specifying sourceDepositor = eCandle address, value, salt, Arc destination)
2. Cloud computes the EIP-712 digest (32 bytes) → publishes via MQTT to ecandle/<MAC>/cmd/sign_burn_intent
3. eCandle BoAT fetches NVS private key → secp256k1 signs the 32-byte digest → publishes reply via MQTT burn_intent_sig
4. Cloud ecrecover-verifies → compares to sourceDepositor address → match
5. Cloud POSTs to gateway-api-testnet.circle.com/v1/transfer → Circle returns {attestation, signature}
6. Cloud uses operator wallet (gas-only) to call GatewayMinter.gatewayMint(attestation, sig) → Arc Testnet on-chain USDC tx
7. Tx receipt arrives → arc-indexer observes AttestationUsed event → PATCHes settlement's onChainTxHash field

Signal: MQTT cmd → MQTT reply → HTTP /v1/transfer → on-chain transaction

Key operation: eCandle BoAT signs EIP-712 BurnIntent (on-chip, ~150ms) Gas: operator wallet pays gas on Arc Testnet (gas asset is USDC, the wallet was funded with 20 USDC from https://faucet.circle.com — completely isolated from device funds)

Step 7: Public Verifiability

After the tx hash is back-filled to settlement, the demo page renders a 🔗 explorer link on the settlement card. Anyone who clicks goes to testnet.arcscan.app/tx/<hash> and can independently verify on-chain:

• block number, status: success
• from = operator wallet, to = GatewayMinter
• logs include the AttestationUsed event
• USDC value matches the settlement card amount exactly

Turning “we say a nanopayment happened” into “anyone can independently verify a nanopayment happened on-chain.”

6. The Protocol-Level Value of Each Partner

6.1 Circle — Gateway + Nanopayments + Arc Testnet Three-Part Stack

What Gateway solves: high-frequency signing → off-chain batching → on-chain materialization, in three stages. It’s the payment-batching layer for the stablecoin world.

Nanopayments protocol: per-slice EIP-3009 authorization + Gateway batched settlement + on-demand BurnIntent → mint. Circle has productized this pattern formally as Nanopayments.

Arc Testnet: USDC is the native gas asset, sub-second finality, purpose-built for high-frequency micropayment workloads. Without Arc, gas would need to be paid in a separate asset — and the device operator suddenly has to manage an inventory unrelated to their core business.

The three pieces together aren’t a single product — they’re the first stack that makes IoT micropayments economically viable end-to-end.

6.2 TLAY — BoAT SDK + HashAnchor: A Complete DePIN On-Chain Stack

TLAY BoAT Machine Wallet Runtime provides embedded cryptography on devices:

• secp256k1 sign / verify
• keccak256 hash
• RLP / ABI encode
• EIP-3009 / EIP-712 typed-data
• NVS-persisted private key (survives reboots)

Measured performance:

The engineering value of BoAT: it moves “DePIN device-side key self-custody” from a PowerPoint promise to a few lines on a BOM. Without BoAT, DePIN devices end up with either a cloud signing service (breaking the trust model) or external HSM (cost out of control).

HashAnchor (TLAY’s companion cloud): the x402 facilitator reference implementation, the standard on-chain pathway for any BoAT-equipped device into Circle Gateway.

Together, TLAY provides not just an SDK but a complete on-chain stack for DePIN devices from silicon to settlement — reusable across any vertical (not just energy).

6.3 Arkreen — Open Infrastructure for Energy DePIN

Arkreen isn’t selling a specific energy device — it provides an open reference architecture for energy devices: eCandle.

See §4.2b for full details. One-liner: as Raspberry Pi was to embedded computing, as Android was to smartphones, Arkreen eCandle is to the DePIN energy ecosystem. Hardware diversity, unified protocol layer, third-party ecosystem.

Arkreen’s value isn’t in any specific device SKU — it’s in giving the DePIN energy vertical a shared infrastructure base. Any energy device manufacturer can plug into the same payment rails, scheduling protocols, and financial primitives.

7. What You Can Build on This Architecture

For developers who made it this far — three concrete directions to extend:

7.1 Onboard new buyer device types

Any device that can sign EIP-3009 can act as a buyer. Beyond miners (Bitaxe), this could be:

• EV charging stations (vehicle signs to buy charge)
• Smart appliances (dishwasher / dryer signs to buy electricity, peak-shaving)
• AI agents (autonomous agents trigger “buy electricity for my inference task”)
• Mobile devices (outdoor IoT consuming local energy)

Engineering needed: implement BLE central + TLAY BoAT integration + auto-mode decision logic. The protocol layer is fully reusable.

7.2 Onboard new seller device types

Any device that can output energy + verify EIP-3009 + sign EIP-712 can act as a seller. Beyond the eCandle-003 small AC output, this could be:

• Commercial EV chargers
• Dwelling-level battery storage
• Microgrid nodes
• Mobile power stations
• Solar inverters (selling generation directly)

Engineering needed: BLE peripheral + BoAT integration + Arkreen Cloud API onboarding. The protocol layer is fully reusable.

7.3 Build on-chain finance on top of the settlement stream

Each device’s settlement history is a stream of trustworthy, auditable, on-chain-verifiable USDC line items. On this base you can build:

• Energy futures: tokenize next-N-days expected generation, sell forward
• Storage capacity markets: battery SoC is on-chain visible → tokenize, lease, collateralize
• DePIN cash-flow lending: long-term settle history as credit → short-term operational loans
• Multi-stakeholder profit-split protocols: bolt on auto-split contracts above settle events; route real-time shares to solar owner / storage lessor / network operator / maintenance provider

Engineering needed: build on top of the /api/settlements event stream plus smart contracts on Arc Testnet. The protocol layer is fully reusable.

8. Summary and Outlook

8.1 What this demo proves

Returning to the question from §1: can fully automated, self-custodial machine-to-machine nanopayments be built entirely on Circle’s and Arc’s already-released stablecoin payment infrastructure plus TLAY BoAT machine wallet on-device signing capability?

At this point, the answer is obviously yes

More importantly, the combination is portable:

• Switch settlement chain (Arc → Polygon → Base) → just change RPC + contract addresses in the four workers
• Switch buyer device type (Bitaxe → drone → EV) → Cloud Orchestration untouched
• Switch transport (BLE → LoRa → cellular) → x402 protocol contract unchanged
• Switch seller business (energy → compute → data stream) → EIP-3009/BurnIntent unchanged

The four building blocks (Circle Nanopayments / Gateway / Arc / BoAT) together aren’t just the implementation of one demo — they form a protocol-stack skeleton for M2M nanopayments.

8.2 From this demo to an ecosystem

A technical demo’s value lies in what it points to. Extending this architecture horizontally and vertically, there are at least three clear paths:

Path 1: single device → device fleet → DePIN network

Today is 1 Bitaxe + 1 eCandle. The same protocol stack extends directly to:

• N buyer devices sharing 1 seller (a charging station / shared compute node / shared sensor)
• 1 buyer roaming across multiple sellers (a drone choosing among multiple charging stations)
• Mesh structure: every DePIN device is simultaneously buyer and seller

At that point, BLE-x402 + Circle Nanopayments becomes the default payment layer for DePIN devices — no need for each project to invent its own.

Path 2: Arc Testnet → Arc Mainnet → cross-chain settlement

Circle Gateway is multi-chain by design. Protocol-wise our full stack switching to mainnet is just configuration changes. The moment Arc Mainnet launches, this demo is a day-1 viable layer of real economic activity — not a testnet toy, but actual stablecoin-denominated machine-to-machine payments.

Further: Gateway’s design enables cross-domain transfers (source domain → destination domain). One device payment can originate on Arc, terminate on Base, and settle on Polygon — entirely transparent to the device, which signs only a single EIP-3009. This is Circle’s path to turning “multi-chain USDC” into “single USDC, multi-chain projection,” which matters most in DePIN scenarios.

Path 3: x402 + BLE → x402 across transports

x402 today lives primarily on HTTP. We’ve proven the semantics (paymentRequirements / paymentPayload) port to BLE without modification. The same semantics also port to:

• LoRa (long-range low-power DePIN)
• Cellular (NB-IoT devices)
• LoRaWAN / Zigbee / Thread (smart home)
• WebRTC DataChannel (browser to browser)

We intend to propose the BLE-x402 transport profile as a spec to the x402 foundation. Once standardized, any transport can reuse the Circle Nanopayments settlement layer.

8.3 A short verdict

In early 2026, terms like “agentic economy,” “machine-to-machine payments,” and “DePIN nanopayments” are appearing in every product launch and investment deck. But the engineering reality of most “machine autonomous payment” demos is cloud-side signing + database accounting, with on-chain presence existing only in the marketing slide.

What this demo shows is: truly self-custodial, truly on-chain, truly independently verifiable machine-to-machine nanopayments are achievable today. All the required components — Circle Nanopayments, Circle Gateway, Arc, TLAY BoAT — are already running in production. What remains is the engineering work of composing them, and that work is done.

The boundary between the physical world and the on-chain world — which has long been a dashed line on slide decks — has, in this demo, been permanently closed by two ~$5 ESP32 boards. The next chapter isn’t debating whether it can be done; it’s deciding what to do with it.

For integration inquiries, contact the TLAY teams via [email protected]