Skip to main content
Assertion Data Availability (Assertion DA) is the storage layer that maintains assertion bytecode and source code, making it accessible to Assertion Enforcers and providing transparency for users and auditors.
Assertion DA is managed by the platform. When you run pcl apply, the platform handles storing your assertion bytecode in Assertion DA automatically. You do not need to interact with Assertion DA directly.

​
Purpose

Assertion DA serves two primary functions:
  1. Persistent Storage: Maintains EVM bytecode of assertions in an accessible location
  2. Integrity Verification: Binds an assertion ID to its deployable creation data

​
Key Concepts

Before diving into how Assertion DA works, it’s important to understand two key concepts: the Assertion ID and the DA Prover Signature.

​
Assertion ID

The assertion ID is deterministically derived from deployable creation data:
The bytecode and encoded constructor arguments are stored separately in Assertion DA and combined to reconstruct the deployment data. This ensures:
  • Each unique assertion has a unique identifier
  • Assertion integrity can be verified by recomputing the hash
  • Submission compiles the Solidity source in a Dockerized solc environment before the artifact is stored

​
Assertion DA Prover Signature

The Assertion DA prover signature is generated by Assertion DA when an assertion is stored. This proof is used during deployment of the assertion to guarantee that the assertion bytecode is available on Assertion DA.

​
Current Implementation

The current implementation is operated by Phylax Systems with a highly available infrastructure:
  • Storage: Off-chain server stores assertion bytecode and source code
  • Access: Publicly accessible for transparency and verification
  • Integration: Works with pcl and the Phylax platform. See the Architecture Overview for details.

​
How It Works

​
Storing Assertions

When you create a release using pcl apply, the platform handles storage in Assertion DA:
  1. pcl apply compiles assertion contracts to EVM bytecode
  2. The platform uploads flattened source code and compiler options to Assertion DA
  3. An assertion ID (the Keccak256 hash of creation bytecode plus encoded constructor arguments) and DA prover signature are generated
Only authorized admins can deploy, modify, or remove assertions for their contracts. This is enforced on-chain by the Credible Layer smart contracts, which verify administrative authority (such as owner-based checks) before allowing assertion management operations. The on-chain State Oracle contracts also enforce the configured timelock for both adding and removing assertions. Ownership verification will be expanded and improved in future versions to support additional ownership patterns. See Ownership Verification for details.

​
Retrieving Assertions

Assertion Enforcers fetch assertions from Assertion DA upon on-chain deployment:
  1. On-Chain Deployment Event: When an assertion is deployed on-chain, the AssertionAdded event is emitted
  2. Fetch Bytecode: Assertion Enforcers detect the event and fetch the assertion bytecode from Assertion DA using the assertion ID
  3. Cache Internally: Store assertion bytecode in internal cache for future use
During transaction validation, Assertion Enforcers use the cached bytecode directly—no fetching occurs on the hot path. This ensures high-performance validation without network latency. See the Architecture Overview for details on how assertions are executed during validation.

​
Complete Lifecycle

The complete flow from assertion development to enforcement involves multiple steps:
  1. Development: Write and test assertions locally using pcl
  2. Apply: Run pcl apply to create a release on the platform. The platform stores assertion bytecode in Assertion DA and returns the assertion ID
  3. Deployment: Review the assertion in the platform, link it to specific contract addresses, choose Staging or Production environment, and sign the transaction to deploy it on-chain
  4. Marked for Enforcement/Staging: After the deployment transaction is accepted on-chain, the State Oracle timelock begins. During that period, the assertion is marked for enforcement (production) or marked for staging (staging environment)
  5. Enforced/Staged: After the timelock expires, Assertion Enforcers fetch assertions from Assertion DA and execute them during block production. Assertions become enforced or staged
If you later remove the assertion, that removal is also delayed by the configured State Oracle timelock before the assertion stops applying to transactions. For a detailed view of how these components interact, see the System Architecture section in the Architecture Overview.

​
Design Rationale

​
Why Off-Chain Storage?

  • Cost Efficiency: EVM bytecode can be large; on-chain storage would be prohibitively expensive
  • Performance: Faster retrieval and caching for high-frequency validation
  • Flexibility: Enables future improvements without base layer changes
  • Additional Metadata: Supports metadata that wouldn’t be feasible on-chain, such as instant source code verification for transparency and auditing

​
Why Compilation Happens Off-Chain

Assertion DA compiles submitted Solidity source off-chain, then the on-chain lifecycle uses the resulting deployment-data hash and availability signature. This keeps compilation and artifact storage outside the State Oracle while binding the on-chain assertion identifier to the exact creation data that enforcers later retrieve.

​
Security Considerations

Availability: The highly available infrastructure ensures consistent uptime. Assertion Enforcers cache assertion bytecode locally, so existing enforced assertions continue operating even during potential downtime. Only new assertion deployments require Assertion DA connectivity. Integrity: The Keccak256 hash verification ensures assertions haven’t been modified. Each assertion ID uniquely corresponds to its creation bytecode and encoded constructor arguments. Transparency: Assertions can be retrieved via Assertion DA, enabling users and auditors to verify security measures. Incentive Alignment: Invalid assertions only harm the developer who submitted them, as they will fail execution deterministically.

​
Next Steps

Quickstart Guide

Learn how to deploy assertions with pcl apply

CLI Reference

Complete reference for pcl commands

Architecture Overview

Understand how Assertion DA fits into the system

Glossary

Learn more about Assertion DA terminology