Paid physical checks · working prototype

Check a place
you can’t see.

Software requests a new measurement from a device on site. The operator earns for answering. The buyer gets a current reading.

RECORDED REPLAY · OCTOBER 11, 2026
No new measurement. No new payment. Test tokens.

Buyer · bounded software

“Is the contact closed?”

The example trip waits for an answer.

Provider · real ESP32-C6

The contact check

No answer requested yet

Illustrative entrance. BOOT represents the contact. The real recorded result is OPEN. Altering the answer changes a copy, not the hardware.

Start with the uncertainty

A past status can’t answer a present question.

The buyer needs a reading for this request, with a ten-second age limit. Replay the actual request, payment, and measurement.

The decision

Check before acting.

In the example, a current OPEN answer permits the trip. An old or altered answer keeps it on hold.

Loading the original public receipt…

Inspect the original receipt and independently query the test payment ↗

The service being sold

A requested check.
An answer you can use.

The proposed buyer avoids a trip made only to inspect something. The provider sells a new measurement, tied to that buyer’s question.

A signature is supporting evidence. It links the answer to the configured device key and request. It does not establish that the device tells the truth.

Both OPEN and CLOSED fulfill the inspection. The operator earns for the check. Payment does not buy a favorable result.

Does this need FieldProof?

Already have a reliable API?Use it. This prototype does not establish an advantage over an existing integration.
Need a check from another operator?FieldProof tests one request, a bounded payment, and signed delivery between buyer and provider.
Will someone pay?That remains unvalidated. The 0.001 test-USDC price demonstrates the payment flow. It is not a business model.

What is real, and what still needs work?

Real in this recorded purchase

An October 11 Solana Devnet transfer preceded a new ESP32 GPIO9 measurement. The board signed OPEN, the request challenge, and the capture time.

The browser verifies the actual signature with the configured public key. Stale and modified answers remain unusable for a new decision.

Open the actual test transfer ↗ · Download the signed receipt

The remaining competition gap

peaq’s intended role is a portable machine identity and a job-linked activity record. The adapters and controlled tests exist. Live activation and event readback remain pending.

This purchase uses Solana and no live peaq identity. It contains founder test activity. There is no customer traction or commercial revenue.

The entrance and trip are an illustrative policy. No gate control, actual trip, escrow, or proof of completed physical work is demonstrated.

Feedback we need before the deadline

Start with a check someone already pays for.

What was the last physical check you paid someone to make—and why couldn’t an existing API answer it?

That is the test for the business. A working payment flow alone does not establish demand.

For the Superteam / peaq reviewer

Does this working paid-check loop fit the Machine Economy track? Which genuine peaq integration will change your assessment most?

Watch the earlier technical demo Review the source ↗