GIP-28: Allow GNO holders to vote even if their GNO are invested/staked/locked in Smart Contracts in different protocols/networks

Thanks for gathering some details on the existing GNO liquidity sources. This does indeed seem quite comprehensive and I would also vote in favour of such a proposal.

It is worth noting that this is a long outstanding GIP-8 (GIP-8: Enable LP token voting on Snapshot) that addresses this very same proposal - although it is rather outdated and the current liquidity is in many different places now.

I don’t think any GNO holder would be against such a proposal, but I suspect the reason it has stagnated for so long is that we are still lacking a concrete implementation plan.

Integrating such a feature, while entirely possible, would require infrastructure for determining exactly how much GNO should be credited to the LP tokens at, say a given moment in time. For traditional AMMs such as UniswapV2 (and similar) or even Balancer this amounts to fetching the pool reserves, the total supply of the LP token corresponding to the reserves and computing how much GNO corresponds to 1 LP token. This is relatively straightforward, but it gets a bit more complicated when trying to perform the analogous share holder representation for Uniswap V3 liquidity - since the LP token is actually an NFT representing how their liquidity is concentrated along the curve.

As a community member, I would be very keen to see this happen and willing to contribute some time to assist with implementation planning. However, I think that providing a concrete plan would be required before moving into the next steps.

Another thing to note is that we would likely have to introduce just a few liquidity sources initially and as time goes on, depending which sources remain substantial/relevant, add support new ones as the ecosystem changes.

7 Likes

But we’re not the first project to face that – I am 90% sure that’s already solved, if not, you can always calculate the global state for each position? See 6.2 in the uni v3 wp.

I am 90% sure that’s already solved

Yes, I wasn’t suggesting its impossible, but rather more involved. I mostly wanted to highlight that each of the different liquidity sources would require a different integration - so that such an endeavor would be manual and require maintenance as the liquidity shifts around to different (not yet supported) protocols.

xDAI is using multichain and delegation with parameters.

https://snapshot.org/#/xdaistake.eth/settings

3 Likes

@elbagococina thanks for this important initiative.
Could you amend your first post with numbers of how much GNO are currently in all those protocols? This would make the discussion much easier.

Also - I would add GNO tokens that are simply on other chains (e.g. Gnosis Chain). This would be the very first step - it would be a shame if you can’t use your GNO on Gnosis Chain to vote in Gnosis DAO.

Regarding the 8 strategy limit - you can theoratically engineer around it (xDAI team did that) by writing aggregation contracts that read balances from different sources and use those aggregators as strategies.

But I am not sure we need that at this point.

6 Likes

If one is using snapshot it shouldn’t be that hard to include liquidity positions.

Also I consider it almost imperative for governance and the health of communities like Gnosis for users to be able to earn return by providing liquidity AND still be able to participate in governance.

I will be pushing for this in MakerDAO and would like to see this move forward for Gnosis.

Given GNO is going to be used on Gnosis chain (formerly xDAI) and GNO is going to be used for liquidity rewards I would like to see GNO liquidity in sushiswap, honeyswap, symmetric, swapr, Agave, Cowswap (when it arrives) be included in voting. In fact I was disappointed that the GNO I now own in the auction contract is excluded. But since I have put it up for sale it makes sense. I also realized my STAKE which will also convert to GNO at .0326 is also excluded - but also makes sense not to include STAKE not converted…

At some point I will establish a firm GNO holding but more than likely it is going to be in a LP and not just sitting doing nothing in a wallet.

Given the above I agree with:

Please seriously consider doing this

1 Like

Hi! Thanks for your support @mkoeppelmann

Mainnet:
Balancer V2 WETH/GNO → 68,147 GNO
Balancer V1 WETH/GNO → 2,400 GNO
Uniswap V3 ETH/GNO → 65,800 GNO
Uniswap V2 ETH/GNO → 362 GNO
Bancor GNO/ETH → 835 GNO

xDai:
Honeyswap GNO/xDAI → 808 GNO

Arbitrum:
Balancer WETH/GNO → 5,806 GNO

Gnosis Beacon Chain:
Validate blocks (staking GNO) → 10,762 GNO

Total GNO= 153.7 kGNO

7 Likes

I found 2 other proposals very similar to this one.

Anna’s proposal is in phase 2 so it’s quite clear this is something the community wants.

@elbagococina Let’s add the top strategies by GNO holdings including Gnosis Chain, move to phase 2 and try to get to snapshot asap.

3 Likes

There is too little public discussion on this topic to reasonably conclude that it is ‘quite clear’ this is something the Community wants.

Most other Communities that offer similar forms of voting require a wallet holder have unfettered tokens in the voting wallet at time of snapshot to participate in a ballot. This encourages active participation and helps moderate the incredible imbalance that can exist when large funds, pools or insiders are allowed to vote with effectively sequestered assets.

A critical point is if staked or loaned assets are allowed to be voted, there is virtually no ability to control multiple votes being cast with the same assets. For example, original holder loans asset to a pool, borrower withdraws to a fresh wallet, then stakes in a third location. Two votes or more could be cast in the case case, with possibility of 200% or (more) voting weight than the original asset amount.

If you are investing your GNO, great! Consider the invested amount as you would any investment such as bonds, 401(k), annuity, etc. Invested funds are not available without action; those assets cannot vote.

If you want to vote, keep some assets (GNO in the case) in a wallet to vote in case snap ballots are created. How much you intentionally hold for voting is up to you. If you want to sponsor a campaign and have extra voting power, make sure to withdraw your GNO to a wallet so it is unencumbered in time for the snapshot.

Requiring these procedures as most blockchain voting systems seems to do allows the Community to track asset flow and better understand what might be happening before announcements are made; this helps keep the Community active and strong.

Finally, it is critical that GNO on xDaiChain (now Gnosis Chain) be allowed to vote. I doubt many, or any GNO holders at all knew or even considered the possibility that voting would not be available.

1 Like

Other communities are clueless if they’d rather have their tokens idle in their wallets instead of being used in DEFI . How can idle GNO encourage active participation? GNO is not a tradfi stock. Applying GNO to different DEFI protocols gives utility to the token and improves GNO overall:

  • GNO holders providing to AMM are natural price defenders by automatically buying when price drops.
  • GNO holders providing to lending pools provide liquidity and tools for traders.
  • GNO validating blocks protect Gnosis Chain.

I really wish everybody utilised ALL their GNO, but it’s risky and requires time and effort. These DEFI users provide a valuable service to GNO and their voice should be heard.

The attack vector for money markets you mentioned that allows to borrow same assets is valid. Maybe we should not allow voting for GNO on protocols like Aave, Agave or Compound.
Thanks for raising that up! @1proof

I agree with your final point, GNO must be available to vote on Gnosis Chain.

3 Likes

A quick update on this. @cris and I are working on an implementation. We have found a way to include more than the previous limit of eight strategies, you can keep track of the implementation details in this notion card.

Along with GNO on mainnet and Gnosis Chain, we currently plan to also track GNO balances in:

Mainnet

  • Balancer v2 - WETH/GNO
  • Uniswap v3 - ETH/GNO
  • GNO Locking contract

Gnosis Chain

  • GNO locking contract
  • MGO contract
  • GBC validator deposits
  • Honeyswap - GNO/xDai
  • Honeyswap - GNO/ETH

The remaining question is whether to track GNO in Symmetric, Swapr, Elk, agave, 1Inch, and/or SushiSwap? And if so, in which pools within those system?

4 Likes

Hi @auryn_macmillan! Thanks for you answer. I think the list that you share it’s OK. If you can add the small pools on those protocols (Symmetic, Elk, etc) it would be better. It would be good to track them. Please add GNO/WETH on Symmetric, GNO/WETH on Sushiswap, GNO/WETH on Elk, GNO/WETH on Swapr.

2 Likes

FYI: Coming from the Gnosis chain side and the fact it is now GNOsis chain the DAO should at least allow GNO there to vote.

I have GNO validators
GNO openly held in open wallets
GNO:wxDAI on Symmetric

People say to pull assets before the snapshot. This is not practical and would only encourage various forms of front running on trading before LP is pulled and after it is replaced. This is a nightmare that is easily avoided by just including various assets in the snapshot with appropriate weights.

I don’t see the issue here other than what contracts to add and how to implement the improved snapshot vote. The idea I have to hold some GNO on Ethereum basically doing nothing is really a waste and alienates all the smaller GNO holders many of them now on Gnosis chain itself.

If governance means that only a certain holder, holding in a certain location, and certain form can vote, well then governance is basically preferring one class over another and denying some of these classes of people their right to participated in decision making. imo I see good governance as something that is inclusive and not exclusive and so the onus is on governance to do everything possible to be inclusive vs. to be progressively exclusive.

1 Like

I believe everyone is onboard with being as inclusive as possible. Most everyone shares that sentiment in this new space. It appears that technical challenges are delaying an all encompassing snapshot. Although, as stated above, it’s merely something that requires “more involvement.” Given this space is moving at hyper speed right now and the seemingly ongoing bull market, it’s understandable that the devs have to prioritize what’s more important to the DAO. Of course, I’m not minimizing the importance of all-inclusive governance, just providing an explanation as to why this long outstanding GIP hasn’t been implemented yet.

I see the description in the link you shared here, but I can’t really see where the plan is being executed? Do you have a GitHub link. It Might encourage someone like myself to help out…

1 Like

In addition, we should also add GNO in the locking contract on Ethereum and Gnosis Chain.

4 Likes

Sorry for the long delay on this everyone. It has been a really bumpy road, but I think we finally have a candidate for the new setup.

Unfortunately, due to some setbacks and roadblocks during implementation of the subgraph, we had to make the decision to only include GNO, MGNO, LGNO, and staked GNO in the new strategy. We’ll make a subsequent proposal once we’ve implemented a version of the subgraph that accounts for GNO in UniswapV2, UniswapV3, Balancer, and Aave.

Note: I’ll post this as a Snapshot proposal tomorrow (Thursday) once I have confirmation from a few others that all of the inputs look correct.


Proposed Transactions:

Mainnet Safe Transaction Payload with Tenderly simulation:

This transaction should:

  1. enable the new Reality module
  2. Update the gnosis.eth ENS name with new text records records for ETH, XDAI, snapshot, daorequirements, quorum, URL, twitter, github, and avatar.
  3. disable the current Reality module
[
  {
    "to": "0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe",
    "value": "0",
    "method": "enableModule(address)",
    "params": ["0x0d70332CEB7F3C94b061cda48327891E3449A9E1"],
    "operation": 0
  },
  {
    "to": "0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41",
    "value": "0",
    "method": "multicall(bytes[])",
    "params": [
      [
        "0x10f13a8c77651e2c25d2b7b073d1068420770f96a43563e74df60e234b2433b2be66e29e000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000008736e617073686f740000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000035697066733a2f2f516d5654346679547875724353337178316b77745038654b4863347847424d7567587835515131686d4459644c320000000000000000000000",
        "0x10f13a8c77651e2c25d2b7b073d1068420770f96a43563e74df60e234b2433b2be66e29e000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000f64616f726571756972656d656e747300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000035697066733a2f2f516d5a5841625979447437575571324871637651726e7877377a58475043474a76515853724e736a696b343955790000000000000000000000",
        "0x10f13a8c77651e2c25d2b7b073d1068420770f96a43563e74df60e234b2433b2be66e29e000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000671756f72756d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000053735303030000000000000000000000000000000000000000000000000000000",
        "0x10f13a8c77651e2c25d2b7b073d1068420770f96a43563e74df60e234b2433b2be66e29e000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000375726c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001168747470733a2f2f676e6f7369732e696f000000000000000000000000000000",
        "0x10f13a8c77651e2c25d2b7b073d1068420770f96a43563e74df60e234b2433b2be66e29e000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000661766174617200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000035697066733a2f2f516d56443555484d5a66767375584a52645663626e6d7250677355466a446a705358416d6664763357374d4e34320000000000000000000000",
        "0x10f13a8c77651e2c25d2b7b073d1068420770f96a43563e74df60e234b2433b2be66e29e000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000b636f6d2e646973636f7264000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001668747470733a2f2f636861742e676e6f7369732e696f00000000000000000000",
        "0x10f13a8c77651e2c25d2b7b073d1068420770f96a43563e74df60e234b2433b2be66e29e000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000a636f6d2e676974687562000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006676e6f7369730000000000000000000000000000000000000000000000000000",
        "0x10f13a8c77651e2c25d2b7b073d1068420770f96a43563e74df60e234b2433b2be66e29e000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000b636f6d2e747769747465720000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008676e6f736973706d000000000000000000000000000000000000000000000000",
        "0x8b95dd7177651e2c25d2b7b073d1068420770f96a43563e74df60e234b2433b2be66e29e000000000000000000000000000000000000000000000000000000000000003c000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000140da0c3e52c977ed3cbc641ff02dd271c3ed55afe000000000000000000000000",
        "0x8b95dd7177651e2c25d2b7b073d1068420770f96a43563e74df60e234b2433b2be66e29e0000000000000000000000000000000000000000000000000000000080000064000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000140da0c3e52c977ed3cbc641ff02dd271c3ed55afe000000000000000000000000"
      ]
    ],
    "operation": 0
  },
  {
    "to": "0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe",
    "value": "0",
    "method": "disableModule(address,address)",
    "params": [
      "0x0d70332CEB7F3C94b061cda48327891E3449A9E1",
      "0x0eBaC21F7f6A6599B5fa5f57Baaa974ADFEC4613"
    ],
    "operation": 0
  }
]

Gnosis Chain Safe transaction payload:
This transaction should enable the new Reality module.

[
  {
    "to": "0x0DA0aDE3840133AAD32723fDf2cDBaE6D753A2F3",
    "value": "0",
    "method": "enableModule(address)",
    "params": ["0xf1C276217e305D701484fa510A2efaf8A31573fd"],
    "operation": 0
  }
]

Snapshot settings

The snapshot settings should be updated to:

  • enforce voting duration (7 days)
  • enforce when voting starts (immediately on creation of proposal)
  • enforce when snapshot is taken (same block that voting opens)
  • enforce basic voting (FOR, AGAINST, ABSTAIN)
  • enforce specific multisend contracts for each Reality module
  • add the newly deployed reality modules
  • use the gno snapshot strategy (aggregates GNO, LGNO, MGNO, and staked GNO on mainnet and Gnosis Chain)

Snapshot Text Record

The snapshot text record at gnosis.eth should be set to the IPFS hash QmVT4fyTxurCS3qx1kwtP8eKHc4xGBMugXx5QQ1hmDYdL2, corresponding with this json file:

{
  "name": "GnosisDAO",
  "skin": "gnosis",
  "about": "GnosisDAO transparently guides decisions on development, support, and governance of its GNO token ecosystem. Start your proposal here: https://forum.gnosis.io",
  "terms": "ipfs://QmYMwQwmsDPTtt3ncu1CaZXyJgdYD4EMbn86oAxT3AVtye",
  "avatar": "ipfs://QmVD5UHMZfvsuXJRdVcbnmrPgsUFjDjpSXAmfdv3W7MN42",
  "github": "gnosis",
  "symbol": "GNO",
  "filters": {
    "minScore": 1,
    "defaultTab": "all"
  },
  "network": "1",
  "voting": {
    "type": "basic",
    "delay": 0,
    "period": 604800,
    "hideAbstain": false
  },
  "plugins": {
    "safeSnap": {
      "safes": [
        {
          "network": "1",
          "realityAddress": "0x0d70332CEB7F3C94b061cda48327891E3449A9E1",
          "multisend": "0xA238CBeb142c10Ef7Ad8442C6D1f9E89e07e7761"
        },
        {
          "network": "100",
          "realityAddress": "0xf1C276217e305D701484fa510A2efaf8A31573fd",
          "multisend": "0xA238CBeb142c10Ef7Ad8442C6D1f9E89e07e7761"
        }
      ]
    },
    "quorum": {
      "total": 75000,
      "strategy": "static",
      "basicCount": [0, 2]
    },
    "poap": {}
  },
  "twitter": "gnosisdao",
  "website": "https://gnosis.io",
  "location": "Ethereum",
  "strategies": [
    {
      "name": "gno",
      "network": "1",
      "params": {
        "symbol": "GNO",
        "decimals": 18,
        "SUBGRAPH_URL": "https://api.thegraph.com/subgraphs/id/QmfZ5cepEwspcrLLwtA3i5M6qEnv3WKDkpAtC65t8VpY6M"
      }
    },
    {
      "name": "delegation",
      "network": "1",
      "symbol": "GNO",
      "params": {
        "strategies": [
          {
            "name": "gno",
            "params": {
              "symbol": "GNO",
              "decimals": 18,
              "SUBGRAPH_URL": "https://api.thegraph.com/subgraphs/id/QmfZ5cepEwspcrLLwtA3i5M6qEnv3WKDkpAtC65t8VpY6M"
            }
          }
        ]
      }
    },
    {
      "name": "gno",
      "network": "100",
      "params": {
        "symbol": "GNO",
        "decimals": 18,
        "SUBGRAPH_URL": "https://api.thegraph.com/subgraphs/id/QmaggnWhZKpqudcFgkNVbiu8HCYRPtK11EL2TMeA6S5ZXV"
      }
    },
    {
      "name": "delegation",
      "network": "100",
      "symbol": "GNO",
      "params": {
        "strategies": [
          {
            "name": "gno-vote-weight",
            "params": {
              "symbol": "GNO",
              "decimals": 18,
              "SUBGRAPH_URL": "https://api.thegraph.com/subgraphs/id/QmaggnWhZKpqudcFgkNVbiu8HCYRPtK11EL2TMeA6S5ZXV"
            }
          }
        ]
      }
    }
  ]
}

DAO Requirements text record

The daorequirements record should be updated to remove things like quorum and minimum bond, which are now defined in the Snapshot settings above.

The daorequirements text record at gnosis.eth should be set to the IPFS hash QmZXAbYyDt7WUq2HqcvQrnxw7zXGPCGJvQXSrNsjik49Uy, corresponding with this markdown file:

# GnosisDAO Proposal Acceptance Criteria
In order for GnosisDAO's SnapSafe module to execute a transaction, any corresponding proposal must have passed, as reported by Reality.eth.

The reality.eth question should conform to this template (the required template ID is defined by the installed Snapsafe Module):
json
{"title": "Did the Snapshot proposal with the id %s in the gnosis.eth space pass the execution of the array of module transactions that have the hash 0x%s and does it meet the requirements of the document referenced in the daorequirements record at gnosis.eth? The hash is the keccak of the concatenation of the individual EIP-712 hashes of the Module transactions. If this question was asked before the corresponding Snapshot proposal was resolved, it should ALWAYS be resolved to INVALID!",
"lang": "en",
"type": "bool",
"category": "DAO proposal"}

Reality.eth should resolve the question to **“yes”** only for proposals that:
* the number of votes **FOR** is greater than the number of votes against **AGAINST**.
* were initiated as a Snapshot proposal in the `gnosis.eth` Snapshot space.
* had no significant service outages or availability issues that could have reasonably restricted GNO holders from casting their votes in the proposal.
* the module transaction hash in the Reality.eth question is the keccak hash of the concatenation of the individual EIP-712 hashes of the module transactions defined in the Snapshot proposal.
* the plain description of the transactions, and their intended result, in the proposal is complete and accurate.
* did not occur during, in, or as a result of any unauthorized or malicious changes to the gnosis.eth Snapshot space.
* were not filtered from the default view in the gnosis.eth Snapshot space during the voting period.

Reality.eth should resolve the question to **“invalid”** if:
* the Reality.eth question meets the above requirements but was created prior to the end of the proposal vote period and/or the snapshot block for the vote. i.e. the final results of the vote are not yet known.

In all other cases, the Reality.eth question should be resolved to **“no”**.

Subgraph

We battled with this subgraph for way longer than we should have trying to get Uniswap to play nicely, but ultimately had to make the decision to remove it for the sake of getting this proposal up.

The current subgraph is the the sans-uni branch of this GitHub repo. It accounts for GNO on:

In the Snapshot settings above, we reference each subgraph by its IPFS hash, rather than linking to an <account>/<subgraph>, in order to improve security. This means that we will require a DAO proposal to change the subgraph in future once we get accounting for the the various AMMs and lending pools working as intended.

4 Likes

Great to see the proposal go live!

As any proposal touching the module is absolutely security-critical could you summarize?

a) What are the exact changes of the new module contract?
b) Can you refer to an audit?
c) Was there a bug bounty? / We should put out a very significant one ($2m+)

1 Like

a) the primary change was to use the version of Reality.eth (v3.0), which allows us to enforce a minimum bond inside of the Reality module.

b) yes, there was an audit back in September and there are a number of DAO’s using this version in production already. You can see the report here: zodiac-module-reality/ZodiacRealityModuleSep2021.pdf at main · gnosis/zodiac-module-reality · GitHub

c) We don’t have an explicit bounty on this contract right now, but we could spin one up quickly with Immunefi. Shall I go ahead and get that set up?

1 Like

Definitely support enabling governance tokens to also earn yield, provide liquidity, etc. as it’s important for increasing voter participation and reducing the opportunity cost of holding governance tokens for voting purposes only.

However, would prefer to see a new proposal that includes all the critical details that were later added in the forum comments (and preferable directly in the snapshot.) Would like to support a future version of this proposal that incorporates all updates and details directly in the proposal.

1 Like