◆Use cases
Where this matters
The workloads that hit base-layer economics first: high transaction counts, low value each, users who notice latency.
These are the workloads where base-layer economics bite first: high transaction counts, low value per transaction, and users who notice latency. Nothing here is live yet — the network settles to Solana devnet today with no public endpoint — this is what it is being built for.
Every card also says which settlement step actually gates it. There are three, and they are not interchangeable: a signed receipt, in milliseconds, which makes the sequencer's ordering an enforceable promise rather than its word; a state root committed to Solana, in seconds, from which anyone can re-derive what happened; and the challenge window — 48 hours, with a 24-hour air gap after it — which gates one thing only — taking value off the chain. Most of the workloads below never wait for the third, and reading the exit time as this network's speed is the most common mistake made about it.
Games
A game writes constantly and quietly: a move, a craft, an item bought, a match result. Each is worth almost nothing on its own, there are enormous numbers of them, and a player notices a delay of half a second. On a shared base layer every one of those competes with a token launch happening somewhere else, and the ones that lose the race still charge the player who made them. Solieum executes an action when it is submitted and refuses what would fail, so a craft the player cannot afford is a message rather than a charge — the failure mode that reads as a broken game rather than a declined action. What is not built yet is the part that would give a title its own execution lane sized for it; that is on the target-architecture page, not this one.
High transaction count · low value each · a player waiting half a second
Gated by: the receipt, per action — play never waits on settlement. Only taking value out of the game meets the window
HFT and DeFi
Order placement and cancellation generate far more transactions than fills, and on an open fee market the ones that lose the race still pay. Solieum executes an order when it is submitted and refuses what would fail, so a quote that misses costs nothing — which for a market maker is the difference between quoting tightly and quoting defensively. The caveat is that withdrawal timing matters more here than anywhere else: about three days on the optimistic path, a 48-hour window plus a 24-hour air gap. The markets page explains the settlement classes designed around that.
Burst throughput · predictable cost · a refusal that costs nothing
Gated by: the receipt to trade — but about three days to move capital off the chain, which is the binding constraint here and the reason the validity-proof class exists
NFT minting and trading
Mints arrive in concentrated bursts that are exactly the shape of traffic that congests a base layer, and the losers of that race pay for it: on the base layer every failed transaction is charged its fee, as this site's own hourly mainnet sample shows. Solieum executes a transaction when you submit it and refuses the ones that would fail, so a mint that cannot succeed costs nothing instead of a fee.
Spiky demand · low mint cost
Gated by: the receipt to mint and trade. Finality matters when the asset leaves, not while it changes hands here
Social applications
Posts, reactions, and follows are only viable on-chain if each one costs a negligible amount. This is the clearest case for sub-cent transactions — today's flat fee on the devnet chain is 5,000 lamports, paid in SOL.
Very high volume · negligible per-action cost
Gated by: the receipt. Nothing on this path ever waits for the window
Governance
When voting is cheap, it can happen more often and include more people. Cost is a real barrier to participation in on-chain governance.
Periodic bursts · broad participation
Gated by: the root on Solana. A vote should be independently re-derivable before it counts — seconds, not days
Payments and remittances
Sending money is the workload the base layer's economics punish most bluntly: the amounts are small, the volume is enormous, and somebody is watching the screen while it happens. The honest split is that moving value between accounts here is a receipt away, while getting it out to Solana is not — a corridor that ends in cash has to be designed around the exit, not around the transfer.
High volume · low value each · a recipient waiting on it
Gated by: the receipt, between accounts on this chain. Taking the value off it waits the window and the air gap after it
Autonomous agents and machine payments
Software that transacts without a person watching it needs two things a human user does not. First, an answer before it commits: this chain executes a transaction when it is submitted, against the position it will occupy, so its simulation is exact rather than advisory and a refusal costs nothing — an agent can establish whether a plan works before spending anything on finding out. Second, a promise it can check itself: ordering issues a signed receipt for the position before execution, and the key that signs those receipts is bonded, so an agent holding two contradictory ones can prove the contradiction and take the bond without asking anyone. Between two machines the argument is rarely whether something happened; it is what order things happened in, and that is the part this chain makes provable. Metered access and per-call payment sit on top of the same rails, at a per-call cost that is still a fee-model target rather than a property.
Continuous machine-to-machine calls · an exact answer before committing · nobody available to retry
Gated by: the receipt, per call, which is the artefact the agent keeps. The window applies to the payout, not to the meter
Physical infrastructure networks (DePIN)
A fleet of sensors, hotspots or nodes reporting every few seconds produces a stream no general-purpose chain wants to carry: constant, tiny, and worth nothing individually. What the operator needs is not a block for every reading but an ordered record each device can be paid against — and what the device owner needs is that the record cannot quietly omit them, because for a network that pays for coverage, being censored and being unpaid are the same event. Two properties here speak to that directly. Every reading is answered with a signed receipt for its position, which is the artefact a reward claim is later argued from; and a device that the operator will not accept can post to the forced-inclusion inbox on Solana, which the chain must consume within a deadline or fault. A malformed or unfunded reading is refused at submission rather than charged. What is still open is the per-message cost that makes the whole thing affordable — the same fee-model question as the rows above.
Constant device reporting · a record that cannot omit a device · no human waiting on it
Gated by: the receipt, per reading. Rewards leaving the chain wait for the window; the telemetry itself never does
Signals you have outgrown the base layer
Concrete symptoms, not vibes. Two or more of these at realistic load is when the trade-off conversation is worth having.
- Fees are a visible line item in your unit economics, or users mention them unprompted.
- Your transactions fail or land late specifically during activity spikes — launches, drops, volatile hours.
- You batch, debounce, or drop user actions you would rather record on-chain.
- A single hot account — a pool, a mint, an order book — serialises your throughput.
- You are moving state off-chain that your design wanted on-chain, purely for cost.
What to measure before migrating anything
- 01
Contention profile
What fraction of your transactions touch shared accounts? That number decides how much parallelism — anywhere — can help you.
- 02
Failure cost
What does a dropped or late transaction cost you — a retry, a mispriced trade, a lost user? This sets what confirmation level each action needs.
- 03
Exit exposure
How much value would sit on the L2, and what is your tolerance for it being slow to leave during an incident? This is the security page's territory.
- 04
Composability needs
Which of your flows must touch L1 protocols atomically? Those flows stay on L1; count them before assuming everything moves.
Trading is the demanding case — the markets page covers it in full →
Building something the base layer can't hold?
Tell us the workload. If Solieum is the wrong answer for it, we would rather say so early than have you find out at launch.