On AllSwap, “non-custodial” means that the consumer product does not create a long-term account balance or platform deposit wallet for the user. The AllSwap application layer also does not generate an order's one-time deposit address or hold its private key, so it cannot unilaterally transfer, freeze, or pause funds at that address. However, once the user's payment is on-chain, it normally cannot be recalled. The funds enter the order settlement process controlled by the underlying market-maker and settlement networks until the destination address receives the assets or the final refund arrives.
What does AllSwap's “non-custodial” model not mean?
Custody generally means that a service provider holds assets for a user over time and records the user's balance in an internal account. For example, a user may first deposit into a personal account at a centralized exchange, then rely on the exchange's internal ledger to trade or withdraw. AllSwap's consumer swap flow works differently: users do not first place assets into a reusable platform account, and there is no personal balance to maintain over time. Each order returns a separate, one-time deposit address. The user actively sends funds to that address from a wallet or exchange, and the destination asset is then settled to the destination-chain address specified by the user.
This non-custodial boundary applies to the AllSwap application layer. Under the currently confirmed architecture, the one-time deposit address is generated by the underlying market-maker network's on-chain settlement mechanism and returned with the order. AllSwap aggregates quotes and displays payment instructions and order status, but it does not generate that address, hold its private key, or have an execution path that lets it unilaterally move, freeze, or pause funds at the address. Users can review this product position in the AllSwap non-custodial security overview.
Public information does not disclose whether the underlying fund permissions are implemented through smart contracts, multiparty computation (MPC), solvers, or another architecture. It would therefore be inaccurate to claim that “code automatically holds the funds,” “no one can control them,” or the system is “absolutely decentralized.” Non-custodial also does not mean proof of reserves, insurance for funds, guaranteed settlement, zero temporary control by any party, or an automatic return to the original on-chain sender for every failed order.
Who controls the funds at each of the three swap stages?
| Stage | Actual control relationship | What the user needs to understand |
|---|---|---|
| Before payment | The assets remain under the control of the user's source wallet or payment account | The user can choose not to pay or can create a new order. AllSwap only displays the quote and payment instructions; an order countdown does not mean that the platform has already obtained the funds. |
| During settlement | After the user transfers funds to the order's one-time deposit address and the payment receives on-chain confirmation, the user normally cannot recall it. The address and authority to move the funds belong to the order settlement mechanism of the underlying market-maker and settlement networks | Until the destination assets or final refund arrive, the user no longer directly controls those funds. Chain congestion, changes in liquidity, network failures, or risk-handling procedures may cause a delay, refund, or manual review. |
| After delivery or refund | After a successful swap, the controller of the destination recipient address controls the delivered assets. After a refund, control depends on whether the user entered a refund address for the order | If a refund address was entered, the refund should settle to that address. If none was entered, the refund first goes to AllSwap's platform fallback refund address; the user must submit verifiable proof of payment and pass review before the platform manually returns the funds. |
The third stage makes it especially important to identify who controls the destination address. AllSwap does not verify that a destination recipient address is necessarily controlled by the person who made the payment. If the user enters an address belonging to a friend, merchant, or exchange, that address's controller—not the original paying wallet—controls the assets after successful delivery. If an exchange deposit requires a destination-side Memo or Tag but the AllSwap page has no corresponding destination Memo field, do not use that exchange deposit address directly. Settle first to a wallet you control.
Refunds do not all “go back the same way.” If the user entered a valid refund address when creating the order, any available refund should be verified by checking actual on-chain receipt at that address. If the user did not enter a refund address, the funds may first arrive at AllSwap's platform fallback refund address. This second route contains an explicit operational control step: the user must contact official support and provide genuine, verifiable proof of payment, after which the platform processes a manual refund once the claim has been reviewed. “Non-custodial” is therefore not a reason to omit the refund address, and it does not support a promise that an order without one will automatically return funds to the source wallet. See the AllSwap refund process for the relevant procedure.
How can users verify control and the funds' final destination?
A non-custodial swap should not be treated as complete merely because a webpage says “successful” or “refunded.” Build a complete chain of on-chain evidence:
- Check the current order before paying. Confirm that the browser hostname is
allswap.io, then check the source asset, source network, specified amount, one-time deposit address, recipient address, refund address, and countdown. If the page returns adepositMemo, copy it exactly when paying. Do not invent one if the page does not return it. - Keep the source-chain payment evidence. Record the order ID, one-time deposit address, and source-chain transaction hash (TxID). Use the appropriate network's block explorer to confirm that the asset, amount, recipient address, and any Memo match the order. The source-chain TxID proves that a payment was sent; by itself, it does not prove that the swap succeeded.
- Verify the final control outcome. For a successful order, check the destination-chain TxID, destination asset, and actual recipient address. For a refund, check the final refund TxID. If no refund address was entered, a transaction into the platform fallback address does not mean that the user has received the refund; also verify the final payment from the platform to the user after the manual refund is completed.
- Do not send additional funds when something is wrong. If a confirmed payment is not recognized, an order remains in processing for an unusually long period, the page says successful but nothing has arrived, the page says refunded but there is no final refund record, or the status is
FAILED, do not send to the one-time address again. Preserve the evidence above and redacted screenshots, then contact support through an official channel listed in the AllSwap Help Center.
No legitimate support review requires a private key, seed phrase, wallet password, one-time authentication code, or remote control of the user's device. An essential part of non-custodial security is that the user always retains these signing and account-control credentials. Yet once funds have been paid into a particular order, determining who has practical control at that moment still requires looking at the settlement stage, destination address, and refund route. For other technical and operational risks of cross-chain settlement, review the AllSwap Risk Disclosure.