State Machine: PayOut
State Machine: Payout
The Payout state machine describes the lifecycle of a payout operation from acceptance to on-chain completion. Some steps may be skipped depending on the blockchain network.
Payout lifecycle
BTC-family networks (BTC, LTC, DOGE, BCH, DASH)
queue
sending →
in_mempool →
confirm_check →
paidEVM networks (ETH, BSC, Polygon, Arbitrum, Base, Optimism, Avalanche, etc.)
queue →
sending →
broadcasting →
confirm_check →
paidOther networks (TRON, TON, XRP, SOL, etc.)
queue →
sending →
confirm_check →
paidWith gas refuel — EVM networks
With gas refuel — other networks (TRON, TON, SOL, XRP)
When the source wallet does not have enough native currency to cover gas fees, the platform performs a gas refuel before sending. In this case the lifecycle includes additional steps:
State descriptions
queue- Payout request accepted and queued for processing.refueling- Gas refuel transaction sent to prepare the source wallet. Waiting for on-chain confirmation. Does not apply to BTC-family networks.refuel_confirmed- Gas refuel confirmed. The payout transaction will be sent next. Does not apply to BTC-family networks.sending- Payout transaction is being broadcast to the blockchain.broadcasting- Transaction is queued in the EVM async pipeline, waiting to be broadcast to the network. The platform polls the pipeline until the transaction appears in the mempool. EVM networks only.in_mempool- Transaction is visible in the mempool, waiting to be included in a block. BTC-family networks only.confirm_check- Transaction included in a block, waiting for the required number of confirmations.paid- Payout completed and confirmed on-chain. Final success state.system_fail- Payout failed. Seeerror_reasonin the response for details. Final failure state.
BTC-Family Networks
BTC-family networks (BTC, LTC, DOGE, BCH, DASH) use the UTXO transaction model. Key differences:
No gas refuel. Transaction fees are included in the transaction itself, so
refuelingandrefuel_confirmedstates are never used.Mempool phase. After broadcast, the transaction enters the mempool (
in_mempool) before being mined into a block. This phase can last from minutes to hours depending on network congestion and fee level.Longer timeouts. Confirmation times are significantly longer than other networks.
Timeouts
Broadcasting (pipeline)
10 minutes
-
-
Mempool wait
-
-
24 hours
Transaction confirmation
30 minutes
30 minutes
6 hours
If a timeout is exceeded, the operation transitions to system_fail.
Callbacks
A webhook callback is sent when the operation reaches a final state (paid or system_fail).
Idempotency
Requests with the same order_id are idempotent — submitting the same payout twice returns the existing operation without creating a duplicate.
Webhook delivery rules and guarantees are described separately in the PayOut Webhook section.
Last updated