High-Level Overview

Introduction

Phylax’s real-time security system detects and pre-emptively removes exploits before losses can be realized.

The Credible Layer is a network extension that lets protocols define security rules and enforces them at the network level. Transactions that would violate these rules are dropped before they can execute, preventing exploits rather than detecting them after the damage is done.

At a glance:

Security rules are defined by the protocol team and deployed as on-chain assertions
The network validates every transaction against relevant assertions before adding them to blocks
Invalid transactions are dropped. If an assertion fails, the transaction never executes

Easy to adopt

Written in Solidity with familiar Forge patterns
No contract modifications or downtime required
Works with immutable contracts
All rules are publicly verifiable on the transparency dashboard
Implementation effort is comparable to writing Forge invariant tests

Use Cases

Assertions enable a wide range of security and compliance use cases:

Parameter Protection

Prevent unauthorized changes to critical protocol parameters such as owner and implementation addresses

Market Integrity

Ensure market prices don’t move beyond specified thresholds inside of a single transaction

Lending Protocol Safety

Guarantee lending positions maintain the required collateralization ratios

Oracle Monitoring

Verify oracle prices stay within specified ranges to detect price manipulation

Balance Invariants

Ensure that the sum of all positions match the total balance of a protocol

Compliance Rules

Enforce KYC/AML requirements by validating that transaction participants meet regulatory criteria

For concrete examples and implementations, explore the Assertions Book.

How It Works

Defining Security Rules

Security rules (technically called invariants) are statements about your contract that must remain true no matter how users interact with it. They express the essential conditions that keep your system secure and functional. Instead of exhaustively predicting every exploit path, you define the states that must never occur. If one of these states is violated, something fundamental has gone wrong. These rules are then implemented as assertions, which are Solidity smart contracts that verify the rules hold true. For a deeper understanding of how assertions work, see the Assertions Overview. Beyond Security Rules While invariants are the most common use case, assertions also enable:

Timelocks and Access Control: Add time-based restrictions or multi-factor authentication requirements for sensitive functions like contract upgrades
Business Logic Enforcement: Ensure operational rules are followed, such as transaction limits or authorized contract interactions

Real-World Example: Balancer V2

In November 2025, an attacker exploited Balancer V2 stable pools through a complex rounding error attack, causing over $120M in losses. Through 84 crafted swap operations, pool rates changed by 20x in a single transaction. The key insight: While the root cause was complex (involving rounding errors and specific balance configurations), the security rule violation was simple:

“Pool rates should not change drastically within a single transaction”

A simple assertion checking that pool rates don’t change by more than 3x would have detected and prevented this attack, regardless of the specific exploit mechanism used.

View the assertion code

contract BatchSwapDeltaAssertion is Assertion {
    uint256 constant MAX_RATE_CHANGE_MULTIPLIER = 3e18; // 3.0x

    function assertionBatchSwapRateManipulation() external {
        address vault = ph.getAssertionAdopter();
        PhEvm.CallInputs[] memory batchSwapCalls = ph.getAllCallInputs(
            vault,
            IVault.batchSwap.selector
        );

        for (uint256 i = 0; i < batchSwapCalls.length; i++) {
            // Get affected pools from swap parameters
            bytes32[] memory uniquePoolIds = _getUniquePoolIds(swaps);

            for (uint256 j = 0; j < uniquePoolIds.length; j++) {
                (address poolAddress, ) = IVault(vault).getPool(uniquePoolIds[j]);

                // Check rate before and after the swap
                ph.forkPreCall(callInput.id);
                uint256 preRate = IRateProvider(poolAddress).getRate();

                ph.forkPostCall(callInput.id);
                uint256 postRate = IRateProvider(poolAddress).getRate();

                // Revert if rate changed by more than 3x
                require(
                    (postRate * 1e18) / preRate <= MAX_RATE_CHANGE_MULTIPLIER,
                    "BatchSwap: Extreme pool rate manipulation detected"
                );
            }
        }
    }
}

This demonstrates the power of assertions: by focusing on what should never happen rather than how it might happen, you protect against both known and unknown attack vectors. Read the full Balancer V2 exploit analysis to see how this assertion was tested against the actual exploit transaction.

Network Enforcement

Once assertions are defined, they need to be deployed to protect your contracts. This involves submitting the assertion to your project, then linking it to your contract address.

The dApp submits assertions to the Credible Layer smart contracts, which deploy them on-chain. These contracts are the source of truth and supply the network with the relevant assertions when a transaction interacts with a protected contract.

How Enforcement Works

A network node running the Credible Layer sidecar does not care how a transaction violates the protocol’s rule. All that matters is whether the assertion passes or fails. If the assertion fails, the node drops the transaction before it can be included in a block. When a user opens a position on a yield protocol, the transaction may touch multiple contracts:

A single transaction can interact with multiple contracts

Each contract that has assertions is checked by the sidecar, which simulates the cumulative end states:

Each contract with assertions is checked by the sidecar

Validation Process

User submits a transaction to the network
The network node passes it to the sidecar for validation
The sidecar simulates the transaction and checks all relevant assertions
If all assertions pass, the transaction is included in the block
If any assertion fails, the transaction is dropped

This validation process never exceeds the time to produce a block. The Credible Layer adapts to each network’s architecture while maintaining the same security guarantees. For the full technical flow, see Architecture.

The Credible Layer is designed as neutral middleware that preserves decentralization for both dApps and networks. Learn more about why neutrality matters.

Next Steps

Ready to dive deeper?

Architecture

Technical deep dive into system architecture and transaction flow

Quickstart Guide

Write and deploy your first assertion

Assertions

How assertions work and how to write them

FAQ

Common questions about the Credible Layer

Getting Started