Can this robot
rely on the answer?
A visiting robot needs a current answer from another operator's gate. Verify one paid observation, then try to break it.
See the Solana payment · Test the signed answer
Solana records payment. The device signs its answer. The buyer checks the signature, challenge, input, and age before its decision.
This prototype purchases one contact observation. This inspector uses recorded evidence.
Use the repository quick start for a new simulated purchase.
The signed contact describes the selected input. The buyer selects its acceptance policy.
Inspect a new paid buyer run
Load the independent buyer's result JSON. Never load a wallet keypair. Loading a result creates no payment or measurement.
The static package supports file inspection. Live monitoring requires the repository gateway.
Installed buyer pin remains the trust root.
Is the answer still useful?
Real ESP32 contact stand-in. Read-only inspection. No robot motion.
Is the gate open?
- Contact state
- Pending
- Configured price
- 0.001 Devnet USDC
- Observer
- ESP32-C6 / GPIO9
- Measured at
- Pending
Connecting the local buyer.
- Select Pay
Real Devnet payment. The laptop signs with a test wallet. BOOT only changes the input.
Original recorded answer
Live path: x402 settlement, then a BLE contact observation. BOOT represents the contact.
Original measurement time. Current browser clock.
Loading the committed evidence.
The signature authenticates the device's claim. It never extends freshness or proves safe access. No button charges money or measures hardware.
This is where Solana enters the transaction.
Loading recorded terms.Loading recorded terms.Open this transaction in Solana Explorer
The facilitator settles payment on Solana. The gateway then requests the ESP32 observation over Bluetooth.
Solana program: SPL Token. The buyer authorizes test USDC. The ESP32 signs the observation, not a Solana transaction.
The laptop demo simulates settlement. Only a real Devnet buyer creates a new chain transaction.
NOT QUERIEDThe amounts above describe the recorded transfer. Run the read-only query to verify it now.
Inspect the chain query details
No network query yet.
This check reads chain data. It never sends funds or refreshes the observation. It trusts the selected RPC. Payment does not establish physical truth or successful delivery.
The public key comes from this installed repository's buyer configuration. A provider cannot select its own trusted key. The private key resides in unencrypted NVS. This proves the signing key's claim, not physical truth.
One device. Two physical states.
The operator held and released BOOT in separate October 2 input checks. Your browser verifies both recorded receipts against the same device pin.
These two checks moved no funds. BOOT represents a contact. Both observations are expired and remain WAIT today.
Checking recorded input evidence.
One observation starts a larger service relationship.
The first buyer hypothesis is a fleet software operator that needs repeated interactions with independent facilities.
Start with one buyer and one authorized operator. A second facility tests whether the buyer can reuse its integration.
Dock use, charging, and elevators are later service candidates. Access permission, control, and completed-service verification remain future work.
peaq Agung registry reads establish deployment readiness today. No observer identity is activated. Registration alone cannot establish installation or physical truth.
Inspect the receipt and buyer challenge
Loading.
Inspect the public identity pin
The operator read this key over trusted USB and verified it after reset. The browser reads the public pin from the installed demo. Use the independent CLI buyer for a new paid observation.
Loading.