Equal-Split Allocation: Boring, Fair, Correct
"Split $20 across five cases" sounds like arithmetic a child could do — four dollars each, done. Then a case costs $6, another skips on price, a third joins the list mid-month, and your scheduler fires twice. Allocation is where daily-buy bots quietly go wrong, and the fix is an accounting model old enough to have a beard: give every item a credit account.
Why naive division fails immediately
The obvious algorithm — divide today's budget by the item count, spend each share today — collides with reality on day one. Items are lumpy: a $4 share can't buy a $6 case, and it buys a $1.20 case three times with change left over. Prices move daily against fixed shares. Max-price lines legitimately block some items for days. If leftovers just vanish, expensive items on your list never accumulate at all and your real allocation drifts far from the equal weights you thought you'd chosen. If leftovers are handed to whatever else is buyable today, cheap items silently eat the expensive items' lunch — same drift, different direction.
Either way, six months later your cost basis reveals a portfolio you never designed. Allocation bugs don't crash; they compound.
The credit-account model, in plain words
The design that works treats each item like it holds a small account with the plan:
- Every day, every item receives its share as credit. Five items on $20/day: each account gets $4 of spending power, whether or not anything is buyable.
- The bot buys when an account can afford a unit. The $1.20 case buys most days. The $6 case waits, its credit building — $4, $8 — and buys on day two, entirely from its own accumulated share.
- Unspent credit carries forward. A skip — over the ceiling, no listings, wallet issue — isn't a forfeit. The credit waits for the price to come back, which is exactly how ceiling-skips convert into dip-buys later.
- No account may borrow. An item can never spend tomorrow's share today, and never spends a sibling's. Fairness is structural, not aspirational.
- A run never exceeds the day's budget. Whatever the accounts hold, actual outflow per day stays capped. Accumulated credit deploys over multiple days, not in one violent burst.
Nothing about this is clever, and that's the compliment. Each rule exists because its absence produces a specific, named failure.
The two bugs that break fairness
Retroactivity is credit granted for time before an item existed. Add a case to a three-week-old plan, and an allocator that backdates its account computes weeks of "owed" credit and fires a catch-up burst — the founder's own config edit once planned nineteen cases in a single run this way. The fix is the fresh-start clock: accrual begins at first appearance, period. That bug and its fix get a full treatment in why new items should start at zero.
Hoarding is the slow-motion twin. Credit that carries forward forever can pile up absurdly — an item priced over its ceiling for two months builds two months of dry powder, and the day it dips, the account is rich enough to distort the book. Carry-forward needs a horizon: enough memory to fund the dip-buying that makes ceilings worthwhile, not enough to turn one red day into an accidental lump sum. Between vanishing leftovers and immortal ones sits the sane default — and the daily spend cap backstops it regardless, the same layered thinking as the rest of bot safety engineering.
Both bugs share a root: treating "theoretical entitlement" as a debt the market must repay. It isn't. The schedule is a discipline, not an IOU — a distinction that matters everywhere in DCA, from missed days to missed weeks.
Why equal, though?
Fair question. Why not weight by conviction — 40% on your favorite case, slivers on the rest? You can, and a good tool lets you (in cs2stack, weighting is expressed structurally: separate plans with separate budgets, or one slot shared by a family of || alternatives). But equal-split earns its place as the default for reasons that outlast most conviction:
- Your conviction has no track record. Weighting is a forecast. Most stackers' forecasts, honestly audited, don't beat a flat split — the same humility argument that favors passive over active in the first place.
- Equal weights are self-auditing. Any position drifting far from the others flags a problem — a broken name, a chronic ceiling-skip, a liquidity drought — the moment you glance at the buy report. Bespoke weights hide bugs inside intentions.
- It removes a knob you'd fiddle. Every weight is an invitation to re-weight after a hot week — buying strength, selling weakness, donating your edge to fees. The flat split is FOMO-proof by construction.
Equal-split across a considered list, budget capped per day, credit accounts enforcing the shares: that's a strategy simple enough to run for years and strict enough to mean something when you review it. On small budgets it even decides your cadence — five items on $5/day works precisely because credit accumulates until units are affordable, which is why $5/day is not nothing.
The test that matters
Run any allocator — homegrown or purchased — for thirty days on paper, then compute each item's share of actual spending. The honest ones sit near 1/N with small, explainable wobbles (lumpy unit prices, a ceiling week). The broken ones show a case at 3% because its price never matched its share, or one at 40% because it hoovered leftovers. You told the bot "equal." The ledger tells you whether it listened — and if you can't run that check from the tool's own records, that's a ledger problem before it's an allocation one.
Boring, fair, correct — in that order, and the order is the point. Excitement in an allocator is always a bug report you haven't read yet.