Verifiable Blackbox

Demo

About

When a robot says “job done,” who checks the claim and authorizes the payment? Businesses buying robot services need more than an activity log. They need a clear connection between the work they requested, the evidence they accepted, and the payment they made. Verifiable Blackbox brings these records together in one traceable workflow. Inspired by an aircraft’s black box, Verifiable Blackbox connects physical robot activity to evidence-backed payments on Ethereum. Every job carries its own conditions, customer approval, evidence, signed verification result, and payment receipt—giving customers and operators a shared record they can inspect. Our demo brings this workflow into the physical world with a small M5Stack Rover. A customer creates a job and deposits a reward into escrow. The Rover is operated through a web interface, and the application connects its session records, video-motion assessment, and signed customer approval to that job. Phala checks the submitted evidence against the onchain job and returns a signed verdict. The Ethereum contract checks the signer, evidence hash, job details, and expiry before releasing the reward. A receipt connects the payment to its supporting evidence. The demo uses test mUSDC on Ethereum Sepolia. Each integration answers a practical business question. Which device signed the record? ENS resolves the robot’s registered public key for device-signature verification. Does this evidence belong to this job? Phala checks the correspondence and signs the result. What supports this payment? Curvegrid MultiBaas retrieves transaction receipts and events, allowing the ledger to connect payments with jobs and verification records. StegaVAR adds video embedding and reconstruction for visual evidence review, while a monthly accounting demo groups records by provider and exports them as CSV. Who may view the recorded evidence? A separate World IDP/OIDC disclosure workflow combines approver permissions with World authentication to grant five-minute access to sample recordings, with revocation and expiry controls. This keeps video access separate from payment authorization. Full authentication-to-disclosure validation in the World Sandbox is still pending. The result is a working prototype that connects robot operations with customer approval, verification, settlement, and accounting. Starting with one Rover, Verifiable Blackbox demonstrates the foundation for buying robot services across businesses: evidence customers can review, payments they can trace, and records they can use.

How it's made

We built four connected components: a physical rover, a web application, a verification service, and Ethereum smart contracts. Job identifiers and evidence commitments connect them. The stack includes M5Stack/ESP32 hardware, Python, Next.js, React, TypeScript, viem, Solidity, Foundry, and Phala Cloud with dstack. Privy supports authentication and wallet integration. The rover combines an M5StickC Plus2 with a RoverC Pro, its gripper, and a Unit CamS3-5MP camera. C++ firmware handles motor control, while a Python bridge handles Wi-Fi commands, telemetry, and camera access. Next.js API routes connect the application to this bridge, bringing job creation, robot operation, approval, and payment receipts into one interface. Settlement uses a Core, Hook, and Evaluator architecture inspired by the ERC-8183 job model. The Core holds the reward in escrow. The application checks the job owner’s approval signature, while the Phala service checks the evidence commitment, job-specific challenge, sequence, expiry, and onchain state. It signs an EIP-712 verdict only when those checks pass. The Evaluator validates the verdict against the target job before settlement. For Phala Cloud deployment, the verifier runs inside a TEE and derives its signing key through dstack KMS. Our independent attestation CLI checks a fresh nonce and expected signer, chain, Evaluator, and execution-environment values. Phala adds a way to inspect the environment producing the verdict, beyond trusting an API response alone. For device identity, the ESP32 signs job identifiers using P-256. We resolve the enrolled public key from an ENS vbb.device.p256 text record and verify the signature locally and through an ERC-7913 verifier deployed on Sepolia. This remains an independent verification component, separate from payment authorization. One practical hardware detail was moving signing into a separate task that runs while the rover is stopped, alongside stop monitoring independent of HTTP processing. Cryptography and network delays should not block stopping the robot. Curvegrid MultiBaas supplies receipts, events, and block information for selected Sepolia payments. We reconcile these records with the corresponding jobs and token transfers. A separate monthly sample dataset demonstrates aggregation by counterparty and CSV export. When bulk event retrieval hit an API limit, we used individual transaction-receipt endpoints to retrieve the existing payments without changing the settlement contracts. We also integrated an experimental StegaVAR video workflow. Recorded rover clips are embedded into cover videos, reconstructed, and analyzed on CPU using the recovered frames. This is currently a public sample comparison and analysis feature; it does not enforce confidentiality or authorize payments. We also added a World IDP/OIDC integration for controlled video disclosure. The workflow combines approver permissions with World authentication to grant five-minute access to a sample recording, with revocation and expiry controls. It remains separate from payment authorization. Full authentication-to-disclosure validation in the World Sandbox is still pending. Our Foundry, Python, TypeScript, and browser checks cover successful settlement, tampered evidence, expiry, verdict reuse, service recovery, and duplicate-payment prevention. The current verifier checks evidence and job consistency. Autonomous verification of physical movement or successful delivery remains an extension we are building toward.