← operator playbook
Jul 07, 20266 min read

Anatomy of a $5,000 cashier transaction, from tap to confirmation

Walk through every step of a real high-value cashier transaction — what the customer sees, what the system does, and what happens on-chain — in the exact order it happens.

operationsengineeringwalkthrough

It's easier to reason about the cashier by walking through one transaction, start to finish. Here's a $5,000 top-up by a returning customer on a US-facing operator.

T+0: intent

Customer taps 'top up' in the operator's app. The client makes a single call: create_intent(customer_id, amount=5000, currency=USDT, network=TRC20). The server responds with an intent ID and a fresh TRC20 address, derived on the fly. Nothing else is provisioned yet — the address exists in the operator's derivation index and in a watcher queue.

POST /intent
  amount: 5000 USDT
  network: TRC20
> intent_id: int_9c4a2
> address: TXf…7yq3
> expires_in: 900s

T+2 min: send

Customer opens their exchange wallet, pastes the address, sends 5,000 USDT. The wallet broadcasts. Fifteen seconds later the transaction is in the mempool. Twenty seconds after that it's in a block.

T+3 min: first sighting

Our TRC20 watcher sees the transaction one block after inclusion. It flags the intent as sighted and starts the confirmation counter. The customer sees a UI update: '1 of 3 confirmations'. Nothing has been credited yet.

T+4 min: confirmations complete

Three confirmations later, the watcher promotes the intent to confirmed. Two things happen in the same transaction on our side:

  1. 01The internal ledger records +5,000 USDT credited to the customer.
  2. 02The address is retired. It will not be handed out again, and the watcher stops polling it.

The customer sees their balance update. The operator sees the credit in their admin console with the transaction hash linked to a block explorer. Total elapsed time from tap to credit: roughly four minutes.

T+4 min: alert

A Telegram alert fires to the operator's ops channel: `[credit] customer 887a · +5,000 USDT · TXf…7yq3 · 3/3 conf`. If the operator has agents actively watching, they see the same event as the customer, in real time.

T+2 days: agent workflow

The customer plays for two days and cashes out $3,200. They request a withdrawal to a fresh TRC20 address of their choosing. The withdrawal request queues into the operator's payout batch. On the next scheduled payout window — same day for cashouts under threshold, next window for larger ones — the operator's treasury signer approves the batch, funds go out on-chain, the customer sees the transaction hash in their app.

T+5 days: settlement

At the end of the week, everything the operator processed — inbound top-ups, outbound cashouts, platform fees — is aggregated into a single statement. The operator's net position settles to their treasury wallet in one on-chain transaction.

The customer sees three transactions on their side (send, cashout, potentially a second cashout). The operator sees three ledger events. On-chain, there are three transactions with the operator, and one final settlement. Nothing else. No card networks, no acquirers, no rolling reserves, no chargebacks. That's the whole shape.

// related reading