sync docs

docs/creating-a-proposal.md

@@ -16,7 +16,7 @@ Once a temperature check has passed, the following things can be done:
     a. Create a new directory under ./scripts/proposals/ for your proposal data, e.g.
 
     ```
-    mkdir ./scipts/proposals/AIPMyProp
+    mkdir ./scripts/proposals/AIPMyProp
     ```
     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.
 
@@ -26,7 +26,7 @@ Once a temperature check has passed, the following things can be done:
         --govChainProviderRPC https://arb1.arbitrum.io/rpc \
         --actionChainIds 1 42161 \
         --actionAddresses 0xAddressA 0xAddressB   \
-        --writeToJsonPath ./scipts/proposals/AIPMyProp/my-prop-data.json  
+        --writeToJsonPath ./scripts/proposals/AIPMyProp/my-prop-data.json  
     ```
     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.)
 

docs/gotchas.md

@@ -4,7 +4,7 @@ _The following is a list of quirks and/or potentially unexpected behaviors in th
 
 
 - **Abstain Vote** 
-Voting “abstain” on a core-governor or treasury governor proposal does not count as either a “for” or “against” vote, but does count towards reaching quorum (5% or 3% of votable tokens, respectively). Voting abstain on a security council member removal proposal is disallowed.
+Voting “abstain” on a core-governor or treasury governor proposal does not count as either a “for” or “against” vote, but does count towards reaching quorum. Voting abstain on a security council member removal proposal is disallowed.
 
 - **Late Quorum Extension**
 The core, treasury, and security-council-member-removal governors all have a minimum 14-day voting period, and use open zeppelin's "late quorum" module to add a late-quorum extension of 2 days. This ensures that there are always at least 2 days of voting after a proposal's quorum is reached; i.e., the maximum total voting period would be 16 days, when/if quorum is reached at the very end of the initial 14-day period. 

docs/overview.md

@@ -5,7 +5,7 @@
 Arbitrum governance has two main bodies:
 
 - **The DAO** - represented by holders of the $ARB token, and votes to pass proposals.
-- **The Security Council** - is made up of a 9 of 12 multisig that can take quick action in case of an emergency and a 7 of 12 multisig that can take slow action for routine upgrades that bypass the DAO vote.
+- **The Security Council** - is made up of a 9 of 12 multisig that can take quick action in case of an emergency and a 9 of 12 multisig that can take slow action for routine upgrades that bypass the DAO vote.
 
 You can read more about these bodies and their powers in the [Arbitrum DAO Constitution](https://docs.arbitrum.foundation/dao-constitution).
 
@@ -35,13 +35,13 @@ Governance has the ability to upgrade both Arbitrum One and Arbitrum Nova, which
 
 The exception to this is proposals that are deemed _non-constitutional_. This type of proposal shouldn't affect the behavior of the chain, or should do so in limited well understood ways. At inception the only type of non-constitutional proposal is the spending of treasury funds.
 
-To differentiate between these two types of proposal, Arbitrum governance uses two Governor contracts. A _constitutional_ one which requires at least 5% of all votable tokens to vote “in favor” and more votable tokens to vote “in favor” than to vote “against” in order to pass, and a _non-constitutional_ one which requires at least 3% of all votable tokens to vote “in favor” and more votable tokens to vote “in favor” than to vote “against” in order to pass. The ability to upgrade Arbitrum contracts is held by the 5% governor, so no proposals made from the 3% governor can cause a change to contract code, or to a set of chain “owner” parameters.
+To differentiate between these two types of proposal, Arbitrum governance uses two Governor contracts. A _constitutional_ one (the Core governor) and a _non-constitutional_ one (the Treasury governor). Both require more votable tokens to vote “in favor” than to vote “against”, and both require a quorum to be reached; the constitutional governor uses a higher quorum than the non-constitutional one (see [Quorum](#quorum)). The ability to upgrade Arbitrum contracts is held by the Core (constitutional) governor, so no proposals made from the Treasury (non-constitutional) governor can cause a change to contract code, or to a set of chain “owner” parameters.
 
 ## Proposal delays
 
 All governance activities occur on Arbitrum One. Proposals are made there, as well as delegation and voting. A proposal made to the constitutional governor experiences enough delay to ensure that users can safely exit the chain before the proposal is executed, should they deem it malicious.
 
-1. **Arbitrum One timelock** - 3 days delay. After passing, a proposal is delivered to a timelock on Arbitrum One. The purpose of this delay is to allow users to initiate withdrawals from the chain should they wish to.
+1. **Arbitrum One timelock** - 8 days delay. After passing, a proposal is delivered to a timelock on Arbitrum One. The purpose of this delay is to allow users to initiate withdrawals from the chain should they wish to.
 2. **L2->L1 message delay** - ~1 week. All proposals must be withdrawn to L1 before being executed (even if they will eventually execute back on an L2). This ensures that any exits made by users in the previous delay can be processed before the upgrade will, since both go through this delay.
 3. **Ethereum mainnet delay** - 3 days. Withdrawals are delayed by any open challenges in the Arbitrum One rollup. This can cause many withdrawals to become eligible for execution on L1 at the same time. This would mean that although a user initiated their withdrawal before the L2->L1 upgrade message, they could both become eligible for execution on the L1 at roughly the same time, causing users to race on L1 against the upgrade. To prevent this, the upgrade proposal goes through a further delay after reaching the L1, ensuring that any withdrawals initiated before the upgrade proposal will be eligible for execution first.
 
@@ -69,24 +69,33 @@ Token holders have the ability to exclude their votes from the governance quorum
 
 Lets dive a bit deeper into each of the individual contracts, and describe more specifically the role each of the plays in the system.
 
-#### Arbitrum One 3% Governor
+#### Arbitrum One Treasury Governor
 
-The _non-constitutional_ governor, proposals made require at least 3% of all votable tokens to vote “in favor” and more votable tokens to vote "in favor" than to vote "against" in order to pass. Currently only has the power to spend funds in the treasury.
+The _non-constitutional_ governor. Proposals require more votable tokens to vote “in favor” than to vote "against", and must reach quorum (see [Quorum](#quorum)). Currently only has the power to spend funds in the treasury.
 
-#### Arbitrum One 5% Governor
+#### Arbitrum One Core Governor
 
-The _constitutional_ governor, proposals made require at least 5% of all votable tokens to vote "in favor" and more votable tokens to vote “in favor" than to vote "against" in order to pass.
+The _constitutional_ governor. Proposals require more votable tokens to vote "in favor" than to vote "against", and must reach quorum (see [Quorum](#quorum)). The Core governor uses a higher quorum than the Treasury governor.
 <br/>
 
 _Comparison Table_
 | Contract | Proposal Type | Limits |
 | -------- | ------------- | ------ |
-| Arb One 3% Governor | non-constitutional | only treasury-related proposals |
-| Arb One 5% Governor | constitutional | - |
+| Arb One Treasury Governor | non-constitutional | only treasury-related proposals |
+| Arb One Core Governor | constitutional | - |
+
+#### Quorum
+
+Quorum is based on the total delegated voting power of $ARB (excluding tokens delegated to the exclude address). For each governor, quorum is a fraction of the delegated voting power, clamped between a fixed minimum and maximum:
+
+| Governor | Fraction of delegated votes | Min quorum | Max quorum |
+| -------- | --------------------------- | ---------- | ---------- |
+| Core (constitutional) | 50% | 150,000,000 ARB | 450,000,000 ARB |
+| Treasury (non-constitutional) | 40% | 100,000,000 ARB | 300,000,000 ARB |
 
 #### Arbitrum One L2 Timelock
 
-Proposals can be scheduled here by the 5% governor, or by a 7-of-12 agreement in the Security Council. This timelock enforces a 3-day delay before the proposal can then be executed by anybody.
+Proposals can be scheduled here by the Core governor, or by a 9-of-12 agreement in the Security Council. This timelock enforces an 8-day delay before the proposal can then be executed by anybody.
 
 #### L1 Timelock
 
@@ -97,7 +106,7 @@ This timelock receives proposals that were executed in the Arb One L2 Timelock.
 _Comparison Table_
 | Contract | Receive proposals scheduled by | Timelock |
 | -------- | ------------------------------ | ----------------- |
-| Arb One L2 Timelock<br/>(Arb1TL) | the 5% governor / 7-12 in Security Council | 3 days |
+| Arb One L2 Timelock<br/>(Arb1TL) | the Core governor / 9-12 in Security Council | 8 days |
 | L1 Timelock | proposals executed in the Arb1TL | 3 days |
 
 #### L1 Upgrade Executor

docs/proposalMonitor.md

@@ -14,7 +14,7 @@ yarn build
 ETH_RPC=<your ethereum rpc here> yarn propmon
 ```
 
-Then navigate to `localhost:8080/propMonUi/propMonUi.html` in a browser. You will need to wait around 30 seconds whilst the propmon discovers all proposals and their stages. The propmon creates a proposalStage.json file that contains a json representation of the data you see on the web page.
+Then navigate to `localhost:8080/propMonUi/propMonUi.html` in a browser. You will need to wait around 30 seconds whilst the propmon discovers all proposals and their stages. The propmon creates a proposalState.json file that contains a json representation of the data you see on the web page.
 
 ## Running with docker
 ```

docs/proposal_lifecycle_example.md

@@ -166,4 +166,4 @@ The security council with a 9 of 12 multisig threshold can directly call the L1
 
 ### Security Council: Non-time-sensitive Critical Upgrade
 
-The security council with a 7 of 12 multisig threshold can call `ArbitrumTimelock.schedule` on the Arbitrum One timelock, without requiring a governance vote.
+The security council with a 9 of 12 multisig threshold can call `ArbitrumTimelock.schedule` on the Arbitrum One timelock, without requiring a governance vote.

docs/security-council-mgmt.md

@@ -31,7 +31,7 @@ Process for selecting and voting for the new cohort of Security council members.
 Process to install the newly elected cohort of Security Council members into the Arbitrum smart contracts.
 
 1. **Security Council manager update (0 days).** The manager is the source of truth for specifying who are the current council members. It processes the election result and takes note on who will be the new security council members.
-2. **L2 timelock + withdrawal + L1 timelock (3 + 7 + 3 days).** All actions that directly affect the core Arbitrum contracts must go through a series of timelocks to protect the right for all users to exit. This is a built-in safety mechanism for users who are unhappy with the approved changes.
+2. **L2 timelock + withdrawal + L1 timelock (8 + 7 + 3 days).** All actions that directly affect the core Arbitrum contracts must go through a series of timelocks to protect the right for all users to exit. This is a built-in safety mechanism for users who are unhappy with the approved changes.
 3. **Individual council update (0 days).** Once the updates have passed through the relevant timelocks, the Security Council manager can install the security council members. This requires updating 4 Gnosis Safe smart contracts that are controlled by the Security Council members.
 
 ![](./security-council-election-flow.png)
@@ -138,7 +138,7 @@ Calling the `UpgradeExecutor`s on each of the chains requires navigating withdra
 
 Constitutional DAO proposals all pass through:
 
-- L2 timelock (3 days),
+- L2 timelock (8 days),
 - L2 → L1 withdrawal (~7 days),
 - L1 timelock (3 days).
 
@@ -155,7 +155,7 @@ The `SecurityCouncilManager` is given the `PROPOSER` role on the L2 timelock ena
 The new Security Council members need to be installed into 4 Gnosis safes:
 
 - Arbitrum One 9 of 12 Emergency Security Council
-- Arbitrum One 7 of 12 Non-Emergency Security Council
+- Arbitrum One 9 of 12 Non-Emergency Security Council
 - Ethereum 9 of 12 Emergency Security Council
 - Nova 9 of 12 Emergency Security Council