[review] MIP-48: Aptos Governance - Governed Gas Pool

MIP/mip-0/README.md

@@ -1,60 +1,138 @@
-# MIP-0: MIPs
-- **Description**: Movement Improvement Proposals standardize and formalize specifications for Movement technologies.
-- **Authors**: [Liam Monninger](mailto:liam@movementlabs.xyz)
-- **Desiderata**: [MD-0](../MD/md-0)
+# MIP-\<number\>: use `aptos_governance` for Goverened Gas Pool
+- **Description**: ????
+- **Authors**: [Richard Melkonian](mailto:richard@movementlabs.xyz)
 
 ## Abstract
 
-Movement Improvement Proposals (MIPs) serve as a mechanism to propose, discuss, and adopt changes or enhancements to Movement technologies. By providing a standardized and formalized structure for these proposals, MIPs ensure that proposed improvements are well-defined, transparent, and accessible to the wider community.
+The Goverened Gas Pool design presented in [MIP-44](../mip-44/) is required to be subject to onchain governance by a governing body that holds the
+`$L2-MOVE` token. In [MIP-44] governance mechanisms and roles are proposed, such as `Proposers` and `Executors` so that the collected gas can be used 
+for the good of the network.
 
-## Motivation
-
-Movement technologies continually evolve, and there's a need to ensure that the process of proposing and adopting changes is both organized and standardized. By establishing MIPs, we aim to facilitate the introduction of new features or improvements, making sure they are well-vetted, discussed, and documented. This ensures the integrity of Movement technologies, making it easier for third parties to adopt and adapt to these changes.
+The Governed Gas Pool may be used to provide liquidity for different network needs, such as L1 Reward Tokens, or to enable the "Trickle-back", where the `$L2-MOVE` would be paid 
+directly to attestors as `$L1-MOVE` for rewards. For all these activities a dispersal of funds is required, this MIP proposes concrete ways to manage dispersal events 
+in a safe immutable and secure manner. 
 
-## Specification
+To decide on how acrued `$L2-MOVE` in the Governed Gas Pool should be used, a robust and thorough implementation of governance should be proposed. 
 
-A Movement Improvement Proposal (MIP) is a design document that provides information to the Movement community, describing a new feature or improvement for Movement technologies.
-
-- **Structure**: Each MIP must adhere to the given template, which requires details like title, description, author, status, and more. A MIP also includes sections like Abstract, Motivation, Specification, Reference Implementation, Verification, Errata, and Appendix. 
+## Motivation
 
-    - An md-template is provided in the [MIP Repository](https://github.com/movemntdev/MIP) which further specifies this structure. This MIP is an example of said structure.
-
-- **Lifecycle**: An MIP starts as a draft, after which it undergoes discussions and revisions. Once agreed upon, it moves to a 'published' status. An MIP can also be deprecated if it becomes obsolete.
+This MIP proposes an implementation of the governance mechanism proposed in [MIP-44] by using the `aptos_governance.move` module. We think this has several benefits. 
+1. `aptos_governance.move` is fully audited and battle tested.
+2. `aptos_governance.move` is currently in use on the Aptos Blockchain. 
+3. Using aptos governance prepares us for extendeding it and using it for future proposals to upgrade or migrate the network, this will be a fairly common necessity post-mainnet.
+4. It strenghtens the utility of `$L2-MOVE` as this becomes the governance token. 
 
-- **Storage**: MIPs should be stored in the MIPs directory at [MIP Repository](https://github.com/movemntdev/MIP). 
+## Specification
 
-- **Definitions** : Provide definitions that you think will empower the reader to quickly dive into the topic.
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
 
 ## Reference Implementation
 
-A reference implementation or a sample MIP following the MIP template can be provided to guide potential proposers. This MIP (MIP-0) serves as a practical example, aiding in understanding the format and expectations.
+The `governed_gas_pool.move` would interact with `aptos_framework.move`, seperating the roles of actual governance, voting and storing of gas and dispersing those funds.
+
+```rust
+//pseudocode
+module GovernedGasPool::goverened_gas_pool {
+    use aptos_framework::aptos_coin::AptosCoin;
+    use aptos_framework::coin;
+    use aptos_framework::signer;
+    use aptos_framework::aptos_governance;
+    use aptos_framework::aptos_governance::{self, GovernanceProposal};
+    use aptos_std::vector;
+    use aptos_std::option::{self, Option};
+
+    // Address of the governance framework module
+    const GOVERNANCE_ADDRESS: address = @0x1;
+
+    struct GovernedPool has key {
+        funds: coin::Coin<AptosCoin>,                // holds the pool of funds in AptosCoin
+        passed_proposals: vector::Vector<Proposal>,  // list of proposals that passed governance
+        admin: address                               // address with permission to execute proposals
+    }
+
+    struct DispersalAction has copy, drop, store {
+        recipient: address,
+        amount: u64
+    }
+
+    struct Proposal has key {
+        id: u64,
+        dispersal_action: Option<DispersalAction>, // Only one type of action at a time
+        executed: bool,
+    }
+
+    /// Initialize the Governed Pool
+    public fun initialize_governed_pool(admin: &signer, authorized_admin: address): address {
+        let governed_pool = GovernedPool {
+            funds: coin::zero<AptosCoin>(),
+            passed_proposals: vector::empty<Proposal>(),
+            admin: authorized_admin
+        };
+        let addr = signer::address_of(admin);
+        move_to(admin, governed_pool);
+        addr
+    }
+
+    /// Add a proposal that has passed governance
+    /// Only callable by the governance module at address 0x1
+    public fun add_passed_proposal(
+        pool: &mut GovernedPool,
+        governance_signer: &signer,
+        id: u64,
+        dispersal_action: DispersalAction
+    ) {
+        // Ensure only the governance framework can call this function
+        assert!(signer::address_of(governance_signer) == GOVERNANCE_ADDRESS, 1);
+
+        // Verify that the proposal is approved in aptos_governance
+        assert!(aptos_governance::is_proposal_approved<GovernanceProposal>(id), 2);
+
+        let proposal = Proposal {
+            id,
+            dispersal_action: option::some(dispersal_action),
+            executed: false,
+        };
+        vector::push_back(&mut pool.passed_proposals, proposal);
+    }
+
+    /// Execute a proposal that has been approved by governance
+    /// Only callable by the designated admin
+    public fun execute_passed_proposal(pool: &mut GovernedPool, executor: &signer, proposal_id: u64) {
+        // Ensure only the authorized admin can call this function
+        assert!(signer::address_of(executor) == pool.admin, 2);
+
+        let proposal_index = find_proposal(&pool.passed_proposals, proposal_id);
+        let proposal = &mut vector::borrow_mut(&mut pool.passed_proposals, proposal_index);
+
+        // Ensure the proposal hasn't already been executed
+        assert!(!proposal.executed, 3);
+
+        // Execute the dispersal action if present
+        if (option::is_some(&proposal.dispersal_action)) {
+            let action = option::borrow(&proposal.dispersal_action).unwrap();
+            let amount = action.amount;
+            assert!(amount <= coin::value(&pool.funds), 4); // Ensure pool has sufficient funds
+            coin::withdraw(&mut pool.funds, amount);
+            coin::deposit(&signer::create(action.recipient), amount);
+        };
+
+        proposal.executed = true;
+    }
+}
+```
+
+Notice the call :
+`assert!(aptos_governance::is_proposal_approved<GovernanceProposal>(id), 2);`
 
 ## Verification
 
-1. **Correctness**: Each MIP must convincingly demonstrate its correctness.
-
-This MIP is correct insofar as it uses a structure established by Ethereum for Improvement Proposals which has hitherto been successful.
-
-2. **Security Implications**: Each MIP should be evaluated for any potential security risks it might introduce to Movement technologies.
-
-The primary security concern associated with this MIP is the exposure of proprietary techologies or information via the ill-advised formation of an MIP which the MIP process might encourage.
-
-3. **Performance Impacts**: The implications of the proposal on system performance should be analyzed.
-
-The primarry performance concern associated with this MIP is its potential for overuse. Only specifications that are non-trivial and very high-quality should be composed as MIPs.
-
-4. **Validation Procedures**: To the extent possible, formal, analytical, or machined-aided validation of the above should be pursued. 
-
-I'm using spellcheck while writing this MIP. You can verify that I am using valid grammar by pasting this sentence into Google Docs.
-
-5. **Peer Review and Community Feedback**: A section should be included that captures significant feedback from the community, which may influence the final specifications of the MIP.
-
-The Movement Labs team is currently reviewing and assessig this process.
 
 ## Errata
 
-Post-publication corrections, if any, to the MIPs should be documented in this section. This ensures transparency and provides readers with accurate and up-to-date information.
 
 ## Appendix
 
-The Appendix should contain references and notes related to the MIP. Materials referenced in the MIP should be marked with specific labels (e.g., ⟨R1⟩) for easy tracking and understanding.
+---
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).