Preview, simulation, signature, finalization, and reconciliation#

Every Mainnet Beta conversion follows a durable, action-specific lifecycle. Classification or wallet connection alone cannot submit a transaction.

Permanent action: DEAD conversion burns the selected token balance and closes the account to the displayed treasury. SELLABLE conversion swaps the selected balance through the displayed Jupiter route. Review the exact action before signing.

1. Active runtime controls#

The production control plane verifies public-access confirmation, treasury identity, pricing/routing availability, execution confirmation, pause state, real-value limits, and action-specific policy. Any missing or inconsistent dependency fails closed.

2. Player preview#

The player reviews the complete token amount, mint and account, classification, action, destination, estimated rent or swap output, slippage/price-impact boundary where applicable, fees, expiry, and permanent consequence. The product does not infer transaction consent from the earlier text signature.

3. Fresh scan and construction#

The server rescans the exact selected account and refreshes market evidence before construction.

• DEAD: build a plan memo, BurnChecked for the full nonzero raw balance, and CloseAccount to the configured treasury.
• SELLABLE: request a fresh exact-in Jupiter order to the configured USDC treasury under bounded slippage, price impact, output, and expiry policy.

Changed accounts, unsafe metadata, price conflict, missing route, action-tier mismatch, or an oversized/expired transaction stops preparation. Mixed burn-and-sell plans are rejected.

4. Server simulation#

The server estimates fees and simulates the exact unsigned transaction. A failed simulation stops the plan. Quotes and blockhashes expire; after expiry, the user reviews a newly prepared transaction rather than reusing stale bytes.

5. Wallet signature and submission#

Before broadcast, the server checks that the signed message bytes equal the reviewed transaction, the signer is the expected verified wallet, and the signature is valid. Submission uses RPC preflight. Receiving a public signature does not issue credit.

6. Finalization#

Every submitted signature must reach finalized commitment. A chain error marks the attempt failed; unavailable status remains durable and retryable. Logging out revokes access but does not erase submitted liabilities or create permission to duplicate them.

7. Independent reconciliation#

After finalization:

• DEAD reconciliation proves selected accounts are absent, loads the finalized transaction, measures actual treasury rent and fees, and obtains a reliable SOL/USD settlement price.
• SELLABLE reconciliation proves the expected Jupiter transaction and exact input/output token deltas, USDC treasury destination, minimum output, and transaction fee.

Credit is issued only from verified realized value. If any required evidence is temporarily unavailable or mismatched, the plan stays in reconciling without credit.

8. Atomic credit settlement#

Conditional state transitions, unique request keys, a settlement guard, and session revisions prevent intentional duplicate credit. The conversion record, session balance, wagering target, ledger entry, and final plan state settle together.

Submitted and reconciling plans can be discovered after reconnecting the same wallet. The safe recovery action is to resume the existing record, never to create a replacement merely because confirmation is slow.

Read the Mainnet safety overview, Mainnet USDC payouts, and Key risks.