Robots Just Got Bank Accounts: Inside the Machine Economy's First Real Deployments

Robots can already move through the physical world. The harder problem is giving them a safe way to participate in the economic one.

The demos, and why they're not just marketing

For years, "machine economy" has been a slide in a conference deck: machines discovering services, paying for them, earning from them, transacting with each other with no human clicking approve. Technically plausible, nowhere deployed.

That's starting to change, and it's worth being precise about what actually happened versus what's still aspirational.

On June 10, 2026, Tether announced it was leading a Series C round of up to $1.4 billion into NEURA Robotics, a German cognitive robotics company, alongside Qualcomm, Amazon, NVIDIA, Bosch, Schaeffler and the European Investment Bank. On its own that's a robotics funding story, reportedly the largest round ever raised by a full-stack robotics company, pushing NEURA toward a roughly $7 billion valuation. What makes it relevant here is the second half of the announcement: Tether isn't just an investor. It's integrating its Wallet Development Kit (WDK) and its QVAC edge-AI runtime directly into NEURA's Neuraverse platform, so NEURA's robots (humanoids, AMRs, robotic arms) can hold self-custodial wallets and transact without a human approving each payment.

A month earlier, on May 12, 2026, a separate project called peaq, a Layer 1 built specifically for DePIN and what it calls the machine economy, ran a live demonstration that's more concrete: a Serve Robotics delivery bot navigating a simulated Seoul street grid using NAVER Maps, completing a delivery, and settling payment onchain in USDT through Tether's WDK, with Solana as the settlement layer. peaq's broader pitch, through a marketplace it calls robotic.sh, is that a robot calling a mapping API or an inference service should look like a metered API call with an onchain settlement receipt attached, and that any machine running peaqOS can plug into that marketplace regardless of which blockchain it natively uses.

Neither of these is a robot casually holding crypto as a novelty. Both are explicit attempts to solve a real infrastructure gap. But it's worth saying plainly: the peaq demo ran in a simulated Seoul environment, not live city streets, and neither deployment should be read as robots conducting unrestricted autonomous commerce in the real world today. What they prove is that the software architecture underneath that idea now exists and is being wired together. What they don't yet prove is the hardest part of the problem, which is the actual subject of this article.

Giving a robot a wallet is the easy 20%

A robot holding a private key doesn't make it an economic agent. That's just:

Robot → private key → wallet → payment

A real autonomous economic system needs a lot more sitting around that core:

Take the delivery robot from the peaq demo. Doing its job for real means it has to establish who it is, figure out what it's actually allowed to spend money on, discover the services it needs (a map, a charging dock), pay for them, execute the physical task, produce evidence that it did, get paid, and update its own track record before doing it again. The wallet is one box in that chain. The interesting engineering is everywhere else.

Why ERC-4337 wasn't built for this

If you've worked with account abstraction, the mental model is familiar: a human owns a smart contract wallet, delegates a scoped session key to an agent (spend up to X, on this contract, until this timestamp), a bundler and EntryPoint handle validation and execution, a paymaster optionally covers gas. The trust root is a person who granted the delegation and can revoke it.

A robot operating continuously in the physical world breaks that model in a specific way: there's no clean session boundary and no human standing behind each individual spend decision. A "session" for a delivery robot isn't a login window, it's an entire operational shift involving dozens of independent pay-or-get-paid decisions. What you actually want isn't a flat spending cap, it's task-scoped, capability-bound authority:

Robot #8472
  navigation   → max $2 / task
  charging     → max $20 / session
  maintenance  → max $50 / incident
  delivery     → can receive payment: yes
  treasury     → can transfer funds: no

Each capability gets its own scope, spending limit, expiration, allowed counterparties, and revocation condition. That's a meaningfully different design target than a single session key, and it's closer to how you'd design permissions for a fleet of IoT devices than how you'd design a session for a human using a dApp. Most 4337 wallets today aren't built with this granularity of delegation hierarchy (company → fleet key → individual robot → per-capability scope), and that's a real gap, not a solved problem with a different UI.

The part account abstraction can't touch: did it actually happen

Here's the distinction that matters most, and it's easy to skip past. ERC-4337 can answer whether a transaction was authorized. It cannot answer whether the real-world claim behind that transaction is true.

A blockchain can verify that account X authorized transaction Y. It cannot directly observe that robot X physically delivered package Y to customer Z at 10:42 AM. A robot claiming "I completed the delivery" is a self-interested party asserting a fact about the physical world, and account abstraction has nothing to say about whether that assertion is correct. That gap is exactly where identity and reputation standards, and eventually a physical attestation layer, become necessary rather than optional.

Where ERC-8004 fits, and where it stops

ERC-8004 (Trustless Agents), currently a draft EIP that extends the Agent-to-Agent protocol with a trust layer, defines three lightweight onchain registries:

• Identity Registry: agents register as portable, chain-agnostic identifiers using the CAIP-10 format, so the same agent identity holds across Ethereum mainnet, Base, and other EVM chains without losing continuity.
• Reputation Registry: structured feedback and performance history a counterparty can check before transacting, instead of trusting a cold-start claim.
• Validation Registry: a slot for stronger trust mechanisms (cryptographic proof, TEE attestation, third-party validators) for interactions where reputation alone isn't sufficient.

The spec is explicit about its own boundary, and this is the sentence worth internalizing: it cryptographically ensures a registration file corresponds to a real onchain agent, but it cannot cryptographically guarantee that the agent's claimed capabilities are functional or non-malicious. In other words, ERC-8004 tells you who an agent is and what its track record looks like. It does not tell you whether this specific delivery, right now, actually happened. For that you still need reputation built over many transactions, a staked validator network, or a hardware attestation from the device itself.

Laid out side by side, the division of labor across the stack looks like this:

Layer	Mechanism	Answers	Does not answer
Authorization	ERC-4337 / EIP-7702 session keys	Who is allowed to sign this transaction, under what scope, until when	Whether the real-world claim behind the transaction is true
Identity & trust	ERC-8004 (Identity / Reputation / Validation registries)	Who is this agent, what's its history, is a validator backing this specific claim	Whether a first-time agent's single, unverified claim is true
Cross-chain intent	ERC-7683	How an agent expresses "pay X on chain A for Y delivered on chain B"	Trust in the counterparty actually performing Y
Physical task verification	Sensor attestation / TEE / oracle network (not yet standardized for robotics)	Did the physical event actually occur	This is the layer that's still genuinely open

That last row is the interesting research gap, and it's the reason the current deployments work at all: they're either simulated (peaq/Serve Robotics), tightly scoped to a known route or dock, or backstopped by the deploying company's own operational reputation standing behind the robot. An actually open marketplace, where a robot from company A pays a service from company B it has no history with, purely on the strength of an onchain claim of physical task completion, needs a verification layer that doesn't fully exist as a standard yet.

AI proposes, policy decides, cryptography enforces

One architectural principle worth being strict about: don't wire an AI model's output directly to a private key.

The AI proposes an action. A deterministic policy layer, not a model, decides whether that action falls within the robot's granted capabilities. The smart account enforces the authorization rules. The cryptographic layer executes. This separation matters more as the models making the proposals get more capable and less predictable; you want the thing that can hallucinate to be several steps removed from the thing that can move money.

Task-gated escrow instead of trust-me-I-did-it

A naive implementation lets the robot sign a transfer the moment it decides a task is done:

That's the robot asserting "trust me" with no independent check. A stronger pattern locks funds at task creation and releases them only against a signed attestation from a party the payer actually trusts, not the payee itself:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

/// @notice Minimal task-gated escrow for machine-to-machine payments.
/// Funds are locked at task creation and released only against a
/// signed attestation from a registered validator, not a raw
/// session-key transfer from the payee. This keeps "who can sign"
/// (ERC-4337 territory) separate from "was the task actually
/// completed" (attestation / validator territory, conceptually
/// aligned with ERC-8004's Validation Registry).
contract TaskEscrow {
    struct Task {
        address payer;      // robot / fleet wallet funding the task
        address payee;      // robot / service being paid on completion
        address validator;  // trusted attestor for this task class
        uint256 amount;      // in USDT (or wrapped equivalent)
        uint64  deadline;
        bool    settled;
    }

    mapping(bytes32 => Task) public tasks;
    IERC20 public immutable settlementToken;

    event TaskCreated(bytes32 indexed taskId, address payer, address payee, uint256 amount);
    event TaskSettled(bytes32 indexed taskId, bool success);

    constructor(address _settlementToken) {
        settlementToken = IERC20(_settlementToken);
    }

    function createTask(
        bytes32 taskId,
        address payee,
        address validator,
        uint256 amount,
        uint64 deadline
    ) external {
        require(tasks[taskId].payer == address(0), "task exists");
        settlementToken.transferFrom(msg.sender, address(this), amount);

        tasks[taskId] = Task({
            payer: msg.sender,
            payee: payee,
            validator: validator,
            amount: amount,
            deadline: deadline,
            settled: false
        });

        emit TaskCreated(taskId, msg.sender, payee, amount);
    }

    /// @notice Releases funds only against a validator signature attesting
    /// completion. The validator role is where the hard problem actually
    /// lives: a TEE-backed sensor attestation, an ERC-8004 Validation
    /// Registry entry, or a staked oracle network, depending on how much
    /// you're willing to trust a single validator versus wanting
    /// slashing-backed guarantees.
    function settleTask(
        bytes32 taskId,
        bool completed,
        bytes calldata validatorSignature
    ) external {
        Task storage t = tasks[taskId];
        require(!t.settled, "already settled");
        require(block.timestamp <= t.deadline, "task expired");

        bytes32 digest = keccak256(abi.encodePacked(taskId, completed));
        address signer = _recoverSigner(digest, validatorSignature);
        require(signer == t.validator, "invalid attestation");

        t.settled = true;

        if (completed) {
            settlementToken.transfer(t.payee, t.amount);
        } else {
            settlementToken.transfer(t.payer, t.amount);
        }

        emit TaskSettled(taskId, completed);
    }

    function _recoverSigner(bytes32 digest, bytes calldata sig) internal pure returns (address) {
        // ECDSA recovery, omitted for brevity
    }
}

interface IERC20 {
    function transferFrom(address from, address to, uint256 amount) external returns (bool);
    function transfer(address to, uint256 amount) external returns (bool);
}

Writing it this way forces you to name the trust assumption explicitly instead of hiding it. Who is validator? In the public description of the NEURA and peaq deployments, the honest answer today is closer to "the platform operator's own infrastructure attesting to its own robot's task completion." That's a reasonable way to bootstrap the system. It is not yet the open, permissionless verification layer the machine economy narrative implies, and that gap is worth naming rather than glossing over.

But locking the check behind a single validator address just relocates the trust problem, it doesn't remove it. If that validator is controlled by the same company running the robot fleet, you've reintroduced a centralized dependency wearing a decentralized costume. A more robust version routes the decision through a quorum:

validator A ┐
validator B ├─ quorum → release / refund
validator C ┘

with validators economically staked and slashable for false attestations. Nobody has fully standardized this for robotics yet. That, not the wallet, is the open research problem.

The stack, end to end

Putting the pieces together, a deployment like NEURA's or peaq's looks roughly like this:

Physical layer      → robot hardware, sensors, actuators
Edge runtime         → on-device inference/decisioning (Tether QVAC)
Identity/orchestration → DID per machine, task orchestration, service
                          discovery (peaqOS, robotic.sh marketplace)
Wallet layer         → self-custodial, modular, keys never leave the
                          device (Tether WDK, built with account-
                          abstraction infra from Candide)
Settlement layer      → USDT for stability during multi-step tasks,
                          Solana for low-fee micro-transactions

Two details are worth pulling out. First, WDK's self-custody model means private key material genuinely lives on the device, no cloud custodian in the loop. That's good for censorship resistance and creates a new problem covered below. Second, the choice of USDT specifically, not a volatile asset, isn't incidental: a robot doing cost-benefit reasoning ("is this charging dock worth $0.40") needs that number to be stable across the ten minutes it takes to get there, not a function of market volatility.

Where this actually breaks

A few failure modes worth naming directly, because they're the difference between a compelling demo and something you'd put real capital or real safety risk behind.

Physical key extraction. A wallet on a server is protected by server-grade operational security. A wallet embedded in a delivery robot standing on a sidewalk is protected by whatever tamper-resistance the hardware has, and delivery robots get kicked, opened, and occasionally stolen. If key material lives on-device, physical access becomes an economically motivated attack surface that doesn't exist for a phone with biometric gating and remote wipe.

Validator capture. Covered above: whoever controls the validator role controls payment release, full stop. Distributing that role across independent, staked, slashable parties without making settlement too slow or expensive for high-frequency micro-payments is unsolved.

Reputation cold-start. ERC-8004's reputation registry helps once an agent has a transaction history. It does almost nothing for a brand-new robot's very first transaction with a stranger, which is exactly the open-marketplace scenario robotic.sh is aiming at. Expect early real-world versions to lean on TEE attestation (trust the hardware) or platform-level reputation (trust NEURA or peaq as an umbrella guarantor) rather than genuinely peer-to-peer trust.

Sybil identities. Nothing stops an attacker from spinning up many fake agent identities to manipulate a reputation system, the same Sybil problem that shows up everywhere else in crypto, now with a physical robot attached to each fake identity.

Simulation-to-reality gap. Worth repeating: the peaq/Serve Robotics demo ran in simulation. That's a legitimate way to validate the payment and orchestration logic without betting capital on real-world edge cases, but simulated task completion is a much easier attestation problem than the real thing, where GPS drift, sensor noise, partial deliveries, and adversarial actors on an actual street all show up. Treat the current demos as proof of software architecture, not proof of the physical trust layer.

Liability. None of the public coverage of either deployment addresses who's responsible when an autonomous payment goes wrong, a robot pays for a service it never received, gets defrauded by a spoofed validator, or hits a race condition in a marketplace with many concurrent machine buyers. There's essentially no regulatory framework yet for liability when a non-human, non-custodial economic agent makes a bad autonomous financial decision. That's not a blocker to building the infrastructure. It is a real blocker to deploying it at scale outside controlled environments.

Why the wallet was always the easy part

If you're already working on agentic wallets, 4337/7702 delegation patterns, or ERC-8004 identity infrastructure, these deployments are the concrete context that makes the abstract research question real: what does authorization look like when the transacting agent isn't software acting for a person at a keyboard, but a physical machine making continuous economic decisions off sensor input, with no human in the loop for the vast majority of individual transactions?

Wallet infrastructure (WDK) is largely solved and genuinely good engineering. Identity and discovery (ERC-8004, peaqOS DIDs) is being actively standardized and is close to workable. What's still open, and where I think the interesting systems research sits for the next year or two, is a decentralized attestation layer that can answer "did this physical task actually happen" with the same rigor ERC-4337 brings to "was this signature authorized." Robots got bank accounts in 2026. They don't yet have a trustworthy way to prove what they did to earn the money, or what they did with it, without leaning on the same centralized operators the decentralization was supposed to route around.