The problem AgentNode solves

TL;DR

AgentNode lets machines pay machines. A device that's too weak for a job (like a Raspberry Pi) finds nearby devices, splits the work, uses its owner's devices for free, pays strangers' devices per job on HSK Chain, keeps private data on devices it trusts, and checks the work before any money moves. Anyone in the room can also scan a QR code and pay a laptop's local AI for a private answer from their own phone.

The problem

1. Machines can't pay each other.
AI agents, robots and small devices increasingly need things from other machines: compute, model access, data. But every payment system today is built for humans, with accounts, API keys, credit cards and monthly plans. A Raspberry Pi can't sign up for a cloud account, and a laptop sitting idle has no simple way to charge a stranger for its spare power.

2. Giving an AI agent a wallet is dangerous.
If an agent can spend money, one bug, one bad loop or one manipulated prompt can drain it. Today the only protection is trusting the agent's code.

3. Strangers can't trust each other.
A device won't do work without a guarantee it gets paid. A buyer won't pay without a guarantee the work is real. Without a middleman, there's no way to settle this.

4. Outsourcing leaks private data.
Sending a job to the cloud or to an unknown machine exposes everything in it, including personal notes and private questions.

How AgentNode solves it

What people can use it for

• Weak devices borrowing power. Robots, Raspberry Pis, smart home hubs and cameras can offload heavy work (rendering, AI inference, data processing) to a laptop or tablet nearby, and pay only when the device isn't their own.
• Idle devices earning money. Laptops, tablets and gaming PCs that sit unused most of the day can sell spare compute to nearby agents, per job, with no platform in the middle.
• Safe budgets for AI agents. Developers can give an agent real spending power with hard limits enforced by a contract, not by hoping the code is correct.
• Private AI for families, teams and classrooms. One strong machine runs a local model, and everyone else asks it questions without anything going to a cloud provider.
• Pay-per-use AI at events. Our demo: anyone scans a QR code, gets their own wallet on their phone, and pays per answer from a laptop's AI. No sign-up, no subscription, and each person's answers are private to them.

How it makes existing tasks easier and safer

• Easier: no accounts, API keys or subscriptions. A device just asks, gets a price, pays and receives the result.
• Safer spending: the agent's limits live in a contract, which is enforced even when the agent misbehaves. We demo the contract blocking an overspend live.
• Safer trading: locked payments protect both sides, and spot-checks catch cheating. We demo a node returning fake work, failing the check, and the payment being refunded.
• More private: private data stays on your own devices, and the AI runs locally instead of in the cloud.
• Fairer: you pay only for what you use, you never pay your own devices, and failed work costs nothing.

What we built

• A Solidity contract on HSK Chain testnet: a node registry, spending-limited agent wallets, and locked per-job payments with release, refund and a claim window that protects nodes.
• A requester agent (the Pi) that scans for nodes, plans the split by speed and budget, pays, verifies, and combines the results. It also chats with private AI.
• A MacBook node running LM Studio and multi-core rendering, and a browser-based node that runs on any device with a browser, demands payment, verifies it onchain itself, and renders its share.
• An audience mode where each phone gets its own wallet, receives a 402 invoice, signs a payment voucher, and gets its own private answer. Forged vouchers, reused vouchers and empty wallets

Challenges I ran into

1. "Payment not locked" — a load-balanced RPC that lags behind itself

The bug: The demo worked several times, then suddenly started failing. The Pi would lock a payment onchain, the transaction confirmed, but the iPad node replied "payment not locked for this node". The automatic refund then failed with "not locked", and small amounts of testnet HSK got stuck in the contract.

The cause: The public HSK testnet RPC is several servers behind one address. The write confirmed on one server, but the very next read hit a server that was still a block behind, so it saw no payment at all. It worked earlier purely by luck of timing.

The fix:

• Every payment check now polls until the chain catches up (up to 20s) instead of trusting a single read.
• Release and refund transactions skip gas estimation (a lagging server wrongly predicted a revert) and retry safely, checking first whether the job was already settled.
• To prove the fix, we built a deliberately laggy RPC proxy that serves stale data on half of all reads, and ran every flow through it until nothing broke.
• Added npm run doctor and npm run fix, which scan contract events for stuck payments and refund them. That's how we recovered the stuck funds.

2. Nonce collisions on back-to-back transactions

Setup sends several transactions in a row (deploy, fund, register). One failed with a cryptic "could not coalesce error" because the RPC returned a stale "pending nonce". We switched every wallet to a nonce manager that tracks nonces locally, so rapid transactions never collide.

3. Campus Wi-Fi blocked device-to-device traffic

The university network uses client isolation, so the iPad couldn't reach the MacBook at all. A phone hotspot didn't solve it either. For the live demo, the iPad node runs in a browser window. It's the same code with its own wallet, making its own onchain checks. This pushed us to design the node as a plain web page, so any device with a browser can be a compute node.

4. An iPad can't run a server

iOS doesn't let a web page accept incoming connections. Instead, the iPad page keeps a WebSocket open to the MacBook, which relays requests to it. The iPad still makes every decision itself: it sends the 402, verifies the payment onchain from its own browser, does the work, and gets paid to its own wallet.

5. How do you know a stranger actually did the work?

Paying before work protects the node; paying after protects the buyer. We needed both. The answer was locked payments plus a deterministic workload: fractal rendering produces bit-identical output in Node.js and Safari, so the buyer can recompute a few random pixels for almost nothing and compare. We tested it with a "cheat mode" that returns fake work: 160 of 160 sampled pixels were wrong, the payment was refunded, and the work was reassigned.

6. Letting the whole audience in, safely

Reachability: audience phones are on mobile data, not our network. We used a Cloudflare tunnel to give the MacBook a public HTTPS address for the QR code.

Security: that tunnel would have exposed everything. The server detects tunneled requests and allows only the question page and its API. Payments, nodes, admin pages and websockets all return 404 or are refused from outside. We tested every route.

Everyone gets their own answer: each phone generates its own key and signs a voucher per question, and answers are readable only by the wallet that paid. We stress-tested six phones asking at once, plus forged vouchers, replayed vouchers, empty wallets and one wallet reading another's answer. All were handled correctly.

One laptop, many users: a single local model can't answer everyone at once, so we built a fair queue that shows each person their position, gives the presenter's Pi priority, and refunds automatically if the model fails.

7. Reasoning models leaking their "thoughts"

Some models in LM Studio stream hidden reasoning in <think> tags before the answer. We strip it on the fly, even mid-stream, so users only ever see the final answer.