Thank you for chiming in, always a pleasure to see you in the forum
Let me quickly clarify a few things.
I definitely see your point. And to be clear again: nothing against you, or for what it matters anybody that is a delegate without directly contributing to a protocol. Just, since i contribute to a few, i have a keen eye toward them, because to me protocols are the core of arbitrum ecosystem; and since their presence in this forum and in governance is not as big as it should be (obviously, in my opinion) I would like to see an outcome in which this presence is not furtherly reduced.
Also to be clear, this is not what I am suggesting nor what I had in mind. I donāt think we should put a cap to what people should get as delegation, nor I ever thought was a valid idea; on the other hand, i think there could be a gamification for which we try to direct the delegation in what we see as the ābestā way (could be: decentralization of delegates, activity of delegates, frequency of votes of delegates, etc). This is effectively where single opinions start to matter on the āhowā we should do it.
I am quite enjoying this convo: is pretty clear we have some different ideas on the topic, likely because we are in different camps, and I really think you would be a tremendous contributor in the working group for the definition of active delegators. Even if you could not be active day to day in there, async messages like this one can still bring a lot of value to the discussion imho
Voting in favor of this proposal. Itās actually one of the more interesting proposal in while. I hope in can further incentivize governance participation. Thanks, @Frisson
Voting āForā this proposal and a fan of this direction but do believe this is a classic devil is in the details situation so hoping for a few more things to be clarified as we progress. The long list below and voting For still, shows how important an idea it is to still move forward and solve.
will the be any additional cost to the DAO for the distirbution of rewards to through these stARB contracts?
while developed through tally, who will have control and any admin keys for the stARB stacking contract (security council?, tally? foundation?)
karma scores could start to hold excessive weight, we are now saying that protest delegates, or delegates who want to take a different approach to exercising their say in governance may not be as worthy to delegate (since those delegating to them donāt receive incentives potentially ā¦ when they start)
Defi Questions
it would be good to understand the impacts of a depeg of the stARB token and risks to the ecosystem since it will trade seperately
will there be a need to additionally support liquidity for this token? will it fragment liquidity and trading for ARB
the idea that if you participate in DeFi your voting power reverts to the DAO for it to deploy seems well a bit counter-intuitive. Would be better for the EVM home of Defi to find a better solution.
ARB staking is an outstanding value add and it unlocks several possibilities, especially aligning incentives between all stakeholders and we are glad to see this come to life. There are still details to work through regarding defining an āactive delegateā, and reward structure but happy to see this pass the initial temp check. We also commit to participating in the working groups once that is established.
re @Frisson you might want to update the diagram in the original post to āstARBā before posting on Tally.
Edited to add that we maintained our support on Tally.
it is too soon to add staking for arb tokens in my opinion, the yields will be very low and there are very unclear regulatory risks. in my opinion, this appears to be a way to quickly try and give some value to the ARB token given how low it is, but it could have the opposite effect if rushed through like this
can we please get comments from the Arbitrum Foundation legal team to understand their position on this and the risks it might represent to the DAO?
Thank you everyone for your support and valuable feedback.
To help address recent questions raised by delegates in this thread, I added technical detail to the System Architecture section of the proposal and added a specific timeline for the working group deliverables.
In addition to updating the proposal text, I created an onchain proposal on Tally to fund development of the staking system. The current onchain proposal is only to fund the development of the staking system. The DAO will vote separately on the implementation of ARB Staking after it has completed development and audit. The DAO will also vote separately on the funding of staking rewards and implementation of delegation based on the recommendations of the working groups. Please note that, while this proposal as a whole is Constitutional, the current onchain proposal targets the Treasury Governor because it controls the ARB treasury.
Thanks for your support and for your feedback @maxlomu. Many of the questions raised by the ARDC will be addressed by the Staking Rewards and Delegation working groups cc @Curia.
Thanks for your support and for your feedback @pedrob. stARB is designed to be able to support any implementation recommended by the working groups. My personal view is that waiting for the working groups to conclude before beginning development will add months of delay without significant benefit.
Thanks for your support and for your thoughtful feedback @JoJo. I agree that protocol representation in DAO governance is important and should not be neglected in the design. Iād love for you to participate in the working groups.
I added a specific timeline for the working group deliverables to the proposal.
My personal view is that both working group topics (staking rewards and delegation) are very important and distinct enough to merit separate groups. We welcome anyone who is interested to participate in both groups.
Thanks for your support and for your feedback @coinflip. I replied to each of your questions in-line below. Happy to discuss further!
No, there will not be any cost to the DAO for the distribution of rewards through stARB contracts.
stARB will be deployed as an immutable, non-upgradeable contract. The delegation strategies part of the system will be upgradeable via Arbitrum DAO Constitutional Proposal. The only part of the system Tally manages is the rebalancing of underlying assets.
The implementation of Karma for ARB Staking is designed to be modular. If, in the future, the DAO wishes to add additional or alternative providers to define āactive delegateā, it can do so. You make an interesting point about āprotestā delegates, or delegates who do not wish to regularly vote. Maybe there is some quantitative way to define their value to the DAO such that it can be included as a qualifier for rewards.
One note is that any stARB withdrawal period will be very short and exist only to prevent people from abusing the reward mechanism (i.e. staking right before a reward, claiming a chunk of it, and immediately unstaking). If there is a price difference, arbitrageurs can quickly unstake stARB and sell it as ARB to close the price difference. This easy arbitrage opportunity minimizes price discrepancies and should make it difficult for any potential governance attacker to acquire ARB at a discount.
I personally donāt think there will be a need for general liquidity support for stARB. I do think itās possible that some protocols in the ecosystem will want to request grant funds (when the liquidity incentivies detox is over) for stARB liquidity.
Another option that is baked into this proposal: DeFi applications can support the ability to retain the userās individual delegation by implementing a Flexible Voting client.
Thank you for your thoughtful feedback and for all the work you do to contribute to the Arbitrum ecosystem @Camelot.
One thing Iād note is this proposal does not, in and of itself, make any changes to the ARB token. The specific implementation of staking rewards and their integration with governance will be determined via the below process and implemented (if desired by the DAO) via separate governance proposals.
Iād also note that the implementation of Karma for ARB Staking is designed to be modular.
In response to various questions, we wanted to share a high-level summary of our analysis of the application of US securities laws to our proposal to implement ARB staking. The analysis below does not constitute legal or financial advice and should not be relied upon by any delegate. The regulatory framework applicable to crypto, including staking and other yield programs, is currently unclear and subject to ongoing litigation. We therefore encourage every delegate to consult with their own counsel.
ARB staking is not an āinvestmentā intended to yield profit, but rather a cryptoeconomic security mechanism intended to increase the security of the Arbitrum protocol. The āyieldā that will be passed through to ARB stakers does not constitute a distribution of the profits of Tally or any other business entity, but rather a programmatic distribution of fees generated at the protocol level. Therefore, ARB stakers should not have any expectation that they are going to be profiting from the efforts of managers of a business entity, nor will ARB stakers be subject to information asymmetries and agency issues that require the application of securities laws.
One of the main problems I face in several DAOs as a self-delegate is that I cannot use my tokens in DeFi. For example, if I move them to AAVE, I lose my delegation power. This is a big problem for a degen like me because it disincentivizes me from delegating all my tokens due to the opportunity costs (I could be generating yield elsewhere).
The introduction of stARB completely fixes this problem; it will finally enable me to maintain my degen addiction while retaining delegation power. For these reasons, Iām voting in favor of this proposal, and I hope it becomes so successful that other DAOs take note and implement similar token utility, as this is clearly aligned with governance and incentives.
this is not totally true. Dolomite allows you to use arb as collateral while delegated to yourself or whoever you prefer; and in my knowledge there are several ways to implement this, just, protocols donāt bother too much doing it.
For sure stArb will hopefully allow for new use cases.
