1fb7266469
- Introduced Aggregator.sol for Chainlink-compatible oracle functionality, including round-based updates and access control. - Added OracleWithCCIP.sol to extend Aggregator with CCIP cross-chain messaging capabilities. - Created .gitmodules to include OpenZeppelin contracts as a submodule. - Developed a comprehensive deployment guide in NEXT_STEPS_COMPLETE_GUIDE.md for Phase 2 and smart contract deployment. - Implemented Vite configuration for the orchestration portal, supporting both Vue and React frameworks. - Added server-side logic for the Multi-Cloud Orchestration Portal, including API endpoints for environment management and monitoring. - Created scripts for resource import and usage validation across non-US regions. - Added tests for CCIP error handling and integration to ensure robust functionality. - Included various new files and directories for the orchestration portal and deployment scripts.
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
|
|
|