FREI-PI Pattern

The FREI-PI pattern (Function Requirements–Effects–Interactions–Protocol Invariants) is a smart contract design pattern published by Nascent that extends the classic Checks-Effects-Interactions (CEI) pattern with an explicit protocol-level invariant check after every state-changing operation.

The four phases

1. Function Requirements — validate all preconditions (input bounds, caller permissions, state prerequisites) at the start of the function.
2. Effects — apply all state updates before any external interaction.
3. Interactions — perform external calls (token transfers, CPI, oracle reads, callbacks).
4. Protocol Invariants — after the interaction completes, verify that system-level invariants still hold. Revert the entire transaction if any invariant is violated.

The key difference from CEI is step 4. CEI protects against reentrancy by ordering operations. FREI-PI adds a final verification that the protocol's global safety properties (total collateral covers total debt, balances sum to supply, etc.) survived the whole sequence.

Why it matters for audits

Projects that adopt FREI-PI hand auditors a codebase where the invariants are encoded directly into the runtime. The invariants become testable: Foundry and Echidna can fuzz the invariant checks, and any violation is caught at the end of every transaction, not just during dedicated invariant tests. This is why the pattern is highly valued during audit-readiness reviews — it signals that the team has thought carefully about what "safe" means at the protocol level, not just at the function level.

How it complements CEI

FREI-PI does not replace Checks-Effects-Interactions — it extends it. Treat all token and ETH transfers as interactions, order effects before them (CEI), and add a protocol invariant check after them (the PI step). Nascent's published examples apply the pattern to lending protocol borrow and repay functions, where a single line of invariant checking at the end of each function prevents entire categories of economic exploits.

Relationship to the invariants list auditors request

A roles table, an invariants list, and an acceptable-issues list are the three pre-audit documents most firms ask for. FREI-PI turns the invariants list from a design artifact into a runtime check. If your team can hand over both the list and the code that enforces it at the end of every state-changing function, auditors spend their time stress-testing whether the invariants are the right ones, not whether they hold.