How it works
From a payout file to a signed-off result.
Six steps, most of them automatic. You say what you meant to pay; PayoutGuard reads the blockchain and shows you, row by row, what actually happened.
The steps
Step 01
Add the wallet that pays
Add the public address your payouts come from. PayoutGuard watches it; it does not prove you own it and never needs to.
- Public address only
- No signature, no connection request
- More wallets on paid plans
Step 02
Describe the payout run
Create a batch: the network and token, the paying wallets, and the time window the payouts were sent in.
- USDC on Base
- A UTC window with a start and an end
- An optional reporting period and reference
Step 03
Upload what you meant to pay
A CSV with a payout ID, recipient and amount per row, or the same rows through the API. Every row is validated before anything is stored.
- Download the template from the app
- Mixed-case addresses must pass their checksum
- Each upload becomes a new, immutable revision
Step 04
PayoutGuard reads the chain
Read-only queries collect every transfer of the token from your wallets in the window, then a second pass re-reads it once the blocks are finalized.
- Complete coverage of the window
- Finality tracked per chain
- Reorganisations detected and repaired
Step 05
Every row gets a status
Each expected payout is matched to the transfer that paid it. What does not match becomes an exception with the evidence that explains it.
- Verified only when final and fully scanned
- Missing, underpaid, overpaid, duplicate, wrong token
- Transfers that match no row are listed too
Step 06
Review, sign off and export
Your team records what happened with each exception, signs off the run, and exports CSV or PDF reports with their checksums.
- Dispositions with reasons
- Sign-off once everything is accounted for
- Monitoring keeps watching afterwards
Why finality matters
Confirmed is not the same as settled.
A blockchain can briefly disagree with itself. A transfer you saw a minute ago can disappear if the block it was in is replaced. Once a block is finalized, that can no longer happen.
ProvisionalPaid, not final
The transfer exists, but its block can still change. PayoutGuard re-checks automatically and promotes the row once the block is finalized.
VerifiedPaid and final
The right amount reached the right recipient, in a finalized block, and every block of the window was read.
Scan incompleteNot enough data yet
Part of the window could not be read. Nothing is assumed: verify again once the data is available.
Verify your next payout run free.
No card, no keys, nothing to install.



