How OTV verifies an incoming payment

The client posts an incoming claim. The API authenticates the caller, selects a chain adapter, and walks a fixed status order. It does not skip from a seen transaction to spendable funds.

Steps the API actually runs

1. Receive the claim: chain, network, transaction hash, and recipient. An asset and an expected amount are optional.
2. Read the chain through a ChainAdapter. The engine does not build JSON-RPC itself.
3. Record OBSERVED, then PENDING, then EXECUTED when the transaction ran.
4. Check the asset and the recipient. Those are ASSET_CONFIRMED and the match evidence, not a balance.
5. Compare the balance change. BALANCE_CONFIRMED is not the same status as FINAL.
6. Apply the network's confirmation depth. FINAL means that depth was reached.
7. SPENDABLE is allowed only after FINAL, and only with the required evidence. Otherwise the verdict can be REJECTED, SUSPICIOUS, or UNVERIFIED.

The verdict schema id is otv.verdict.v1. The server signs the canonical payload with Ed25519. Clients verify the signature. They do not mint verdicts. The signed verification verdict is documented at /signed-verdict.

Related

Scan a transaction · Look up a verdict · Explore documentation · Download the Android app