Why static allocations don't scale
Fixed capital allocations are simple to understand, but they become increasingly limiting as an automated system manages more opportunities.
Capital allocation looks simple when a system manages only a few opportunities.
Choose how much capital each part can use, define limits and let it operate. The approach is attractive precisely because it is predictable.
As Oblivion grew into a multi-bot system, however, I started seeing the limitations of treating capital as permanently fixed buckets.
Static allocation made the early system easier to reason about. It also made the system less flexible than the market it was operating in.
Opportunities are uneven
Markets do not distribute opportunity evenly.
One asset may remain quiet while another becomes highly active. A pair that used capital efficiently last month may spend much of the next month doing very little.
A fixed allocation ignores that difference because capital remains assigned according to a decision made in the past.
The system may be technically respecting its configuration while still using capital poorly.
Boundaries still matter
Static allocation is not useless.
It creates clear boundaries, makes exposure easier to understand and prevents one component from consuming resources intended for another. Those safeguards matter, especially when automation is involved.
The problem is not that fixed limits are bad.
The problem is that fixed limits become increasingly incomplete as the system starts managing more assets, more bots and more market conditions.
Allocation becomes a portfolio question
Once several bots operate simultaneously, allocation stops being only a configuration setting.
It becomes a portfolio-level question. How much should remain available? How much can be committed? When does unused capacity represent safety, and when does it represent missed opportunity?
These questions do not have universal answers.
More flexibility can improve capital usage while also creating new forms of risk. More restriction can improve safety while also preventing the system from adapting when opportunity shifts.
Scaling changes the tradeoff
The tradeoff changes as the platform grows.
With one bot, a static allocation can be simple and reasonable. With several bots, the same model can start hiding inefficiencies. With a broader portfolio, allocation begins to look less like a setting and more like an ongoing decision process.
That realization shaped how I thought about Oblivion.
The goal was not to remove limits. The goal was to make limits smarter without making the system impossible to understand.
Looking back
Static allocation was useful because it made the early system understandable.
Its limitations only became obvious as scale changed the nature of the problem.
That pattern appears often in software. A simple rule can be exactly right at one stage and quietly limiting at the next.