Pay for an answer.
Verify it before
you rely on it.

Understand the product

The company hypothesis

The first product to test is paid remote inspection jobs for remote-operations software. An existing device supplies a current answer when the buyer lacks a reliable API.

Compare one authorized operator's current workaround with FieldProof. Then test a second operator and measure integration reuse.

Demand, price, provider margins, and distribution remain unvalidated. Access control and completed-service proof remain future work.

The current strategy route links the canonical plain-language story and commercial test.

One buyer, one operator, one immediate decision

Example: a delivery robot reaches an access point operated by another company. Its controller needs the current gate-contact state.

The operator permits sale of that observation. The buyer pays for one answer. Its controller decides whether that answer helps the next action.

This is the product hypothesis. We have no robot customer or installed gate. Our ESP32 button represents the contact.

A ten-second answer fits a nearby decision. It cannot predict gate state after a long trip. It also cannot grant access permission.

What each part does

The buyer CLI, gateway, and BLE bridge run on one laptop. The Seeker can run the browser verifier independently.

Separate software roles establish verification boundaries. They do not demonstrate separate commercial operators.

Why pay with x402?

402 Payment Required is an HTTP response. HTTP is the request protocol your browser uses.

The x402 protocol adds machine-readable payment terms. A compatible buyer checks those terms, signs a constrained transaction, and retries the request.

The facilitator verifies and submits the payment. The gateway reads the sensor only after successful settlement.

Our paid buyer permits Solana Devnet USDC, one merchant, and a maximum payment of 0.001 USDC. It needs no checkout form.

An ordinary authenticated API remains an alternative. x402 supplies per-request payment terms for compatible buyers. A pilot must establish whether that helps these operators.

Why sign the answer?

The device keeps a private signing key. The buyer stores its matching public key, called an identity pin.

A valid signature ties the reported fields to that private key. The gateway cannot change the contact state without invalidating the signature.

The buyer installs its pin through trusted provisioning. Accepting any public key advertised by a provider defeats this identity check.

A signature does not certify wiring, location, truthful firmware, or permission. Physical key extraction remains possible because device storage is unencrypted.

Why use a challenge and an expiration?

The buyer supplies a new nonce: a number that identifies this question. The device signs that nonce with the answer.

An earlier answer cannot answer a different challenge. A matching answer also needs a recent measurement time.

The device clock starts from an authenticated host request. This prototype checks that time against the buyer clock. It lacks independent time attestation.

Five matching samples show short-term agreement from one input. They are not five independent observers or a calibrated probability of correctness.

What changes with two observers?

The optional pair policy requires two configured device identities to report fresh, stable OPEN. Any missing, conflicting, stale, invalid, skewed, or replayed evidence produces WAIT.

Both receipts use one evaluation time. The pair expires when its oldest observation or earliest request expires.

Two valid signatures can disagree. They identify the reporting keys, not an independently verified physical truth. Two sensors can also share one wiring fault.

Run uv run --project host capmesh corroborate-demo --scenario all to explore eight explicitly simulated signed-fixture scenes. It uses no hardware and moves no funds.

The paid demonstration still uses one board. See the pair policy and physical acceptance gates before claiming two-board operation.

Why can authentic evidence still produce WAIT?

The recorded purchase really settled, and its device signature remains valid. Its ten-second decision window expired.

Replaying the receipt or verifying the chain cannot refresh that window. A new decision needs a new observation.

DISPATCH means the demo accepts fresh OPEN evidence. It does not mean the robot has permission or a safe path.

What happens if payment succeeds and delivery fails?

The gateway preserves the payment and marks delivery_failed. An operator must review the failure and any refund.

The payment and sensor response do not share an atomic transaction. A blockchain payment alone does not prove delivery.

A retry returns the stored answer if delivery completed. It never silently purchases another answer or resets the evidence timestamp.

Where does peaq fit?

The proposed peaq role is the observer's registered identity and honest service history. Solana remains the demonstrated observation-payment rail.

The current Agung diagnostic reads the published machine registry and computes an ID from the public device pin. It does not activate a machine.

It also checks ownership at the same finalized block. The recorded proposed ID was absent. Absence reserves nothing and grants no ownership.

An activated identity can later connect an operator, verification method, and service endpoint. Registration alone cannot certify sensor truth or installation.

See the peaq integration decision for measured readiness, remaining inputs, and the documented Solana-onboarding limitation.

What creates a durable business?

The unvalidated opportunity is repeated physical-service use across operator boundaries. The first observation tests only the evidence-purchase step.

Existing infrastructure solutions matter. Open-RMF already connects robot fleets, doors, elevators, and building systems.

FieldProof must establish an additional commercial problem around terms, payment, permitted evidence, and failure recovery. Open-RMF

Start with one buyer incident. Identify the missing fact, current alternative, useful-time window, operator permission, and cost of a wrong decision.

Then test repeated delivery and a real budget. Query counts and a test-token transfer do not justify installing a sensor fleet.

Future advantages depend on authorized supply, useful coverage, reliable delivery, and repeat customers. The MVP establishes none of those commercial results.

What this MVP demonstrates

Run it yourself

Prerequisites for every mode: Python 3.10+, uv, and Node.js 22.13+ with built-in node:sqlite. Firmware work additionally needs ESP-IDF 6.1 and esptool 5.4.

Run one mode at a time for your rehearsal. The current signed-receipt walkthrough inspects recorded payment evidence and executes browser verification.

Step by step: no hardware

Start at the repository root. Use a second terminal for tests while a gateway runs. Stop it with Ctrl+C before changing modes.

1. Install the Python environmentuv sync --project host
2. Run the adversarial CLI loopuv run --project host capmesh observe-demo --simulated
   Watch it reject a cheaper stale provider, a replayed answer, a changed answer, and a replayed device request. It also records served and unmet demand.
3. Install the gatewaynpm --prefix gateway ci
4. Start the browser simulatornpm --prefix gateway run demo
5. Open the dispatch deskhttp://127.0.0.1:4022
   Select Get payment quote to see the 402 response. Then select Run simulation. Wait eleven seconds to watch WAIT appear when evidence expires.
6. Rehearse the closed stateStop the open simulator first.npm --prefix gateway run demo -- --closed
7. Run every software testuv run --project host pytest -qnpm --prefix gateway test

Step by step: with the ESP32

Start at the repository root. The attached board already runs the verified firmware. Rehearsal needs no flash.

For another board or a replaced key, complete trusted identity provisioning first. The checked-in pin identifies our demonstration board.

1. Close other BLE scansLive mode fails when the board is busy. It never substitutes simulated hardware.
2. Build only when firmware changesActivate the environment created by your ESP-IDF installer.(cd firmware/esp32 && idf.py build)
   Espressif Installation Manager creates activate_idf_v6.1.sh. The standard installer uses "$IDF_PATH/export.sh". Follow the provisioning runbook for flashing. Keep BOOT released during reset or flashing.
3. Confirm the observation pathuv run --project host capmesh observe-demo
   Check evidence_mode: physical-contact-demo and sample_agreement: 5/5.
4. Browser with real contactnpm --prefix gateway run demo -- --physical
5. Prove both statesHold BOOT while you run the observation. Check CLOSED and WAIT. Release BOOT, create a new quote, run another observation, and check OPEN and DISPATCH.
6. Run the hardware suiteuv run --project host pytest -q --hardware

Alternative transport: connect to the board's CAPMESH_96A2 access point and pass --http-url http://192.168.4.1. On Linux with overlapping VPN routes, add --http-interface with your Wi-Fi interface name.

Step by step: real Devnet payment

Start at the repository root. Keep the gateway in one terminal and run the buyer in another.

1. Start the Devnet gatewaynpm --prefix gateway start
   Binds to 127.0.0.1:4021. Offers x402 V2 exact payment for 1,000 base units of Devnet USDC.
2. Fund a disposable buyerUse a throwaway Solana CLI keypair and the Devnet faucet. Never use a funded mainnet keypair.
3. Pay and verifynode gateway/buyer.js /path/to/disposable.keypair.json
   The client rejects other networks, other assets, other recipients, and any amount above 0.001 USDC. It prints no key material.
4. Check the chain yourselfSearch the printed transaction signature on Devnet before you claim an on-chain result.

Anatomy of one purchase

This is the whole product in ten steps. Each step names the file that owns it.

1. The buyer creates an immutable challengegateway/server.js · POST /requests
   A positive 32-bit nonce becomes part of a stored purchase ID. The challenge cannot be edited after creation.
2. The buyer asks for the observation URLGET /observe/:id returns 402 Payment Required with the exact amount, network, asset, and recipient.
3. The buyer refuses a changed contractgateway/buyer.js
   Before any money moves, the client re-reads the quote. If the gateway widened the freshness limit, moved the location, changed the endpoint, or raised the price, the purchase stops here.
4. The buyer signs and settlesThe x402 V2 SDK and Solana Kit build the transaction. The gateway verifies, reserves a unique proof, and settles on Devnet.
5. The gateway marks the purchase as measuringgateway/store.js
   An atomic reservation moves quoted to settling before settlement. Successful settlement then moves it to measuring.
6. The device authenticates the requestfirmware/esp32/main/protocol/capmesh_dispatcher.c
   It rebuilds the canonical request string, checks the HMAC, checks the expiration, and checks the replay table. Rejection returns AUTH_INVALID, AUTH_EXPIRED, NONCE_CACHE_FULL, or BUSY.
7. The device samples GPIO9 five timesfirmware/esp32/main/capabilities/contact_capability.c
   Roughly 10 milliseconds apart. closed=true means GPIO9 reads low. stable_samples counts samples that match the first sample.
8. The receipt is signed and returnedThe device signs the canonical observation string with ECDSA P-256 and SHA-256. The v3: receipt fits a 512-byte BLE characteristic.
9. The buyer verifies the receiptgateway/buyer.js checks the pinned signature, buyer challenge, contact contract, and age. Failure stops the paid buyer.
10. The buyer derives the decisionOpen plus fresh plus authenticated produces DISPATCH. Closed, missing, stale, replayed, or invalid produces WAIT. Confidence stays null.

Where the flow deliberately breaks

Architecture

Components

Trust boundaries

• A manifest cannot establish its own identity. The buyer pins the device ID and P-256 public key through trusted USB provisioning.
• Physical observation receipts use the persistent private device key. The buyer rejects substitution with the public demo HMAC.
• Command authorization, simulated receipts, and legacy LED checks retain public demo HMAC. Command authorization is not private access control.
• The private device key resides in unencrypted NVS. Production needs protected storage and firmware integrity.
• The device timestamp derives from an authenticated host request and uptime. It is not independent time attestation.
• The receipt establishes what this firmware reports about its GPIO samples. It does not establish external physical truth.

The wire protocol

Envelope capmesh/0.1. Capability state.observe. Provisioned metric gate.closed. Provisioned location demo-gate. Sensor gpio9-contact.

Request

{
  "protocol": "capmesh/0.1",
  "request_id": "obs-00000001",
  "device_id": "esp32-c6-96a2",
  "capability": "state.observe",
  "parameters": {"location": "demo-gate"},
  "nonce": 1,
  "timestamp": 1790807040,
  "expiration": 1790807070,
  "authorization": {"type": "hmac-sha256-v2", "token": "64-lowercase-hex-characters"}
}

The two canonical strings

Both sides must produce byte-identical UTF-8 messages. Field names are replaced by values. Integers are decimal with no padding. JSON field order does not matter.

fieldproof-auth-v1|request_id|device_id|state.observe|location|nonce|timestamp|expiration

fieldproof-observation-v1|protocol|request_id|provider|capability|location|nonce|
metric|sensor|closed|stable_samples|total_samples|started_at|completed_at

closed is encoded as 0 or 1. Physical receipt signatures use v3: plus padded base64 of the 64-byte r || s P-256 signature. Simulated receipts retain v2: HMAC and simulated-contact. See the canonical protocol and identity provisioning.

The buyer acceptance rules

The paid buyer creates a new challenge per purchase. Gateway retries return the original receipt for the same purchase. The recorded inspector permits repeated inspection without claiming a new observation.

Fresh open evidence produces DISPATCH. Closed, missing, stale, or invalid evidence produces WAIT. Confidence stays null.

Device replay and concurrency

• BLE and HTTP share one dispatcher mutex and one replay table.
• The device keeps 64 nonce and expiration pairs. It never evicts an unexpired authorization to admit another request.
• A full table returns NONCE_CACHE_FULL. Concurrent dispatch returns BUSY.
• Reboot clears the table and the time anchor. The first authenticated request anchors epoch time to monotonic uptime.

Gateway endpoints

POST /requests

Create an immutable challenge and purchase ID.

GET /observe/:id

Return a 402 quote, or verify and settle a matching x402 V2 payment.

GET /manifest

Describe the single contact observation.

GET /demand

Summarize local purchase states.

GET /health

Identify the configured payment and evidence mode.

POST /simulate/:id

Simulated server only. Exercise the same purchase handler with fake settlement.

Payment and recovery

The gateway pins the network, the USDC mint, the merchant, the exact scheme, and 1,000 base units. It matches the payment resource to the stored purchase and checks every advertised requirement.

What is real and what is simulated

Proof uniqueness

• The gateway hashes the decoded signed transaction message and reserves it before settlement.
• The hash excludes signature bytes, because the facilitator can replace its signature without creating another payment.
• Signature variants cannot authorize a second purchase with the same signed message.
• Rewriting the resource JSON cannot authorize a second purchase with the same transaction message.
• Solana transaction signatures do not sign HTTP resource metadata. This gateway ledger enforces the purchase binding.

The seven purchase states

A retry returns the original receipt and marks it cached. It does not refresh the timestamp. The browser re-checks age and sets WAIT when the freshness window closes.

Buyer safety rails

• The client accepts only loopback endpoints.
• It rejects other networks, assets, recipients, and amounts above 0.001 USDC.
• It never prints key material.
• It re-reads the quote after payment and fails if the gateway changed the challenge, location, freshness limit, or endpoint.
• On any failure it preserves and prints the purchase ID for review.

What the device does

Verified results

See the canonical verification record for current test counts, commands, failures, and evidence limits.

Payment evidence

Transaction

4XSokajCzpoKy7bEQGF6NPpsvVLjo4Q5bSuH73hiuiXP23PbhuHN8pWeJ9fBxwjGk58iiv1Xqu5MTTmwQGggnBLw

Slot

506374923 · commitment confirmed · transaction_error: null

Mint

4zMMC9srt5Ri5X14GAgXhaHii3GnPAEERYPJgZJDncDU (USDC)

Merchant

CaQAKBcwf7G5vXeu2RNuNGJafnJ8724Uj4wv9ivfxfQA · delta +1000

Payer

2U7Bz5u4bVMsUtNcF4b4xdWG7K3N7WmbsGCqMQmjevMf · delta -1000

RPC check

https://api.devnet.solana.com, measured after the chain block

Purchase ID

3e063c69ce654ed1 · DISPATCH when verified on October 1

Receipt

gate.closed=false, 5/5 samples, buyer-pinned v3: P-256 signature

Inspect the recorded signed purchase. Open /proof on a local gateway to verify its signature and query the chain.

Human contact-state evidence

On October 2, separate BLE observations verified each state with the buyer-pinned P-256 key. No reset, output operation, or payment occurred.

Inspect both device-signed receipts. The older October 1 state checks retain historical HMAC signatures.

Video artifacts

Test suites

Python: uv run --project host pytest -q

The default run skips ten hardware tests. --hardware requires the board. Exact executed results live in VERIFICATION.md.

Node: cd gateway && npm test

Current counts and executed results live in the verification record.

Build history

These checkpoints preserve the MVP's development. Git history owns exact dates and diffs. Current verification appears above.

Threat model and limits

The product review in STRATEGY.md examines access rights, truth, remote delivery, economics, and demand quality. It concludes that one recurring buyer-provider workflow must be earned before an open sensor marketplace is worth building.

Five-minute demo script

1. Open the dispatch deskRun cd gateway && npm run demo, then open http://127.0.0.1:4022. The header shows SIMULATED PAYMENT · NO FUNDS MOVED.
2. State the questionA buyer requests one current contact state. BOOT supplies the real test input. No gate or robot connects to this prototype. Budget 0.001 USDC. Freshness ten seconds.
3. Request the quoteSelect Get payment quote. Show the 402 response with the exact amount, network, asset, and recipient. No evidence yet.
4. Complete the purchaseSelect Run simulation. Show the payment mode label, the receipt, and the DISPATCH decision with 5/5 agreement.
5. Show expiryWait eleven seconds. The desk flips to WAIT with Evidence expired. Explain that a cached receipt never becomes fresh on retry.
6. Run the adversarial loopIn another terminal run uv run --project host capmesh observe-demo --simulated. Show the cheaper stale provider rejected, the replayed answer rejected, the changed answer rejected, and the replayed device request rejected.
7. Inspect recorded paymentOpen /proof. Select Verify recorded payment. Explain that a chain read moves no funds and cannot refresh the expired receipt.
8. Break the receiptFlip its state, change its challenge, and use another key. Restore the original. Its valid signature still produces WAIT because it expired.
9. Close on the next testOne recurring buyer and authorized operator must establish the useful-time window, budget, reliability, and permission. Test counts and demand counters do not establish customer demand.

With real hardware in the demo

Restart with npm run demo -- --physical. Hold BOOT during the observation and show CLOSED and WAIT. Release BOOT, create a fresh quote, run again, and show OPEN and DISPATCH. Do not press Reset while you hold BOOT.

Repository map

Which document answers which question

Companion pages: interactive dispatch desk · diagnostics · MVP overview · demo runbook · verification record.

Deadlines and open items

Required fields