Summary: Bonsol is a Solana-side verifiable-compute control plane built around RISC Zero. The useful part is not the usual zk coprocessor pitch; it is the concrete operator surface: guest-image hosting, prover claim races, input-fetch policy, proof wrapping for Solana verification, and callback design.
What it does:
Lets developers build RISC Zero zk guest programs and register them onchain for use by Solana applications
Uses onchain deployment records that include at least the guest image id, image size, required inputs, and a public URL where provers fetch the image bytes
Lets Solana programs or offchain clients create execution requests that specify an image, inputs, tip, expiry, execution config, and optional callback behavior
Runs a prover network whose nodes watch Solana for execution requests, decide whether they want to claim them, execute the guest program, and submit proofs back onchain
Verifies proofs in a Solana program and can forward verified outputs to a developer-supplied callback program for application-specific effects
Supports multiple input modes including raw public data, Solana account data, public URLs, proof-as-input URLs, and a more trustful private-URL path through a private input server
Exposes CLI and SDK tooling for building guest programs, deploying manifests, requesting execution, and integrating Bonsol from Anchor or offchain software
Key claims:
Bonsol’s most important distinction is not merely offchain compute with proofs, but the fact that it packages a Solana-native execution market plus callback interface around that compute. The architecture docs explicitly say provers watch the chain, claim requests they find worthwhile, and race under a deadline while the tip decays after claim.
The project’s reusable mechanism is the split between request creation, prover claim policy, proof submission, onchain verification, and callback execution. That makes it more useful analytically than filing it only under RISC Zero or generic zk coprocessor branding.
The docs make the cost/composability tradeoff explicit: Bonsol starts with RISC Zero STARK proofs, then wraps them into Groth16 proofs so verification can happen natively on Solana with fixed-size proofs and low enough compute cost to compose with other programs.
The input model is another key control surface. Public inputs can come from direct bytes, Solana accounts, URLs, or prior proofs; private inputs can come through a private input server or through proof composition. This means data-origin trust and prover visibility are first-order design choices, not implementation details.
The onchain program registry is analytically important because it turns guest-image distribution into part of the protocol surface. Provers fetch image bytes from a public URL, but the bytes must match the onchain image id and size.
The docs also surface meaningful caveats instead of hiding them: the compute auction is described as a first cut whose incentive design is still being researched; URL-input security is still being hardened; and PrivateUrl inputs are only private from the public, not from the prover that fetches them.
Bonsol clears the corpus bar because it exposes a distinct design branch for Solana verifiable compute: guest-image registration, prover claim markets, callback-native composability, and data-ingest policy all matter as much as the underlying zkVM.
Whitepaper: No standalone official whitepaper was surfaced in this pass. The main primary-source packet is the official docs plus repository README, saved in ../whitepapers/bonsol-primary-sources-2026-05-13.md.