Automating long-tail token conversion

Swap fees are often earned in-kind, but opex is paid in stables. If your product takes fees this way—DEX aggregators, launchpads, routers, marketplaces—you're earning whatever your customers trade: hundreds, if not thousands, of long-tail tokens you don't want on your balance sheet. And it's even worse for builders who operate across multiple networks.

Holding long-tail tokens is problematic for many reasons:

1. Unwanted exposure to volatile assets. Revenue earned today is worth less tomorrow.
2. Less working capital. Tokens pile up as dust across chains.
3. Manual ops are error-prone and time-consuming. Approvals, slippage, MEV, tax lots, gas, signers all require accountability.

Pricing long-tail tokens is also hard. Majors (ETH, stables, etc) have Chainlink feeds and deep liquidity, so swapping them is tedious but straightforward. Long-tail tokens have neither. Often the only price is a thin AMM pool that can be manipulated, making fair execution hard.

Lemons into lemonade#

The shape of the solution, regardless of implementation, is a dedicated receiving account that can accept any token. Ideally it's the same address on every network you operate on.

The receiving account prices each token, swaps it into your desired denomination (i.e. a stablecoin), and sends the proceeds to your operating or treasury account on the network of your choice.

Teams either pay others to do this for them, or spend hours each week/month doing it manually.

Managed automation accounts#

Automation accounts in Splits are designed for this scenario. They're deposit addresses that swap, bridge, and route funds. They execute every ~10 minutes on balances over $5.

Our server handles pricing, execution, and routing. Your workspace's spam filters remove tokens you don't want processed. You get a clean stream of working capital into your operating account, reconciled per revenue stream, without running custom infra.

DIY setup#

If the managed approach doesn't work for you (i.e. nobody can direct funds after deploy), you can build your own without building too much.

There are three core parts to the setup:

1. Swapper contract: a payable contract that converts everything it receives into one output token. Tokens accumulate until someone calls flash, pays the beneficiary the oracle price, and takes the tokens. You can include a discount to incentivize third parties.
2. Oracle contract: determines a fair "clearing price" for the Swapper. Off-the-shelf options are UniV3 TWAP and Chainlink, but those only cover the majors. In practice, you'll write a custom oracle that prices assets the way you trust.
3. Server key: for long-tail tokens that MEV bots aren't watching, you'll run a small server with its own key that monitors balances, prices the trade, and executes it. This gives you full control over routing and slippage.

You get full self-custody and control over pricing and execution, at the expense of simplicity and maintenance.

Taken to the extreme, you can make this entirely trustless—immutable contracts, fixed destination, permissionless runtime functions—though that's often not needed. Keep in mind if you do: an ownerless Swapper needs an oracle for every token it will ever receive. Tokens it can't price, it can't swap, and without an owner those funds are lost.

The tradeoffs#

Life is just a series of tradeoffs. The DIY approach trades operator risk for oracle risk. Neither option is right without understanding your goals and constraints, and what works today may not work next year.

We've spent years building payments and financial infra. If this is a problem you're facing, we're happy to help you think through your options and architecture.