Wallets
Where the integrator fee lands on each chain and whether it can actually land there — an address book and a readiness report, not a custody screen. Includes the Solana token-account trap.
/admin/dex/wallet. One page answering one question: where does the money
land, and can it actually land there?
This is not a custody screen, and it never will be
The Ecosystem addon's master wallets hold an encrypted private key. That is what makes Ecosystem custodial — it can issue deposit addresses, sign withdrawals and move a customer's funds without the customer present.
This addon holds no key for anybody. There is no "create wallet" button here, and its absence is not an oversight:
Two independent guards forbid the code that would introduce custody into this addon — a lint rule and a build-time invariant check, both of which reject wallet construction, key generation and decryption in this tree.
So this page cannot become a custody screen by accident, and a future "just add a signer" change fails the build rather than shipping.
What an operator actually needs is narrower and this page serves exactly that: a fee address per chain, a check that the address is real, and a warning when it cannot receive anything yet.
The readiness answer is per virtual machine
"Can this address receive our fee" has two genuinely different answers, and this is the single most likely misconfiguration in the addon.
EVM — yes, always
An address receives any ERC-20 with no setup at all. The only question the page can ask is whether a recipient is set. If one is, you are done.
Solana — not necessarily
An SPL token is not held by a wallet. It is held by a token account owned by that wallet, one per mint, and each one must exist before anything can arrive.
So a correctly-typed, perfectly valid Solana fee recipient can collect nothing — and nothing about the address itself reveals it. The page goes and looks, mint by mint, and tells you which ones are missing.
There is a Create fee account action for the mints that need one.
Swaps succeed. Users are happy. The fee ledger accrues. And the money is not there, because there was nowhere for it to go. You find out at the first sweep, which may be weeks later.
Check this page after enabling Solana, and again after listing any new SPL token.
TRON and TON
Both have their own account model. TRON follows the TRC-20 approval flow; jettons on TON live in per-owner contracts rather than as balances on the owner. The page reports readiness for each in the same shape as the others — set, real, and able to receive.
What the page shows per chain
| Column | Read it as |
|---|---|
| Fee recipient | The address configured on Chains |
| Rendered address | The same address in that chain's own format — a quick way to catch a value pasted from the wrong network |
| Can receive | Whether anything would actually arrive today |
| Blocking detail | Per mint on Solana; a single answer elsewhere |
What it deliberately does not serialise
No RPC endpoint URL is returned by this route, even though it uses one.
The common RPC providers embed the API key in the URL path, so returning "the endpoint" would be returning a credential to every admin who can read this screen. The page reports only whether an endpoint resolved — the same contract the chain console follows.
Routine
-
Set a recipient on every chain you have enabled. A chain with no recipient serves swaps and earns nothing, and that shows as a separate status from "broken".
-
Check the rendered address matches the network you meant. A pasted EVM address on a Solana row is caught here rather than at sweep time.
-
On Solana, create the missing token accounts — including after every new SPL listing.
-
Re-check after any change to the chain's configuration. See Requirements for the wider per-chain report.