> ## 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.
# Network Integration Overview
> High-level integration path for networks and sequencers adopting the Credible Layer
Use this page when your goal is to scope a network integration and identify the infrastructure surfaces your team will need.
If you need concrete implementation details, continue to the [Linea / Besu integration](./network-integrations/architecture-linea) or [OP Stack implementation](./network-integrations/architecture-op-stack). If you need background first, read the [Architecture Overview](./architecture-overview).
This page explains how networks integrate the Credible Layer at a high level. It focuses on the
interface surfaces and operational expectations without internal implementation details.
## Who This Is For
* L2 networks and sequencers evaluating integration
* Infrastructure teams operating block builders or validators
* Security teams defining network-level enforcement goals
## High-Level Flow
```mermaid theme={null}
---
title: Network Integration Flow
---
flowchart LR
Users[Users + Applications] --> RPC[Network RPC]
RPC --> Builder[Block Builder]
Builder --> Enforcer[Assertion Enforcer]
Enforcer -->|valid| Block[Block]
Enforcer -->|invalid| Drop[Dropped]
Enforcer -.-> Registry[On-Chain Registry]
Enforcer -.-> DA[Assertion DA]
```
## Integration Surfaces
Networks provide the following integration surfaces:
* **Block-building hook**: the block builder queries the Assertion Enforcer before including a
transaction
* **Registry access**: the enforcer consumes registry data (indexed from on-chain events) to discover which assertions apply
* **Assertion data access**: the enforcer fetches assertion bytecode from Assertion DA
* **Operational monitoring**: incidents and status are surfaced via the Phylax platform
## Integration Policy Decisions
Network integrations should define how enforcement is applied across the network's transaction paths and traffic management layers.
### L1-originated transaction paths
Some rollups include L1-originated transaction paths, deposits, or delayed inboxes alongside ordinary sequencer-selected transactions. The integration policy should specify how assertion validation fits into each path.
Before production rollout, define:
* Which L1-originated, deposit, or delayed inbox paths the network supports
* Where assertion validation runs for those transactions
* How validation results are routed into sequencing or block-building policy
* Which application-layer response options protocols can use during the validation window
* What incident metadata is sent to affected protocols
L1-originated transaction policy is network-specific and should be documented as part of the integration.
### Ingress traffic management
Networks can pair assertion validation with ingress-level caching and rate-limit policies for repeated invalid submissions.
Common controls include exact invalid-transaction caching, broader short-lived fingerprints for repeated attempts against the same assertion and target surface, peer or sender budgets, and clear TTLs for any broad match.
## Operational Expectations
* The enforcer runs alongside the block builder and does not change consensus rules
* Enforcement is deterministic and only depends on on-chain state and assertion code
* Protocol teams choose whether assertions are staged or enforced; networks honor the registry status during validation
## Integration Checklist (High Level)
* Identify the block-building hook for transaction validation
* Configure access to registry data and assertion bytecode
* Ensure the enforcer respects staged vs enforced assertions as set by protocol teams
* Define validation policy for L1-originated transactions and repeated invalid submissions
* Set up monitoring and incident review workflows
## Integration Requirements (Public)
* **Block-building hook** that can query the enforcer before inclusion
* **Registry access** for assertion discovery (on-chain events indexed locally)
* **DA access** for assertion bytecode retrieval
* **Incident visibility** through the Phylax platform
## Next Steps
Detailed system architecture and transaction flow
Plugin-based integration pattern for Besu
Sidecar validation flow and enforcement role
OP Stack integration notes