Pilot review page · workflow first

How a PayeeProof pilot fits into a payout workflow without rebuilding the stack.

This page is for teams that want one practical answer: what goes into a pilot, what PayeeProof returns, and how a verification result can slot into payout, risk, support, or treasury operations.

See pilot flow Open pilot outline Open onboarding checklist Open pricing & packages Open policy examples

Email-first pilot start

Pre-send + recovery

Readable record

Low-friction integration

Pilot entryWorkflow brief or live use case

Main outputSAFE · BLOCK · REVERIFY · TEST FIRST

Stored artifactStructured verification record

Operational usersOps, support, treasury, risk

Escalation modelHumans only when needed

Review styleCommercial main site + compact tech page

Pilot flow

Four steps from intake to operational action.

Step 1

Team sends context

The team shares the payout or recovery use case, expected route, and the operational point where a verification answer is needed.

Step 2

Live verification runs

PayeeProof checks network, asset, address format, destination class, and transaction context where relevant.

Step 3

Verdict + record returned

The system returns a clear operational verdict plus a structured record suitable for workflow logs or support review.

Step 4

Escalate only when needed

Teams only spend manual time on BLOCK, REVERIFY, TEST FIRST, recovery, or partner-specific edge cases.

What goes in

Pilot inputs stay narrow and practical.

Pre-send review

expected networkThe chain the payout is supposed to use.

expected assetThe token or stablecoin expected for the route.

provided addressThe destination the user or workflow is trying to use.

optional memo / tagUseful for destinations that require it.

context fieldsOnly if the team needs custom workflow routing or logging.

Recovery review

chainThe chain where the transaction actually happened.

tx hashThe anchor for real post-error analysis.

issue typeWrong network, wrong address, unsupported route, or similar.

intended routeHelpful when the user meant to send somewhere else.

operator notesOptional, for support teams handling escalations.

What comes back

A verdict for action, plus a record for traceability.

verdict

SAFE / BLOCK / REVERIFY / TEST FIRST

reason_code

Stable label for logs and policy routing

confidence

Quick summary layer for nuanced cases

destination type

Personal wallet / contract / exchange-like deposit / bridge-router / unknown

why this verdict

Human-readable explanation for ops and support

checked_at

Timestamp suitable for audit-style review

Operational outcome

SAFEApprove the payout when expected details and destination class align.

BLOCKStop before funds move when the route is clearly wrong or invalid.

REVERIFYPause and confirm when a human check is the safer next action.

TEST FIRSTUse a small test for exchange-like or route-sensitive destinations.

Open verification record Open record JSON

Compact API view

Enough for review, without turning this into developer docs.

Endpoints in the current pilot surface

GET /healthService health and configured network visibility.

POST /api/preflight-checkPre-send verification for payout approval workflows.

POST /api/recovery-copilotTransaction-anchored post-error guidance.

POST /pilot-requestPilot intake for workflow review and setup planning.

Request shape examples

Open compact request examples

POST /api/preflight-check
{
  "network": "ethereum",
  "asset": "USDC",
  "address": "0x1111111111111111111111111111111111111111"
}

POST /api/recovery-copilot
{
  "chain": "polygon",
  "tx_hash": "0x..."
}

Pilot next step

Review the main site for positioning. Use this page when the team wants the workflow in plain English.

A clean review path is simple: main site for the commercial story, verification record for trust, technical overview for compact field logic, and this page for the actual pilot flow.

Request pilot on main site Open pilot form Open technical overview