# The Ethereum Eagle Project (EGL) EGL is a community led effort to solve the misalignment of incentives and lack of transparency between the community (e.g. users, core devs, DApps) and miners in the Ethereum ecosystem. Our primary focus is to align incentives and enable coordination between the community and miners in a way that maximizes value for all Ethereum stakeholders. Following in the footsteps of Flashbots, this effort builds upon the phenomenon of community initiatives focused on tackling protocol level attributes without requiring a protocol change. **Specifically, EGL introduces a coordination token to allow holders to vote on what their individual desired Ethereum Gas Limit is, and reward miners (pools) for listening to the community and user preferences.** ## **The Problem** Mining pools control the block gas limit and their incentives for determining the "right" gas limit are different than the community's and they may not know what the "right" limit . Concurrently, the community (users) rant on Twitter about "fees being too high" but they have no mechanism to affect it. EGL aims to solve this coordination problem between miners and users. All ETH holders ought to care about the block gas limit because it directly affects Ethereum's throughput (TPS/scalability) and user transaction fees. This is because the gas limit sets the block's transaction supply (i.e. how many transactions can fit in a block) and thus the transaction fee auction. EGL's design is simple, yet elegant. ## The Solution EGL holders vote on what their individual desired Ethereum block gas limit is, and rewards miners for listening to the community and user preferences. Additionally, EGL creates an economic incentive for the community to research, vote and ultimately discover what the “economically efficient” gas limit is and rewards mining pools for listening and taking the economic risk of listening to them. EGL builds on Ethereum’s experiment of moving some parameters away from core devs to miners, by giving some of that power back to not only core devs, but also the entire community. Key Insight: on-chain voting tokens are nothing new, yet EGL’s novelty lies in: * Identifying that pools can be incentivized with EGLs to take into consideration the ecosystem’s preference. * Bootstrapping EGLs using Balancer to spin the flywheel {% embed url="" %} # Key Functionality The Eagle Project defines an ERC-20 token which allows its holders to vote on their desired value for Ethereum's Gas Limit (`desiredEgl`), and incentivizes pools to follow their collaborative decision. The key functions of the EGL smart contract are: 1. Allowing EGL holders to vote on their desired gas limit. 2. Weekly tally, which gradually adjusts `desiredEgl`. 3. Awarding pools with EGLs when they mine blocks following the vote, adjusted according to how closely they match `desiredEgl`. 4. Creating an ETH-EGL market, to ensure pools are immediately incentivized to follow the EGL vote. {% embed url="" %} # EGL Genesis ETH holders can support the EGL Genesis by sending ETH to the EGL launch contract. The ETH sent will be matched with 750,000,000 EGLs and deployed to a Balancer ETH-EGL pool. The resulting *balancer* *pool tokens (BPT)* will be held by the EGL smart contract, and gradually released to the Genesis supporters. Furthermore, an additional 500,000,000 EGLs are awarded to supporters, allowing them to actively vote on their desired gas limit.\ \ Contract Address:[ 0x21Df223E4cc9F270383e33BCdDBc25F27cf7aE96](https://etherscan.io/address/0x21Df223E4cc9F270383e33BCdDBc25F27cf7aE96) ## Genesis closed on August 13, 2021 at 6am PT The EGL Genesis closed on August 13, 2021 at 6am PT with 10,806.88 ETH Stake, worth \~$35M and matched with 1.25B EGLs worth, at the time, \~$58M! \ \ The tokens were sent to an [ETH-EGL Balancer Pool](https://app.balancer.fi/#/pool/0xB0401AB1108BD26C85A07243DFDF09F4821D76A200020000000000000000007F) and the voting contract was deployed by the multisig holders. EGL Token Contract: [0x1e83916Ea2EF2D7a6064775662E163b2D4C330a7](https://etherscan.io/token/0x1e83916Ea2EF2D7a6064775662E163b2D4C330a7)\ EGL Voting Contract: [0xE9a09e0032D1aB5Ce4bF09149ef746258252Bd0B](https://etherscan.io/address/0xE9a09e0032D1aB5Ce4bF09149ef746258252Bd0B) Balancer Pool Token: [0xB0401Ab1108BD26C85A07243dFDF09F4821D76a2](https://etherscan.io/address/0xB0401Ab1108BD26C85A07243dFDF09F4821D76a2) {% embed url="" %} # Genesis ## Genesis The EGL smart contract awards Genesis Supporters with 1.250 Billion EGLs, equaling the amount of EGLs awarded to incentivize mining pools (1.25 Billion). This amount is awarded in two forms: * **Matching EGLs:** 750M EGLs (out of the total 4 Billion EGLs) * **Bonus Voting EGLs:** 500M EGLs to allow Supporters to participate in the weekly vote EGL favors long term Supporters - those who stake ETH for longer durations - and awards more EGLs to later supporters. Thus, earlier supporters have their tokens released sooner ([Release Schedule)](/protocol-overview/launch/eth-egl-release-schedule), while later Supporters receive more Bonus Voting EGLs. ## Matching Any ETH holder can participate in the Genesis and stake ETH to the EGL Genesis contract. In turn, the EGL smart contract will: * Collect ETH until 100,000 ETH is staked (`cumulativeBalance`) * Match ETH with 750M EGLs (doubling the value), and deploy ETH and EGLs to a Balancer ETH-EGL pool. * Award 500M Bonus Voting EGLs to allow Supporters to vote on `desiredEgl`. Supporters are awarded a substantial amount of EGLs for staking in the Genesis and bootstrapping EGL. {% hint style="info" %} The Genesis contract will close following the transaction that pushes `cumulativeBalance` above the threshold or after 1 week. Thus, more than 100,000 ETH may be staked if the last transaction plus the prior amount staked is more than 100,000 ETH. {% endhint %} ## Bonus Voting EGLs An additional 500M EGLs are awarded to Genesis Supporters to be used for voting. The exact amount each supporter receives depends on: * The total amount of ETH staked for matching * The Supporter's "place in line" Specifically, EGL keeps track of the number of EGLs used for matching (which is capped at 750M). Assuming `totalEglsMatched=x` prior to the Supporter Tx and `totalEglsMatched=y`after the Supporter Tx, the supporter will be matched with `x-y` and will be awarded: $$ (y^4-x^4)/(\frac{81}{128}) \* 10^{27}) $$ where, $$ y = \frac{\text{TotalETH staked at Genesis}}{750M EGLs} \* \text{cumulative ETH staked after you contribute} $$ $$ x = \frac{\text{TotalETH staked at Genesis}}{750M EGLs} \* \text{cumulative ETH staked before you contributed} $$ Thus: * the Supporter who got matched with the first 1M EGLs receives: $$(1M^4 - 0^4)/((\frac{81}{128})\*10^{27})=0.00158$$ EGLs * the Supporter who got matched with the median 1M EGLs receives: $$(350M^4 - 349M^4)/(\frac{81}{128}\*10^{27})= 269,853.07496$$ EGLs * the Supporter who got the matched with the last 1M EGLs receives: $$(750M^4 - 749M^4)/(\frac{81}{128}\*10^{27})=2,661,338.07249$$ EGLs {% hint style="danger" %} Bonus EGL amounts may be slightly off due to rounding errors. Solidity can only store up to `.16E+77`this means formulas are only accurate up to 10 decimal places. {% endhint %} # Release Schedule ## Matching EGLs The ETH and EGLs deployed to the Balancer ETH-EGL pool entitles Supporters to the received [*Balancer Pool Tokens*](https://balancer.gitbook.io/balancer/core-concepts/protocol/pool-lifecycle) (*BPTs)*. These tokens are released in a FIFO schedule, over a period ranging between 70 and 364 days after the voting contract launch. The basic idea of the release is as follows: when *X%* of the lockup period passes, the first *X%* of the EGLs matched are released, and therefore the pool tokens which correlate to these EGLs are released. As outlined in [Genesis Rewards](/protocol-overview/launch/untitled), the EGL smart contract tracks the amount of EGLs matched (`totalEglsMatched`). For each Supporter, `totalEglsMatched`is recorded both before and after, providing liquidity in a range format `(start,stop)` , as well as the `poolTokensDue`. At any given time, the last EGL released is 0 if 10 weeks have not passed since the launch, and otherwise computed as follows: * `lockupTimePassed= currentTime-launchTime- 10*7*24*60*60` * `lockupPercentile= lockupTimePassed/(364-70)*24*60*60` * `lastEglReleased = lockupPercentile^4 * 750,000,000` Using `lastEglReleased`, the number of BPTs to be released for a specific Supporter is 0 if `lastEglReleased <= start`, and otherwise: `poolTokensDue * (lastEglReleased - start) / (stop-start)` At any given time, a supporter may call `withdrawPoolTokens()` to withdraw all their released pool tokens. To find when your individual BPT tokens will be released: $$ \text{First BPT Release Date} =(\frac{\text{first\_serialized\_EGL}}{750,000,000})^{1/4}\* 294 + 70 $$ $$ \text{Last BPT Release Date} = (\frac{\text{last\_serialized\_EGL}}{750,000,000})^{1/4}\* 294 + 70 $$ where, $$ \text{ETH:EGL Genesis Ratio}: \frac{\text{Total ETH staked at Genesis}}{\text{750,000,000 EGLs}} $$ $$ \text{last serialized EGL} = \text{ETH:EGL Genesis Ratio} \* \text{cumulative ETH staked after you contribute} $$ $$ \text{first serialized EGL} = \text{ETH:EGL Genesis Ratio} \* \text{cumulative ETH staked before you contributed} $$ ## Bonus Voting EGLs Supporters are awarded additional EGLs (see [Launch Rewards](/protocol-overview/launch/untitled#liquidity-voting)) based on their "place in line". These EGLs allow Supporters to participate in the gas limit vote, as well as earn [Voter Rewards](/protocol-overview/voting). These Bonus EGLs may be withdrawn once all the Supporter's BPTs are released, as outlined above, unless the Supporter chooses to extend their lockup further using `reVote()` (see [Voting](/protocol-overview/voting)). Thus, for a given supporter, BPT tokens have a gradual release schedule, while Bonus Voting EGLs are released all at once with the last BPT token release. {% hint style="warning" %} All the EGLs used to vote from a Genesis participant's wallet address - regardless of how they were acquired - will be locked for the entirety of the lockup. {% endhint %} {% hint style="info" %} We've created a[ spreadsheet](https://docs.google.com/spreadsheets/d/1vdpZF6vDZkM1axpoc3cP1rAy2tD3J3VwOPe7coVELE4/edit#gid=0) to help with calculating their BPT Tokens, Bonus Voting Tokens, and release yourself. You can also use the spreadsheet to see how many EGLs you received. You can also go to [EGL.vote](http://www.egl.vote) or query the contract directly. {% endhint %} ## # Balancer Deployment The ETH-EGL pool will be created once Genesis closes and just before the Voting contract is deployed. The funds collected from Genesis will be transferred automatically to a multisig wallet once the Genesis period has ended. At this point, the multisig will have both the ETH and the EGL's required to created the Balancer pool. The Balancer pool is created by forming the transactions to the relevant Balancer V2 contracts (see [Balancer docs](https://docs.balancer.fi/developers/guides/pool-creation) for more details) for the multisig to sign and execute. Once executed, the pool will be funded with ETH-EGL's and is ready for use. Finally, once the EGL voting contract is deployed, the multisig will transfer all BPT tokens received from creating the pool to the voting contract to be released on the schedule defined in [Release Schedule](/protocol-overview/launch/eth-egl-release-schedule). All remaining EGL's will also be transferred from the multisig to the voting contract for it to distribute as necessary # Voting EGL’s primary function is to vote on a `desiredEgl`, which is adjusted in weekly tallies. Pools are then incentivized to follow the `desiredEgl`. Contract Address: [0x1e83916Ea2EF2D7a6064775662E163b2D4C330a7](https://etherscan.io/token/0x1e83916Ea2EF2D7a6064775662E163b2D4C330a7) {% embed url="" %} # Vote, Revote, Withdraw ## **Timeline** EGL voting works in weekly epochs, using the block's timestamps. At the end of each week the votes are tallied (`tallyVotes()`) and the `desiredEgl` is updated (see [Calculating desiredEgl](/protocol-overview/voting/calculating-desiredegl)). The first vote is to be calculated one week after the EGL smart contract is launched and every week thereafter. Votes may be cast using `vote()` or `revote()` at any time, up until 4 hrs before the weekly tally is scheduled to take place. `tallyVotes()` can be called directly by anyone once an epoch has ended, or indirectly by any `vote()`, `revote()`, or `withdraw()` calls. {% hint style="warning" %} You cannot vote or revote within 4 hours of a given epoch ending. EGL.vote will not allow you to vote, but if you call the contract directly within this time period, your vote will fail. {% endhint %} ## **Lockup** To cast a vote, an EGL holder must lock up some amount of EGLs (`eglAmount`) for a period of 1-8 weeks (`lockupDuration`) . The lockup starts from the time of the `vote()`or `revote()` Tx being mined. Therefore, a voter who votes on Wednesday Jan 1st at noon and specifies `lockupDuration=2` will be able to withdraw said EGLs on Wednesday Jan 15th at noon. It is possible for voters to adjust their vote using `revote()` (outlined [below](/protocol-overview/voting/vote-revote-withdraw#vote-withdraw-and-revote)), however the locked `eglAmount` will not be released any sooner. ## `vote()`, `withdraw()` and `revote()` To keep the design as clean and simple as possible: * `vote()` can only be called if the wallet/address has no active vote nor EGLs locked or uncollected. * `withdraw()` withdraws *all the EGLs* including [Voter Reward](/protocol-overview/voting/rewards), leaving a clean slate, and can be called after the lockup has expired. * `revote()` calls `withdraw()` *internally,* cleaning any existing votes and their effect on the vote, collecting any rewards, and then calls `vote()` *internally* using the original `eglAmount` plus any reward tokens due as the new `eglAmount`, but ensuring the EGLs release date is the later between * The existing vote (now removed) * The new vote, based on current time and `lockupDuration`. {% hint style="info" %} Revote can be used in two ways: 1) to change your vote when EGLs are locked and owned by the contract (i.e. not available for withdrawal) and 2) to submit a new vote when EGLs are in the contract but available for withdrawal. {% endhint %} ## Maintaining Votes for Multiple Epochs Votes can be cast for up to `8` weeks into the future, thus at any given time the EGL smart contract maintains `8` sets of variables to track the weight-averaged desired change to `desiredEGL`, and `vote()` and `revote()` affect the relevant variables depending on their `lockupDuration`. Once `tallyVotes()` is called and `desiredEGL` is adjusted, the values for each epoch are advanced by 1 slot, and the last (8th) variables are initialized with 0. # Calculating desiredEgl The initial value for `desiredEGL` at launch will equal the current gas limit at launch, e.g. 15M gas. Each vote specifies the voter’s desired `gasTarget`, as well as an `eglAmount` and `lockupDuration`, and the weekly tally calculates the weighted average of all the votes’ `gasTarget` to determine the `desiredEGL`. The votes are weighted based on `eglAmount` (the more EGLs you use, the stronger your vote) and `lockupDuration` (1 to 8 weeks; the longer you lockup your EGLs, the stronger your vote). Specifically, weight = `eglAmount` \* `lockupDuration` , and the weighted average is calculated as $$ \frac{\sum\_i (targetGasLimit\_i \* weight\_i)}{ \sum\_i weight\_i} $$ `desiredEGL`is calculated by storing and updating 2 variables: 1. sum of all voters’ `eglAmount` \* `lockupDuration` 2. sum of all voters’ `eglAmount` \* `lockupDuration` \* `gasTarget` {% hint style="info" %} When `tallyVotes()` is called, the weighted average is calculated, and `desiredEGL` is adjusted towards it, but by no more than 1M gas. {% endhint %} To avoid manipulation of the weighted average by using very high / low values for `gasTarget`, the value of `gasTarget`must be close to the actual gas limit of the block in which the `vote()`/`revote()`Tx is mined. {% hint style="info" %} If the `desiredEGL` is within 10,000 of the `tallyVotesGasLimit,`functionally the community is voting to keep the gas limit the same. For simplicity, the`desiredEGL` will be set to`tallyVotesGasLimit.` {% endhint %} Specifically, the delta between the two must be no greater than 4M gas. To protect honest users from having their Tx fail due to jitters in the gas limit, the UI provided at [egl.vote](https://docs.egl.vote/protocol-overview/voting/www.egl.vote) allows a delta of up to 3M gas between `gasTarget`and the current gas limit. Sophisticated users can of course bypass this limitation, and carry the risk of having their Tx fail. If your vote for a given epoch was within 4M of the gas at the time of the vote, but you've locked in your vote for several weeks and now it is outside of the 4M range, it will *still* be included in the `desiredEGL` calculation. For example, if you voted for 7M gas when the current gas was 10M and now the current gas is 13M, your 7M vote will still be included as (7M \* your multiplier) in the calculation. However, remember that the `desiredEGL` cannot change by more than 1M each week. {% hint style="danger" %} `desiredEGL` is calculated when `tallyvotes()` is called for the first time after the epoch has ended. Thus, someone needs to call `tallyvotes()` after an epoch has ended to ensure `desiredEGL` is calculated. {% endhint %} # Voting Threshold ## Voting Threshold For `tallyVotes()` to “pass” and adjust `desiredEGL`, enough EGLs must participate to meet the `votingThreshold`, which is defined as a % of `eglsInCirculation`. `eglsInCirculation` is calculated as the sum of EGLs at the time `tallyVotes()` is called that were: 1. Swept by pools 2. Distributed and claimed (i.e. used to vote at least once) by Core Devs 3. Distributed and claimed (i.e. used to vote at least once) by Genesis participants 4. Deployed to Balancer as part of the Genesis (i.e. 750M tokens) 5. Calculated as Voter Rewards (i.e. when `withdraw()` is called) 6. Unlocked and sent to EGL Creators 7. Distributed by the EGL DAO See [Token Distribution](/protocol-overview/token-distribution) for details. The `votingThreshold` is initialized at 10% of the `eglsIncirculation`for the first 7 epochs, after which it jumps to 30% for the remaining 45 epochs (totaling 52 epochs) after the EGL launch, and then gradually increases every epoch at a rate of 10% / year to a maximum of 50%: $$threshold\_i =10%$$ , if i <= 7 $$threshold\_i =30%$$ , if 7 < i < 52 $$threshold\_i = min(50%, (((i+1)/52)-1) \* 10% + 30%)$$, if i ≥ 52 {% hint style="info" %} i = 0 for the first epoch {% endhint %} ## Unfavorable Default Vote Behavior If the `votingThreshold` is not met, the tally does NOT leave the `desiredEGL` unchanged. Instead, in order to incentivize voter participation, the default behavior is to gradually undo the change since EGL launch, which is very likely a negative outcome for EGL voters. Specifically, the default behavior sets the `desiredEGL` to 95% of the `tallyVotesGasLimit` (the gas limit of the block that the successful `tallyvote()` was called in). For example, assume: 1. EGL the `tallyVotesGasLimit` is 15M gas. 2. The voted on `desiredEGL` is 16M. 3. At some point in the future the `votingThreshold` is not met. After the vote, the new `desiredEGL` would be 14.25M (15M \* 95%) since the threshold wasn't met. ## Grace Period The aforementioned default behavior does not take place for a grace period of 7 epochs (weeks) from smart contract launch. Thus, in the first 7 weeks, if a vote does not meet the threshold, `desiredEGL` stays the same (e.g. what it was in the prior week). # Rewards The Voter Reward incentivizes the initial participation in EGL voting in the first year (52 weekly votes). The voter reward is not actively awarded to voters; rather, voters collect it when they call `withdraw()`or `reVote()`. ## Voter Reward Amount The Voter Reward is awarded in the first 52 weekly votes (index 0 to 51), and its amounts are calculated using the following formula: $$ reward\_i= 362,844.70 · (52-i) $$ Thus, it gradually reduces from $$reward\_0 = 18,867,924$$EGLs in the first tally, to$$reward\_{51} = 362,844.70$$EGLs in the 52nd tally. ## Voter Share Size The Voter Reward is shared each week among the EGL voters who actively voted in said week to affect the `desiredEgl`. The amount distributed each week is fixed (see below) and the share of each voter depends on the `lockupDuration` and `eglAmount` she specified in the `vote()` or `reVote()`. The share size for $$voter\_j$$ is calculated as: $$ share\_j = EGLs\_locked · lockup\_period $$ while$$voter\_j's$$ EGL reward in week i is calculated: $$ reward\_j = share\_j \* reward\_i $$ For example, given the following voters in a week: * $$voter\_1$$ locks up 10 EGLs for 1 week (Share1 = 10 · 1 = 10) * $$voter\_2$$ locks up 10 EGLs for 2 weeks (Share2 = 10 · 2 = 20) * $$voter\_3$$ locks up 20 EGLs for 1 week (Share3 = 20 · 1 = 20) $$voter\_2$$ will be rewarded $$20/50$$ or 40% of the weekly EGL reward (e.g. · Reward1)
# Leaderboard EGL is designed to coordinate a desired gas limit that reflects the view of the entire community. We've provided a leaderboard so voters can take into consideration how other stakeholders in the community have voted. The leaderboard shows votes for the *current* epoch and ranks votes based on their weight (EGLs voted x weeks). The board can be filtered by [EGL Signals](/protocol-overview/the-dao/core-devs).
# Mining Pool Reward Pools are able to sweep EGLs when they produce a block with a gas limit within 1M gas of `desiredEGL` that is directionally correct. Each time `sweepPoolRewards()` is called, the potential (i.e. maximal) Pool Reward is calculated, and then the exact amount is calculated depending on how close the block’s gas limit matches `desiredEGL`. The potential Pool Reward in each block is calculated as a small percentage of the remaining Pool Reward - specifically, `potentialReward` =`remainingPoolReward` \* 0.0000004. Thus, the potential reward immediately after the launch, while the remaining Pool Reward is 1.250B EGLs is 500 EGLs. A pool sweeping EGLs will be awarded 25% of the potential Pool Reward for mining a block with a gas limit directionally correct up until the gas equals the `desiredEGL` plus 10,000. The remaining 75% is awarded based on how close the block’s gas limit is to the `desiredEGL`. A pool will receive all 75% for a gas limit which exactly matches `desiredEGL`, 0% if it is at the current gas limit at the time of tally vote, 37.5% for a gas limit which it is half way to the `desiredEGL`. For example: * `desiredEGL` = 16,000,000 * `tallyVotesGasLimit` = 15,000,000 Thus, * Direction = up (16,000,000 - 15,000,000 >0) * Buffer = 10,000 Thus if a pool mines a block that has a higher gas limit than the previous block, they will receive 25% of the reward EGLs as long as the block is less than 16,010,000 (`desiredEGL` + buffer). If a pool mines a block between 15,000,000 and 16,000,000, she will receive a portion of the remaining 75% of the miner reward and if she mines a block at 16,000,000 she will receive all 100% of the EGL reward. In this example: | Block’s gas limit | Direction | % of potential pool reward | | ------------------ | --------- | -------------------------- | | <15.0M | Down | 0% | | 15.0M | Up | 25% | | 15.5M | Up | 25% + (75% \* 50%) | | 16.0M | Up | 25% + (75% \* 100%) | | >16.0M, <= 16.010M | Up | 25% + (75% \* 100%) | | Any number | Too high | 0% | The `desiredEGL` is considered to be "the same" as the current gas limit if `desiredEGL` is within 10,000 of the `tallyVotesGasLimit` (see [Calculating desiredEgl](/protocol-overview/voting/calculating-desiredegl)). In this case, if a miner produces a block +/- 10,000 from the `tallyVotesGasLimit` it will receive 100% of the miner reward. For example: * `desiredEGL` = 15,005,000 * `tallyVotesGasLimit` = 15,000,000 Thus, * Direction = same (abs(15,005,000 - 15,000,000 ) <10,000) * Buffer = 10,000 In this example: | Block’s gas limit | Direction | % of potential pool reward | | --------------------- | --------- | -------------------------- | | <14.995M | down | 0% | | =>14.995M, <= 15.015M | same | 25% + (75% \* 100%) | | >15.015M | up | 0% | {% hint style="info" %} For the first week of voting (before the 1st desired gas limit has been set by EGL holders) the desired gas limit will be equal to the gas limit of the block that had the create contract transaction (i.e. the current gas limit). Thus, during the first week miners will only need to call the [`sweepPoolRewards()`](/documentation/functions-1)to claim EGLs. {% endhint %} # The DAO ### EGL DAO The EGL DAO is allocated 250M EGLs, which can be spent for any purpose by the EGL holders, and is intended to be used to fund development of future upgrades, security audits, code audits, etc. A multisig wallet controls the EGL contract, including the DAO, and requires 3 of 5 signatures for a transaction to be approved (see the [governance ](/governance-model)section for more information). ### Elevating Community Voices To highlight important voices in the ETH community that may serve as an information signal of what the community's desired gas limit ought to be, 50M EGLs are to be distributed core devs, including client teams. We call this group [EGL Signals](/protocol-overview/the-dao/core-devs). These EGLs can be used to vote like any other EGL, can be locked for a duration of 1-8 weeks, and can collect Voter Rewards, with the exception that no amount of EGLs can be withdrawn after 1 year from the deployment of the EGL smart contract. {% embed url="" %} # EGL Signals ## Why have EGL Signals? Building on Bitcoin and Ethereum's experimentation with who should control the gas limit / block size, EGL builds on Ethereum’s experiment of moving some parameters away from core devs to miners, by giving some of that power back to not only core devs, but also the entire community. Core devs have the greatest insight to the nodes’ technical limitations, and their opinions should carry significant weight. Thus, EGLs will be awarded to all interested core devs, both to directly affect the EGL vote, and to signal to other actors their respective opinions. EGL Signals must vote with their EGLs to be able to withdraw them when they unlock. This is to ensure that EGL voices are indeed a signal for the community. Awarded EGLs are locked for an entire year before they can be withdrawn. ### Who are core devs? There is no set list of who exactly is a core dev. From speaking with those in the community, it seems clear that client teams should have a say, as well as anyone that has authored an EIP that was implemented into production. This may leave out some thought leaders and researchers, and we rather cast a wide net than be exclusive. {% hint style="info" %} If you think you ought to be included on this list, please reach out to . Signals can only be added up 70 days post launch. {% endhint %} ## How to vote? EGL Signal holders can use egl.vote with their wallet listed on the [allocations page](/protocol-overview/the-dao/core-devs/allocations). With your first vote, your EGLs will be claimed and locked for the compulsory year from launch. EGLs that are used to vote can participate in the weekly voter rewards. {% hint style="warning" %} Similar to wallet addresses that participated in Genesis, all the EGLs used to vote from a Signal's wallet address - regardless of how they were acquired - will be locked for the entirety of the lockup. {% endhint %} ## Can EGL Signals participate in Genesis? Yes! However, you must use a different wallet address than the one you're using for EGL Signals. # Allocations | Name | Awarded EGLs | | --------------------------------------------------------------------------------------------------------- | ------------ | | [Alberto Cuesta Cañada](https://github.com/albertocuestacanada) | 1,500,000 | | [Alex Vlasov](https://github.com/shamatar) | 1,500,000 | | [Artem Vorotnikov](https://twitter.com/vorot93?lang=en) | 1,500,000 | | [Boris Petrov](https://twitter.com/b00riscd?lang=en) | 1,500,000 | | [James Hancock](https://github.com/madeoftin) | 1,500,000 | | [James Prestwich](https://twitter.com/_prestwich?lang=en) | 1,500,000 | | [John Adler](https://twitter.com/jadler0?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) | 1,500,000 | | [Matt Garnett](https://garnett.dev/) | 1,500,000 | | [Giulio Rebuffo](https://twitter.com/GiulioRebuffo) | 1,500,000 | | [Micah Zoltu](https://github.com/MicahZoltu) | 1,500,000 | | [Philippe Castonguay](https://github.com/PhABC) | 1,500,000 | | [Alexey Sharp](https://twitter.com/realledgerwatch?lang=en) | 1,500,000 | | [Eugene Danilenko](https://github.com/JekaMas) | 1,500,000 | | [Scott Bigelow](https://twitter.com/epheph?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) | 1,500,000 | | [Alex Sharov](https://github.com/AskAlexSharov) | 1,500,000 | | [Igor Mandrigin](https://twitter.com/mandrigin) | 1,500,000 | | [G. Nicholas d'Andrea](https://twitter.com/gnidan?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) | 1,500,000 | | [Andrea Lanfranchi](https://github.com/AndreaLanfranchi) | 1,500,000 | | [Kaushik Donthi](https://github.com/kdonthi) | 1,500,000 | # Token Distribution Up to 4 Billion EGLs can be minted and distributed, with half of the value going to the ETH community (2B EGLs) and another 1.25B EGLs going to miners. Specifically, ![](/files/-Md2QcnDOJm_Xn4Uqqfd) ## ETH Community Half of the EGLs - 2B out of 4B - is awarded to the ETH community, specifically to: * **Genesis Supporters** who help bootstrap EGL * **Voter Reward** to incentives usage * **Core Devs**, whose different opinions are key to guide community * **DAO** treasury to support and fund future developments, audits, or any other cause chosen by the EGL holders. ## Mining Pools Mining pools are awarded EGLs whenever they mine a new block, depending on how closely they follow the community's desired gas limit (`desiredEgl`). This reward gradually decreases over time, since the initial incentive - needed to persuade pools to alter their behavior and adhere to the EGL vote - is much greater than the incentive required for pools to *continue* doing so in the long term. The total amount is of EGLs awarded to pools is capped at 1.25B EGLs. ## EGL Creators EGL creators and early backers of the project are awarded 750M EGLs. These EGLs are gradually minted over a period starting 9 weeks after the Launch, and ending 52 weeks after it. They are released on the same schedule at Genesis participants, which the majority of the tokens being released close to week 52. From the Creators pool, a portion of the tokens are for a handful of investors that provided the necessary seed capital to fund development. They have the same lockup as the Creators. # Architecture https\://github.com/eglvote ## EGL Genesis Contract Contract Address:[ 0x21Df223E4cc9F270383e33BCdDBc25F27cf7aE96](https://etherscan.io/address/0x21Df223E4cc9F270383e33BCdDBc25F27cf7aE96) ![](https://lh4.googleusercontent.com/dGmf4gQssR1dGs5GxuhvqnUxw8sOTxAdtMSNOp2OqGwzU8YNSz-Mq43DzAZz0SFIvDRLeADTsQfflPIwFkMx4R1RdU_Ecph91Ca8EpRRyZmrULlZO7uESFHfPAJHtCm7UDfDjfsL) ## **EGL Voting Contract** Contract Address: [0xE9a09e0032D1aB5Ce4bF09149ef746258252Bd0B](https://etherscan.io/address/0xE9a09e0032D1aB5Ce4bF09149ef746258252Bd0B) ![](https://lh4.googleusercontent.com/mFYdy922AVnrfo7gx6OVKmhZt0Kq2W0wU2NAQiOx9iOamvuYyM2tHceeTeGRZtNxzJW5nT7ekjzzHhHCitkGMw_s85WkkSuU5d336S3WVLOvTrO6DCkceeY3lMOZHXrYRiG16lfl) # Voting Public Functions There are 2 functions that support voting - 1. `vote` - used when the wallet/address has no active vote nor EGLs locked or uncollected 2. `reVote` - used to either change an existing votes parameters (gas target, lockup duration and/or number of EGL's voted with), or to submit a new vote if the existing vote has elapsed (exceeded the lockup duration) without first withdrawing the EGLs to a wallet address See [Voting](/protocol-overview/voting/vote-revote-withdraw) for more details ### 1.**`vote()`** Allows any wallet with EGL's to submit a vote to affect the weekly desired gas limit value {% hint style="warning" %} Since any vote requires you to spend some amount of EGL's, it is necessary to ensure the voting contract has a sufficient `allowance` to spend that amount of EGL's for the vote on your behalf. If the allowance is set high enough, this only had to be done once {% endhint %} {% hint style="info" %} The `_eglAmount` parameter *must* be passed in as the wei value, i.e. the EGL token uses 18 decimal places so 1 EGL = 1000000000000000000 wei {% endhint %} {% hint style="info" %} This function will additionally call `tallyVotes()` if the current voting period (epoch) has elapsed and the vote for the previous period has not yet been tallied. See [Tally Votes](/documentation/tally-votes) {% endhint %} #### Function Signature ```javascript function vote(uint _gasTarget, uint _eglAmount, uint8 _lockupDuration) external whenNotPaused ``` | Parameters | **Data Type** | Description | Example | | ----------------- | ------------- | ------------------------------------------------------------------------------------------------ | -------------------- | | `_gasTarget` | `uint256` | The gas limit value you are voting for (must be + / - 4,000,000 of the current blocks gas limit) | 16500000 | | `_eglAmount` | `uint256` | The amount of EGLs to be locked and used for voting (Must be >=1 EGL) | 10000000000000000000 | | `_lockupDuration` | `uint8` | The number of weeks your vote will be locked up for (valid values are numbers 1 through 8) | 6 | #### Validations | Validation **Rule** | Description | | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | `_eglAmount >= 1 ether` | Amount being voted with must be greater than 10000000000000000000 (1 EGL) | | `_eglAmount <= eglToken.balanceOf(msg.sender)` | The voting address must have a balance that is at least equal to the amount being voted with | | `eglToken.allowance(msg.sender, address(this)) >= _eglAmount` | The voting contract must a have an allowance from the voter of at least the voting amount | #### Events Emitted * `VotesTallied` (Conditional) * `Transfer` * `Vote` #### Web3 Example ```javascript // Allowance await eglTokenInstance.increaseAllowance( eglContractInstance.address, web3.utils.toWei("5000"), { from: "0x2be650ba..." } ); // Vote await eglVotingInstance.vote( 15500000, web3.utils.toWei("100"), 4, { from: "0x2be650ba..."} ) ``` #### ### 2. **`reVote()`** Allows a wallet that already has a vote locked in, to update that existing vote. This function also calculates any rewards that are due to the voter from past weeks (epochs). These rewards are automatically added to the updated vote. It is also possible, but not required, to add additional EGL's to the vote over and above the original vote amount. {% hint style="warning" %} Updating a vote with a shorter `_lockupDuration` will not allow locked EGL's to be released sooner. For example, if a vote was entered with an original `_lockupDuration` of 6 weeks, and 1 week later a `reVote()` was entered with a new lockup duration of 2 weeks, the EGL's will still only be unlocked 6 weeks from the original vote date, i.e. the unlock/release date is set to the`max(originalLockupDuration, reVoteLockupDuration)` {% endhint %} {% hint style="warning" %} If an additional amount of EGL's is being voted with, over and above the original amount, it is necessary to ensure the voting contract has a sufficient allowance to spend the required amount of EGL's for the vote from your account. {% endhint %} {% hint style="info" %} The `_eglAmount` parameter *must* be passed in as the wei value, i.e. the EGL token uses 18 decimal places so 1 EGL = 1000000000000000000 wei {% endhint %} {% hint style="info" %} This function will additionally call `tallyVotes()` if the current voting period (epoch) has elapsed and the vote for the previous period has not yet been tallied. See [Tally Votes](/documentation/tally-votes) {% endhint %} ```javascript function reVote(uint _gasTarget, uint _eglAmount, uint8 _lockupDuration) external whenNotPaused ``` | Parameters | **Data Type** | Description | Example | | ----------------- | ------------- | ------------------------------------------------------------------------------------------------- | -------- | | `_gasTarget` | `uint256` | The gas limit value you are voting for (must be + / - 4,000,000 of the current gas limit) | 16500000 | | `_eglAmount` | `uint256` | The amount of EGLs, over and above the original vote, to be locked and used for voting (Can be 0) | 0 | | `_lockupDuration` | `uint8` | The number of weeks your vote will be locked up for (valid values are numbers 1 through 8) | 6 | #### Validations | Validation Rule | Description | | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | `voters[msg.sender].tokensLocked > 0` | Voting address must already have a vote locked to use `reVote()` | | `_eglAmount >= 1 ether` | If `_eglAmount > 0`, the amount being voted with must be greater than 10000000000000000000 (1 EGL) | | `_eglAmount <= eglToken.balanceOf(msg.sender)` | if If `_eglAmount > 0`, the voting address must have a balance that is at least equal to the amount being voted with | | `eglToken.allowance(msg.sender, address(this)) >= _eglAmount` | If `_eglAmount > 0`, the voting contract must a have an allowance from the voter of at least the voting amount | #### Events Emitted * `VotesTallied` (Conditional) * `Transfer` (Conditional) * `Withdraw` * `Vote` * `ReVote` #### Web3 Example ```javascript await eglVotingInstance.reVote( 15500000, web3.utils.toWei("100"), 4, { from: "0x2be650ba..."} ) ``` # Claiming EGLs Public Functions If a wallet has participated in Genesis, or has been added as a Signal / Seeder account, they are eligible to claim EGL's. Attempts to claim by any other wallet will result in the function call being reverted and the transaction failing ## **Bonus Voting EGLs** #### 1.**`claimSupporterEgls()`** Allows Genesis supporters to claim their bonus voting EGL's. The bonus voting EGL's are immediately put into a vote upon claiming, so a valid `gasTarget` and `lockupDuration` are required when calling this function. The number of bonus voting EGL's as well as BTP's is calculated when this function is called - see [Release Schedule ](/protocol-overview/launch/eth-egl-release-schedule)for more information The `releaseDate` (date that EGL's are available to withdraw) for Genesis supporters is initially set to 52 weeks from the start of the first vote, although this is updated to the date all BPT's are released, unless the Supporter has chosen to extend their lockup further using `reVote()` {% hint style="info" %} This function will additionally call `tallyVotes()` if the current voting period (epoch) has elapsed and the vote for the previous period has not yet been tallied. See [Tally Votes](/documentation/tally-votes) {% endhint %} #### Function Signature ```javascript function claimSupporterEgls(uint _gasTarget, uint8 _lockupDuration) external whenNotPause ``` | Parameters | Data Type | Description | Example | | ----------------- | --------- | ------------------------------------------------------------------------------------------ | -------- | | `_gasTarget` | `uint256` | The gas limit value you are voting for (must be + / - 4,000,000 of the current gas limit) | 16000000 | | `_lockupDuration` | `uint8` | The number of weeks your vote will be locked up for (valid values are numbers 1 through 8) | 4 | #### Validations | Validation Rule | Description | | -------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | `remainingSupporterBalance > 0` | The contracts remaining bonus voting EGL balance must be greater than 0 | | `remainingBptBalance > 0` | The contracts remaining Balancer pool token balance must be greater than 0 | | `eglGenesis.canContribute() == false && eglGenesis.canWithdraw() == false` | EGL Genesis must be closed | | `supporters[msg.sender].claimed == 0` | The claiming address must not have already claimed their tokens | | `contributionAmount > 0` | The claiming address must have contributed in Genesis | #### Events Emitted * `VotesTallied` (Conditional) * `SupporterTokensClaimed` * `Vote` #### Web3 Example: ```javascript await eglVotingInstance.claimSupporterEgls(15500000, 4, { from: "0x2be650ba..."}) ``` #### ### 2. `claimSeederEgls()` Allow preconfigured signal / seeder accounts to claim their bonus voting EGL's. The bonus voting EGL's are immediately put into a vote upon claiming, so a valid `gasTarget` and `lockupDuration` are required when calling this function. The `releaseDate` (date that EGL's are available to withdraw) for signal / seeder accounts is set to 52 weeks from the start of the first vote {% hint style="info" %} This function will additionally call `tallyVotes()` if the current voting period (epoch) has elapsed and the vote for the previous epoch has not yet been tallied. See [Tally Votes](/documentation/tally-votes) {% endhint %} #### Function Signature ```javascript function claimSeederEgls(uint _gasTarget, uint8 _lockupDuration) external whenNotPaused ``` | Parameters | Data Type | Description | Example | | ----------------- | --------- | ------------------------------------------------------------------------------------------ | -------- | | `_gasTarget` | `uint256` | The gas limit value you are voting for (must be + / - 4,000,000 of the current gas limit) | 16000000 | | `_lockupDuration` | `uint8` | The number of weeks your vote will be locked up for (valid values are numbers 1 through 8) | 4 | #### Validations | Validation | Description | | ------------------------- | -------------------------------------------------------------------- | | `seeders[msg.sender] > 0` | The claiming address must be configured as a seeder / signal account | #### Events Emitted * `VotesTallied` (Conditional) * `SeedAccountClaimed` * `Vote` #### Web3 Example: ```javascript await eglVotingInstance.claimSeederEgls(15500000, 4, { from: "0x2be650ba..."}) ``` # Withdrawing EGLs Once the release date for a vote has been reached, or the lockup period for Genesis supporters and signal / seeder account has expired, the EGLs can be withdrawn from the contract to the voting wallet address. The amount received will be the original voting amount plus any rewards earned from participating in votes ### 1. `withdraw()` #### Function Signature ```javascript function withdraw() external whenNotPaused ``` #### Validations | Validation **Rule** | Description | | -------------------------------------------------- | ------------------------------------------------------------------------------- | | `voters[msg.sender].tokensLocked > 0` | Voting address must already have a vote locked to use `withdraw()` | | `block.timestamp > voters[msg.sender].releaseDate` | EGL's must be available for withdrawal, i.e. the release date must have elapsed | #### Events Emitted * `Withdraw` * `Transfer` #### Web3 Example ```javascript await eglVotingInstance.withdraw({ from: "0x2be650ba..."}) ``` # Withdrawing Pool Tokens Balancer Pool Tokens (BPT's) can be withdraw as they become available. Only those that are available can be withdrawn. The remaining balance stays in the contract until such time that they become available and can be withdrawn. BPT's gradually start to unlock after 10 epochs with the last BPT being unlocked after 52 epochs {% hint style="info" %} See the [release schedule](/protocol-overview/launch/eth-egl-release-schedule#matching-egls) for a detailed breakdown of when the BPT's are released. {% endhint %} ### 1. `withdrawPoolTokens()` #### Function Signature ```javascript function withdrawPoolTokens() external whenNotPaused ``` #### Validations | Validation **Rule** | Description | | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `supporters[msg.sender].poolTokens > 0` | Calling address must have available pool tokens to withdraw | | `block.timestamp.sub(firstEpochStartDate) > minLiquidityTokensLockup` | Cannot withdraw pool token before the minimum lockup period has elapse | | `_supporter.firstEgl <= currentSerializedEgl` | The current serialized EGL must be after the calling addresses first EGL - meaning the calling addresses BPT's have started to be released | #### Events Emitted * `SerializedEglCalculated` * `PoolTokensWithdrawn` * `Transfer` #### Web3 Example ```javascript await eglVotingInstance.withdrawPoolTokens({ from: "0x2be650ba..."}) ``` # Tally Votes At the end of each epoch, the votes cast in that epoch need to tallied to determine the new `desiredEgl` value. This can be called directly by any wallet, or will get called automatically on any `vote(...)` or `reVote(...)` call if the epoch has ended. See [Voting Threshold](/protocol-overview/voting/voting-threshold) for details regarding participation requirements See [Calculating desiredEgl](/protocol-overview/voting/calculating-desiredegl) for details regarding how the `desiredEgl` is calculated ### 1.`tallyVotes()` #### Function Signature ```javascript function tallyVotes() public whenNotPaused ``` #### Validations | Validation **Rule** | Description | | ---------------------------------------------------------- | -------------------------------------------------------------------- | | `block.timestamp > currentEpochStartDate.add(epochLength)` | Epoch must have ended before the votes for that epoch can be tallied | #### Events Emitted * `VoteThresholdMet` (Conditional) * `VoteThresholdFailed` (Conditional) * `CreatorRewardsClaimed` (Conditional) * `VotesTallied` #### Web3 Example ```javascript await eglVotingInstance.tallyVotes({ from: "0x2be650ba..."}) ``` # Setting the gasLimit and gasTarget Miners and mining pools are awarded EGL's when they produce a block with a gas limit that follows the `desiredEgl` vote. Miners can implement a geth patch on their geth node to automatically follow the vote each week. While the node is running, just send the node an RPC request with either `miner_enableEgl` or `miner_disableEgl` to turn following EGL on or off (IPC functions also available). EGL is enabled by default if its configured when the node starts. {% embed url="" %} # Claiming Miner Rewards Public Functions Miners and mining pools are awarded EGL's when they produce a block with a gas limit that is within 1,000,000 of the `desiredEgl`. The reward amount is based on how close the block gas limit is to the `desiredEgl` value. See [Mining Pool Reward](/protocol-overview/miner-rewards) for details The reward must claimed by calling the `sweepPoolRewards()` and rewards for the block it is included in. The function can be called by anyone but the reward always goes to the `block.coinbase` address so the intention is for miners to include this transaction when they produce the block ### 1.`sweepPoolRewards()` #### Function Signature ```javascript function sweepPoolRewards() external whenNotPaused ``` #### Validations | Validation **Rule** | Description | | ---------------------------------- | -------------------------------------------------------------------------------- | | `block.number > latestRewardSwept` | If the reward for the block has already been claimed, it cannot be claimed again | #### Events Emitted * `BlockRewardCalculated` * `Transfer` (Conditional) * `PoolRewardsSwept` #### Web3 Example ```javascript await eglVotingInstance.sweepPoolRewards({ from: "0x2be650ba..."}) ``` #### Python Example This example shows how to create, sign and send the raw transaction which calls `sweepPoolRewards()` ```python import sys from web3 import Web3 if __name__ == "__main__": chainId = int(sys.argv[1]) eglContractAddress = sys.argv[2] accountPvtKey = sys.argv[3] accountNonce = int(sys.argv[4]) w3 = Web3(Web3.HTTPProvider()) transaction = { "to": eglContractAddress, "value": 0, "gas": 78000, "gasPrice": int(10*1e9), "nonce": accountNonce, "chainId": chainId, "data": "0x112bbd1d" } signed_tx = w3.eth.account.sign_transaction(transaction, accountPvtKey) print(signed_tx.rawTransaction.hex()) w3.eth.send_raw_transaction(signed_tx.rawTransaction) ``` # Internal Functions The EGL Voting contract contains multiple internal functions. These include: ### internalVote: ``` function _internalVote( address _voter, uint _gasTarget, uint _eglAmount, uint8 _lockupDuration, uint _releaseTime ) internal ``` Records the details of the vote for a given address and sets up the relevant data structures Emits `Vote` event ### internalWithdraw: ``` function _internalWithdraw( address _voter ) internal returns (uint totalWithdrawn) ``` Removes the vote for a given address and calculates any rewards due Emits `Withdraw` event ### issueCreatorRewards: ``` function _issueCreatorRewards(int _rewardEpoch) internal ``` Calculates the creator rewards for the reward epoch and transfers the rewards to the `creatorRewardsAddress` Emits `CreatorRewardsClaimed` event ### calculateBlockReward: ``` function _calculateBlockReward( int _blockGasLimit, int _desiredEgl, int _tallyVotesGasLimit ) internal returns (uint blockReward) ``` Calculates the potential block reward of the block that would be claimed by the miner of the block. Emits `BlockRewardCalculated` event ### calculateSerializedEgl: ``` function _calculateSerializedEgl( uint _timeSinceOrigin, uint _maxEglSupply, uint _timeLocked ) internal returns (uint serializedEgl) ``` Calculates the current serialized EGL. The serialized EGL value is used when calculating how many BPT's have been release as well as in the calculation of creator rewards Emits `SerializedEglCalculated` event ### calculateCurrentPoolTokensDue: ``` function _calculateCurrentPoolTokensDue( uint _currentEgl, uint _firstEgl, uint _lastEgl, uint _totalPoolTokens ) internal pure returns (uint poolTokensDue) ``` Calculates the number of pool tokens due based on the current serialized EGL ### calculateBonusEglsDue: ``` function _calculateBonusEglsDue( uint _firstEgl, uint _lastEgl ) internal pure returns (uint bonusEglsDue) ``` Calculates the number of bonus EGL's due to Genesis participants based on their contribution in Genesis ### calculateVoterReward: ``` function _calculateVoterReward( address _voter, uint16 _currentEpoch, uint16 _voterEpoch, uint8 _lockupDuration, uint _voteWeight ) internal returns(uint rewardsDue) ``` Calculates the reward due to the voter based on their vote parameters Emits `VoterRewardCalculated` event ### calculatePercentageOfTokensInCirculation: ``` function _calculatePercentageOfTokensInCirculation( uint _total ) internal view returns (uint votePercentage) ``` Calculates the percentage of token in circulation give the total number of tokens # Governance Model {% embed url="" %} EGL is governed by its community, via Discord and forum discussions. At launch, EGL is fully functional: EGL holders can vote on their desired gas limit and miners can follow the vote. Any EGL holder can, and is encouraged to, actively participate in any future development of EGL. At launch the EGL smart contract are governed by multisig wallets of independent and decentralized actors. The multisig members are trusted members of the DeFi & Ethereum ecosystem. Specifically, **Genesis** * A wallet deploys Genesis and passes through a parameter that sets the contract's ownership to the Genesis multisig wallet. * A wallet deploys the EGL Token Contract and passes through a parameter assigning all 4 billion EGLs to the Genesis multisig wallet. * Upon Genesis ending, all ETH staked is transferred the to Genesis multisig wallet. **Balancer Deployment** * The Genesis multisig wallet deploys a ETH-EGL Balancer with all the staked ETH and 750M EGLs **Voting Contract** * A wallet deploys the Voting Contract and passes through a parameter setting the contract's ownership to the Voting multisig Wallet * The Genesis multisig wallet moves the remaining 3.250M EGLs to the Voting Contract * The voting contract can be upgraded with the Upgrade mutlisig wallet ## Multisig Wallets The multisig wallets require 3 of 5 members to sign a transaction for it to be approved. The Genesis multisig members are: * [BeePool](https://www.beepool.com/), top ETH mining pool * [Philippe Castonaguy](https://twitter.com/phabcd?lang=en), Director of Product[@0xHorizonGames](https://twitter.com/0xHorizonGames), Building [@SkyweaverGame](https://twitter.com/SkyweaverGame) * Dennis Chou, Director of Trading at Pantera Capital * [Will Meister](https://twitter.com/will_meister), fmr VP Engineering [@OptimismPBC](https://twitter.com/optimismPBC), current independent consultant * [bloXroute Labs](https://twitter.com/bloXrouteLabs) The Voting Contract multisig members are: * [BeePool](https://www.beepool.com/), top ETH mining pool * [Philippe Castonaguy](https://twitter.com/phabcd?lang=en), Director of Product[@0xHorizonGames](https://twitter.com/0xHorizonGames), Building [@SkyweaverGame](https://twitter.com/SkyweaverGame) * [Tesa Ho](https://twitter.com/defin00b), Portfolio Manager at Digital Asset Alpha, coordinator [@BanklessDAO](https://twitter.com/banklessDAO) * [Ivan Bogatyy](https://twitter.com/IvanBogatyy), Decentralizing Ethereum block production [@Mining\_DAO](https://twitter.com/Mining_DAO), Research [@dragonfly\_cap](https://twitter.com/dragonfly_cap), prev GP Metastable,[@GoogleAI](https://twitter.com/GoogleAI) [@TensorFlow](https://twitter.com/TensorFlow) * [bloXroute Labs ](https://twitter.com/bloXrouteLabs) The Upgrade multisig members are: * [BeePool](https://www.beepool.com/), top ETH mining pool * [Philippe Castonaguy](https://twitter.com/phabcd?lang=en), Director of Product[@0xHorizonGames](https://twitter.com/0xHorizonGames), Building [@SkyweaverGame](https://twitter.com/SkyweaverGame) * [Tesa Ho](https://twitter.com/defin00b), Portfolio Manager at Digital Asset Alpha, coordinator [@BanklessDAO](https://twitter.com/banklessDAO) * [Ivan Bogatyy](https://twitter.com/IvanBogatyy), Decentralizing Ethereum block production [@Mining\_DAO](https://twitter.com/Mining_DAO), Research [@dragonfly\_cap](https://twitter.com/dragonfly_cap), prev GP Metastable,[@GoogleAI](https://twitter.com/GoogleAI) [@TensorFlow](https://twitter.com/TensorFlow) * [bloXroute Labs ](https://twitter.com/bloXrouteLabs) {% embed url="" %} # Genesis ## To Be a Genesis Supporter 1. Navigate to [EGL.Vote](https://egl.vote/) and click the "join now" button. 2. Connect to the application with your Metamask {% hint style="info" %} Only Metamask is currently supported {% endhint %} 3\. Click "Join" and enter the amount of ETH you would like to stake {% hint style="info" %} The Genesis will close at the earlier of $100,000,000 staked or 1 week. {% endhint %} 4\. Check Etherscan to see if your transaction was confirmed. That's it! ## To participate with another wallet address: 1. Go to Metamask and [switch addresses](https://metamask.zendesk.com/hc/en-us/articles/360061346311-Switching-accounts-in-Metamask) ![](/files/-Mcoew5-v45QuQ9iftvl) {% hint style="info" %} See [here ](https://metamask.zendesk.com/hc/en-us/articles/360015289452-How-to-Create-an-Additional-Account-in-your-MetaMask-Wallet)for how to create multiple wallet addresses. {% endhint %} 2\. If your wallet is showing "[not connected](https://metamask.zendesk.com/hc/en-us/articles/360045901112-How-to-connect-to-a-website-dapp-in-V8-desktop-browser-extension-)", click on the "not connected" and then click "connect" ![](/files/-McodWe38HWuOyV63lL-) ![](/files/-Mcodm__VRuSAjQliY6Y) 3\. Do a hard re-fresh {% hint style="info" %} For Chrome: * Windows users: hold down Ctrl and then press F5 on your keyboard. * Mac users: hold down Cmd and Shift and then press R on your keyboard. {% endhint %} Repeat steps from above. ## Calculating Your Estimated BPT and Bonus Voting Tokens We've created a[ spreadsheet](https://docs.google.com/spreadsheets/d/1vdpZF6vDZkM1axpoc3cP1rAy2tD3J3VwOPe7coVELE4/edit#gid=0) to help with calculating their BPT Tokens, Bonus Voting Tokens, and release yourself. You can also use the spreadsheet to find out how many EGLs you've received, or you can find this through [egl.vote](http://www.egl.vote) or by querying the contract directly.
# Voting Genesis Supporters and EGLSignals *must* ["Claim & Vote](/guides/voting/claim-and-vote)" for their first vote and vote with all of your Bonus Voting EGLs for the first vote. By doing this, the contract will calculate your BPT and Bonus Tokens. This step needs to be completed or else you cannot withdraw your BPT and Bonus Voting EGLs (when they become available for withdraw). All other EGL holders can jump to the [Vote ](/guides/voting/vote)guide. {% hint style="info" %} Only Metamask currently works with EGL.Vote {% endhint %} ## # Claim & Vote ## Genesis Supporters & EGL Signals 1. Go to EGL.vote 2. Click "Join" 3. Go to the Vote tab in the header 4. Click the "Claim & Vote" button 5. Select your Desired Gas Limit and the number of weeks to lock your vote. The module will automatically vote with all your available EGLs. ![Vote by choosing your desired gas limit and number of lockup weeks.](/files/-MgliQVQgoK89PPlav6h) {% hint style="info" %} Locking up your vote for longer will increase your multiplier when calculating the `desiredEGLs` and your portion of the voter rewards. {% endhint %} That's it! # Vote 1. Go to EGL.vote 2. Click "Join" 3. Go to the Vote tab in the header 4. Click the "Connect" button * There will be 2 transactions: the first allows your wallet to interact with the contract and the second is your vote. * When the first transaction is completed, you'll see the Vote button appear. * If metamask doesn't automatically pop up you may need to go to metamask and confirm the transaction. 5. Input the number of EGLs you'd like to vote with, your Desired Gas Limit and the number of weeks to lock your vote. Note: There will be 2 transactions: 1) allows your wallet to interact with the contract and 2) the vote ![](/files/-Mgq_TEY9BWqwLrFkX5L) {% hint style="info" %} Locking up your vote for longer will increase your multiplier when calculating the `desiredEGLs` and your portion of the voter rewards. {% endhint %} ![Afterward, your vote will appear in this table.](/files/-Mglg3pFqysgiAeRcLiH) # Revote ## You can revote when: 1. You have a vote currently locked that you'd like to increase the number of EGLs you are voting with, extend the number of weeks you are voting with, or change your Desired Gas Limit. 2. You previously voted EGLs that are no longer locked in a vote but are still in the contract (not in your wallet). You can put all of these EGLs back in a vote with one function using revote If you want to change the number of EGLs you are voting with, you will have to withdraw your EGLs first to your wallet and then revote with the number of EGLs you'd like. ## To use Revote 1. Go to EGL.vote 2. Go to the Vote tab in the header 3. Click the "revote" button 4. Select your Desired Gas Limit, the number of weeks to lock your vote, and any additional EGLs you'd like to vote with. ![](/files/-Mgq_cGQ6MO8bEGM3u4s) {% hint style="info" %} The number of weeks you select will become your new multiplier. Thus, if you had previously selected 8 weeks (an 8 multiplier) and now select 6 weeks, your vote will decrease its multiplier weight to 6. {% endhint %} # Helpful Tips ## Trouble connecting on Chrome? Manually connecting to EGL.vote often resolves this issue. You can find directions [here](https://metamask.zendesk.com/hc/en-us/articles/360045901112-How-to-connect-to-a-website-dapp-in-V8-desktop-browser-extension-). ## **EGL.vote on Mobile** If you want to view the website on mobile, please do it from the browser function within MetaMask. ## EGL.vote on Brave To use EGL.vote on Brave please make sure your wallet is set to "metamask" and the "load crypto wallets on startup" is turned off. ![](/files/-MgSIilZzOYvRfJdOyoA) ## **Vote Early** Votes are locked for weekly increments from the time they are locked, regardless of when the epoch ends. Thus, the earlier you vote, the earlier your tokens will become available. Additionally, there is a four hour window of when the epoch closes and the next vote begins that you cannot vote within. Egl.vote will not allow voting for you, but if you call the contract directly your vote will fail. ## Vote for More Weeks Votes can be cast for up to 8 weeks into the future. The number of weeks you lock your vote for becomes a multiplier in both calculating `desiredEGLs` and the voter reward. Thus, locking up your EGLs for longer increases the influence your vote has on the system and your share of the participation reward. Additionally, if in any given week not enough EGL holders voted, the system will set`desiredEGLs` to 95% of the the current gas limit - likely lowering the gas limit. Locking up EGLs for longer will help in avoiding falling below the threshold. ## **Genesis Participation / EGLs Signals + Acquiring more EGLS** If you participated in Genesis or are an EGL Signals with a given wallet address and would like to acquire more additional EGLs, we suggest you use a different wallet address for two reasons: 1\) When you claim and vote for the first time, it will only claim and vote with your Bonus Voting EGLs. You will have to go back and vote again with the additional EGLs you've acquired. 2\) The EGL unlock date for your wallet address will apply to ALL EGLs used to vote, regardless of how they are acquired. Thus, if you vote with those additional EGLs, they will be locked for the same amount of time as your Bonus Voting EGLs (e.g. over 70 days). If you used a separate wallet address that did not participate in Genesis and is not an EGL Signals wallet, then those EGLs will only be locked for the voting length (e.g. 1-8 weeks). ## Use Revote Revote can be used in two ways: 1) to change your vote when EGLs are locked and owned by the contract (i.e. not available for withdrawal) and 2) to submit a new vote when EGLs are in the contract but available for withdraw. It is advantageous to use `revote()` when you want to vote again will all of your EGLs because the function combines `withdraw()` and `vote()` into one transaction and will save you on gas. ## Withdrawing BPT Tokens For wallet addresses that participated in Genesis, when your BPTs and Bonus Voting EGLs become unlocked AND it's less than 1 year from contract launch, you must first withdraw all your BPTs before you can withdraw your Bonus Voting EGLs. If it is after 1 year from launch, you can withdraw your Bonus EGLs first. Additionally, BPTs unlock overtime and can be withdrawn overtime while Bonus Voting EGLs unlock all at once, with the last BPT unlocking. ## How to vote with less EGLs If you wanted to lower the amount of EGLs you are voting with, you first must wait until they become unlocked (i.e. for Genesis wallets this is when the Bonus Voting EGLs become unlocked, for EGL Signals this is after 52 weeks, and for all other wallets this could be 1-8 weeks). Once the EGLs are unlocked, you must `withdraw()` your EGLs (you are forced to withdraw all of them) and then place a new `vote()` with the new desired amount of EGLs. If you try to use revote (withdraw and vote again in one function) it will force you to use all the EGLs associated with your address in the contract (as noted above). ## Staking Length EGL favors long term Supporters - those who stake ETH for longer durations - and awards more EGLs to later supporters. Thus, earlier supporters haver their tokens released sooner (Release Schedule), while later Supporters receive more Bonus EGLs. # Formulas ## Genesis **ETH:EGL\_Genesis\_Ratio:** $$ \text{ETH:EGL Genesis Ratio}: \frac{\text{Total ETH staked at Genesis}}{\text{750,000,000 EGLs}} $$ **Bonus Voting EGL**~~**s**~~: $$ (y^4-x^4)/(\frac{81}{128}) \* 10^{27}) $$ where, $$ \text{last serialized EGL = y} = \text{ETH:EGL Genesis Ratio}\* \text{cumulative ETH staked after you contribute} $$ $$ \text{first serialized EGL = x} = \text{ETH:EGL Genesis Ratio} \* \text{cumulative ETH staked before you contributed} $$ **BPT Unlock Schedule:** $$ \text{First BPT Release Date} =(\frac{\text{first\_serialized\_EGL}}{750,000,000})^{1/4}\* 294 + 70 $$ $$ \text{Last BPT Release Date} = (\frac{\text{last\_serialized\_EGL}}{750,000,000})^{1/4}\* 294 + 70 $$ {% hint style="info" %} Launch is the date the voting contract is deployed, not the date the Genesis closes. {% endhint %} **Bonus Token Unlock**: With your individual last BPT token ## ‌Voting **Voting Rewards**: $$Reward\_i = 362844.70 \* (52 - i)$$EGLs **Desired Gas Limit (**`desiredEgl`): $$\frac{\sum\_i (targetGasLimit\_i \* weight\_i)}{ \sum\_i weight\_i}$$ ## Miners (Pools) **Max Miner Reward**: Remaining EGLs available \* 0.0000002 (see [Mining Pool Reward](/protocol-overview/miner-rewards) for more details)
## Creator's Fund **Release Date:** $$ \text{Release Date} =(\frac{\text{serialized\_EGL}}{750,000,000})^{1/4}\* 294 + 70 $$ ## Other EGls in Circulation `(eglsInCirculation)` = $$Matching EGLs + Claimed BonusVotingEGls + Claimed EGL Voices + Claimed Miner Rewards + Allocated DAO EGLs + Unlocked Creator Rewards$$ (see [Voting Threshold](/protocol-overview/voting/voting-threshold)) # Attributes | Attribute | Data Type | Description | | --------------------------- | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `desiredEgl` | int | the community's desired gas limit [calculated](/protocol-overview/voting/calculating-desiredegl) at the end of a voting epoch | | `baselineEgl` | int | the average block gas limit of all blocks in an epoch that include vote transaction | | `initialEgl` | int | the actual block gas limit fo the block that deployed the contract | | `tallyVotesGasLimit` | int | the gas limit of the block that contained the successful tally votes function call | | `creatorEglsTotal` | uint256 | the total number of EGL's awarded to the creators | | `liquidityEglMatchingTotal` | uint256 | the total number of EGL's to deploy to Balancer when the pool is created | | `currentEpoch` | uint16 | the current active epoch | | `currentEpochStartDate` | uint256 | the start date of the current epoch | | `tokensInCirculation` | uint256 | the token number of tokens in circulation | | `voterRewardSums` | uint256\[52] | an array of length 52 (max reward epochs) where each index contains the sum of all the vote weights for that epoch | | `votesTotal` | uint256\[8] | an array of length 8 (max lockup duration) where each index contains the sum of all vote amounts for that epoch | | `voteWeightsSum` | uint256\[8] | an array of length 8 (max lockup duration) where each index contains the sum of all vote weights that epoch | | `gasTargetSum` | uint256\[8] | an array of length 8 (max lockup duration) where each index contains the sum of all target gas limit values for that epoch | | `voters` | mapping(address => Voter) | a mapping that maps addresses to `Voter` structs. Represents all votes | | `supporters` | mapping(address => Supporter) | a mapping that maps addresses to `Supporter` structs. Represents all genesis participants | | `seeders` | mapping(address => uint256) | a mapping that maps addresses to the EGL amount given to each signal/seeder account. | | `Voter` | struct |

a struct containing the active vote details for each address . The struct has the following attributes:

  • lockupDuration: number of weeks to lock the vote in for
  • voteEpoch: the epoch the vote was cast in
  • releaseDate: the date the EGL's can be withdrawn
  • tokensLocked: the number of EGL's locked in the contract
  • gasTarget: the target gas limit the address voted for
| | `Supporter` | struct |

a struct containing the claim status of a genesis participant. The struct has the following attributes:

  • claimed: whether the address has claimed their EGL's
  • poolTokens: BPT tokens due to the participant
  • firstEgl: the participants first serialized EGL
  • lastEgl: the participants last serialized EGL
| | `votingThreshold` | uint256 | the percentage of `eglsInCirculation` that must participate in the vote for `tallyVotes()` to “pass” | | `eglAmount` | unit256 | Amount of EGL's used for voting | # FAQs ## **Contract Addresses:** * EGL Token contract: [0x1e83916Ea2EF2D7a6064775662E163b2D4C330a7](https://etherscan.io/address/0x1e83916ea2ef2d7a6064775662e163b2d4c330a7) * EGL Voting Contract: [0xE9a09e0032D1aB5Ce4bF09149ef746258252Bd0B](https://etherscan.io/address/0xE9a09e0032D1aB5Ce4bF09149ef746258252Bd0B) * ETH-EGL Balancer Pool: ## [**Design**](/appendix/faqs#design) * What happens if the desired gas limit is an "unsafe" number? * Who are EGL Signals? * Why would miners listen to EGL voters? * What happens if miners stop listening to EGL? * Why limit the vote to 4M? * At what desired gas limit does EGL launch? * What's to stop community members from freeloading; i.e. simply benefitting from others' voting without voting themselves? ## [**Genesis**](/appendix/faqs#genesis) * What is the contract address? * When does Genesis open and close? * What if I want to participate more than once? * When do my BPT tokens unlock? * When do my Bonus Voting EGLs unlock? * What will my EGL unlock date be if my Genesis unlock date is before the unlock date of my vote? ## [Voting](/appendix/faqs#voting) * Who should vote with EGLs? * Don’t know what to vote? * Why vote more than 1 million? * Can you change your vote? * Can I revote and lock up my EGLs for less than the original vote? * What happens when we’ve hit my desired gas limit? Can I stop voting and sell my EGLs? * Can I delegate my vote? ## [**Other** ](/appendix/faqs#other) * Why do we need EGL? * What exactly is the gas limit and why does it matter? * Who currently controls the gas limit? * What is the current gas limit? * Is there a "right" gas limit? * Can EGL be used for other things? * What happens when ETH 2.0 comes? * There are concerns about state size. What does this mean? * How does EGL interact with EIP-1559? * Which wallets work with egl.vote? * Are gas limit and block size directly related? * What are mining pools and who comprises them? * How does Layer-2 affect EGL? * Will the smart contracts be audited? # Design ## What happens if the desired gas limit is an "unsafe" number? Don’t worry, EGL is built to adjust the gas limit gradually. While you can vote for a gas limit of +/- 4 million from the current gas limit, each week the new desired gas limit can move at most +/- 1 million from the current limit gas limit. This gradual change allows the ecosystem to safely discover what the “right” number is. Additionally, miners can only increase / decrease a block by 0.1% from the prior block, further allowing the ecosystem to discover if the desired gas limit is safe. ## Who are EGL Signals? "EGL Signals" was created to help signal and guide the community on the desired gas limit. This group is made up of client teams (those who make the software nodes run on), those who've submitted updates (EIPs) that have been approved and implemented, as well as a handful of researchers and contributors. Those in this group have informed insights about what may be the right gas limit. We encourage voters to let how the Signals vote inform their own voting decisions. "EGL Signals" was created to help signal and guide the community on the desired gas limit. This group is made up of client teams (those who make the software nodes run on), those who've submitted updates (EIPs) that have been approved and implemented, as well as a handful of researchers and contributors. Those in this group have informed insights about what may be the right gas limit. We encourage voters to let how the Signals vote inform their own voting decisions. ## Why would miners listen to EGL voters? EGL incentivizes miners to listen to voters by rewarding them in EGLs for doing so. ## What happens if miners stop listening to EGL? Miners are only rewarded with EGLs if they follow the vote. Thus, if miners stop listening to EGL and forgo such a reward, this likely signals that the new desired gas limit was at an unsafe level. In such an event, EGL holders ought to vote back towards the last level miners followed. This will allows miners to claim the EGL reward and allow the EGL community to hold the gas limit at such a level (remember, if no vote passes then the system automatically lowers the desired gas limit to 95% of the current gas limit). ## Why limit the vote to 4M? EGL is built to adjust the gas limit gradually. In a perfect world EGL holders would vote each week, the miners would listen, and the next week's vote would reflect those learnings. In reality, it might take several weeks before the effect of a gas limit change becomes apparent, and some EGL holders may not be watching the network that vigilantly. Having a 4M range to vote balances these two variables. ## At what desired gas limit does EGL launch? The current gas limit (\~15M). ## What's to stop community members from freeloading; i.e. simply benefitting from others' voting without voting themselves? EGL has designed a two-part solution to this problem: A certain threshold of votes must be hit each week, and this threshold will gradually increase over time. If the threshold isn't met, the desired gas limit will be set to 95% of the current gas limit each week that threshold isn't met, addressing the tragedy of the commons problem by incentivizing all community members to vote. # Genesis ## What is the contract address? ## When does Genesis open and close? Genesis opens on August 7th at 1pm ET and closes on the earlier of 100,000 ETH staked or August 13th 8am PT. ## What if I want to participate more than one? You can participate more than once by using a different wallet address. See the [Genesis ](/guides/genesis)user guide for more details. ## When do my BPT tokens unlock? Your BPT Tokens unlock based on when you participated in Genesis - the earlier you participated the earlier they unlock. See the [Release Schedule](/protocol-overview/launch/eth-egl-release-schedule) for how to calculate. ## When do my Bonus Voting EGLs unlock? Your Bonus Voting EGLs unlock with your last BPT token. See the [Release Schedule](/protocol-overview/launch/eth-egl-release-schedule) for how to calculate. ## **What will my release date be if my Genesis unlock date is before the unlock date of my vote?** Your unlock date will be the longer of the two. For example, if your release date is Aug. 1 but your vote’s unlock date is Aug 14, then your tokens will unlock on Aug. 14.
# Voting ## Who should vote with EGLs? Anyone who holds Ethereum and is invested in its future. This is especially true for Ethereum users, VCs, DApps, and developers. ## Don’t know what to vote? That's okay. We’ve elevated the voices of experienced core devs to help clue you in to what the optimal desired gas level should be. Our leaderboard also includes investors and dApps. If you’re not sure what to vote, use these experts as a guidepost. Gradually, through research and experience, you'll come to develop your own insights and in the future you’ll be able to delegate your vote to a trusted source. ## Why vote more than 1 million? Voting more than 1 million above or below the current gas limit allows you to not have to revote each week if your desired gas limit is more than 1M from the current gas. Let’s say you wanted the gas limit to be 19 million and the current gas limit was 15 million. You’d have to go in and vote every week +1 million for at least 4 weeks to get to 19 million (assuming the vote passed at +1M each week). By simply voting 19 million, you save time and gas fees. ## Can you change your vote? No problem, you can always revote. When you revote, any rewarded EGLs will be added to your revote and the amount of weeks you lock up your vote for will become your new multiplier. ## **Can I revote and lock up my EGLs for less than the original vote?** While you can technically revote for less weeks and this will become your new multiplier, your EGLs will still be locked for the original lock term because your EGLs are always locked for the longer term. \ \ For example, if you originally voted for 8 weeks, 2 weeks pass and you revote (so 6 weeks are left) and pick 3 weeks, then your new multiplier will be 3 but your EGLs will still be locked for the 6 weeks left on your original vote. Thus, it is suggested that you always revote for at least as long as your EGLs are still locked. ## What happens when we’ve hit my desired gas limit? Can I stop voting and sell my EGLs? No. Optimizing the gas limit to its maximal safe value creates value for the entire ecosystem, but also opens the door for the tragedy of the commons; every actor will ask herself why should it fall upon her to invest capital and effort to hold EGLs and vote. To incentivize the participation EGL leverages a two-step mechanism: 1. For a weekly tally to pass, a minimal threshold of EGLs must participate in the vote, and this threshold gradually increases over time. 2. If the threshold is not met, the desired gas limit does not remain unchanged. Instead, it is set to revert to 95% of the current gas limit. Thus, failure to participate in voting begins to revert the value EGL creates. The rationale beyond this unconventional design choice is the community benefits greatly from EGL. Therefore they are significantly better off locking some capital in EGL and voting compared to losing the value they capture from EGL. ## Can I delegate my vote? No, but this functionality can be added in the future should the community want it. # Other ## Why do we need EGL? The gas limit effectively controls the block size and thus the number of transactions Ethereum can process (i.e. tps). When demand for limited block space increases, the cost to use Ethereum (i.e. gas fees) spikes as users outbid each other to fit inside of the block. The gas limit is set by Ethereum miners, not Ethereum developers or users. EGL is a coordination token to enable the community to voice their collective desired gas limit and to reward Ethereum miners for listening to EGL holders. ## What exactly is the gas limit and why does it matter? "Gas" reflects the computational power required to run a given transaction. More complex transactions require more gas and simpler transactions require less gas. In Ethereum there is no "block size" (e.g. 1MB in BTC), but rather a "gas limit" - a maximum amount of gas that a block can contain. Thus, the number of transactions included in a block is determined by the sum of all the "gas" that the transactions use. A higher gas limit typically means a block can include more transactions and a smaller one means fewer transactions. The "gas limit" influences the throughput of Ethereum, often measured as transactions per second (tps). ## Who currently controls the gas limit? Miners (pools) control the gas limit, setting it with each block they produce. A miner can produce a block with a gas limit +/- .1% from the previous block, moving the needle higher or lower by increments. Sometimes mining pools privately agree to change the target gas limit, acting as a cartel, and that's when you'll see the gas limit experience significant swings. ## What is the current gas limit? The gas limit is currently \~15M, up from 10M last year. You can follow the gas limit's movement [here](https://ycharts.com/indicators/ethereum_average_gas_limit). ## Is there a "right" gas limit? There is no "right" gas limit -- it is a moving target as Ethereum evolves and hardware becomes more efficient. However, since the gas limit does have downstream effects, there are certainly numbers that produce more desirable outcomes. EGL allows the community and miners to discover through gradual movements more optimal gas limits. Getting closer to an optimal limit requires the granular knowledge of core devs, which is why we've elevated their voices with EGL. ## Can EGL be used for other things? Yes! While EGL initially is used to express a desired gas limit, it could be used to solve other coordination issues such as rewarding miners for ordering a block based on specific criteria (MEV). ## What happens when ETH 2.0 comes? “The Merge” is the first step in transitioning ETH to PoS, confirming ETH blocks in the ETH2 consensus. This is huge for ETH, but does not mitigate the gas limit issue. Validators will now increase/decrease the gas limit, just like miners are currently doing. Furthermore, the burden to figure out the “right” gas limit will now shift from the centralized mining pools to (hopefully) more decentralized validator operators, increasing the need for a coordination tool such as EGL. ## There are concerns about state size. What does this mean? The state refers to all the blocks in the Ethereum blockchain to date, and the transactions within those blocks. As the number of transactions on ETH grows, so does the state, and thus the speed at which transactions are added influences the speed at which the state size grows. Concerns about state size refer to concerns about a growing history that is so large an average user cannot download it in a reasonable amount of time. Fortunately, this is a solved problem. Ethereum has introduced the concepts of "stateless" clients and state expriry. As Vitalik explains "Statelessness allows for a class of nodes that verify the chain without maintaining permanent storage. State expiry pushes out state that has not been recently accessed, forcing users to manually provide proofs to renew it. Both of these paths have been worked at for a long time, and proof-of-concept implementation on statelessness has already started. These two improvements combined can greatly alleviate these concerns and open up room for a significant gas limit increase." ## How does EGL interact with EIP-1559? EIP-1559 doesn’t solve “high fees.” EGL actually provides a missing piece to EIP-1559: an incentive for pools to adjust the gas limit as long as it’s safe. EIP-1559 changes how gas fees are paid to miners. Specifically, with EIP-1559 users will pay a base fee + tip where the base fee will be burned (i.e. the miner does not get it) and the tip is paid to miners when congestion is high to incentivize inclusion. As most people know, EIP-1559 doesn’t solve this whole “fees are high” thing. It does make fees more predictable and works better than the first price auction (FPA). However, when many people try to send their Txs and the capacity is limited, the most valuable Tx will outbid the less valuable (i.e. pay a higher fee). The EGL community helps to collectively signal what capacity (gas limit) they think is right. More importantly, EIP-1559 completely removes the incentive for pools to increase the gas limit, even if everyone agrees it is completely safe. Why should they? Producing larger blocks would only increase their risk of uncle blocks, but would hardly increase their revenues (since fees are burned). We realized that EGL might be the perfect bridge to smooth the transition to EIP-1559. EGL aims to reward pools substantially, potentially similarly to their expected revenues from fees, thus it might allow for pools to maintain their expected revenues while benefitting users with EIP-1559's superior monetary policy and fee predictability. {% embed url="" %} ## Which wallets work with egl.vote? At this time only MetaMask works. ## Are gas limit and block size directly related? Block size and gas requirement tend to be directionally related, but this is not a one to one relationship. Two different block sizes could have the same gas requirement. This is because gas refers to the computational complexity of the code and size refers to the amount of bytes of data a transaction contains. ## What are mining pools are who comprises them? Mining pools are made up of miners who run the hardware to win the block reward, and an administrator who organizes and runs the pool. One's probability of winning is directly related to how much computational power they have. It's pretty intensive right now to win, so a single miner might win once every 2-3 years! Winning is big but you have bills to pay in the meantime. Thus, miners mine in groups - called pools - to smooth out their earnings. Pools are run by mining pool admins who take each transaction and build the block. About 4 mining pools control 70% of the hash. Mining pools collect about 1% on the block reward + fees and pass on the rest to underlying miners who contribute hash power. ## How does Layer-2 affect EGL? Layer-2 solutions such as optimistic rollups, side channels, or even off-chain DEXes use layer-1 as an anchor of trust rather than a generalized state machine which processes everything. However, all of these solutions are only safe under the assumption that any fraud proof can be easily sent on chain — i.e. maintain the anchor of trust. Thus, their success is intrinsically tied to the ability of a blockchain to continually process transactions without congestion and as such are limited by the scalability bottleneck, i.e. on-chain transaction throughput. ## Will the smart contracts be audited? Yes, the contracts will be audited by [Halborn](http://www.halborn.com/). # Audits {% embed url="" %} {% embed url="" %}