Payout Strict
Best for teams that only want to approve clear personal-wallet style routes. Ambiguous destinations should stop and go back for re-verification.
Decision examples for payout operations
How PayeeProof turns ambiguous payout checks into clear operator decisions.
This page is not a raw API dump. It shows the practical decision layer: what each verdict means, how destination types are classified, and how an ops team can read a structured verification record without translating blockchain jargon first.
SAFE · BLOCK · REVERIFY · TEST FIRST
Personal wallet / contract / exchange-like / bridge-router / unknown
Readable for ops and treasury
Preset policy profiles
Primary jobReduce bad approvals before funds move
Decision styleReadable verdict + reference + next action
Destination classesPersonal wallet, contract, exchange-like deposit, bridge-router, unknown
Workflow fitOps review, payout approval, support escalation, audit trail
Human roleEscalate only when the case is not clearly safe
Decision policy
Verdicts are designed for action, not for technical theater.
Each verdict is paired with a practical bias: approve, block, verify again, or require a small live test before releasing a larger payout.
Low-friction approvalSAFE
Approve when the target looks consistent with the intended destination.
Typical triggerWallet match, expected network, no obvious destination mismatch.
Operator actionProceed with the payout using the confirmed target.
Why it existsTeams need a positive approval state, not only warnings.
Hard stopBLOCK
Block when the payout target is clearly wrong or invalid.
Typical triggerWrong network, invalid address, unsupported asset, obvious mismatch.
Operator actionDo not send. Reconfirm destination details from the source of truth.
Why it existsSome cases do not need debate. They need prevention.
Needs confirmationREVERIFY
Reverify when the destination is reachable but context is incomplete or risky.
Typical triggerContract destination, unclear ownership, unusual routing path, incomplete context.
Operator actionPause and obtain a fresh confirmation before release.
Why it existsIt catches cases that are not broken, but are not comfortable enough to approve blind.
Caution with live fundsTEST FIRST
Require a small live test when the destination may be valid but still sensitive.
Typical triggerExchange-like deposit address, bridge-router path, high-value first-time payout.
Operator actionSend a minimal test amount first, then confirm receipt before full release.
Why it existsIt converts uncertainty into a controlled operational step.
Destination classification
Destination classes should sound like operations, not like a blockchain forum.
ClassPersonal wallet
A direct wallet destination controlled by an end user or treasury wallet with no obvious exchange-style deposit behavior.
ClassContract destination
A smart contract or program destination. It may be valid, but usually deserves a pause unless the contract is explicitly expected.
ClassExchange-like deposit
A destination that behaves like a custodial deposit endpoint. It may work, but teams should often test small before sending size.
ClassBridge-router
A routing or bridge-related destination where the operational path matters as much as the raw address itself.
ClassUnknown
The destination is syntactically valid, but context is insufficient for a comfortable approval.
ClassInvalid or mismatched
The address, network, or asset relationship does not support sending. This is a stop state, not a discussion state.
Policy presets
Three practical starting profiles for real workflows.
Deposit Review
Best for exchange-like deposit flows where venue, memo, or route context often matters more than a simple wallet/not-wallet split.
Treasury Review
Best for finance and treasury teams that want a cautious operational review before release without pretending every route is equally safe.
Structured examples
Example records, written the way a payout team would actually consume them.
Example 01SAFE
Wallet match on intended network
The payout target matches the expected wallet pattern and no major mismatch is detected.
Example 02BLOCK
Wrong network selected for a valid address
The address may exist elsewhere, but the current chain context is inconsistent with the intended transfer.
Example 03REVERIFY
Contract destination instead of a direct wallet
Funds may land somewhere real, but the destination type introduces enough ambiguity to require a fresh check.
Example 04TEST FIRST
Exchange-like deposit destination for a first-time payout
The endpoint may be legitimate, but the safest move is to confirm with a small live send first.
Example 05BLOCK
Invalid address or unsupported target format
The target cannot safely receive the intended transfer in the current context.
Example 06NOT FOUND
Recovery review with no on-chain transaction found
Recovery mode can only reason from a real transaction anchor. If the hash is absent, the team needs a valid one before analysis.
Review notes
What these examples are meant to communicate during a real rollout.
Readable outside engineering
Policy examples should help an ops or treasury lead understand the decision logic without needing to interpret raw chain terminology first.
Operational, not legalistic
These examples describe practical handling states. They are designed to guide action in a workflow, not to pretend every payout can be reduced to a legal guarantee.
Strict where needed
Wrong-network or invalid-format cases should look unapologetically blocked. That sharpness is part of the value.
Cautious where ambiguity remains
When a destination may be valid but context is incomplete, PayeeProof should visibly prefer re-verification or a small test over false certainty.