Architecture

An overview of Fira's system architecture, module dependencies, and cross-cutting design decisions.

System overview

The Fira protocol is organized into a layered architecture where each module has a clear responsibility and well-defined dependencies.

Solid arrows = primary dependencies. Dashed purple arrows = support modules.

Module dependency graph

The dependency flow is: Router → Market + YieldContracts → FW → Underlying Vault

  • The Router holds no state of its own (beyond selector mappings). Each action facet reads market and yield contract state, orchestrates token transfers, and calls into the market or CT contract to execute operations.

  • The Market depends on CT for the BC index (needed for pricing) and on the factory for fee configuration.

  • CT depends on FW for the exchange rate (to compute the BC index) and on BT for mint/burn gating.

  • FW tokens wrap external yield sources (ERC-4626 vaults) and expose a standardized deposit/redeem interface.

  • The RehypothecationModule controls how much of FW's underlying sits idle vs. deployed in the vault.

Cross-cutting concerns

Reentrancy

Every external entry point uses nonReentrant from FiraERC20. The router relies on the market and CT contracts for reentrancy protection — the router itself has no reentrancy guard because it delegates all state-changing calls to contracts that do.

Access control

Component
Owner controls

Factory

Market fee configuration

CT Factory

Interest fee configuration, treasury address

FW

Pausing, rehypothecation module assignment

Router

Selector-to-facet mappings

LiquidityInjector

BT injection and withdrawal

Upgradability

  • Markets and yield contracts are not upgradeable — deployed via factories and immutable once created.

  • The Router is pseudo-upgradeable — the owner can point selectors at new facet addresses, effectively upgrading logic without migrating state.

  • FW tokens use BoringOwnableUpgradeable and the initializer pattern for proxy-based upgradability.

Last updated