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
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
- FolioVersionRegistry: Central registry of approved versions (1 per ecosystem)
- FolioDeployer: Version-specific deployer (1 per version)
- FolioImplementation: Shared logic contract (1 per version)
- FolioProxy: Individual Folio proxy (1 per Folio)
- FolioProxyAdmin: Upgrade executor with registry validation (1 per Folio)
Example: Full Upgrade Flow