Security Practices

Security overview for the Fira Protocol, covering multi-layered defences baked into every contract layer.

Security approach

Multi-layered security strategy

1. Secure development practices — All Fira contracts follow battle-tested Solidity patterns from OpenZeppelin, with strict adherence to the checks-effects-interactions pattern and consistent use of custom errors for gas-efficient revert reasons.

2. Access control — Sensitive state changes are gated behind BoringOwnableUpgradeable ownership checks at the contract level and role-based function selectors in the Router facet architecture.

3. Reentrancy protection — State-mutating entry points in FWBase, FiraMarket, CouponToken, and the LiquidityInjector are protected by OpenZeppelin's ReentrancyGuard (nonReentrant modifier).

4. Pause controls — FW token contracts implement whenNotPaused guards, allowing the owner to freeze deposits and redemptions during incidents without requiring a contract upgrade.

5. Upgrade mechanisms — Contracts use the Initializable pattern with upgradeable proxies, enabling hotfixes while preserving storage layout. The Router uses a diamond-like facet system with versioned selectors.

6. Oracle safety — A multi-layer oracle pipeline (Aave → Chainlink adapter → Fira solvency oracle → BC/LP oracle) provides defence-in-depth for price feeds, with staleness checks at every layer.

7. Continuous monitoring — On-chain events are designed for real-time indexing, supporting anomaly detection across all role buckets (see Events & Indexing).

For detailed information on each security mechanism and how it applies across the contract stack, see Security Design.

Pages

• Security Design — In-depth coverage of access control, reentrancy, pause, and upgrade patterns

• Audits — Chronological overview of completed security audits