← Back

Ch.02 · What I check

Seven rails. Five assertions each.

Every asset settles differently, so every asset gets its own state machine and its own assertions. Pick a rail and watch it run, then see which surfaces have been taken through which layers — and what each one does when the network stops behaving.

Five states of a Bitcoin payment — invoice created, broadcast, one confirmation, three confirmations, settled — each with the assertion that has to hold there.
One rail, five states, an assertion at each. Six more rails behind it, each settling differently.
Ch.02Pick a rail

Every asset fails differently.

Three rails. Three state machines. Three ways to lose money. Pick one and watch what I assert at each step.

Bitcoin · on-chain

BTC

Known risk — Slow finality, reorg risk

  1. Invoice created

    Amount and address match the order; invoice has an expiry

  2. Broadcast

    Transaction accepted to mempool; fee rate above the floor

  3. 1 confirmation

    Order stays pending. One confirmation is not settlement

  4. 3 confirmations

    Status flips to paid exactly once, even on a replayed webhook

  5. Settled

    Ledger row and API response agree on amount, asset and timestamp

Lightning Network

LN

Known risk — Instant, but invoices expire

  1. Invoice created

    Payment hash unique; expiry short enough to price-protect

  2. Route found

    Insufficient liquidity surfaces as a retry, not a failed order

  3. In flight

    Checkout holds state, with no double-submit while the HTLC is pending

  4. Preimage received

    Preimage verifies against the payment hash before crediting

  5. Settled

    Expired-mid-checkout path issues a fresh invoice, not a silent fail

Ethereum · native

ETH

Known risk — Gas, nonces, reverts

  1. Quote locked

    Rate held for the quoted window; drift past tolerance rejects

  2. Tx submitted

    Nonce sequencing correct; gas estimate survives a busy block

  3. Mined

    Receipt status is 1. A mined revert is not a payment

  4. Confirmed

    Reorg below the confirmation depth does not credit the account

  5. Settled

    Amount credited net of gas, matching the ledger to the wei

Tether · ERC-20

USDT

Known risk — Token transfer, not native

  1. Deposit address issued

    Address derived for this account only; never reused across users

  2. Transfer event

    Transfer log parsed from the right contract, not a lookalike token

  3. Decimals applied

    Six decimals, not eighteen. The classic off-by-10¹² bug

  4. Confirmed

    Zero-value and self-transfer events are ignored

  5. Settled

    Credited balance reconciles against the on-chain balance

Tether Gold

XAUT

Known risk — Tokenised commodity

  1. Quote locked

    Gold price feed fresh; a stale feed blocks the quote

  2. Transfer event

    Fractional units handled, because gold trades in fractions of an ounce

  3. Confirmed

    Rounding never favours the house or the customer silently

  4. Converted

    Swap to fiat or stablecoin matches the locked quote, fees itemised

  5. Settled

    Ledger, statement and API all report the same unit and precision

Smart contract

ABI

Known risk — Contract calls and events

  1. Call encoded

    ABI encoding matches the deployed contract, not a stale artefact

  2. Simulated

    Dry run catches the revert before a real transaction pays gas

  3. Executed

    Emitted events carry the values the UI is about to display

  4. Access checked

    A non-owner calling a privileged method reverts, every time

  5. Settled

    Contract state, event log and our database tell the same story

Crypto payout

OUT

Known risk — Money leaving. The scary one

  1. Payout requested

    Destination address checksum-valid for the chosen chain

  2. Address verified

    Unverified address is refused. No exceptions, no override path

  3. Approved

    Balance and limits checked at approval, not just at request

  4. Broadcast

    A retried request never broadcasts twice for one payout id

  5. Settled

    Audit trail records who approved it, when, and to where

Where the money actually goes

Four hops between a customer paying and a merchant being paid. Each one is a place to lose it.

  1. 1

    Payer

    wallet or card

    Amount and asset match the invoice before anything is signed

  2. 2

    Rail

    chain or Lightning

    Broadcast confirmed, and confirmations counted for that asset

  3. 3

    Ledger

    our record

    One row per payment, written exactly once, reconciled on read

  4. 4

    Payout

    merchant out

    Destination verified, approval recorded, retry never double-sends

Ch.03Coverage & conditions

Breadth, then depth.

Which surfaces I have taken through which layers, and what each one does when the network stops behaving.

What I have taken through which layer

33 of 50 cells

UIAPIDBPerfSecurity
Merchant checkout
Merchant checkout UI covered
Merchant checkout API covered
Merchant checkout DB covered
Merchant checkout Perf covered
Merchant checkout Security not claimed
Payment links
Payment links UI covered
Payment links API covered
Payment links DB covered
Payment links Perf not claimed
Payment links Security not claimed
Refunds
Refunds UI covered
Refunds API covered
Refunds DB covered
Refunds Perf not claimed
Refunds Security not claimed
Instant payout
Instant payout UI covered
Instant payout API covered
Instant payout DB covered
Instant payout Perf covered
Instant payout Security covered
Swap
Swap UI covered
Swap API covered
Swap DB covered
Swap Perf not claimed
Swap Security not claimed
Transfer
Transfer UI covered
Transfer API covered
Transfer DB covered
Transfer Perf not claimed
Transfer Security not claimed
Cashback
Cashback UI covered
Cashback API covered
Cashback DB covered
Cashback Perf not claimed
Cashback Security not claimed
KYB / KYC onboarding
KYB / KYC onboarding UI covered
KYB / KYC onboarding API covered
KYB / KYC onboarding DB covered
KYB / KYC onboarding Perf not claimed
KYB / KYC onboarding Security covered
Smart contract calls
Smart contract calls UI not claimed
Smart contract calls API covered
Smart contract calls DB not claimed
Smart contract calls Perf not claimed
Smart contract calls Security covered
Withdrawals
Withdrawals UI covered
Withdrawals API covered
Withdrawals DB not claimed
Withdrawals Perf covered
Withdrawals Security not claimed

Blank means not claimed — a coverage grid that is all filled in is a lie

The same checkout, five network conditions

drag the dial

200mshealthy

Checkout completes

Nothing to catch here. This is the only state most suites ever test.

the assertion
Happy path passes. Necessary, and nowhere near sufficient

Next

How I keep up →

That does not scale by hand. The second half of this job is tooling, and knowing which tool to reach for.