Cowrie Research

steel-primary-sources-2026-05-15

3 min read

Steel primary sources

Reviewed: 2026-05-15 UTC

Official positioning

  • https://docs.boundless.network/developers/steel/what-is-steel
    • Best short official framing in this pass.
    • Used to confirm that Steel is positioned as The ZK Coprocessor for EVM apps, that it moves EVM computation offchain while preserving onchain verification, and that it is presented as a distinct developer-facing module rather than only a feature of Boundless or RISC Zero.
    • Also useful for the concrete ERC20 counter walkthrough showing the onchain-versus-offchain execution split.

Execution model / preflight / guest re-execution

  • https://docs.boundless.network/developers/steel/how-it-works
    • Best mechanism source in this pass.
    • Used to confirm the host-side preflight step, RPC-provider dependence, eth_getProof / EIP-1186 state acquisition, guest-side revm execution, Merkle-proof verification inside the zkVM, and the contract pattern where proof verification gates the downstream state transition.
    • Especially important for showing that Steel is not a blind RPC-to-proof adapter: the guest re-checks the fetched state cryptographically.

Commitment validation model

  • https://docs.boundless.network/developers/steel/commitments
    • Best source for the explicit trust anchor and onchain validation boundary.
    • Used to confirm that Steel commitments package block identifiers and digests, that validation can happen through blockhash or EIP-4788 beacon roots, and that these methods create distinct freshness windows and chain-specific requirements.
    • Important because it makes Steel’s practical liveness/freshness envelope explicit.

Historical-state extension

  • https://docs.boundless.network/developers/steel/history
    • Best source for Steel’s historical-query mode.
    • Used to confirm the execution-block versus commitment-block split, canonical-ancestor proof logic via beacon roots, the dependence on archive execution data plus beacon APIs, and the linear cycle / API-cost growth as the history gap widens.
    • This is the strongest evidence that Steel belongs in the historical-state-access comparison set, not only the generic zkVM one.

Current repo-level framing

  • https://github.com/boundless-xyz/steel
    • Best concise repo source.
    • Used to confirm that Steel now lives in a dedicated repository, is documented under Boundless, and is presented as a reusable EVM execution-proof layer with examples and separate docs for commitments, history, and events.

Crate-level API docs

  • https://risc0.github.io/risc0-ethereum/risc0_steel/
    • Useful technical reference for the library surface.
    • Used to confirm the existence of separate modules for accounts, commitments, history, events, EVM environment input, Merkle Patricia trie support, and commitment validation.
    • Helpful for grounding Steel as a concrete library/runtime surface instead of only a marketing concept.

Parent-stack integration context

Main takeaways from this pass

  • Steel is best understood as EVM execution-prover middleware with explicit state-acquisition, commitment-validation, and historical-query layers, not as a generic zk coprocessor slogan.
  • The most useful analytical split is between host-side state fetch, guest-side proof-checked execution, onchain commitment validation, and optional history extension through execution-versus-commitment block separation.
  • Steel clears the corpus bar because it makes view-call proofs, freshness windows, archive/beacon dependence, and verifier-gated application logic legible as reusable comparison layers beneath the broader Boundless / RISC Zero stack.

Graph View