The Optimism Stack isn't a dApp.
But it is critical infrastructure securing billions in TVL, across many major chains. A single bug doesn't just drain one protocol; it can compromise entire ecosystems. When infrastructure at this scale fails, the damage is measured in networks, not smart contracts.
This is why Optimism has spent time on Failure Mode Analysis (FMA): a systematic process to identify, analyze, and document potential failure modes before they become exploits.
But there’s a gap between identifying failure modes and preventing them. FMAs tell you what could go wrong; they don't make it impossible for those failures to occur.
That’s where our DevRel Jacob comes in.
He took some time to translate a selection of Optimism's comprehensive FMA documentation into executable assertions that can prevent these failure modes at the transaction level.
The key insight is that some FMA failure conditions map very well to assertion boolean logic, making it very easy to translate them into assertions.
A little primer for those of you who don’t know: the Credible Layer introduces assertions as a security primitive. These are functions that map blockchain state to boolean values, defining what states should never occur. Unlike traditional security, which tries to enumerate valid states, assertions specify invalid states that must be prevented. These assertions execute off-chain in a modified EVM run by the network as part of the block builder, validating every transaction against defined invariants before allowing execution. If any transaction breaks a rule, that transaction is removed.
Failure Mode Analysis
As documented in their security design docs, FMA's "shift-left" risk assessments so mitigations can be planned and implemented earlier. Rather than waiting for bugs to surface, FMAs systematically enumerate potential failure scenarios, assess their impact and likelihood, and document mitigation strategies.
The protocol has conducted extensive failure mode analyses across critical components: the Interop Portal, ETH Lockbox, Message Passing contracts, and more. Each FMA identifies specific failure modes with detailed analysis of their potential impact: from withdrawal safety failures to complete fund loss.
But here's the reason we’re writing this blog: many of these failure modes can be prevented by enforcing invariants at the sequencer level. For instance, if an FMA identifies that "incorrect state reporting by AnchorStateRegistry" could lead to withdrawal safety failures, assertions can validate state consistency before allowing withdrawal transactions to proceed.
FMA to Assertion Translation
Let's examine how specific failure modes identified in Optimism's FMAs map to executable assertions:
ETH Lockbox: Unauthorized Access Prevention
The ETH Lockbox is a contract that holds ETH for cross-chain operations, providing lockETH and unlockETH functions for portal contracts to manage funds during bridge operations.
FMA: Unauthorized access to lockETH and unlockETH functions could drain the lockbox.
OP’s Risk Assessment: CRITICAL impact, LOW likelihood due to access controls.
Our Assertions:
These assertions validate that only authorized portals can call lockETH and unlockETH functions. Any transaction attempting unauthorized lockbox access gets rejected before execution. They also check that there are no unauthorized transactions that drain the lockbox.
Message Passing: Replay Attack Prevention
Message passing contracts handle cross-chain message relay operations, ensuring messages sent between chains are properly validated and executed once.
FMA: Replay attacks could enable duplicate message execution, potentially leading to duplicate minting or asset theft.
OP’s Risk Assessment: CRITICAL impact, MEDIUM likelihood.
Our Assertions:
These assertions eliminate different errors and bugs by checking the successfulMessages mapping before any message is validated.
Interop Portal: State Consistency Validation
The Interop Portal manages cross-chain interactions and withdrawal processes, with the AnchorStateRegistry tracking state transitions across different chains.
FMA: Incorrect state reporting by AnchorStateRegistry could lead to withdrawal safety failures.
OP’s Risk Assessment: CRITICAL impact, LOW likelihood.
Our Assertions:
These assertions validate state changes in the AnchorStateRegistry, preventing incorrect state reporting that the FMA identified as a critical failure mode.
Implementation
The Credible Layer integration adds no new trust assumptions to the Optimism stack.
Since Optimism already controls their sequencer and smart contracts, implementing assertion validation simply leverages their existing infrastructure. The sequencer already has the authority to include or reject transactions—assertions provide a systematic framework for making those decisions based on security invariants.
This approach preserves Optimism's neutrality while enhancing security. The assertions themselves are derived from Optimism's own FMA analysis, making them protocol-native rather than externally imposed restrictions. Block builders and sequencers in the ecosystem can adopt these assertions voluntarily, creating a competitive advantage through enhanced security guarantees while maintaining the open, permissionless nature of the network.
They've already done the hard work of systematic failure mode identification through their FMA process. The assertions we've developed can serve as a starting point for further research into turning FMA research into preventative measures.
Conclusion
FMAs can translate directly to assertions, enabling prevention, demonstrating that assertions are relevant for more than just dApps. The result is infrastructure that doesn't just understand and plan mitigations for its failure modes; it actively prevents them at the block building level.
