Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.polygon.technology/llms.txt

Use this file to discover all available pages before exploring further.

Polygon CDK supports a privacy configuration for institutions that need to keep transaction data inside their own infrastructure while retaining Ethereum-anchored security and Agglayer interoperability. The chain runs as an OP Stack validium: raw transaction data is held in a data availability server the institution operates, and Ethereum sees only a Keccak256 commitment plus a SP1 Hypercube validity proof. This configuration is intended for regulated institutions that want full control over where customer data lives while staying connected to the broader Ethereum ecosystem for liquidity and settlement.

​
Stack At A Glance

The privacy configuration runs OP Stack in OP Succinct validium mode, with SP1 Hypercube handling proof generation and AltDA serving as the institution-operated data availability layer. Implementation partners like Conduit and Gateway operate the stack as a service; institutions can also run sequencers themselves. The chain settles to Ethereum and connects to Agglayer for cross-chain liquidity and state.

​
What This Configuration Delivers

Customer data confidentiality. Sensitive transaction data stays inside infrastructure the institution owns and operates. Regulators, auditors, and counterparties receive scoped access on the institution’s terms. Self-hosted infrastructure. Data availability runs behind the institution’s existing security perimeter, in jurisdictions it has already cleared with compliance. There is no third-party dependency for data storage or retrieval. Global liquidity. The chain stays connected to the Ethereum ecosystem through Agglayer, retaining access to stablecoins, tokenized assets, and counterparty capital across connected chains. Ethereum-anchored security. Every chain transition is verified by a ZK validity proof settled to Ethereum, inheriting Ethereum’s economic security for settlement.

​
How It Works

The privacy configuration replaces the OP Stack’s default L1 data availability with a Keccak256-commitment alt-DA flow. The pipeline runs in four stages:
  1. Batch submission to private DA. When the sequencer produces a batch, op-batcher submits the batch data to the institution’s data availability server using the standard OP Stack alt-DA HTTP API. PUT /put returns a Keccak256 commitment; GET /get/0x{commitment} retrieves the data.
  2. L1 anchoring. The batcher posts an L1 transaction containing the DerivationVersion1 prefix byte (0x01) followed by the 32-byte Keccak256 commitment. Raw transaction data never reaches a public network.
  3. Proof generation. The OP Succinct proposer reads the L1 commitment, fetches the batch data from the DA server, and feeds it to SP1. Inside the zkVM, the proving program verifies keccak256(data) == commitment via the preimage oracle before executing the OP Stack derivation pipeline.
  4. Proof settlement. The validity proof is posted to the chain’s OPSuccinctL2OutputOracle contract on Ethereum, where it is verified against a range verification key and rollup config hash pinned at deployment.

​
Trust Model

The privacy configuration splits trust between data integrity and data availability:
  • Data integrity is not trusted to the DA server. SP1 verifies keccak256(data) == commitment inside the zkVM before accepting any data into the derivation pipeline. A malicious or compromised DA server cannot forge state.
  • Data availability is trusted to the DA server. If the DA server loses data or refuses to serve it for a given commitment, no proof can be produced for the affected range. DA-layer redundancy, backup, and access control are the operator’s responsibility.
For institutional deployments this is the intended trust split: the DA server sits inside the operator’s perimeter precisely so the operator controls availability. Cryptographic integrity is enforced by the prover; operational availability is enforced by the institution’s own infrastructure practices.

​
Access Control

The privacy configuration is typically paired with chain-level access controls. These are operator-configurable surfaces; some require additional implementation by the operator or the rollup-as-a-service partner:
  • Gated RPC endpoints. Custom RPC layers can be placed behind enterprise identity systems such as Okta, Azure AD, or any OIDC-compatible SSO.
  • Permissioned block explorers. Block-explorer access can be restricted to authorized users.
  • Custom sequencer policies. Sequencers can enforce KYC-gated mempools, allowlists, and other admission policies.
  • Contract-level access controls. Application logic can enforce per-function and per-role access controls within each smart contract.

​
Configuration Reference

The AltDA configuration is gated behind a Cargo feature and a single required environment variable:
  • Feature flag: altda Cargo feature on the validity binary.
  • Environment variable: ALTDA_SERVER_URL (no default; the deployment fails to start if unset).
  • Service name: op-succinct-altda, with a separate docker-compose-altda.yml for the AltDA-mode stack.
  • Range ELF: altda-range-elf-embedded, embedded at build time.
  • Deployment helpers: just deploy-oracle .env altda and just update-parameters .env altda.
When deploying or upgrading, the range verification key, aggregation verification key, and rollup config hash must be regenerated with --features altda. Without this, OPSuccinctL2OutputOracle reverts with ProofInvalid() on proof submission.

​
Limitations

The OP Succinct AltDA mode is marked experimental. Configuration keys, feature flags, and on-disk artifacts may change without notice across releases. Pin specific versions for production deployments, and treat the OP Succinct AltDA documentation as the canonical source of truth.
Additional limitations to plan around:
  • Keccak256 commitments only. The current implementation accepts only Keccak256 commitments. Generic commitments (the OP alt-DA 0x01 type byte) are explicitly rejected.
  • DA availability is operator-enforced. The zkVM verifies that retrieved data matches the on-chain commitment, but it cannot force the DA server to serve data. Availability and censorship resistance are operator responsibilities.
  • No recovery past a missing commitment. If the DA server loses or refuses to serve data for a given commitment, no proof can be produced for the affected range. There is no recovery path past a missing commitment.
  • Hardcoded 30-second HTTP timeout. The DA fetch timeout is fixed in the current implementation and is not configurable.
  • Standard L1 head selection. The proposer uses standard L1 head selection; there is no Blobstream-style finality tracking.
  • Components out of scope for OP Succinct. The alt-DA server itself, generic-commitment encoding, and on-chain DA challenge/bonding logic are not provided by OP Succinct.

​
Deployment Options

Three deployment patterns are supported:
  • Institution-operated. The institution runs the full stack: sequencer, op-node, op-batcher, op-proposer, and the AltDA server.
  • Conduit-managed. Conduit operates the full stack as a service, including the AltDA server, on behalf of the institution.
  • Gateway-managed. Gateway provides equivalent rollup-as-a-service operation of the stack.

​
Settlement And Interop

Validity proofs are posted to the chain’s OPSuccinctL2OutputOracle contract on Ethereum L1, where each proof is verified against a range verification key and rollup config hash pinned at deployment. The chain connects to Agglayer for cross-chain liquidity and state; see the Agglayer documentation for cross-chain mechanics and integration patterns.

​
Resources

Polygon CDK overview

Architecture, execution clients, rollup modes, and performance.

OP Succinct AltDA docs

Canonical upstream reference for the AltDA mode used by this configuration.

op-succinct on GitHub

Source code for the OP Succinct prover and AltDA integration.

Agglayer documentation

Cross-chain liquidity and state for connected chains.

Polygon launch blog

Announcement and positioning of the privacy configuration.

Succinct launch blog

Technical write-up from Succinct on the AltDA shipment.