feat: dcurve

[thelostone-mc]

@dgrants/dcurve

This package allows you to create a distribution for a specific GrantRound based on the contributions recieved by the Grants.

This package is intended to be used

• by the dApp hosting dGrants to
  • generate the CLR distribution at the end of the round
  • how the prediction would vary for a grant it it were to receive an additional contribution of value X
• as a standalone dApp to allow members of the DAO to verify the distribution/merkle root themselves to ensure that the results are correct

Structure

.
├── src
│   ├── README.md               # getting started guide
│   ├── types.ts                # typescript types
|   ├── index.ts                # root of the project, exporting public interface
│   ├── internal
│       ├── calc                # folder containing implementations of CLR algorithms
│       ├── merkle.ts           # file containing implementations to generate merkle-root and claims
|       ├── fetch.ts            # fetch information from chain
|       ├── clr.ts              # orchestrator
└── ...

Examples/Testing

The distribution calculation has been (inefficiently) added to the datastore (app/src/store/data.ts) so that we can test the functionality ahead of getting this merged - please visit any page and check the console.

[frankchen07]

@thelostone-mc - in linear.ts starting on line 68:

    if (grantMatch.match >= matchCap) {
      // normalize match if grant has match greater than cap
      grantMatch.match = matchCap;
    }
  });

What's the use for match cap here? I think that was from downtown stimulus - we're not artificially limiting the cap, but we are normalizing when we hit saturation.

[frankchen07]

The rest of the CLR logic LGTM. 👍

[gdixon]

All changes are in!

Everything is working correctly, the fetch method may benefit from another set of eyes (@mds1?), in the future we will probably replace the rpc calls with queries to the graph, but for now I was wondering if we could better filter the GrantDonation's to pull down only a specific rounds events?

If we're happy to optimise later, then this PR is good for review 🙌 @apbendi @phutchins @mds1 @frankchen07 @corydickson @wildmolasses @jferas - any feedback, please let us know and we'll get it sorted asap! 👍

Thanks for all your help here @thelostone-mc!!

[mds1]

This is awesomeeeeeee great job! Love all the code comments too, really helped me understand what's going on 😍

Personally I like avoiding reliance on the Graph for as long as possible because it does add another dependency / point of failure. Added some comments about the query options, and one other thing is we can cache events in IndexedDB if we want (caching in localStorage will fill it up too fast)

[mds1]

Are these intentionally left as TODO for now? Also I don't see any tests, but this feels like a good package for testing since we want to make sure the results are accurate. But we can create an issue for that and handle it at some future date

[thelostone-mc]

yup ! we'd want to add this in soon

[mds1]

@thelostone-mc Is there an issue for this? Just looked but might have missed it

[gdixon]

@mds1 - I've just opened #137 and added some questions there to start the conversation - it might be better to track this in a discussion until we iron out the details though?

[corydickson]

kind of a nit, just wondering why it's not a constant here.

[gdixon]

This was just to demo/test that things are working, we will likely want to hook the prediction call in rather than calculate and we can probably avoid calling fetch from the app itself too.

We can remove these calls prior to merging 🙌

[phutchins]

All looks good!

[phutchins]

I could definitely see this being used in a DAO UI as its something that is very much needed. It may be a while before we have that however so I could see going either way for the short term.

all comments addressed