What Problem Does PPA Solve?
While ELIP-008 successfully extends operator set replication and signature verification across EVM chains, it does not address critical challenges when scaling to high-throughput altVMs like Solana or Sui, or when building applications with tight latency requirements.Latency and Execution Throughput
Traditional AVS designs require fully aggregated quorum signatures before executing. This creates a bottleneck. On high-throughput blockchains like Solana or Sui, where thousands of transactions must clear within sub-second latency windows, waiting for full quorum can breach application SLAs. Some AVSs like EOracle only attest to data, allowing consuming applications to act on un-finalized information. But for task-based AVSs like Skate, the constraint is different. Execution directly touches capital. Traditional optimistic execution (execute now, punish later) is too risky. A malicious executor could drain liquidity and cause catastrophic losses before any slashing mechanism activates.Cross-VM Verification Complexity
ELIP-008 works smoothly on EVM chains where the CertificateVerifier contract can be deployed natively. But extending this to different virtual machines is challenging. Even if operator sets, weights, and BLS keys are replicated everywhere, implementing signature verification independently per VM becomes intractable. Many chains lack the necessary cryptographic precompiles, support different curves, or require custom verification code. Maintaining this complexity across dozens of ecosystems is neither sustainable nor secure.Security Curve Choice
ELIP-008 currently supports BN254 for efficiency on EVM. But for long-term security, Ethereum consensus uses BLS12-381. On most non-EVM chains, efficient BLS12-381 verification is either prohibitively expensive or unsupported, making it unrealistic to enforce stake-weighted verification on-chain across the board.How Policy-Proved Attestations Work
Policy-Proved Attestation (PPA) introduces a novel approach: instead of replicating full verification logic across every chain, executors enforce execution policies inside trusted execution environments (TEEs). These policies encode the conditions under which a task may execute, such as quorum requirements or stake thresholds. Skate uses Cubist’s programmable policy engine to define and enforce these policies.The Architecture
Operator Identity and Weights Live on Ethereum: Operators register BLS public keys and stake weights in EigenCloud’s Ethereum contracts. This remains the single source of truth. Policy Verification in TEE: Executors run inside Trusted Execution Environments using Cubist’s programmable policy engine. Before execution, the TEE evaluates tasks against custom, programmable policies. A policy might specify: “Execute only if at least 60% of operator stake has attested to this task” or “For latency-sensitive swaps, require attestations from 3 fast operators.” Policies are defined as WASM modules and deployed to the policy engine. Chain-Native Approval: Rather than sending aggregated signatures to every destination chain, the TEE produces a lightweight, chain-native approval that each destination chain can verify. This approval is small and efficient. Slashing Remains on Ethereum: Even if executors act on partial quorums, accountability is anchored in Ethereum. If an executor used false or invalid attestations, slashing can still be enforced on Ethereum against the operators who signed incorrectly.Execution Flow
- Operators Sign Off-Chain: EigenCloud operators sign tasks using their BLS keys registered on Ethereum. Multiple operators can sign the same task.
- Partial Attestation Set: Instead of waiting for all operators to sign, a smaller subset provides attestations. This subset is tuned to the application’s security needs and latency constraints.
- TEE Policy Check: An executor running in a TEE validates that the partial attestation set meets the programmable policy. For example: “At least X% of the total restaked stake has signed this task.”
- Policy-Proved Execution: If the policy check passes, the executor acts on the task. It executes the transaction and settles results on the destination chain.
- Post-Facto Accountability: Once full attestations arrive, if any operator signed incorrectly or the partial set was fraudulent, the incorrect behavior is logged and slashing can be triggered on Ethereum.
Why This Matters
Policy-Proved Attestation transforms executors from simple message relays into policy-enforcing agents. They act only when programmable policies anchored in EigenCloud’s Ethereum contracts say it’s safe to do so. This means applications can scale across chains and VMs without each chain reimplementing signature verification logic. Skate can operate on Solana’s sub-second settlement without waiting for heavyweight aggregated signatures. Solana traders still benefit from EigenCloud’s $4.5B+ in restaked economic security, but they experience fast, responsive execution.Practical Benefits
For AMMs and Swaps: Execute trades atomically and instantly across all chains. A swap on Solana settles at the same second as a swap on Ethereum. Users enjoy low-latency execution with economic security backing every trade. For Cross-Chain Protocols: Build complex multi-step transactions that touch multiple blockchains. The policy engine ensures all steps either succeed together or fail safely. For Builders Across VMs: Deploy once on the hub chain. The stateless pattern handles distribution across Solana, Sui, Ethereum, and other VMs. Skate’s PPA mechanism ensures every chain’s execution is verified and accountable without forcing each chain to implement complex cryptography.For Developers: Defining Custom Policies
Applications can define custom policies tailored to their security and latency needs. Policies are programmable and can encode rules like:- Quorum thresholds: “Require signatures from at least 10 operators” or “Require 50% of restaked stake”
- Latency requirements: “For trades under 100k USD, use fast quorum. For trades over 1M USD, require 90% quorum.”
- Operator requirements: “Require at least 3 validators from diverse geographic regions”
BLS Signature Verification Demo
The following Rust example demonstrates how operator signatures are verified in a policy. In this demo, two operators (A and B) sign the same message using BLS keys. The policy engine verifies the aggregated signature:Cubist Policy SDK Example
The following example shows how to build a policy using the Cubist SDK. This policy enforces a 2-of-2 operator requirement, approving execution only if both designated operators have attested:Implementation: Cubist Policy Engine
The Cubist programmable policy engine provides the foundation for PPA. Policies are written in Rust, compiled to WASM, and deployed to TEEs operated by the Execution Network. The Cubist policy SDK provides primitives for:- Verifying aggregated BLS signatures
- Checking operator stake thresholds
- Enforcing quorum requirements
- Validating message content against policies