Sends - approving, following and settling payouts

Admin → Convert → Sends (/admin/convert/send). Viewing needs view.convert.send; approving, confirming, cancelling and reversing need manage.convert.send, which no role holds until you grant it.

A Send is a convert whose output the house pays on-chain, from its own address, to an address the user gave. By the time a Send appears here the ledger has already moved: the user's input went to the house and is held there, the house's ledger of the target fell by the gross amount, the fee landed, and the gross is reserved on the house's inventory of that chain. The user was never credited the target and no withdrawal row exists, so no generic refund action can touch a Send. Only this engine settles it.

The states

What the jobs do on their own

Both jobs run every 30 seconds and keep running while the addon is disabled or unlicensed: the user's value is already held, and these are what deliver it.

The payout job claims each PLANNED Send with a conditional update (so two runners can never pay one Send) and has the ecosystem addon pay it from the house's own address on that chain, never the master and never a customer's. Under a signer lock per chain and signing address, every transaction is recorded before it is broadcast: its hash, its nonce or blockhash or expiration, its signer. If that record cannot be written, the transaction is not sent. A crash after a broadcast therefore always leaves a hash to check, never a blind retry.

A refusal before anything reached the chain is sorted:

• transient (a provider rate limit, a chain addon answering 503, the signer busy, a house shortfall): retried with backoff from 15 seconds up to five minutes, for convertSendRetryMinutes (default 10) after the first attempt, then failed and reversed in full;
• caused by the destination (code at a native EVM address, a Solana account below rent): failed, reversed at the worse rate, the fee kept;
• invalid (a validation refusal): failed, reversed in full;
• anything else after a broadcast: NEEDS_REVIEW. Never retried.

The confirmation job asks the chain about every SENT and SENDING Send, and every Send in review that has a hash:

• Confirmed as the transfer asked for: booked in one transaction. The house's trackers on that chain fall by what left its address (plus its own gas on native EVM and SOL), the house's ledger gets back the difference between the gross it gave up and that figure (the network fee margin, which is the house's), gas the master paid for a token transfer is recorded as a record-only CONVERT_HEDGE cost against the house, the user's input hold is released to the house, the reservation is spent. Send CONFIRMED, order COMPLETED. When the house's own key burned more gas than the network fee charged, the difference comes off the house's ledger and is a house cost in the Profit & loss, with no admin_profit row.
• Confirmed but not as asked, or with nothing to book: NEEDS_REVIEW. Never booked or reversed automatically.
• Mined and moved nothing (a revert): failed and reversed.
• Not seen for 30 minutes after broadcast: NEEDS_REVIEW.

It also retries every reversal that has not landed yet, and alerts the admins who can act (in-app, high priority, once per Send and state) when a payout reverts, when a Send goes to review, and when one has waited for approval for more than ten minutes.

The approval queue

A Send paid from a Spot balance runs the Spot withdrawal controls, including approval: when Auto-Approve Withdrawals (System → Settings → Wallet, withdrawAutoApprove) is off (the platform's default is manual), the Send waits here as AWAITING_APPROVAL. The house holds the price while it waits; the exposure was taken at execute and hedging covers it like any other.

• Approve releases it to the payout job, and records you as the approver.
• To refuse it, Reverse it. Nothing was ever signed, so the confirmation is the Send's own id typed back, and the user gets back everything they paid.

A Send paid from an Ecosystem balance is never held: Ecosystem withdrawals have no approval setting.

The review queue

A Send lands here when only a person can settle it: the chain did not say whether the payout landed, it confirmed something other than what was asked, or a failed payout's reversal is pending. Open one to see its figures, every transaction it recorded before broadcasting (under Signed before broadcast), and the actions open for it now.

Confirm sent books the payout with the transaction ID you found on the explorer. It must be a hash this Send recorded before broadcasting (the dialog lists them), and the chain must confirm it as this Send's transfer; otherwise nothing is booked and the Send stays in review.

Reverse returns the user's input and restores the house's ledger and reservation; a Send that already failed because of its destination is paid back on the terms in the Reversed row above instead. It is the one irreversible mistake in this console: a reversed payout that then lands is paid twice, from the house. So the engine refuses it unless one of these holds:

• nothing was ever signed for the Send;
• the Send has already FAILED;
• the chain proves that none of the Send's transactions can ever land.

It also needs a reason of at least ten characters (what you checked) and a typed confirmation: the transaction ID it will ask the chain about, or the Send ID when nothing was signed.

The chain's proof that a payout can never land

A timeout, or a status the chain will not state, is not proof. The rule fails closed: the Send stays open.

Cancel on chain (EVM only, a Send in flight with a signed nonce on record) signs a zero-value transaction from the same key to itself, at the same nonce and higher fees (nodes require at least 10% more; the engine offers 12.5%). One of the two transactions lands. If it is the cancel, the reversal's proof holds once it is mined; if it is the payout, the confirmation job books it as sent. The Send goes to review with the cancel's hash on it either way.

Confirm sent and Reverse are also on the core Instant Convert house page, which keeps working while the addon is disabled or unlicensed. Cancel on chain and Approve are only in this console, so neither is available while the addon is off.

Known chain limits in this release

• A native EVM payout uses a fixed 21,000 gas and is refused to any address with code. On chains that charge a separate L1 data fee (OP-stack chains) that fee is not in the quoted network fee, so the house bears it. On chains whose gas accounting does not fit 21,000 for a plain transfer, the payout fails to send and lands in review.
• A TRC-20 payout's network fee is priced on at least 131,000 energy for a recipient that has never held the token and at least 65,000 for one that has, or on the simulated figure when that is higher.
• TON and XMR Sends are not built. TRX and UTXO coins are pooled, so they leave Convert through convert and withdraw, not a Send.