Use this page for short answers. If you are trying to complete a task, go to the how-to guides. If you need definitions, use the Glossary. If you need the system rationale, start with the Architecture Overview and Trust Model.
General Questions
What is the Phylax Credible Layer?
The Credible Layer is a network extension that enables developers to link security rules to their smart contracts on-chain. These rules are defined in Solidity, executed off-chain, and enforced by the network during block building. Since these rules are verifiable, apps can turn implicit security assumptions into an explicit security posture using The Phylax Explorer so that users can inspect the protections behind the apps they use. Learn More:- Credible Layer Overview - Non-technical introduction
- Architecture - Technical deep dive
Why do I need the Credible Layer when I can write rules in my contracts?
There are several key advantages:- Off-chain Execution: Rules that would be too expensive or impossible to express on-chain due to gas costs and limits can be implemented easily as assertions as they are run off-chain. Our current benchmarks show around 1000x efficiency gains.
- Simpler Security Model: By writing invariants that define a state to prevent instead of every edge case that would lead there, you simplify and strengthen your protocol.
- No redeployment or downtime: Add new security rules without modifying your existing contracts. You can even add rules to immutable contracts. To learn how this is possible read the How do you extend the validation logic of the sequencer to the platform? section below.
How does the Credible Layer differ from other security approaches?
The Credible Layer offers several key advantages:- Deterministic prevention: Binary enforcement based on protocol-authored assertions rather than opaque scoring
- Pre-execution Protection: Stop hacks during sequencing rather than detecting after damage
- Network-Native Security: Protocol-controlled rules enforced by the network itself, without relying on external execution services
- Transparent Enforcement: Public, verifiable Solidity rules rather than opaque algorithms
- No contract modifications: Add new protections without changing the protected contract; activation still follows the configured assertion lifecycle and timelocks
What’s the difference between assertions and traditional audits?
While audits provide point-in-time code reviews, the Credible Layer offers continuous protection via the sequencer actively validating every transaction that interacts with your contracts against your assertions. Learn More:What is The Phylax Explorer?
The Phylax Explorer is the public dashboard that displays the security and operational risk posture of protocols that have opted into runtime enforcement. Users can find summaries of actions protected by circuit breakers and assertions, scenarios the assertions prevent, operational details for admin multisig wallets, upgradeability documentation, and whether the currently deployed protocol has meaningfully diverged from the code at the time of audit. Learn More:Is the Credible Layer a SaaS protocol?
No. The Credible Layer is a protocol with product tools around it: the platform andpcl help teams author, review, deploy, and monitor assertions, while the on-chain registry remains the source of truth for active assertion state.
Access to assertion management is still gated by authorization. Only verified protocol admins can attach assertions to protected contracts, and supported networks may have onboarding or availability constraints.
Learn More:
Technical Details
What exactly is an assertion?
An assertion is a Solidity contract that defines an invariant about your protocol, some state you want to prevent. Its identifier and registry entry are stored on-chain, while bytecode is stored in Assertion DA for enforcement. You can think of it as an inverse intent — you define the state you don’t want to occur without specifying or caring about all the specific vectors that could lead to it. Assertions are binary in nature, implemented through Solidity’srequire statement:
- If the
requirecondition is met, the transaction is valid - If the
requirefails, the transaction is invalid and is dropped by the network
- Unauthorized admin changes
- Significant price movements
- Violation of core protocol invariants
- Complex cross-contract validations
What are invariants and why are they important?
Invariants are properties of your protocol that you want to maintain. They are fundamental to the Credible Layer’s approach to security, and assertions are our tool to let you enforce them. While invariants define what should always be true, assertions give you the practical means to enforce these rules across your entire protocol:- Definition:
- Properties that must hold true throughout execution
- Core rules that define valid and invalid protocol states
- Security guarantees that shouldn’t be violated
- Common Examples:
- Total supply must equal sum of all balances
- Pool balance should never drop below initial deposit
- Admin privileges can’t be granted without proper authorization
- Price changes must stay within acceptable bounds
- Advantages:
- Easier to reason about security properties
- Path Independent: Any state transition that breaks the invariant is flagged
How do assertions work?
Although assertion IDs and registry entries are stored on-chain for transparency, assertions are run off-chain through the PhEVM (Phylax EVM) by the sequencer or block builder for performance reasons and can:- Compare state before and after transactions
- Monitor specific function calls
- Track changes to storage slots
- Analyze transaction patterns
- Enforce protocol-wide invariants
What counts as an assertion failure?
An assertion failure occurs when an assertion reverts during validation. The transaction is then considered invalid and is dropped before it can be included in a block. Learn More:What are cheatcodes and how do they help?
Cheatcodes are special functions provided by the PhEVM that give assertions powerful capabilities beyond standard Solidity. For detailed documentation and examples of all available cheatcodes, see our Cheatcodes Reference Guide. Learn More:How do I edit assertions?
There might be cases where you want to edit an assertion to add new checks or change existing ones. Editing an assertion is straightforward:- Disable the current assertion
- Deploy new assertion and point it to the contract you’re protecting
- Enable new assertion
Can I copy assertions from other protocols?
Yes, you can copy and adapt assertions from other protocols and use them to protect your own protocol. You should make sure that the assertions are compatible with your protocol. It will make the most sense to copy assertions for standard libraries and interfaces. You can inspect public assertion posture in The Phylax Explorer. Some project and invalidation details are only visible to project managers and collaborators. Learn More:Implementation and Adoption
How does the Credible Layer work at the sequencer level?
- Simulates each transaction against relevant assertions
- Allows valid transactions to proceed
- Filters out transactions that violate assertions
How does the Credible Layer work with decentralized sequencers?
- Enshrine assertions as part of state transition function or fork-choice rule, making them integral to the protocol.
- Credible sequencers that mark blocks as safe by running invariants and posting attestations on-chain, ensuring safety without compromising performance
How are externally originated transactions handled?
Network integrations define validation policy for transactions that do not enter through ordinary user RPC flow, such as bridge-originated actions, delayed queues, scheduled system transactions, or forced-inclusion-style paths. The policy specifies where assertion validation runs, how results are routed into sequencing or block-building components, what timeout behavior applies, and which invalidation context is sent to affected protocols. Learn More:Does the Credible Layer introduce new trust assumptions or centralization points?
No. For single-sequencer L2s, users and protocol teams already trust the sequencer with transaction inclusion, because, in theory, a sequencer can censor transactions arbitrarily when it receives them at the RPC layer. The Credible Layer simply extends the sequencer’s validation logic with protocol-defined rules, expressed as Assertions (EVM bytecode). Learn More:Is this a form of censorship?
The Credible Layer simply lets protocol teams define assertions that can prevent certain states regardless of the contract code. These assertions should be thought of as an addition to the protocol’s core contracts. It would be censorship if a 3rd party (anyone other than the protocol team) could write assertions for a protocol’s contracts. This is not how the Credible Layer works, and hence this is not censorship. Read more about this in Can anyone write assertions for my contracts? below. Learn More:Does the Credible Layer slow down the network?
The Credible Layer is designed to keep assertion overhead bounded and off the serial block-building path where the network integration supports that model. The hot path should mainly pay for tracing, assertion routing, checkpointing, and work submission, while assertion execution can run in parallel worker capacity. The practical requirement is that assertion workers keep up with the transaction workload. If assertion execution falls behind, the integration needs bounded backpressure, publication-boundary waiting, or another network-specific policy. Learn More:How do you extend the validation logic of the sequencer to the platform?
The exact implementation depends on the network architecture. The shared model is that the network adds an enforcement hook around block building, sequencing, preflight validation, or another documented inclusion boundary. That hook sends candidate transaction context to the Assertion Enforcer. The enforcer selects relevant assertions, executes them, and returns a valid or invalid result that the integration applies before settlement. This requires no changes to protected contracts because assertions run as enforcement middleware around transaction inclusion. Learn More:Can anyone write assertions for my contracts?
Anyone can write the assertions, but only the owner of the contract that the assertions protect can deploy them. This way, we ensure that no malicious third party reduces functionality by writing assertions for your contract. Learn More:My protocol doesn’t support the owner interface. Can I still use the Credible Layer?
Yes, if the contracts are deployed on a supported rollup. You may need manual verification if your contracts are immutable or do not expose an admin interface such asowner(). Phylax can verify off-chain evidence that your team controls the protocol and then register the selected protocol admin for the specific contracts.
Manual verification is not available for Ethereum mainnet contracts because enforcement works differently on L1 and L2 blockchains.
Learn More:
How can you write rules for immutable contracts?
As mentioned above in How do you extend the validation logic of the sequencer to the platform?, the Credible Layer is functionally middleware as it enables the sequencer to drop transactions that would break the protocol’s rules. The Credible Layer will still work with immutable contracts because the prevention happens at the sequencing step, which is where the L2 has ultimate power over transaction inclusion, whether or not they come from immutable contracts. Learn More:What are the ramifications of writing rules for supposedly immutable contracts?
Short answer: We don’t know. But here is what we think: If there is an owner it communicates that the protocol wants to have some power over the contracts. That is why we only allow only the owners of contracts to write assertions. We will use timelocks on protocols with immutable contracts as many of the users may be using that protocol because it is immutable and would not want to use it any longer if there is anything resembling censorship, even if it is configured through the platform itself. Learn More:What’s the difference between Staging and Production environments?
When deploying assertions, you can choose between two environments:- 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. After the timelock period, assertions become “staged”.
- 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. After the timelock period, assertions become “enforced”.
How long is the timelock period?
The timelock period 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. The exact duration may vary because it is configured on the State Oracle smart contracts. The same model applies when assertions are removed: the change is scheduled on-chain first, then only takes effect after the configured timelock expires. Learn More:Practical Questions
What are some example use cases for assertions?
- DeFi Protection
- Prevent flash loan attacks
- Monitor liquidity pool ratios
- Enforce borrowing limits
- Detect price manipulation
- Governance Safety
- Validate proposal execution
- Monitor admin actions
- Enforce timelock requirements
- Track parameter changes
- Cross-Protocol Security
- Monitor oracle data feeds
- Track cross-chain messages
- Validate bridge transactions
- Enforce protocol dependencies
How do I test my assertions?
Testing assertions is similar to standard Forge testing, with additional Credible Layer-specific features:-
Standard Testing Tools:
- Use familiar Forge assertions (
assertEq,assertTrue) - Access standard cheatcodes (
vm.prank,vm.deal) - Leverage console logging for debugging
- Use familiar Forge assertions (
-
Credible Layer-Specific Testing:
- Register assertion function to be run on the next transaction using
cl.assertion() - Test both positive and negative cases
- Verify assertion behavior across different scenarios
- Register assertion function to be run on the next transaction using