DAI payout (26/08/2022-25/09/2022) - luzzifoss

As per the original worker proposal’s terms (visible here) I’m asking for 9000 xDAI in total to be sent to DevX’s wallet (DevX.eth).

Proof of work


Work on the contracts continued in order to get back a final report from Sigma Prime, which came back Sep 16th.

On the v1 contracts I have:

  • Improved the CREATE2 salt generation algorithm to make it harder to have collision between 2 different KPI tokens.
  • Reduced gas consumption by a lot on KPI token creation by avoid passing the entire template struct information to the newly created KPI token to store. Instead, the base template manager now keeps track of all template versions that were ever created so that only the information about the template id and version can be passed to KPI tokens. In the template view function of the token it’s now sufficient to call the base template manager in order to get template info at a specific version.
  • Moved the KPI token initialization logic to the factory instead of the template manager to save gas.
  • The contracts were slimmed down a little bit logic wise, making them slightly clearer.
  • Used a struct in oracle initialization to avoid stack too deep errors (natspec doc and tests were updated in the process).
  • Implement ownership transfer in ERC20 KPI token and also enforce it in the generic KPI token interface.
  • Added a Foundry script to manually add a template to any given template manager.
  • Improved overall project documentation surrounding the available Foundry tasks/scripts and what generally can be done.

Proof here.

On the alpha frontend I have:

  • Removed the previously featured campaigns
  • Added new featured campaigns
  • Prepared the release of the new versions with the newly featured campaigns.
  • Fixed the public path in the webpack config that was causing issues in the frontend.
  • Upgraded the dependencies.

Proof here.

A few changes in the project’s overall v1 structure were also made. A monorepo was created with all frontend-related stuff put in one single place. This also helps handling interdependencies as you can work on related projects with less context switches all around. At the same time templates development will be done in separate repositories, as templates can be seen as their own little “apps” in the Carrot ecosystem, with the main frontend acting as an orchestrator so to speak.

1 Like