Abstract
Enable fees sharing through decentralized sequencer with staking of $arb
Motivation
The Arbitrum community should implement this Arbitrum Improvement Proposal (AIP) to address centralization concerns surrounding the sequencer. By enabling $ARB token holders to participate in sequencer operations through staking, we can decentralize the network’s economic and operational control. This change is expected to increase network participation, security, and align incentives across the ecosystem.
It also gives additional utility and pursue the decentralization path with the $arb token.
Rationale
This proposal aligns with the following values :
-Sustainable: Arbitrum should be built and operated with an eye to the medium to long term. Decisions about technology, economics, and resource allocation should not value short-term optimization over the longer-term health and thriving of the Arbitrum protocol, technology and community.
-Socially inclusive: The community should be open and welcoming to all people who wish to participate constructively. Differences in knowledge, resources, geography, language, and life experience should be seen as opportunities to learn and to grow the community.
-User-focused: The Arbitrum ecosystem should be managed for the benefit of all Arbitrum users.
The idea is good, but Arbitrum’s goal is to scale Ethereum. The whole project was initiated for this purpose and all the work was done on this. As a result, realizing this idea is not as easy as it seems and will take years.
Arbitrum is a layer 2, this means is an infrastructure “sub-product” of a main infra which is the layer 1, Ethereum. The main purpose of Arbitrum is to make Ethereum ecosystem better, specifically from the scalability standpoint.
To give, not to take. To help, not to compete. To improve, not to harm.
Ethereum tokenomics need from network fees in order to be deflationary and enough demand to keep the price uptrend and so healthy and long term sustainable.
All the utility, demand and buying pressure you want to add to ARB by implementing this change, you are taking it away from ETH. That needs to be clear: you are not creating new demand from the void, you are simply snatching it from ETH.
ETH is the base fuel of the entire ecosystem and where most of the liquidity sit after stable coins.
Your proposal is harming ETH tokenomics and changes like this one can jeopardize the whole system.
Imagine if this becomes a trend and every single layer 2 decide to use their own token to pay for txns.
ARB will very likely be used for L2 validators/sequencers staking, so there will be additional uses besides the governance.
I don’t support replacing ETH with ARB as a gas token, for various reasons. Some were already mentioned in this thread, I’ll add that implementing this would bring a lot of complexities, one of them being having a system to sell ARB fees to get ETH for paying fees on L1 (not to mention this would introduce a constant selling pressure for ARB).
I’m open to experimenting with ARB as a gas token on some new chain (e.g. a new AnyTrust chain similar to Nova, or an L3 chain), but not on Arbitrum One.
Rather than replace Eth, id like it if i could choose between ARB and Eth for paying gas
Also worth noting that gas fees in $ARB will affect our sequencer revenue collection, which is currently printing 1000 eth a month and is a big source of strength for ARB
One of the advantages of the Ethereum Layer 2 ecosystem is that you need ETH to operate on all different chains. In my opinion, this is a tremendous value proposition for new users and the general user experience. If every L2 uses its native token for gas, a user needs to purchase/hold all of the different L2s, making the landscape scattered rather than integrated.
I remember Steven Goldfeder at Permissionless in Austin saying that we need to work on integrating the L2 ecosystem, rather than separating it.
I’m aware of a project in Cosmos called “gas station” that lets the user choose the gas token. This would be life-changing in terms of UX, in my opinion, but simply replacing ETH with ARB worsens the UX, and I’m not even sure it would improve ARB’s economics, i.e., ARB’s sell pressure to pay gas.
In my opinion, there are 2 key aspects to consider regarding this proposal.
Lack of Increased Token Demand: Analyzing the token flows reveals no significant new demand. Users purchase your token to access your rollup. However, when they use gas, the sequencer offloads these tokens to meet data availability i.e DA expenses, which are payable only in ETH. If the gas fees in your token aren’t sufficient to cover DA costs, the protocol itself has to bear the extra DA expenses. This situation implies that while you’re encouraging use of your rollup by effectively subsidizing it, you still face DA costs in ETH.
Challenges with Cross-Domain MEV and Interoperability: Looking ahead, cross-domain interoperability and MEV could emerge as primary revenue sources for rollup sequencers. By requiring the Arbitrum rollup users to acquire ARB, you unintentionally create obstacles for searchers/builders in extracting MEV on Arbitrum. They would have to manage another token (potentially one for each rollup) instead of just holding ETH, which significantly complicates their strategy for managing token inventories.
The proposal to switch Arbitrum’s gas token from ETH to ARB has potential benefits, but needs further analysis and discussion.
This sentence summarizes the main points of the proposal and its analysis. It is concise and easy to understand, and it leaves open the possibility that the proposal could be successful with further development.
Im not new to the community but new to the board but have been following this proposal and working on this during the eth global hackathon.
As @TempeTechie suggested, I’m helping build a community, Arbitchain, as an L3 that can leverage arb as the gas/network token. Being that Orbit Chains are permissionless tech, we can bifurcate the ecosystem and let Arbitrum One retain its ETH equivalence while “Arbitchain” can be a community based chain that uses ARB for gaming, DeFi etc…