You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following is a guide to creating an on-chain Arbitrum DAO core governor proposal.
4
+
5
+
Prior to creating a proposal, it should be publically discussed on the Arbitrum Forum and a an off-chian temperature-check snapshot poll should be conducted; see [Arbitrum DAO docs](https://docs.arbitrum.foundation/how-tos/create-submit-dao-proposal#step-2-submit-your-on-chain-proposal-using-tally) for details.
6
+
7
+
Once a temperature check has passed, the following things can be done:
8
+
9
+
1.**Create Action Contract(s)**: Create the Governance Action Contract(s) for the proposal. See [here](../src/gov-action-contracts/README.md) for a guide to Governance Action Contracts.
10
+
11
+
1.**(Optional) Unit Tests**: Write unit tests for the Action Contracts if appropriate, i.e., if they introduce non-trivial new logic.
12
+
13
+
1.**Deploy And Verify Action Contracts**: Using `forge create`, deploy Action Contracts on their appropriate chain(s) (Ethereum, Arbitrum One, or Nova) and verify their bytecode on etherscan/arbiscan. (Note that no additional scripting should be used/required for Action Contract deployment.)
14
+
15
+
1.**Generate Propoposal Calldata**:
16
+
a. Create a new directory under ./scripts/proposals/ for your proposal data, e.g.
17
+
18
+
```
19
+
mkdir ./scipts/proposals/AIPMyProp
20
+
```
21
+
b. Generate proposal data using `yarn gen:proposalData` using the addresses of the deloyed action contracts, and providing a path to store the new JSON file.
Note that the indices for the chain ids correspond with those of the action contracts. E.g., in the example, 0xAddressA should be deployed on chain 1 (Ethereum) and 0xAddressB should be deployed on chain 42161 (Arbitrum One.)
32
+
33
+
Run `yarn gen:proposalData --help` to see all optional parameters.
34
+
35
+
Once the data JSON is properly created, it can be included in a public pull request to this repo.
36
+
37
+
Note that while some prior proposals include description text and/or deployment scripts, that is no longer necessary.
38
+
39
+
1. **Run Simulation**
40
+
41
+
Using the calldata generated in the previous step, test the proposal using [the Arbitrum DAO governance seatbelt](https://github.com/ArbitrumFoundation/governance-seatbelt). Include the configuration in a PR to the seatbelt repo ([example](https://github.com/ArbitrumFoundation/governance-seatbelt/pull/26)).
42
+
43
+
The seatbelt will generate a human readable report of all of the state changes in the proposal; only proceed if the report's result are what is expected.
44
+
45
+
1. **Submit Proposal In Tally UI** See [here](./submit_a_proposal.md).
Copy file name to clipboardExpand all lines: docs/gotchas.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -12,8 +12,8 @@ The core, treasury, and security-council-member-removal governors all have a min
12
12
-**Timelock vs Governor Execution**
13
13
An operation queued in the core-governor-timelock or the treasury-governor-timelock can be executed permissionlessly on either its associated governor (typical) or on the timelock itself (atypical). The execution will be the same in either case, but in the later case, the governor’s `ProposalExecuted` event will not be emitted.
14
14
15
-
-**Two L1 Proxy Admins**
16
-
There are two L1 proxy admins - one for the governance contracts, once for the governed core Nitro contracts. Note that both proxy admins have the same owner (the DAO), and thus this has no material effect on the DAO's affordances.
15
+
-**Multiple L1 Proxy Admins**
16
+
There are 3 L1 proxy admins - one for the governance contracts, one for the governed core Nitro contracts of Arb1, and one for the governed core Nitro contracts of Nova. Note that all proxy admins have the same owner (the DAO), and thus this has no material effect on the DAO's affordances.
17
17
18
18
-**Non-excluded L2 Timelock**
19
19
ARB in both the treasury timelock and the DAO treasury can be transferred via treasury gov DAO vote; however, only ARB in the DAO treasury is excluded from the quorum numerator calculation. Thus, the DAO’s ARB should ideally all be stored in the DAO Treasury.
Copy file name to clipboardExpand all lines: docs/security-council-mgmt.md
+19-13Lines changed: 19 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -21,9 +21,10 @@ The election process and update stages are performed via on-chain smart contract
21
21
22
22
Process for selecting and voting for the new cohort of Security council members.
23
23
24
-
1.**Nominee Selection (7 days).** Candidates must gain 0.2% of total votable tokens in order to make it to the next step.
25
-
2.**Compliance check by Foundation (14 days).** As dictated in the Constitution, the selected nominees must undergo a compliance check to ensure they comply with the legal requirements, service agreements, and additional rules dictated by the Constitution.
26
-
3.**Member election (21 days).** Votes are cast and the top 6 nominees are selected.
24
+
1.**Candidate registration (7 days)** Candidates must put themselves up for nomination in order to receive votes.
25
+
2.**Nominee selection (7 days).** Candidates must gain 0.2% of total votable tokens in order to make it to the next step.
26
+
3.**Compliance check by Foundation (14 days).** As dictated in the Constitution, the selected nominees must undergo a compliance check to ensure they comply with the legal requirements, service agreements, and additional rules dictated by the Constitution.
27
+
4.**Member election (21 days).** Votes are cast and the top 6 nominees are selected.
27
28
28
29
## Update Stages
29
30
@@ -37,12 +38,21 @@ Process to install the newly elected cohort of Security Council members into the
37
38
38
39
# Election Stages in detail
39
40
40
-
## 1. Nominee selection (7 days)
41
-
42
-
This stage consists of handling election timing, candidate registration, candidate endorsement:
41
+
## 1. Election creation and candidate registration (7 days)
43
42
44
43
-**Election creation.** Elections can be created by anyone, but only every 6 months. The election alternates between targeting the positions on the two cohorts. Once created, this first stage of the election process lasts for 7 days.
45
44
-**Candidate registration.** During these 7 days, any candidate can register, unless they are already a member of the other cohort. Members of the current cohort (the cohort up for election) are allowed to register for re-election.
45
+
46
+
### Implementation details
47
+
48
+
A new proposal is created each election cycle by calling `SecurityCouncilNomineeElectionGovernor.createElection`. Once a proposal is created it will be "Pending" for 7 days.
49
+
50
+
Voting is not allowed while the proposal is pending.
51
+
52
+
During the 7 day pending window, contenders register themselves by signing an EIP712 message of type `AddContenderMessage(uint256 proposalId)` and calling `SecurityCouncilNomineeElectionGovernor.addContender`.
53
+
54
+
## 2. Nominee selection (7 days)
55
+
46
56
-**Endorsing candidates.** Delegates can endorse a candidate during this 7 day window. A single delegate can split their vote across multiple candidates. No candidate can accrue more than 0.2% of all votable tokens.
47
57
-**Fallback in case of too few candidates.** In the event that fewer than 6 candidates receive a 0.2% endorsement, the Arbitrum Foundation will randomly select members from the outgoing cohort to make up to 6 candidates.
48
58
@@ -55,13 +65,9 @@ It inherits most of its functionality from the OpenZeppelin Governor contracts,
55
65
- Custom counting module to allow delegates to endorse multiple candidates.
56
66
- Overridden proposal and execution to make the governor single purpose.
57
67
58
-
This governor contract has the following general interface relevant to the first stage:
59
-
60
-
- A new proposal is created each election cycle by calling `createElection`
61
-
- Contenders can make themselves eligible to receive votes by calling `addContender`.
62
-
- Delegates can call `castVoteWithReasonAndParams` or `castVoteWithReasonAndParamsBySig` supplying custom arguments in the params to indicate which candidate they wish to endorse with what weight.
68
+
Delegates can call `castVoteWithReasonAndParams` supplying custom arguments in the params to indicate which candidate they wish to endorse with what weight.
63
69
64
-
## 2. Compliance check by the Foundation (14 days)
70
+
## 3. Compliance check by the Foundation (14 days)
65
71
66
72
The Foundation will be given 14 days to vet the prospective nominees. If they find that a candidate does not meet the compliance check, they can exclude the candidate from progressing to the next stage. The compliance rules are not detailed here, and will instead be published by the Foundation, but note that grounds for exclusion will include greater than 3 members of a given organisation being represented in the nominee set (as described in section 4 of the Constitution).
67
73
@@ -77,7 +83,7 @@ The Governor smart contract enforces that at least a 2 week time period be provi
77
83
78
84
Once the compliance check has completed, anyone can call the `execute` function on the `SecurityCouncilNomineeElectionGovernor` to proceed to the member election stage.
79
85
80
-
## 3. Member election (21 days)
86
+
## 4. Member election (21 days)
81
87
82
88
The voting process can begin once a set of compliant candidates have been successfully nominated.
0 commit comments