What this does not do

Every product page lists what a thing does. This page lists what Swap does not do, because the gap between "not built yet" and "deliberately not built" is the difference between waiting for a release and choosing a different product.

Nothing below is a placeholder. Each item was scoped, costed, and left out for a reason that is written down, and each says what would have to be true before it changes.

Cross-chain bridging

Not included, and it is not a bigger version of a swap. It has been scoped in full — model, state machine, poller, fee handling, both consoles, test plan, effort — and the answer is build it when an operator asks, and not before. The estimate is 18–22 developer-days for one bridge provider on a subset of networks, which is more than the monetisation and hardening phases of this addon combined.

A swap is one transaction on one chain that either succeeds or reverts. A bridge is two transactions on two chains, minutes to hours apart, with a settlement window in which the user's funds are in neither place. It has failure modes a swap does not have at all: a destination-side failure with the source side already spent, a refund path that returns a different asset than was sent, and a stuck transfer that no amount of retrying resolves.

Folding that into the swap path would mean the same progress UI, the same history row and the same confirmation poller describing two fundamentally different things — and the moment one is stuck, the copy that reassures a swap user ("this is still confirming") is a lie to a bridge user.

What it would take: its own record with a source and destination network, a poller that reads a bridge provider's status endpoint rather than a chain receipt, copy that never implies we can recover a stuck transfer, and its own risk disclosure.

And one state most bridge interfaces do not have: unresolved. The source transaction confirmed, the provider has not given a final answer, and we have stopped asking. It is neither success nor failure, and saying so — with the provider's name and the route id — is the honest version of what every other interface renders as a spinner that never stops.

Solana and other non-EVM chains

Shipped. This entry used to say "not included, and not planned", and that is no longer true.

It is recorded here rather than deleted because it is the largest thing on this page to have changed, and an operator who read the old version deserves to see that it changed rather than to find the sentence quietly gone.

Swap now spans four virtual machines — EVM, Solana (SVM), TRON (TVM) and TON — across fifteen chains, priced by Jupiter, SunSwap and STON.fi alongside the EVM adapters. The old entry was right about the reason it was hard: the VM, not the chain, is what decides how a token is held and what an approval means, so each one is a separate integration rather than a row in a registry.

Two consequences of that survive and are worth knowing before you enable them:

• On Solana a fee address is not enough. A token lives in a token account, one per mint, and each must exist before anything can arrive — so a perfectly valid recipient can collect nothing, silently. Wallets goes and looks, per mint.
• TRON and TON have no integrator fee hook at all. Neither SunSwap's nor STON.fi's router takes a fee parameter, so what you take on those two chains is taken the way a direct pool takes it, or not at all. See Providers.

More aggregators

Partly shipped. KyberSwap and LI.FI are in the box; Odos is still out.

The old entry deferred all three behind a venue-interface rewrite. That rewrite landed — a quote now carries a venue kind and a nullable fee side — and KyberSwap and LI.FI were built against the new interface rather than twice. LI.FI is also the only adapter that prices Cronos, Rootstock and Celo.

Odos is unchanged and still out, for the reason that was always the real one: its fee mechanism is an on-chain registered referral code, per chain, and a code typed into a form that was never registered produces swaps that succeed and pay you nothing, forever, silently. When it lands it will be a deploy step with receipt verification and a refusal to route through Odos until the registration is confirmed on chain — not a text field.

Market depth and a live trade tape

Deferred to the same release, for a better reason than sequencing.

A depth curve for an aggregated route has to be sampled — the server quotes a dozen sizes and interpolates — and every point costs a vendor call. For a direct pool it is exact: the whole curve is a closed-form function of two reserves, which is one on-chain read and arithmetic. Building the sampled version first means shipping the approximate one and then replacing it.

The same applies to the trade tape. Today's swap list is honest about being your platform's swaps, because labelling platform-only flow as market flow is a claim about liquidity that is not true. A genuine tape needs on-chain Swap events, which arrive with the pool indexer.

A wallet we create and hold for the user

Not included, and this one is a design decision rather than a schedule.

Note the word hold. There is now a wallet a user creates inside the product — one BIP-39 phrase across all four virtual machines, no extension to install — and it is not an exception to anything on this page. The phrase is generated and encrypted in the user's browser; your server is handed an opaque envelope it has no key for, plus the public addresses, which is why a locked wallet still renders a portfolio. It announces itself over EIP-6963 and the Wallet Standard, so the swap terminal, sign-in and the NFT flows use it with no code path of their own.

What is not included is the custodial version. The platform holds no key, signs nothing on a user's behalf, and cannot move or recover funds — including for the wallet it just helped create. Optional email and social sign-in creates a wallet the user controls through a third-party key service; it is still self-custody, the disclosure in the wallet menu says so, and we still cannot recover it.

There is no configuration that turns this into a custodial product, and there is not going to be. If you need to hold customer funds and move them internally, that is the exchange side of the platform, not this addon.

Deploying our own contracts

Not included, permanently, at this tier.

Every transaction a user signs here targets a contract that already exists on chain and that we did not write. That is what lets the security statement be short: a bug of ours cannot lose a user's funds, because no code of ours is in the transaction path.

A fee-taking wrapper contract of our own would work, and it is what fee-charging swap frontends without an aggregator do. It is rejected on four independent grounds, the shortest of which is that it changes what users approve from a well-known router to our address — and there is no audit budget, no contract test lane, and no permanent security owner behind it.

On-chain honeypot simulation

Shipped, off by default, and it needs something from you.

The screener can buy a token and sell it straight back inside a simulated block and treat a reverted sell as a honeypot. It needs an RPC endpoint that implements eth_simulateV1, which most free endpoints do not. When yours does not, it contributes nothing rather than failing tokens.

Verify it against your own RPC on a token you already know before you rely on it — turn it on, screen a token you know is clean and one you know is not, and compare the verdicts to the vendor's. It can only ever make a verdict worse, so the risk of leaving it on is a false positive, not a false negative.

Translated wallet-custody copy

A known gap, small and specific.

The custody disclosure shown for an email or social wallet, and the Permit2 approval wording, are English-only. Every other sentence a user reads before signing is translated into all supported locales. These two are not yet, and they are the sentences that matter most to a first-time user — it is on the list.