Skip to main content
Summary
  • Comparable to writing Forge invariant tests when invariants are defined
  • Written in Solidity with familiar patterns
  • Few additional cheatcodes to learn
  • Main variable: whether invariants are already defined

​
Effort Factors

Development effort depends on whether invariants are already defined for your protocol.

​
Invariants Defined

When invariants exist, writing assertions is similar to writing Forge invariant tests:
  • Workflow: Write Solidity, test with pcl test(fork of forge), deploy via the dApp
  • Learning curve: A small set of cheatcodes for state comparison (ph.forkPreTx(), ph.forkPostTx(), etc.)
  • Familiarity: Developers who write Forge tests can write assertions

​
Invariants Not Defined

You can write assertions without pre-defined invariants, but having them makes the process easier, more structured, and lowers the risk of overlooking attack vectors. Defining invariants involves identifying:
  • States that should never occur
  • Relationships that must always hold (e.g., total supply = sum of balances)
Some teams do this internally; others engage security researchers or auditors. For guidance, see Intro to Invariants ↗.

​
Testing Assertions

Testing assertions can take longer than writing them. However, assertion tests reuse existing protocol test infrastructure. Existing Forge test setups carry over with minimal to no additional effort. See Testing Assertions for patterns and best practices.

​
Next Steps

Quickstart

Write and deploy your first assertion

Assertion Guide

Step-by-step guide to writing assertions

Cheatcodes

Learn the additional tools available

Testing

Test your assertions locally