Skip to main content

Overview

Reserve Folio uses the ERC1967 proxy pattern to enable upgradeability while maintaining security and decentralization. All upgrades must go through the FolioVersionRegistry to ensure only approved implementations can be used.

Proxy Architecture

FolioProxy

Each Folio is deployed as a proxy that delegates calls to a shared implementation:
Key characteristics:
  • Uses ERC1967 storage slots to avoid collisions
  • Admin can only call upgradeToAndCall()
  • All other calls are delegated to the implementation
  • Follows transparent proxy pattern

FolioProxyAdmin

The admin contract validates upgrades against the version registry:

Version Registry

Registration

The DAO registers new Folio versions through FolioVersionRegistry:

Deprecation

Versions can be marked deprecated by the DAO or emergency council:
Deprecated versions cannot be upgraded to, but existing Folios running deprecated versions continue to function. Folio owners should upgrade to the latest version when deprecations occur.

Upgrade Process

1. DAO Registers New Version

2. Folio Admin Proposes Upgrade

3. Governance Approval

4. Post-Upgrade Verification

Storage Layout

Folio uses OpenZeppelin’s upgradeable contracts with careful storage management:
Storage safety rules:
  • Never remove or reorder existing storage variables
  • Only append new variables at the end
  • Use storage gaps for future expansion (if needed)
  • Mark deprecated storage with _DEPRECATED suffix

Version Strings

Folio versions follow semantic versioning:
Version components:
  • Major: Breaking storage layout changes
  • Minor: New features, backward compatible
  • Patch: Bug fixes, no storage changes

Querying Version Information

Current Folio Version

Latest Available Version

Check Version Status

Security Considerations

Access Control

  • Version registration: Only DAO owner
  • Version deprecation: DAO owner or emergency council
  • Folio upgrades: Folio’s DEFAULT_ADMIN_ROLE (typically governance timelock)

Upgrade Validation

Time Delays

Upgrades typically go through governance timelocks:
Never skip timelock delays for upgrades. This gives users time to exit if they disagree with the upgrade.

Deployment Architecture

Components

  1. FolioVersionRegistry: Central registry of approved versions (1 per ecosystem)
  2. FolioDeployer: Version-specific deployer (1 per version)
  3. FolioImplementation: Shared logic contract (1 per version)
  4. FolioProxy: Individual Folio proxy (1 per Folio)
  5. FolioProxyAdmin: Upgrade executor with registry validation (1 per Folio)

Example: Full Upgrade Flow