Skip to main content
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 sits between the mempool and block production:
  1. Receives transactions from the network validator
  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 without code changes to the sequencer
  • Scales separately from the main network components
  • Fails gracefully without affecting L2 operations
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 queries the on-chain registry 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 network validator receives clear valid/invalid signals
  • Block production continues normally with validated transactions

​
Forced Inclusion Transactions

Forced inclusion transactions (such as L1→L2 deposits) require special handling since they must be included regardless of assertion results. The Credible Layer has mitigation pathways for these scenarios.
We have developed a solution for forced inclusion transactions and are actively implementing it. Ask us about it!

​
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 ensures validation latency doesn’t impact block production times.