Switch exchanges without redoing your grid by hand
Updated 25 August 2026. Two migrations are described below. The July 2026 one was done by hand. The 24 August 2026 one was run with the v3.0.0 tooling.
A grid bot that has been running for months carries baggage: one open sell order for every completed buy. That is exactly what you want while it runs, and exactly what you do not want the day you have to leave an exchange, or the day you decide too much capital is parked in sell orders far above the current price.
Grid Restructuring, in CryptoBot Pro v3.0.0, rewrites your open sell orders in one planned, verified operation, from two buttons in the Cycles tab. Two modes: consolidate (N orders become a few price bands, for migrating or freeing order slots) and split (large orders become K smaller pieces, so cycles complete more often and release capital sooner). You see the full plan before anything is sent, the database is backed up before the first cancel, and your trading history is never deleted. What you do not get is an undo, so the preview screen is where you decide.
Why you would need this
Two situations, both from real life:
- You are forced to move. In 2026, as MiCA took effect, Binance wound down its service for EU users, and accounts ended up in withdrawal-only mode. Delistings of specific pairs happen on every exchange. When that day comes, your BTC can be transferred in one transaction, but your 100+ open sell orders cannot: someone has to re-enter them on the new venue, which may also have a lower open-order limit.
- You want capital back sooner. A sell order at a price far above the market can sit untouched for months. Splitting it into smaller pieces at staggered prices lets parts of it fill earlier, and every fill releases USDC that goes back into the bot's working capital to start new cycles.
How it works
Consolidate: N orders become one order per price band
The planner groups every open sell order into price bands (2,000 USDC wide by default, configurable). Each band becomes a single order: its quantity is the sum of the merged lots, and its price is the highest original target in the band, rounded up to a valid tick on the target exchange. That rounding direction is the contract: no merged lot is ever priced below its own original target.
Schematic. Quantities are conserved in the plan: total in equals total out plus reported dust, and anything below the exchange's minimum step is listed as dust, not silently dropped.
Before anything executes, the plan is checked: total quantity in equals total quantity out plus reported dust, every order clears the target exchange's minimum order size, every merged lot keeps a price at or above its original target, and the final order count fits the exchange's open-order limit. Any failed check aborts the run. Bands that would fall below the minimum order size are merged upward into the next band instead of being dropped.
Two ways to use it, both from the same Reduce or move sells… button in the Cycles tab. A selector, What do you want to do?, decides which one you get: its first option is Reduce the number of orders on the same exchange (no transfer), and the options after it are the destination exchanges you have configured.
Migrate to another exchange
- The form states it plainly: Choosing another exchange moves the grid there. That takes two steps, because you transfer the BTC yourself in between.
- Phase 1 cancels the source orders and shows the exact order list plus the total BTC to transfer.
- You move the funds yourself. The bot's API keys carry no withdrawal permission, deliberately. A bot that can move coins off an exchange is a bot whose compromise costs you the coins.
- Phase 2 places the planned orders on the new exchange once your balance has arrived. Interrupted? Reopen the dialog and it picks up where it stopped.
Free open-order slots
- Exchanges cap the number of open orders per account or per pair.
- Consolidating old sells into bands frees slots so the bot can keep placing new buy orders.
- One pass: cancel, then re-place, on the same venue. Same checks, same preview, same backup before the first cancel.
- This path has run on exported order books, not yet on a live account. The cross-venue path has (see below).
Split: one order becomes K pieces, capital comes back sooner
Split takes sell orders above a notional threshold you choose and cuts each one into K pieces (2 by default). Piece prices are laddered between the cycle's break-even (buy price plus fees on both sides, plus a safety margin) and its original target. Lower pieces fill earlier, complete their cycle, and release USDC back into the bot's working capital.
Being clear about the trade-off: laddered pieces can sell below the original target
price, so projected revenue for those cycles goes down. The dry-run shows that delta
in plain numbers before you confirm. Pieces are never priced below break-even, and a
keep-price option splits quantity only, leaving every price untouched.
Filling in the Split dialog
The app's Cycles → Split sells… dialog asks for four things. Only one of them needs thought.
| Field | What to put |
|---|---|
| Exchange | The venue whose sell orders you want to cut. One venue per run. |
| Parts (K) | How many pieces each order becomes. This is the one that needs a number you have actually worked out, see below. Start at 2. |
| Above (USDC) | Ignore sell orders smaller than this. 0 means every sell order.
Raise it when you only want to cut your few large positions. |
| Keep price | Leave it unticked for the normal behaviour: pieces are laddered, so the lower ones fill sooner and return capital. Tick it to split the quantity while leaving every price exactly where it was. Same expected profit, more granularity. |
Choosing K, the only number that can waste your run
Every exchange refuses orders below a minimum value. Splitting an order into more pieces than it can pay for does not produce smaller orders, it produces nothing: the engine skips that order and lists it as skipped rather than quietly using a smaller K. So the ceiling is simply
K ≤ order value ÷ minimum order size
| Exchange | Minimum order | A 60 USDC sell splits into at most |
|---|---|---|
| Kraken, Bitvavo, Aster, Binance, MEXC, KuCoin | 6 USDC | 10 pieces |
| Hyperliquid | 11 USDC | 5 pieces |
Read that the other way round and it explains the most common disappointment: a grid made of small cycles cannot be split at all. A 10 USDC sell order on a venue with a 6 USDC minimum has no room for even two pieces, and a dry-run over such a book comes back empty. That is not a failure, it is the exchange's floor. Splitting is for grids whose individual orders are comfortably larger than the minimum.
One more ceiling applies on top: after the split, open orders must stay under 90 % of the venue's cap, so the bot can still place new buys. If your K breaks that, the dry-run stops and tells you the largest K that fits. Nothing is placed either way, since the preview is always a dry-run and only the confirmation screen touches your account.
The Split dialog works on one venue at a time and never moves anything anywhere. Grouping sell orders, whether you stay put or move to another exchange, is the consolidate mode, and it has its own entry next to Split in the Cycles tab: Reduce or move sells…. One dialog, four screens.
- Form. The exchange holding the orders, the selector that chooses between staying put and moving, then the price band, whose hint states the rule: Orders whose targets fall in the same band become one order, priced at the highest target of the band. A wider band means fewer orders and a higher price for the ones merged upward. Last field is Above (USDC): Only sells with notional ≥ this amount. 0 = all sell orders.
- Preview. Preview is a dry-run: nothing is cancelled or created until you confirm. No order can ever end up below its original target price. The screen lists current orders, planned orders, dust, skipped lots and why, and the projected revenue delta. Closing the dialog here costs you nothing.
- Transfer. Migration only. It gives the exact BTC amount to send, then makes you answer for the withdrawal fee, which comes out of what you send so that less arrives than the plan assumed. Either you add the missing BTC yourself and every order keeps its planned size, or you resize every order down by the same percentage to match what arrived, in which case the shortfall comes out of the profit rather than out of the purchase cost. If you top up, you can also type the fee you paid and every planned price rises by the same percentage to earn it back. That field is in USDC while exchanges quote the fee in BTC, and the hint spells the conversion out with a worked example.
- Resume. Appears when a previous run stopped part-way. It re-reads the real state of every order on the exchange and finishes the remaining steps. Before v3.0.0 that recovery existed only on the command line, with the app closed.
The command line still does the same work and is the fallback if the interface will not start:
bot-spot -restructure -exchange<source> --mode=consolidate \
--target-exchange=<destination> --band=1000 --format=jsonThat prints the plan without touching anything. Drop --format=json and
add --execute to run it, move your funds, then place the orders on the
destination with -restructure-place -exchange<destination>. Close the
app first: both commands refuse to start while it holds the database. The in-app path
is the opposite, it needs the app open until the run finishes.
Neither dialog will start unless your licence is active and the scheduler is stopped, Split included. Stopping the scheduler is not a formality: a bot placing new buy orders while the planner is cancelling sells would invalidate the plan halfway through it.
The migration behind the feature, July 2026
In July 2026, the maintainer's own grid was running on Binance when EU accounts went into MiCA wind-down, withdrawals only. The book had 155 open sell orders. Re-entering 155 limit orders by hand on a new exchange was not a realistic option, so the consolidation algorithm that v3.0.0 productizes was written and used for real, moving the grid to Hyperliquid.
Every number above was verified by script before execution: each of the 155 lots ended up priced at or above its original target, winning net of Hyperliquid's 0.04% maker fee, with total quantity conserved. The honest counterpart: a band's price is the highest target inside it, so some lots now fill later than they would have on their own. That is the trade you make for 16 orders instead of 155.
One thing the July 2026 migration did that v3.0.0 will not do: it purged the old database cycles, keeping a CSV archive on the side. Grid Restructuring replaces that purge with marking. Source cycles stay in the database, flagged as restructured and linked to the orders that replaced them. Nothing is deleted, ever.
The first run with the shipped tool, 24 August 2026
That second migration had nothing to do with regulation. The maintainer's grid was sitting on a venue charging 0.40 % on the sell side against 0.05 % on the venue he moved it to. On a grid whose cycles aim at a few tenths of a percent, that gap takes a visible share of every completed cycle, over and over. This time the move was done from the dialog described above, not by hand.
The +5.86 USDC is not a trade and not a forecast, it is the band rule doing arithmetic. Each band is priced at the highest target it contains, so every other lot in that band gets listed slightly above the price it was already waiting for. It costs nothing, and it is why consolidate cannot lower projected revenue. The counterpart is unchanged from July: some lots now sit behind a higher price and will fill later than they would have alone.
Neither exchange is named here. The fee gap was the whole reason for the move, fee schedules change, and a named comparison would be stale before it was useful. What the run does establish is narrow and worth stating plainly: the cross-venue path has been used on a live order book once, at 82 orders. Regrouping sells on a single venue has not, and that test is planned rather than done.
Your records stay intact
Cycles are never deleted
A restructured cycle is marked, not removed. Its purchase price, purchase date, fees paid, and realized profit are never modified. New orders carry a reference back to the cycles they replaced, so the chain from original buy to final sale stays auditable.
Automatic backup before phase 1
Phase 1 starts with a full database backup to a dedicated folder that the daily backup rotation never touches. If the backup fails, the run aborts before anything changes. Placing the orders on the destination and resuming an interrupted run do not take a backup of their own.
Nothing is sent before you have read the plan
The dialog's second screen is the full before/after table: current orders, planned orders, dust, skipped lots and why, plus the projected revenue delta. Nothing has reached the exchange while you are reading it. On the command line the same plan prints unless you pass an explicit execute flag.
Resumable after interruption
Every step is written to the database before it runs on the exchange. If the process crashes or an order is rejected mid-way, reopening the dialog lands on the resume screen, which reconciles the actual exchange state against the plan and finishes the job without double-placing anything.
The automatic backup restores the local database. It cannot un-cancel orders the exchange has already cancelled, and it cannot pull back orders already placed. Restoring after a partial run makes things worse rather than better: the database returns to a state the exchange has already left, and the two are then out of sync.
So the preview screen is where you change your mind, and the way out of a half-finished run is the resume screen, not the backup file.
FAQ
What about my tax declarations?
The data your declaration is built from does not change. Original purchase prices, dates, fees, and realized profits stay exactly as they were, on the original cycles, which remain in the database and in every export. Replacement orders are linked back to their source cycles, so a complete history from first buy to final sale can always be exported for you or your accountant.
One caveat on which numbers to use. The reference is the raw export, not the aggregated statistics on the dashboard. Those aggregates carry simplifications that are fine for reading your grid at a glance and wrong for a declaration.
CryptoBot Pro is record-keeping software, not a tax service. How restructured positions should be declared depends on your jurisdiction. The feature's job is to make sure the raw data is complete and untouched.
What if it crashes in the middle of a run?
Designed for exactly that. The sequence is: backup first, then every state change is persisted before the matching exchange call. After a crash you run the resume command, which re-reads the real state of every order on the exchange (including orders that filled during the outage, which are settled normally, not re-sold) and completes the remaining steps.
Worst case between crash and resume: some BTC sits unsold on the exchange. Nothing is lost, it is just not re-listed until you resume. Note that resume is the recovery path, not the backup. Restoring the database over a half-finished run would only desynchronise it from the exchange.
Does the bot transfer my funds between exchanges?
No, and it is not going to. The bot's API keys are created without withdrawal permission, and that stays true with this feature. It is the single setting that caps what a stolen key is worth: a bot able to move coins off an exchange is a bot whose compromise costs you the coins, and saving you one manual transfer per migration does not buy that back.
So migration is two-phase. Phase 1 cancels the source orders and gives you the total BTC to transfer. You withdraw and deposit yourself, from your own exchange accounts. Phase 2 places the planned orders once the balance has arrived.
The transfer screen does handle the withdrawal fee, since what lands is never what you sent. Either you add the missing BTC yourself and the orders keep their planned sizes, or you resize every order down by the same percentage and the shortfall comes out of the profit rather than out of the purchase cost. If you top up, you can also enter the fee you paid, and every planned price rises by the same percentage so the orders earn it back. That field is in USDC while exchanges quote the fee in BTC, and the hint spells the conversion out.
Can consolidation sell my coins below their original targets?
No. Each band's price is the highest original target inside that band, rounded up to a valid price tick. This is enforced as a hard check before execution: if any lot would end up priced below its own original target, the run aborts. The cost of that guarantee is patience, since a higher price fills later.
And split? That one lowers prices, right?
By default, yes, deliberately: pieces are laddered between the cycle's break-even (fees included, plus a margin) and the original target, so lower pieces can fill earlier. No piece is ever priced below break-even, and the dry-run prints the projected revenue delta before you confirm. If you only want smaller pieces at unchanged prices, use the keep-price option.
Does this run from the app, or from the command line?
From the app. The Cycles tab carries two buttons. Reduce or move sells… opens the consolidate dialog, which covers both grouping orders on the venue you are on and moving a whole grid to another one. Split sells… is the separate button for cutting large orders into pieces.
The command line does the same work and is still there for scripting, or for the day the interface refuses to start. It needs the app closed, because it takes the database lock the app is holding.
Has this been used on a live order book?
The cross-exchange path has, once. On 24 August 2026 it moved a real grid off a venue charging 0.40 % on sells onto one charging 0.05 %: 82 open sell orders regrouped into 9, in 2,000 USDC bands, +5.86 USDC of consolidation gain, and no cycle re-listed below the price it was already waiting for.
Grouping sells on a single venue has only been exercised against exported order books so far. The code path is shared with the migration case, but that is an argument, not evidence, and the live test is planned rather than done. Read the preview screen before you confirm, which is what it is there for.
Start on any of the 7 supported exchanges
Full-featured 90-day trial · No account required to download · Grid Restructuring ships with v3.0.0 as a free update
Risk disclaimer. CryptoBot Pro is a software tool, not an investment service. Nothing on this page is financial, investment, legal, or tax advice. Cryptocurrency trading involves substantial risk of loss, and grid strategies can and do lose money, in particular in sustained downtrends. Past performance is not indicative of future results. See the Terms of Sale for the full risk disclosure.
Note. Grid Restructuring ships with v3.0.0. Behaviour described here reflects the implementation as of 25 August 2026. The July 2026 figures come from a migration performed by hand with standalone tooling. The 24 August 2026 figures come from a single run of the shipped feature on one account. Both are shown as aggregates and neither is a promise of any outcome.
Exchange note. The Binance EU wind-down under MiCA is referenced as publicly reported in 2026. Availability and regulatory status of any exchange can change; verify your venue's current status before moving funds. Exchange names are trademarks of their respective owners; no affiliation or endorsement is implied.