Funding Request: Bounty Request on Unproposable market

Refund Proposer for Eth 1,600 market.

Proposer: Adam Sherman asherman@berkeley.edu

Proposal Summary I proposed the ETH 1,600 market correctly at the time of proposal, UMANS verified this, but since data disappears a correct proposal can also be disputed correctly, we should reward this bug find.

Project Description
Precedent for proposing the market the way I did.

Two other markets had been proposed where Coingecko data did not match many people’s visions of consistent reality.

The market above is similar to the ETH 1,600 market. No Uman dispute occurred as all Polymarket participants agreed the resolution source did not show a candle under 98c. Based on the recent ruling, this surely should have been disputed. Umans, as we now know, are willing to change the rules and requirements of a market after the market is over if an Uman whale indicates they believe it is the right thing to do for another company’s ecosystem and smart contracts, regardless of precedent.

For instance, in the above market, market participants saw Tether fall below 98c. It is widely reported and verifiable that Tether fell below a dollar, we all agreed that we saw it, and the price traded almost 99c, but the candle didn’t appear on coingecko.

Coinmarketcap had it hitting 95c. Many MEV trades were executed buying tether below 96c. But Coingecko had no candle on it. We resolved that market no as the resolution source was the historical data in coingecko. It did not fall below 98c on that resolution source, so based on the ancillary data, “The primary resolution source for this market will be Coingecko’s 30min candlestick low prices, with “Sun Jul 31 2022, 00:00:00” as the last relevant candle used for the market: https://www.coingecko.com/en/coins/tether.”

I resolved this market to no. There was no dispute.

Final Result: Coingecko candle in resolution source > credible reporting

The next market which made me believe it would be acceptable to propose the Eth 1,600 market on Polymarket

Note the rules:

The primary resolution source for this market will be CoinGecko’s 30min candlestick high prices, with “Mon Aug 01 2022, 00:00:00” as the last relevant candle used for the market. The resolution source can be found here: https://www.coingecko.com/en/coins/polygon. Note, this 00:00:00 candle lists the opening price at 11:30:00 PM ET and the closing price at 12:00:00 AM ET.

Traders, myself included, saw Matic trade over 1$ on many exchanges. This is seen on the Coinmarketcap for historical data for the day. The candle never appeared on Coingecko. So despite losing lots of money in this market, I did not dispute the correct resolution to no. No other Uman did as well, they respected our resolution source it resolved no, despite credible reporting that Matic reached $1.00.

Final Result: Coingecko candle in resolution Source > credible reporting

  1. Every other crypto price market was resolved with data that would not be available in a dispute without question, which was verifiable for only 24 hours. Umans and Polymarket bettors had been fine with this for over a year. Usually the candles and credible reporting match and are equivalent

Final Result: Coingecko candle in resolution Source = credible reporting, despite data not being available in case of dispute

This is the only time a dispute was made in a Crypto market and we learned all these markets have been using a faulty resolution source that isn’t available for enough time for the dispute, the proposer of this market should get a refund, and UMA and Polymarket harden the oracle going forward.

Value Add Keeps Polymarket working with the UMA ecosystem longer, rewards proposers who consistently follows the ancillary data protocol to bring markets to UMA.

Deliverables Delivered

Total Budget Requested 0x10010799404496d92058473cdbc99E6D22e174AF I am requesting $4,020 USDC equivalent in UMA, at 2.36 UMA per USDC thats approximately 1704 UMA.

Team Adam Sherman

Additional Information

I’m hoping I’ll get answers to some of the questions here as well

Questions I have:
Is there any valid proposal I can make after the 12:00 candle with 1600.07 comes out other than propose yes?
Do you believe no was the correct proposal at the time, and it would not have been disputed?
Do you believe yes was the correct proposal, but it should be disputed and then turned to no even if archive.org was available?
Do you believe yes was the correct proposal, but it should be disputed because no one used archive.org?
Do you believe yes was the correct proposal and no was the correct dispute vote in search of truth and that the proposer should lose 4,000 every time here?
Do you believe no one should propose these markets as they’ve been fundamentally flawed and UMA has allowed 100’s to pass without doing the relevant checks?

This is the most important question.
What should I have done to avoid losing $4,000 proposing a market that had all the ancillary data laid out in the rules providing a clear answer of yes, with hundreds of resolved markets as precedent
Do you support moving forward with this proposal?

  • For
  • Against

0 voters

2 Likes

UMA is an optimistic oracle which offers rewards to proposers, disputers and tokenholders for achieving consensus on questions that are presented to it.

To answer your questions first.

  1. Is there any valid proposal I can make after that candle comes out other than yes?
    Yes, no and undecided are all valid proposals.

  2. Do you believe no was the correct proposal at the time, and it would not have been disputed?
    Its impossible to say whether it would have been disputed or not.

  3. Do you believe yes was the correct proposal, but it should be disputed and then turned to no even if archive.org was available?
    The DVM has resolved that the price of eth at 16.00 UTC on 26th August was below $1600, therefore, with the benefit of hindsight, it can be seen that the correct proposal was no as this was the shelling point

  4. Do you believe yes was the correct proposal, but it should be disputed because no one used archive.org?
    It was correct to dispute as the DVM did not agree with the original proposal.

  5. Do you believe yes was the correct proposal and no was the correct dispute vote in search of truth and that the proposer should lose 4,000 every time here?
    This is a risk that the proposer takes when resolving a market where other people have different ideas of the correct resolution.

  6. Do you believe no one should propose these markets as they’ve been fundamentally flawed and UMA has allowed 100’s to pass without doing the relevant checks?
    All markets that have been disputed have been resolved through the DVM, if the market has not been disputed, tacit agreement on the shelling point has been reached.

  7. What should I have done to avoid losing $4,000 proposing a market that had all the ancillary data laid out in the rules providing a clear answer of yes, with hundreds of resolved markets as precedent?
    The data source that the ancillary data pointed to indicated that this may be a close call. This datasource is now unavailable, however screenshots are available. It can be seen that the close price indicated was 1600.07, very close to the cutoff and the opening position of the following candle looks as if (and indeed was, but you have to take my word for it!) below 1600, which should have indicated that there was a level of ambiguity and that any proposed answer to this market was at high risk of being disputed. Further investigation into the source of that ambiguity would have been prudent to understand the scope of the risk prior to making a proposal.

(Note that while the time on the screenshot (09.00) is not the time indicated in the proposal (12pm ET), I accept this as a valid screenshot as I was checked the market while the data was still available. However other UMA tokenholders cannot independently verify it as such.)

On the specific cases you mentioned.

  • Will USDT fall below 0.98 {within a restricted time period}
    The reported drop below 0.98 occurred on 12th May, and the market was not proposed until 31st July. Had there been someone who believed that USDT had dropped below 0.98 on 12th May, they had a full month to propose a NO resolution, there appears to have been prior consensus that this did not meet the conditions of the market.
    The data source pointed to in the ancillary data is now unavailable, as is many other sources with granularity that would confirm that USDT did hit an aggregated low below 0.98, although it can be confirmed that different exchanges did see substantial dips below that figure. Had a YES vote been proposed at the time, it is unclear which way it would have resolved.

  • Will $matic reach $1 by July 31?
    Again, although the high of $1 can clearly be seen on coinmarket cap, there is no way to verify that an aggregated price would have reached that level. Had that market been disputed at the time, with more information it is unclear which way it would have been resolved.

In the USDT and Matic cases, a proposal was made and there was no objection to that proposal, demonstrating consensus in the proposal, therefore it stands.

In the recent ETH case, there was no consensus and that was demonstrated by someone disputing the proposed resolution. When this dispute was put to the DVM, the consensus of the DVM indicated that the proposal was incorrect.

NOTE - posed in personal capacity as an UMA tokenholder.

  1. The DVM has resolved that the price of eth at 16.00 UTC on 26th August was below $1600, therefore, with the benefit of hindsight, it can be seen that the correct proposal was no as this was the shelling point.

This is ignoring the Ancillary data specifically provided by Polymarket. To propose no, when the candle showed 1600.07 would be assuming I knew that the Umans would ignore the ancillary data. Do you think this is a solid precedent for an oracle that asks for a specific resolution source to avoid ambiguity?

  1. Its impossible to say whether it would have been disputed or not.

Do you think it’s a good precedent to submit markets that directly contradict the ancillary data that Polymarket provides Uma?

  1. It was correct to dispute as the DVM did not agree with the original proposal.

What role does UMIP 107 saying that the data must be available at time of request and proposal in this? The DVM should support price requests for the YES_OR_NO_QUERY price identifier. YES_OR_NO_QUERY is intended to be used with ancillary data to allow anyone to request an answer to a “yes or no” question from UMA governance. This UMIP does not attempt to put any other restrictions on the content of the query, and instead leaves construction of the query up to the requester within ancillary data.

The ancillary data specified if a coingecko candle was available that should be used for resolution. No Umans are disputing that the coingecko candle was available, thus I’d have to ignore this UMIP to propose no? Should I make it a rule to ignore the Umips?

  1. This is a risk that the proposer takes when resolving a market where other people have different ideas of the correct resolution.

Once again should I ignore Umips?

  1. All markets that have been disputed have been resolved through the DVM, if the market has not been disputed, tacit agreement on the shelling point has been reached.

Once again, what is this shelling point if it’s not consistency? Every other market was reached without dispute, this shelling point is different than all previous markets. How would I know we would reach a new shelling point?

  1. The data source that the ancillary data pointed to indicated that this may be a close call. This datasource is now unavailable, however screenshots are available. It can be seen that the close price indicated was 1600.07, very close to the cutoff and the opening position of the following candle looks as if (and indeed was, but you have to take my word for it!) below 1600, which should have indicated that there was a level of ambiguity and that any proposed answer to this market was at high risk of being disputed. Further investigation into the source of that ambiguity would have been prudent to understand the scope of the risk prior to making a proposal.

It sounds like you are saying close markets with specific resolution sources shouldn’t be proposed? Does this work with 99-98 basketball games on who wins? Does it work on 90.01 oil prices on the CME website with a 90$ strike? Trust me I will never propose a close market to the Umans ever again! I just want to know do Umans think the inability to resolve close markets on Polymarket is a feature of the optimistic oracle, UMA, not being able to propose close markets or is it a bug?

2 Likes

I want to focus on a specific exchange in this forum between @squee and @Mhairi-UMA where the following question is asked by @squee:

Do you believe no one should propose these markets as they’ve been fundamentally flawed and UMA has allowed 100’s to pass without doing the relevant checks?

@Mhairi-UMA responds:

All markets that have been disputed have been resolved through the DVM, if the market has not been disputed, tacit agreement on the shelling point has been reached.

and @squee offers the rebuttal:

Once again, what is this shelling point if it’s not consistency? Every other market was reached without dispute, this shelling point is different than all previous markets. How would I know we would reach a new shelling point?

My perspective on this, ignoring the specific outcome of said resolution, is that there was no way for @squee to have knowingly proposed what the DVM determined to be the correct result. It is hard to dismiss the inconsistency of this resolution. The examples @squee has made have an undeniably similar ruleset and context to the recent $1600 ETH market and assuming that a “tacit agreement on the shelling point” was reached in these cases, no proposer could have anticipated the same would not be the case here. Now let’s assert the DVM produced the correct outcome in all cases, what that means is, at a minimum, the recent dispute established a new precedent for how to handle these competitive markets. This new precedent was established at the expense of @squee, an active UMA reporter, and some Polymarket traders, customers of the UMA OO. With the knowledge produced by this contentious vote, actionable improvements have can now be made including 1) hardening the price source used in a question’s ancillary data and 2) authoring an explicit UMIP that outlines the expected way these situations should be handled (because they are impossible to avoid 100% of the time). Generally, it seems clear to me that this edge case was not anticipated by the oracle, and any previous precedent was not explicitly adopted. As such I think, at a very minimum, @squee should be reimbursed his proposal bond in good faith for surfacing this unknown with the UMA OO resolution process. I would also push for Polymarket traders on the losing side of this outcome to be reimbursed not as an admission of DVM failure, but instead as a reward for improving and hardening the UMA oracle by surfacing an area of required improvement and clarification.

1 Like

Original Market Rules:

This is a market on if the price of Ethereum (ETH) will be above $1,600 in USD on August 26, 2022 (12 PM ET).

This market will resolve to “Yes” if Ethereum (ETH) has a candlestick closing price of $1,600.01 or more, as per the resolution source, on August 26, 2022, 12 PM ET, and “No” otherwise.

The resolution source for this market will be prices listed on CoinGecko (Ethereum Price in USD: ETH Live Price Chart & News | CoinGecko).

This market will resolve according to the “C” (i.e. closing price) listed for the candle titled “Fri Aug 26 2022, 12:00:00”, with the “Price” tab selected, in the Eastern Time Zone. Note, this 12:00:00 candle lists the opening price for 11:30:00 AM ET and the closing price for 12:00:00 PM ET.

The check will be after the relevant candle closes. If CoinGecko is unavailable, another credible source will be chosen.

After the relevant candlestick closed on CoinGecko, the resolution value was checked (in accordance with the rules) and determined to be $1600.07. A request was sent to UMA, and the proposer (Squee) correctly proposed P2 (1.0) - YES. As is always the case, CoinGecko keeps 30m candlestick data visible on the website for a 24-hour period. For this entire time frame, the “C” closing cost for the candlestick in the rules / ancillary data remained $1600.07 and was readily verifiable by both market participants and those discussing on the UMA server.

In fact, it was even posted by the main supporters of the N argument and verified by multiple UMA Team members including Clayton and Reinis. We went through an entire day of debate on the UMA server, and there was no contention regarding the candlestick closing price. Furthermore, UMA documentation (UMIP-107) makes it clear that a dispute on the DVM determines whether or not the proposal was the correct answer to the request given the request timestamp.

Even the CEO of Polymarket has said explicitly that $1600.07 was unambiguously the resolution value stipulated in the rules. And told us community members clearly that UMA has failed to provide the right answer. This isn’t just a rules interpretation debate like prior contentious disputes. For those, I would not have any complaint if the oracle had ruled the other outcome. Make no mistake. This resolution by UMA was a complete override of clearly delineated market rules, to the point where even Polymarket has had to publicly comment. The UMA Oracle led to an incorrect resolution of a Polymarket market, and this is a serious concern for both oracle integrity and the future of the prediction market space. If nothing is done to rectify this situation, this will be a deterrent against potential future integration partners trusting the OO. Even if it is an inherent limitation of the current dispute process, that doesn’t change that the wrong outcome was reached. I think the UMA Team has created a worthwhile product with the OO. While I fully believe the OO has real-world utility, UMA needs to step up and ensure that they improve over time and showcase that utility.

The proposal that Squee has put forward is a reasonable solution that would reimburse the proposer (Squee) and allot a fund of 10,000 UMA towards those who lost money trading the correct outcome. We are still in the infancy of the oracle, and reimbursement would serve in the best interests of both UMA and the trading community.

This is true, as it is true of all UMA markets, as individuals have individual perspective, but what matters to UMA is the collective perspective of tokenholders.

Some requests are relatively easy to propose on (eg is the price of BTC on 30th August 2022 below $0.01), because you can be very confident that few would disagree, others are more difficult because there are a range of opinions on the outcome. For example “What is the price of BTC on 30th April 2022 to 8 decimal places”, because

  1. There are a number of ways of interpreting the question (at close? average price? at 12 noon?)
  2. There are a wide variety of data sources that can be used to answer this are more likely to disagree with one another than not

Ancillary data works to reduce this risk of a proposal being overturned by the DVM in an upheld dispute by increasing specificity and suggesting a “front line” data source, but it can never eliminate it.

A proposer may assume that because markets based on this datasource that have similarly had ambiguous outcomes have not be disputed this one would also not be disputed, but that is an assumption. Anyone can dispute any market by paying the appropriate bond, a prior market not being disputed should not be taken as an indication that any future market may not be. The key thing that the proposer should be confident of before making a proposal is “If this were disputed, what is that the shelling point achieved by the DVM would be in line with my proposal”, or if they are not confident that the risk of losing the proposer bond is one that they are willing to take.

There is no new precident here. The principle that applies is that a proposal is true unless disputed, and if disputed is resolved by UMA tokenholders. This is the oracle working exactly as intended under the same principle it always has.

I have considerable empathy for @Squee in this situation. However Squee is not a customer of the Optimistic Oracle, the data-user of UMA is Polymarket - a prediction market which Squee and other traders are users of.

In the light of expectations of Polymarket users that this resolution has revealed, I think both of your suggestions are prudent to better align Polymarket with user expectations in particular ensuring that

  • any data sources referenced in ancillary data are available for the required amount of time in the event of a dispute
  • the ancillary data does not contain contradictory or ambigous information (such as the closing price of a candle not aligning with a specified time)

Issues with Coingecko as a resolution source appear to have been raised on the polymarket discord forum a number of times (1, 2, 3, 4, 5, 6, 7 ) dating back to June, giving considerable indication that the choice of source may have been sub-optimal.

I understand that Polymarket runs a Market Review Bounty Programme which includes identifying issues with the resolution source and edge cases in market resolution, although it appears that the incentives offered for review have not been sufficient to catch these issues, despite being raised informally on a number of occasions.

This type of edge case is the strength of the optimistic oracle - that it can resolve data even when a specified source is unavailable or ambiguous. The principle that the oracle works to is that proposals are accepted true unless disputed, if disputed the query is resolved by UMA tokenholders, which is exactly what happened in this case and all previous cases.

This isnt a DVM failure, the DVM worked perfectly as did the oracle. The problem seems to have occurred with a badly designed market which used an ambiguous data source with limited availability despite previously been identified as having problems.

I think that there may be a case for reimbursing @squee and polymarket traders in this market, however I would consider that as the dispute arose from (known) issues with ancillary data, it would be a matter for the data requester, in this case Polymarket.

NOTE - posed in personal capacity as an UMA tokenholder.

The general connotation of this reply is quite frustrating to me. It comes across very much as “UMA got this right, did nothing wrong, could have done nothing better and too bad to all of the affected parties” (which are both customers and UMA oracle participants). I agree there were some flaws on the Polymarket side. Coingecko was a poor choice of resolution source. But it would be dishonest to dismiss that as the only issue here. A few things:

  1. It is impossible to always write perfect questions
  2. UMA is designed to sort through ambiguity to produce the truth
  3. there is a clear disconnect between what most of the Polymarket side thought should have been the outcome and what the UMA DVM answered.

If you want to direct all the blame on to the question definition and take the stance that it was the only issue in this situation, that’s fine, seems like a great strategy to improve UMA and keep customers happy. I, instead, think that there should be a constructive conversation on reconciling the third point here taking the two former points as assumptions.

the DVM worked perfectly as did the oracle

If a question is asked by a user which has a clear expectation of resolution direction and it resolves to an outcome unexpected by the user I don’t think you can say everything with the UMA system worked perfectly. Sure the DVM in isolation may have produced the correct answer, but there was something wrong (prior precedents, assumptions etc.) that created such strong disconnect (which still exists after the resolution!!!).

I still strongly believe there was a change in precedent in the decision made by the DVM here, which is not to say the DVM was wrong, it’s just an objective observation which I have not heard a strong rebuttal to.

I have considerable empathy for @Squee in this situation. However Squee is not a customer of the Optimistic Oracle, the data-user of UMA is Polymarket - a prediction market which Squee and other traders are users of.

@squee has authored this proposal as the initial outcome proposer who had his proposal bond slashed. He is an active participant in the UMA oracle system - he is working directly for the UMA OO oracle as a proposer. I would think that UMA would want to take care of these agents who are the foundation on which the UMA OO is built.

1 Like

@Mhairi-UMA It’s been 14 days since this discussion started can we get a forum vote started this week?

1 Like

@L-Kov

It is for the proposer to add a poll to their Opening Post with a 5 day close.

(cc: @squee)

Note - posted as Admin

2 Likes

**EDIT: I support rebating Squee for his dispute bond; I absolutely do not support any kind of rebate to platform users on Polymarket.

humble tokenholder here,

Historically, Risk Labs has reimbursed on a few occasions people when something like this has happened. Top of mind: tokens sent to UMA contract address, and even an example like this one as I recall.

This is the first time such a request comes to the UMA DAO.

I support @squee’s request. Doing a whole DAO vote for it is hitting a tack with a wrecking ball, but it’s the only channel we have at the moment.

To opine on another topic…

I feel less interested in this question of “Was the result wrong” especially because you’d have to be willfully disingenuous to say there is only one side to this argument. I do think that we’re squabbling over some fairly provincial matters, if I can be blunt.

The reason? We started feeding questions to it that had historically been resolved based on precedent and familiarity, and expected the same results. It can’t really be surprising that this might happen. I also think that a conversation about precedent isn’t terribly useful. It’s not clear to me that precedent is even a good theory for modeling an optimistic oracle; it’s not some natural law. In fact, it’s what defines “common law” as opposed to “statutory law,” and I’m not sure it’s a great framework.

Either way, there’s lower hanging fruit than that:

I think it’s Risk Lab’s (and UMA DAO’s) responsibility to provide more guidance on:

1. How to ask the oracle questions and get the answer you expect
2. Research on the “personality” of the oracle, e.g., what it values. In this case, I think we saw that it values verisimilitude more than polymarket UX

There is progress being made on both of these. They should help requestors have a predictable experience, and help proposers be more confident in their proposals.

The optimistic oracle is a powerful coordination tool that gives a bunch of people the motivation to be honest. My personal opinion is that we’ve got a lot to learn about it. Does that mean this is “testing in prod”? No, I think we’re doing a lot better than that – But I do support reimbursing @squee because I think they were participating in an honest fashion, and got chewed up in an issue that arose from not yet having optimized #1 and #2 above. Arguing about whose fault it is doesn’t change that; even if it’s more on the requestor, I have no problem with UMA DAO being the one to make them whole.

I will close by saying my support of this proposal is just because I think it’s the way to behave with people who are working together to help build this thing. What I’d like is for @squee to keep proposing, to get $UMA from this and keep voting, and continue to be in the UMA community helping to reveal the power of this tool.

3 Likes

The result of the temp check was

  • 11 voters
  • 72% in favour
  • 27% against.

This will now go forward to a snapshot vote.

The budget request in the proposal is

0x10010799404496d92058473cdbc99E6D22e174AF I am requesting $4,020 USDC on Polygon mainnet to refund my proposal loss. I believe enough UMA should also be made available for traders in the marketplace who sustained losses in this market as well, I believe 10000 UMA would cover all losses sustained.

Note that the UMA governor wallet does not hold USDC on Polygon to perform the requested transfer of 4020 $USDC on polygon to 0x10010799404496d92058473cdbc99E6D22e174AF which is the only specific request in this proposal

@squee could you clarify the mechanism by which you would like this transfer completed.

Note: posted as Admin

Not to create too much of a sidebar, but the justification for providing a refund of @squee’s proposer bond is that:

  1. They were acting in good faith and made what seemed like a reasonable proposal at the time.
  2. The UMA DAO wants to encourage good faith proposers and disputers to actively participate in the system.
  3. The bond system has very sharp edges (since bonds are so high) that can result in good people getting slashed on rare occasions, and the UMA DAO always has the option (through governance) of reimbursing them for the bond amount, even if the proposal was deemed incorrect by the DVM.

As an UMA DAO member, I have long been a proponent of the DAO delegating voting power to voters with a high cost of corruption as a way of strengthening the oracle’s security and providing extra incentives to ecosystem participants.

Going forward, it may be worth considering delegating voting power to frequent (good) proposers and disputers, since these individuals provide a lot of value to the protocol and have a deep understanding of the oracle. If they are able to collect some (or all) of the voting rewards, that should also smooth out their risk of losing a bond in the rare edge cases.

This seems better, to me, than reimbursing bonds for specific votes. Since the active proposers/disputers are getting regular income from voting with their delegated tokens, their personal risk from posting bonds is minimized, but they still have an incentive to propose and dispute correctly (since losing the bond will cut deeply into their income, and there is no expectation that bonds would get reimbursed for any reason, even for edge cases).

I don’t know if @squee has any interest in something like this, and a vote delegation system to incentive and smooth out risks for ecosystem contributors is a much bigger topic (and way out of scope for this proposal, so I’m not suggesting we pivot from voting on a refund to voting on vote delegation), but it’s something worth mulling over for the future.

An example:
Doing some napkin math, let’s say we wanted to provide $2,000 a month in incentives to a selected community member. Based on a $2.50 UMA price, and an APY of 30% for voting rewards, they would earn $2,000 a month in voting rewards if they were delegated 64,000 UMA tokens in voting power out of the DAO’s treasury of 34,778,500 UMA tokens.

In this scenario, making a proposal that is successfully disputed still hurts (you effectively lose two months of voting rewards) and you have strong incentives to get things right, but it doesn’t feel too bad, and almost never happens, anyway.

As you say, this is a larger conversation, but I wouldnt see this as desirable as you want to maximise the number of active independent voters to achieve the best schelling point.

If you have delegation, you are reducing the independence of voters as it is then easier for an UMA tokenholder not to directly track what is being put onchain, but simply trust that an actor who has previously been honest will continue to be. Potential colllusion among those who amass large delegations is a risk and as there is also no sybil resisitance, it may not be visible when one entity has control over 51% of voting power.

Note: posted in personal capacity as an UMA tokenholder

I actually see the DAO delegating its (significant, unused) voting power as a way to increase decentralization and participation, but I’ll save that for a different thread. :slight_smile:

A snapshot vote on this funding request will go live in approximately 1h and will remain open for 5 days.

https://snapshot.org/#/uma.eth/proposal/0x59aed1d0009016b7098007b0b8e25c5f630507935d9f0942c8b0af5f13895c08

Note: Posted as Admin

1 Like