Introducing SP1-CC: Unleashing the Full Power of the EVM

Leland Lee

Jul 17, 2025 — 4 min read

Succinct is supercharging the EVM with a new ZK primitive: SP1-Contract-Call (SP1-CC). With SP1-CC, developers get a ZK coprocessor that makes Ethereum more feature complete and programmable than ever, exceeding the limitations of the EVM.

The EVM is the most widely adopted smart contract platform, securing over $100B in assets across multiple chains. However, it comes with core limitations:

No access to historical state. Smart contracts can only access the current value of a storage slot. Tracking historical data requires expensive SSTORE operations and bespoke logic, adding development time.
Gas constraints. Developers want to build rich, compute-heavy applications. However, high gas costs and a fixed gas limit force simpler, less capable designs.
Rigid smart contracts. Smart contracts are designed to be immutable. Upgrades are costly unless specific design patterns are implemented upfront—overhead that many dApps can’t afford.

These constraints are designed to preserve Ethereum’s performance and decentralization. But they make it hard to build and maintain onchain applications. SP1-CC, enables developers to break free from these limitations.

SP1-CC Unleashes the EVM

SP1-CC introduces a new compute paradigm for the EVM: Read → Compute → Verify.

Read: Ingest historical blockchain state (i.e., storage, events, calldata¹) at any block.
Compute: Execute arbitrary Solidity logic offchain. No gas limits. Full flexibility.
Verify: Submit a single ZK proof onchain to prove the computation was executed correctly.

This model makes the EVM introspective, scalable, and programmable—without changing a line of L1 code. The table below outlines the changes for developers:

¹ Reading historical calldata will be available in a future update

How to build with SP1-CC

SP1-CC comes with three primitives for accessing and computing over onchain data:

call() Emulates contract calls at any historical block. Read storage. Simulate logic. No actual state changes.
create() Virtually deploy contracts and execute them offchain—no onchain transaction needed. This lets you simulate contract logic, read storage, and compose complex behaviors by calling into other contracts. Since execution happens offchain, there are no gas limits—your program can be as compute-heavy as needed.
get_logs() Query and filter logs across arbitrary blocks. Access data that’s normally inaccessible in the EVM.

With these three building blocks, a range of emergent applications are now possible.

Leading teams are building with SP1-CC

Teams like Eigenlayer are already using SP1-CC. EigenDA uses SP1-CC to prove that each data availability (DA) blob is backed by quorum-wide stake attestations. Before SP1-CC, verifying a KZG commitment for every blob directly onchain was prohibitively expensive.

By integrating SP1-CC, EigenDA sidestepped onchain compute limits. Complex blob verification now runs offchain, with a single succinct proof verified onchain. Moreover, with SP1’s aggregation layer, multiple blobs can be simultaneously proven at a flat, predictable cost.

Extend the EVM with a universe of new applications

With SP1-CC, developers can transform their blockchain applications while keeping their business logic in Solidity. Here’s a picture of what is now possible:

Onchain Governance Without Migrations

The best practice for deploying ERC20s is to ensure that they’re not upgradable—otherwise, the contract can be modified to introduce bugs or vulnerabilities. But this comes at a cost: older tokens can’t add new features or governance functionality without a full migration. A costly endeavor that requires all users to relinquish their old tokens and claim new ones.

With SP1-CC, governance can be progressively upgraded. Developers can snapshot token balances at any block, verify offchain signatures, compute vote weights (by stake, DeFi positions, etc.), and prove the result onchain. Teams no longer need proxy contracts or lengthy state migrations with a new contract deployment.

DeFi Oracles Without Checkpointing

Today, teams can calculate a token’s TWAP (time-weighted average price) by calling any Uniswap v2/v3 AMM pool. However, because the design relies on an “accumulator” to track prior prices, developers must initiate two checkpoint transactions. This creates a clunky developer experience.

With SP1-CC, developers can use call() to fetch price data at any historical block without complex accumulator logic. More advanced functionality is also possible: a team could compute a VWAP for an onchain ETF—with no centralized oracle or smart contracts changes—by using call() to fetch token prices across multiple pools at various block heights.

Improved Security Disclosures via Proof of Exploit

Today, whitehats disclose smart contract vulnerabilities by privately sharing the exploit with a team. The team is responsible for reproducing the bug, a slow process that risks leaking the vulnerability.

With SP1-CC's create() and call() functionality, whitehats can simulate sophisticated attacks and prove the smart contract vulnerability with a single ZK proof. The process is much safer, as it does not reveal the underlying exploit.

Transparent and Verifiable Airdrops

Airdrops currently rely on opaque scripts and centralized indexers. Users must trust that the team ran the selection logic correctly.

With SP1-CC, developers can design verifiable airdrops with transparent selection criteria. These airdrops can have complex criteria like LP participation, DAO votes, and other onchain behavior—at the end of the day, everything is verified with a ZK proof.