Accounting for votes ARB that locked in various projects

Proposals
1

Proposal: Accounting for votes ARB that locked in various projects
(for discussion)

Сonstitutional

Abstract

A large part of ARB tokens (more than 13,500,000) are locked in the various protocols, but users cannot participate in governance with these tokens.
cp0x believes that it is necessary to take these tokens into account in the governance system if there is a technical possibility for this in the smart contracts of projects (for example, there is a function that allows you to understand the exact number of arb tokens for a certain account).

Motivation

Users who use ARB in various projects are the most active, but cannot be a part of the governance, since their tokens due to technical implementation are not on their account. Such users also often have interest in participating in the DAO governance

Rationale

This way we can increase:

  • the number of votes, since at the moment users participating with their tokens in various protocols and they are not able to participate in voting

  • quality of votes, as we will involve more experienced and active users in the voting process

Specifications

Quite a large part of ARB tokens (more than 13,500,000) are locked in the following protocols:

  • Uniswap. more than 500,000 ARB locked (link)

  • SILO. more than 5,000,000 ARB locked (link)

  • GMX. More than 4,000,000 ARB locked (link)

  • Camelot. More than 3,000,000 ARB locked (link)

  • Sushi. More than 1,000,000 ARB locked (link)

etc. It’s just a few examples (volumes are constantly changing)

Steps to Implement

  1. Select protocols to be taken into account in the calculation
  2. Analysis of the possibility of accounting for user tokens for the selected protocol
  3. For each protocol, write code that will take into account not only the presence of ARB tokens in the account of everyone who delegated to the Delegate, but also the presence of ARB tokens in the above-mentioned projects
  4. After appropriate audit, apply the code so that the current getVote() function takes this proposal into account

Timeline

Estimated schedule:

  1. Select protocols. 1 month from the end of voting on Snapshot
  2. Analysis by smart contract developers: 2 days for every protocol (up to 10 protocols are expected)
  3. Audit code: depends on results of analysis
  4. Apply the code

Total duration is about 16 weeks (4 month)

Overall Cost

Can be organized a grant for this work, with a cost of $100/hour

If it is impossible for employees to participate, you can hire programmers, 3 people for 4,000 ARB per month.

Audit - 10,000 ARB, it is possible to use the grant among individuals, since many companies do not check security, but issue certificates without greatly improving security.

Total amount: 3p x 4.000 ARB x 3 month + 10.000 = 46.000 ARB

5 Likes
2

This is already possible in some protocols. In Dolomite for example you can deposit ARB as collateral but also delegate these arbs to whoever you want. And I also heard there are also other ways available to implementi it.

Possibility is technically already there, it’s up to protocols to implement it.

1 Like
3

After the incentive programs that the DAO has executed I believe it is a good moment for implementing this proposal that has surfaced before but I don’t have the technical knowledge to know how complex it is and if possible. It would be great to have someone providing information regarding this topic.

1 Like
4

To begin with, we can allocate a grant for this research to understand how to implement it.
I have no doubt about this technical possibility

1 Like
5

Yes, you are right, some protocols may provide this capability.
But we cannot force all existing and future protocols to implement this.
Therefore, in my opinion, the right option is to develop our own technical capabilities to take into account locked tokens in protocols.

1 Like
6

gm @cp0x I think including ARB tokens in DeFi contracts in governance is important. One thing I’d note on a technical level is that the Flexible Voting module upgrade included in Tally’s proposal will make this much easier to do.

2 Likes
7

I think we can do this. Liquidity providers are like ARB holders, maybe they are really interested in participating in Arbitrum development by voting. If the technical possibility to do so exists, I see no reason not to do it.

1 Like
8

Hi, @Frisson
Wow, thanks for the link and this technical solution.
It perfectly suits the solution to the problems that I indicated in this proposal

1 Like
9

I do know that @MarcZeller has just finished implementing a similar change so that Aave could vote with their locked ARB tokens

Might be worth checking out what they did and getting an estimate of how many others like them there are.

Overall hugely supportive of this proposal. If we had DAO employees this would be a good task for them to take on; in their absence, the proposal cost is reasonable and i’d think it worthy of funding.

One thing i wonder is that since the amount is small, might it make more sense to approach @DisruptionJoe for a firestarter rather than direct to the dao?

3 Likes
10

Hello,

We do apply strategies giving voting power to Aave in some protocols, but doing so is quite trivial on Snapshot; the APE would be happy to write and make available a snapshot strategy that gives voting power to ARB deposited in Aave V3.

Let us know if that’s of any interest.

4 Likes