Skip to content

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

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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.

Start verifying payouts