Overview
Security posture, smart contract architecture, and operational safeguards for the DomFi protocol on Base.
Smart Contract Architecture
The protocol consists of 10 upgradeable contracts deployed behind OpenZeppelin TransparentUpgradeableProxy instances, plus 6 non-upgradeable contracts. All contracts resolve each other through a central DomfiRegistry.
Upgrades are governed by DomfiTimelockOwner, which enforces role-based access control. ProxyAdmin manages all proxy upgrades.
CONTRACT ARCHITECTURE
TRADING FLOW
ORACLE PIPELINE
VAULT & LP
GOVERNANCE & INFRASTRUCTURE
See the Contract Reference for a full list of deployed addresses and roles.
Access Control
Four roles managed by DomfiTimelockManager:
| Role | Capabilities |
|---|---|
| Governor | Register contracts, add trading pairs, set fee schedules, admin operations |
| Developer | Claim accumulated dev fees |
| Manager | Set max open interest per pair |
| Deployer | Initial deployment only — not used for ongoing operations |
All governance operations are subject to a timelock delay via DomfiTimelockOwner.
Operational Safeguards
- Oracle verification — price data is verified on-chain via ECDSA signatures (
DomfiVerifier). Only prices signed by a registered authorized signer are accepted. - Anomaly detection — the oracle pipeline rejects price ticks that diverge more than 50% from CoinGecko reference market caps, catching catastrophic data errors at ingest time. A separate delta check carries forward the previous dominance value if any asset's dominance moves more than 2 percentage points between publish cycles.
- Timelock governance — all contract upgrades and configuration changes pass through a timelock, preventing instant unilateral changes.
- Proxy separation —
ProxyAdminis a separate non-upgradeable contract, isolating upgrade authority from application logic.