Solve Framework

Solve, Solieum's main framework, and its Cradle toolchain: what they produce for Solana runs on Solieum unchanged.

Solve is the main framework for building on Solieum. Programs are written in its language, CradleScript, and its toolchain, Cradle, compiles them to native programs for more than one chain, Solana among them. It has its own site at solvelang.com and a web IDE at cradle.solvelang.com, and those are the source of truth for the language itself.

This page covers only the part that belongs in a Solieum paper: what happens when you point that toolchain at a Solieum chain.

The claim, and how it was tested

The artifact Cradle produces for Solana is the artifact Solieum executes, unchanged.

On 5 September 2026 a counter contract written in CradleScript was compiled by Cradle to a native Solana program, built to SBF with the standard toolchain, registered on a local Solieum chain, and driven through Cradle's own seven-step conformance scenario.

The program was not edited. Its instruction encoding was not edited. The client that drove it was Cradle's own harness client with the transport swapped.

All seven steps passed: initialize with an owner, read a zero count, refuse an underpaid increment, accept a paid one, accept an overpaid one, refuse a reset from a non-owner, accept a reset from the owner. Every block in the run settled to its Layer 1.

Three things in that run were Solieum's, not Solana's

The two refusals cost nothing and left no record. The underpaid call and the non-owner reset came back at submit time as the program's own custom errors, with the program's own logs. On a Solana cluster those are two failed transactions, charged and recorded forever. Here they never entered a block, because execution happens at admission and a failing transaction is refused rather than included.

Every block settled. Each block of the run went to its Layer 1 as a published batch and a committed root. A local run is not a devnet run, but the settlement path exercised is the same one.

The program was registered, and the chain said what that costs. A program registered at node start is reported by getChainInfo together with the caveat that steps through it are opaque to the dispute game. It is a local chain's convenience, and the node prints the limitation rather than letting it be inferred.

What this does and does not show

It shows compatibility at the level that matters: a compiler targeting Solana does not need a Solieum target, a Solieum SDK, or a Solieum dialect. It shows the same for the client side, where only the transport changed.

It does not show a deploy path on the public devnet chains. Programs are registered at node start today, not deployed by a transaction, and that is the next step for this path rather than a solved one.

It also does not extend the dispute game. A step through a registered program is opaque until the one-step classes cover it. Running third-party programs on a Solieum chain and defending every step of them in a dispute are two different maturity levels, and this paper keeps them apart.

Why Solve targets Solana rather than a Solieum dialect

Solve is Solieum's main framework, and it still compiles to Solana. The execution environment is Solana's and the artifacts are Solana's, so what Solve produces for a Solieum chain is an ordinary Solana program, and the counter run is the evidence that this is real rather than rhetorical.

Being the main framework is not being the only way in. Anchor programs, native Rust programs and anything else that produces a Solana .so are in exactly the same position on a Solieum chain.

An earlier version of this page showed Solve installed from a Solieum package registry, with a code sample using macros from a Solieum crate. No such package or crate exists: Solve is CradleScript and the Cradle toolchain, as described above.