Frax Governance (frxGov) is an on-chain governance system set to be implemented by Frax Finance. It is set to revolutionize the Frax ecosystem, ushering in a new era of trustless protocol management.
In this article, we delve into the exciting world of Frax Governance, exploring its innovative features and the potential it holds for the future of decentralized finance.
Now, with its code currently undergoing an audit, frxGov aims to establish a robust governance framework that enables Frax to operate independently, free from reliance on the core team.
This transformative system empowers veFXS token holders, offering them the ability to veto proposals, replace signers, and initiate transactions entirely on-chain. It allows veFXS token holders to propose and vote on governance actions through two different contracts:
FraxGovernorAlpha and
FraxGovernorOmega
FraxGovernorAlpha is used for high-quorum situations and one-off governance parameter changes, while FraxGovernorOmega is a special contract that enables the Frax team to submit proposals corresponding to Gnosis Safe transactions.
Let’s delve deeper…
FraxGovernorAlpha:
FraxGovernorAlpha is designed with a high quorum requirement and is responsible for controlling the Gnosis Safes. The Gnosis Safe here, is a robust and versatile multi-signature smart contract wallet, providing users with the ability to establish a designated group of owner/signer accounts and set a specific threshold for transaction confirmation. By defining this threshold, users can ensure that a predetermined number of signers must endorse a transaction before it can be executed within the Safe.
To integrate FraxGovernorAlpha into the underlying Gnosis Safes, its TimelockController must be set as a module. This contract holds full control over the Gnosis Safes and all governance parameters, including those related to FraxGovernorOmega.
The general flow of FraxGovernorAlpha follows the same pattern as the OpenZeppelin Governor contract. Proposals are made through the propose() function, which can only be called by veFXS token holders.
FraxGovernorOmega:
FraxGovernorOmega is a contract with a lower quorum requirement compared to FraxGovernorAlpha. It operates as a signer on the underlying Gnosis Safe, granting limited control. Similar to FraxGovernorAlpha, only veFXS token holders can initiate proposals through the propose() function.
However, proposals using FraxGovernorOmega are intended to be used infrequently and for specific cases, such as recovering tokens mistakenly sent to a certain address.
The general flow of FraxGovernorOmega involves the following steps:
1. DeFi transaction initiation:
An owner initiates a DeFi transaction using the Gnosis Safe, generating a transaction hash that identifies the action.
2. EOA signature collection:
Three out of five owners of externally owned accounts (EOAs) sign the transaction through the user interface (UI).
3. Calling addTransaction():
Once three signatures are collected, anyone can call the function fraxGovernorOmega.addTransaction(address teamSafe, TxHashArgs calldata args, bytes calldata signatures) to initiate the on-chain governance process. This step is incentivized for the Frax team since they require FraxGovernorOmega's approval to execute any Gnosis transaction.
4. Voting window:
veFXS voters then have a two-day window to vote on the proposal.
5. Execution or veto:
If the voting window concludes without meeting the quorum or if there are more votes against the proposal than for it, anyone can call the execute() function. This function internally calls safe.approveHash() from FraxGovernorOmega, providing the necessary approval to execute the Gnosis transaction through the Gnosis UI.
In the case of a veto, fraxGovernorOmega.rejectTransaction(address teamSafe, uint256 nonce) is called, causing FraxGovernorOmega to sign a zero ETH transfer Gnosis transaction with the same nonce. Safe owners can then sign the same transaction in the UI using the "replace transaction" functionality and execute the zero ETH transfer, incrementing the nonce.
As a result, the original transaction becomes invalid as it lacks approval from FraxGovernorOmega and the nonce has moved forward.
Abort Transaction Flow:
The abort transaction flow exists to stop a Gnosis transaction that is considered incorrect or no longer necessary. The steps are as follows:
1. Rejection transaction initiation:
An EOA owner starts a rejection transaction through the Gnosis Safe UI.
2. EOA signature collection:
Three out of five EOAs sign the rejection transaction.
3. Calling abortTransaction():
Anyone can call the function fraxGovernorOmega.abortTransaction(address teamSafe, bytes calldata signatures), which immediately triggers Omega to approve the rejection transaction (a zero ETH transfer) on the underlying Gnosis Safe with the provided nonce.
Execution of the approved transaction:
Safe owners can now execute the approved transaction, which increments the nonce, rendering the original transaction and any associated veto proposal useless. If the original transaction was already added to FraxGovernorOmega with addTransaction(), the corresponding proposal will be marked as ProposalState.Cancelled, preventing further voting on it.
Tests:
To run the tests, you need to create a virtual environment and install Vyper 0.2.12. This is necessary because of the deployment of the actual veFXS.vy contract relies on VyperDeployer. Here are the steps to run the tests:
Create a virtual environment and install Vyper 0.2.12:
virtualenv -p python --no-site-packages ~/vyper-venv source ~/vyper-venv/bin/activate pip install vyper==0.2.12
Navigate to the project directory:
cd $PROJECT_DIR
Run the tests:
forge test
Coverage: To generate coverage reports, use the following commands:
forge coverage --report lcov genhtml lcov.info -o report --branch-coverage open report/index.html
This will generate coverage reports in the
report
directory and open the index.html file in a browser to view the results.Deploy: Before deploying, make sure to update the Constants.sol file with the necessary configuration.
Local Deploy:
For local deployment using a forked network, execute the following commands:
forge script script/test/DeployTestFxs.s.sol:DeployTestFxs --fork-url http://localhost:8545 --broadcast
forge script script/test/DeployTestnet.s.sol:DeployTestnet --fork-url http://localhost:8545 --broadcast
Arbitrum Deploy (test):
To deploy on the Arbitrum network for testing purposes, use the following commands:
forge script script/test/DeployTestFxs.s.sol:DeployTestFxs --rpc-url $ARBI_RPC_URL -vvvvv --verify --etherscan-api-key $ARBISCAN_KEY --verifier-url $ARBISCAN_API_URL
forge script script/test/DeployTestnet.s.sol:DeployTestnet --rpc-url $ARBI_RPC_URL -vvvvv --verify --etherscan-api-key $ARBISCAN_KEY --verifier-url $ARBISCAN_API_URL
Make sure to replace the `$ARBI_RPC_URL`, `$ARBISCAN_KEY`, and `$ARBISCAN_API_URL` with the appropriate values.
Deploying MockVeFxs on Arbitrum:
To deploy the MockVeFxs contract on Arbitrum using Remix, follow these steps:
1. Open Remix and install the Vyper Remix plugin.
2. Bump the version of `veFXS.py` to 0.2.16.
3. Deploy the contract through Remix.
4. Obtain the ABI-encoded parameters from Remix, as it will be required for verification on Arbiscan.
5. Verify the contract on Arbiscan, providing the ABI-encoded parameters and necessary details.
Contract Verification:
To verify a contract, use the `forge verify-contract` command with the appropriate parameters. For example:
forge verify-contract $CONTRACT_ADDRESS src/VeFxsVotingDelegation.sol:VeFxsVotingDelegation --verifier-url $ARBISCAN_API_URL --etherscan-api-key $ARBISCAN_KEY --chain 42161 --constructor-args $CONSTRUCTOR_ARGS --show-standard-json-input
Make sure to replace `$CONTRACT_ADDRESS`, `$ARBISCAN_API_URL`, `$ARBISCAN_KEY`, `$CONSTRUCTOR_ARGS`, and other required values accordingly.
My fears:
Like all on-chain governance platforms out there, there is still a potential risk of centralization or concentration of power within the Frax Governance system.
While this proposed system aims to promote decentralized decision-making through on-chain governance and veFXS token holder participation, there may still be a possibility of a small group of token holders exerting significant influence or control over governance actions. This concentration of power could potentially undermine the democratic and inclusive nature of the governance process.
Conclusion:
Frax Finance has established itself as a prominent platform that embraces decentralization and community engagement in its decision-making processes. The introduction of the Frax Governance system further strengthens this commitment by empowering veFXS token holders to actively contribute to the governance parameters and actions within the Frax Finances protocol.
This approach fosters transparency, accountability, and inclusivity. It promotes a democratic framework that encourages open participation and input from the community, thus ensuring that the platform's direction aligns with the collective interests of its stakeholders.
As the Frax Governance system evolves, it will be fascinating to witness the impact it has on the Frax ecosystem and the broader DeFi landscape. Its success has the potential to set a precedent for other projects to follow, inspiring the adoption of similar community-driven governance models that prioritize the interests of token holders.