.png)
At their core, assertions are simple yet powerful: They're functions that check if a smart contract's state is valid or invalid according to specific rules. Think of assertions as guardians who continuously monitor smart contracts, transaction by transaction, ensuring they never enter a state that is defined as undesired by the protocol. Be it invariant changes in the protocol logic or unexpected ownership changes in the business logic. Check out the Whitepaper here for a more in-depth explanation of how the Credible Layer and all the underlying components work.
Unlike traditional security measures that try to enumerate all possible attacks, assertions flip the model: they define what states must never occur. This "negative intent" approach is particularly powerful for security, as it's often easier and more comprehensive to specify what shouldn't happen than to predict every possible valid interaction.
At its heart, an assertion is a function that defines blockchain states as boolean values: true for valid states and false for invalid ones. However, this simple interface enables powerful security guarantees through its implementation details.
Assertions run in a modified version of the EVM called the PhEVM. This specialized environment gives assertions access to:
This rich context allows assertions to perform complex validations that would be impossible or prohibitively expensive to do on-chain.
Let's walk through how an assertion might prevent a lending protocol exploit:
Let's look at some practical examples of how assertions can prevent common types of exploits:
Consider the recent Radiant Capital hack. An assertion could have specified that their critical ownership variable should never change from its initial value. Even if a vulnerability in the contract's logic existed, any transaction attempting to change the owner would be blocked. The protocol would need to explicitly disable this assertion before making legitimate ownership changes, adding an extra security layer.
For lending protocols like Cream Finance (which suffered a major exploit), assertions could specify:
Assertions can encode complex protocol-specific safety requirements:
Many DeFi hacks involve oracle manipulation. Assertions can prevent these by specifying:
What makes assertions particularly powerful is their ability to encode complex security requirements that would be impractical or impossible to implement in smart contracts:
1. Cross-Transaction Analysis: Assertions can look at patterns across multiple transactions, identifying sophisticated attacks that span multiple steps.
2. Resource-Intensive Calculations: Since they're computed off-chain, assertions can perform complex mathematical validations that would be too gas-intensive to do on-chain.
3. Dynamic Security: Assertions can be added, modified, or removed without changing contract code, allowing security to evolve with new threat discoveries.
4. Intent Verification: They can verify that transactions have their intended effect, catching subtle manipulation attempts that technically follow the rules but achieve malicious outcomes.
Assertions represent more than just another security tool - they're a fundamental rethinking of how we approach blockchain security. By moving from a model of "define what's allowed" to "define what's forbidden" they provide a more natural and comprehensive way to express security requirements.
This approach is particularly valuable as DeFi protocols become more complex and interconnected. Instead of trying to anticipate every possible attack vector, teams can focus on defining their protocol's fundamental safety properties and let assertions enforce them automatically.
The ability to add security checks without modifying contract code also means that security can evolve without risking new vulnerabilities through upgrades. This separation of security logic from business logic represents a significant advancement in how we build and maintain secure protocols.
As the ecosystem continues to grow, assertions will likely become a standard primitive for protocol security, as fundamental as multisigs or time locks are today. They provide the tools we need to build truly robust protocols that can withstand sophisticated attacks while remaining flexible enough to evolve with new threats.
The Credible Layer represents a fundamental shift in blockchain security. Instead of reacting to attacks, we're creating an environment where hacks are prevented by the underlying infrastructure.
If you have any questions about the Credible Layer or the whitepaper in general, please join our Discourse and join the discussion.
If you're interested in integrating the Credible Layer or contributing to its development, join our Telegram chat here.
