Managing 20 Raydium LP Wallets on Android Cloud Phones
Managing 20 Raydium LP Wallets on Android Cloud Phones
Concentrated liquidity on Raydium rewards attention. A CLMM position earns fees only while the price sits inside its range, and its fees don't compound on their own. When the price drifts, someone has to look, decide and sign. Teams that provide liquidity across many pools end up checking positions at odd hours, from whatever device is nearby, which is exactly when mistakes happen.
One setup that works well for this is a cloud phone per wallet. BitCloudPhone runs Android phones in the cloud that you open in a window on any computer. Each phone runs a Solana wallet app with Raydium open in its in-app browser, and each phone holds exactly one wallet. Twenty pools or strategies, twenty phones, no account picker to get wrong.
It also comes with a real trade-off that this guide doesn't hide. A cloud phone is hosted hardware. Keys on it are hot keys, and hot keys get capped balances. Reserves stay on a hardware wallet you keep at home or in the office.
Contents
- Why twenty LP wallets
- The trade-off: hot keys on hosted phones
- The pool map
- Setting up one phone per wallet
- Connections and locations
- What never to do with twenty LP wallets
- CLMM positions: ranges, fees and rebalancing
- CPMM positions: the quiet ones
- Running the phones from a desktop
- Bookkeeping per phone
- Safety habits Raydium itself recommends
- When a wallet looks compromised
- Questions
Why twenty LP wallets
The number comes from separating things that shouldn't share a balance.
One wallet per CLMM strategy. A tight range on a stable pair and a wide range on a volatile pair need different attention. In separate wallets, each position, its fees and its rebalancing history stay readable.
Separate wallets for passive CPMM positions. Standard pools hold fungible LP tokens and fees compound into the pool, so they need far less attention. Keeping them away from active CLMM wallets means a busy rebalancing day can't touch them.
One wallet per owner or budget. A token project providing liquidity for its own token, a treasury with a separate market-making budget, or a fund with two mandates all need clean separation for their books.
A short approval list. A wallet that only ever touches one pool has a short, readable history. If something goes wrong, the damage stays in that wallet.
All twenty wallets belong to one owner. Anyone following the funding transactions on Solana can see that, and the setup doesn't pretend otherwise.
The trade-off: hot keys on hosted phones
Raydium's own wallet guide recommends keeping only an amount you can afford to lose in a hot wallet and using a hardware wallet for larger holdings. A wallet app on a cloud phone is a hot wallet. Its key lives on hardware in someone else's data centre, protected by your BitBrowser account, the phone's app lock and the provider's security.
That leads to three rules:
- Cap every phone. Decide a maximum balance per LP wallet before you create it, and never go above it. The cap should be an amount the owner can afford to lose outright.
- Reserves live elsewhere. Funds waiting to be deployed, and fees taken out of positions, sit in a hardware-backed wallet on a computer you control, not on any cloud phone.
- Phones are for operating, not storing. If a position grows beyond its cap, take the excess out to the reserve wallet at the next review.
If those rules don't fit your situation, use desktop browser profiles with hardware wallets instead. Raydium's docs suggest a dedicated browser profile with as few extensions as possible, which is the other common way to run many wallets.
The pool map
Here's an example map for a team running twenty LP wallets.
| Group | Phones | Purpose |
|---|---|---|
| CLMM, stable pairs | 4 | Tight ranges, frequent small adjustments |
| CLMM, major pairs | 6 | Medium ranges, reviewed daily |
| CLMM, long-tail pairs | 3 | Wide ranges, small caps |
| CPMM, passive | 4 | Standard pools, reviewed weekly |
| Fee collection | 2 | Receive claimed fees before they go to the reserve |
| Spare | 1 | Kept empty, used to rebuild a wallet if a phone has a problem |
Each phone gets a name that says what it holds: RAY-CLMM-STB-1, RAY-CLMM-MAJ-3, RAY-CPMM-2, and so on. The phone's notes record the pool, the range strategy, the cap, the public address and who operates it.
Setting up one phone per wallet
The steps for each phone:
- Create the cloud phone in BitCloudPhone and name it from the map.
- Set its connection (see the next section).
- Install the Solana wallet app your team uses from Google Play.
- Create a new wallet in the app. Write the recovery phrase on paper and store it with the team's other recovery material. Never screenshot it, type it into a note, or upload it to the phone as a file.
- Set an app passcode in the wallet.
- Bookmark raydium.io in the wallet's in-app browser and only ever open Raydium from that bookmark.
- Fund the wallet from the reserve with a small test amount first, then up to the phone's cap.
- Record the public address in the phone's notes and the team sheet.
Leave the phone unrooted. BitCloudPhone offers ADB and one-click root for custom scripting, and that's useful for other work, but a wallet phone should be as plain as possible.
Connections and locations
BitCloudPhone matches each phone's language, time zone, location, carrier and SIM details to the IP of its proxy. For wallet phones, that's a reason to choose the proxy carefully, not creatively.
Use a static proxy in the country the operator actually works from, one per phone or one per operator, and leave it alone. Never use rotating proxies on a phone that holds a wallet, and never pick a proxy country to reach a service that isn't available where you are. If a protocol, wallet or interface restricts some locations, a proxy doesn't change your obligations, and many DeFi interfaces explicitly prohibit using a VPN or proxy to get around their restrictions. Check the terms shown in Raydium's official app and in your wallet app before you start.
What never to do with twenty LP wallets
Never trade between your own wallets. Swapping from one of your wallets into a pool where another of your wallets provides the liquidity, back and forth, creates volume that isn't real. That's wash trading, and for a token project it's also a fast way to destroy trust in the token.
Never use the phones to fake activity. BitCloudPhone's RPA can automate taps and swipes across many phones. That's a tool for legitimate repetitive work elsewhere. On wallet phones, nothing automated should open the wallet app, and nothing automated should ever sign.
Never split one person's activity to look like many people. If a campaign rewards unique users, twenty wallets owned by one team are not twenty users.
CLMM positions: ranges, fees and rebalancing
Raydium's docs put the difference neatly: CLMM rewards active management, CPMM rewards inaction. A CLMM position is a non-fungible position NFT tied to a price range. When the price leaves the range, the position stops earning fees. Fees accrue per position and have to be claimed; they don't compound into the position by themselves.
So each CLMM phone has a routine:
Check range. Open the phone, look at the position, and note whether the price is inside the range.
Claim fees on schedule. Claim to the wallet, then send to one of the fee-collection phones. From there, fees go to the reserve at the weekly review.
Rebalance with a reason. Moving a range means closing or adjusting the position and opening a new one. Write down why before you do it: price left the range, the strategy changed, or the cap was exceeded. A rebalance without a written reason is usually a reaction, not a decision.
One detail matters for anyone farming: Raydium's farms stake CPMM and legacy AMM LP tokens, not CLMM position NFTs. If a strategy depends on farm rewards, it belongs in a CPMM wallet.
CPMM positions: the quiet ones
Standard CPMM pools hold fungible LP tokens. Fees compound into the pool's reserves, so your share grows without claiming, and there's no range to fall out of. These phones need a weekly look, not a daily one.
Keep them boring. One pool per phone, no swaps from the same wallet, and a note of the date and amount of each deposit and withdrawal. When the position ends, withdraw to the wallet, send to the reserve, and shut the phone down until it's needed again.
Running the phones from a desktop
Twenty phones are a lot of windows. The BitBrowser desktop client manages BitCloudPhone, and its built-in MCP server, available from version 7.1.5, lets an AI client such as Claude, Cursor or Codex open, restart and shut down cloud phones when you ask in plain words. You turn it on under Settings, Browser Settings, Local API, with authentication switched on, and copy the configuration BitBrowser shows for your AI client. The connection runs locally, usually at http://127.0.0.1:54345/mcp, with a token in an x-api-key header.
Keep a sheet, raydium-lp.csv, with one row per phone: name, pool, range strategy, cap, and the last review date. A daily round looks like this:
Raydium daily round.
1. Read raydium-lp.csv.
2. List the CLMM phones whose last review is older than one day.
3. For each one, in order:
a. Read out the pool, strategy and cap.
b. Open that cloud phone on the left half of the screen.
c. Wait until I type "next".
d. Shut the phone down and wait 5 seconds.
4. Never open two wallet phones at the same time.
5. Never open, tap or type inside any app on the phones.
The assistant brings the right phone onto the screen and puts it away afterwards. You open the wallet, review the position and sign anything yourself. The rule against two phones at once is what keeps one wallet's decision from being made in another's window.
For team work, BitCloudPhone lets you share a phone with a team member or transfer it to another account. Give each operator only the phones for their pools, and take them back the same day someone changes role.
Bookkeeping per phone
Liquidity positions create messy histories: deposits, partial withdrawals, fee claims, range changes and transfers to the fee-collection phones. Twenty wallets make that worse unless each one keeps its own record.
Once a month, export each wallet's history from a Solana block explorer, tag every transaction by pool and type, and file it with that month's records. Label transfers between your own wallets as internal. Note each rebalance with the reason you wrote down at the time. When the owner or the accountant asks what a pool actually earned, the answer sits in one wallet's history instead of being spread across twenty.
Safety habits Raydium itself recommends
Raydium's trust and safety page reads like a checklist for anyone running many wallets.
Check the domain. Clones of the Raydium interface buy search ads above the real site. Use the bookmark, read the domain, and don't trust the padlock alone.
Read every signature. If a signing prompt has more than three or four instructions from programs you don't recognise, reject it. If a transaction would transfer all of a token rather than a specific amount, reject it.
Trust mint addresses, not names. Anyone can create a token with a familiar ticker. The mint address is the token's real identity.
Ignore unknown tokens. Unsolicited tokens often link to claim pages that phish recovery phrases or ask for malicious signatures. Hide them and don't visit their links.
Nobody legitimate asks for a recovery phrase. Raydium says it doesn't message users first. Anyone who does, and asks for a phrase or a "verification", is trying to steal it.
With twenty wallets, these habits matter twenty times over. Separate phones help because one mistake stays in one wallet.
When a wallet looks compromised
If a phone's wallet shows an approval you didn't make or a transfer you didn't sign, act in this order:
- Stop using that phone for anything else.
- From the same phone, move whatever is left to a fresh wallet on the spare phone, and revoke approvals you don't recognise.
- Rotate the BitBrowser account password and check which team members had access to that phone.
- Write down what happened, with the time, before you touch anything else.
Solana transactions are final, so speed matters more than understanding at first. The investigation can wait until the funds are safe. Because the other nineteen phones share no app, session or approval with the affected one, the incident stays where it started.
For the iPhone side of a team, BitCloudPhone-iOS runs native iOS on real iPhone SE hardware, with apps from a preconfigured marketplace. If your team prefers an iOS wallet app, check it's listed there, and apply the same caps and rules.
Questions
Is it safe to keep a wallet on a cloud phone?
It's a hot wallet on hosted hardware. Keep only a capped amount you can afford to lose on each phone, and keep reserves on a hardware wallet you control.
Can a cloud phone use my hardware wallet?
Plan on hardware wallets staying with the computers and devices you hold. The reserve wallet lives there.
Why one phone per wallet instead of one phone with twenty accounts?
One phone per wallet removes the account picker, keeps approvals separate, and keeps any incident in one place.
Can the assistant rebalance positions?
No. It opens and shuts down phones and reads your sheet. People review and sign.
Can twenty wallets trade with each other to build volume?
No. That's wash trading. Each wallet provides liquidity; none of them trades against the others.
Start with five phones and a week of daily rounds. Add the next five only when the routine runs without surprises.
Disclosure: I do content work with BitBrowser, and the BitBrowser link above carries a referral code.
Not financial advice. This post describes an operational setup, not an investment strategy. Liquidity provision can lose money through price moves and impermanent loss, and nothing here is a recommendation.