Best first fit
Payout approvals and exchange-like deposit review are the two strongest starting workflows because they create clear operator decisions before funds move.
Pilot pack · what it checks · what is in scope today
Pre-send verification for stablecoin payouts.
Stop wrong-network and wrong-destination mistakes before funds move. This pilot pack shows what PayeeProof checks, what results it returns, what is supported today, and how a pilot fits into a payout workflow. The primary operator outcomes are SAFE, BLOCK, REVERIFY, and TEST FIRST; UNAVAILABLE remains a system fallback when live lookup does not complete.
Ideal for payout teams, exchange-like deposit review, marketplaces, and treasury operations. Not included by default: broad custom rollout, expanded policy logic across many workflows, or recovery-heavy support programs.
Pre-send verification
Six live networks
Reason-code driven outputs
Main questionCan this stop preventable payout mistakes before funds move?
Primary operator outcomesSAFE · BLOCK · REVERIFY · TEST FIRST
System fallbackUNAVAILABLE when live lookup does not complete
Primary use casePre-send verification before approval, release, or manual payout
Current live scopeEthereum, Arbitrum, Base, Polygon, BNB Chain, Solana
Integration styleSimple API call before release, approval, or manual payout
Pilot postureEmail-first, narrow scope, live checks, clear limitations
Best first fitOne payout workflow, one operator pain point, one success metric
Pre-send endpoint
1
Primary outcomes
4
Pilot intake
Live
Networks today
6
Best first fit
The strongest pilot is narrow and operator-visible.
Good second step
Treasury release control can follow once the first workflow proves useful and the record format is already accepted operationally.
Not the first promise
Do not treat the base pilot like a universal fraud suite, a broad recovery program, or a guarantee across every chain, asset, and partner flow.
What the product checks
One focused module with a narrow operational job.
Pre-Send Check
Used before approval, release, or manual send. It is designed to catch preventable routing mistakes while the transfer is still stoppable.
Network matchCompares expected and provided chain.
Core
Asset matchChecks whether the submitted asset matches the approved route and is in supported scope.
Core
Address validityValidates format and blocks obvious failures such as invalid or zero address.
Core
Memo or tag alignmentFlags memo-sensitive deposit flows where a missing or mismatched memo can break crediting.
Context
Destination classificationLabels destination as personal wallet, contract or app, exchange-like deposit, bridge-router, unknown, or unavailable.
Live lookup
Operational next stepReturns the action language a workflow can use immediately: proceed, block, re-verify, or test first.
Output
Verdict language
Simple outputs first. Details stay in the result and next steps.
| Pre-send verdict | Meaning | Typical action |
|---|---|---|
| SAFE | Core details match and the destination looks like a normal personal-wallet style route. | Approve and keep the proof record. |
| BLOCK | The route is wrong, unsupported, invalid, or operationally unsafe to approve. | Stop the transfer and re-verify the request. |
| REVERIFY | Core details may match, but deposit-style or unclear destination context still needs a human confirmation. | Pause and re-check venue, memo, or destination context. |
| TEST FIRST | The destination looks like infrastructure, a contract, an app, or a bridge-router flow. | Use a small test before any full send. |
| UNAVAILABLE | Live destination lookup did not complete, so the result should not be treated as final approval. | Retry or send to manual review. |
What sits next to the verdict
reason_codeShort explanation that helps the team route the case correctly.
confidenceSignals whether the response should be treated as straightforward or conservative.
destination_typePersonal wallet, contract or app, exchange-like deposit, bridge-router, unknown, or unavailable.
checked_at / trace_idGives operators a traceable proof block for review and audit.
next_actionApprove, block, re-verify, test first, or route to manual review.
The goal is not false precision. The goal is one clear operational answer before funds move, with enough structured context to justify that answer.
Reason codes
Stable machine-readable labels, with plain-English meaning for operators.
| Pre-send reason code | What it means |
|---|---|
| OK | Route matched and looks safe enough to proceed. |
| NETWORK_MISMATCH | Provided network does not match the approved route. |
| ASSET_MISMATCH | Provided asset does not match the approved route. |
| ADDRESS_MISMATCH | Provided destination differs from the approved destination. |
| MEMO_MISMATCH | Memo or tag differs from the approved route. |
| INVALID_ADDRESS | Address format failed validation for the selected network. |
| ZERO_ADDRESS | Destination is the EVM zero address and must be blocked. |
| DESTINATION_IS_BRIDGE_ROUTER | Destination looks like bridge or router infrastructure. |
| DESTINATION_IS_CONTRACT_OR_APP | Destination looks like a contract or app rather than a personal wallet. |
| DESTINATION_REQUIRES_MEMO_OR_VENUE_CHECK | Destination looks like a deposit-style route that may depend on venue and memo. |
| DESTINATION_NOT_CLASSIFIED | Core details matched, but live classification stayed inconclusive. |
| DESTINATION_LOOKUP_UNAVAILABLE | Live destination lookup did not complete. |
| UNSUPPORTED_NETWORK | Selected chain is outside current supported scope. |
| UNSUPPORTED_ASSET_OR_NETWORK | Asset-network combination is outside current supported scope. |
How result labels are meant to be used
Allow
OK supports a controlled SAFE outcome.Block
NETWORK_MISMATCH, ASSET_MISMATCH, ADDRESS_MISMATCH, INVALID_ADDRESS, and ZERO_ADDRESS stop the transfer.Re-check
MEMO_MISMATCH and DESTINATION_REQUIRES_MEMO_OR_VENUE_CHECK push the case into human confirmation.Test first
DESTINATION_IS_BRIDGE_ROUTER and DESTINATION_IS_CONTRACT_OR_APP keep operators from treating infrastructure routes like personal wallets.Fallback
DESTINATION_NOT_CLASSIFIED, DESTINATION_LOOKUP_UNAVAILABLE, and unsupported-scope codes prevent fake green lights.These labels are meant to stay stable enough for workflow routing, support playbooks, and clear operational handling during the pilot.
Supported scope
What is live today, and where the scope is intentionally narrow.
| Network | Current asset support | Notes |
|---|---|---|
| Ethereum | USDC, USDT, DAI, USDS, PYUSD | Pre-send verification is in current pilot scope. |
| Arbitrum | USDC, USDT, DAI, USDS | Pre-send verification is in current pilot scope. |
| Base | USDC, USDT | Pre-send verification is in current pilot scope. |
| Polygon | USDC, USDT | Pre-send verification is in current pilot scope. |
| BNB Chain | USDC, USDT | Pre-send verification is in current pilot scope. |
| Solana | USDC, USDT | Pre-send supports Solana address validation and route checks. |
Endpoints available in the current pilot
GET /health
POST /api/preflight-check
POST /pilot-request
The public website demo stays narrower than the live product. It focuses on the clearest product story first.
Where the pilot stays intentionally conservative
exchange-like deposit
memo-sensitive route
contract or app
bridge-router
lookup unavailable
The pilot is designed to stop false confidence. Some routes should land in REVERIFY, TEST FIRST, or UNAVAILABLE instead of being forced into SAFE.
Integration scenario
How a pilot fits into a real payout or support workflow.
Step 1
Workflow identifies a check point
Usually the last pause before release, approval, or manual payout execution.
Step 2
Client sends a narrow request
Expected-versus-provided payout details are sent for a narrow pre-send decision.
Step 3
PayeeProof returns action language
Verdict, reason code, confidence, traceable proof block, and next action.
Step 4
Client routes the case
Approve, block, re-verify, use a small test, or route to manual review.
Where it usually lands first
Payout opsUse pre-send check before release.
TreasuryAdd a lightweight approval control without changing custody.
Support or customer opsUse the same verdict language during manual payout review or customer-confirmation flows.
Risk or compliance opsKeep the proof block and result labels for workflow evidence.
What the integration is not
Not a custodianPayeeProof does not move or hold funds.
Not a wallet replacementExecution stays with the operator or client workflow.
Not a universal guaranteeReason codes and guidance help reduce mistakes, but cannot override partner-side platform rules.
Not an infinite scope pilotThe pilot stays intentionally narrow so teams can judge the product on a real workflow.
What is included in the pilot
Pilot — $399 / month
For teams that want to validate PayeeProof in one live payment workflow before broader rollout.
Included
1 workflowOne defined payment or destination-check flow.
1–2 networksKeep the pilot narrow and operationally clear.
Up to 1,000 checks / monthEnough for a controlled live pilot.
Up to 2,000 record reads / monthReview results and history during the pilot.
Operational setup
Verification recordsEach completed check can be reviewed as a structured result.
Basic webhook deliverySend key events into the client workflow.
Email-based onboardingStart without requiring a kickoff call.
Standard supportPractical help during the pilot window.
What is not included
No mandatory setup feeThe standard Pilot does not require a separate implementation fee.
No broad rollout promiseExpanded rollout is quoted separately when the scope grows.
No feature sprawlThe Pilot is intentionally limited so teams can judge it on one real workflow.
Current limitations
What is deliberately not over-claimed in the current pilot.
Scope is selective
Only the currently supported networks and asset combinations are in scope. Anything else should be treated as unsupported, not hand-waved into a false green light.
Not every route should become SAFE
Exchange-like deposits, memo-sensitive flows, contracts, apps, bridge routes, and lookup failures should stay conservative instead of being forced into a false green light.
Destination classification can stay conservative
Some destinations will still land in REVERIFY, TEST FIRST, or UNAVAILABLE. That is intentional. The product should stop bad certainty, not manufacture fake certainty.
Advanced rollout work is separate
The standard Pilot covers a narrow live workflow. Broader setup, deeper customization, or expanded rollout work is quoted separately.
Dedicated admin tooling is not the Pilot
The Pilot is focused on live checks, records, and practical workflow decisions. Broader admin tooling can be discussed if the rollout expands.
Human review still matters
Some flows, especially exchange-like deposits, platform-specific memo rules, and app-owned destinations, still need a support or operations decision even after the API response.
Bottom line
PayeeProof is strongest as a focused pre-send verification layer for stablecoin payouts. It helps teams stop preventable transfer mistakes before execution with narrow scope, live checks, and explainable outputs.