Cowrie Research

bonsol-primary-sources-2026-05-13

5 min read

Bonsol primary sources — 2026-05-13

What I reviewed

Key takeaways from primary sources

  • Bonsol is best understood as a Solana-native verifiable-compute control plane, not merely as a thin wrapper around RISC Zero. The docs repeatedly frame it as a way to request offchain computation, let provers claim and run the job, and then verify the result on Solana with optional callback-driven side effects.
  • The project’s most reusable mechanism is the split between guest-image registration, execution-request creation, prover claiming, proof compression/verification, and callback delivery into downstream Solana programs.
  • The prover network is not hidden behind generic decentralization language. The architecture docs explicitly say provers watch the chain, decide which execution requests are worth claiming, and race under a deadline while the request’s tip decays after claim.
  • Bonsol’s proof pipeline matters analytically. The what is Bonsol docs explain that Bonsol starts from RISC Zero STARK proofs and wraps them into Groth16 proofs for Solana-native verification, which makes verifier economics and composability part of the actual product surface.
  • Input sourcing is a key trust/control surface. Public inputs can come from bytes, Solana accounts, URLs, or prior proofs; private inputs can come from a private input server or proof composition. The docs are explicit that PrivateUrl hides inputs from the public but not from the prover that fetches them.
  • The project is candid about maturity and open design questions. The architecture page calls the compute auction a first cut and says the team is still researching the best incentive model.

Specific source signals worth retaining

1) Official landing page

  • URL: https://bonsol.sh/
  • Key signals:
    • Frames Bonsol as Everything Possible on Solana and Prove Anything.
    • Says Bonsol uses zk(risc0) to prove computations that are impossible to run onchain.
    • Emphasizes Solana integration and developer tooling rather than only prover benchmarks.
  • Why it mattered:
    • The site makes clear that the project is positioning itself as a Solana coprocessor / composability layer, not just as a proving library.

2) What is Bonsol?

  • URL: https://bonsol.sh/docs/explanation/what-is-bonsol
  • Key signals:
    • Calls Bonsol a ZK co-processor for Solana.
    • Describes the high-level flow: developers create RISC Zero zk programs, register them with Bonsol, users request execution, provers generate STARK proofs, Bonsol wraps them into a SNARK, and Solana verifies the result.
    • Says Groth16 conversion gives constant-size proofs and fast onchain verification, with a claim that verification can happen in less than ~200k compute units.
    • Explains input-digest verification as an integrity check so malicious provers cannot quietly swap inputs.
  • Why it mattered:
    • This is the clearest primary-source explanation of the STARK-to-SNARK compression layer and of why Bonsol is shaped specifically around Solana verifier constraints.

3) Architecture page

  • URL: https://bonsol.sh/docs/explanation/bonsol-architecure
  • Key signals:
    • Describes Bonsol as both tooling/libraries and a prover network.
    • Says provers watch the chain for execution requests and claim the ones they judge worthwhile.
    • Says the first prover to claim gets a bounded amount of time to submit the proof; if it misses the deadline another prover can claim.
    • Says the tip value falls according to a curve after claim to incentivize faster proving.
    • Lists the main components: prover, verifier, callback program, private input server, and program registry.
  • Why it mattered:
    • This page exposes the real economic and control surfaces: job selection, claim timing, tip decay, callback power, and data-serving dependencies.

4) Input-types documentation

  • URL: https://bonsol.sh/docs/explanation/bonsol-input-types
  • Key signals:
    • Public inputs can come from raw bytes, Solana account data, URLs, or prior proofs.
    • URL-origin verification is still incomplete; current docs say the best available mitigation is input-hash verification.
    • PrivateUrl requires the prover to authenticate to a private-input server, but the docs explicitly warn that the input is no longer globally private once a prover sees it.
    • Proof inputs are treated specially and currently are not added to the execution request input hash.
  • Why it mattered:
    • This page makes Bonsol useful for the corpus because it surfaces concrete data-ingest and privacy caveats rather than flattening everything into generic private compute language.

5) Tutorial / callback flow

  • URL: https://bonsol.sh/docs/tutorials/a-taste-of-bonsol
  • Key signals:
    • Shows an Anchor program requesting execution from the Bonsol channel program and later receiving a callback after proof verification.
    • Demonstrates ExecutionConfig and CallbackConfig as application-facing interfaces.
    • Shows how verified outputs can directly trigger downstream program logic like token minting.
  • Why it mattered:
    • This is the clearest proof that callbacks are not a minor feature; they are the main application-facing bridge from verified offchain compute back into Solana state transitions.

6) Repository README

  • URL: https://raw.githubusercontent.com/bonsol-collective/bonsol/main/README.md
  • Key signals:
    • Calls Bonsol a Solana-native verifiable computation framework.
    • Emphasizes the decentralized prover network plus developer toolkit.
    • Lists use cases such as verifiable agents, storage proofs, provable game engines, private liquidity pools, and cross-chain activity proofs.
  • Why it mattered:
    • The README is the best concise statement that Bonsol should be treated as a framework plus network, not only as a single prover or SDK.

Working conclusion

Bonsol belongs in the corpus because it makes a distinct Solana-specific verifiable-compute stack legible: guest-image registry, execution-request accounts, prover claim races, optional private-input servers, STARK-to-Groth16 verifier compression, and callback-based program composition. The durable insight is that the important control surface is not only the zkVM, but the entire path from request intake to proof economics to callback-mediated downstream execution.

Graph View