Skip to content

Commit

Permalink
Merge pull request #328 from DXgovernance/develop
Browse files Browse the repository at this point in the history
v2.0.0 Release
  • Loading branch information
AugustoL authored Mar 15, 2023
2 parents 54410e2 + 8b42f57 commit 9dc284c
Show file tree
Hide file tree
Showing 241 changed files with 49,315 additions and 21,190 deletions.
14 changes: 8 additions & 6 deletions .env.example
Original file line number Diff line number Diff line change
@@ -1,10 +1,12 @@
// Required
KEY_MNEMONIC="seed phrase here"
KEY_INFURA_API_KEY="xxxx"
MNEMONIC_PHRASE="seed phrase here"

// Required to verify smart contracts
KEY_ETHERSCAN="xxx"
ETHERSCAN_API_KEY="xxx"

// Required for get reputation script
REP_FROM_BLOCK=7850172
REP_TO_BLOCK=12212988
// Required for mainnet and goerli, Alchemy RPCs have priority over Infura
INFURA_API_KEY="xxx"
ALCHEMY_API_KEY="xxx"

// To enable report of gas, default false
REPORT_GAS=true
2 changes: 2 additions & 0 deletions .eslintignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
coverage
docs
2 changes: 1 addition & 1 deletion .eslintrc.json
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@
"no-undef": "off",
"eol-last": 2,
"eqeqeq": "error",
"indent": ["error", 2],
"indent": ["off"],
"block-spacing": ["error", "always"],
"comma-spacing": "error",
"brace-style": "error",
Expand Down
4 changes: 4 additions & 0 deletions .gitbook.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
root: ./
structure:
readme: README.md
summary: docs/SUMMARY.md
4 changes: 2 additions & 2 deletions .github/workflows/test.yml
Original file line number Diff line number Diff line change
Expand Up @@ -2,8 +2,7 @@ name: Tests

on:
pull_request:
branches:
- develop
branches: ["**"]
push:
branches: ["**"]
workflow_dispatch:
Expand Down Expand Up @@ -36,3 +35,4 @@ jobs:
with:
coverage-file: coverage/lcov.info
minimum-coverage: 80

5 changes: 4 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -25,4 +25,7 @@ tags
.log/
yarn-error.log
venv/
contracts/hardhat-dependency-compiler
contracts/hardhat-dependency-compiler
types
.turbo
bytecodes
2 changes: 1 addition & 1 deletion .prettierignore
Original file line number Diff line number Diff line change
@@ -1 +1 @@
OMNGuild.sol
docs
2 changes: 1 addition & 1 deletion .prettierrc
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@
{
"files": "*.sol",
"options": {
"printWidth": 120,
"printWidth": 120
}
}
]
Expand Down
11 changes: 2 additions & 9 deletions .solcover.js
Original file line number Diff line number Diff line change
@@ -1,12 +1,5 @@
module.exports = {
skipFiles: [
"daostack/",
"schemes/ContributionReward.sol",
"schemes/SchemeRegistrar.sol",
"test/",
"utils/",
"votingMachines/",
"node_modules/@daostack",
],
skipFiles: ["test/", "utils/", "hardhat-dependency-compiler/"],
istanbulReporter: ["lcov"],
configureYulOptimizer: true,
};
44 changes: 28 additions & 16 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,11 +18,11 @@ KEY_INFURA_API_KEY="xxxx"
// Required to verify smart contracts
KEY_ETHERSCAN="xxx"
API_KEY_ETHERSCAN="xxx"
// Required for get reputation script
// Required to run getReputation script
REP_FROM_BLOCK=7850172
Expand All @@ -42,7 +42,7 @@ REP_TO_BLOCK=12212988

### Gas Report

It will run the tests and report the gas cost of each function executed in every smart contract in the tests.
Will run the tests and report the gas cost for each function executed in every smart contract during the tests.

`REPORT_GAS=true yarn test`

Expand All @@ -56,13 +56,21 @@ This script will get the DXdao Rep from mainnet or xdai DXdao rep token and REP

`yarn coverage`

## Deterministic Deployment

Example command for goerli:

```
ETHERSCAN_API_KEY=Y3TJ6KYE7RGNDNWVEC2K3A2PRC7HSAMVPS DEPLOY_SALT=0x5caa6a9b2e6023fe37efcabde5d64ed32e8523bac8d1 yarn hardhat deploy --tags PermissionRegistry,DXdaoTreasuryGuild,DXdaoDevOpsGuild,DXDGuild --network goerli
```

## Create2

This hardhat task runs on the selected network, it receives the name of the contract that wants to be deployed using create2 and the salt. In case a contract has a initialize function you can also send teh initialization parameters.

Example for ERC20Token:

`yarn hardhat create2 --network arbitrumTestnet --contract ERC20Token --salt 2 --initializer "DXGovTestToken,DXGTT,0xC4B60a931929d3ed0AC423F9Ea80e5962726dA73,100000000000000000000000"`
`yarn hardhat create2 --network arbitrumTestnet --contract ERC20Token --salt 2 --initializer "DXGovTestToken,DXGTT,0xC4B60a931929d3ed0AC423F9Ea80e5962726dA73,1000000000000000000000000"`

## Sourcify

Expand Down Expand Up @@ -98,9 +106,9 @@ Code taken from: https://github.com/gnosis/dx-daostack.

The smart contracts used in DXdao gov 1.x dapp. It consist of the DXDVotingMachine, PermissionRegsitry and WalletScheme contracts, this are used with the existent DXdao daostack contracts deployed on mainnet.

The Wallet Scheme creates and register the proposals in the Voting Machine, the voting machine receives the votes and stakes, the state of a proposal will be changing over time (depending of the votes and stakes over it). When a proposal is approved the Wallet Scheme will check that the calls to be executed are allowed in the Permission Registry, if the check passes the proposal is executed successfully.
The Wallet Scheme creates and registers the proposals in the Voting Machine, the voting machine receives the votes and stakes, the state of a proposal will be changing over time (depending of the votes and stakes on it). When a proposal is approved the Wallet Scheme will check that the calls to be executed are allowed in the Permission Registry, if the check passes the proposal is executed successfully.

There can be multiple Wallet Schemes being used at the same time and each of them will have their own configuration and permissions, allowing DXdao to distribute funds and configure the access to them.
M ultiple Wallet Schemes may be used at the same time and each will have its own configuration and permissions, allowing DXdao to distribute funds and configure access to them.

![DXdao Gov 1-x-schemes](assets/DXdao%20Gov%201-x.png)

Expand All @@ -116,15 +124,15 @@ The Quick Wallet scheme will have access to funds held by the scheme itself, wit

- **name**: The name of the scheme, this will be used to identify the scheme by name in DXvote dapp.

- **callToController**: If the scheme make calls to the controller or not. A Scheme that makes calls to a controller will make calls from the dxdao avatar (which gives access to the dxdao funds) and a scheme that do not call the controller will make call directly from itself, which means that it will have access only to the funds held in the scheme address.
- **callToController**: If the scheme make calls to the controller or not. A Scheme that makes calls to a controller will make calls from the dxdao avatar (which gives access to the dxdao funds) and a scheme that does not call the controller will make calls directly from itself, which means that it will have access only to the funds held in the scheme address.

- **maxSecondsForExecution**: This is the amount of time that a proposal has to be executed in the scheme, this is useful to "clean" proposals that weren't successful or weren't able to be executed for some reason. This means that if a proposal passes in 3 days in the voting machine and the `maxSecondsForExecution` are 6 days it will have 3 days to be executed, after that it will be marked in `ExecutionTimeout` state and wont be able to be executed again, reaching a state of termination.

- **maxRepPercentageToMint**: This is the maximum amount of rep in percentage allowed to be minted by proposal, the value can be between 0-100, if a proposal execution mints 5% of REP and the `maxRepPercentageToMint` equals 3, it will fail.
- **maxRepPercentageToMint**: This is the maximum amount of rep in percentage allowed to be minted by proposal, the value can be between 0-100. If a proposal execution attempts to mint 5% of REP and the `maxRepPercentageToMint` equals 3, it will fail.

- **Controller Permissions**: This are four values that determine what the scheme can do in the dxdao controller contract, the most powerful contract in the stack, the only two values that we use from it are `canRegisterSchemes` and `canGenericCall`. `canRegisterSchemes` allows the addition/removal of schemes and the `canGenericCall` allows the execution of calls in the avatar contract.
- **Controller Permissions**: There are four values that determine what the scheme can do in the dxdao controller contract, the core contract in the stack. The two values that we use from it are `canRegisterSchemes` and `canGenericCall`. `canRegisterSchemes` allows the addition/removal of schemes and the `canGenericCall` allows the execution of calls in the avatar contract.

- **Permission Registry Permissions**: This permissions are checked before a proposal execution to check that the total value transferred by asset and the functions to be called are allowed. If a scheme make calls to the controller the permissions are checked from the avatar address.
- **Permission Registry Permissions**: These permissions are checked before a proposal execution to check that the total value transferred by asset and the functions to be called are allowed. If a scheme makes calls to the controller the permissions are checked from the avatar address.

The permissions are set by asset, specifying the sender and receiver addresses, the signature of the function to be used and the value to be transferred.

Expand Down Expand Up @@ -158,7 +166,7 @@ The Quick Wallet scheme will have access to funds held by the scheme itself, wit

#### DXD Voting Machine

The DXD Voting Machine is a fork of the the Genesis Protocol (GEN token voting machine) with new very cool features:
The DXD Voting Machine is a fork of the the Genesis Protocol (GEN token voting machine) with additional functionality:

- Use of DXD as staking token.

Expand All @@ -176,15 +184,15 @@ The DXD Voting Machine is a fork of the the Genesis Protocol (GEN token voting m

### ERC20Guild

The smart contracts to add a very basic, efficient and flexible governance layer over an ERC20 token.
Smart contracts to add a very basic, efficient and flexible governance layer over an ERC20 token.

The guild **executes previously authorized functions** to smart contracts after a proposal action to execute that function reaches the **minimum amount of votes** using **locked tokens as voting power** after a **period of time**.

- The guild can execute only allowed functions, this means that if you want to call function X to smart contract P you will need to first submit a proposal to allow the execution of function X to smart contract P.

- A guild proposal can have none or multiple actions, each proposal action is a list of ethereum calls, that can execute functions and transfer value.

- The voter can set his vote on a decision only once, the action voted cant be changed, only the voting power can be increased.
- The voter can set his vote on a decision only once, the action voted can't be changed, only the voting power can be increased.

- The voting power in the guild is based on the ERC20 token balance **locked by the voter**, that means that the tokens need to be locked for a minimum period of time in order to be used as voting power.

Expand All @@ -196,9 +204,9 @@ The guild **executes previously authorized functions** to smart contracts after

- The voter can sign a vote that can be executed by other account on his behalf.

- When a proposal is created it enters the voting period. Once the voting period passes if the is no proposal action with enough votes to execute, it will be rejected. If it has enough votes to execute and executes successfully during a the execution period of time, it will be finished successfully. If during that execution period of time the proposal action cant be executed it will be set as failed and wont be able to be executed again once the execution time ends.
- When a proposal is created it enters the voting period. Once the voting period passes if there is no proposal action with enough votes to execute, it will be rejected. If it has enough votes to execute and executes successfully during a the execution period of time, it will be finished successfully. If during that execution period of time the proposal action can't be executed it will be set as failed and won't be able to be executed again once the execution time ends.

- The guild can be configured to automatically pay the voting costs back to the voter, for this the vote gas a max gas price to be use for vote refund needs to be set.
- The guild can be configured to automatically pay the voting costs back to the voter, for this the max gas price to be used for voting needs to be set.

- Each proposal has a title and a content hash that can be used to refer off-chain information.

Expand All @@ -218,12 +226,16 @@ An ERC20Guild with the functionality to migrate the ERC20 voting token used, the

#### SnapshotERC20Guild

An ERC20Guild that keeps track of the voting power by saving a snapshot of the voting power each time a lock/withdraw of tokens happens. The voting power to be used on a proposal would be the one that the guild had at the moment of the proposal creation.
An ERC20Guild that keeps track of the voting power by saving a snapshot of the voting power each time a mint/burn of tokens happens. The voting power to be used on a proposal would be the one that the guild had at the moment of the proposal creation.

#### SnapshotERC20REPGuild

An ERC20Guild designed to with with a ERC20 Reputation Token, a token that is not transferable only can be minted and burned by the guild itself. Very similar to the REP token used by dxdao, this allows the guild to be used as a "mini" dxdao, a stepping stone to later growth to a governance 2.0 stack.

### Contracts Documentation

[See auto-generated solidity documentation here](/docs/SUMMARY.md)

### Utils

The smart contracts used to facilitate and automate the deployment of the DXdao.
42 changes: 42 additions & 0 deletions contracts/dao/DAOAvatar.sol
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
// SPDX-License-Identifier: AGPL-3.0
pragma solidity ^0.8.17;

import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";

/**
* @title DAO Avatar
* @dev The avatar, representing the DAO, owned by the DAO, controls the reputation and funds of the DAO.
*/
contract DAOAvatar is OwnableUpgradeable {
/// @notice Emitted when the call was executed
event CallExecuted(address indexed to, bytes data, uint256 value, bool callSuccess, bytes callData);

receive() external payable {}

/**
* @dev Initialize the avatar contract.
* @param owner The address of the owner
*/
function initialize(address owner) public initializer {
__Ownable_init();
transferOwnership(owner);
}

/**
* @dev Perform a call to an arbitrary contract
* @param to The contract's address to call
* @param data ABI-encoded contract call to call `_to` address.
* @param value Value (ETH) to transfer with the transaction
* @return callSuccess Whether call was executed successfully or not
* @return callData Call data returned
*/
function executeCall(
address to,
bytes memory data,
uint256 value
) public onlyOwner returns (bool callSuccess, bytes memory callData) {
(callSuccess, callData) = to.call{value: value}(data);
emit CallExecuted(to, data, value, callSuccess, callData);
return (callSuccess, callData);
}
}
Loading

0 comments on commit 9dc284c

Please sign in to comment.