10Target architecture
Where this is going
The multi-vertical design and the institutional clearing framework Solieum is being built toward — published with what exists today beside each one, because a target stated as a fact is just a claim. Nothing on that page is live.
Solieum runs on the Solana Virtual Machine, and the reason for the verticals below is one property of that choice: an execution lane can be sized and priced for the workload on it, rather than every application bidding into one blockspace market. That is the argument. The sections below say how far along each part of it actually is, because a target published as a fact is just a claim.
01Multi-vertical support
One lane per workload, not one queue for everything
On a shared base layer a single congested application raises the price for everyone on the chain. The target is that a spike stays bounded to the contracts causing it, so unrelated protocols are not taxed by someone else's launch. Solieum charges a flat fee today and has no fee market at all, localized or otherwise — that is the first thing that has to change for any of this to mean anything.
- 01
High-frequency trading and DeFi
Target. Order books held in memory with their own execution domain, so matching is not interleaved with unrelated traffic, and a market maker's round trip is predictable rather than a race against every other bot on the chain.
Today. The matching engine exists as a library: price-time priority with an admission-sequence tiebreak, three time-in-force modes, post-only, both self-trade policies and a canonical fingerprint, under 27 tests. It is not wired to the node, so there is no market — and no latency figure has been measured, which is why none is quoted here.
What it needs. Wiring it to the sequencer, a domain per market, and a latency curve with a published method.
- 02
Gaming and immersive worlds
Target. Session-scoped execution that keeps heavy multiplayer mechanics off the shared ledger and settles the result when the session closes, so a game's frame-by-frame state never competes with financial traffic.
Today. Not built, and not decided. No accepted decision covers it.
What it needs. It is a different system class from the optimistic rollup Solieum is today, so it needs its own trust statement before it is designed, not after.
- 03
Ephemeral lanes for real-time work
Target. A lane for work that cannot wait for a block. Chosen accounts are handed to a short-lived sequencer that runs them in milliseconds, and the result is written back to the chain when the session ends. Nothing settles per block during the session, which is what makes a millisecond cadence affordable rather than a thousand times the cost.
Today. Not built, and not decided. The block interval itself is now adjustable down to milliseconds, and measured: on a local chain a transaction goes from submitted to settled in about 250 ms at a 250 ms interval, and the work inside that is tens of milliseconds. But on a chain that settles to Solana, every block is a transaction there, so a short interval multiplies cost rather than removing the wait.
What it needs. The honest part first: during such a session the fraud proof and the published data do not cover the fast sequencer, so a user's protection is whatever the hand-off lets them reclaim, not Solieum's dispute game. Saying otherwise would be false. A decision has to answer that, and whether an account handed over can still be reached by the forced-inclusion queue that exists so nobody can be censored.
- 04
NFT mints and secondary markets
Target. A mint that sells out in ninety seconds stays inside its own lane, so the people trading in the next lane never see the price of a block move.
Today. The isolation this depends on is the same missing fee model as above. The measured base-layer behaviour it is meant to fix is on the failed-transactions page, re-taken every hour, where every failure pays its fee.
What it needs. Per-contract pricing, and the throughput ceiling arithmetic to size a lane honestly.
- 05
Social and micro-interaction feeds
Target. Account-state compression, so hundreds of millions of small updates cost something a social product can actually afford.
Today. Not built. There is a compression crate in the tree, but it is a data-availability payload codec — it makes published bytes smaller, which is a different thing from compressing account state.
What it needs. A design and an accepted decision.
- 06
AI and machine-to-machine data
Target. Streaming corridors for agents writing verification footprints, with the heavy data held on a sub-layer rather than the main one.
Today. Not built, and this one runs into an existing decision rather than a missing one: external data availability was rejected, because a second data provider becomes a second thing you have to trust and 'secured by Solana' stops being true. One exception is pre-authorised — a per-market validium, disclosed on that market's own page.
What it needs. Either that disclosed per-market route, or reversing the decision in the open.
- 07
Budgets an agent cannot exceed
Target. Per-agent spend and rate limits enforced by the chain rather than by the agent's own code, so a key held by autonomous software is bounded by something it cannot edit. The admission gate is the natural place for it: it already runs a transaction before anything is charged, which is exactly where a policy check belongs.
Today. Not built. The gate exists and refuses what would fail, but it enforces no per-sender policy — the decision record lists a per-payer admission rate limit and a per-transaction compute ceiling as the next two guards and says plainly that neither is written. Until they are, a public endpoint wants a rate limit in front of it.
What it needs. Those two guards, and a policy model that survives the question of who may change a limit and how fast.
- 08
Physical infrastructure networks
Target. A high-density lane for real-time device telemetry, so a fleet of sensors reporting continuously does not compete with settlement traffic.
Today. Not built, and not decided.
What it needs. An accepted decision. The throughput arithmetic to size it already exists in the node.
02Institutional clearing
A clearing framework, and why none of it is claimed yet
The target is to do a clearing house's job inside the protocol rather than in an end-of-day pipeline: margin watched as trades execute, offsetting positions netted continuously, and an institution able to trade without publishing its book to the world. None of it exists. It is written down here rather than quietly, because a clearing house makes promises about other people's money and the promises should be visible before the code is.
- 01
Real-time risk and cross-margin
Target. Margin evaluated as execution happens rather than at a block boundary, with partial liquidations that step in early enough to stop one account's loss becoming everyone's bad debt.
Today. Nothing. There is no margin engine, no position model and no liquidation path.
What it needs. The state machine, and a published answer to the question a regulator asks first: what happens to a liquidation cascade while the sequencer is down.
- 02
Continuous netting and an insurance pool
Target. Offsetting contracts netted across participants so the ledger carries positions rather than every leg, with netted exposure backed by an insurance pool on Solana.
Today. Nothing.
What it needs. Netting trades data cost against the audit trail, and regulated markets keep that trail — so the trade-off has to be decided in the open. The pool needs a funding source and a published loss waterfall before it is worth the name.
- 03
Compliance gates and private institutional flow
Target. Permissioned environments where an allocator proves who it is off-chain, receives a zero-knowledge credential, and clears at size without publishing proprietary positions.
Today. Nothing. There is no identity system of any kind.
What it needs. This is the hardest of the three to publish honestly. A permissioned lane inside a permissionless rollup changes who can be excluded and by whom, and it meets forced inclusion — which exists precisely so that nobody can be excluded — head-on. That interaction gets decided before the feature is described as a product.
03Order of operations
How something here becomes real
In this order: an accepted decision record first, the blueprint's reconciliation table second, this site third. Anything that arrives on the site before those two has skipped the part that makes it checkable. Where this page and a decision record disagree, the record governs until a new one supersedes it.