Network Integration Overview

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.

Use this page when your goal is to scope a network integration and identify the infrastructure surfaces your team will need. 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

​

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