> ## Documentation Index
> Fetch the complete documentation index at: https://docs.phylax.systems/llms.txt
> Use this file to discover all available pages before exploring further.
# High-Level Overview
> High-level overview of the Credible Layer system that explains how exploit prevention works, without requiring deep technical knowledge.
This explanation describes how the Credible Layer prevents invalid transactions before execution and why that model matters for protocol teams and networks.
## 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 as [assertions](/credible/glossary#assertion), with assertion IDs registered on-chain and bytecode served through [Assertion DA](/credible/assertion-da)
* **The network** validates every transaction against relevant assertions before adding them to blocks
* **Invalid transactions** are [dropped](/credible/glossary#drop). 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](/credible/glossary#transparency-dashboard)
* [Implementation effort](/credible/development-effort) is comparable to writing Forge invariant tests
## Use Cases
Assertions enable a wide range of security and compliance use cases:
Prevent unauthorized changes to critical protocol parameters such as owner and implementation addresses
Ensure market prices don't move beyond specified thresholds inside of a single transaction
Guarantee lending positions maintain the required collateralization ratios
Verify oracle prices stay within specified ranges to detect price manipulation
Ensure that the sum of all positions match the total balance of a protocol
Enforce KYC/AML requirements by validating that transaction participants meet regulatory criteria
For concrete examples and implementations, explore the [Assertions Book](/assertions-book/assertions-book-intro).
## Who It's For
Deploy and manage assertions to protect your contracts
Integrate enforcement into block building
## How It Works
### Defining Security Rules
Security rules (technically called [invariants](/credible/glossary#protocol-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](/credible/glossary#assertion), which are Solidity smart contracts that verify the rules hold true. For a deeper understanding of how assertions work, see the [Assertions Overview](/credible/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.
```solidity theme={null}
import {AssertionSpec} from "credible-std/SpecRecorder.sol";
contract BatchSwapDeltaAssertion is Assertion {
uint256 constant MAX_RATE_CHANGE_MULTIPLIER = 3e18; // 3.0x
constructor() {
registerAssertionSpec(AssertionSpec.Reshiram);
}
function triggers() external view override {
registerFnCallTrigger(this.assertionBatchSwapRateManipulation.selector, IVault.batchSwap.selector);
}
function assertionBatchSwapRateManipulation() external view {
address vault = ph.getAssertionAdopter();
PhEvm.TriggerContext memory ctx = ph.context();
// Get affected pools from swap parameters
bytes32[] memory uniquePoolIds = _getUniquePoolIds(swaps);
for (uint256 i = 0; i < uniquePoolIds.length; i++) {
(address poolAddress, ) = IVault(vault).getPool(uniquePoolIds[i]);
PhEvm.ForkId memory preCall = PhEvm.ForkId({forkType: 2, callIndex: ctx.callStart});
PhEvm.ForkId memory postCall = PhEvm.ForkId({forkType: 3, callIndex: ctx.callEnd});
uint256 preRate = uint256(ph.loadStateAt(poolAddress, RATE_SLOT, preCall));
uint256 postRate = uint256(ph.loadStateAt(poolAddress, RATE_SLOT, postCall));
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](/assertions-book/previous-hacks/balancer-v2-stable-rate-exploit) 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 [Phylax platform](https://app.phylax.systems) creates releases and submits assertion changes to the Credible Layer smart contracts. Those contracts are the source of truth for which assertion IDs protect which contract addresses and when changes become active. Assertion bytecode is stored in [Assertion DA](/credible/assertion-da) and fetched by the enforcer before validation.
#### How Enforcement Works
A network node running the Credible Layer [sidecar](/credible/glossary#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:
Each contract that has assertions is checked by the sidecar, which simulates the cumulative end states:
#### Validation Process
1. User submits a transaction to the network
2. The network node passes it to the sidecar for validation
3. The sidecar simulates the transaction and checks all relevant assertions
4. If all assertions pass, the transaction is included in the block
5. If any assertion fails, the transaction is dropped
The validation path is designed to keep assertion lookup and execution bounded for each network integration. The Credible Layer adapts to each network's architecture while preserving the same core model: protocol-authored assertions inform the block inclusion decision.
For the full technical flow, see [Architecture](/credible/architecture-overview).
The Credible Layer is designed as neutral middleware that preserves decentralization for both protocols and networks. Learn more about [why neutrality matters](/credible/neutrality).
For interface boundaries and integration touchpoints, see [Interface Overview](/credible/interfaces-overview).
## Next Steps
Ready to dive deeper?
Technical deep dive into system architecture and transaction flow
Write and deploy your first assertion
How assertions work and how to write them
Common questions about the Credible Layer