◆Base layer
About Solana
Solieum settles on Solana, so Solana's properties are the foundation. A short primer for anyone evaluating what that inheritance is worth.
Solieum settles on Solana, so Solana's properties are Solieum's foundation. This page is a short primer on what the base layer does and where a Layer 2 adds headroom — written for people evaluating Solieum, not as a Solana tutorial.
◆How it works
Proof of History
A verifiable ordering of events that lets validators agree on sequence without round-tripping to agree on time. It is what allows the rest of the pipeline to run as fast as it does.
Stake-weighted consensus
Validators participate in proportion to stake, with holders delegating to them. Security scales with the value staked behind the network. Solieum has no validator set of its own and will not add one: Solana's is the one that decides finality.
Parallel execution
Transactions declare the accounts they read and write, so non-overlapping transactions execute simultaneously. This is the source of Solana's throughput — and its limit, since transactions contending for the same account still serialise.
Low fees by design
Fees are small enough that applications can put activity on-chain that would be uneconomic elsewhere. Under contention, priority fees rise and that assumption weakens.
Where a Layer 2 adds something
Solana's constraint is rarely raw speed — it is contention. Popular accounts serialise, spikes exceed inbound capacity, and the applications that suffer most are the ones generating the most transactions. Moving those workloads to a separate execution environment removes them from the contention set entirely, while still settling on Solana.
Figures often quoted for base-layer throughput are theoretical maxima measured under favourable conditions. Real throughput depends on how much the workload contends for the same accounts — which is exactly why Solieum publishes its own numbers as a curve rather than a peak.
◆Vocabulary
Terms you will meet
Four more pieces of Solana vocabulary that matter when reasoning about a Layer 2 on top of it.
Slots and epochs
A slot is the (~sub-second) interval in which a leader may produce a block; epochs group thousands of slots for staking and schedule purposes. Solieum's own slots are a different clock — the compatibility matrix covers the difference.
Leader schedule
Solana knows in advance which validator leads each slot. Transactions race toward that leader — which is why congestion shows up as drops in transit, not queues at a gate.
Priority fees
Under contention, transactions bid extra for inclusion. It works, and it means "low fees" is a statement about the quiet hours. An L2 moves whole workloads out of that auction.
Commitment levels
processed → confirmed → finalized, in increasing certainty. Solieum's settlement cares about the last one: a root is only as final as the L1 block it lives in. The devnet node submits and polls at confirmed, then reads its head back from the settlement program's own account; treating a root as final waits for Solana's finality plus the challenge window.
What Solieum actually asks of Solana
Three services, nothing exotic: a place to publish data so anyone can verify, a court that can check one disputed instruction and settle who is right, and a vault that locks deposits and honours proven withdrawals — plus a fourth the design added, a queue the sequencer cannot close, so a censored transaction still lands. All four are Solana programs on devnet today, the vault initialized and holding its rent reserve. Everything else — execution, ordering, state — happens on Solieum. That division of labour is the entire design: Solana does the parts that need maximum trust, Solieum does the parts that need maximum throughput.
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.