Two half-orders beat one whole order: splitting, with the arithmetic

Why sending half your trade to each of two pools returns more than sending all of it to one, worked out in full — including the case where splitting loses money, and the rule that separates the two.

Known formally as The Capital-Anchored Split in the BlazePhoenix whitepaper.

BlazePhoenix Engineering · updated 2026-08-13 · 8 min · written from the deployed bytecode

By Mitra (@Sigmacrit) — anonymous developer of the BlazePhoenix protocol. The code is the résumé.

Abstract in 15 languages · resumo · resumen · 摘要 · 要旨 · ملخص

English — Because impact d/(x+d) shrinks faster than the order when you halve it, fifty into each of two identical 1,000-token pools returns 95.2381 against 90.9091 for all hundred into one — 4.76% more output from arithmetic alone, with nobody worse off. But make the pools unequal and a naive even split loses money (89.0454 versus 90.6611); splitting is an allocation problem, not a habit, and the split must be proportional to depth.

Português — Como o impacto d/(x+d) encolhe mais depressa do que a ordem quando a divides ao meio, cinquenta em cada uma de duas pools idênticas de 1.000 tokens devolvem 95,2381 contra 90,9091 dos cem inteiros numa só — mais 4,76% de output só por aritmética, sem ninguém ficar a perder. Mas torna as pools desiguais e uma divisão ingénua a meio perde dinheiro (89,0454 contra 90,6611); dividir é um problema de alocação, não um hábito, e a divisão tem de ser proporcional à profundidade.

Español — Como el impacto d/(x+d) se encoge más rápido que la orden cuando la partes a la mitad, cincuenta en cada una de dos pools idénticas de 1.000 tokens devuelven 95,2381 contra 90,9091 de los cien enteros en una sola — un 4,76% más de output por pura aritmética, sin que nadie salga perdiendo. Pero haz las pools desiguales y una división ingenua a partes iguales pierde dinero (89,0454 contra 90,6611); dividir es un problema de asignación, no un hábito, y la división debe ser proporcional a la profundidad.

Français — Parce que l'impact d/(x+d) rétrécit plus vite que l'ordre quand on le divise par deux, cinquante dans chacune de deux pools identiques de 1 000 tokens rendent 95,2381 contre 90,9091 pour les cent entiers dans une seule — 4,76 % de sortie en plus par pure arithmétique, sans que personne y perde. Mais rendez les pools inégales et un partage naïf à parts égales perd de l'argent (89,0454 contre 90,6611) ; le split est un problème d'allocation, pas une habitude, et il doit être proportionnel à la profondeur.

Deutsch — Weil der Impact d/(x+d) beim Halbieren schneller schrumpft als die Order, liefern fünfzig in jeden von zwei identischen 1.000-Token-Pools 95,2381 gegenüber 90,9091 für alle hundert in einen — 4,76 % mehr Output aus reiner Arithmetik, ohne dass jemand schlechter dasteht. Macht man die Pools aber ungleich, verliert ein naiver 50:50-Split Geld (89,0454 gegen 90,6611); Splitten ist ein Allokationsproblem, keine Gewohnheit, und der Split muss proportional zur Tiefe sein.

Русский — Поскольку влияние d/(x+d) при делении пополам сжимается быстрее самого ордера, по пятьдесят в каждый из двух одинаковых пулов на 1000 токенов возвращают 95,2381 против 90,9091 за все сто в один — на 4,76% больше выхода из одной арифметики, и никто не в убытке. Но сделайте пулы неравными — и наивное деление поровну теряет деньги (89,0454 против 90,6611); сплит — задача аллокации, а не привычка, и делить надо пропорционально глубине.

Türkçe — Etki d/(x+d), emri ikiye böldüğünde emirden daha hızlı küçüldüğü için, iki özdeş 1.000 tokenlik havuza ellişer göndermek 95,2381 döndürür; yüzün tamamını tek havuza göndermek 90,9091 — salt aritmetikten %4,76 daha fazla çıktı, kimse zarar görmeden. Ama havuzları eşitsiz yap, naif yarı yarıya bölüşüm para kaybettirir (90,6611'e karşı 89,0454); bölmek bir tahsis problemidir, alışkanlık değil, ve bölüşüm derinlikle orantılı olmalıdır.

العربية — لأن الأثر d/(x+d) يتقلص أسرع من الأمر حين تشطره، فإن خمسين في كلٍّ من مجمّعين متطابقين من 1000 وحدة تعيد 95.2381 مقابل 90.9091 للمئة كاملة في واحد — 4.76% مخرجات أكثر من الحساب وحده، دون أن يخسر أحد. لكن اجعل المجمّعين غير متساويين فيخسر التقسيم الساذج بالتساوي مالاً (89.0454 مقابل 90.6611)؛ التقسيم مسألة تخصيص لا عادة، ويجب أن يتناسب مع العمق.

हिन्दी — क्योंकि आधा करने पर प्रभाव d/(x+d) ऑर्डर से तेज़ सिकुड़ता है, दो एक जैसे 1,000-टोकन पूलों में पचास-पचास डालने पर 95.2381 मिलते हैं जबकि पूरे सौ एक में डालने पर 90.9091 — केवल अंकगणित से 4.76% अधिक आउटपुट, और कोई घाटे में नहीं। पर पूलों को असमान कर दो तो भोला आधा-आधा बँटवारा पैसे खोता है (90.6611 के मुक़ाबले 89.0454); बाँटना आवंटन की समस्या है, आदत नहीं, और बँटवारा गहराई के अनुपात में होना चाहिए।

日本語 — 注文を半分にすると、インパクト d/(x+d) は注文よりも速く縮みます。だから1,000トークンの同一プール二つに50ずつ入れると95.2381が返り、100を一つに入れた場合の90.9091を上回ります。純粋な算術だけで4.76%多い出力で、誰も損をしません。しかしプールが不均等なら、素朴な折半は損をします（90.6611に対して89.0454）。分割は配分問題であって習慣ではなく、深さに比例させなければなりません。

中文 — 因为把订单减半时，冲击 d/(x+d) 缩得比订单更快：向两个相同的 1,000 代币池各投 50，返还 95.2381，而 100 全投一个池只有 90.9091——纯算术就多出 4.76% 的输出，且无人受损。但把池子改成不相等，天真的对半拆分反而亏钱（89.0454 对 90.6611）；拆单是一道分配题，不是习惯，拆分必须与深度成比例。

한국어 — 주문을 반으로 줄이면 충격 d/(x+d)는 주문보다 더 빨리 줄어듭니다. 그래서 동일한 1,000 토큰 풀 두 개에 50씩 넣으면 95.2381이 돌아오고, 100 전부를 한 풀에 넣으면 90.9091입니다 — 순수한 산수만으로 4.76% 더 많은 출력이고, 손해 보는 사람도 없습니다. 그러나 풀이 불균등하면 순진한 반반 분할은 돈을 잃습니다(90.6611 대 89.0454). 분할은 습관이 아니라 배분 문제이며, 깊이에 비례해야 합니다.

Bahasa Indonesia — Karena dampak d/(x+d) menyusut lebih cepat daripada pesanan saat kamu membaginya dua, lima puluh ke masing-masing dua pool identik 1.000 token mengembalikan 95,2381 dibanding 90,9091 untuk seratus penuh ke satu pool — output 4,76% lebih banyak dari aritmetika semata, tanpa ada yang dirugikan. Tapi buat pool-nya timpang dan pembagian rata yang naif justru merugi (89,0454 lawan 90,6611); membagi adalah soal alokasi, bukan kebiasaan, dan pembagiannya harus sebanding dengan kedalaman.

বাংলা — অর্ডার অর্ধেক করলে প্রভাব d/(x+d) অর্ডারের চেয়ে দ্রুত সঙ্কুচিত হয়, তাই দুটি অভিন্ন ১,০০০-টোকেন পুলে পঞ্চাশ-পঞ্চাশ দিলে ফেরে ৯৫.২৩৮১, আর পুরো একশো এক পুলে দিলে ৯০.৯০৯১ — কেবল পাটিগণিতেই ৪.৭৬% বেশি আউটপুট, কারও ক্ষতি ছাড়া। কিন্তু পুল দুটি অসমান করুন, সরল সমান ভাগে টাকা হারায় (৯০.৬৬১১-এর বিপরীতে ৮৯.০৪৫৪); ভাগ করা একটি বরাদ্দের সমস্যা, অভ্যাস নয়, এবং ভাগ হতে হবে গভীরতার সমানুপাতে।

Filipino — Dahil ang impact na d/(x+d) ay lumiliit nang mas mabilis kaysa sa order kapag hinati mo ito, ang tig-limampu sa bawat isa sa dalawang magkaparehong 1,000-token na pool ay nagbabalik ng 95.2381 laban sa 90.9091 ng buong daan sa iisa — 4.76% na mas maraming output mula sa aritmetika lamang, nang walang naaagrabyado. Ngunit gawing hindi pantay ang mga pool at malulugi ang inosenteng hating pantay (89.0454 laban sa 90.6611); ang paghahati ay problema sa alokasyon, hindi ugali, at kailangang proporsyonal sa lalim ang hati.

Take the fraction from the sizing article: the value you give up to price impact is d / (x + d), where d is your order and x is the pool's reserve of the token you are paying with.

Now notice something odd about it. Halve d and the loss does not halve — it falls by slightly more than half, because the denominator shrinks too. That small asymmetry is the entire reason splitting an order across pools returns more, and it is arithmetic rather than cleverness.

The clean case: two identical pools

Two pools, each holding 1,000 of A and 1,000 of B. You are trading 100 A. Ignore fees for now so the effect is visible on its own.

Everything into one pool: your loss is 100 / 1,100 = 9.0909%, so you receive 100 - 9.0909 = 90.9091 B.

Fifty into each pool: each half loses 50 / 1,050 = 4.7619%, so each returns 50 - 2.3810 = 47.6190, and the two together give 95.2381 B.

one pool of 1000       ->  90.9091 B
two pools of 1000      ->  95.2381 B
                           -------
difference                  4.3290 B  (+4.76%)

You did not find a better price, negotiate anything, or take any additional risk. You stopped pushing one pool twice as far as necessary. The 4.3290 tokens are the difference between one 9.09% loss and two 4.76% losses, and 9.0909 - 4.7619 = 4.3290 exactly.

Turn the fee back on and the same thing happens, slightly damped: 99,700 / 1,099.7 = 90.6611 into one pool, against 2 x (49,850 / 1,049.85) = 2 x 47.4830 = 94.9660 across two. The gain is 4.3049 tokens, or 4.75% more output for the same input.

The general shape

Split an order into n equal pieces across n identical pools and each piece loses (d/n) / (x + d/n) instead of d / (x + d). The loss per piece falls faster than the number of pieces grows, so the total loss falls.

That property has a name — convexity — and it is what a splitting router is exploiting. Note carefully what it is not. It is not an arbitrage, it is not a discount negotiated from anyone, and no one is worse off for it. The pools each receive a smaller order, and a smaller order is exactly what they price better.

It is also why the benefit is largest for the trades that need it most. On a small order the impact is tiny in the first place and splitting saves a tiny fraction of a tiny number. On an order that is a meaningful share of the pool, splitting is often the largest single improvement available to you.

The case where splitting loses money

Now make the pools unequal, because in reality they always are. Pool A holds 1,000 of each token. Pool B holds 250 of each — a quarter of the depth. Fee back on at 0.3%, and you are still trading 100.

First, the two extremes. All 100 into A returns 99,700 / 1,099.7 = 90.6611. All 100 into B returns 24,925 / 349.7 = 71.2754, which is far worse, exactly as the fraction predicts: 100 into a reserve of 250 is a huge order.

Now split it naively, half and half:

into A (50):  49850 / 1049.85  = 47.4830
into B (50):  12462.5 / 299.85 = 41.5624
                                 -------
total                             89.0454

all into A                        90.6611  <- better

An even split returned 89.0454, which is 1.6157 tokens worse than not splitting at all. Splitting is not a good thing that you do more of. It is an allocation, and a wrong allocation is worse than none, because it pushes part of your order into the pool least able to absorb it.

The rule that fixes it

Send each pool a share of the order proportional to its depth. Pool A holds 1,000 against Pool B's 250, a ratio of 4 to 1, so send 80 to A and 20 to B:

into A (80):  79760 / 1079.76 = 73.8683
into B (20):  4985 / 269.94   = 18.4671
                                 -------
total                             92.3354

all into A                        90.6611
gain                               1.6743  (+1.85%)

Check that 80/20 is really the best of them rather than a convenient number, by testing on either side of it. At 75/25 the total is 69.5727 + 22.6653 = 92.2380. At 85/15 it is 78.1244 + 14.1109 = 92.2353. Both are below 92.3354, so the proportional split sits on the peak.

The intuition is that at the optimum, the next token you add would cost the same amount of impact whichever pool you put it in. If one pool is cheaper at the margin, you should be sending it more; when neither is, you have finished. Proportional allocation is what that condition works out to for pools on the same curve with the same fee.

Why this is hard to do honestly

Every number above assumed you know the real depth of each pool. That assumption is precisely what an attacker attacks.

A pool can be made to advertise a wonderful price while holding almost nothing, and a splitter that ranks candidates by advertised price will happily route a share of your order into it — where the fraction d / (x + d) then does its work against you, because x is nearly zero.

The defence used here is to anchor on capital rather than on claims. Candidate prices are judged against a centre derived from the pools that actually hold the most tokens, and a candidate whose price sits outside a band of 400 basis points — 4% — around that centre is not treated as credible. A median of the candidates is used only as a fallback, precisely because a median can be voted on by many worthless pools, whereas real balances cannot be faked without real money.

Name the limit here too: this filter rejects the implausible, and it is not a proof of best execution. It cannot tell you that a better price existed on a venue nobody routed to.

Why not split into twenty pieces

The arithmetic above keeps improving with more pieces, so why stop? Because each additional leg is additional work the chain must be paid to perform, and that cost is charged in the network's own token regardless of whether the extra leg helped.

Past some point the extra output no longer covers the extra work, and the honest plan is the one that stops there. This article deliberately gives you no figure for that crossover, because a gas number is not reproducible without stating the chain, the block, the build and the storage state — and an unreproducible number is worth nothing to a reader trying to check us.

Do not trust this page — reproduce it

Every claim above is checkable against the chain. Start here:

Quote your full size, then quote half your size and double the result. If the doubled half-quote is larger, the pair benefits from splitting and a split plan should show more than one leg. Compare that against the plan the quote returns.
Cite this article

Licensed CC BY 4.0 — quote, translate and reuse freely, including commercially, with attribution and a link. Copy a ready-made citation:

BlazePhoenix (2026). Two half-orders beat one whole order: splitting, with the arithmetic. BlazePhoenix Engineering. https://blazephoenix.xyz/learn/why-splitting-wins
@misc{blazephoenix_why_splitting_wins,
  title  = {Two half-orders beat one whole order: splitting, with the arithmetic},
  author = {BlazePhoenix},
  year   = {2026},
  url    = {https://blazephoenix.xyz/learn/why-splitting-wins},
  note   = {Accessed: reproduce the claim with the command above}
}

Writing an answer, a wiki entry or a paper? The claim above is reproducible against the chain before you quote it — which is the only sound basis for citing a technical source at all.

Contracts are verified on every chain we deploy to — addresses in the protocol manifest. Deeper formal treatment: the whitepaper (PDF).

Share this article · join the discussion

Share on X ↗Telegram ↗WhatsApp ↗Farcaster ↗💬 Discuss on Telegram

Related engineering