​
Frequently Asked Questions (FAQ)

Welcome to the Phylax Credible Layer FAQ! Here you’ll find answers to common questions about the PCL’s features, capabilities, and usage. If you can’t find what you’re looking for, please reach out in our Telegram.

​
General Questions

​
What is the Phylax Credible Layer (PCL)?

PCL is a security framework that prevents smart contract exploits by enforcing user-defined security rules (assertions) at the sequencer level. It stops malicious transactions before they can affect your protocol.

​
Why do I need the Credible Layer when I can write rules in my contracts?

There are several key advantages:

  1. Off-chain Execution: Rules that would be too expensive or impossible to express on-chain can be implemented as assertions. Our current benchmarks show around 1000x efficiency gains.
  2. Simpler Security Model: Instead of handling all edge cases in your contract, you define states that should never occur
  3. No Redeployment: Add new security rules without modifying your existing contracts
  4. Comprehensive Protection: Define protocol-wide invariants that span multiple contracts

​
How does PCL differ from other security approaches?

The Credible Layer offers several key advantages:

  1. Prevention First: Stops attacks before they happen by filtering invalid transactions, rather than detecting them after the fact
  2. Protocol-Defined Security: Your team defines exact security rules in Solidity, eliminating false positives from generic heuristics
  3. No Contract Changes: Add new security rules without modifying or redeploying your contracts
  4. Comprehensive Coverage: Define rules that span multiple contracts and complex interactions
  5. Full Transparency: Unlike AI/LLM analysis which operates as black boxes, assertions are written in Solidity and their logic is fully transparent and verifiable
  6. Economic Incentives: Creates a market where sequencers earn fees for enforcing security rules

​
What’s the difference between assertions and traditional audits?

While audits provide one-time code reviews, assertions offer continuous protection by actively monitoring every transaction that interacts with your protocol. They run at the sequencer level, checking each transaction before it’s included in a block, providing real-time protection against:

  • New attack vectors discovered after deployment
  • Unexpected contract interactions
  • Changes in market conditions
  • Updates to protocol parameters
  • Governance decisions

​
What is the transparency dashboard?

The transparency dashboard is a tool that allows you to view and browse all assertions deployed by different protocols. It is a useful tool for understanding the security posture of a protocol.

​
Technical Details

​
What exactly is an assertion?

An assertion is a Solidity contract that defines invalid states your protocol should never reach. You can think of it as an inverse intent - you define something you don’t want to happen without specifying or caring about all the edge cases that could lead to it.

Assertions are binary in nature, implemented through Solidity’s require statements:

  • If the require condition is met, the transaction is valid
  • If the require fails, the transaction is invalid and will be filtered out

This simple binary approach makes assertions both powerful and easy to reason about - there’s no ambiguity about what constitutes a violation.

Common examples include:

  • Unauthorized admin changes
  • Suspicious 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 must always remain true. They are fundamental to the Credible Layer’s approach to security, and assertions are the perfect tool to enforce them. While invariants define what should always be true, assertions give you the practical means to enforce these rules across your entire protocol:

  1. Definition:

    • Mathematical properties that must hold true throughout execution
    • Core rules that define valid vs. invalid protocol states
    • Security guarantees that shouldn’t be violated

  2. 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

  3. Advantages:

    • More robust than trying to catch all possible exploits
    • Easier to reason about security properties
    • Can catch novel attack vectors
    • Provides clear security boundaries

For a good explainer on invariants see this article

​
How do assertions work?

Assertions run off-chain through the PhEVM (Phylax EVM) and:

  1. Compare state before and after transactions
  2. Monitor specific function calls
  3. Track changes to storage slots
  4. Analyze transaction patterns
  5. Enforce protocol-wide invariants

​
What are cheatcodes and how do they help?

Cheatcodes are special functions provided by the PhEVM that give assertions powerful capabilities beyond standard Solidity:

  1. State Inspection:

    • Examine blockchain state at any point in a transaction
    • Compare values before and after execution
    • Access historical state data

  2. Transaction Analysis:

    • Inspect call data and function parameters
    • Track emitted events
    • Monitor internal transactions
    • Analyze call traces

  3. Storage Access:

    • Monitor specific storage slots
    • Track state changes across contracts
    • Access complex data structures
    • Monitor cross-contract interactions

  4. Testing Utilities:

    • Simulate different scenarios
    • Mock contract responses
    • Manipulate execution environment
    • Debug assertion behavior

For detailed documentation and examples of all available cheatcodes, see our Cheatcodes Reference Guide.

​
How do I upgrade assertions?

Updating assertions is straightforward:

  1. Disable current assertion
  2. Deploy new assertion pointing to upgraded contract
  3. Enable new assertion
  4. Include these steps in your upgrade process

​
Can I copy assertions from other protocols?

Yes, you can copy assertions from other protocols and use them in 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 will be able to see all assertions deployed by other protocols on the transparency dashboard.

​
Implementation and Adoption

​
How does PCL work at the sequencer level?

PCL uses a modified Flashbots builder that:

  1. Simulates each transaction against relevant assertions
  2. Allows valid transactions to proceed
  3. Filters out transactions that violate assertions
  4. Maintains Superchain compliance for L2 compatibility

​
How are forced inclusion transactions handled?

For L1->L2 deposits and other forced transactions, PCL:

  1. Intercepts incoming L1 blocks
  2. Validates deposit transactions
  3. Applies mitigations if needed
  4. Ensures the L2 chain never stalls

​
Does this introduce new trust assumptions?

No. For single-sequencer L2s, users already trust the sequencer. PCL simply extends the sequencer’s validation logic with protocol-defined rules.

​
What are some example use cases for assertions?

  1. DeFi Protection

    • Prevent flash loan attacks
    • Monitor liquidity pool ratios
    • Enforce borrowing limits
    • Detect price manipulation

  2. Governance Safety

    • Validate proposal execution
    • Monitor admin actions
    • Enforce timelock requirements
    • Track parameter changes

  3. 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 PCL-specific features:

  1. Standard Testing Tools:

    • Use familiar Forge assertions (assertEq, assertTrue)
    • Access standard cheatcodes (vm.prank, vm.deal)
    • Leverage console logging for debugging

  2. PCL-Specific Testing:

    • Register assertions using cl.addAssertion()
    • Validate transactions with cl.validate()
    • Test both positive and negative cases
    • Verify assertion behavior across different scenarios

For detailed examples and testing patterns, see our Testing Guide.

Introduction to Phylax