Welcome to the Phylax Credible Layer FAQ! Here you’ll find answers to common questions about the Credible Layer’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?

The Credible Layer is a network extension that enables apps to define security rules and prevents transactions from violating them. These rules are defined in Solidity, executed off-chain, and enforced on-chain. Since these rules are verifiable, apps can turn implicit security assumptions into an explicit security posture using our transparency dashboard so that users can trust the apps they use.

​
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 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.
  2. 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. If you are confused about what an invariant is, read on 👇🏻
  3. No Redeployment, downtime or APIs: 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 dApp? section below.

​
How does the Credible Layer differ from other security approaches?

The Credible Layer offers several key advantages:
  1. Deterministic Prevention: Binary enforcement with zero false positives rather than AI/heuristic guessing
  2. Pre-execution Protection: Stop hacks during sequencing rather than detecting after damage
  3. Network-Native Security: Protocol-controlled rules enforced by the network itself, with no external dependencies or single points of failure
  4. Transparent Enforcement: Public, verifiable Solidity rules rather than opaque algorithms
  5. Instant Deployment: Add new protections without contract modifications, downtime, or governance votes

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

​
What is the transparency dashboard?

The transparency dashboard is a tool that allows anyone to view and browse all assertions deployed by different protocols. It is a useful tool for end users as they can verify the security guarantees of any protocol, while devs can use it to copy assertions from protocols with similar contracts.

​
Is the Credible Layer a SaaS protocol?

No. We are a permissionless protocol that enables hack definition and prevention. No APIs for dApps. No points of failure. No additional trust assumptions.

​
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, and that is stored on-chain. 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’s require statement:
  • If the require condition is met, the transaction is valid
  • If the require fails, the transaction is invalid and is dropped by the network
This simple binary structure makes assertions both powerful and easy to understand - there’s no ambiguity about what constitutes a violation. It either is or isn’t a hack. Common examples include:
  • 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:
  1. Definition:
    • Properties that must hold true throughout execution
    • Core rules that define valid and 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:
    • Easier to reason about security properties
    • Path Independent: Any state transition that breaks the invariant is flagged
For a good explainer on invariants see this article

​
How do assertions work?

Although assertions are stored on-chain for transparency’s sake, assertions are run off-chain through the PhEVM (Phylax EVM) by the sequencer for performance reasons and can:
  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. For detailed documentation and examples of all available cheatcodes, see our Cheatcodes Reference Guide.

​
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:
  1. Disable the current assertion
  2. Deploy new assertion and point it to the contract you’re protecting
  3. 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 will be able to see all assertions deployed by other protocols on the transparency dashboard.

​
Implementation and Adoption

​
How does the Credible Layer work at the sequencer level?

  1. Simulates each transaction against relevant assertions
  2. Allows valid transactions to proceed
  3. 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 forced included transactions handled for OP Stack Rollups?

The solution is currently in development. Ask us about it!

​
Does the Credible Layer introduce new trust assumptions or centralization points?

No. For single-sequencer L2s, users/dApps 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 dApp-defined rules, expressed as Assertions (EVM bytecode).

​
Does the Credible Layer slow down the network?

No. We have performed worst-case stress tests, using the most inefficient operations available (hashing), to execute assertions worth 1bn gas per block without slowing down the block time. This is because the Credible Layer heavily parallelizes execution and can fully utilize CPU cores compared to standard serial execution of transactions.

​
How do you extend the validation logic of the sequencer to the dApp?

For OP stack chains, Flashbots introduced a piece of software that enables a sequencer to have an external block-builder that implements custom block-building logic, without changing the sequencer itself. This is also what powers Flashblocks. For other chains, the exact implementation varries but generally follows the following architecture: Our custom block builder enables the sequencer to check each transaction against assertions defined by the dApp. This requires no changes to contracts as it is effectively middleware.

​
Can anyone write assertions for my contracts?

Anyone can write the assertions, but only the owner of the contract that the assertions protect can “activate” them. This way, we ensure that no malicious third party reduces functionality by writing assertions for your contract.

​
My protocol doesn’t support the owner interface, can I still use the Credible Layer?

We are working on more authentication techniques to service dApps with non-traditional ownership architectures. Reach out!

​
How can you write rules for immutable contracts?

As mentioned above in How do you extend the validation logic of the sequencer to the dApp?, the Credible Layer is functionally middleware as it enables the sequencer to remove transactions that would break the dApp’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.

​
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 defined and executed by the dApp itself.

​
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 Credible Layer-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. 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
For detailed examples and testing patterns, see our Testing Guide.