├── .github ├── main.workflow └── workflows │ └── update-glossary.yaml ├── .gitignore ├── CODEOWNERS ├── LICENSE ├── README.md ├── assets ├── Arbitrum Expansion Program Jan182024.pdf ├── ArbitrumFoundationBiannualReport2024H1.pdf ├── ArbitrumFoundationCaptiveInsuranceProduct.pdf ├── ArbitrumFoundationTransparencyReport2023.pdf ├── ArbitrumFoundationTransparencyReport2024.pdf ├── The Arbitrum Foundation - Boilerplate Grant Agreement.pdf ├── The Arbitrum Foundation Bylaws 20 July 2023.pdf └── The Arbitrum Foundation M&A - 20 July 2023.pdf ├── babel.config.js ├── docs ├── airdrop-eligibility-distribution.md ├── arbitrum-bold-economics │ ├── bold-reimbursing-challenge-bonds.md │ ├── bold-reimbursing-gas-costs.md │ └── bold-reimbursing-service-fees.md ├── concepts │ ├── arb-token.md │ ├── arbitrum-dao.md │ ├── dao-vote.md │ ├── delegate-delegation.md │ ├── lifecycle-anatomy-aip-proposal.md │ ├── public-preview-content.md │ ├── security-council.md │ └── sybil-account.md ├── dao-comprehension-check.md ├── dao-constitution.md ├── dao-faqs.md ├── dao-glossary.md ├── deployment-addresses.md ├── fee-distribution.md ├── foundation-documents.mdx ├── foundational-documents │ └── transparency-report-initial-foundation-setup.md ├── gentle-introduction-dao.md ├── how-tos │ ├── apply-become-delegate.md │ ├── build-strong-delegate-platform.md │ ├── create-submit-dao-proposal.md │ ├── resubmit-dao-proposal.md │ ├── select-delegate-voting-power.md │ └── vote-dao-proposals.md ├── network-upgrades.md ├── new-arb-chains.md ├── partials │ ├── _anatomy-aip-partial.md │ ├── _constitution-content-partial.md │ ├── _draft-expectations-partial.md │ ├── _faq-partial.md │ └── _glossary-partial.md ├── security-council-members.md ├── state-of-progressive-decentralization.md ├── token-circulating-supply.md ├── what-foundation.md └── why-governance.md ├── docusaurus.config.js ├── global.d.ts ├── notion-docs ├── .eslintrc.js ├── .gitignore ├── .prettierrc.js ├── package.json ├── scripts │ └── update.ts ├── tsconfig.json └── yarn.lock ├── package.json ├── postmortems ├── 15_Dec_2023.md └── assets │ ├── 15_Dec_2023_Figure_1.png │ └── 15_Dec_2023_Figure_2.png ├── prettier.config.js ├── scripts ├── updateConstitutionHash.js └── verifyQuicklooks.js ├── sidebars.js ├── src ├── components │ ├── AddressExplorerLink │ │ └── index.tsx │ ├── ConstitutionHash │ │ ├── constitutionHash.json │ │ └── index.tsx │ ├── Hasher │ │ └── index.tsx │ ├── HeaderBadges │ │ └── index.tsx │ ├── HomepageFeatures │ │ ├── index.tsx │ │ └── styles.module.css │ ├── HorizontalRuleWithText │ │ ├── index.tsx │ │ └── styles.module.css │ ├── PendingConstitutionNotice │ │ └── index.tsx │ ├── Quicklooks │ │ └── index.tsx │ └── TrackedLink │ │ └── index.tsx ├── css │ ├── custom.css │ └── custom.less ├── pages │ └── index.tsx └── theme │ ├── DocItem │ └── Content │ │ └── index.js │ ├── Footer │ └── index.tsx │ └── SearchBar │ ├── DocSearch.js │ ├── algolia.css │ ├── index.js │ ├── lunar-search.js │ ├── styles.css │ ├── templates.js │ └── utils.js ├── static ├── .nojekyll ├── aep │ └── ArbitrumExpansionProgramTerms.pdf ├── glossary.json └── img │ ├── favicon.ico │ └── logo.svg ├── tsconfig.json ├── vercel.json └── yarn.lock /.github/main.workflow: -------------------------------------------------------------------------------- 1 | name: Autocloser 2 | on: 3 | issues: 4 | types: [opened, edited, reopened] 5 | jobs: 6 | autoclose: 7 | runs-on: ubuntu-latest 8 | steps: 9 | - name: Autoclose issues 10 | uses: arkon/issue-closer-action@v3.4 11 | with: 12 | repo-token: ${{ secrets.GITHUB_TOKEN }} 13 | rules: | 14 | [ 15 | { 16 | "type": "body", 17 | "regex": ".*Psst, this issue will be closed with a templated response if it isn't a documentation update request.*", 18 | "message": "@${issue.user.login} Hi there! It looks like you submitted an update request template without filling in the details. I'm going to close this for now, but feel free to reopen if you have a specific update request.💙🧡" 19 | } 20 | ] -------------------------------------------------------------------------------- /.github/workflows/update-glossary.yaml: -------------------------------------------------------------------------------- 1 | # This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node 2 | # For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs 3 | 4 | name: Node.js CI 5 | 6 | on: [workflow_dispatch] 7 | 8 | jobs: 9 | update-glossary: 10 | runs-on: ubuntu-latest 11 | defaults: 12 | run: 13 | shell: bash 14 | working-directory: notion-docs 15 | steps: 16 | - uses: actions/checkout@v3 17 | - name: Use Node.js 18 | uses: actions/setup-node@v3 19 | with: 20 | node-version: 16.x 21 | cache: 'yarn' 22 | - run: npm i -g yarn 23 | - run: yarn 24 | - name: Create .env file 25 | run: echo $NOTION_DOTENV > .env 26 | env: 27 | NOTION_DOTENV: ${{ secrets.NOTION_DOTENV }} 28 | - run: yarn update:all 29 | - name: Create Pull Request 30 | uses: peter-evans/create-pull-request@v4 31 | with: 32 | title: Notion updates 33 | branch: notion-update 34 | delete-branch: true 35 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Dependencies 2 | /node_modules 3 | 4 | # Production 5 | /build 6 | 7 | # Generated files 8 | .docusaurus 9 | .cache-loader 10 | 11 | # Misc 12 | .DS_Store 13 | .env.local 14 | .env.development.local 15 | .env.test.local 16 | .env.production.local 17 | 18 | npm-debug.log* 19 | yarn-debug.log* 20 | yarn-error.log* 21 | .vscode/settings.json 22 | -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | # This file provides an overview of code owners in the `examples` repository. 2 | 3 | # Each line is a file pattern followed by one or more owners. 4 | # The last matching pattern has the most precedence. 5 | # For more details, read the following article on GitHub: https://help.github.com/articles/about-codeowners/. 6 | 7 | # These are the default owners for the whole content of the `examples` repository. The default owners are automatically added as reviewers when you open a pull request, unless different owners are specified in the file. 8 | * @stonecoldpat @aboutlo 9 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Website 2 | 3 | This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator. 4 | 5 | ### Installation 6 | 7 | ``` 8 | $ yarn 9 | ``` 10 | 11 | ### Local Development 12 | 13 | ``` 14 | $ yarn start 15 | ``` 16 | 17 | This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server. 18 | 19 | ### Build 20 | 21 | ``` 22 | $ yarn build 23 | ``` 24 | 25 | This command generates static content into the `build` directory and can be served using any static contents hosting service. 26 | 27 | ### Deployment 28 | 29 | Using SSH: 30 | 31 | ``` 32 | $ USE_SSH=true yarn deploy 33 | ``` 34 | 35 | Not using SSH: 36 | 37 | ``` 38 | $ GIT_USER= yarn deploy 39 | ``` 40 | 41 | If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch. 42 | -------------------------------------------------------------------------------- /assets/Arbitrum Expansion Program Jan182024.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ArbitrumFoundation/docs/a2d1d0d715769a0425982b8dd1ba0f0a5cb1b1fa/assets/Arbitrum Expansion Program Jan182024.pdf -------------------------------------------------------------------------------- /assets/ArbitrumFoundationBiannualReport2024H1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ArbitrumFoundation/docs/a2d1d0d715769a0425982b8dd1ba0f0a5cb1b1fa/assets/ArbitrumFoundationBiannualReport2024H1.pdf -------------------------------------------------------------------------------- /assets/ArbitrumFoundationCaptiveInsuranceProduct.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ArbitrumFoundation/docs/a2d1d0d715769a0425982b8dd1ba0f0a5cb1b1fa/assets/ArbitrumFoundationCaptiveInsuranceProduct.pdf -------------------------------------------------------------------------------- /assets/ArbitrumFoundationTransparencyReport2023.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ArbitrumFoundation/docs/a2d1d0d715769a0425982b8dd1ba0f0a5cb1b1fa/assets/ArbitrumFoundationTransparencyReport2023.pdf -------------------------------------------------------------------------------- /assets/ArbitrumFoundationTransparencyReport2024.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ArbitrumFoundation/docs/a2d1d0d715769a0425982b8dd1ba0f0a5cb1b1fa/assets/ArbitrumFoundationTransparencyReport2024.pdf -------------------------------------------------------------------------------- /assets/The Arbitrum Foundation - Boilerplate Grant Agreement.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ArbitrumFoundation/docs/a2d1d0d715769a0425982b8dd1ba0f0a5cb1b1fa/assets/The Arbitrum Foundation - Boilerplate Grant Agreement.pdf -------------------------------------------------------------------------------- /assets/The Arbitrum Foundation Bylaws 20 July 2023.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ArbitrumFoundation/docs/a2d1d0d715769a0425982b8dd1ba0f0a5cb1b1fa/assets/The Arbitrum Foundation Bylaws 20 July 2023.pdf -------------------------------------------------------------------------------- /assets/The Arbitrum Foundation M&A - 20 July 2023.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ArbitrumFoundation/docs/a2d1d0d715769a0425982b8dd1ba0f0a5cb1b1fa/assets/The Arbitrum Foundation M&A - 20 July 2023.pdf -------------------------------------------------------------------------------- /babel.config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | presets: [require.resolve('@docusaurus/core/lib/babel/preset')], 3 | }; 4 | -------------------------------------------------------------------------------- /docs/arbitrum-bold-economics/bold-reimbursing-gas-costs.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: bold-reimbursing-gas-costs 3 | title: "Reimbursing honest party gas costs in Arbtrum BoLD" 4 | sidebar_label: Gas cost reimbursements 5 | description: A specification for how honest parties are reimbursed for gas costs by the Arbitrum Foundation for their active, honest participation in Arbitrum BoLD 6 | dao_author: dlee 7 | dao_sme: mMcGilvrayAlvarez 8 | --- 9 | 10 | :::note 11 | The details on this page pertain only to Arbitrum One, as it is the only Arbitrum DAO-owned chain with permissionless validation enabled using Arbitrum BoLD. 12 | ::: 13 | 14 | This document will cover how we reimburse costs for gas to honest parties. The main document describing how we reimburse challenge bonds is [here](./bold-reimbursing-challenge-bonds.md). The document describing how we pay “service fees” to proposers is [here](./bold-reimbursing-service-fees.md). 15 | 16 | We reimburse gas costs offchain for a few reasons: 17 | 18 | - The amounts of money involved are going to be smaller than assertion bonds, so there is less risk in using an out-of-band procedure 19 | - The logic required to implement gas reimbursement onchain would require a lot of extra bookkeeping, as it would require the parent chain to keep track of data about the chain history, including previous transactions interacting with the challenge protocol, the senders of those transactions, and the gas prices they paid. 20 | - This extra bookkeeping would be expensive and might even outweigh the value of the reimbursement. Depending on where exactly these costs are born, it could either make the entire protocol noticeably more expensive or create a situation where it never makes sense to get reimbursed for gas because you’ll spend almost as much (or more) money to pay for the reimbursement transaction as that transaction would pay out. 21 | 22 | ### The basic idea 23 | 24 | Consider a slightly abstracted version of the honest strategy. The honest strategy can be seen as computing, given (the honest party’s view of) the current protocol state, zero or more (distinct) actions are needed to ensure that the honest party wins the challenge. That is, we can view the honest strategy as a function: 25 | 26 | $H : ProtoState \rightarrow Set(ProtoAction)$ 27 | 28 | From a protocol state to a set of actions. 29 | 30 | For more details on the strategy that honest parties are expected to adhere to in BoLD (the "honest strategy"), see sections 4.5 and 5.5 in the [BoLD whitepaper](https://arxiv.org/abs/2404.10491). 31 | 32 | ### The procedure 33 | 34 | Concretely, the reimburser can run the following algorithm. Remember that we are running offchain, and thus are allowed to do heavier-weight computation than possible onchain. In particular, we can invoke $H$ (the abstract honest strategy) to see what it would do. 35 | 36 | We can also check to see if the protocol, including all sub-challenges, is over (i.e., we no longer need to keep looking at protocol actions to see if any more needs reimbursing) at any particular state. Let’s call the function that does this check $C : ProtoState \rightarrow bool$; it returns $true$ if the protocol is over. 37 | 38 | When we check for set membership in sets of protocol actions, we need to see if two actions $A_1$ and $A_2$ are equal to protocol actions. By this, we mean that: 39 | 40 | 41 | - $A_1$ and $A_2$ are both the same type of action ($CreateRoot$, $Bisect$, $Refine$, $OneStepProve$, or $UpdateTimers$) 42 | - Furthermore, $A_1$ and $A_2$ have the same arguments 43 | 44 | :::note 45 | This notion of equality ignores metadata on the transaction, such as the sender, nonce, timestamp, etc. 46 | ::: 47 | 48 | - Let $state : ProtoState := Init$ be initialized to the starting protocol state. 49 | - Let $acts : Stream(ProtoAction)$ be a stream that returns the actions that take place in this run of the protocol, in order; each call to $acts.get()$ will return one action. 50 | - Let $b : bool := C(state)$ 51 | - While $b != true$: 52 | - Let $next : ProtoAction := acts.get()$ 53 | - Let $honest : Set(ProtoAction) := H(state)$ 54 | - If $next \in honest$: 55 | - $reimburse(next.sender, next.gas\_spent)$ 56 | - $state := executeProtoActionOnState(next, state)$ 57 | - $b := C(state)$ 58 | 59 | ### Why this is correct 60 | 61 | While the procedure makes intuitive sense, seeing that this works is not entirely trivial. For instance, the concrete honest strategy will submit its moves in some particular order. The moves may get censored, reordered, and/or delayed before being executed on the parent chain. During this time (between the honest party sending the actions and the actions executing), other actions may have occurred, causing the protocol state to change. 62 | 63 | However, the worst that can happen here is that the honest party’s transaction arrives after the same transaction occurs. In this case, we don’t reimburse the honest party whose transaction arrived later, but this is intended behavior (see [reimbursing extra-gas costs](#reimbursing-extra-gas-costs) below). 64 | 65 | - Put differently, an honest party’s transaction can fail to be reimbursable if another party’s identical transaction arrives first. (Timer updates, discussed below, slightly complicate the matter, but not by too much.) 66 | - Another way to put this is that the honest strategy never attempts to do work that isn’t strictly necessary to confirm the honest root edge. So given that the honest root does get confirmed, *every action that any honest party could have tried to submit, no matter what state they saw at the time, will either be reimbursable or have been front-run by an identical action*. 67 | - Reorgs on the parent chain don’t affect this argument either since, if an honest party submits a transaction based on a state that gets reorg’d out, that transaction will also get reorg’d out. 68 | 69 | As mentioned above, there is a subtlety around timer updates. Namely, the honest party needs to be careful how they set their “timer target” parameter when updating timers. Recall how this works: when submitting an “update timers” transaction, the sender chooses a “target” value. The timer will be updated unless the currently-stored bottom-up timer is equal to or larger than the target. 70 | 71 | For any honest edge $E$ needing to have its timer updated, the correct target can be calculated as follows: 72 | 73 | - Let $A$ be the honest root of the challenge (or sub-challenge) currently being fought. ($E$ is a descendant of $A$). 74 | - $A$ is confirmable if $T_{bottomup}(E) + T_{topdown}(E) \geq T_{confirm}$, where 75 | - $T_{bottomup}(E)$ is $E$’s bottom-up timer (the value whose approximation is getting updated by the update timer action) 76 | - $T_{topdown}(E)$ is the sum of local timers starting from $A$ down to $E$ 77 | - $T_{confirm}$ is the confirmation threshold 78 | - The target value will be the minimum bottom-up timer needed to confirm $E$; that is, $T_{confirm} - T_{topdown}(E)$ 79 | 80 | :::note 81 | This value doesn’t depend on the current timestamp, so delays and censorship before the execution of the transaction can’t render this target invalid. 82 | ::: 83 | 84 | If the honest party chooses the correct value (the minimum possible value that leads to the node being confirmable), then only the following situations are possible: 85 | 86 | - Frontrun an identical transaction 87 | - This means the honest party’s transaction won’t result in a state change and will be relatively cheap. The honest party won’t get reimbursed, but it won’t lose much (relative to how much a state change would cost) 88 | - Frontrun a transaction with a larger target 89 | - This larger transaction can only be honest if we are in a sub-challenge, and the sub-challenge root and challenge root are confirmable but not confirmed simultaneously. This example is an edge case, but it is also not a problem. The worst result here is the same as the previous case (the honest party’s transaction is a no-op and doesn’t get reimbursed) 90 | 91 | ## On gas prices 92 | 93 | Parties in the protocol may set excessive gas prices when they send transactions; if they do this and get reimbursed for the full cost of their transactions, they can drain funds from the protocol. Therefore, the intention is that the Foundation (or whoever administers the out-of-band reimbursement process) should cap the level of gas price for which they reimburse, depending on what gas prices were at the time when bonders submitted the honest transactions. This cap must be implemented carefully so that honest parties don’t lose money if gas prices are legitimately high. 94 | 95 | ## Reimbursing extra-gas costs 96 | 97 | 98 | One might wonder whether it is worth attempting to reimburse gas for transactions that could have resulted from multiple honest parties racing to make some particular protocol move. We call such gas fees *extra gas*. In such a case, only the party whose transaction was first run (on the parent chain) will get reimbursed under the approach outlined. Though this seems like an undesirable outcome, we mitigate the situation because only the first transaction will cause any state change in cases with duplicate transactions. Thus, we expect the L1 gas fees for any such “extra” transactions beyond the first to be relatively low. 99 | 100 | Reimbursing extra gas costs is vulnerable to abuse by dishonest parties who repeatedly make redundant copies of honest moves to try to drain funds from the protocol. Trying to address these avenues for abuse would likely result in extra complexity that we don’t consider worthwhile, given how small we expect these additional costs to be (for honest parties following the honest strategy correctly) anyway. 101 | 102 | ## Other remarks 103 | 104 | As outlined in the now-passed [AIP proposal to request funds to bootstrap the first BoLD validator](https://forum.arbitrum.foundation/t/aip-funds-to-bootstrap-the-first-bold-validator/24506#p-51247-payment-facilitation-final-costs-restrictions-13), all requested funds for the gas fee reimbursement budget get sent to a multi-sig controlled by the Arbitrum Foundation. After three years, any unspent funds from the gas fee reimbursement budget will return to the Arbitrum DAO. An additional proposal will be forthcoming to help cover Arbitrum's future operational costs. The Arbitrum DAO reserves the right to revoke the Arbitrum Foundation's proposer at any time and return the bonds to the treasury. This policy will be implemented and enforced via the BoLD smart contracts: 105 | * **Withdrawal address**: The funds will get deposited into BoLD, and the withdrawal address will get set to the 'UpgradeExecutor' contract on the parent chain. 106 | * **Triggering withdrawal**: The Arbitrum DAO (via governance) or the Arbitrum Foundation will have the authority to trigger a withdrawal, and the funds can only be sent to the pre-established withdrawal address (i.e., the Arbitrum DAO's treasury). 107 | 108 | In short, the Arbitrum DAO will have the authority to return the funds to the Arbitrum DAO treasury. This model can be used for future proposals if other entities want to run a proposer on behalf of the Arbitrum DAO. 109 | -------------------------------------------------------------------------------- /docs/arbitrum-bold-economics/bold-reimbursing-service-fees.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: bold-reimbursing-service-fees 3 | title: "Reimbursing honest party service fees in Arbitrum BoLD" 4 | sidebar_label: Service fee payments 5 | description: A specification for how honest parties are paid services fees by the Arbitrum Foundation for their active, honest participation in Arbitrum BoLD 6 | dao_author: dlee 7 | dao_sme: mMcGilvrayAlvarez 8 | --- 9 | 10 | :::note 11 | The details on this page pertain only to Arbitrum One, as it is the only Arbitrum DAO-owned chain with permissionless validation enabled using Arbitrum BoLD. 12 | ::: 13 | 14 | ## Introduction 15 | 16 | ## Introduction 17 | 18 | In Arbitrum BoLD, proposing assertions can be permissionless; however, when proposing an assertion, the proposer must place a *bond* associated with the assertion. Further reading on the economics of BoLD and why this is needed can be found in the [Economics of Disputes in Arbitrum BoLD](https://docs.arbitrum.io/how-arbitrum-works/bold/bold-economics-of-disputes). This bond is 3600 `ETH`. While `ETH` is locked up in this way, they are not earning any yield; thus, locking up this `ETH` represents a cost for proposers: the opportunity cost of not earning yield on their `ETH`. 19 | 20 | Service Fees attempt to make honest proposers whole for the opportunity cost they bear while bonded on assertions in recognition that, in doing so, they provide an essential service to Arbitrum and that providing this service is not free for the honest proposers. The idea is simple: we want to reimburse honest proposers for what they could have earned on a safe investment elsewhere. The fee should be in the same currency as the bond (i.e., `ETH`). It should correlate to the annualized income the parent chain (Ethereum) mainnet staked validators receive over the same period. The yield of being a staker on the parent chain can, of course, this may vary over time, but currently at the time of writing, the estimated annual income for Ethereum mainnet validators is approximately 3% to 4% of their stake (based on [CoinDesk Indices Composite Ether Staking Rate (CESR)](https://indices.coindesk.com/indices/cesr-composite-ether-staking-rate) benchmark and [Rated.Network](https://explorer.rated.network/network?network=mainnet&timeWindow=all&rewardsMetric=average&geoDistType=all&hostDistType=all&soloProDist=stake)). This fee is not a "reward" for the same reasons why the protocol does not reward honest parties with the funds confiscated from a malicious actor (see [FAQ](https://www.notion.so/arbitrumfoundation/Arbitrum-BOLD-FAQ-93210f430a6a470792496be040ac9990) for more details). 21 | 22 | There is one important exception to the rule that honest proposers earn service fees. The Arbitrum Foundation currently operates a node that acts as a proposer, using money allocated to it for that purpose by the Arbitrum DAO ([AIP: Funds to bootstrap the first BoLD validator](https://forum.arbitrum.foundation/t/aip-funds-to-bootstrap-the-first-bold-validator/24506)). Since this proposer runs using the Arbitrum DAO's money as a bond, the Arbitrum Foundation's proposer will not earn service fees for proposing assertions. (It is, of course, still bonded on its assertions and is still subject to slashing if it is dishonest). 23 | 24 | ## Implementation 25 | 26 | In our initial implementation of BoLD, we envision the process of paying honest proposers their service fees as being mediated by the Arbitrum Foundation. However, this calculation of how much is owed in service fees, and to whom, is logically separate from the decision about who pays these parties their service fees (and how). 27 | 28 | :::note 29 | We deal in notional “time units” $u$ here, which are likely in practice to be parent chain block times or something similar. The details of what these units represent actually don’t matter very much; we just need a conversion factor $\theta = \frac{u}{\text{year}}$ 30 | ::: 31 | 32 | How service fees get calculated: 33 | 34 | - Take a time range $[t_{initial}, t_{final})$. This corresponds to the period of time we are going to consider; we will pay out only service fees accrued during this time. 35 | - $t_{final}$ must be some time in the past from the current time $t_{current}$. This is so that we can know “once and for all” which assertions were honest (from BoLD’s viewpoint) and which were not. How far in the past? The worst case is where the last assertion proposed before $t_{final}$ resulted in a challenge, which could take up to $2 \cdot p$ to resolve ($p$ being a challenge period). 36 | - We might be able to get away with less that $2 \cdot p$ if we are doing this offchain, since an offchain user can determine which assertions are honest before BoLD knows. These calculated honest assertions could then be used in the DAO proposal. However, we would still require at least that the assertions up to $t_{final}$ have gained finality on the parent chain before $t_{current}$. 37 | - Make a list $L$ of all honest assertions that were proposed between $t_{initial}$ and $t_{final}$. For each such honest assertion $A$, collect the following information: 38 | - $T(A)$, the time between the creation of $A$ and its honest successor assertion (measured in units $u$) 39 | - $Addr(A)$, the address of the bonder who bonded on $A$ 40 | - For each $A$ in $L$: 41 | - For generality, let $B$ be the bond amount, and let $R$ be the APY used to determine the service fee. 42 | - Compute the payment amount $M = T(A) \cdot \frac{1}{\theta} \cdot B \cdot R$ 43 | - Example: the parameters described above, using hours as our time unit $u$ (so $\theta = \frac{8760\ \text{hour}}{\text{year}}$, ignoring leap years) this would be: 44 | - $M = \frac{T(A) \cdot 3600\text{ETH} \cdot \frac{.05}{year}}{8760 \frac{\text{hour}}{\text{year}}} = .002055 \text{ETH} \cdot T(A) \cdot \frac{1}{\text{hour}}$ (remember that we defined $T(A)$ so that it includes its unit ($\text{hour}$)) 45 | - Pay $M(A)$ to $Addr(A)$ 46 | 47 | It is important to ensure that this procedure is not called on overlapping time ranges, as this could result in service fees being paid twice for any legitimate assertion within the overlap. 48 | 49 | ## How much does it cost? 50 | 51 | It's natural to ask how much this mechanism will cost the Arbitrum DAO. First, the common case might be that the Arbitrum Foundation's proposer usually proposes blocks. In this case, there is only one proposer (assuming the Arbitrum Foundation is honest and there are no challengers). This assumption is one reason we don't want to make the service fees for proposing blocks too high: we don't want unnecessary competition between honest proposers trying to profit by earning service fees. No service fees need to be paid out in this "happy case" (with only Arbitrum Foundation proposing). 52 | 53 | On the other hand, it could (in the worst case) happen that the Arbitrum Foundation proposer never gets a chance to propose. In this case, other honest parties would be earning 3% APY on their bonds 100% of the time. So, over a year, we would have to pay out 3% \cdot 3600 = 108 `ETH`. 54 | 55 | This example is the worst case: we are *guaranteed never to have to pay more than the staking rate that the parent chain Ethereum validators get for the same period*. 56 | 57 | **Proof Sketch:** To see this, let's look retrospectively at states of the challenge protocol, from the perspective of a time after all relevant parent chain blocks have become finalized, and all relevant assertions have either been accepted or rejected (i.e., adjudicated as honest or dishonest). First, notice that there can only be one bonded honest proposer for all points in time. 58 | 59 | - Suppose there were two honest proposers at some point in time, bonded on two different assertions. 60 | - If these assertions are both honest, one must be a predecessor of the other. However, only one bond can exist on any one assertion, including all predecessors of that assertion. So we have a contradiction. 61 | - Otherwise, at least one of the assertions is dishonest, contradicting our assumption that the proposers are both honest. 62 | 63 | Using this, we can prove the main result: 64 | - Suppose there exists a point in time where we have paid out more than 108 `ETH` during the past year. In the case above ("the Arbitrum Foundation proposer never gets a chance to propose"), one honest bonded proposer is eligible for the service fee at any time. But in this case, we pay out only 108 `ETH`. To pay out more, we would need to be paying out service fees on more bonds. But since every point in time already has a bond on an honest assertion, the only way to "squeeze in" more bonded value would be to create a situation where two honest parties are bonded on different assertions (as, again, there can only be one bond per assertion) at some point in time. But this contradicts the statement proven above (that there can only be one bonded honest proposer at any point in time). 65 | 66 | ## Other remarks 67 | 68 | In principle, the calculations determining who should receive service fee payments and how much they receive could be completed onchain. It would be possible to implement a smart contract that a current or former proposer can call to retrieve their service fee payments; such a smart contract would probably be feasible from a gas-cost standpoint. However, we do not do this for the initial release of BoLD due to development time constraints. Determining how *often* to pay parties their service fees is not obvious and involves some tradeoffs. This decision will be left up to the Arbitrum Foundation as the Arbitrum DAO entrusts them to make these payments on behalf of the Arbitrum DAO, when necessary. All service fee payments will be manually processed by the Arbitrum Foundation periodically (weekly or monthly), alongside a requirement that all payments adhere to the Arbitrum Foundation’s compliance process. 69 | 70 | The approved [AIP proposal to request funds to bootstrap the first BoLD validator](https://forum.arbitrum.foundation/t/aip-funds-to-bootstrap-the-first-bold-validator/24506#p-51247-payment-facilitation-final-costs-restrictions-13), and all funds requested for service fees will go to a multi-signature wallet controlled by the Arbitrum Foundation. After three years, the Arbitrum DAO will return any unspent funds from the service fee reimbursement budget. Additionally, a proposal that addresses future operational costs for Arbitrum is forthcoming. The Arbitrum DAO reserves the right to revoke the Arbitrum Foundation's proposer at any time and return the bonds to the treasury. We will implement and enforce this process through the BoLD smart contracts. 71 | * **Withdrawal address**: The funds will be deposited into BoLD and the withdrawal address set to the ‘UpgradeExecutor’ contract on the parent chain. 72 | * **Triggering withdrawal**: The Arbitrum DAO (via governance) or the Arbitrum Foundation will have the authority to trigger a withdrawal and the funds can only be sent to the pre-established withdrawal address (i.e., the Arbitrum DAO’s treasury). 73 | 74 | In short, the Arbitrum DAO will have the authority to return the funds to the Arbitrum DAO treasury. This model can be used for future proposals if other entities want to run a proposer on behalf of the Arbitrum DAO. 75 | -------------------------------------------------------------------------------- /docs/concepts/arb-token.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: arb-token 3 | title: "The $ARB token: A conceptual overview" 4 | sidebar_label: $ARB token 5 | description: Learn about the $ARB governance token, a special-purpose digital asset that gives its holders the ability to vote on on-chain proposals that affect the operation and evolution of the Arbitrum DAO and the technologies it governs. 6 | dao_author: symbolpunk 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | The **$ARB token** is an ERC-20 governance token that allows its holders to participate in the Arbitrum DAO's on-chain governance protocol. The $ARB token is minted by a smart contract that lives on Arbitrum One, a Layer 2 Arbitrum rollup chain. 15 | 16 | The Arbitrum DAO is responsible for managing both the governance protocol as defined within the [Constitution](../dao-constitution.md), and the technologies that the DAO governs. This includes the Arbitrum One and Arbitrum Nova chains, along with their underlying protocols. 17 | 18 | If you own $ARB tokens, you can vote on governance proposals that affect the operation and evolution of the Arbitrum One and Arbitrum Nova chains. This includes proposals for upgrades to the chain, as well as proposals for how to use the funds within the DAO Treasury. 19 | 20 | When you vote on an on-chain proposal, you're using your $ARB tokens to signal your support or opposition. The more $ARB tokens you have, the more influence your vote will have. This is because the Arbitrum DAO's smart contracts are implemented such that votes are token-weighted, meaning that the power of a vote is determined precisely by the number of tokens the voter's wallet represents. 21 | 22 | Note that $ARB tokens can be delegated to other wallets. This means that you can vote using your own $ARB tokens (those in your own wallet), but you can also vote using someone else's $ARB tokens as long as the owner of those tokens has delegated their voting power to you. Delegation is useful for DAO members who don't have time to commit to reviewing and discussing DAO proposals on a regular basis[^1]. 23 | 24 | $ARB was created with an initial supply of 10 billion. New $ARB can be minted at a rate of 2% of its supply per year _at most_, with the first of these mints becoming eligible on March 15, 2024. $ARB minting events are performed by the DAO via a [constitutional](../dao-constitution.md) proposal. 25 | 26 | In summary, the $ARB token is a special-purpose digital asset that gives its holders the ability to vote on on-chain proposals that affect the operation and evolution of the Arbitrum DAO and the technologies it governs. Holding $ARB tokens allows you democratically shape the future of the Arbitrum ecosystem alongside other values-aligned and incentives-aligned token holders. 27 | 28 | 29 | [^1]: See [Delegates and delegation: A conceptual overview](./delegate-delegation) to learn more about this concept. See [How to delegate your voting power](../how-tos/select-delegate-voting-power) to learn how to transfer the voting power of your $ARB tokens to a delegate of your choosing. 30 | -------------------------------------------------------------------------------- /docs/concepts/arbitrum-dao.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: arbitrum-dao 3 | title: "Arbitrum DAO: A conceptual overview" 4 | sidebar_label: Arbitrum DAO 5 | description: Learn about the Arbitrum DAO, its governance token, and its built-in treasury and security mechanisms. 6 | dao_author: symbolpunk 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | The Arbitrum DAO is a decentralized autonomous organization (DAO) built on the Ethereum blockchain. At its core, the Arbitrum DAO is a community-driven governance mechanism that allows $ARB token holders to propose and vote on changes to the organization and the technologies it governs. 15 | 16 | The Arbitrum DAO's governance smart contracts are implemented on the Arbitrum One rollup chain, which is a Layer 2 scaling solution for the Ethereum blockchain. These smart contracts include the DAO's governance token, $ARB. DAO members use $ARB tokens to vote on Arbitrum DAO proposals (AIPs). The weight of any given voter's vote is proportional to the amount of $ARB they hold (or represent)[^1]. 17 | 18 | The Arbitrum DAO has a built-in treasury system ([implemented as a smart contract](https://github.com/ArbitrumFoundation/governance/blob/main/docs/overview.md)); the DAO's treasury is used to fund ongoing development and maintenance of the organization and its technologies. Token holders can propose and vote on how to use the treasury's funds. 19 | 20 | The Arbitrum DAO also has a built-in security mechanism called the Security Council. The Security Council is a group of entities who are responsible for ensuring the security and integrity of the DAO and its chains. The council can bypass the slow voting process and take fast action in the case of security emergency, as outlined in the Constitution. The members of the Security Council are elected by the DAO via semiannual elections. 21 | 22 | Overall, the Arbitrum DAO is a powerful tool that facilitates decentralized governance and community-driven management of the Arbitrum ecosystem. By holding $ARB tokens and participating in the governance process, individuals can have a direct impact on the future of Arbitrum and, by extension, Ethereum. 23 | 24 | [^1]: Some DAO members might not have the capacity to actively participate in the governance process. These members can delegate their voting power to other members who are able to actively participate. This mechanism is called "voting delegation". See [Delegates and delegation](./delegate-delegation) to learn more about this concept. If you hold $ARB tokens and want to delegate your voting power, see [How to delegate your voting power](../how-tos/select-delegate-voting-power). 25 | -------------------------------------------------------------------------------- /docs/concepts/dao-vote.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: dao-vote 3 | title: "Arbitrum DAO votes: A conceptual overview" 4 | sidebar_label: DAO vote 5 | description: Learn about the different types of votes that take place in the Arbitrum DAO. 6 | dao_author: symbolpunk 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | The Arbitrum DAO is governed by a protocol that allows $ARB governance token holders to propose and vote on different actions, such as changes to the DAO's [Constitution](../dao-constitution.md) or funding for specific projects. These votes are crucial for making decisions that shape the future of Arbitrum and the technologies it governs. 15 | 16 | ### Types of votes 17 | 18 | There are two types of votes in the Arbitrum DAO: 19 | 20 | 1. **Temperature check:** This is a preliminary vote that gauges the community's interest in a proposal before it moves on to the next stage. Temperature checks are conducted on the Snapshot platform and are only open to $ARB token holders who hold (or represent) at least 0.01% of votable tokens. 21 | 22 | 2. **On-chain vote:** If the proposal passes the temperature check, it will move on to an on-chain vote facilitated by [Tally](https://tally.xyz/gov/arbitrum). This "call for votes" can be initiated by $ARB token holders who hold (or represent) at least 1,000,000 votable tokens. To be approved, more than 50% of the votable tokens that voted on the proposal must have voted in favor of the proposal; constitutional proposals must receive votes from at least 5% of all votable tokens in existence; non-constitutional proposal must receive votes from at least 3% of all votable tokens in existence. Refer to the [Constitution](../dao-constitution.md) for a more precise description of Arbitrum DAO's governance protocol. 23 | 24 | ### Token-weighted voting 25 | 26 | The amount of voting power you have is determined by the number of $ARB tokens you hold. However, you also have the option to grant your voting power to a delegate who can vote on your behalf. This is a great option for token holders who may not have the time or resources to actively participate in the DAO's governance. See [How to delegate your voting power](../how-tos/select-delegate-voting-power.md) to learn more about this option. 27 | 28 | ### Values-based voting 29 | 30 | It's important to note that the Arbitrum DAO operates on a set of values outlined in its [Constitution](../dao-constitution.md). These values include decentralization, security, and scalability. When evaluating proposals, voters should consider whether the proposal aligns with these values and if the proposal furthers the interests of the DAO as a whole (as opposed to special interests that don't represent the DAO as a whole). 31 | 32 | ### Conclusion 33 | 34 | Voting is an important aspect of the Arbitrum DAO's governance and allows token holders to make decisions that shape the future of the DAO. By understanding the different types of votes, your voting power, and the values that guide the DAO, you can help the DAO make collectively informed and incentives-aligned decisions. -------------------------------------------------------------------------------- /docs/concepts/delegate-delegation.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: delegate-delegation 3 | title: "Delegates and delegation: A conceptual overview" 4 | sidebar_label: Delegates and delegation 5 | description: Learn about the role of delegates and delegation within the context of the Arbitrum DAO. 6 | dao_author: symbolpunk 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | When participating in the Arbitrum DAO, token holders have the option to either vote directly on proposals or to give their voting power to a delegate. This concept doc explores the role of delegates and delegation within the context of the Arbitrum DAO. 15 | 16 | ### What is a delegate? 17 | 18 | A delegate is a member of the Arbitrum DAO community who has been elected to represent other token holders and vote on their behalf. Delegates are elected by token holders who choose to grant their voting power to them. Delegates are required to follow the protocols defined by the [Constitution of the Arbitrum DAO](../dao-constitution.md), and must act in the best interest of the token holders whom they represent. 19 | 20 | ### Why delegate? 21 | 22 | Delegation allows token holders to participate in the governance of the Arbitrum DAO without having to actively keep track of every proposal and vote. By granting their voting power to a delegate, token holders can passively participate by entrusting a representative to vote on proposals in a way that aligns with their own beliefs and values. 23 | 24 | Token holders who delegate their voting power are able to revoke this delegation and reclaim voting power back to themselves at any time. They may want to do this if, for example, there's an important proposal that they themselves want to vote on directly. 25 | 26 | ### How to delegate 27 | 28 | The Arbitrum DAO uses [Tally](https://tally.xyz/gov/arbitrum) to facilitate delegation. The process in a nutshell: 29 | 30 | 1. Connect your Ethereum wallet to [Tally](https://tally.xyz/gov/arbitrum) and navigate to the Arbitrum DAO page. 31 | 2. Select the "delegate" button. 32 | 3. Search for the delegate you'd like to delegate your voting power to and confirm the delegation by following Tally's prompts. 33 | 34 | Note that through Tally, you can change or revoke your delegation at any time. If you wish to delegate to multiple delegates, then you will need an address per delegate. For more detailed how-to guidance, see [How to delegate your voting power](../how-tos/select-delegate-voting-power). 35 | 36 | ### Conclusion 37 | 38 | The Arbitrum DAO's delegation mechanism lets $ARB token holders passively participate in Arbitrum DAO's governance by facilitating the transfer of their token-weighted voting power to values-aligned representatives of the Arbitrum DAO's values, as defined by [The Constitution of the Arbitrum DAO](../dao-constitution.md). -------------------------------------------------------------------------------- /docs/concepts/public-preview-content.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: public-preview-content 3 | title: "Public preview content" 4 | sidebar_label: Public preview content 5 | description: Learn about the public preview content pattern used by the Arbitrum DAO. 6 | dao_author: symbolpunk 7 | dao_sme: symbolpunk 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | Every Arbitrum DAO governance document (excluding the [Constitution](../dao-constitution)) is initially published with the following "public preview" disclaimer: 13 | 14 | 15 | 16 | This disclaimer is used to **set expectations** and to **invite feedback** from readers like you. Whenever there's evidence that a given document is meeting readers' needs, its public preview disclaimer is lifted. When a document's public preview disclaimer is lifted, it's considered "validated", but it's still subject to change based on reader feedback. 17 | 18 | ### What types of documents does this apply to? 19 | 20 | This pattern applies to all Arbitrum DAO governance documents that are published here on the Arbitrum DAO docs portal, excluding [The Constitution of the Arbitrum DAO](../dao-constitution.md). Examples include: 21 | 22 | - Conceptual documentation 23 | - [Delegates and delegation](./delegate-delegation.md) 24 | - [Lifecycle and anatomy of an AIP](./lifecycle-anatomy-aip-proposal.md) 25 | - How-to documentation 26 | - [Apply to become a delegate](../how-tos/apply-become-delegate.md) 27 | - [Submit an AIP](../how-tos/create-submit-dao-proposal.md) 28 | 29 | 30 | ### How do you know when a public preview document is ready to have its disclaimer lifted? 31 | 32 | In general, a document is considered validated if it's 1) frequently viewed, 2) has a low bounce rate, and 3) doesn't have any open issues on GitHub/[Discord](https://discord.gg/arbitrum). This heuristic isn't supported by precise thresholds; it's an informal and experimental process. This document will be updated if the process changes. 33 | 34 | ### Does this mechanism apply to The Constitution of the Arbitrum DAO? 35 | 36 | No. The private preview content pattern does **not** apply to [The Constitution of the Arbitrum DAO](../dao-constitution.md). 37 | 38 | ### What's the difference between a draft and a public preview? 39 | 40 | Readers generally interpret drafts as "not ready for public consumption". Arbitrum DAO's public preview documentation is ready for public consumption with the caveat that it still needs to be measured, validated, and optimized. 41 | 42 | ### Does this mean that the Arbitrum DAO isn't committed to its governance documentation? 43 | 44 | No. The Arbitrum DAO is committed to its governance docs, just not in exactly the same way that it's committed to the Constitution: 45 | 46 | - **The Constitution** is the Arbitrum DAO's highest-order governance document. It's the only document that's subject to the formal governance proposal mechanism. In order for the Constitution to change, a proposal must be submitted to the Arbitrum DAO and approved by a majority of the Arbitrum DAO's voting power. This is a formal process that only the Arbitrum DAO can initiate and execute. 47 | - **Other governance documents** are derived from a combination of 1) the Constitution and 2) reader feedback. These docs frequently change via traditional pull requests issued against the governance docs repository. This is an informal, continuous, iterative process that anyone can participate in. 48 | 49 | 50 | ### Is the governance protocol itself in public preview? 51 | 52 | No. This disclaimer applies only to the documents that display it. It doesn't apply to the protocol; it doesn't apply to the Constitution; it doesn't apply to the smart contracts; it doesn't apply to the DAO. The Arbitrum DAO's governance protocol is in production. Some of the Arbitrum DAO's governance documentation is in public preview; those docs are marked with the same `PUBLIC PREVIEW DOCUMENT` disclaimer that you see at the top of this page. -------------------------------------------------------------------------------- /docs/concepts/security-council.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: security-council 3 | title: "Security Council: A conceptual overview" 4 | sidebar_label: Security Council 5 | description: Learn about the Security Council, a group of individuals who are responsible for managing the risk of the Arbitrum ecosystem through the selective application of emergency actions. 6 | dao_author: symbolpunk 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | [The Constitution of the Arbitrum DAO](../dao-constitution) outlines the process for electing members to the Security Council, a group of individuals who are responsible for addressing risks to the Arbitrum ecosystem through the selective application of emergency actions and non-emergency actions. The Security Council is made up of 12 members who are elected by the members of the Arbitrum DAO through a democratic process. See [here](../security-council-members) for the current members of the Security Council. 15 | 16 | ### The role of the Security Council 17 | 18 | The primary role of the Security Council is to address critical risks associated with the Arbitrum protocol and its ecosystem. The Security Council is responsible for making time-sensitive and emergency response decisions that protect the interests of the DAO, its members, and the broader Arbitrum community. The Security Council is subject to the oversight and control of the DAO's members, who have the power to remove Security Council members if they're not acting in the best interests of the DAO. 19 | 20 | ### How the elections work 21 | 22 | The Security Council is a 12-member council divided into two groups. Every six months, there are elections to fill the seats in these two groups, respectively. 23 | 24 | Every elected Security Council member’s term lasts one year, excluding the first cohort’s member terms, which are truncated by the amount of time between the date of the first election specified in the Constitution and the date of the DAO's launch. 25 | 26 | To become a candidate for the Security Council, you must be a member of the Arbitrum DAO. You must also have support from at least 0.2% of all votable tokens. Once the candidates have been chosen, all members of the Arbitrum DAO can vote for the candidates. The 6 candidates who receive the most votes will be elected to the Security Council. Additionally, the Arbitrum Foundation may set forth further guidelines and procedures for ensuring a fair, transparent and effective elections process. 27 | 28 | No more than 3 candidates from the same organization should be elected into the Security Council. Also, candidates shouldn't have any conflicts of interest that would prevent them from acting in the best interests of the Arbitrum DAO. 29 | 30 | The rules for the Security Council elections can be changed by the members of the Arbitrum DAO, but these changes can't be made during an ongoing election. Security Council members can also be removed from their position prior to their term ending if at least 10% of all votable tokens participate in a removal vote, and at least 5/6 of the votes are in favor of removal. A member can also be removed if at least 9 members of the Security Council vote in favor of removal. 31 | 32 | Note that the [Constitution](../dao-constitution.md) is the most authoritative specification of the Arbitrum DAO's rules. If there are any discrepancies between this document and the Constitution, please feel free to submit an issue, and note that the Constitution takes precedence. 33 | 34 | 35 | ### Why elections are important 36 | 37 | The Security Council elections are important because they democratically determine who will be responsible for being vigilant about the security and integrity of the Arbitrum DAO. By holding regular elections, the community can ensure that the Council is made up of members who truly represent the values enshrined within [The Constitution of the Arbitrum DAO](../dao-constitution). 38 | 39 | In addition, the election process allows for the removal of Council members who are not acting in the best interests of the DAO. This helps to ensure that the Council always has the best interests of the network in mind. 40 | 41 | 42 | ### Conclusion 43 | 44 | The Security Council and its elections are an important part of the governance of the Arbitrum DAO. By participating in the elections, community members can ensure that the Security Council is made up of members who are trusted to represent the Arbitrum community’s values and to offer subject-matter expertise the community thinks relevant for the Council. 45 | 46 | These needs will generally demand expert-level technical proficiency and experience across a variety of technical domains, but the Arbitrum DAO’s values and needs are likely to evolve over time. Developing an understanding of the Security Council mechanism and its purpose is very important, especially if you’re a delegate or are otherwise active in Arbitrum DAO’s governance. 47 | 48 | If you're a member of the Arbitrum DAO, it's especially important for you to be aware of and support efforts towards risk management and progressive decentralization in order to ensure the long-term success and sustainability of the Arbitrum DAO and the technologies it governs. This includes the management of expectations and perceptions within and beyond the Ethereum community. It also includes continuous, collaborative self-education. 49 | -------------------------------------------------------------------------------- /docs/concepts/sybil-account.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: sybil-account 3 | title: "Sybil accounts: A conceptual overview" 4 | sidebar_label: Sybil accounts 5 | description: Learn about Sybil accounts and how they were detected prior to the $ARB airdrop. 6 | dao_author: dzgoldman 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | 15 | ### What are Sybil accounts? 16 | 17 | In the context of Arbitrum Governance, Sybil accounts are Arbitrum accounts controlled by an entity trying to create the false appearance of being many entities via deceptive on-chain activity in order to unfairly game the $ARB airdrop. 18 | 19 | ### How were Sybil accounts detected prior to the airdrop? 20 | 21 | A process called "Sybil hunting" was used to detect and remove Sybil accounts. The process involved creating a graph of all transactions that have taken place on Arbitrum One, and then partitioning this graph into different subgraphs. The subgraphs that have a large number of nodes and a high degree of connectivity were considered to be likely Sybil clusters. The accounts within these clusters were collapsed into a single recipient account for the airdrop. Entities explicitly known to by Sybils were also removed; the dataset of these entities was created with help from our friends at [Nansen](https://www.nansen.ai/) and [Hop](https://hop.exchange/). See [Arbitrum Sybil Hunting](https://github.com/ArbitrumFoundation/sybil-detection) for more information. 22 | 23 | ### Why is it important to prevent Sybil accounts? 24 | 25 | By receiving an outsized share of the $ARB airdrop, Sybil accounts can lead to concentration of voting power and undermine the decentralized nature of the Arbitrum DAO. By preventing Sybil accounts, the Arbitrum DAO is able to ensure that the initial token distribution is as fair as possible. 26 | 27 | ### Why not use proof-of-personhood? 28 | 29 | Criteria for allotment of the $ARB airdrop involves on-chain activity. The ability for users to interact with Arbitrum One permissionlessly and pseudonymously is a fundamental property of the system. Requiring some sort of identity verification for airdrop-qualification would undermine this core value, and thus wasn't considered. 30 | 31 | -------------------------------------------------------------------------------- /docs/dao-constitution.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: dao-constitution 3 | title: The Amended Constitution of the Arbitrum DAO 4 | sidebar_label: The Constitution of the Arbitrum DAO 5 | description: Read "The Constitution of the Arbitrum DAO", the ultimate governing document of the Arbitrum DAO. Arbitrum DAO's smart contracts implement the protocols described in this document. 6 | --- 7 | 8 | import ConstitutionPartial from '@site/docs/partials/_constitution-content-partial.md'; 9 | import { ConstitutionHash } from '@site/src/components/ConstitutionHash' 10 | import { PendingConstitutionNotice } from '@site/src/components/PendingConstitutionNotice' 11 | 12 | 13 |
14 | 15 |
16 | 17 | 18 | ### Constitution hash 19 | 20 |
21 | 22 | 23 | 24 |

25 | 26 | To compute this hash yourself, you can clone [ArbitrumFoundation/docs](https://github.com/ArbitrumFoundation/docs) to your local machine and run `yarn update-constitution-hash` from the root directory of the repo. Alternatively, you can install [Node.js](https://nodejs.org/en/), navigate to the `docs` folder, and run `node ./scripts/updateConstitutionHash.js`. 27 | 28 | This will use the `keccak256` method from the [@ethersproject/solidity](https://github.com/ethers-io/ethers.js#readme) project to compute the hash of the Constitution's markdown source code, located in [`/ArbitrumFoundation/docs/blob/main/docs/partials/_constitution-content-partial.md`](https://github.com/ArbitrumFoundation/docs/blob/main/docs/partials/_constitution-content-partial.md). 29 | 30 | -------------------------------------------------------------------------------- /docs/dao-faqs.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: dao-faqs 3 | title: Arbitrum DAO FAQs 4 | sidebar_label: FAQs 5 | description: FAQs about the Arbitrum DAO. 6 | toc_min_heading_level: 3 7 | --- 8 | 9 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 10 | 11 | 12 | 13 | 14 | import FAQsPartial, {toc as FAQsTOC} from '@site/docs/partials/_faq-partial.md'; 15 | 16 | 17 | 18 | export const toc = FAQsTOC 19 | -------------------------------------------------------------------------------- /docs/dao-glossary.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: dao-glossary 3 | title: Arbitrum DAO glossary 4 | sidebar_label: Glossary 5 | description: Review the Arbitrum DAO's key terms and definitions. 6 | toc_min_heading_level: 3 7 | --- 8 | 9 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 10 | 11 | 12 | 13 | 14 | import GlossaryPartial, {toc as GlossaryTOC} from '@site/docs/partials/_glossary-partial.md'; 15 | 16 | 17 | 18 | export const toc = GlossaryTOC 19 | -------------------------------------------------------------------------------- /docs/deployment-addresses.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: deployment-addresses 3 | title: DAO contract addresses 4 | sidebar_label: Contract addresses 5 | --- 6 | 7 | import DraftExpectationsPartial from '@site/docs/partials/\_draft-expectations-partial.md'; 8 | 9 | 10 | 11 | import { AddressExplorerLink as AEL } from '@site/src/components/AddressExplorerLink' 12 | 13 | ### Token 14 | 15 | | Contract | Chain | Address | 16 | | -------------------- | ---------- | ---------------------------------------------------------------------------------- | 17 | | $ARB Token | Arb One | | 18 | | $ARB Token (bridged) | Ethereum | | 19 | | $ARB Token (bridged) | Nova | | 20 | | $ARB Token (testnet) | Arb Sepolia| | 21 | 22 | ### Token Distribution 23 | 24 | | Contract | Chain | Address | 25 | | -------------------------------- | ------- | ---------------------------------------------------------------------------------- | 26 | | Token Distributor\* | Arb One | | 27 | | DAO Treasury | Arb One | | 28 | | Foundation Vesting Budget Wallet | Arb One | | 29 | 30 | _\*Note: the Token Distributor contract was [self-destructed](https://arbiscan.io/tx/0xa2477f2f1d7824501520a88b50835ad283e7472e0fa5e67005452528bf740175) after the end of the aidrop claiming period._ 31 | 32 | ### Token Bridging 33 | 34 | | Contract | Chain | Address | 35 | | ------------------------- | ---------- | ----------------------------------------------------------------------------------- | 36 | | $ARB Gateway (Arb1) | Arb One | | 37 | | $ARB Gateway (L1) | Ethereum | | 38 | | $ARB Gateway (Nova) | Nova | | 39 | | $ARB Gateway (L2 testnet) | Arb Sepolia| | 40 | | $ARB Gateway (L1 testnet) | Sepolia | | 41 | 42 | ### DAO Governance 43 | 44 | | Contract | Chain | Address | 45 | | ----------------------------------- | -------- | ---------------------------------------------------------------------------------- | 46 | | Core Governor | Arb One | | 47 | | Treasury Governor | Arb One | | 48 | | Arb One Upgrade Executor | Arb One | | 49 | | Nova Upgrade Executor | Nova | | 50 | | L1 Upgrade Executor | Ethereum | | 51 | | L2 Core Timelock | Arb One | | 52 | | L2 Treasury Timelock (ETH treasury) | Arb One | | 53 | | L1 Timelock | Ethereum | | 54 | 55 | ### Security Council 56 | 57 | | Contract | Chain | Address | 58 | | ----------------------------------- | -------- | ---------------------------------------------------------------------------------- | 59 | | Security Council (Arb One, emergency) | Arb One | | 60 | | Security Council (Arb One, non emergency) | Arb One | | 61 | | Security Council (L1, emergency) | Ethereum | | 62 | | Security Council (Nova, emergency) | Nova | | 63 | 64 | _Note: See ["Security Council Members"](./security-council-members) for addresses of the current members of the Security Council._ 65 | 66 | ### Security Council Elections 67 | 68 | | Contract | Chain | Address | 69 | | -------------------------- | -------- | ---------------------------------------------------------------------------------- | 70 | | Nominee Election Governor | Arb One | | 71 | | Member Election Governor | Arb One | | 72 | | Manager | Arb One | | 73 | | Upgrade Exec Route Builder | Arb One | | 74 | | Member Removal Governor | Arb One | | 75 | | Member Sync Action | Arb One | | 76 | | Member Sync Action | Ethereum | | 77 | | Member Sync Action | Nova | | 78 | 79 | ### DAO Constitution 80 | 81 | | Contract | Chain | Address | 82 | | ----------------- | ------- | ---------------------------------------------------------------------------------- | 83 | | Constitution Hash | Arb One | | 84 | 85 | ### Governance Contracts Proxy Admins 86 | 87 | | Contract | Chain | Address | 88 | | ------------------- | -------- | ---------------------------------------------------------------------------------- | 89 | | Arb One Proxy Admin | Arb One | | 90 | | Nova Proxy Admin | Nova | | 91 | | L1 Proxy Admin | Ethereum | | 92 | 93 | ### Fee Distribution 94 | 95 | | Contract | Chain | Address | 96 | | -------------- | ------- | ---------------------------------------------------------------------------------- | 97 | | L1 Base Fee | Arb One | | 98 | | L1 Surplus Fee | Arb One | | 99 | | L2 Base Fee | Arb One | | 100 | | L2 Surplus Fee | Arb One | | 101 | 102 | | Contract | Chain | Address | 103 | | -------------- | ----- | ---------------------------------------------------------------------------------- | 104 | | L1 Base Fee | Nova | | 105 | | L1 Surplus Fee | Nova | | 106 | | L2 Base Fee | Nova | | 107 | | L2 Surplus Fee | Nova | | 108 | -------------------------------------------------------------------------------- /docs/fee-distribution.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: fee-distribution 3 | title: Fee Distribution 4 | sidebar_label: Fee Distribution 5 | description: Learn how fees collected on DAO-governed chains are distributed 6 | dao_author: dzgoldman 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | ### Overview 11 | 12 | Users pay fees when transacting on Arbitrum One and Arbitrum Nova in the chains' native currency, Ether. Fees exist as a spam / denial-of-service prevention measure, as well as a way to pay for the chains' operational and maintenance costs. 13 | 14 | Several different things are accounted for when computing a user's transaction fee, as discussed below. One portion of a transaction fee — "the L1 Base Fee" — goes to the entity controlling the chain's Sequencer, which for both chains is the Arbitrum Foundation. This portion of the fee compensates the Sequencer for the costs it pays to post users' transactions on layer 1; i.e., by receiving this fee, the Sequencer / the Arbitrum Foundation breaks even over time, but does not generate profit. 15 | 16 | On Arbitrum One, the remainder of a transaction's fee goes directly to the Arbitrum DAO. On Arbitrum Nova, the remainder goes mostly to the DAO, while a portion goes to various third parties running the chain's critial infrastructure (see below). 17 | 18 | ### Fee Breakdown 19 | 20 | The total fee that a user pays for a transaction is computed as the sum of four 4 different components: 21 | 22 | | Fee | Description | Recipient (Arbitrum One) | Recipient (Nova) | 23 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | -------------------------------------------------------------------------- | 24 | | L1 Base Fee | The L1 Base Fee is the estimated cost of L1 calldata a transaction will contribute to a batch. When a batch is posted, the actual cost paid the Sequencer is reported to L2, and the estimated L1 cost adjusts accordingly. This ensures the Sequencer breaks even (i.e., neither profits or operates at a lost) over time. For more info, see [here](https://docs.arbitrum.io/arbos/l1-pricing). | The Sequencer / The Arbitrum Foundation | The Sequencer / The Arbitrum Foundation | 25 | | L2 Base Fee | The L2 Base Fee pays the minimum L2 gas price for each of unit of L2 gas in a given L2 transaction. This minimum L2 gas price is 0.1 gwei on Arbitrum One and 0.01 gwei on Arbitrum Nova. | The DAO | 80% to the DAO, remaining 20% to parties running Nova Validators / the DAC | 26 | | L2 Surplus Fee | With sufficient chain congestion, the L2 fee increases above the minimum L2 gas price; the fee paid to cover the difference between the gas price and the minimum gas price for each unit of gas is the L2 Surplus Fee. | The DAO | The DAO | 27 | | L1 Surplus Fee | Additional fee charged as proportion of L1 base fee, beyond, e.g., the amount strictly necessary for the Sequencer to break even. | The DAO | The DAO | 28 | 29 | For both Arbitrum One and Nova, any of the fee recipients can be updated by the DAO via a [constitutional proposal](./how-tos/create-submit-dao-proposal.md). 30 | 31 | ### Implementation Details 32 | 33 | Fees for each of the four fee-components initially accrue at a distinct [Reward Distributor contract](https://github.com/OffchainLabs/fund-distribution-contracts); at any point, the fees can be distributed to their target recipients by any party via a permissionless contract call. This design allows for ease of distributing fees to multiple parties at different proportions, as well as a means for the DAO to easily change fee recipients. 34 | 35 | On Arbitrum One, the fee recipient for "the DAO" is the [Treasury Timelock](https://arbiscan.io/address/0xbfc1feca8b09a5c5d3effe7429ebe24b9c09ef58); the DAO can spend these funds via a [treasury governance proposal](./how-tos/create-submit-dao-proposal.md). For Nova, the DAO's fee recipient is an address accessible via cross-chain messages from a core governance proposal. 36 | 37 | For fee distribution contract addresses, see [here](./deployment-addresses.md). 38 | -------------------------------------------------------------------------------- /docs/foundation-documents.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | id: foundation-documents 3 | title: The Arbitrum Foundation Documents 4 | sidebar_label: Foundation documents 5 | description: A collection of documents relating to The Arbitrum Foundation, including its setup and processes. 6 | dao_author: fred 7 | dao_sme: fred 8 | --- 9 | 10 | import { TrackedLink } from '@site/src/components/TrackedLink'; 11 | import ArbitrumFoundationTransparencyReport2024 from '../assets/ArbitrumFoundationTransparencyReport2024.pdf' 12 | 13 | ### The Arbitrum Foundation Documents 14 | 15 | In this page you may find a collection of documents relating to The Arbitrum Foundation, including its setup and processes. 16 | 17 | - [Bylaws](../assets/The%20Arbitrum%20Foundation%20Bylaws%2020%20July%202023.pdf) 18 | - [M&A](../assets/The%20Arbitrum%20Foundation%20M&A%20-%2020%20July%202023.pdf) 19 | - [Standard Grant Agreement](../assets/The%20Arbitrum%20Foundation%20-%20Boilerplate%20Grant%20Agreement.pdf) 20 | - [Arbitrum Expansion Program](pathname:///aep/ArbitrumExpansionProgramTerms.pdf) 21 | 22 | #### Transparency Reports 23 | - [Initial Setup Transparency Report](./foundational-documents/transparency-report-initial-foundation-setup.md) 24 | - [2023 Transparency Report](../assets/ArbitrumFoundationTransparencyReport2023.pdf) 25 | - [2024 Biannual Progress Report](../assets/ArbitrumFoundationBiannualReport2024H1.pdf) 26 | - [Captive Insurance Product](../assets//ArbitrumFoundationCaptiveInsuranceProduct.pdf) 27 | - 2024 Transparency Report -------------------------------------------------------------------------------- /docs/how-tos/apply-become-delegate.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: apply-become-delegate 3 | title: How to become a delegate 4 | sidebar_label: Become a delegate 5 | description: Learn how to become a delegate for the Arbitrum DAO. 6 | dao_author: symbolpunk 7 | dao_sme: amarrazza 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | ### Background 15 | 16 | Arbitrum DAO's launch [was announced in March of 2023](https://arbitrumfoundation.medium.com/arbitrum-the-next-phase-of-decentralization-e7f8b37b5226) and the $ARB airdrop took place fron 3/23/23 to 9/24/23. $ARB token-holders are able to delegate the voting power of their tokens to delegates of the Arbitrum DAO[^1]. 17 | 18 | To become a delegate, create a profile on [Tally](https://tally.xyz/gov/arbitrum) and begin [building your delegate platform](./build-strong-delegate-platform). To make it easy for voters to learn more about you, submit a delegate statement using the template on the [Arbitrum DAO governance forum](https://forum.arbitrum.foundation/t/delegate-application-template/31). 19 | 20 | ### Become a delegate: Best practices 21 | 22 | Before deciding to become a delegate, it's important to understand the responsibilities and expectations of the role. Review the following guidelines to ensure that you're prepared to become a delegate for the Arbitrum DAO: 23 | 24 | - Delegates are expected to actively participate in the decision-making process and to act in the best interests of the network. They should also be familiar with [The Constitution of the Arbitrum DAO](../dao-constitution) and each of the documents within this content set. 25 | - Review [The Constitution of the Arbitrum DAO](../dao-constitution) and each of the documents within this content set to ensure that you understand the scope of delegate responsibilities and the mechanisms by which the Arbitrum DAO operates. 26 | - Review the [comprehension check](../dao-comprehension-check.md) to self-assess your understanding of the Arbitrum DAO governance protocol. 27 | - Prepare to [build a strong delegate platform](./build-strong-delegate-platform). This includes establishing an online presence that outlines your qualifications, experience, and vision for the Arbitrum DAO. You can use your platform to demonstrate your understanding of the protocol and the highest-priority challenges that the community is facing. 28 | - Submit a delegate statement using the template posted in the [delegate application template thread](https://forum.arbitrum.foundation/t/delegate-application-template/31). Although delegate applications aren't required now that the airdrop has occurred, the application template gives community members a standardized way to learn more about your qualifications and platform. 29 | 30 | Becoming a delegate is a significant responsibility and should not be taken lightly. Delegates should have a solid foundational technical understanding of the Arbitrum protocol, a sense of the Ethereum ecosystem at large, and a desire to continuously engage with the Arbitrum community as it grows and evolves. If you have any questions or concerns, visit the [Arbitrum DAO governance forum](https://forum.arbitrum.foundation/) or [Discord](https://www.discord.gg/arbitrum). 31 | 32 | [^1]: To learn how to delegate the voting power of your $ARB tokens, visit ["How to delegate your voting power"](./select-delegate-voting-power.md). 33 | -------------------------------------------------------------------------------- /docs/how-tos/build-strong-delegate-platform.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: build-strong-delegate-platform 3 | title: How to build a strong delegate platform 4 | sidebar_label: Build a delegate platform 5 | description: Learn how to build a strong delegate platform as a delegate of the Arbitrum DAO. 6 | dao_author: symbolpunk 7 | dao_sme: amarrazza 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | As a delegate of the Arbitrum DAO, you play a vital role in the governance and decision-making process used to govern both the DAO's protocol and its technologies. Your role is to represent the interests of token holders who have delegated their voting power to you, and to make informed decisions on their behalf. Whether you're a first-time delegate or a seasoned pro, building a strong delegate platform that's aligned with the interests and values of Ethereum at large is of critical importance. The following tips will help you build a strong, incentives-aligned delegate platform: 15 | 16 | 17 | ### Tip 1: Understand the Constitution 18 | 19 | The first step in building a strong delegate platform is to develop a thorough understanding of [The Constitution of the Arbitrum DAO](../dao-constitution). The Constitution outlines the governance structure of the DAO, including the roles and responsibilities of delegates, as well as the decision-making process. Review the [comprehension check](../dao-comprehension-check.md) to test your knowledge of the Constitution. 20 | 21 | ### Tip 2: Communicate with token holders 22 | 23 | As a delegate, it's important to maintain an open and transparent line of communication with the token holders you represent. This can include creating a website or social media presence where you can provide updates on your activities, answer questions, and solicit feedback. Ensure that your voters are informed of any important developments or changes related to the DAO by staying tuned in to the [Arbitrum DAO governance forum](https://forum.arbitrum.foundation/) and [Discord](https://www.discord.gg/arbitrum). Continuously relaying important information to the token holders that you represent can help you build trust and credibility while positioning yourself as a valuable representative of the Arbitrum DAO community. 24 | 25 | ### Tip 3: Stay active in the community 26 | 27 | Another key aspect of building a strong delegate platform is staying active in the community. This can include participating in discussions on the [Arbitrum DAO governance forum](https://forum.arbitrum.foundation/), attending community events, participating in online discussions wherever relevant conversations are happening on social media, and contributing to the development of the DAO. 28 | 29 | ### Tip 4: Be transparent and accountable 30 | 31 | Transparency and accountability are crucial for building a strong delegate platform. As a delegate, you have a responsibility to be transparent about your motivations and decisions, and to be accountable to the token holders you represent. This can include being open to feedback and criticism and being willing to answer questions and address concerns. 32 | 33 | ### Tip 5: Build a strong support system 34 | 35 | Building a strong support system is essential for success as a delegate. This can include building relationships with key members of the community and developing a team to assist you with research, analysis, and decision-making. A strong support system can help you stay informed, make better decisions, and build a more effective delegate platform. 36 | 37 | ### Tip 6: Subit a delegate statement 38 | 39 | Submit a delegate statement using the template posted in the [delegate application template thread](https://forum.arbitrum.foundation/t/delegate-statement-template). Although delegate applications aren't required, the application template gives community members a standardized way to learn more about your qualifications and platform. 40 | 41 | ### Conclusion 42 | 43 | As a delegate, you play a vital role in the governance and decision-making process of the DAO; a strong platform can help you be more effective in that role. Remember to stay informed, be transparent and accountable, and build a strong support system. And always try to stay in touch with your voters so you can meet their needs. If you have any questions or concerns, visit the [Arbitrum DAO governance forum](https://forum.arbitrum.foundation/) or [Discord](https://www.discord.gg/arbitrum). -------------------------------------------------------------------------------- /docs/how-tos/create-submit-dao-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: create-submit-dao-proposal 3 | title: How to submit a DAO proposal 4 | sidebar_label: Submit a DAO proposal 5 | description: Learn how to submit a proposal to the Arbitrum DAO's governance forum by using Snapshot to conduct a temperature check, and then Tally to facilitate an on-chain vote. 6 | dao_author: amarrazza 7 | dao_sme: amarrazza 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | In this how-to, you'll learn how to submit an Arbitrum Improvement Proposal (AIP) to the Arbitrum DAO. Familiarity with Arbitrum, DAOs, and Ethereum is expected. Otherwise, this how-to makes no assumptions about your experience with governance protocols. 15 | 16 | ### Prerequisites 17 | 18 | To submit a temperature check using a Snapshot poll, you must have an Ethereum wallet address with 500,000 votable tokens[^1]; to submit a proposal on-chain using [Tally](https://tally.xyz/gov/arbitrum), you must have an Ethereum wallet address that represents at least 1,000,000 votable tokens. 19 | 20 | If you don't have enough voting power, consider delegating your votes to a delegate who can create a proposal on your behalf[^2]. 21 | 22 | ### Proposal types 23 | 24 | There are two types of AIPs: Constitutional and non-Constitutional: 25 | 26 | - **Constitutional AIPs** are those that modify the text or procedures of the Constitution or AIP-1, install or modify software on any chain, or take any action that requires "chain owner" permission on any chain. 27 | - **Non-Constitutional AIPs** are all other AIPs, such as those that request funds/grants or provide general guidelines or information to the community. 28 | 29 | See [Constitution](../dao-constitution.md) for further details. 30 | 31 | ### Proposal structure 32 | 33 | import AnatomyAIPPartial from '@site/docs/partials/_anatomy-aip-partial.md'; 34 | 35 | 36 | 37 | ### Pre-proposal development 38 | 39 | Proposals that require code changes should include the code that will be executed when the proposal is passed. This code should handle the data structures, logic, executable data, and execution of the proposal. Refer to [Governance Proposal Lifecycle: Example](https://github.com/ArbitrumFoundation/governance/blob/main/docs/proposal_lifecycle_example.md) for an example. 40 | 41 | ### Step 1: Conduct a formal temperature check with a Snapshot poll 42 | 43 | The [DAO governance forum](https://forum.arbitrum.foundation/) facilitates discussions about Arbitrum DAO and governance proposals that are submitted by eligible token delegates. To submit your proposal: 44 | 45 | 1. Go to the [DAO governance forum](https://forum.arbitrum.foundation/). 46 | 2. Create a new post with your proposal using the template located [here](./create-submit-dao-proposal#proposal-structure). You can add additional fields to this template to provide more context for your proposal if you'd like. 47 | 3. Whenever you're ready, navigate to [Snapshot](https://snapshot.org/#/arbitrumfoundation.eth) to create a poll that will gauge the community's interest in your proposal. 48 | 1. Connect your wallet. 49 | 2. Open the Arbitrum DAO [Snapshot space](https://snapshot.org/#/arbitrumfoundation.eth) if it isn't already open. 50 | 3. Create a poll that points to your forum post. The poll should run for one week and should be decided by a simple majority. 51 | 4. Navigate back to your forum post and share the link to your Snapshot poll with the community. 52 | 4. Allow at least one week for discussion and debate. Iterate on your proposal based on feedback from the community. 53 | 54 | If your proposal doesn't pass the temperature check, you shouldn't submit it for an on-chain vote. Instead, head back to your forum post and engage with the community to address any concerns that they have. 55 | 56 | If your proposal passes the temperature check, then you can move to the second and final step: an on-chain vote facilitated by Tally. Ensure that you've incorporated feedback brought up during relevant forum discussions and temperature checks before proceeding. 57 | 58 | ### Step 2: Submit your on-chain proposal using Tally 59 | 60 | If your wallet can represent at least 1,000,000 tokens, you can create an on-chain proposal using [Tally](https://tally.xyz/gov/arbitrum). 61 | 62 | To submit your proposal on Tally: 63 | 64 | 1. Log in to [Tally](https://tally.xyz/gov/arbitrum) using the wallet that represents the $ARB tokens. 65 | 2. Navigate to the "explore DAOs" section or click on "My DAOs" within your Tally profile and select Arbitrum DAO's page. 66 | 3. Select "Create new proposal" 67 | 4. Choose which governor you are targeting: 68 | - **Arbitrum Core**: For Constitutional Proposals 69 | - **Arbitrum Treasury**: For non-Constitutional Proposals 70 | 5. Give the proposal a name and description (preview image is optional). Ensure that you’re submitting the correct type of proposal to the right DAO page in Tally. 71 | 6. Add proposal actions to be executed if passed. For example, "transfer n ETH to 0x address". 72 | 7. Preview your proposal and either save as a draft or submit on-chain. 73 | 74 | A proposal passes if two conditions are met: 75 | 76 | 1. More votes are cast in favor than against 77 | 2. The total number of votes cast in favor is at least the following percentage of the votable tokens: 78 | 1. **5%**, for a Constitutional AIP 79 | 2. **3%**, for a non-Constitutional AIP 80 | 81 | If the proposal passes, congratulations! After a delay, the proposal’s actions will be executed on-chain[^3]. 82 | 83 | If the proposal doesn’t pass, but there's interest in improving and resubmitting it, refer to [How to resubmit your proposal](./resubmit-dao-proposal). 84 | 85 | This protocol is in its early days and will likely evolve in response to your feedback. If you have any questions or concerns, visit the [Arbitrum DAO governance forum](https://forum.arbitrum.foundation/) or [Discord](https://www.discord.gg/arbitrum). 86 | 87 | Welcome to the future of governance! 88 | 89 | 90 | #### Important notes 91 | 92 | 1. The Security Council has the power to execute emergency actions and non-emergency actions, as delegated to it by the Constitution. These are unlike traditional AIPs in that they can be approved by the Security Council without going through the above process. See the [Security Council](../concepts/security-council) page for more information. 93 | 2. The threshold of support required for a proposal to pass can vary depending on the type of proposal and the quorum requirements specified in the Constitution. 94 | 3. You can delegate your voting power[^2] to another address whether or not you have enough tokens to submit on-chain proposals. If you hold any $ARB tokens whatsoever, you can participate in Arbitrum DAO's governance. 95 | 96 | 97 | [^1]: When we say "an Ethereum wallet address with at least 500,000 votable tokens", we mean that 500,000 or more tokens are delegated to this address. You can delegate the tokens to your own address and other $ARB token holders can delegate to you. 98 | [^2]: Learn how to delegate your votes by visiting [How to delegate your voting power](./select-delegate-voting-power). 99 | [^3]: Refer to [The Constitution of the Arbitrum DAO](../dao-constitution) for additional details and conditions. 100 | -------------------------------------------------------------------------------- /docs/how-tos/resubmit-dao-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: resubmit-dao-proposal 3 | title: How to resubmit a DAO proposal 4 | sidebar_label: Resubmit a proposal 5 | description: Learn how to resubmit a proposal to the Arbitrum DAO that was previously rejected or did not reach quorum. 6 | dao_author: symbolpunk 7 | dao_sme: amarrazza 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | In this how-to, you'll learn how to resubmit a proposal to the Arbitrum DAO that was previously rejected or did not reach quorum. 15 | 16 | ### Step 1: Review the feedback from the previous proposal 17 | 18 | Review the feedback from the previous proposal and try to identify any common concerns or objections that were raised by the community. Align with the community on the best way to address these concerns and incorporate them into your proposal. 19 | 20 | ### Step 2: Draft a revision 21 | 22 | Incorporate the community's feedback into a revised proposal. Consider using your original proposal's forum thread to draft this revision. Ensure that you incorporate any new information that may have become available since the original proposal was submitted. 23 | 24 | ### Step 3: Resubmit the proposal 25 | 26 | Treat your revised proposal as a brand new proposal. Begin by conducting a new temperature check on the governance forum by following the [Submit a proposal](./create-submit-dao-proposal.md) procedure. Pay close attention to the guidance within the proposal structure section of this procedure; you'll want to include additional information that explicitly addresses the concerns that were raised during the previous submission. 27 | 28 | If your proposal is rejected multiple times, it may be best to reconsider the proposal altogether or to engage more extensively with the community to gather feedback and build support. 29 | 30 | Resubmitting a proposal is an iterative process that requires patience, persistence, and an open mind. By working closely with the community to capture and integrate feedback, you can increase your chances of getting your proposal passed. If you have any questions or concerns, visit the [Arbitrum DAO governance forum](https://forum.arbitrum.foundation/) or [Discord](https://www.discord.gg/arbitrum). -------------------------------------------------------------------------------- /docs/how-tos/select-delegate-voting-power.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: select-delegate-voting-power 3 | title: "How to delegate your voting power: A guide for $ARB token holders" 4 | sidebar_label: Delegate your voting power 5 | description: Learn how to delegate your voting power to a values-aligned Arbitrum DAO delegate. 6 | dao_author: symbolpunk 7 | dao_sme: amarrazza 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | Delegating your voting power is an essential part of participating in the Arbitrum DAO. As a token holder, you have the ability to vote on governance proposals and to elect members of the Security Council. 15 | 16 | If you don't have the time or resources to actively participate in the DAO's governance, you can still make your voice heard by delegating your voting power to a delegate. This how-to will walk you through the process of evaluating and selecting a delegate. 17 | 18 | ### Delegate your voting power on Tally 19 | 20 | 21 | :::info Looking for the Tally link? 22 | 23 | If you're familiar with the process of using Tally to delegate, visit the Arbitrum delegation page on [Tally](https://www.tally.xyz/gov/arbitrum/delegates). Otherwise, read on for a step-by-step guide. 24 | 25 | ::: 26 | 27 | Before you delegate your voting power, it's important to understand that by delegating your voting power, you're entrusting someone else to vote on your behalf. So it's really important to choose a delegate who aligns with your values and who you trust to make decisions in the best interest of the Arbitrum DAO and its community. 28 | 29 | To delegate your voting power, you'll need an Ethereum wallet that holds $ARB tokens, such as MetaMask. Once you have your wallet set up, you can follow these steps: 30 | 31 | 1. Go to the Arbitrum DAO page on [Tally](https://tally.xyz/gov/arbitrum), the decentralized governance tool that the Arbitrum DAO uses. 32 | 2. Connect your wallet to Tally by clicking on "Connect Wallet" and selecting the address that holds your $ARB tokens. 33 | 3. Click on the "Delegate" tab on the top menu. 34 | 4. Search for the delegate you want to vote for by typing their Ethereum address or their name in the search bar. 35 | 5. Click on the "Delegate" button next to the delegate you've chosen. 36 | 6. Confirm the delegation by clicking on the "Delegate" button on the pop-up window that appears. 37 | 7. Wait for the transaction to be confirmed on the Arbitrum One network. 38 | 39 | Once your transaction is confirmed, your voting power will be transferred to the delegate you've chosen. You can also check your delegation by going to the "Votes" tab on Tally and looking for the delegate you've chosen. 40 | 41 | When selecting a delegate, it's important to consider the following: 42 | 43 | - The delegate's values, as outlined in the [Constitution](../dao-constitution.md) and their position on the proposals. 44 | - The delegate's track record, if they have one. 45 | - The delegate's level of engagement with the community and their willingness to listen and respond to feedback. 46 | - The delegate's level of technical expertise and their experience in the space. 47 | 48 | By following these steps and considering these factors, you can ensure that you're delegating your voting power to a trustworthy and competent delegate who will work to further the goals of the Arbitrum DAO and its community. If you have any questions or concerns, visit the [Arbitrum DAO governance forum](https://forum.arbitrum.foundation/) or [Discord](https://www.discord.gg/arbitrum). 49 | -------------------------------------------------------------------------------- /docs/how-tos/vote-dao-proposals.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: vote-dao-proposals 3 | title: How to vote on Arbitrum DAO governance proposals 4 | sidebar_label: Vote on proposals 5 | description: Learn how to vote on Arbitrum DAO governance proposals. 6 | dao_author: symbolpunk 7 | dao_sme: amarrazza 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | As a member of the Arbitrum DAO, it's important to be an active participant in the DAO's decision-making process by voting on governance proposals that other DAO members submit. The voting process can vary depending on the given proposal's stage; in this how-to, you'll learn how to locate, evaluate, and vote on proposals at each of the possible stages. 15 | 16 | ### Proposals in the "temperature check" stage 17 | 18 | Proposals are first submitted to the [Arbitrum DAO governance forum](https://forum.arbitrum.foundation/) for community discussion and debate. These forum submissions are usually accompanied by a Snapshot poll that gauges the community's interest in the proposal. As an $ARB token holder (or delegate) you can participate in these Snapshot polls and "temperature check" discussions: 19 | 20 | 1. Go to the [DAO governance forum](https://forum.arbitrum.foundation/). 21 | 2. Locate the proposal you'd like to vote on and read through the proposal and the discussion thread. 22 | 3. Provide feedback and participate in the discussion to help shape the proposal. 23 | 24 | The forum submission for any given proposal will usually include a link to a Snapshot poll that allows you to vote on the proposal: 25 | 26 | 1. Navigate to [Snapshot](https://snapshot.org/#/arbitrumfoundation.eth). 27 | 2. Connect your wallet. 28 | 3. Open the [Arbitrum DAO Snapshot space](https://snapshot.org/#/arbitrumfoundation.eth) and locate the proposal you'd like to vote on (or click the Snapshot link in the forum submission). 29 | 4. Cast your vote by following the prompts within Snapshot's UI. 30 | 31 | ### Proposals in the "on-chain vote" stage 32 | 33 | If the proposal passes the temperature check, it will move on to an on-chain vote facilitated by [Tally](https://tally.xyz/gov/arbitrum). To pass this stage, the proposal must meet two thresholds: 34 | 35 | 1. The proposal must receive more votes in favor than against; and 36 | 2. Constitutional AIPs must receive votes from at least 5% of votable tokens; non-Constitutional AIPs must receive votes from at least 3% of votable tokens. 37 | 38 | To vote on proposals in the "on-chain vote" stage: 39 | 40 | 1. Log in to [Tally](https://tally.xyz/gov/arbitrum) using a wallet that has been delegated voting power. $ARB tokens must be delegated to the wallet address before the voting period beings to vote on the proposal. 41 | 2. Navigate to the "explore DAOs" section or click on "My DAOs" within your Tally profile and select the page for either Constitutional or non-Constitutional AIPs. 42 | 3. Locate the proposal you'd like to vote on and cast your vote. 43 | 44 | 45 | ### On proposal evaluation 46 | 47 | It's important to evaluate proposals based on their alignment with the values and goals of the Arbitrum DAO as outlined in the [Constitution](../dao-constitution.md). Remember that the ultimate goal of the DAO is to create a decentralized and transparent platform that benefits all members, including those who aren't yet members. 48 | 49 | 50 | ### On delegation 51 | 52 | You can grant your voting power to a delegate if you don't have the time to actively participate in the governance process. If you decide to delegate your voting power to someone else, be sure to select a delegate who demonstrates the values enshrined within the [Constitution](../dao-constitution). If you're looking for guidance on how to delegate, or how to select a delegate, refer to [How to delegate your voting power](./select-delegate-voting-power). 53 | 54 | 55 | ### Conclusion 56 | 57 | This system is in its early days and will likely evolve in response to feedback from readers like you. Changes made to this process will be facilitated through proposals that follow the procedure outlined in the [Constitution](../dao-constitution.md). To learn more about proposals or the voting process, refer to the [Constitution](../dao-constitution.md) and the other documents within this content set. If you have any questions or concerns, visit the [Arbitrum DAO governance forum](https://forum.arbitrum.foundation/) or [Discord](https://www.discord.gg/arbitrum). 58 | -------------------------------------------------------------------------------- /docs/network-upgrades.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: network-upgrades 3 | title: Network upgrades 4 | sidebar_label: Network upgrades 5 | --- 6 | 7 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 8 | 9 | 10 | 11 | 12 | 13 | This page has information on the state and timelines of major software updates to Arbitrum One and Arbitrum Nova. Software updates that alter an Arbitrum chain's ability to produce valid Arbitrum blocks are referred to as ArbOS upgrades and, as outlined in the [Arbitrum DAO Constitution](./dao-constitution.md), will always require a Constiutional AIP to pass for DAO-governed chains. 14 | 15 | Visit [Inside Arbitrum Nitro](https://docs.arbitrum.io/inside-arbitrum-nitro/) to learn more about Nitro's architecture; more information about ArbOS software releases is available on the [Arbitrum DAO forum](https://forum.arbitrum.foundation/t/arbitrum-arbos-upgrades/19695) as well as in the documentation for the [overview of ArbOS software releases](https://docs.arbitrum.io/node-running/reference/arbos-software-releases/overview). 16 | 17 | ## Network activation statuses 18 | 19 | | Upgrade | Governance Approval Status | Link to most recent governance stage | Arbitrum Sepolia (YYYY-MM-DD) | Arbitrum One (YYYY-MM-DD) | Arbitrum Nova (YYYY-MM-DD) | 20 | |-----------------|----------------------------|--------------------------------------------------|----------------------------------|---------------------------|-------------------------------------| 21 | | [ArbOS 40 Callisto](https://docs.arbitrum.io/node-running/reference/arbos-software-releases/arbos40) | Approved but pending on-chain execution | [Snapshot vote](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x7cc26491a070c74c1a4ec5a9892571d31eb690015936a35b52c0d3a97bd5497f) | [Mon, 2025-05-06 at 02:54:45 PM UTC](https://sepolia.arbiscan.io/tx/0xce8d716391583d10e6c7b27d17118b9e2845cbb44321b466adff1b9168603a40) | Tues, 2025-06-17 4:00:00 PM UTC | Tues, 2025-06-17 4:00:00 PM UTC | 22 | | [Arbitrum BoLD](https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction) | Approved & executed | [On-chain Tally vote](https://www.tally.xyz/gov/arbitrum/proposal/101924107818180443784046677916233531742645798596604549673138282938475874935972?govId=eip155:42161:0xf07DeD9dC292157749B6Fd268E37DF6EA38395B9) | [Weds, 2024-12-11 06:21:36 PM UTC](https://sepolia.etherscan.io/tx/0x84950b761493e33b792986b66201401fce921cc75ad2e1811fea3f2644a27b99) | [Wed, 2025-02-12 02:00:11 PM UTC](https://etherscan.io/tx/0xe9788a104f8443b5900e54f8c887f0522d121487fc343a1ff90e1e6ed987967e) | [Wed, 2025-02-12 02:00:11 PM UTC](https://etherscan.io/tx/0xe9788a104f8443b5900e54f8c887f0522d121487fc343a1ff90e1e6ed987967e) | 23 | | [ArbOS 32 Bianca](https://docs.arbitrum.io/run-arbitrum-node/arbos-releases/arbos32) | Approved & executed by the Arbitrum Security Council | N/A | [Weds, 2024-09-25 at 02:06:01 UTC](https://sepolia.arbiscan.io/tx/0x180d29cc945cbedbb7076d721560cecbde71cda9b61a1614535f88e712dce692) | [Weds, 2024-09-25 at 02:37:30 UTC](https://arbiscan.io/tx/0x28f3ae9002bd49f4bbcb6ffa48b2e8f30692f7fdf0b9d84e4c2a4e0b75d732e8) | [Weds, 2024-09-25 at 02:26:11 UTC](https://nova.arbiscan.io/tx/0x77224d12d0154bf971094202a5e24cbc21b7e8f1bef2d716098e9fc9b34202b7) | 24 | | ArbOS 31 Bianca | Approved & executed | [On-chain Tally vote](https://www.tally.xyz/gov/arbitrum/proposal/108288822474129076868455956066667369439381709547570289793612729242368710728616) | Mon, 2024-06-17 at 17:00:00 UTC | Tues, 2024-09-03 at 17:00:00 UTC | Tues, 2024-09-03 at 17:00:00 UTC | 25 | | [ArbOS 20 Atlas](https://docs.arbitrum.io/node-running/reference/arbos-software-releases/arbos20) | Approved & executed | [On-chain Tally vote](https://www.tally.xyz/gov/arbitrum/proposal/46905320292877192134536823079608810426433248493109520384601548724615383601450?chart=bubble) | Thu, 2024-02-29 at 18:00:00 UTC | Thu, 2024-03-14 01:48:09 PM UTC | Thu, 2024-03-14 01:48:09 PM UTC | 26 | | [ArbOS 11](https://docs.arbitrum.io/node-running/reference/arbos-software-releases/arbos11) | Approved & executed | [On-chain Tally vote](https://www.tally.xyz/gov/arbitrum/proposal/77069694702187027448745871790562515795432836429094222862498991082283032976814) | Tues, 2024-01-30 at 17:00:00 UTC | Thu, 2024-02-24 at 20:01:13 UTC | Thu, 2024-02-24 at 20:01:13 UTC | 27 | 28 | 29 | 30 | ### Stay up to date 31 | To stay up to date with proposals, timelines, and statuses of network upgrades to Arbitrum One and Nova: 32 | - Subscribe to the [Arbitrum Node Upgrade Announcement channel](https://t.me/arbitrumnodeupgrade) on Telegram 33 | - Join both the `#dev-announcements` and `#node-runners` Discord channels in the [Arbitrum Discord server](https://discord.gg/arbitrum) 34 | - Follow the official Arbitrum ([`@Arbitrum`](https://twitter.com/arbitrum)) and Arbitrum Developers ([`@ArbitrumDevs`](https://twitter.com/ArbitrumDevs)) _X_ accounts, formerly Twitter. 35 | -------------------------------------------------------------------------------- /docs/new-arb-chains.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: new-arb-chains 3 | title: 'Creating new Arbitrum chains' 4 | sidebar_label: Creating new Arbitrum chains 5 | description: Understanding how and why new Arbitrum chains will be created 6 | dao_author: dzgoldman 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | Rollup is the new server. 15 | 16 | In line with the rollup-centric roadmap of Ethereum, we anticipate the emergence of hundreds and thousands of rollups, dedicated to protecting users and their assets when interacting with an online service. 17 | 18 | The following section covers the basics on Arbitrum Orbit and the Arbitrum Expansion program, that enables projects to easily adopt the Arbitrum technology stack when deploying their own chain. 19 | 20 | ## Arbitrum Orbit 21 | 22 | Arbitrum Orbit represents our strategy for enabling projects seeking to adopt the Arbitrum technology stack when deciding to deploy their own chain. 23 | 24 | There are many reasons why a project will decide to launch their chain using Arbitrum Orbit: 25 | 26 | - **Dedicated blockspace.** Gain independence from chain usage by other applications. 27 | - **Custom gas token.** Choose which token is used for chain fees allowing you to create native economies and utility incentives. 28 | - **Low latency.** Orbit chains have demonstrated the ability to sustain ~100ms block times. 29 | - **Data availability layer choices.** AnyTrust, Celestia, and more data availability solutions are already integrated into Arbiturm Orbit. 30 | - **No governance constraints.** Control your own destiny; no need to submit to shared governance. 31 | - **Stage 1 rollup.** External validation that the Arbitrum technology stack is amongst the best of all rollup implementations. 32 | 33 | In fact, Arbitrum One and Arbitrum Nova, can be considered the first Orbit Chains, to demonstrate the capability of the technology. The proven track record of the technology has led to an explosion of projects adopting the technology stack. 34 | 35 | To learn more, please visit the [Arbitrum Orbit website which includes developer documentation.](https://arbitrum.io/orbit) 36 | 37 | 38 | ## Arbitrum Expansion Program (AEP) 39 | The Arbitrum Foundation, in consultation with the ArbitrumDAO [[1](https://forum.arbitrum.foundation/t/request-for-feedback-when-and-how-should-the-arbitrum-foundation-issue-a-licence-for-the-arbitrum-technology-stack-to-a-new-strategic-partner/15758),[2](https://forum.arbitrum.foundation/t/the-arbitrum-expansion-program-and-developer-guild/20722),[3](https://forum.arbitrum.foundation/t/temperature-check-change-arbitrum-expansion-program-to-allow-deployments-of-new-orbit-chains-on-any-blockchain/23280)], put together the Arbitrum Expansion Program to help enable projects to deploy and operate their own chain using the Arbitrum technology stack. 40 | 41 | The [Arbitrum Expansion Program](https://docs.arbitrum.foundation/aep/ArbitrumExpansionProgramTerms.pdf) is designed to be a self-service path for any project seeking to adopt the Arbitrum Technology stack. It allows the project to fork the code and modify it according to their business needs alongside to deploy on any blockchain network. In return, the project is required to pay 10% of their chain’s profit back to the ArbitrumDAO with 8% distributed to the ArbitrumDAO’s treasury and 2% to a Arbitrum Protocol Developer guild. 42 | 43 | Our program is designed with the following spirit in mind: 44 | 45 | - **Permissionless.** Any project can deploy a chain using the Arbitrum technology stack as long as they agree to opt-in to the Arbitrum Expansion Program. There is no need to contact the Arbitrum Foundation. 46 | - **Deploy on any chain.** Projects are allowed to deploy an Orbit Chain on any blockchain network including Ethereum, Bitcoin, other L2s, etc. 47 | - **Modify & fork.** Projects can modify the Arbitrum technology stack to suit their business needs. 48 | - **Value accrual.** Support the Arbitrum ecosystem by sending a portion of the chain’s revenue back to the ArbitrumDAO and the Arbitrum Developer guild. 49 | - **Community enablement.** Additional community-run features, alongside the software license, that will act as a supportive cornerstone for projects that adopt the Arbitrum technology stack. 50 | - **Freedom to innovate.** There is no limitation on how a chain governs itself such as a requirement to submit to shared governance or other similar constraining structures. 51 | 52 | Put another way, you are free to adopt the Arbitrum technology stack, deploy your chain, expand the Ethereum ecosystem, and ultimately serve your users. In regards to the fee collection, we will update our documentation will further information shortly. 53 | 54 | -------------------------------------------------------------------------------- /docs/partials/_anatomy-aip-partial.md: -------------------------------------------------------------------------------- 1 | The Constitution of the Arbitrum DAO encourages proposers to include the following sections within Arbitrum Improvement Proposals: 2 | 3 | - **Abstract** - Two or three sentences that summarize the AIP. 4 | - **Motivation** - A statement on why the Arbitrum community should implement the AIP. 5 | - **Rationale** - An explanation of how the AIP aligns with the Arbitrum community's mission and guiding values. 6 | - **Key Terms** - Definitions of any terms within the proposal that are unique to the proposal, new to the Arbitrum community, and/or industry-specific. This section is optional, but recommended. 7 | - **Specifications** - A detailed breakdown of the platforms and technologies that will be used. This is where you can elaborate on the "why" of your design decisions. You can also use this section to describe alternate designs that were considered and related work, e.g. how similar specifications have been successfully (or unsuccessfully) implemented in other chains or languages. 8 | - **Steps to Implement** - The steps to implement the AIP, including associated costs, manpower, and other resources for each step where applicable. AIPs that involve transactions with third parties (such as grants) will need to ensure that applicable legal documentation and procedures are also included. 9 | - **Timeline** - Relevant timing details, including but not limited to start date, milestones, and completion dates. 10 | - **Overall Cost** - The total cost to implement the AIP. The overall cost section should include a breakdown of the total cost of the AIP, including any associated costs for each step where applicable. Consider both fixed costs and recurring costs. 11 | 12 | Sometimes, AIPs aren't passed on the first try. If an AIP is not passed, the proposer may resubmit the AIP after addressing the concerns of the community. The proposer should include the following additional sections in the resubmitted AIP: 13 | 14 | - **A link to the previous AIP** - The link to the previous AIP should be included in the resubmitted AIP. 15 | - **Reasons why the AIP was not passed** - The reasons why the AIP was not passed should be included in the resubmitted AIP. 16 | - **Changes made to the AIP** - The changes made to the AIP should be included to address the concerns raised during the previous AIP submission. 17 | - **Additional information** - More detailed intentions, specifics and implication details can help the community understand the revised AIP, increasing the chances of it being passed. 18 | -------------------------------------------------------------------------------- /docs/partials/_draft-expectations-partial.md: -------------------------------------------------------------------------------- 1 | :::info PUBLIC PREVIEW DOCUMENT 2 | 3 | This document is currently in **public preview** and may change significantly as feedback is captured from readers like you. Click the *Request an update* button at the top of this document or [join the Arbitrum Discord](https://discord.gg/arbitrum) to share your feedback. 4 | 5 | ::: -------------------------------------------------------------------------------- /docs/security-council-members.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: security-council-members 3 | title: 'Security Council Members' 4 | sidebar_label: Security Council Members 5 | description: Current members of the security council 6 | dao_author: dzgoldman 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | The following are the current members of the Security Council; for information about the Security Council, see ["Security Council Overview"](./concepts/security-council). 11 | 12 | i. September Cohort 13 | 14 | 1. [gzeon](https://x.com/gzeon) is an experienced smart-contract developer at OffchainLabs. 15 | - `0xe2e9d5B97d8C0457B1cf80BC93802bce4DF03e33` 16 | 2. [John Morrow](https://x.com/jmo_mx) worked in DeFi for the past 5 years, published peer-reviewed research on DeFi risks and is co-founder at Gauntlet. 17 | - `0x78bb97d2f3811256d7f0041e81aaf4b426ef3b67` 18 | 3. [Emiliano Bonassi](https://x.com/emilianobonassi) is the Rollup Product Lead at Conduit RaaS. 19 | - `0x33ddb82e68940f0e4C1050885BcE8faF5Ddd1b93` 20 | 4. [Immunefi](https://x.com/immunefi) is a bug-bounty platform. 21 | - `0x9A301de96b15Db3aB778E2969Bf6cAa909cA56E8` 22 | 5. [Dennison Bertram](https://x.com/DennisonBertram) is the CEO of Tally, a governance service provider and an early team member at OpenZeppelin, a smart contract security firm. 23 | - `0x59c8535419bbcb8adffdb3c835435e907e3b183b` 24 | 6. [Griff Green](https://x.com/thegrifft) is the founder of Giveth and a member of the White Hat Group that responded to the TheDAO hack. 25 | - `0x882c6FCb3D358b9d70B97c6999159cea64168B6F` 26 | 27 | ii. March Cohort 28 | 29 | 1. [Bartek Kiepuszewski](https://twitter.com/bkiepuszewski) has been a blockchain architect at MakerDAO since 2017. He also co-founded [l2beat.com](http://l2beat.com/) and TokenFlow Insights. Bartek holds a PhD in computer science from Queensland University of Technology. 30 | - `0x0275b3d54a5ddbf8205a75984796efe8b7357bae` 31 | 2. [Michael Lewellen](https://x.com/LewellenMichael) has security expertise in smart contracts, governance and incident response, and is currently the Head of Solutions Engineering at Blockaid. They co-authored the Security Council Best Practices guide and managed high-profile audits during his time at OpenZeppelin, and continues to develop Web3 security standards. 32 | - `0xBBD2E01eFB88ce00F8f5b6B9a696966070089392` 33 | 3. [Yoav Weiss](https://twitter.com/yoavw) is a security researcher at the Ethereum Foundation and has been building in the Ethereum space since 2017, working on account abstraction (ERC-4337), OpenGSN, L2 security, etc. Yoav brings over 25 years of experience and has developed security technologies used by industry leading companies. 34 | - `0x475816ca2a31D601B4e336f5c2418A67978aBf09` 35 | 4. [fred](https://twitter.com/0x66726564) is the former Tech Lead at both Offchain Labs and the Arbitrum Foundation and cares about the long-term success and security of the Arbitrum ecosystem. They have read the entire Arbitrum codebase multiple times, written significant parts of it, and has worked on countless engagements (i.e. audits) with security professionals across the industry. 36 | - `0xD8D4cEC103c0B6d7166405F0EbD7087C75a1528E` 37 | 5. [Certora](https://twitter.com/CertoraInc) are experts in smart contract formal verification and have formally verified the EVM bytecode of a range of applications for whom security is paramount, Certora is motivated to contribute to developing safe digital and financial infrastructure built on Arbitrum. Organization represented by Elad Erdheim. 38 | - `0xeEe3Fb3B792C7DDbB6aEF0C440FBC621f4d6fe2D` 39 | 6. [OpenZeppelin](https://twitter.com/OpenZeppelin)'s mission is to secure the decentralized web. By combining their vast experience across DAOs and protocols, comprehensive security solutions, and a community-first approach, OpenZeppelin is uniquely positioned to contribute significantly to Arbitrum's security and governance. Organization represented by Steven Thornton. 40 | - `0x9316ca66f5f936E3239e4fD2AAAEA5C7b6f3C4cC` 41 | -------------------------------------------------------------------------------- /docs/state-of-progressive-decentralization.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: state-of-progressive-decentralization 3 | title: The state of Arbitrum's progressive decentralization 4 | sidebar_label: State of decentralization 5 | description: Learn about the state of Arbitrum's progressive decentralization. 6 | dao_author: dzgoldman 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/\_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | Progressive decentralization is the process of gradually increasing the decentralization of a system over time. This document details the current state of progressive decentralization for the Arbitrum One and Arbitrum Nova chains, the two chains currently governed by the Arbitrum DAO. 15 | 16 | ### The components of Arbitrum's progressive decentralization 17 | 18 | The following components determine the degree of decentralization for Arbitrum One and Arbitrum Nova: 19 | 20 | 1. [**Chain ownership**](#1-chain-ownership) 21 | 2. [**Validation decentralization status**](#2-validation-decentralization-status) 22 | 3. [**Sequencer ownership**](#3-sequencer-ownership) 23 | 4. [**Data Availability Committee ownership**](#4-data-availability-committee-ownership) 24 | 25 | Let's evaluate the current status of these components for both Arbitrum One and Arbitrum Nova, beginning with chain ownership. 26 | 27 | ### 1. Chain ownership 28 | 29 | - **Description**: A chain's "owner" has the ability to change the protocol in various ways, including upgrading the core smart contracts, setting system parameters, and pausing the system. 30 | - **Current status**: **Governed by Arbitrum DAO**. Chain ownership of both Arbitrum One and Arbitrum Nova is under the control of the Arbitrum governance system. The Arbitrum Decentralized Autonomous Organization (DAO), made up of `$ARB` token-holders and delegates, can carry out chain-owner operations through governance votes. The Security Council can also carry out chain-owner operations; it can act quickly through a 9 of 12 multisig wallet, but only in critical emergency situations. The Security Council can also act slowly through a 9 of 12 multisig wallet in non-emergency situations to carry out routine and minor upgrades, such as minor bug fixes. The members of the Security Council (split by cohort) are elected every six months by the Arbitrum DAO. 31 | - **Risks**: 32 | - If 9 of the Security Council members are compromised or behave maliciously, the system and users' funds could be compromised. 33 | - If a malicious proposal is successfully put through DAO governance, or if 9 of the Security Council members are compromised or behave maliciously, the system's safety could be compromised. In either of these cases, users will have several weeks to withdraw their funds back to Ethereum before the proposal takes effect. 34 | - **Changes To Current Status**: The governance system currently has the ability to alter governance itself. 35 | 36 | ### 2. Validation decentralization status 37 | 38 | - **Description**: Validators are responsible for confirming the valid state of the Arbitrum chains back on L1. 39 | 40 | | Chain | Decentralization Status | Description | 41 | |------------------------|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 42 | | **Arbitrum One** | **Permissionless** | Validation on Arbitrum One now follows the BoLD protocol, any node implementing the BoLD protocol can join. You can learn more about BoLD in this [introduction to BoLD](https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction) | 43 | | **Arbitrum Nova** | **Permissioned** | Arbitrum Nova remains permissioned as its Data Availability committee is a trusted one | 44 | 45 | - **Risks**: If there is not a single honest active validator, and a malicious validator proposes an invalid state update, the system's safety could be compromised. 46 | 47 | ### 3. Sequencer ownership 48 | 49 | - **Description**: The Sequencer is typically responsible for collecting and ordering users' transactions. 50 | - **Current status**: **Centralized**. The Sequencers for both Arbitrum One and Arbitrum Nova are currently maintained by the Arbitrum Foundation. Governance currently has the power to select new Sequencers. 51 | - **Risks**: The Sequencer has the ability to delay the inclusion of a user's transaction by up to 24 hours and reorder transactions over short time-horizons. The Sequencer, however, cannot compromise the system's safety or prevent a transaction from ultimately being executed. 52 | - **Changes to Current status**: The Arbitrum governance system (see #1) currently has the power to elect a new entity as the Sequencer. 53 | 54 | ### 4. Data Availability Committee ownership 55 | 56 | DACs apply only to Arbitrum AnyTrust chains like Arbitrum Nova 57 | :::note 58 | 59 | This applies only to Arbitrum AnyTrust chains like Arbitrum Nova. 60 | 61 | ::: 62 | 63 | - **Description**: AnyTrust chains like Arbitrum Nova rely on a permissioned committee to store the chain's data and provide it on demand. 64 | - **Current status**: 6-member committee. The Arbitrum Nova chain has a 6-party DAC, whose members can be seen [here](#data-availability-committee-members). Governance has the ability to remove or add members to the committee. 65 | - **Risks**: If 5 of the 6 committee members in conjunction with the Sequencer behave maliciously and collude, the safety of the system can be compromised. 66 | - **Changes to Current status**: The Arbitrum governance system (see #1) currently has the power to change the DAC, such as by adding or removing members or modifying the power it has over the system. 67 | 68 | ### Data Availability Committee members 69 | 70 | These are the current members of the 5-of-6 [data availability committee (DAC)](#4-data-availability-committee-dac-ownership) in Arbitrum Nova: 71 | 72 | - ConsenSys Software Inc. 73 | - QuickNode, Inc. 74 | - P2P.org 75 | - Google Cloud 76 | - Offchain Labs, Inc. 77 | - Opensea Innovation Labs Private Limited 78 | -------------------------------------------------------------------------------- /docs/token-circulating-supply.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: token-supply 3 | title: What is the token circulating supply? 4 | sidebar_label: Token Circulating Supply 5 | description: Learn about the Arbitrum token circulating supply 6 | dao_author: fred 7 | dao_sme: wat-dis 8 | --- 9 | 10 | ### What is a tokens circulating supply 11 | 12 | A token's circulating supply is the amount of coins that are currently available to be transferred and utilized in the network. 13 | 14 | ### How can I calculate the Arbitrum token circulating supply 15 | 16 | The circulating supply is based on the [initial distribution](airdrop-eligibility-distribution#distribution-post-aips-11-and-12) and the [unlock schedule](airdrop-eligibility-distribution#vesting-and-lockup-details) of the team, investors, and contributors. 17 | You can calculate the Arbitrum token's current circulating supply with the following formula: 18 | 19 | The team, contributor, and investor tokens unlock over a 4 year period, starting from 16 March 2023. 20 | The first unlock starts on 16 March 2024, and continue to unlock on a monthly cadence. 21 | 22 | The Arbitrum Foundation tokens also unlock over a 4 year period, starting from 17 April 2023. 23 | The first unlock starts on 17 April 2023, and continue to unlock every second. 24 | 25 | 26 | ### What is the current circulating supply 27 | 28 | As of March 7 2024, the above formula results in 1.537 billion tokens total circulating supply. 29 | 30 | | Allocated to | Tokens Allocated | In circulation at March 7 2024| 31 | | ------------------------- | ---------------- | -------------- | 32 | | ArbitrumDAO Treasury [^1] | 3,528,000,000 | 126,131,267 | 33 | | Team and contributors | 2,694,000,000 | 0 | 34 | | Investors | 1,753,000,000 | 0 | 35 | | Users of platform (via airdrop) | 1,162,000,000 | 1,092,551,615 [^2] | 36 | | Arbitrum Foundation | 750,000,000 | 205,715,264 [^3] | 37 | | DAOs building on Arbitrum (via airdrop) | 113,000,000 | 113,000,000 | 38 | | | | | 39 | | Totals | 10,000,000,000 | 1,537,398,145 | 40 | 41 | _Note that numbers are rounded for presentation._ 42 | 43 | 44 | 45 | On March 17 2024 it is expected that following the above formula the total circulating supply will be 2.654 billion tokens. 46 | 47 | | Allocated to | Tokens Allocated | In circulation at March 17 2024 | 48 | | ------------------------- | ---------------- | -------------- | 49 | | ArbitrumDAO Treasury [^1] | 3,528,000,000 | 126,131,267 | 50 | | Team and contributors | 2,694,000,000 | 673,500,000 [^4] | 51 | | Investors | 1,753,000,000 | 438,250,000 [^4] | 52 | | Users of platform (via airdrop) | 1,162,000,000 | 1,092,551,615 [^2] | 53 | | Arbitrum Foundation | 750,000,000 | 210,506,502 [^3] | 54 | | DAOs building on Arbitrum (via airdrop) | 113,000,000 | 113,000,000 | 55 | | | | | 56 | | Totals | 10,000,000,000 | 2,653,939,384 | 57 | 58 | 59 | _Note that numbers are rounded for presentation._ 60 | 61 | [^1] The Arbitrum DAO treasury is calculated as of March 7 2024 and can be viewed in https://arbiscan.io/token/0x912ce59144191c1204e64559fe8253a0e49e6548?a=0xF3FC178157fb3c87548bAA86F9d24BA38E649B58. The DAO treasury's circulating supply is based on tokens deployed by the DAO delegates in governance proposals. 62 | 63 | [^2] Tokens that were not claimed during the airdrop period were sent to the DAO treasury. They are now part of the treasury but here they are presented as tokens in circulation in the User section, for the presentation to consisently show the amount of tokens deployed by the DAO delegates in governance proposals. 64 | 65 | [^3] The amount unlocked by the Arbitrum Foundation is based on the 700 million tokens in the vesting contract, plus the 50 million tokens that were initially distributed. 66 | 67 | [^4] The team, investor, and contributor tokens unlocked are calculated as the number seconds in a year divided by 12 from March 16 2024. 68 | 69 | _**Disclaimer:** The total circulating supply of tokens displayed is the best estimate as of March 17, 2024, based on publicly available information. It may not always reflect the actual circulating supply due to factors such as additional distributions from the ArbitrumDAO Treasury or the unlocking of vesting contracts. This page will undergo regular updates to ensure alignment with the most accurate representation of the total circulating supply._ 70 | -------------------------------------------------------------------------------- /docs/what-foundation.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: what-foundation 3 | title: What is The Arbitrum Foundation? 4 | sidebar_label: What is The Arbitrum Foundation? 5 | description: Learn about The Arbitrum Foundation is and what it is responsible for within the ecosystem 6 | dao_author: fred 7 | dao_sme: wat-dis 8 | --- 9 | 10 | ### Overview of The Arbitrum Foundation 11 | The Arbitrum Foundation is a Cayman Islands foundation company that is tasked with developing and nurturing the Arbitrum ecosystem. The Foundation operates as a neutral steward in order to support the ArbitrumDAO, the continuous innovation of the Arbitrum technology and the development and education of the Arbitrum community. 12 | 13 | 14 | As a steward for ArbitrumDAO, the Foundation is able to interact with traditional legal frameworks by: 15 | - Facilitating both compliance with relevant regulations, including sanctions-related regulations, and accountability of any particular AIP approved by the ArbitrumDAO by ensuring that appropriate KYC measures and documentation are implemented; 16 | - Engaging in various transactions and agreements with other entities, such as service providers, traditional enterprises and contractors on behalf of the ecosystem; 17 | - Supporting and facilitating infrastructure, socials, subscriptions, and various services for ArbitrumDAO. 18 | 19 | 20 | ### Mandate of The Arbitrum Foundation 21 | The Arbitrum Foundation’s mission is stated in its [bylaws](../assets/The%20Arbitrum%20Foundation%20Bylaws%2020%20July%202023.pdf) and focuses on fostering, developing, authorizing, and governing ArbitrumDAO-Approved Chains - currently Arbitrum One, an Optimistic Rollup, that instantly scales apps, reducing costs and increasing capacity without sacrificing Ethereum's security, and Arbitrum Nova, which allows for ultra-low cost fees by leveraging AnyTrust technology. 22 | 23 | 24 | Furthermore, The Arbitrum Foundation is dedicated to consistently supporting the ArbitrumDAO, encouraging involvement from individuals and entities seeking to contribute to and advance any aspect, whether technical or otherwise, of the ecosystem and future implementations of the Arbitrum technology. 25 | 26 | 27 | Specifically, the mandate empowers The Arbitrum Foundation to: 28 | - Support and fund research and development activities and projects; 29 | - Educate the public regarding ArbitrumDAO, the broader Ethereum ecosystem and Arbitrum technology; 30 | - Foster ecosystem growth through strategic initiatives, including the Arbitrum Foundation Grant Program and organizing educational initiatives for ArbitrumDAO; 31 | - Increase autonomy and fuel decentralization for ArbitrumDAO. 32 | 33 | 34 | ### How does The Arbitrum Foundation operate? 35 | The Arbitrum Foundation is governed by a Board of Directors as provided in the [Transparency report: Initial foundation setup](../docs/foundational-documents/transparency-report-initial-foundation-setup.md). The ArbitrumDAO has significant authority over the Board of Directors as it may remove or elect the Foundation's Directors, or expand or reduce the number of directors at any time pursuant to a Non-Constitutional AIP. 36 | 37 | 38 | The responsibility of the Board of Directors is to oversee and handle the operational and administrative aspects of the Foundation. The Foundation also engages officers, employees, contractors, and service providers to carry out its operational and administrative objectives in order to support the ArbitrumDAO. 39 | -------------------------------------------------------------------------------- /docs/why-governance.md: -------------------------------------------------------------------------------- 1 | --- 2 | id: why-governance 3 | title: Why decentralize Arbitrum governance with $ARB? 4 | sidebar_label: Why decentralize governance? 5 | description: Learn about the rationale behind introducing the $ARB governance token, and the important role it plays in the progressive decentralization of the Arbitrum protocol. 6 | dao_author: dzgoldman 7 | dao_sme: dzgoldman 8 | --- 9 | 10 | import DraftExpectationsPartial from '@site/docs/partials/_draft-expectations-partial.md'; 11 | 12 | 13 | 14 | 15 | $ARB is the governance token for the Arbitrum ecosystem. This document aims to explain the rationale behind introducing the $ARB governance token, and how it plays a necessary role in the progressive decentralization of the Arbitrum protocol. 16 | 17 | ### Protocol upgrades and "chain ownership" 18 | 19 | Arbitrum chains like Arbitrum One have a concept of a "chain owner." A chain owner isn't strictly part of the [Arbitrum protocol](https://github.com/OffchainLabs/nitro/blob/master/docs/Nitro-whitepaper.pdf), but is rather essentially an administrator of the chain, responsible for managing how changes are made to the system. More specifically, a chain's owner [can modify core system parameters](https://developer.arbitrum.io/arbos/precompiles#ArbOwner), [pause incoming transactions](https://github.com/OffchainLabs/nitro/blob/f1866a8be0deb6209d47319eeeced06c2b16b5a4/contracts/src/bridge/Inbox.sol#L106), and - most importantly - update any of the [contracts that define and enforce the core protocol](https://developer.arbitrum.io/useful-addresses). 20 | 21 | It's necessary to have some way to upgrade an Arbitrum chain's core contracts for several reasons. First, planned improvements need to be made to the system. Arbitrum has already gone through several such upgrades (most notably, its evolution to [Arbitrum Nitro](https://developer.arbitrum.io/why-nitro#nitro-vs-classic) from the "Arbitrum Classic" tech stack), and there will likely be more [that no one can anticipate](https://twitter.com/sgoldfed/status/1570262560947183617?s=20&t=R1VBQFAB5BaVUwjs1ur0xQ) as technological progress continues. Additionally, if a critical bug in the Arbitrum codebase is discovered, upgrades may be necessary to fix it. Finally, changes will be necessary to remain compatible with Ethereum as Ethereum undergoes its own hard-fork improvements. 22 | 23 | The ability to arbitrarily change how an Arbitrum chain works obviously makes the chain ownership role quite powerful, and thus it can't be taken lightly when considering the decentralization of the Arbitrum technical stack. 24 | 25 | ### The necessity of L2 on-chain governance 26 | 27 | Given the potential vector for centralization that chain ownership introduces, it's worth asking whether Arbitrum can simply do away with ownership entirely and handle protocol upgrades some other way. Ethereum itself, for example, has no explicit notion of a "chain owner", and yet has gone through numerous upgrades over its ~7 year life span, both to improve the system (new features, better performance, etc.) and to fix critical bugs. 28 | 29 | Here though, there's a crucial difference between Ethereum and Arbitrum: Ethereum is a Layer 1 (L1) protocol, and L1 protocols (and in turn, changes to L1 protocols) are ultimately defined by social consensus. When the community wants to upgrade Ethereum, those running the Ethereum node software install the software upgrade, and if the community at large agrees that the new change represents the "real Ethereum," then it implicitly, inherently, is so. Everyone chooses for themselves whether to adopt the change, and the choice that has critical mass becomes canonical. 30 | 31 | Layer 2 (L2) protocols like Arbitrum One, however, are fundamentally different in that their rules are ultimately *not* governed implicitly by social consensus, but rather explicitly by L1 smart contracts. For Arbitrum One to upgrade, it isn't enough to simply upgrade the Arbitrum node software; its contracts must upgrade as well, which are controlled not by the social consensus of the Arbitrum community, but by Ethereum itself. 32 | 33 | The upshot is that the consensus to upgrade Ethereum can be an informal and off-chain process, whereas the consensus to upgrade Arbitrum must operate through a formal decision making process governed by on-chain contracts. In other words, governance. 34 | 35 | There's a possible future scenario that would enable Arbitrum chains to upgrade without any explicit ownership: the Ethereum community may someday deem it acceptable to modify L1 consensus in order to upgrade Arbitrum One. That is, Ethereum's social consensus could allow hard forking of the L1 for the sake of particular L2s. L2 chains under this hypothetical arrangement have been deemed "[enshrined rollups](https://twitter.com/apolynya/status/1511623766664966146?s=20&t=u3HjXgi2UFK5kGOXy1_QCA)". 36 | 37 | While it's possible that Ethereum's L2s eventually become enshrined in this way, this likely isn't happening any time in the near future. Such a change to the Ethereum/L2 ecosystem would have to eventuate from wider discussion and debate within the Ethereum community; a decision like this is largely outside of the control of the Arbitrum community. In the meantime, the community needs a solution that can be implemented today. 38 | 39 | So given that there's a need for a path towards protocol upgrades, and that enshrined rollups are (at least currently) off the table, the only viable option remaining, then, is explicit on-chain governance. 40 | 41 | 42 | 43 | 44 | ### Enter $ARB governance token for decentralized governance 45 | 46 | The introduction of the $ARB governance token provides the ability to propose and carry out protocol upgrades in a decentralized manner. 47 | 48 | Tokens were initially airdropped via transparent criteria meant to be as fair as possible[^1]. The goal was to spread out ownership to a large set of parties with stake in the Arbitrum ecosystem who are geographically distributed and have diverse backgrounds and affiliations. The chain ownership role is given to this “Arbitrum DAO”, a shorthand for the collective of all holders of the ARB token (and those delegated voting rights by token holders). 49 | 50 | There are two paths through which a protocol upgrade can take place. The first is a **decentralized** upgrade path that allows the DAO (and only the DAO) to carry out every step in the process: proposing an upgrade, publicly debating it, voting on it, and ultimately activating it. 51 | 52 | Several important properties are preserved in a decentralized upgrade process, all of which are enforced at the smart contract level: 53 | 54 | - No permissioned parties are required at any step; the DAO itself can carry out the entire process. 55 | - The DAO is given time to view a proposal before voting on it and, if it gets to that stage, given sufficient time to vote on it. 56 | - Once a proposal passes, Arbitrum users are given time to withdraw assets from the system, should they disagree with the direction and prefer to opt out. 57 | 58 | 59 | ### Security Council 60 | 61 | The second protocol upgrade path is similar to the first path, except that it allows the Security Council, a permissioned group of publicly named entities, to skip certain steps in specific situations. Notably, the Security Council has the ability to upgrade the protocol directly and without delays in case of emergency. 62 | 63 | This is a critically necessary role to protect against emergencies like the discovery of exploitable vulnerabilities, in which case the typical slow governance path is not viable for two reasons: 64 | 65 | 1. If there's a critical vulnerability that can be exploited, it's counterproductive to broadcast it on the public governance forum before it has been mitigated. 66 | 2. The fix to such a vulnerability should go into effect immediately and not have the several weeks' delay of typical governance changes. 67 | 68 | The Security Council is bound by [The Constitution of the Arbitrum DAO](./dao-constitution.md) to only use its powers when necessary for these sorts of emergencies, and to issue a transparency report when appropriate whenever its powers are used. To keep the Security Council in check, the DAO votes in semi-annual elections (split by cohorts) for the Security Council's members. 69 | 70 | The Security Council can also trigger non-emergency upgrades, such as routine software upgrades and maintenance. These upgrades don't require a DAO vote to pass; they instead go through a delay period before taking effect, giving users time to opt out by withdrawing (as with decentralized DAO upgrades). 71 | 72 | To learn more about the Security Council, refer to the [Security Council](./concepts/security-council.md) concept doc. For a formal articulation of the Security Council's role within Arbitrum DAO's governance process, refer to [The Constitution of the Arbitrum DAO](./dao-constitution). 73 | 74 | 75 | ### The future of Arbitrum governance 76 | 77 | The initial governance launch provides the community with the tools it needs: a means of decentralized governance, along with a faster, permissioned upgrade path to ensure the system remains safe in case of emergencies. As for how this system will change moving forward, many open questions remain: 78 | 79 | - Can the governance process be further decentralized? 80 | - How and when can the Security Council's power be further minimized, or eliminated entirely? 81 | 82 | These don't have easy answers and will continue to be the topic of lively discussion within the community as the Arbitrum technology continues to mature, and as the perceived risk profiles of various states of decentralization change along with it. But crucially, the Arbitrum governance system controls *all* aspects of the Arbitrum protocol, including the governance process itself. 83 | 84 | With the DAO in control, decisions about how Arbitrum should evolve over time — including the governance process itself — are in the hands of the Arbitrum community. 85 | 86 | 87 | [^1]: Refer to [$ARB airdrop eligibility and distribution specifications](./airdrop-eligibility-distribution.md) to learn more about the airdrop specifications. Refer to [Arbitrum Sybil Hunting](https://github.com/ArbitrumFoundation/sybil-detection/) for an overview of our Sybil mitigation methodology. -------------------------------------------------------------------------------- /docusaurus.config.js: -------------------------------------------------------------------------------- 1 | // @ts-nocheck 2 | // Note: type annotations allow type checking and IDEs autocompletion 3 | 4 | const lightCodeTheme = require('prism-react-renderer/themes/github'); 5 | const darkCodeTheme = require('prism-react-renderer/themes/dracula'); 6 | 7 | // for LaTeX support 8 | const math = require('remark-math'); 9 | const katex = require('rehype-katex'); 10 | 11 | /** @type {import('@docusaurus/types').Config} */ 12 | const config = { 13 | title: 'Arbitrum DAO - Governance docs', 14 | tagline: 'Decentralized governance is cool', 15 | url: 'https://docs.arbitrum.foundation', 16 | baseUrl: '/', 17 | onBrokenLinks: 'throw', 18 | onBrokenMarkdownLinks: 'warn', 19 | favicon: 'img/favicon.ico', 20 | markdown: { 21 | mermaid: true 22 | }, 23 | themes: ['@docusaurus/theme-mermaid'], 24 | // Even if you don't use internalization, you can use this field to set useful 25 | // metadata like html lang. For example, if your site is Chinese, you may want 26 | // to replace "en" with "zh-Hans". 27 | i18n: { 28 | defaultLocale: 'en', 29 | locales: ['en'], 30 | }, 31 | plugins: ["docusaurus-plugin-less", [require.resolve('docusaurus-lunr-search'), { 32 | indexBaseUrl: true 33 | }]], 34 | presets: [ 35 | [ 36 | 'classic', 37 | /** @type {import('@docusaurus/preset-classic').Options} */ 38 | ({ 39 | docs: { 40 | // q: why is it configured this way? 41 | // a: we originally tried to use "docs only mode" by setting the `routeBasePath` to `/`, but this prevents the landing page from displaying the`/gentle-intro-dao-governance` slug, which is important for SEO. 42 | // this doc elaborates: https://docusaurus.io/docs/docs-introduction#docs-only-mode 43 | path: 'docs', 44 | routeBasePath: '/', 45 | sidebarPath: require.resolve('./sidebars.js'), 46 | breadcrumbs: false, 47 | // Please change this to your repo. 48 | // Remove this to remove the "edit this page" links. 49 | editUrl: 50 | 'https://github.com/ArbitrumFoundation/docs/edit/main/', 51 | remarkPlugins : [math], 52 | rehypePlugins : [katex], 53 | }, 54 | blog: false, 55 | theme: { 56 | customCss: require.resolve('./src/css/custom.less'), 57 | }, 58 | }), 59 | ], 60 | ], 61 | themeConfig: 62 | /** @type {import('@docusaurus/preset-classic').ThemeConfig} */ 63 | ({ 64 | navbar: { 65 | title: 'Arbitrum DAO - Governance docs', 66 | logo: { 67 | alt: 'Arbitrum DAO', 68 | src: 'img/logo.svg', 69 | href: '/gentle-intro-dao-governance', 70 | }, 71 | items: [ 72 | { 73 | href: 'https://github.com/ArbitrumFoundation/docs', 74 | label: 'GitHub', 75 | position: 'right', 76 | }, 77 | ], 78 | }, 79 | footer: { 80 | style: 'dark', 81 | links: [ 82 | { 83 | title: 'Docs', 84 | items: [ 85 | { 86 | label: 'Get started', 87 | to: '/gentle-intro-dao-governance', 88 | }, 89 | ], 90 | }, 91 | { 92 | title: 'Community', 93 | items: [ 94 | { 95 | label: 'Discord', 96 | href: 'https://discord.gg/arbitrum', 97 | }, 98 | { 99 | label: 'Twitter', 100 | href: 'https://twitter.com/arbitrum', 101 | }, 102 | ], 103 | } 104 | ], 105 | copyright: `Copyright © ${new Date().getFullYear()} Arbitrum Foundation.`, 106 | }, 107 | prism: { 108 | theme: lightCodeTheme, 109 | darkTheme: darkCodeTheme, 110 | }, 111 | // announcementBar: { 112 | // id: "banner", 113 | // content: `Arbitrum DAO has been officially announced, and the $ARB airdrop is live. Claim your $ARB.`, 114 | // backgroundColor: 'rgb(8 53 117)', 115 | // textColor: 'white', 116 | // isCloseable: false, 117 | // }, 118 | }), 119 | 120 | // also needed for math stuff. 121 | // see https://docusaurus.io/docs/2.x/markdown-features/math-equations 122 | stylesheets: [ 123 | { 124 | href: 'https://cdn.jsdelivr.net/npm/katex@0.13.24/dist/katex.min.css', 125 | type: 'text/css', 126 | integrity: 'sha384-odtC+0UGzzFL/6PNoE8rX/SPcQDXBJ+uRepguP4QkPCm2LBxH3FA3y+fKSiJ+AmM', 127 | crossorigin: 'anonymous', 128 | }, 129 | ], 130 | scripts: [ 131 | // Fathom Analytics 132 | { 133 | src: 'https://cdn.usefathom.com/script.js', 134 | 'data-site': 'QLNDABBR', 135 | defer: true, 136 | }, 137 | ], 138 | }; 139 | 140 | module.exports = config; 141 | -------------------------------------------------------------------------------- /global.d.ts: -------------------------------------------------------------------------------- 1 | declare module "*.md"; -------------------------------------------------------------------------------- /notion-docs/.eslintrc.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | env: { 3 | commonjs: true, 4 | es6: true, 5 | node: true, 6 | }, 7 | plugins: ['prettier'], 8 | extends: [ 9 | 'eslint:recommended', 10 | 'plugin:prettier/recommended', // Enables eslint-plugin-prettier and displays prettier errors as ESLint errors. Make sure this is always the last configuration in the extends array. 11 | ], 12 | parserOptions: { 13 | ecmaVersion: 2018, // Allows for the parsing of modern ECMAScript features 14 | sourceType: 'module', // Allows for the use of imports 15 | }, 16 | rules: { 17 | 'prettier/prettier': 'error', 18 | 'no-unused-vars': 'off', 19 | 'prefer-const': [2, { destructuring: 'all' }], 20 | 'object-curly-spacing': ['error', 'always'], 21 | }, 22 | overrides: [ 23 | { 24 | // this config is run against test files (same as the one bellow but not limited to `src` folder) 25 | files: ['*.ts', '*.tsx'], 26 | parser: '@typescript-eslint/parser', 27 | extends: [ 28 | 'eslint:recommended', 29 | 'plugin:@typescript-eslint/recommended', 30 | 'plugin:prettier/recommended', 31 | ], 32 | plugins: ['@typescript-eslint', 'prettier'], 33 | rules: { 34 | 'no-empty-pattern': 'warn', 35 | 'prettier/prettier': ['error', { singleQuote: true }], 36 | '@typescript-eslint/member-delimiter-style': ['off'], 37 | '@typescript-eslint/no-explicit-any': ['off'], 38 | '@typescript-eslint/no-use-before-define': ['off'], 39 | '@typescript-eslint/no-non-null-assertion': ['off'], 40 | '@typescript-eslint/ban-ts-comment': ['warn'], 41 | '@typescript-eslint/no-unused-vars': [ 42 | 'warn', 43 | { 44 | argsIgnorePattern: '^_', 45 | varsIgnorePattern: '^_', 46 | caughtErrorsIgnorePattern: '^_', 47 | }, 48 | ], 49 | 'no-implicit-coercion': 'error', 50 | }, 51 | }, 52 | { 53 | files: ['src/**/*.ts', 'src/**/*.tsx'], 54 | parser: '@typescript-eslint/parser', 55 | parserOptions: { 56 | project: 'tsconfig.json', 57 | }, 58 | extends: [ 59 | 'eslint:recommended', 60 | 'plugin:@typescript-eslint/recommended', 61 | 'plugin:prettier/recommended', 62 | ], 63 | plugins: ['@typescript-eslint', 'prettier', '@typescript-eslint/tslint'], 64 | rules: { 65 | 'no-empty-pattern': 'warn', 66 | 'prettier/prettier': ['error', { singleQuote: true }], 67 | '@typescript-eslint/member-delimiter-style': ['off'], 68 | '@typescript-eslint/no-explicit-any': ['off'], 69 | '@typescript-eslint/no-use-before-define': ['off'], 70 | '@typescript-eslint/no-non-null-assertion': ['off'], 71 | '@typescript-eslint/ban-ts-comment': ['warn'], 72 | '@typescript-eslint/no-unused-vars': [ 73 | 'warn', 74 | { 75 | argsIgnorePattern: '^_', 76 | varsIgnorePattern: '^_', 77 | caughtErrorsIgnorePattern: '^_', 78 | }, 79 | ], 80 | '@typescript-eslint/tslint/config': [ 81 | 'error', 82 | { 83 | rules: { 'strict-comparisons': true }, 84 | }, 85 | ], 86 | 'no-implicit-coercion': 'error', 87 | '@typescript-eslint/no-shadow': ['error'], 88 | }, 89 | }, 90 | ], 91 | } 92 | -------------------------------------------------------------------------------- /notion-docs/.gitignore: -------------------------------------------------------------------------------- 1 | node_modules 2 | .env 3 | bin 4 | -------------------------------------------------------------------------------- /notion-docs/.prettierrc.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | semi: false, 3 | trailingComma: 'es5', 4 | singleQuote: true, 5 | printWidth: 80, 6 | tabWidth: 2, 7 | arrowParens: 'avoid', 8 | bracketSpacing: true, 9 | } 10 | -------------------------------------------------------------------------------- /notion-docs/package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "notion-docs", 3 | "version": "1.0.0", 4 | "main": "index.ts", 5 | "license": "MIT", 6 | "private": true, 7 | "type": "commonjs", 8 | "scripts": { 9 | "build": "tsc", 10 | "update:all": "ts-node ./scripts/update.ts", 11 | "format": "prettier --config .prettierrc.js 'scripts/**/*.ts' --write", 12 | "lint": "eslint . --ext .ts" 13 | }, 14 | "dependencies": { 15 | "@notionhq/client": "^2.2.3", 16 | "@offchainlabs/notion-docs-generator": "^0.0.5", 17 | "@types/node": "^18.11.18", 18 | "dotenv": "^16.0.3", 19 | "typescript": "^4.9.4" 20 | }, 21 | "devDependencies": { 22 | "@typescript-eslint/eslint-plugin": "^5.48.0", 23 | "@typescript-eslint/eslint-plugin-tslint": "^5.48.0", 24 | "@typescript-eslint/parser": "^5.48.0", 25 | "eslint": "^8.31.0", 26 | "eslint-config-prettier": "^8.6.0", 27 | "eslint-plugin-prettier": "^4.2.1", 28 | "prettier": "^2.8.1", 29 | "ts-node": "^10.9.1", 30 | "tslint": "^6.1.3" 31 | } 32 | } 33 | -------------------------------------------------------------------------------- /notion-docs/scripts/update.ts: -------------------------------------------------------------------------------- 1 | import { Client } from '@notionhq/client' 2 | import { 3 | lookupProject, 4 | lookupGlossaryTerms, 5 | lookupFAQs, 6 | handleRenderError, 7 | recordValidity, 8 | renderGlossary, 9 | renderGlossaryJSON, 10 | renderFAQs, 11 | } from '@offchainlabs/notion-docs-generator' 12 | import dotenv from 'dotenv' 13 | 14 | import type { KnowledgeItem, LinkableTerms, LinkValidity } from '@offchainlabs/notion-docs-generator' 15 | 16 | import fs from 'fs' 17 | 18 | dotenv.config() 19 | 20 | const notion = new Client({ 21 | auth: process.env.NOTION_TOKEN, 22 | }) 23 | 24 | async function generateFiles() { 25 | const governanceProject = await lookupProject(notion, 'Governance docs') 26 | console.log('Looking up FAQs') 27 | const faqs = await lookupFAQs(notion, { 28 | filter: { 29 | and: [ 30 | { 31 | property: 'Project(s)', 32 | relation: { 33 | contains: governanceProject, 34 | }, 35 | }, 36 | { 37 | property: 'Publishable?', 38 | select: { 39 | equals: 'Publishable', 40 | }, 41 | }, 42 | ], 43 | }, 44 | }) 45 | console.log('Looking up Glossary') 46 | const definitions = await lookupGlossaryTerms(notion, {}) 47 | console.log('Rendering contents') 48 | const linkableTerms: LinkableTerms = {} 49 | const validity = (item: KnowledgeItem): LinkValidity => { 50 | return recordValidity(item, governanceProject) 51 | } 52 | const addItems = (items: KnowledgeItem[], page: string) => { 53 | for (const item of items) { 54 | linkableTerms[item.pageId] = { 55 | text: item.title, 56 | anchor: item.title, 57 | page: page, 58 | valid: validity(item), 59 | notionURL: item.url, 60 | } 61 | } 62 | } 63 | const isValid = (item: KnowledgeItem) => { 64 | return validity(item) == 'Valid' 65 | } 66 | 67 | addItems(definitions, '/dao-glossary') 68 | addItems(faqs, '/dao-faq') 69 | const publishedFAQs = faqs.filter(isValid) 70 | const publishedDefinitions = definitions.filter(isValid) 71 | const definitionsHTML = `\n\n${renderGlossary( 72 | publishedDefinitions, 73 | linkableTerms 74 | )}\n` 75 | const glossaryJSON = renderGlossaryJSON(publishedDefinitions, linkableTerms) 76 | fs.writeFileSync('../docs/partials/_glossary-partial.md', definitionsHTML) 77 | fs.writeFileSync('../static/glossary.json', glossaryJSON) 78 | fs.writeFileSync( 79 | '../docs/partials/_faq-partial.md', 80 | renderFAQs(publishedFAQs, linkableTerms) 81 | ) 82 | } 83 | 84 | async function main() { 85 | try { 86 | await generateFiles() 87 | } catch (e: unknown) { 88 | if (await handleRenderError(e, notion)) { 89 | process.exit(1) 90 | } 91 | throw e 92 | } 93 | } 94 | 95 | main() 96 | .then(() => process.exit(0)) 97 | .catch(err => { 98 | console.error(err) 99 | process.exit(1) 100 | }) 101 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "docs", 3 | "version": "0.0.0", 4 | "private": true, 5 | "scripts": { 6 | "docusaurus": "docusaurus", 7 | "start": "docusaurus start", 8 | "build": "docusaurus build", 9 | "swizzle": "docusaurus swizzle", 10 | "deploy": "docusaurus deploy", 11 | "clear": "docusaurus clear", 12 | "serve": "docusaurus serve", 13 | "write-translations": "docusaurus write-translations", 14 | "write-heading-ids": "docusaurus write-heading-ids", 15 | "typecheck": "tsc", 16 | "format": "prettier --write .", 17 | "verifyQuicklooks": "node scripts/verifyQuicklooks.js", 18 | "update-constitution-hash": "node scripts/updateConstitutionHash.js", 19 | "verifyAndBuild": "yarn verifyQuicklooks && yarn build" 20 | }, 21 | "dependencies": { 22 | "@docusaurus/core": "2.2.0", 23 | "@docusaurus/preset-classic": "2.2.0", 24 | "@docusaurus/theme-mermaid": "2.2.0", 25 | "@ethersproject/address": "^5.7.0", 26 | "@ethersproject/solidity": "^5.7.0", 27 | "@mdx-js/react": "^1.6.22", 28 | "clsx": "^1.2.1", 29 | "docusaurus-lunr-search": "^2.3.2", 30 | "ethers": "^6.7.1", 31 | "hast-util-is-element": "1.1.0", 32 | "prism-react-renderer": "^1.3.5", 33 | "react": "^18.2.0", 34 | "react-dom": "^18.2.0", 35 | "rehype-katex": "5", 36 | "remark-math": "3", 37 | "tippy.js": "^6.3.7" 38 | }, 39 | "devDependencies": { 40 | "@docusaurus/module-type-aliases": "2.2.0", 41 | "@tsconfig/docusaurus": "^1.0.5", 42 | "docusaurus-plugin-less": "^2.0.2", 43 | "less": "^4.1.3", 44 | "less-loader": "^11.1.0", 45 | "prettier": "^2.8.1", 46 | "typescript": "^4.7.4" 47 | }, 48 | "browserslist": { 49 | "production": [ 50 | ">0.5%", 51 | "not dead", 52 | "not op_mini all" 53 | ], 54 | "development": [ 55 | "last 1 chrome version", 56 | "last 1 firefox version", 57 | "last 1 safari version" 58 | ] 59 | }, 60 | "engines": { 61 | "node": ">=16.14" 62 | } 63 | } 64 | -------------------------------------------------------------------------------- /postmortems/assets/15_Dec_2023_Figure_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ArbitrumFoundation/docs/a2d1d0d715769a0425982b8dd1ba0f0a5cb1b1fa/postmortems/assets/15_Dec_2023_Figure_1.png -------------------------------------------------------------------------------- /postmortems/assets/15_Dec_2023_Figure_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ArbitrumFoundation/docs/a2d1d0d715769a0425982b8dd1ba0f0a5cb1b1fa/postmortems/assets/15_Dec_2023_Figure_2.png -------------------------------------------------------------------------------- /prettier.config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | tabWidth: 2, 3 | useTabs: false, 4 | semi: true, 5 | singleQuote: true, 6 | bracketSpacing: true, 7 | arrowParens: 'always', 8 | trailingComma: 'es5', 9 | }; 10 | -------------------------------------------------------------------------------- /scripts/updateConstitutionHash.js: -------------------------------------------------------------------------------- 1 | // README: `node ./scripts/updateConstitutionHash` 2 | 3 | const fs = require('fs'); 4 | 5 | const { pack, keccak256, sha256 } = require('@ethersproject/solidity'); 6 | const main = async () => { 7 | const data = await fs.readFileSync( 8 | './docs/partials/_constitution-content-partial.md', 9 | 'utf8' 10 | ); 11 | const constitutionHash = keccak256(['string'], [data]); 12 | fs.writeFileSync( 13 | './src/components/ConstitutionHash/constitutionHash.json', 14 | JSON.stringify({ constitutionHash }) 15 | ); 16 | return constitutionHash; 17 | }; 18 | 19 | main().then((res) => { 20 | console.log('Constitution hash:'); 21 | console.log(res); 22 | }); 23 | -------------------------------------------------------------------------------- /scripts/verifyQuicklooks.js: -------------------------------------------------------------------------------- 1 | const fs = require('fs'); 2 | const glob = require('glob'); 3 | const quicklookKeysJSON = require('../static/glossary.json'); 4 | 5 | 6 | const QUICKLOOKS_PREFIX = 'data-quicklook-from=' 7 | 8 | function findQuotedTextAfter(string, input) { 9 | const regex = new RegExp(`${string}[\\s]*(['"])(.*?)\\1`, 'g'); 10 | const matches = []; 11 | let match; 12 | while ((match = regex.exec(input)) !== null) { 13 | matches.push(match[2]); 14 | } 15 | return matches; 16 | } 17 | 18 | glob('./docs/**/*', function (err, res) { 19 | if (err) { 20 | throw new Error(err); 21 | } else { 22 | let quicklookKeys = []; 23 | for (const path of res) { 24 | if (!path.endsWith('.md')) continue; 25 | const data = fs.readFileSync(path, 'utf8'); 26 | quicklookKeys = quicklookKeys.concat( 27 | findQuotedTextAfter(QUICKLOOKS_PREFIX, data) 28 | ); 29 | } 30 | const notFoundKeys = quicklookKeys.filter((key) => !quicklookKeysJSON[key]); 31 | if (notFoundKeys.length === 0) { 32 | console.log('Quicklooks verification successful'); 33 | process.exit(0); 34 | } else { 35 | console.log( 36 | `Quicklooks verification failed: the following keys not found in glossary:\n${notFoundKeys.join( 37 | '\n' 38 | )}` 39 | ); 40 | process.exit(1); 41 | } 42 | } 43 | }); 44 | -------------------------------------------------------------------------------- /sidebars.js: -------------------------------------------------------------------------------- 1 | // @ts-nocheck 2 | // Docs: https://docusaurus.io/docs/next/sidebar 3 | // Tip: sidebar labels are specified within the frontmatter of individual docs, not here 4 | 5 | module.exports = { 6 | sidebar: [ 7 | { 8 | type: 'doc', 9 | id: 'gentle-intro-dao-governance', 10 | }, 11 | { 12 | type: 'doc', 13 | id: 'why-governance', 14 | }, 15 | { 16 | type: 'doc', 17 | id: 'what-foundation', 18 | }, 19 | { 20 | type: 'doc', 21 | id: 'airdrop-eligibility-distribution', 22 | }, 23 | { 24 | type: 'doc', 25 | id: 'token-supply', 26 | }, 27 | { 28 | type: 'doc', 29 | id: 'state-of-progressive-decentralization', 30 | }, 31 | { 32 | type: 'doc', 33 | id: 'dao-constitution', 34 | }, 35 | { 36 | type: 'doc', 37 | id: 'new-arb-chains', 38 | }, 39 | { 40 | type: 'doc', 41 | id: 'network-upgrades', 42 | }, 43 | { 44 | type: 'category', 45 | label: 'Arbitrum BoLD economics guides', 46 | collapsed: true, 47 | items: [ 48 | { 49 | type: 'doc', 50 | id: 'arbitrum-bold-economics/bold-reimbursing-service-fees', 51 | }, 52 | { 53 | type: 'doc', 54 | id: 'arbitrum-bold-economics/bold-reimbursing-gas-costs', 55 | }, 56 | { 57 | type: 'doc', 58 | id: 'arbitrum-bold-economics/bold-reimbursing-challenge-bonds', 59 | }, 60 | ] 61 | }, 62 | { 63 | type: 'category', 64 | label: 'How-to guides', 65 | collapsed: false, 66 | items: [ 67 | { 68 | type: 'doc', 69 | id: 'how-tos/create-submit-dao-proposal', 70 | }, 71 | { 72 | type: 'doc', 73 | id: 'how-tos/resubmit-dao-proposal', 74 | }, 75 | { 76 | type: 'doc', 77 | id: 'how-tos/select-delegate-voting-power', 78 | }, 79 | { 80 | type: 'doc', 81 | id: 'how-tos/apply-become-delegate', 82 | }, 83 | { 84 | type: 'doc', 85 | id: 'how-tos/build-strong-delegate-platform', 86 | }, 87 | { 88 | type: 'doc', 89 | id: 'how-tos/vote-dao-proposals', 90 | } 91 | ], 92 | }, 93 | { 94 | type: 'category', 95 | label: 'Governance concepts', 96 | items: [ 97 | { 98 | type: 'doc', 99 | id: 'concepts/arb-token', 100 | }, 101 | { 102 | type: 'doc', 103 | id: 'concepts/arbitrum-dao', 104 | }, 105 | { 106 | type: 'doc', 107 | id: 'concepts/delegate-delegation', 108 | }, 109 | { 110 | type: 'doc', 111 | id: 'concepts/sybil-account', 112 | }, 113 | { 114 | type: 'doc', 115 | id: 'concepts/dao-vote', 116 | }, 117 | { 118 | type: 'doc', 119 | id: 'concepts/security-council', 120 | }, 121 | { 122 | type: 'doc', 123 | id: 'concepts/lifecycle-anatomy-aip-proposal', 124 | }, 125 | { 126 | type: 'doc', 127 | id: 'concepts/public-preview-content', 128 | } 129 | ], 130 | }, 131 | { 132 | type: 'category', 133 | label: 'Governance architecture', 134 | items: [ 135 | { 136 | type: 'doc', 137 | id: 'security-council-members', 138 | }, 139 | { 140 | type: 'link', 141 | label: 'Sybil detection', 142 | href: 'https://github.com/ArbitrumFoundation/sybil-detection', 143 | }, 144 | { 145 | type: 'link', 146 | label: 'Smart contract architecture', 147 | href: 'https://github.com/ArbitrumFoundation/governance/blob/main/docs/overview.md', 148 | }, 149 | { 150 | type: 'doc', 151 | id: 'fee-distribution' 152 | }, 153 | { 154 | type: 'doc', 155 | id: 'deployment-addresses' 156 | } 157 | ], 158 | }, 159 | { 160 | type: 'doc', 161 | id: 'foundation-documents' 162 | }, 163 | { 164 | type: 'doc', 165 | id: 'dao-comprehension-check', 166 | }, 167 | { 168 | type: 'doc', 169 | id: 'dao-glossary', 170 | }, 171 | { 172 | type: 'doc', 173 | id: 'dao-faqs', 174 | } 175 | ], 176 | }; 177 | -------------------------------------------------------------------------------- /src/components/AddressExplorerLink/index.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import { getAddress, isAddress } from '@ethersproject/address'; 3 | 4 | type ChainID = 1 | 11155111 | 42170 | 421614 | 42161; 5 | 6 | const chainIDToExplorerUrlRoot: { 7 | [chainId in ChainID]: string; 8 | } = { 9 | 1: 'https://etherscan.io/address', 10 | 11155111: 'https://sepolia.etherscan.io/address', 11 | 42161: 'https://arbiscan.io/address', 12 | 42170: 'https://nova.arbiscan.io/address', 13 | 421614: 'https://sepolia.arbiscan.io/address', 14 | }; 15 | 16 | export const AddressExplorerLink = (props: { 17 | address: string | 503; 18 | chainID: ChainID; 19 | }) => { 20 | const { address, chainID } = props; 21 | const rootUrl = chainIDToExplorerUrlRoot[chainID]; 22 | if (!rootUrl) 23 | throw new Error(`Error: no root url set for chain id ${chainID} `); 24 | 25 | if (address === 503) { 26 | return soon™️; 27 | } 28 | if (!isAddress(address)) 29 | throw new Error(`Error ${address} is not an address`); 30 | if (getAddress(address) != address) 31 | throw new Error( 32 | `Error: ${address} has invalid checksum; should be ${getAddress(address)}` 33 | ); 34 | 35 | return ( 36 | 37 | {address} 38 | 39 | ); 40 | }; 41 | -------------------------------------------------------------------------------- /src/components/ConstitutionHash/constitutionHash.json: -------------------------------------------------------------------------------- 1 | {"constitutionHash":"0x28faf2acba9b3ff80ec484e3d5646931eeef40568b1b7c38dbe52b890bfd7938"} -------------------------------------------------------------------------------- /src/components/ConstitutionHash/index.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import constHashJson from './constitutionHash.json'; 3 | 4 | export const ConstitutionHash = () => { 5 | return <>{constHashJson.constitutionHash}; 6 | }; 7 | -------------------------------------------------------------------------------- /src/components/Hasher/index.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import styles from './styles.module.css'; 3 | import BrowserOnly from '@docusaurus/BrowserOnly'; 4 | 5 | export const Hasher = ({ targetElementId }) => { 6 | 7 | // https://stackoverflow.com/questions/7616461/generate-a-hash-from-string-in-javascript 8 | const cyrb53 = (str, seed = 0) => { 9 | let h1 = 0xdeadbeef ^ seed, 10 | h2 = 0x41c6ce57 ^ seed; 11 | for (let i = 0, ch; i < str.length; i++) { 12 | ch = str.charCodeAt(i); 13 | h1 = Math.imul(h1 ^ ch, 2654435761); 14 | h2 = Math.imul(h2 ^ ch, 1597334677); 15 | } 16 | 17 | h1 = Math.imul(h1 ^ (h1 >>> 16), 2246822507) ^ Math.imul(h2 ^ (h2 >>> 13), 3266489909); 18 | h2 = Math.imul(h2 ^ (h2 >>> 16), 2246822507) ^ Math.imul(h1 ^ (h1 >>> 13), 3266489909); 19 | 20 | return 4294967296 * (2097151 & h2) + (h1 >>> 0); 21 | }; 22 | 23 | 24 | let calculateHash = function (id) { 25 | console.log("calculating hash..."); 26 | let targetElement = document.getElementById(id); 27 | if (targetElement != null) { 28 | return cyrb53(targetElement.innerText); 29 | } 30 | return; 31 | }; 32 | 33 | return ( 34 | 35 | {() => ( 36 | 42 | )} 43 | 44 | ); 45 | }; 46 | -------------------------------------------------------------------------------- /src/components/HeaderBadges/index.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import BrowserOnly from '@docusaurus/BrowserOnly'; 3 | import styles from './styles.module.css'; 4 | 5 | export const HeaderBadges = () => { 6 | return ( 7 | 8 | {() => ( 9 | 15 | )} 16 | 17 | ); 18 | }; -------------------------------------------------------------------------------- /src/components/HomepageFeatures/index.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import clsx from 'clsx'; 3 | import styles from './styles.module.css'; 4 | 5 | type FeatureItem = { 6 | title: string; 7 | Svg: React.ComponentType>; 8 | description: JSX.Element; 9 | }; 10 | 11 | const FeatureList: FeatureItem[] = [ 12 | { 13 | title: 'Easy to Use', 14 | Svg: require('@site/static/img/undraw_docusaurus_mountain.svg').default, 15 | description: ( 16 | <> 17 | Docusaurus was designed from the ground up to be easily installed and 18 | used to get your website up and running quickly. 19 | 20 | ), 21 | }, 22 | { 23 | title: 'Focus on What Matters', 24 | Svg: require('@site/static/img/undraw_docusaurus_tree.svg').default, 25 | description: ( 26 | <> 27 | Docusaurus lets you focus on your docs, and we'll do the chores. Go 28 | ahead and move your docs into the docs directory. 29 | 30 | ), 31 | }, 32 | { 33 | title: 'Powered by React', 34 | Svg: require('@site/static/img/undraw_docusaurus_react.svg').default, 35 | description: ( 36 | <> 37 | Extend or customize your website layout by reusing React. Docusaurus can 38 | be extended while reusing the same header and footer. 39 | 40 | ), 41 | }, 42 | ]; 43 | 44 | function Feature({ title, Svg, description }: FeatureItem) { 45 | return ( 46 |
47 |
48 | 49 |
50 |
51 |

{title}

52 |

{description}

53 |
54 |
55 | ); 56 | } 57 | 58 | export default function HomepageFeatures(): JSX.Element { 59 | return ( 60 |
61 |
62 |
63 | {FeatureList.map((props, idx) => ( 64 | 65 | ))} 66 |
67 |
68 |
69 | ); 70 | } 71 | -------------------------------------------------------------------------------- /src/components/HomepageFeatures/styles.module.css: -------------------------------------------------------------------------------- 1 | .features { 2 | display: flex; 3 | align-items: center; 4 | padding: 2rem 0; 5 | width: 100%; 6 | } 7 | 8 | .featureSvg { 9 | height: 200px; 10 | width: 200px; 11 | } 12 | -------------------------------------------------------------------------------- /src/components/HorizontalRuleWithText/index.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import styles from './styles.module.css'; 3 | 4 | export default function HorizontalRuleWithText({ children }) { 5 | return ( 6 |
7 | {children} 8 |
9 | ); 10 | } 11 | -------------------------------------------------------------------------------- /src/components/HorizontalRuleWithText/styles.module.css: -------------------------------------------------------------------------------- 1 | .horizontal-rule { 2 | display: flex; 3 | align-items: center; 4 | } 5 | 6 | .horizontal-rule::before, 7 | .horizontal-rule::after { 8 | content: ''; 9 | display: inline-block; 10 | flex: 1 1 auto; 11 | height: 1px; 12 | background-color: var(--ifm-color-primary-dark); 13 | } 14 | 15 | .horizontal-rule span { 16 | display: inline-flex; 17 | margin: var(--space-s); 18 | } 19 | -------------------------------------------------------------------------------- /src/components/PendingConstitutionNotice/index.tsx: -------------------------------------------------------------------------------- 1 | import React, { useEffect, useState } from 'react'; 2 | import constHashJson from '../ConstitutionHash/constitutionHash.json'; 3 | import { Contract, JsonRpcProvider } from 'ethers'; 4 | 5 | const hashDiff = (docsHash: string, chainHash: string) => { 6 | return [docsHash, chainHash].sort().join(','); 7 | }; 8 | 9 | const diffToAIP = { 10 | [hashDiff( 11 | '0x2498ca4a737c2d06c43799b5ddf5183b6e169359f68bea4b34775751528a2ee1', 12 | '0x60acde40ad14f4ecdb1bea0704d1e3889264fb029231c9016352c670703b35d6' 13 | )]: { 14 | AIP: '6', 15 | link: 'https://www.tally.xyz/gov/arbitrum/proposal/108413626736577087081818577238162267924459697981830202052718122463860611528602', 16 | }, 17 | }; 18 | 19 | export const PendingConstitutionNotice = () => { 20 | const [chainHash, setChainHash] = useState(); 21 | const [docsHash, setDocsHash] = useState(); 22 | const checkConstitutionDiff = async () => { 23 | const arbOneProvider = new JsonRpcProvider('https://arb1.arbitrum.io/rpc'); 24 | const constitutionHashContract = new Contract( 25 | '0x1D62fFeB72e4c360CcBbacf7c965153b00260417', 26 | ['function constitutionHash() view returns(bytes32)'], 27 | arbOneProvider 28 | ); 29 | setChainHash(await constitutionHashContract.constitutionHash()); 30 | setDocsHash(constHashJson.constitutionHash); 31 | }; 32 | useEffect(() => { 33 | checkConstitutionDiff(); 34 | }, []); 35 | 36 | const AIPInfo = diffToAIP[hashDiff(docsHash, chainHash)]; 37 | const showNotice = docsHash && chainHash && docsHash !== chainHash; 38 | if (!showNotice) return; 39 | return ( 40 |
41 | {AIPInfo ? ( 42 | <> 43 | Note: Displaying pending constitution hash for{' '} 44 | 45 | AIP {AIPInfo.AIP} 46 | 47 | , passed but not yet executed.
48 | Displayed Constitution hash: {docsHash}
49 | On-chain hash: {chainHash}{' '} 50 | 51 | ) : ( 52 | <> 53 | Note: displayed constitution mismatches with on-chain constitution 54 | hash:
55 | Displayed Constitution hash: {docsHash}
56 | On-chain hash: {chainHash}
57 | Open an issue{' '} 58 | 65 | here 66 | 67 | 68 | )} 69 |
70 | ); 71 | }; 72 | -------------------------------------------------------------------------------- /src/components/Quicklooks/index.tsx: -------------------------------------------------------------------------------- 1 | import React, { useEffect } from 'react'; 2 | import useIsBrowser from '@docusaurus/useIsBrowser'; 3 | import { useLocation } from '@docusaurus/router'; 4 | import Tippy from 'tippy.js'; 5 | import 'tippy.js/dist/tippy.css'; 6 | import 'tippy.js/themes/light-border.css'; 7 | import glossary from '../../../static/glossary.json' 8 | 9 | export const Quicklooks = () => { 10 | // todo:qqq - document usage of this component for nontechnical content contributors 11 | const isBrowser = useIsBrowser(); 12 | const location = useLocation(); 13 | 14 | useEffect(() => { 15 | if (!isBrowser) { 16 | return; 17 | } 18 | Tippy('a[data-quicklook-from]:not([data-quicklook-enabled])', { 19 | trigger: 'mouseenter', 20 | duration: [100, 200], 21 | theme: 'light-border', 22 | allowHTML: true, 23 | interactive: true, 24 | content: (reference) => { 25 | reference.setAttribute('data-quicklook-enabled', 'true'); 26 | let contentSourceKey = reference.getAttribute('data-quicklook-from'); 27 | let termItem = glossary[contentSourceKey] 28 | if (!termItem) { 29 | console.warn(`WARNING: No quicklook entry found for ${contentSourceKey}`); 30 | return undefined 31 | } 32 | return termItem.text 33 | }, 34 | }); 35 | // re-render tippys when location (page) changes 36 | }, [isBrowser, location]); 37 | 38 | return <>; 39 | }; 40 | -------------------------------------------------------------------------------- /src/components/TrackedLink/index.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | 3 | export const TrackedLink = ({href, children, trackedEvent}) => { 4 | function onClick() { 5 | if (trackedEvent) { 6 | // @ts-ignore - fathom is added by docusaurus config 7 | fathom.trackEvent(trackedEvent) 8 | } 9 | } 10 | return {children}; 11 | }; 12 | -------------------------------------------------------------------------------- /src/css/custom.css: -------------------------------------------------------------------------------- 1 | /** 2 | * Any CSS included here will be global. 3 | * Uses Infima. Infima docs -> https://infima.dev/ 4 | * If you're updating this, make sure you're updating the LESS file. 5 | */ 6 | /* You can override the default Infima variables here. */ 7 | :root { 8 | --ifm-color-primary: #007bdd; 9 | --ifm-color-primary-dark: #295f78; 10 | --ifm-color-primary-darker: #275771; 11 | --ifm-color-primary-darkest: #20465d; 12 | --ifm-color-primary-light: #337292; 13 | --ifm-color-primary-lighter: #357899; 14 | --ifm-color-primary-lightest: #3c85ad; 15 | --ifm-color-content: #000; 16 | --ifm-link-color: #007bdd; 17 | --ifm-code-font-size: 95%; 18 | --ifm-global-radius: 2px; 19 | --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1); 20 | --ifm-color-info-dark: #359aec; 21 | --ifm-color-info-contrast-background: #f0f8ff; 22 | --ifm-alert-padding-vertical: 1.5rem; 23 | --ifm-alert-padding-horizontal: 1.5rem; 24 | } 25 | 26 | /* For readability concerns, you should choose a lighter palette in dark mode. */ 27 | [data-theme='dark'] { 28 | --ifm-color-primary: #28a0f0; 29 | --ifm-color-primary-dark: #2182af; 30 | --ifm-color-primary-darker: #1f7fa5; 31 | --ifm-color-primary-darkest: #1a6c88; 32 | --ifm-color-primary-light: #29b0d5; 33 | --ifm-color-primary-lighter: #32b4d8; 34 | --ifm-color-primary-lightest: #4fbcdd; 35 | --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3); 36 | } 37 | 38 | .header-badges { 39 | display: block; 40 | margin-bottom: 15px; 41 | min-height: 35px; 42 | text-align: right; 43 | /*pragmatism over perfection*/ 44 | } 45 | 46 | .header-badges .header-badge { 47 | transition-property: all; 48 | transition-duration: 0.2s; 49 | display: inline-block; 50 | border-radius: 20px; 51 | background-color: #efefef; 52 | padding: 3px 20px 3px 3px; 53 | height: 31px; 54 | margin-right: 6px; 55 | margin-bottom: 5px; 56 | vertical-align: top; 57 | white-space: nowrap; 58 | overflow: hidden; 59 | text-overflow: ellipsis; 60 | max-width: 100%; 61 | } 62 | 63 | .header-badges .header-badge:hover { 64 | text-decoration: none; 65 | background-color: #e6e6e6; 66 | opacity: 1; 67 | } 68 | 69 | .header-badges .header-badge:hover .badge-avatar { 70 | opacity: 1; 71 | } 72 | 73 | .header-badges .header-badge:hover .badge-label { 74 | color: #000; 75 | } 76 | 77 | .header-badges .header-badge .badge-label { 78 | white-space: nowrap; 79 | overflow: hidden; 80 | text-overflow: ellipsis; 81 | transition-property: all; 82 | transition-duration: 0.2s; 83 | font-size: 13px; 84 | line-height: 24px; 85 | color: #333; 86 | display: inline-block; 87 | vertical-align: top; 88 | height: 25px; 89 | max-width: calc(100% - 33px); 90 | } 91 | 92 | .header-badges .header-badge .badge-avatar { 93 | transition-property: all; 94 | transition-duration: 0.2s; 95 | display: inline-block; 96 | border-radius: 30px; 97 | width: 25px; 98 | height: 25px; 99 | background-size: cover; 100 | margin-right: 12px; 101 | font-size: 12px; 102 | vertical-align: top; 103 | line-height: 23px; 104 | padding-left: 8px; 105 | opacity: 0.7; 106 | } 107 | 108 | .header-badges .header-badge .emoji-avatar { 109 | margin-right: 8px !important; 110 | } 111 | 112 | .truncate { 113 | white-space: nowrap; 114 | overflow: hidden; 115 | text-overflow: ellipsis; 116 | } 117 | 118 | article .markdown h1:first-child { 119 | font-size: 30px; 120 | } 121 | 122 | article .markdown>h3 { 123 | font-size: 21px; 124 | margin-top: 50px; 125 | margin-bottom: 15px; 126 | } 127 | 128 | article .markdown li li { 129 | margin-top: 4px; 130 | } 131 | 132 | article .markdown .small-table { 133 | font-size: 12px; 134 | margin-top: 20px; 135 | } 136 | 137 | article .markdown .small-table td { 138 | padding: 10px; 139 | } 140 | 141 | article .markdown .definition-list dt { 142 | font-weight: 700; 143 | margin-top: 20px; 144 | } 145 | 146 | article .markdown .definition-list dd { 147 | margin-left: 0; 148 | } 149 | 150 | article .markdown a { 151 | font-weight: 600; 152 | } 153 | 154 | article .markdown a:hover { 155 | cursor: pointer; 156 | opacity: 0.9; 157 | } 158 | 159 | article .markdown strong { 160 | font-weight: 600; 161 | } 162 | 163 | article .markdown .theme-admonition { 164 | margin-bottom: 2em; 165 | } 166 | 167 | article .markdown .theme-admonition svg { 168 | height: 1.3rem; 169 | width: 1.3rem; 170 | } 171 | 172 | article .markdown .a-b-list { 173 | list-style-type: lower-alpha; 174 | } 175 | 176 | .theme-doc-sidebar-menu { 177 | font-size: 13.5px; 178 | } 179 | 180 | .hidden-glossary { 181 | display: none; 182 | } 183 | 184 | .show-hidden-glossary>.hidden-glossary { 185 | display: block; 186 | } 187 | 188 | [data-tippy-root] ul, 189 | .hidden-glossary ul, 190 | [data-tippy-root] li, 191 | .hidden-glossary li { 192 | margin: 5px 0 5px 0; 193 | } 194 | 195 | .tippy-box { 196 | padding: 8px; 197 | } 198 | 199 | .tippy-content p:last-child { 200 | margin-bottom: 0; 201 | } 202 | 203 | @media (max-width: 736px) { 204 | .markdown h1:first-child { 205 | font-size: 24px; 206 | } 207 | 208 | .markdown>h3 { 209 | font-size: 18px; 210 | margin-top: 35px; 211 | margin-bottom: 10px; 212 | } 213 | } 214 | 215 | /* temp location to avoid merge conflicts */ 216 | @font-face { 217 | font-family: 'Fira Code'; 218 | font-style: normal; 219 | font-weight: 300; 220 | font-display: swap; 221 | src: url(https://fonts.gstatic.com/s/firacode/v21/uU9eCBsR6Z2vfE9aq3bL0fxyUs4tcw4W_GNsFVc.ttf) format('truetype'); 222 | } 223 | 224 | @font-face { 225 | font-family: 'Fira Code'; 226 | font-style: normal; 227 | font-weight: 400; 228 | font-display: swap; 229 | src: url(https://fonts.gstatic.com/s/firacode/v21/uU9eCBsR6Z2vfE9aq3bL0fxyUs4tcw4W_D1sFVc.ttf) format('truetype'); 230 | } 231 | 232 | @font-face { 233 | font-family: 'Fira Code'; 234 | font-style: normal; 235 | font-weight: 500; 236 | font-display: swap; 237 | src: url(https://fonts.gstatic.com/s/firacode/v21/uU9eCBsR6Z2vfE9aq3bL0fxyUs4tcw4W_A9sFVc.ttf) format('truetype'); 238 | } 239 | 240 | @font-face { 241 | font-family: 'Fira Code'; 242 | font-style: normal; 243 | font-weight: 600; 244 | font-display: swap; 245 | src: url(https://fonts.gstatic.com/s/firacode/v21/uU9eCBsR6Z2vfE9aq3bL0fxyUs4tcw4W_ONrFVc.ttf) format('truetype'); 246 | } 247 | 248 | @font-face { 249 | font-family: 'Fira Code'; 250 | font-style: normal; 251 | font-weight: 700; 252 | font-display: swap; 253 | src: url(https://fonts.gstatic.com/s/firacode/v21/uU9eCBsR6Z2vfE9aq3bL0fxyUs4tcw4W_NprFVc.ttf) format('truetype'); 254 | } 255 | 256 | #constitution { 257 | background: #f4f4f4; 258 | border: 1px solid #ddd; 259 | border-left: 2px solid #28a0f0; 260 | color: #666; 261 | page-break-inside: avoid; 262 | font-family: 'Fira Code', monospace; 263 | font-size: 14px; 264 | line-height: 1.6; 265 | margin-bottom: 1.6em; 266 | max-width: 100%; 267 | overflow: auto; 268 | padding: 50px; 269 | display: block; 270 | word-wrap: break-word; 271 | white-space: pre-wrap; 272 | } 273 | 274 | #constitution h3 { 275 | font-family: 'Fira Code', monospace; 276 | margin-top: 40px; 277 | } -------------------------------------------------------------------------------- /src/css/custom.less: -------------------------------------------------------------------------------- 1 | /** 2 | * Any CSS included here will be global. 3 | * Uses Infima. Infima docs -> https://infima.dev/ 4 | * If you're updating this, make sure you're updating the LESS file. 5 | */ 6 | 7 | /* You can override the default Infima variables here. */ 8 | :root { 9 | --ifm-color-primary: #007bdd; 10 | --ifm-color-primary-dark: #295f78; 11 | --ifm-color-primary-darker: #275771; 12 | --ifm-color-primary-darkest: #20465d; 13 | --ifm-color-primary-light: #337292; 14 | --ifm-color-primary-lighter: #357899; 15 | --ifm-color-primary-lightest: #3c85ad; 16 | --ifm-color-content: #000; 17 | --ifm-link-color: #007bdd; 18 | --ifm-code-font-size: 95%; 19 | --ifm-global-radius: 2px; 20 | --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1); 21 | --ifm-color-info-dark: #359aec; 22 | --ifm-color-info-contrast-background: #f0f8ff; 23 | --ifm-alert-padding-vertical: 1.5rem; 24 | --ifm-alert-padding-horizontal: 1.5rem; 25 | } 26 | 27 | /* For readability concerns, you should choose a lighter palette in dark mode. */ 28 | [data-theme='dark'] { 29 | --ifm-color-primary: #28a0f0; 30 | --ifm-color-primary-dark: #2182af; 31 | --ifm-color-primary-darker: #1f7fa5; 32 | --ifm-color-primary-darkest: #1a6c88; 33 | --ifm-color-primary-light: #29b0d5; 34 | --ifm-color-primary-lighter: #32b4d8; 35 | --ifm-color-primary-lightest: #4fbcdd; 36 | --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3); 37 | } 38 | 39 | .header-badges { 40 | display: block; 41 | margin-bottom: 15px; 42 | min-height: 35px; 43 | text-align: right; 44 | /*pragmatism over perfection*/ 45 | 46 | .header-badge { 47 | .truncate; 48 | transition-property: all; 49 | transition-duration: 0.2s; 50 | display: inline-block; 51 | border-radius: 20px; 52 | background-color: #efefef; 53 | padding: 3px 20px 3px 3px; 54 | height: 31px; 55 | margin-right: 6px; 56 | margin-bottom: 5px; 57 | vertical-align: top; 58 | white-space: nowrap; 59 | overflow: hidden; 60 | text-overflow: ellipsis; 61 | max-width: 100%; 62 | 63 | &:hover { 64 | text-decoration: none; 65 | background-color: #e6e6e6; 66 | opacity: 1; 67 | 68 | .badge-avatar { 69 | opacity: 1; 70 | } 71 | 72 | .badge-label { 73 | color: #000; 74 | } 75 | } 76 | 77 | .badge-label { 78 | .truncate; 79 | transition-property: all; 80 | transition-duration: 0.2s; 81 | font-size: 13px; 82 | line-height: 24px; 83 | color: #333; 84 | display: inline-block; 85 | vertical-align: top; 86 | height: 25px; 87 | max-width: calc(100% ~'-' 33px); 88 | } 89 | 90 | .badge-avatar { 91 | transition-property: all; 92 | transition-duration: 0.2s; 93 | display: inline-block; 94 | border-radius: 30px; 95 | width: 25px; 96 | height: 25px; 97 | background-size: cover; 98 | margin-right: 12px; 99 | font-size: 12px; 100 | vertical-align: top; 101 | line-height: 23px; 102 | padding-left: 8px; 103 | opacity: 0.7; 104 | } 105 | 106 | .emoji-avatar { 107 | margin-right: 8px !important; 108 | } 109 | } 110 | } 111 | 112 | .truncate { 113 | white-space: nowrap; 114 | overflow: hidden; 115 | text-overflow: ellipsis; 116 | } 117 | 118 | article { 119 | .markdown { 120 | h1:first-child { 121 | font-size: 30px; 122 | } 123 | 124 | >h3 { 125 | font-size: 21px; 126 | margin-top: 50px; 127 | margin-bottom: 15px; 128 | } 129 | 130 | li li { 131 | margin-top: 4px; 132 | } 133 | 134 | .small-table { 135 | font-size: 12px; 136 | margin-top: 20px; 137 | 138 | td { 139 | padding: 10px; 140 | } 141 | } 142 | 143 | 144 | 145 | .definition-list { 146 | dt { 147 | font-weight: 700; 148 | margin-top: 20px; 149 | } 150 | 151 | dd { 152 | margin-left: 0; 153 | } 154 | } 155 | 156 | a { 157 | font-weight: 600; 158 | 159 | &:hover { 160 | cursor: pointer; 161 | opacity: 0.9; 162 | } 163 | } 164 | 165 | strong { 166 | font-weight: 600; 167 | } 168 | 169 | .theme-admonition { 170 | margin-bottom: 2em; 171 | 172 | svg { 173 | height: 1.3rem; 174 | width: 1.3rem; 175 | } 176 | } 177 | 178 | .a-b-list { 179 | list-style-type: lower-alpha; 180 | } 181 | 182 | sup { 183 | padding-left: 2px; 184 | } 185 | 186 | .footnote-backref { 187 | display: none; 188 | } 189 | 190 | .footnotes { 191 | border-top: 1px solid #ddd; 192 | margin-top: 50px; 193 | 194 | &:before { 195 | content: "Footnotes:"; 196 | font-weight: 600; 197 | margin-top: 30px; 198 | display: inline-block; 199 | margin-bottom: 20px; 200 | } 201 | 202 | hr { 203 | display: none; 204 | } 205 | } 206 | } 207 | } 208 | 209 | .theme-doc-sidebar-menu { 210 | font-size: 13.5px; 211 | } 212 | 213 | .tippy-box { 214 | padding: 8px; 215 | } 216 | 217 | .tippy-content p:last-child { 218 | margin-bottom: 0 219 | } 220 | 221 | @media (max-width: 736px) { 222 | .markdown h1:first-child { 223 | font-size: 24px; 224 | } 225 | 226 | .markdown>h3 { 227 | font-size: 18px; 228 | margin-top: 35px; 229 | margin-bottom: 10px; 230 | } 231 | } 232 | 233 | @import url('https://fonts.googleapis.com/css2?family=Fira+Code:wght@300;400;500;600;700&display=swap'); 234 | 235 | #constitution { 236 | background: #f4f4f4; 237 | border: 1px solid #ddd; 238 | border-left: 2px solid #28a0f0; 239 | color: #666; 240 | page-break-inside: avoid; 241 | font-family: 'Fira Code', monospace; 242 | font-size: 14px; 243 | line-height: 1.6; 244 | margin-bottom: 1.6em; 245 | max-width: 100%; 246 | overflow: auto; 247 | padding: 50px; 248 | display: block; 249 | word-wrap: break-word; 250 | white-space: pre-wrap; 251 | 252 | h3 { 253 | font-family: 'Fira Code', monospace; 254 | margin-top: 40px; 255 | } 256 | } 257 | 258 | article a:not([data-quicklook-from]):not(.footnote-ref) { 259 | text-decoration: underline; 260 | } 261 | .docusaurus-mermaid-container{ 262 | display: flex; 263 | justify-content: center; 264 | } 265 | #pending-constitution-notice{ 266 | font-style: italic; 267 | font-size: 12px; 268 | } -------------------------------------------------------------------------------- /src/pages/index.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import { Redirect } from 'react-router-dom'; 3 | 4 | /** 5 | * This page is needed because Docusaurus complains if there is no index page. 6 | * The client-side redirect is here as a fallback, as Vercel should handle the redirect. See vercel.json. 7 | */ 8 | export default function Home() { 9 | return ; 10 | } 11 | -------------------------------------------------------------------------------- /src/theme/DocItem/Content/index.js: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import Content from '@theme-original/DocItem/Content'; 3 | import { HeaderBadges } from '@site/src/components/HeaderBadges'; 4 | 5 | export default function ContentWrapper(props) { 6 | return ( 7 | <> 8 | 9 | 10 | 11 | ); 12 | } 13 | 14 | // This file was generated via `yarn swizzle @docusaurus/theme-classic DocItem/Content` - I selected `wrap` when prompted and then imported & injected the `HeaderBadges` widget. Lines :3 and :9 are the only additions I made. 15 | // docs -> https://docusaurus.io/docs/next/swizzling#wrapping 16 | // other docs -> https://docusaurus.io/docs/next/markdown-features/react#mdx-component-scope 17 | // note that the "other docs" recommend wrapping `@theme/MDXComponents` but this is no longer possible as of docusaurus v2. 18 | -------------------------------------------------------------------------------- /src/theme/Footer/index.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import Footer from '@theme-original/Footer'; 3 | import { Quicklooks } from '@site/src/components/Quicklooks'; 4 | 5 | export default function FooterWrapper(props) { 6 | return ( 7 | <> 8 | 9 |