Recently this question was asked and put on hold as off-topic: In a futarchy, how do you measure the success of a specific proposal?

Using futarchy to measure the success of a specific proposal is a technique likely to be used by smart contracts - for example, it's likely that Gnosis will have have a futarchic mechanism to govern its upgrades. An good answer would likely point to some Ethereum code to show how people are using this mechanism for their Ethereum contracts. However, this is a general design technique not a specific code question.

There are probably a lot of other questions that fall into a similar category, particularly game-theory related.

Should these be considered off-topic for Ethereum? If so, is there somewhere more appropriate we could suggest people take their questions?

1 Answer 1


N.B.: I am personally against the concept of a futarchy, so keep this in mind.

Unfortunately, it's not quite on topic, but I don't think there's anywhere else either.

The help center currently lists philosophy as a disallowed topic. In this case, I don't know what objective answer could really be provided, since it's philosophical. What exactly makes one style of futarchy better than another? Is it all right if it's inaccurate, as long as the group benefits as a whole? Or does the system need to correctly award and punish the users so that the future uses of the futarchy are more accurate? Do you trust the proposers enough that they can select what indices their proposals are measured by? These questions aren't answerable objectively.

If someone could point straight to an algorithm or algorithms, then said algorithm could be straightly pointed, and the question would be objective. If the question was "How do I lazily evaluate a bunch of indices in Solidity with a given algorithm and match them to proposals?" then it would also be objective. Otherwise, it's a kind of "recommend me a tool" question.

Additional example: Someone making an auction contract asks about the different kinds of auctions and their theoretical advantages and disadvantages. Certainly we can provide code on how to implement any given method, or even suggest another if the one offered is difficult to implement. (Hidden bids, for example.) But asking for a general answer is stretching the boundaries.

Bigger picture question: At what point does "How do I architect my dapp?" go from legitimate question to too broad for this format? I personally am happy to explain the trade-off between using structs versus separate contracts, or avoiding race conditions, or the like. But there's more border cases like this one.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .