What it does
Every time there is a proposal up for vote, we take the
proposal_period and chunk it up into
N discrete buckets. At the end of each bucket, the offered reward for voting steps up to the next bracket. At the end of the voting period, some random
threshold_block is chosen at which point all further votes will be counted toward the final vote, but not rewarded directly. Hence it is in the voters' interest to: a) carefully analyze their real cost of voting and b) submit a vote as close to when the the proposed reward by the DAO surpasses it.
There is seemingly the incentive to delay indefinitely in order to maximize rewards, but the caveat is that they run the risk of delaying past the threshold block (which is determined retroactively) and hence being frozen out of rewards entirely.
Challenges we ran into
- provably fair method of picking
Accomplishments that we're proud of
- Groking and implementing the research article in just a few days while also learning how NEAR works from scratch
- Actually writing some Rust code that works (after being scared away by Substrate years ago)
What we learned
- All the
near_sdktypes and blockchian specific primitives to use out of the box
- All the testing tools provided by
- How a NEAR DAO is structured (with the Sputnik example)
What's next for Meta DAO
Nretroactively in a provably fair / random way (maybe like Polkadot's Candle Auctions)
- build a UI and a community around it to play with it
Log in or sign up for Devpost to join the conversation.