Summary: Steel is worth cataloging not as just another RISC Zero example, Boundless developer convenience, or generic zk coprocessor label, but as the module that turns EVM view calls into explicit offchain execution proofs anchored to verifiable block commitments. The current Boundless and RISC Zero docs describe a flow where host-side preflight pulls account and storage data from an RPC provider plus eth_getProof, packages that data into an EVM environment, guest-side revm execution inside the zkVM re-checks the Merkle proofs and runs the view-call-dependent logic, and the resulting proof is only accepted onchain after the contract validates a Steel commitment via blockhash or EIP-4788 beacon roots. Steel History extends the same pattern by separating the execution block from the commitment block and proving the older execution state is a canonical ancestor of a still-verifiable recent commitment block. That makes Steel a useful comparison point for Herodotus, Relic Protocol, Brevis, generic zkVM runtimes, and onchain data-coprocessor stacks because the real control surfaces are preflight state selection, RPC and beacon endpoint dependence, commitment-window limits, archive-node access, proof-generation venue, and verifier-contract integration.
What it does:
Lets Solidity and EVM developers move view-call-heavy execution offchain into the zkVM, then submit a concise proof onchain instead of re-executing the same work inside the EVM
Uses a host-side preflight step to fetch the accounts, storage slots, and Merkle proofs needed for a specific execution path, including eth_getProof / EIP-1186 responses from an RPC provider
Reconstructs an EVM environment inside the guest with revm, verifies the Merkle proofs there, performs the target view calls and downstream logic, and commits a Steel commitment plus application-specific journal output
Requires the destination contract to validate the Steel commitment onchain and then verify the zk proof before allowing the state transition that depends on the offchain execution result
Supports two main commitment-validation modes: recent block-hash validation through the EVM blockhash opcode and longer-window validation through Ethereum’s EIP-4788 beacon roots contract
Extends historical queries through Steel History, which pins a recent commitment block for onchain validation while proving that an older execution block is its canonical ancestor
Key claims:
Boundless explicitly positions Steel as The ZK Coprocessor for EVM apps and repeatedly frames it as a way to get unbounded EVM computation without changing the application’s onchain trust model to a centralized executor.
The How does Steel work? docs make the practical trust split very clear: the host and RPC provider gather state, but the guest verifies Merkle proofs for that state inside the zkVM before executing the relevant logic. That means Steel is not just a proving wrapper around blind RPC results.
The commitment docs are especially important because they show Steel’s real onchain control surface. Proof validity alone is not enough; the contract must also validate that the committed block hash or beacon root is still accessible onchain, which creates explicit time windows and chain-specific limitations.
The two commitment modes materially change the application envelope. blockhash gives roughly a 256-block / ~50-minute validation window, while beacon-root commitments extend that to just over 24 hours on Ethereum L1 but add EIP-4788 dependence and somewhat higher verification complexity.
Steel History adds another comparison-relevant split: old state access is not free or unbounded. It depends on an execution block plus a recent commitment block, beacon-root chaining, archive execution data, beacon API availability, and linearly increasing proof/API cost as the gap widens.
The repo and integration docs also show Steel is a distinct layer inside the broader RISC Zero / Boundless stack rather than just marketing around the parent runtime. It now lives in its own repository and has its own docs, examples, commitment model, and history feature.
Steel clears the corpus bar because it isolates one reusable mechanism family: host-side state acquisition, guest-side EVM re-execution with proof-checked inputs, explicit block-commitment validation, and optional historical-state extension. Filed only under boundless or risc-zero, those surfaces would be flattened into a generic proving-platform story.
Whitepaper: No standalone canonical Steel whitepaper surfaced in this pass. The strongest primary materials were the official Boundless docs, the Steel crate docs, the Boundless repository, and the RISC Zero Ethereum integration docs; see ../whitepapers/steel-primary-sources-2026-05-15.md.