About Solana

The base layer Solieum settles to, and the specific properties a rollup on it depends on.

This page is not a general introduction to Solana. It covers the properties of the base layer that Solieum's design depends on, because those are the ones whose failure would be Solieum's failure too.

The properties Solieum depends on

Fast, cheap writes. A rollup settles constantly: a state root and a batch per block. Solana's base fee of 5,000 lamports per signature and its sub-second block time are what make settling every few seconds affordable at all. On a base layer with minute-scale blocks and dollar-scale fees, the same design would settle far less often and confirmations would be correspondingly weaker.

A compute budget large enough to verify one instruction. The whole fraud proof design rests on a single Solana transaction being able to verify one disputed step from Merkle witnesses. A Solana transaction has 1,400,000 compute units. A witnessed one-step verification measures 19,216 units for a system transfer and 20,408 for an SPL-token transfer on the sorted-leaf tree, and several times that on the sparse tree the current chain uses. In every measured case it fits inside one transaction, which is the load-bearing feasibility claim of the entire system.

Account-model state with rent. Solieum's settlement records are Solana accounts, and their rent is the dominant cost of running the chain. That is a base-layer property with a direct economic consequence, covered in Fees, Economics and the Token.

Program-derived addresses and cross-program invocation. The dispute program's verdicts reach the settlement program only by cross-program call from a pinned address, so a direct key cannot inject one. The bridge's deposit path signs for a relay address that only the portal program can sign for. Both controls are base-layer primitives, not Solieum inventions.

The properties that constrain it

No blob market. Ethereum rollups post data to a market built for them. Solana has no such market, so Solieum's batch data competes with ordinary traffic in ordinary transactions, inside a 1,232-byte packet limit. This is the largest architectural difference between a Solana rollup and an Ethereum one, and it is why this paper refuses to publish a throughput number without a cost model behind it.

Halts. Solana has halted. The longest on record is on the order of 19 hours. A challenge window denominated in wall-clock seconds would spend that time on hours in which nobody could have challenged. Solieum's window and its dispute deadlines are denominated in slots for exactly this reason: a halted chain produces no slots, so a move deadline freezes, an honest party cannot be timed out, and the window cannot run out while nobody could act.

Slot time is a target, not a guarantee. The 400-millisecond figure is the target. On public devnet, slots measured about 166 milliseconds over a 500,000-slot sample, so the 432,000-slot window that is 48 hours at the mainnet target runs about 20 hours of wall-clock there. Every duration this paper quotes in hours is at the 400-millisecond target, and says so where it matters.

Solana's own failure modes are inherited. A deep reorg or a runtime bug on Solana is a Solieum problem, and nothing in Solieum's design addresses it. That is the price of settling somewhere.

On Solana's throughput numbers

Solana's documentation quotes a theoretical ceiling around 65,000 transactions per second. Measured sustained throughput of real user transactions has run an order of magnitude below that. Both facts are ordinary for any blockchain, and neither is a criticism.

This paper does not compare a Solieum figure against either one. The reason is in Why Solana Needs a Layer 2: a rollup's ceiling is set by what it costs to publish data on the chain it settles to, and a comparison table that ignores that is a comparison of two unrelated numbers.