Snapshot 1 — payout approval
Situation: submitted route points to the wrong chain for the approved payout request.
Result: BLOCK
Operational value: the transfer stops before release instead of becoming support cleanup or manual recovery work.
No-custody verification · live pre-send checks · pilot from $399/mo
Verify stablecoin payout destinations before funds move.
PayeeProof helps payout, treasury, and operations teams catch avoidable payout mistakes before approval. Run a live pre-send check, get one clear operational outcome — SAFE, BLOCK, REVERIFY, or TEST FIRST — and keep execution control with your team.
Stop avoidable payout errors
Keep operators in control
Store a verification record
Six networks live
Why teams buy
Decision layerCheck destination details before approval instead of relying on manual double-checks alone.
No custodyYour team keeps approval and execution control. PayeeProof adds verification, not fund handling.
Clear outputSAFE / BLOCK / REVERIFY / TEST FIRST gives operators one standard language for action and escalation.
Live coverageEthereum, Arbitrum, Base, Polygon, BNB Chain, and Solana. Public checker supports USDC and USDT.
Built first for payout approvals and exchange-like deposit review. Treasury release control can follow once the first workflow proves useful.
Reduce preventable payout incidents
Add a verification step where payout mistakes are still stoppable — before approval, before release, and before support tickets start multiplying.
Keep a clean operator workflow
Operators get a simple verdict, a destination class, and a next step instead of raw blockchain noise or vague tooling output.
Create an auditable record
Each result is built to look like a verification record your team can reference during approval, escalation, and post-incident review.
Best first fit
Start with two high-signal workflows, not a broad rollout.
The strongest first rollout is narrow: payout approval and exchange-like deposit review. Treasury release control can come next. Broad recovery programs, every-chain coverage, or all-purpose compliance tooling are not the right first promise for the current product.
Primary wedge: payout approvals
Use PayeeProof at the last operator pause before release, where one wrong network or destination detail is still stoppable.
Primary wedge: exchange-like deposit review
Use REVERIFY or TEST FIRST when the destination looks custodial, memo-sensitive, routing-dependent, or operationally ambiguous.
Good second wedge: treasury release control
Add one more verification step before funds move while keeping approval and execution in-house.
Not a first-fit promise
Do not sell the first rollout as a full incident-recovery program, a universal fraud suite, or support for every network and asset combination.
Representative workflow snapshots
What useful pilot signal should look like.
These are representative workflow snapshots, not named customer testimonials. They show the kind of operator signal a narrow pilot should produce in a live approval flow.
Snapshot 2 — exchange-like destination
Situation: address pattern looks custodial, memo-sensitive, or still depends on venue confirmation.
Result: REVERIFY or TEST FIRST
Operational value: the operator gets a clear pause signal instead of vague uncertainty or a false SAFE state.
Snapshot 3 — clean personal-wallet route
Situation: network, asset, address, and context line up cleanly and the destination looks operationally normal.
Result: SAFE
Operational value: teams keep approval moving with a readable proof record instead of ad-hoc reassurance in chat or email.
Use cases
Where PayeeProof fits in real teams and workflows.
The strongest starting point is narrow: payout approval and exchange-like deposit review first. Treasury controls and post-send recovery can stay secondary until the main workflow proves useful.
Payout ops
Use PayeeProof at the last approval pause before funds move, where one wrong detail turns into a preventable incident.
Exchange-like deposits
Use REVERIFY when a destination looks custodial, route-sensitive, or still needs extra confirmation.
Treasury controls
Add one narrow verification layer before release while keeping final approval and execution with the operator.
Recovery guidance
Keep post-send guidance as a secondary module for cases where something already went wrong and support needs a faster starting point.
Proof format
A verification result should read like a record, not a chatbot answer.
This page shows the record format the product is built around: a compact verification record with a stable verdict, reference, confidence level, destination class, and a clear next step.
What the record captures
Stable outcome languageSAFE, BLOCK, REVERIFY, or TEST FIRST — one clear status language for action and escalation.
Proof fieldsChecked at, confidence, reference, destination class, source, and next action.
Operational contextShort explanation for why the decision was returned and how an ops team should react.
ReviewabilityA result that can be used in a workflow, ticket, or approval log without rewriting it.
Format preview only. Signed records are produced inside controlled workflows.
Record id
ppf_demo_2026_03_24_001
Time checked
2026-03-24T19:12:08Z
Verdict
SAFE
System reference
OK
Confidence
High
Destination type
Personal wallet
Source
Live RPC lookup
Next action
Approve payout
Why this verdict
Network, asset, address, and memo checks matched. The destination classified as a personal wallet.
Before sending
Pre-Send Verification
Use this at the approval step before funds move. The service compares expected and provided transfer details, validates the address format, and runs a live lookup to classify the destination and return one operational verdict.
Run a live pre-send verification
Expected vs provided chain, asset, address, and memo/tag. The current public checker supports USDC and USDT across six live networks.
Live verification
Expected by payer
Provided by payee
Open example scenarios (optional)
These review scenarios stay available for inspection, but remain outside the main product path.
Ready for a live check.
READY
No verification record yet.
Run a live check to generate a proof-style result card. Pilot review scenarios stay available below if you need examples.
READY
Next step
Run live check
Time checked
—
Confidence
—
System reference
—
Why this verdict
Waiting for a live or pilot-review result.
Destination type
Unknown
Risk flags
—
Checks
Live verificationWaiting
After a mistake
Recovery guidance after a bad send
Use this after something already went wrong. Recovery is the secondary module: it looks up the live transaction and returns practical next steps based on the network, transaction status, recipient type, and issue type.
Analyze a real transaction
Paste a real transaction hash to get live status, recipient analysis, and practical recovery guidance across current live network coverage.
Live analysis
Recovery input
Optional hint. Leave this on Auto-detect if you are not fully sure what went wrong.
What the guide returns
StatusConfirmed / failed / not found / unavailable
What was detectedNetwork, status, recipient, transfer hints, and whether the recipient is a wallet, contract, or app
Recovery outlookPossible / manual review / unlikely / depends
Next actionsPractical steps for the user or support team
Recovery packetA copy-ready summary and support message built from the live result
Open recovery example
A single sample case stays available for review without turning the main page into a sandbox.
Ready to check a transaction.
READY
No transaction checked yet.
Paste a real transaction hash to see what likely happened and what to do next.
—
Quick answer
What this means
Run a check to get a clear answer.
Contact first
We will suggest the right contact path after a live check.
First step
Start with a live transaction lookup.
Recovery verdict
—
Recovery chance
—
Recipient type
—
Contact path
—
Detailed next step
—
On-chain status
—
Checked at
—
Confidence
—
Case reference
—
Why this result
Waiting for a live or pilot-review result.
Action plan
—
Support message
Run a check to generate a ready-to-send support message.
Recovery packet
Run a check to generate a copy-ready packet.
Security model
PayeeProof should be a control layer, not a new trust problem.
The safest version of this product is the one that explains its answer clearly, does not hold funds, and blocks mismatches instead of trying to guess through them.
No custody
PayeeProof does not hold funds and does not execute transfers. It exists to verify or analyze, not to move money.
Block when details do not match
If details are invalid, mismatched, or suspicious, the safe answer is block, reverify, or escalate — not “probably fine.”
Live network checks
Uses live blockchain lookups to identify the recipient type and analyze transactions instead of relying only on static form checks.
Integration flow
How PayeeProof fits into a payout workflow.
A short integration story is stronger than a wall of raw JSON: collect payout details, run the check, get one clear verdict, then approve, block, or escalate.
Step 1
User enters details
Network, asset, address, and memo or tag are collected before any transfer is approved.
Step 2
PayeeProof checks
The service compares expected vs provided details and runs a live destination lookup.
Step 3
Clear verdict
The result returns one public language standard: SAFE, BLOCK, REVERIFY, or TEST FIRST. UNAVAILABLE stays a system fallback, not a green-light state.
Step 4
Ops takes action
Approve the payout, stop it, re-confirm details, or ask for a small test transaction first.
Live today
Pre-Send verificationLive validation for network, asset, address, memo or tag, and destination classification.
Policy presetsPayout Strict, Deposit Review, and Treasury Review for clearer rollout fit.
Pilot intakeTeams can submit one workflow and get a practical pilot fit review through the request form.
Exchange-side verification still depends on direct partner integrations. Public chain checks and guided recovery are already live.
Technical overview (optional)
Public API positioning stays pre-send first. The technical page is there for teams that want request and response shape, record fields, and rollout boundaries without turning the main page into a developer manual.
Public API v1Pre-send first, with verification records and account endpoints for authenticated clients.
Recovery pathDocumented separately as a secondary module so the main offer stays focused.
Policy presetsPayout Strict, Deposit Review, and Treasury Review help align the decision layer to a real workflow.
Verification scenarios
Common outcomes, shown in one operational language.
These are the scenarios a payout or support team usually cares about first: match, mismatch, risky destination classes, and the recovery cases that need escalation instead of guesswork.
Pre-Send
SAFE
Wallet details match
Network, asset, and destination align, and the recipient looks like a personal wallet rather than an ambiguous service endpoint.
Pre-Send
BLOCK
Wrong network or invalid address
The safest answer is to stop immediately when the address format fails or the provided network does not match the intended route.
Pre-Send
REVERIFY
Exchange-like deposit destination
Some addresses behave more like service endpoints than self-custody wallets. They should be confirmed before a full transfer is approved.
Pre-Send
REVERIFY
Contract or app destination
Funds may technically arrive, but recoverability and ownership depend on contract logic, permissions, and whether the destination was truly intended.
Recovery
NOT FOUND
Transaction hash not found
When the lookup cannot find the transaction on the selected network, the right move is to verify the hash and chain first instead of improvising recovery steps.
Recovery
MANUAL REVIEW
Missing memo or ambiguous recipient
Some failures are not solved by chain data alone. Service-side records, support workflows, or destination-owner confirmation may still be required.
Pricing & pilot packages
Start with a narrow pilot, then expand only if the workflow proves useful.
The strongest commercial path is usually not a giant rollout. It is a defined workflow, a reviewable decision layer, and a clear next step after teams review real records, policy examples, and trust boundaries.
Pilot evaluation
Best for one workflow, one operational pain point, and one success criterion. Good for a fast review.
Custom integration
Best for teams that already know the workflow and want policy, verdicts, and outputs aligned to real operations.
Enterprise path
Best for broader operational usage, repeated verification, and a longer-term commercial relationship.
Pilot
Request a pilot
Use the form to describe the payout flow you want to protect. Share enough detail for a serious fit review and a clear next-step recommendation.
Best fitPayout approvals, exchange-like deposit review, and treasury release control.
What to includeNetworks, assets, destination types, where mistakes happen today, and what decision your team needs before approval.
Pilot review outputA practical fit check, an initial pilot direction, and clear next steps.
Request pilot
Use a work email and include enough context for a serious fit review, not just a one-line intro.