OIG Election Contract Issues

[mdcryptonfts]

OIG Election Voting Discussion

Hello, I have some concerns about the current voting contract and how it impacts the overall WAX ecosystem. I would like to propose these concerns, and a possible solution so that others can provide feedback about what side effects / issues may potentially arise if these changes were to be implemented.

What's The Issue?

We all know that WAX has been struggling for some time now to gain any relevancy in the crypto space. We haven't seen any real innovation or onboarding of users or developers, and the token price has continued to go down (which is fine theoretically, but the chain will not be able to sustain itself after a certain point if this goes on for too long).

With the recent launch of WaxFusion and Alcor's LSW, we are starting to see some new life come into the ecosystem. Some users have started to come in from other chains, random people are creating Twitter threads about why WAX Blockchain is the future (haven't seen this happen in years before recently), Alcor's liquid staking contract has achieved 6.5 million WAX in TVL in their first 4 months, and WaxFusion has reached almost 2.5 million WAX in TVL in its first 4 days in existence.

In turn, the success of WaxFusion has further increased the TVL of Alcor due to the built in liquidity incentives, and we are working on some partnerships with other projects as well.

Liquid staking tokens are the first building block of DeFi. We now have yield bearing assets that can be built on top of by other projects, so pretty soon you will start seeing the second stage of DeFi, where lending platforms and other similar projects will start launching.

The ecosystem will continue to grow, multiple projects will be attracting users from different chains/communities for different reasons, and you will also see some of this capital/volume start to spill over into the other projects on WAX, such as NFT markets etc.

The problem is that when the OIG Election comes around, we will likely see bank runs on some of these protocols because people will want to get their capital out so they can vote for the election canditates. If the first building blocks of DeFi are getting subject to bank runs, then everything built on top of them will suffer as well, destroying all of the hard work and innovation that took place for close to a year prior to the election. And, this will happen every 6 months moving forward.

Furthermore, the current voting contract is extremely inefficient and limited, due to needing off chain scripts to run every minute and sync every single voter in the election contract with the current state of the chain. For this reason, we also can't have weighted voting (1 person submits a vote of 1 million WAX for Kaefer, and 500k WAX for t break as a second choice, for example).

My Proposal

I am open to feedback on what I am about to propose, so please tell me if you see any flaws in my logic.

I think that these issues can both be solved with a governance token contract that issues tokens to voters. These tokens should be non-transferable. Prior to each election, there should be a timestamp x days ahead, that is considered a "snapshot time".

Being that the delegated bandwidth table on the system contract is indexed by from and to, and there is no global tally of how much WAX a single user has staked, the solution IMO is relatively simple.

Create a table on the new governance token contract with the same indexing - from and to as a 128 bit secondary index (or scope by from and primary index by to).

On the governance token contract, have a claimtokens action. When the action is called, look up the 128 bit key. If it exists, check if they claimed their tokens already. If they haven't, issue them and set the flag to true.

If it doesn't exist, you issue tokens to the voter based on their current stake on the system contract. You also emplace a row, storing a record that this user got their tokens already for this election.

If it does exist but they've already claimed, you do nothing.

But what if something changes on the system contract?

A simple notification could be added to the system contract.

ACTION system::any_action_that_might_affect_delegated_bw(){

    // This code snippet can also be added to open source, multisig token contracts
    // like WaxFusion's token contract, to allow lsWAX holders to be issued tokens.
    // Other contracts like Alcor's LSW could be open sourced and mutisig'd with 
    // OIGs and the WAX team if they wanted LSW holders to be able to vote
    if( is_there_currently_an_election() ){
        notify_governance_token_contract( existing_resources_struct );
    }
}

After the notification, the governance token contract does the lookup, and if from has not been issued voting tokens for the from_to_combo yet, emplace a row with bool has_claimed = false, along with the staked resource information.

But this might break the system contract

I really don't see how, if it's written properly and tested thoroughly. The actual voting itself should be on a different contract to avoid this contract having any logic aside from issuing tokens and storing records of who was issued what.

The token contract and governance contract should both be open source and either multisig, or directly under the control of the WAX team. It should be audited properly and not just some random contract - it should be considered a part of the system.

This is also 1000x more efficient, because when users vote - they vote with their tokens, not with their "current state that hopefully might not change on the delegated bandwidth table". This means no off chain scripts, no "rechecking everyone's state 100,000 times throughout the election", and the ability to vote for multiple candidates. You simply allocate x amount of your governance token to a candidate. Update the voter, and update the global tally of votes.

This could be abused because of the RAM costs

Have a minimum requirement of 50 WAX or the equivalent of LSWAX (for example. could be less, could be more). This prevents storing 1e8 records for 1 WAX worth of stake weight by 1e8 bots with 0.00000001 WAX each. When the voter claims their tokens, they take over as payer. If they don't claim, their records are deleted after the election anyway and the RAM is freed up. I am more than happy to personally donate 5,000 WAX of my own money to buy RAM for this contract.

I am also more than happy (and would prefer) to write this contract (and the accompanying code snippets) myself and submit it to whoever needs to audit it.

Final Thoughts

We are getting to a point where this is actually going to matter. The chain is getting exciting due to the start of DeFi and introduction of LSTs. There is a reason why the vast majority of top TVL projects in the entire crypto space are liquid staking derivatives. See DefiLlama for proof.

I would love to get ahead of this problem before it exists. I am not asking to let my contract (or anyone else's) submit votes on anyone's behalf. Simply suggesting that voting tokens could be issued to holders of WAX LSTs, provided those contracts are open sourced, multisig and approved by the actual WAX team.

Also, even if the idea of supporting LSTs is not something that the team wants to do (which would still leave us with a huge issue to deal with), this logic is still valid for people staking the WAX token itself. It would greatly improve the election process.

Please provide any feedback and address your concerns in case I am missing anything. i.e. how this might affect APIs/indexers/SHIPs etc.

[mdcryptonfts]

Also, a 2nd option is to completely ignore everything I said about LSTs, but still do the other stuff with voting tokens for WAX stakers, and allow weighted voting.

Then platforms like mine/Alcor's can just write our own voting contracts to allow users to tell us what they want to vote, and then our contract can submit on their behalf since the non transferable tokens would be held by the LST contract.

[NKCSS]

Some notes. 1: I don't think people care that much about voting that they will pull out staked assets (at least not the majority). 2: this doesn't need to be an actual token, you could just snapshot vote_power per wallet and have a vote action with amount that lets you allocate vote power. Could even make this opt-in (e.g. have a 'register to vote' action that makes sure your account is snapshotted; that way you can limit resources involved as well.