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.

​
Purpose

Assertion DA serves two primary functions:
  1. Persistent Storage: Maintains EVM bytecode of assertions in an accessible location
  2. Integrity Verification: Validates that on-chain assertion IDs match the Keccak256 hash of the actual assertion bytecode

​
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 the assertion bytecode: 
Assertion ID = Keccak256(Deployable_Assertion_EVM_Bytecode)
Where Deployable_Assertion_EVM_Bytecode is the flattened smart contract code and the constructor arguments. This ensures:
  • Each unique assertion has a unique identifier
  • Assertion integrity can be verified by recomputing the hash
  • Not compilable bytecode will fail execution deterministically, so no validation is needed at submission time

​
Assertion DA Prover Signature

The Assertion DA prover signature is generated and returned by Assertion DA as part of storing the assertion. 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 uses a centralized server operated by Phylax Systems:
  • Storage: Off-chain server stores assertion bytecode and source code
  • Access: Publicly accessible for transparency and verification
  • Integration: Works with pcl and the Credible dApp. See the Architecture Overview for details.
The Assertion DA is currently centralized. This means that if Assertion DA is unavailable, the Assertion Executor will eventually be unable to operate successfully. Decentralization is planned for H1 2026.

​
How It Works

​
Storing Assertions

When you store an assertion using pcl: 
pcl store MyAssertion
pcl does the following:
  1. Compiles assertion contracts to EVM bytecode
  2. Uploads flattened source code and compiler options to Assertion DA
  3. Returns the assertion ID (Keccak256 hash of the bytecode) and DA prover signature
Only the contract owner (the address returned by the contract’s owner() function) can deploy, modify, or remove assertions for their contract. This is enforced on-chain by the Credible Layer smart contracts, which verify ownership before allowing any assertion management operations. During the early phase of the project, there is also a manual whitelist in place. Ownership verification will be expanded and improved in future versions to support additional ownership patterns and multisig integration. 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 addAssertion 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. Storage: Store assertion bytecode in Assertion DA using pcl store, which returns the assertion ID
  3. Submission: Submit the assertion ID to your project in the Credible dApp using pcl submit
  4. Deployment: Review the assertion, link it to specific contract addresses, choose Staging or Production environment, and sign the transaction to deploy it on-chain
  5. Marked for Enforcement/Staging: During the timelock period, the assertion is marked for enforcement (production) or marked for staging (staging environment)
  6. Enforced/Staged: After the timelock expires, Assertion Enforcers fetch assertions from Assertion DA and execute them during block production. Assertions become enforced or staged
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 No On-Chain Bytecode Validation?

The protocol intentionally omits bytecode validation because:
  • PhEVM execution is deterministic
  • Not compilable bytecode will consistently fail execution
  • This allows Assertion Enforcers to safely discard invalid assertions without verification overhead

​
Security Considerations

Availability: Critical for system liveness. If Assertion DA fails, Assertion Enforcers cannot validate transactions. Integrity: The Keccak256 hash verification ensures assertions haven’t been modified. Each assertion ID uniquely corresponds to its bytecode. Transparency: All assertions are publicly accessible, 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 store and submit assertions

CLI Reference

Complete reference for pcl commands

Architecture Overview

Understand how Assertion DA fits into the system

Glossary

Learn more about Assertion DA terminology