Return to Merkle treeInteractive demo
Cross-chain verifier builder2025Public detailed

Solana Verifier

A STARK verifier on Solana, split into staged programs to fit compute, ownership, and transaction limits.

Reading frame

Verifier stages shaped by runtime limits

Verification had to fit tight compute budgets, strict account ownership, and proof state too large for one path.

Four verifier programs share a task pipeline. Two large accounts ping-pong state and ownership so each stage mutates only what it owns.

Boundary note
Solana compute limits force chunked execution and transaction batching instead of one monolithic verifier call.Account ownership rules mean the architecture has to encode state handoff, not just computation.
Evidence path
Verifier stage split / Ownership handoff between stages / Bidirectional stack layoutUse the repo as the artifact; linked PRs point to the pipeline split and FRI stage.
What it proves
  • Open-source evidence for cross-chain systems work
  • Source for the verifier-pipeline lab and deeper protocol interviews
System Model

How the data moves through the system

First read the data path. Then use the code hooks as pointers to the mechanisms that make the claim inspectable.

Data path
01
Stage-oriented verifier design

Runtime limits become pipeline architecture instead of helper-function sprawl.

02
Ownership and memory handoff

Account ownership and buffer layout define how verifier state moves across stages.

03
Runtime limits as system inputs

Compute ceilings, chunked loading, generated dispatch, and account limits shape the design.

Code hooks
01
Two-account ping-pong

Stages alternate between two large accounts, copy state forward, and transfer ownership.

02
Bidirectional stack layout

Task payloads use one side of the account; intermediate data uses the other.

03
Generated task dispatch

Build-generated dispatch executes typed tasks while keeping stage boundaries explicit.

04
Account-memory execution machine

Solana account data works as the verifier's RAM while generated task dispatch advances typed frames in place.

Execution Flow

How the system progresses

A short staged view of the system from start to final output.

#01
Stage 01Solana Verifier

Load proof state in chunks

Large verifier state is serialized through many instructions.

#02
Stage 02Solana Verifier

Run a staged verifier pipeline

Stages handle public input, query generation, verifier-verification, and the FRI tail.

#03
Stage 03Solana Verifier

Transfer ownership between stages

When the next stage needs writes, state moves to the account that stage owns.

Code evidence

Use the repo as the artifact; linked PRs point to the pipeline split and FRI stage.

Verifier stage splitOwnership handoff between stagesBidirectional stack layoutFRI as explicit tail stage
What to inspect in public code
  • Inspect stage boundaries, task dispatch, ownership handoff, and buffer layout under runtime limits.
  • The proof is the architecture across programs, accounts, and execution examples.
Reading order

Finish the evidence first. The full-screen environment is the closing section.

Experiment Environment

Open the full-screen environment for this project

One project mechanism, isolated from the article.