Skip to main contentCore Concepts
The Credible Layer
The Credible Layer is security infrastructure that enables developers to link security rules to their smart contracts on-chain. Then, the network validates every transaction that interacts with their smart contracts against their security rules, dropping any invalidating transaction.
See the Introduction for a comprehensive overview.
Assertion
A smart contract that verifies specific properties or behaviors of other smart contracts. Assertions are the fundamental building blocks of the Credible Layer, used to enforce security properties and invariants.
Learn more: What are Assertions? | Assertion Guide
Protocol Invariants
Critical conditions or properties that must always be maintained within a protocol, such as ensuring total assets ≥ total liabilities or maintaining specific ownership rules. These invariants can be:
- Single-contract: Rules within a single contract
- Protocol-wide: Rules spanning multiple contracts and complex interactions
- Security-specific: Rules focused on preventing unauthorized access or changes
System Architecture
PhEVM (Phylax EVM)
A specialized EVM implementation that includes additional capabilities for assertion verification and state manipulation.
Assertion DA (Data Availability)
The data availability layer responsible for storing assertion code and metadata. This ensures that assertions are accessible and verifiable by anyone.
Learn more: Assertion Data Availability
Block Builder
The component of the network that simulates transactions and runs assertions before transaction finalization to ensure they don’t violate defined conditions.
Sequencer
The network component responsible for building blocks and validating transactions against assertions before including them in the blockchain.
Assertion Enforcer
The entity responsible for enforcing assertions and vouching for not including any transactions that would invalidate them. Usually a block builder or sequencer.
Credible dApp
The web application interface for interacting with the Credible Layer. It allows dApp developers and end-users to deploy, manage, and view assertions and projects.
Transparency Dashboard
A tool that allows users to view and browse all assertions deployed by different protocols, providing visibility into their security posture.
Sidecar
A software architecture pattern where a component runs alongside the main application without modifying it. The Credible Layer operates as a sidecar to the network’s sequencer, intercepting and validating transactions during the block building process. This allows the Credible Layer to add assertion validation capabilities without requiring changes to the core network code.
See the Architecture documentation for implementation details.
Network Validator (Node)
The network infrastructure component responsible for processing transactions, building blocks, and maintaining blockchain consensus. In L2 networks, this is typically the sequencer. The Credible Layer integrates with the network validator through a sidecar to validate transactions against assertions before block inclusion.
Related terms: Sequencer, Block Builder
Assertion Components
Trigger
A function that determines when an assertion should be executed. Triggers are registered with the PCL system to specify the conditions under which an assertion should be evaluated. There are several types of triggers:
- Call Triggers: Execute on specific contract calls
- Storage Triggers: Execute on storage changes
- Balance Triggers: Execute on ETH balance changes
See the Cheatcodes Reference for detailed information about different trigger types.
Pre-state/Post-state
Snapshots of the blockchain state captured before and after a transaction. These states are used by assertions to verify changes and enforce properties. The ability to compare pre and post states enables assertions to detect and prevent invalidating transactions that would result in undesired state changes.
See the Cheatcodes Reference for information about forkPreTx, forkPostTx, forkPreCall, and forkPostCall.
State Changes
Modifications to contract storage that occur during transaction execution. These can be tracked and verified using the Credible Layer’s state change tracking capabilities, allowing assertions to monitor and prevent unauthorized modifications.
See the Cheatcodes Reference for state tracking functions.
Callstack
The sequence of function calls that occur during a transaction’s execution. PCL’s ability to inspect state changes across the entire callstack is a powerful feature that enables assertions to:
- Track state modifications through complex contract interactions
- Monitor cross-contract dependencies
- Detect unauthorized changes in deeply nested calls
- Enforce invariants that span multiple contract boundaries
See the Cheatcodes Reference for callstack inspection capabilities.
Assertion Bytecode
The compiled form of an assertion contract that is stored in the Assertion DA and executed by the PCL network.
See the pcl Reference for build and store commands.
Assertion ID
A unique identifier for an assertion, computed as the Keccak256 hash of the assertion’s EVM bytecode. The assertion ID is used to reference assertions in the Credible Layer protocol and retrieve assertion bytecode from the Assertion DA.
Learn more: Assertion Data Availability
Assertion DA Prover Signature
A signature generated and returned by the Assertion DA as part of storing an assertion. This proof is used during deployment of the assertion to guarantee that the assertion bytecode is available on the Assertion DA.
Learn more: Assertion Data Availability
Assertion Adopter
The contract that is being monitored by an assertion. This is the contract whose behavior the assertion is designed to verify.
Assertion Group
A collection of assertions in the same contract that are related to the same protocol contract. This allows for organizing multiple assertions that protect different aspects of the same protocol.
Assertion Function
A function in an assertion contract that performs a specific check. These functions must be registered in the triggers() function and are called by the PCL system when their trigger conditions are met.
pcl
The command-line tool for building, testing, storing, and submitting assertions to the Credible Layer.
See the pcl Reference for all available commands.
phorge
A minimal fork of Forge with functionality for assertion execution, used for testing and running assertions in the Credible Layer. It provides the infrastructure needed to compile, test, and deploy assertions.
credible-std
The Phylax smart contract library that provides the base contracts and utilities for writing assertions. It includes the interfaces and implementations needed to interact with the Credible Layer’s cheatcodes and assertion system.
Cheatcodes
Special precompiles (similar to Ethereum’s native precompiles) that provide additional capabilities for state manipulation, forking, and assertion management in the PhEVM environment. These are accessed through the credible-std library.
See the Cheatcodes Reference for a complete list of available cheatcodes and their usage.
Test Environment
The PCL testing interface that extends Forge’s testing capabilities with additional utilities specifically for testing assertions. It provides functions for adding assertions and validating transactions, making it easier to test assertion behavior in different scenarios.
Learn more about testing assertions in the Testing Guide.
Security Features
Off-chain Execution
The ability to run complex security rules outside the main blockchain execution, providing significant efficiency gains compared to on-chain validation.
Forced Inclusion Transactions
Special transactions that must be included in blocks regardless of validation, such as L1->L2 deposits. PCL handles these by intercepting and validating them appropriately.
Verifiability
The transparent and public nature of all assertions deployed on PCL. Since assertions are stored in the Assertion DA and are publicly accessible, any user or auditor can inspect and verify the security mechanisms in place for a protocol. This transparency enables community-driven security reviews and builds trust by making security measures fully auditable.
Prevention
Revert
What happens at the EVM/Solidity level when an assertion function detects that a transaction violates the rules defined in the assertion. When an assertion reverts, it signals that the transaction would result in an undesired state. The sidecar detects this revert and notifies the sequencer that the transaction should be dropped.
Drop
The technical term for when a sequencer or block builder excludes a transaction from block inclusion. After the sidecar detects that an assertion has reverted, it notifies the sequencer, which then drops the invalid transaction before it can be included in a block.
Prevent
The overarching term used to describe what the combination of assertions, sidecar, and sequencer accomplishes when an invalidating transaction is detected. The system prevents malicious transactions from executing by detecting violations, dropping invalid transactions, and protecting protocols from exploits.
Assertion Lifecycle
Store
The process of uploading assertion bytecode and source code to Assertion DA using pcl store. This makes the assertion available for retrieval by the network but does not yet associate it with a project.
Submit
The process of submitting an assertion contract to a project in the Credible Layer dApp using pcl submit. After storing, assertions must be submitted to a project before they can be deployed.
Deployment
The process of reviewing an assertion, linking it to a contract, and signing the transaction to deploy it on-chain. Deployment includes choosing whether to deploy to Staging or Production environment. The deployment transaction must succeed for the assertion to be deployed on-chain.
Staging
A mirrored chain environment used for testing assertions without affecting production. Assertions run on staging to observe behavior, but transactions are not dropped if they break assertion rules. This allows protocol teams to test assertions safely before deploying to production.
Production
The real chain environment where assertions actively prevent hacks. In production, transactions that violate assertions are dropped before they can execute, protecting protocols from exploits.
Timelock
A period between assertion deployment and enforcement (production) or staging (staging environment). The timelock exists for two reasons: (1) to provide latency for the enforcer to index on-chain state and prepare for enforcement, and (2) to give users time to expect changes to protocol behavior. During the timelock period, assertions are marked for enforcement or staging but not yet active.
Marked for Enforcement
The state of an assertion deployed to production during the timelock period. The assertion is deployed but not yet actively preventing hacks. After the timelock expires, the assertion becomes enforced.
Marked for Staging
The state of an assertion deployed to staging during the timelock period. The assertion is deployed but not yet running on the staging environment. After the timelock expires, the assertion becomes staged.
Enforced
The state of an assertion in production after the timelock period has expired. An enforced assertion is actively preventing hacks by causing invalidating transactions to be dropped. This term is only used for production assertions.
Staged
The state of an assertion in staging after the timelock period has expired. A staged assertion is running on the mirrored chain environment, allowing protocol teams to observe how it behaves without transactions being dropped if they violate the assertion.
Removal
The process of removing an assertion from active enforcement or staging. Removal requires a timelock period before the assertion stops being enforced or staged, giving users time to expect the change. 
