discuss: script calculating clr matching curve

[thelostone-mc]

What

Once 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

• who made the contribution
• amount of contribution
• and a few other factors (like trust bonus)

This calculation is also done during the round to let folks know

• what the current match is
• how much the amount would increase by if the user were to add a few tokens

V0 (in the next 1-2 weeks)

• 1:1 match algorithm and not even do pairwise (DO WE WANT TO DO THIS )

V1 (before round 11)

Personally, I'm not convinced that CLR calculation should be done onchain -> cause it's expensive. But irrespective of which route we take we'd want a script that would for V1

• consume -> GrantRound txn hash
• consume DonationSent event. Check here
• consume a list of addresses to ignore contributions
• calculate the
  • current match for every grant taking part in the round
  • match if 1 DAI was contributed
  • matching if 100 DAI was contributed

At the end of it , the dApp would have function which it would invoke to calculate this curve which returns the

• distribution curve
• current CLR matching
• hash of the current CLR matching

V2

• can take it other parameters to influence contribution match like trust bonus score

Related

Once 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

[frankchen07]

on-chain vs off-chain

I think it's agreed that the calculation shouldn't be on-chain.

1:1 or pairwise

Agree not to do pairwise, but also not 1:1, we can perhaps use the original quadratic, non-pair matching formula?

distribution curve

Do we need a curve, or just the output of the CLR match given the inputs?

[thelostone-mc]

Agree not to do pairwise, but also not 1:1, we can perhaps use the original quadratic, non-pair matching formula?

What was done for downtown stimulus i assume ? that could work

Do we need a curve, or just the output of the CLR match given the inputs?

Tweaked the description to make it more clear. The function would return

• distribution curve (this I feel is needed for UI to show how much a user's contribution would influence the contribution by)
• current CLR matching
• hash of the current CLR matching

[gdixon]

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?

[apbendi]

A few thoughts @thelostone-mc:

• You make a good point about how to show the matching estimate during the Round itself. I think there are two broad options here:
  • Host the matching script as an API endpoint that the frontend simply queries to return a value. Perhaps the appropriate endpoint could be a required field in the Round metadata, so other entities running a Round could simply point toward the endpoint implementing whatever matching algorithm they plan to use
  • Embed the matching script in the frontend and basically run it live in the user's client when viewing Rounds. This feels more "decentralized" in a way, as the user is running verifiable code on their device instead of trusting the response from an unknown API (to be clear, it's only an estimate, so it doesn't require trust for the actual payout). The problem I see with this understanding how different entities could seamlessy embed their own algorithms into the frontend. Maybe that's not a requirement for this prototype level frontend, though?
• Regarding which event to consume, and where that event will be emitted from, and what its parameters will be, just note that it's likely to change dramatically from what we have now based on the discussion in #20. General approach will be the same, though.
• There should also be an accompanying contract implementation, and the script should produce output that can be sent to an instance of that contract to "lock in" the payouts generated. Options here include:
  • A Merkle distributor, where the output of the script is a Merkle root set at contract deployment (eventually, I think we'll want this option)
  • A naive mapping solution where the output of the script is something like grantId -> payoutAmount, which is then sent via calldata to a method that configures the payouts then finalizes them so they can't be changed. The only reason we'd prefer this approach is speed to MVP— it's basically what we have now for payouts in cGrants, so it'd be easy to repurpose, and would require minimum work.
• I don't have strong feelings about the matching algo used for the MVP— ya'll have more experience with that and are better positioned to understand the level of effort and tradeoffs.

[thelostone-mc]

@gdixon

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?

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 Since we are using lerna => we could just create a new folder and have it added to lerna.json and treat it as it's module

@phutchins waddya think of this ?

---

@apbendi

There should also be an accompanying contract implementation

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

Host the matching script as an API endpoint that the frontend simply queries to return a value. Perhaps the appropriate endpoint could be a required field in the Round metadata, so other entities running a Round could simply point toward the endpoint implementing whatever matching algorithm they plan to use

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

The problem I see with this understanding how different entities could seamlessy embed their own algorithms into the frontend. Maybe that's not a requirement for this prototype level frontend, though?

So having as it's own node module, entities can either swap it out for their own module or instead raise a PR against the module to implement their version of it. (check the screenshot below for an example of what i was trying to do a few years back )

We tried doing this earlier as a pip package but didn't follow through. Check out the readme at and the type param where we would allow users to choose what type of funding they wanted

https://github.com/thelostone-mc/quadratic-funding/tree/patch-1

[apbendi]

So having as it's own node module, entities can either swap it out for their own module or instead raise a PR against the module to implement their version of it. (check the screenshot below for an example of what i was trying to do a few years back )

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?

[mds1]

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?

The GrantRounds metaPtr could be used for this, where the JSON schema specifies a field containing the match calculation details. Some possibilities for this field:

1. It returns a stringified JS function and frontends eval it. Not recommended because arbitrary code execution is obviously a big security risk
2. Each round/frontend uses the same algorithm/package, and the field returns an object with key-value pairs specifying values for all supported parameters shown in the screenshot from @thelostone-mc
3. We standardize an interface, and the field returns an API endpoint that returns match information based on the provided inputs. Frontends than query this API endpoint

[gdixon]

2. Each round/frontend uses the same algorithm/package, and the field returns an object with key-value pairs specifying values for all supported parameters shown in the screenshot from @thelostone-mc

I like the sound of this for our implementation - and I don't see anything to stop a third-party deploying their own frontend with their own algorithm - it all comes down to how the CLR coordinator wants to verify the distribution after the round ends. If somebody wants to run a round with their own calculation then it will just be on them to work out how to ratify their payout procedure, or they can feel free to use our mechanism?

---

Some thoughts on how the CLR matching might work with regards to issue: #20:

• In order to produce a verifiable distribution for each CLR we need to have the contribution amount denominated in a common currency for all contributions (for all CLRs) - as we're simply calculating a distribution, it is only important that we have a common denomination for the contributions and not the fund. If we allow contributions in any currency:
  • then this introduces the challenge of how we gather the conversion rate, we can't simply check the contribution value offline at a later date because this would result in different final hashes/merkle roots depending on when the calculation is ran or where the price data is sourced from (unless there is a trusted public api with historical price data for every currency with enough granularity to make this possible?).
  • then this means we will likely need to query the value of the contribution as it is made (with an oracle), but this also raises concerns. If a malicious user was to use a flash loan to increase the value of a dust coin before making a contribution, the price that we record on chain would be inflated, and will unfairly drain the match funds.

---

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?

[thelostone-mc]

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 ? The argument could be made here like how we have 1 GrantRegistry we have 1 Router Pattern.

Pretty much quoting what @mds1 said https://github.com/dcgtc/dgrants/issues/20#issuecomment-884184751

Another benefit of using the Registry is that is simplifies communications/authority decisions. Who gets to decide what is the "official" router that all rounds should be using? And how do you communicate to all entities when a new router is deployed? An example: what if (1) GrantRound1 starts with Router1, then (2) Router2 is deployed, then (3) GrantRound2 starts with Router2—it now is difficult to ensure my contribution is counted for matching in both GrantRound1 and GrantRound2 because they use different routers