In IIP-67 (above) we agreed to delegate our UNI to Flipside. This would allow them to make the proposal, and use our UNI to vote FOR.
What happened?
Shortly after the proposal went live here, Index Coop delegated UNI votes back to our Operations wallet. This was done with the intention of being prepared to vote on any other Uniswap governance votes that might subsequently be proposed.
However, once the UNI votes were delegated away from Flipsideâs wallet address, the proposal fell below the required proposal threshold allowing the vote to be cancelled. A Uniswap community member then stepped in and cancelled the vote.
This was an error on our part, and Iâm deeply sorry for the added confusion and frustration this caused Flipside & the Uniswap community. The IIP the Index Coop agreed to above specifies that UNI should be delegated to the Flipside address for the duration of the vote.
In my opinion, the Index Coop have not yet followed through on itâs commitment outlined in IIP-67. If Flipside were to request another UNI delegation per the IIP-67 specification, I would be supportive. But this is a subject for the community to decide.
I would agree that we must take heed and learn from this mishaps.
Though I believe itâs just an oversight and human mistake and wasnât intentional; which is bound to happen occasionally. Especially in this fast pace industry. It just how we react & mitigate the fallout that matters.
Moving forward we need to mindful of this especially when it involves Meta-Governance and certain processes needs to be established if this occurs again. As it could affect the credibility of our brand.
Thatâs unfortunate and I appreciate the teams efforts to make this happen in the first place.
Iâd strongly recommend that once weâve decided what to do next (re-attempt or let it go), we should do a Correction Of Error (COE) document that details 1) what went wrong, 2) five why analysis on why it went wrong, and 3) updated process documented so that we avoid this again.
Iâm happy to drive this if folks agree. Iâve found this to be very helpful in the past, and it will help us build much more robust processes as we scale.
Thatâs a facet of the UNI voting that I wasnât aware of. I assume that this means that our vote power varies over the course of a vote as DPI mints and redeems?
Obviously, snapshot votes are based on the number in the address at the snapshot block.
While itâs not ideal, the key thing is no funds we put at risk. (I also understand that the vote was compromised by a bug on Tally).
Almost. Voting power is snapshotted at the proposal block for Uniswap governance. On the other hand, proposal power fluctuates even after a proposal is created (and did in this case since we undelegated too early).
Iâd like to clarify something. @dylan is free to characterize it as an error, but in my view it wasnât an error. The un-delegation was done with Flipsideâs blessing. Neither Flipside nor the Coop were aware that doing so would make the proposal cancellable. Certainly an oversight, but not an error in my view. The un-delegation was intentional to bifurcate âdelegation to allow the proposal to be put forwardâ and actual voting.
âIn light of errors with Tallyâs front-endâ is easy to gloss over there, but supplies the substantive rationale behind the cancellation.
I agree with Dylan that we still âoweâ delegation for this proposal if thatâs how it happens. However, that depends on what Flipside wants to do. For reasons entirely unrelated to ICâs delegation/undelegation there may be some adjustments to their approach.
Disclosure - Iâm on the exec team at Flipside as well as a contributor to the Coop.
Agree with @fallow8 that it wasnât an error, just had unknown implications for the voting process. We view this as a blessing in disguise â with the Tally issues yesterday, we would not have wanted to proceed with miscast votes.
Flipside is appreciative of the partnership weâve started with the Coop, and would love to continue working together as we take in community feedback from yesterday and work to resubmit our proposal! Iâd love to find a way to engage the Coop and other stakeholders earlier in the process â though weâre super appreciative of the constructive feedback yesterday, it came at a point when we couldnât change the proposal that was already up for a final vote. My DMs are open on Discord if anyone wants to chat about this!
As a Coop contributor, Iâd also love to continue the conversation on the best way for these delegations to happen in the future. There was some great conversation last week on who should be involved in delegations (meta gov committee vs community IIP vs alternative solutions), as well as whether delegations should be viewed as an âyesâ vote towards the proposal or simply an agreement that the proposal is worth putting up for a vote.
I agree that getting more community feedback is helpful, but Iâd say that @sassal IS missing something if the characterization of the proposal is âallowing an entity to loot $25MM from the treasury to pay for its operations.â
The program was intended to be funded through yield on the grant. And the grant was proposed to be staged as $15M for one-year, and then either extended with an additional $10MM based on success at the end of that one year. The initial grant could be returned by an Oversight Committee at any time.
Some of the loudest and probably most salient feedback was that the CEO of Flipside not be on the Oversight Committee. Which I think is obvious and fair and likely a misstep for the proposal.
Still agree with @Matthew_Graham that we should look at ecosystem feedback overall. I think monetsupply.eth does a great job of providing substantive feedback on his no-vote. TL;DR below, but the whole thread is worthwhile:
The Meta Gov Team has been working on a few ideas for formalizing a Meta Governance Proposal (using Indexâs MetaGov Powers for direct proposal/delegation) Framework.
This incident has shown the need for clarity around this area, and hopefully, that work is posted to the forum soon for the community to discuss, debate, and iterate upon.
Obviously we need to improve the process of delegating votes, but I believe we as asset managers have bigger questions to answer. We as Asset Managers/Investment Managers have the biggest stake in developing analytics to enable us to track the performance of tokens in our âindexesâ. Uniswap is (just one) exchange (with a big Treasury). Flipside is (just one) data vendor. WE are consumers of analytics. The issue is analytics BY whom and FOR whom. I think the entire proposal needs to be rethought from the perspective of who does what, who competes with who and who should be in charge. First of all, Flipside is not a yield manager, this job belongs to platforms that do asset/yield management (there are several). Second of all, in crypto (unlike TradFi) data is on-chain, and yes, analytics primitives and derivatives need further development. HOWEVER, judgement is always required to turn data into information. In this process, bias is ever present. We need a proposal where asset managers (who are the end-users of analytics) are in control of (competitive) bounties to develop (consensus) primitives and feeds with (transparent) assumptions and (general) accessibility. The fact that Uniswap has a big Treasury not currently being farmed for yield is actually irrelevant to the problem. As an (neutral) exchange, Uniswap and others should not be involved in transforming raw data in any way, especially not funding the work.
Hey @TJB2K â feels like your comments are mostly about the Flipside proposal rather than the IC delegation issue, so not sure if the forum is the right place for this. That said, Iâm happy to chat about your concerns! You can find me on discord, same handle, DMs are open
I am sure others in Index Coop would like to understand where to find a PUBLIC statement of the problem Flipside is trying to solve, what role Index (and other Asset Managers) should/could play, and why Uniswap (and not other exchanges, or any exchanges for that matter) are being involved? Regulators take a keen interest in what supposedly neutral exchanges do to their dataâŚwe have to figure out how buy-side and sell-side analytics are going to work with on chain data.
