Skip to main content
Start with the transaction’s actual state: has the wallet received a request, has a transaction hash been returned, or has a receipt confirmed? The wallet flow checks network, release identity, balances, allowances, and execution bounds. The contracts are deployed on Arc mainnet; the public app is not hosted yet. Check release status for current availability.

​
A quote is unavailable

An unavailable route is not an instruction to increase slippage. Slippage controls settlement bounds; it does not create liquidity.

​
Why there can be more than one wallet request

The spending contract needs an allowance before it can transfer an ERC-20 input. The current wallet flow can:
  1. Skip approval if the existing allowance is sufficient.
  2. Request approval for the required amount if there is no allowance.
  3. Reset an insufficient nonzero allowance to zero, then approve the required amount.
These are separate onchain transactions. Approving an allowance does not complete the launch or swap. If the account or network changes during approval, the dependent action stops. The completed approval remains an onchain action for its original account.

​
New launches are paused

The registry’s launchesPaused() flag controls new token creation. At the latest deployment check, it was true. A paused launch is not fixed by increasing gas or slippage. This gate applies to FX-pair, single-currency, and dedicated official-FX launches. Changing it does not restart an existing token’s opening window or pause existing trading and claims.

​
A transaction is pending

A returned transaction hash means the wallet submitted a transaction. A receipt timeout means confirmation is still unresolved. Check that hash in the wallet or the relevant network explorer before sending the same action again. The implementation retains a pending-operation record and can resume receipt tracking. If the wallet response was interrupted before a hash returned, check its transaction history. A lost response is not proof that nothing was submitted.

​
A transaction reverted or was replaced

A reverted receipt means the intended contract operation did not complete. Review the receipt and refresh the quote before deciding on another submission. Network gas can still have been spent. Wallet speed-ups and cancellations can replace a transaction. A replacement with a different action is not confirmation of the original trade.

​
The trade confirmed but the page looks unchanged

The transaction and the market-data index have separate update times. A confirmed transaction can appear before the refreshed portfolio or chart reaches its block. Keep the receipt as the source of the transaction result. Refresh the view and check the snapshot. Do not repeat a confirmed trade merely because its display has not updated.

​
A balance or reward looks missing

Confirm the account, network, selected release, and page scope. A portfolio page covers the selected factory’s launched tokens, not every asset held by the wallet. A fully sold position can retain unpaid holder rewards. Creator fees, holder rewards, and vested builder tokens are different entitlements. See creator and holder fees.

​
Information that helps resolve an issue

Record the network, public wallet address, token address, transaction hash if available, selected route, amount mode, and visible error. These distinguish a signing issue from a route failure or a delayed read. Never include a private key, recovery phrase, or secret RPC credential in an issue report.