discuss: script calculating clr matching curve #56
-
WhatOnce a GrantRound is complete, we calculate the distraction using the CLR pairwise matching algorithm This lists out what each grant would get based on the
This calculation is also done during the round to let folks know
V0 (in the next 1-2 weeks)
V1 (before round 11)Personally, I'm not convinced that CLR calculation should be done onchain -> cause it's expensive.
At the end of it , the dApp would have function which it would invoke to calculate this curve which returns the
V2
RelatedOnce this script is ready, the next steps would be deciding where to store this hash and the actual distribution curve once a round ends cc @gdixon |
Beta Was this translation helpful? Give feedback.
Replies: 10 comments
-
I think it's agreed that the calculation shouldn't be on-chain.
Agree not to do pairwise, but also not 1:1, we can perhaps use the original quadratic, non-pair matching formula?
Do we need a curve, or just the output of the CLR match given the inputs? |
Beta Was this translation helpful? Give feedback.
-
What was done for downtown stimulus i assume ? that could work
Tweaked the description to make it more clear.
|
Beta Was this translation helpful? Give feedback.
-
I agree with @thelostone-mc - it makes sense to have the distribution curve calculated here too, we just need to make sure that the calculation is being performed regularly and whereever we store the result will have to differentiate between ongoing and final distribution data. -- Should we also be building out an interface to allow third-parties to perform the calculation and approve the hash within the system? I'm envisaging a simple page within dGrants that the user can visit, which will allow them to view the calculation, hit calculate, retrieve the distribution (we could show them this as a visualisation and toggle to show the raw data) along with the final hash. We would then have a button for the user to submit their hash to an onchain (or offchain) destination to signal their approval? Would it make sense to produce this as a standalone repo/project so that users could pull from github and confirm nothing has been manipulated before they produce and submit their hash? |
Beta Was this translation helpful? Give feedback.
-
A few thoughts @thelostone-mc:
|
Beta Was this translation helpful? Give feedback.
-
You mean as a separate node module ? I like this idea -> then this can be imported into this repo and the function could be invoked to get the value. overtime this does make it easier to go crazy with this and adopt diff kinds of matching algorithm @phutchins waddya think of this ?
Let's sync up on the next call so that we're on the same page and i get go ahead and write a spec to get us kicked off
Yup ! Looking at what @gdixon said -> this actual business logic could live in it's own node module and the dapp can install this as a dependency -> and host and endpoint which it can consume itself / expose it for others to consume
So having as it's own node module, entities can either swap it out for their own module or We tried doing this earlier as a pip package but didn't follow through. https://github.com/thelostone-mc/quadratic-funding/tree/patch-1 |
Beta Was this translation helpful? Give feedback.
-
But if the frontend is a generic Round browser, then how will it know which algorithm a given Round it is being asked to display is supposed to use? |
Beta Was this translation helpful? Give feedback.
-
The GrantRounds
|
Beta Was this translation helpful? Give feedback.
-
I like the sound of this for our implementation - and I don't see anything to stop a third-party deploying their own frontend Some thoughts on how the CLR matching might work with regards to issue: #20:
I think the safest way forward is to convert the contributions to a single currency, the idea of having a router seems to be the best way to accomplish this, that way we can keep all contributions in a common currency and avoid the need for oracles at all (other than uniswap as a swapping mechanism). We could also lean on uniswap to allow the user to claim their contributions in any currency they like by setting a preferred payout currency which would route the contribution through uniswap again before landing in the grants wallet? The main concern here would be the cost of gas and the swapping fees - which might render the contribution amount negligible unless it is made in the correct currency to begin with, or if we hold all the contributions in contract and allow the grant owner to claim + swap when they see fit? Does this sound valid @thelostone-mc @phutchins @apbendi @mds1? Any other thoughts on how we might avoid these issues/get to a position of being able to run a CLR calc over the contributions? |
Beta Was this translation helpful? Give feedback.
-
So which means have another contract the Router Pattern and all funds go via that which is responsible for swapping it to given token AKA all grants receive a contribution in the same token What i am unclear on what happens when someone deploys their own RouterPattern and swaps it out for a different token. Would that mess things up ? Pretty much quoting what @mds1 said #20 (comment)
|
Beta Was this translation helpful? Give feedback.
-
As discussed on standup! |
Beta Was this translation helpful? Give feedback.
As discussed on standup!
We'll be implmenting linear QF and rolling with that for our first round.
Pairwise would have to wait as we still need the convience layer "backend" to be able to store results (as pairwise is way moer expensive)