Assertion Enforcer

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.

The Assertion Enforcer is a sidecar component that validates transactions against assertions during block production. It operates alongside the network’s sequencer or block builder, intercepting transactions and determining which should be included in blocks.

​

Role in the System

The Assertion Enforcer operates inside the block production pipeline:

1. Receives candidate transactions from the block builder or sequencer
2. Identifies which assertions apply to each transaction
3. Invokes PhEVM to execute assertions against transaction states
4. Returns validation results (valid/invalid) to the network
5. Only valid transactions are included in blocks

​

Sidecar Architecture

As a sidecar, the Assertion Enforcer:

• Operates independently from the main L2 infrastructure
• Integrates alongside block builders without changing core protocol rules
• Scales separately from the main network components
• Preserves network continuity by keeping block production policy under the network operator’s integration

This design allows networks to adopt the Credible Layer without modifying their core infrastructure.

​

Validation Process

When a transaction arrives for validation, the Assertion Enforcer orchestrates the following process:

​

Step-by-Step

1. Identify Relevant Assertions: The Assertion Enforcer consults registry data (indexed from on-chain events) to find which assertions apply to the contracts the transaction interacts with
2. Fetch Assertion Bytecode: Assertion bytecode is retrieved from internal cache (populated from Assertion DA when assertions are deployed)
3. Simulate Transaction: The transaction is executed against pre-transaction state to produce the post-transaction state
4. Execute Assertions: PhEVM runs all relevant assertions with access to:
   • The transaction itself
   • Pre-transaction state (State1)
   • Post-transaction state (State2)
5. Return Result:
   • If any assertion reverts → transaction is invalid
   • If all assertions pass → transaction is valid

​

Block Building Integration

The Assertion Enforcer integrates with block builders to ensure only valid transactions enter blocks:

• Transactions that would violate assertions are dropped before block inclusion
• The block builder or sequencer receives clear valid/invalid signals
• Block production continues normally with validated transactions

​

Performance Model

The Assertion Enforcer is designed to keep the synchronous block-building path small. In the common case, the block builder pays for routing work such as metadata collection, assertion selection, checkpoint creation, and work submission. Assertion execution itself can run separately from that serial path, depending on the network integration. The important performance constraint is keeping assertion work bounded and predictable for the transaction workload. Network integrations use bounded queues, publication policies, fine-grained triggers, deterministic gas or runtime limits, and bounded execution surfaces to keep validation predictable. The enforcer also avoids network fetches on the transaction hot path. Assertion bytecode is fetched after deployment events and cached before validation.

​

Production Admission and Resource Limits

Production execution uses the active assertion set admitted through the configured registry and review process. Production assertion admission should account for:

• Protected protocol surface and trigger conditions
• Expected trigger frequency
• Maximum gas or runtime budget
• Expected read footprint
• Deterministic behavior and read-only execution
• Historical backtesting and staging behavior
• Suitability for common acceleration paths, such as compact trace summaries or native helper functions

These controls keep block-building resources predictable and help protocol teams understand which assertions are ready to promote from staging to production.

​

Operational Expectations (Public)

• Non-invasive: Runs alongside existing block builders without changing consensus rules
• Deterministic: Results are based on on-chain state and assertion code only
• Staging support: Networks can validate assertions before enforcing them in production
• Transparent outcomes: Incidents are visible in the platform and dashboard

​

Assertion Caching

To ensure high-performance validation, the Assertion Enforcer maintains an internal cache of assertion bytecode:

• On deployment: When an assertion is deployed on-chain, the Assertion Enforcer detects the event and fetches bytecode from Assertion DA
• During validation: Assertions are loaded from cache. No network requests occur on the hot path.

This caching strategy keeps assertion data retrieval out of the block-production hot path.

​

Learn More