115 lines
2.1 KiB
Markdown
115 lines
2.1 KiB
Markdown
|
# Governance Framework
|
||
|
|
|
||
|
|
## Overview
|
||
|
|
|
||
|
|
This document outlines the governance framework for the DeFi Oracle Meta Mainnet (ChainID 138).
|
||
|
|
|
||
|
|
## Governance Structure
|
||
|
|
|
||
|
|
### Admin Role
|
||
|
|
|
||
|
|
The admin role has full control over:
|
||
|
|
- Oracle aggregator configuration
|
||
|
|
- CCIP router configuration
|
||
|
|
- Transmitter management
|
||
|
|
- Fee configuration
|
||
|
|
|
||
|
|
### Transmitter Role
|
||
|
|
|
||
|
|
Transmitters can:
|
||
|
|
- Update oracle answers
|
||
|
|
- Submit oracle data
|
||
|
|
|
||
|
|
## Proposal Process
|
||
|
|
|
||
|
|
### 1. Proposal Creation
|
||
|
|
|
||
|
|
Proposals can be created for:
|
||
|
|
- Parameter changes (heartbeat, deviation threshold)
|
||
|
|
- Transmitter additions/removals
|
||
|
|
- Fee adjustments
|
||
|
|
- Contract upgrades
|
||
|
|
|
||
|
|
### 2. Proposal Review
|
||
|
|
|
||
|
|
- Technical review
|
||
|
|
- Security assessment
|
||
|
|
- Impact analysis
|
||
|
|
|
||
|
|
### 3. Proposal Execution
|
||
|
|
|
||
|
|
- Admin approval required
|
||
|
|
- Multi-sig for critical changes
|
||
|
|
- Timelock for major upgrades
|
||
|
|
|
||
|
|
## Voting Mechanisms
|
||
|
|
|
||
|
|
### Current Implementation
|
||
|
|
|
||
|
|
- Admin-based governance
|
||
|
|
- Single admin address
|
||
|
|
- Immediate execution
|
||
|
|
|
||
|
|
### Future Enhancements
|
||
|
|
|
||
|
|
- Multi-sig admin
|
||
|
|
- Timelock contracts
|
||
|
|
- On-chain voting
|
||
|
|
- DAO governance
|
||
|
|
|
||
|
|
## Upgrade Procedures
|
||
|
|
|
||
|
|
### Contract Upgrades
|
||
|
|
|
||
|
|
1. **Proposal**: Create upgrade proposal
|
||
|
|
2. **Review**: Technical and security review
|
||
|
|
3. **Testing**: Test on testnet
|
||
|
|
4. **Approval**: Admin approval
|
||
|
|
5. **Execution**: Deploy upgrade
|
||
|
|
6. **Verification**: Verify upgrade success
|
||
|
|
|
||
|
|
### Parameter Changes
|
||
|
|
|
||
|
|
1. **Proposal**: Document parameter change
|
||
|
|
2. **Review**: Impact assessment
|
||
|
|
3. **Approval**: Admin approval
|
||
|
|
4. **Execution**: Execute parameter change
|
||
|
|
5. **Monitoring**: Monitor impact
|
||
|
|
|
||
|
|
## Security Controls
|
||
|
|
|
||
|
|
### Access Control
|
||
|
|
|
||
|
|
- Admin role restricted
|
||
|
|
- Transmitter whitelist
|
||
|
|
- Multi-sig for critical operations
|
||
|
|
|
||
|
|
### Audit Requirements
|
||
|
|
|
||
|
|
- Security audits before upgrades
|
||
|
|
- Code review for all changes
|
||
|
|
- Testing on testnet
|
||
|
|
|
||
|
|
## Compliance Requirements
|
||
|
|
|
||
|
|
### Documentation
|
||
|
|
|
||
|
|
- All changes documented
|
||
|
|
- Audit trails maintained
|
||
|
|
- Incident reports filed
|
||
|
|
|
||
|
|
### Reporting
|
||
|
|
|
||
|
|
- Regular status reports
|
||
|
|
- Incident notifications
|
||
|
|
- Security updates
|
||
|
|
|
||
|
|
## Best Practices
|
||
|
|
|
||
|
|
1. **Transparency**: Document all decisions
|
||
|
|
2. **Security**: Security-first approach
|
||
|
|
3. **Testing**: Test all changes
|
||
|
|
4. **Monitoring**: Monitor all changes
|
||
|
|
5. **Documentation**: Maintain documentation
|
||
|
|
|