Synopsis

State what the proposal does in one sentence.

Keep DrGorilla.eth in JuiceboxDAO recurring payouts, without compensation change, for another 8 cycles, under the quality of software engineer focused on contract and blockchain engineering.

Motivation

What problem does this solve? Why now?

DrGorilla.eth has been poking holes into the protocol for a lil less than 2 years now, as software engineer (working mostly on the smart contract side). Offering to renew DrG's payout (and, therefore, to keep using gorilla's code) solves 2 issues:

software engineers (and especially blockchain/solidity focused ones) are hard to find and to keep
Juicebox has been growing into a big codebase, with a pretty steep learning curve, increasing the need to have developers at ease with the shadiest corners of it (DrG loves shady corners)

DrGorilla.eth has been working on the following piece of codes recently (and might forget some other minor projects/non-core thingies) - as the previous similar proposals, some projects were scheduled, others not, and some others were dropped. DrG roles is first and foremost reactive (to business needs) then proactive (improvement/safety and coding creativity driven).

Juice metadata library (author) + implementation in existing delegates: this is a core piece in supporting multiple delegate as it allows having data passed to specific delegate (ie this takes multiples data for multiple delegate then build a small "dictionary" which can then be used to easily find these data). This project is done.
Buyback delegate (author): This pay datasource and delegate allows to use an Uniswap V3 liquidity pool as source for a project token. This gives payers (individuals or other project) the best rate between funding cycle weight and Uniswap, while sustaining secondary market price (if under the minting rate). This project is done.
C4 BBD (author/victim): Code4arena audits can be painful, as it requires answering lots of questions and reviewing lots of not-so-funny findings. DrG lead and supported this C4 audit of the Buyback delegate.
Delegate registry (author): As new needs/use-cases arise, DrG has been extending the delegate registry (which provide a list of delegate to the frontend, to determine which one is from a "trusted" deployer)
Terminal 3.1.1+3.1.2 (reviewer/tester): See JBP-140 (

https://www.jbdao.org/s/juicebox/410)

- DrG has been mostly helping in review and testing the new terminals
721 (reviewer/tester): DrG has been doing a similar role of reviewing and testing the latest development.

DrGorilla.eth offers to pursue working on (if no other more urgent needs come up):

Multi-datasource and -delegate supports: the metadata library was a first step (as it solves the metadata problem), other issues still need a solution (eg how to reconciliate multiple weight? How to determine delegate allocation from the datasource? etc)
Optimise the multi metadata lib: while the current version is fairly gas efficient, DrG is convinced having a low-level language (aka Yul) might gives a bit more saving. As the protocol peripheral contracts interactions grows, every marginal gain in gas needs to be actively hunted down.
New token supports: terminals should be allowing them easily, 2 things needs to be tested and might require extra-work: oracle (and limitations/safety guards) and inter-terminal interaction (for project having ETH and USDC for instance, how to process this in delegates? Are redemptions correctly computed? etc)
Protocol safety: on top of overall availability for protocol emergencies, we still lack resistant monitoring and alerting tool (this has been taken over from previous proposal, BBD/C4 having been prioritized by DrG in the meantime)
Resume the "smart treasury" effort: a vault-terminal was being built, a while ago (AppleJuice Terminal) but never crossed the finish line. Having dormant ETH (or other token) doesn't make much sense, DrG would like to resume effort for having, at least, a way to stack ETH (while keeping redemption unchanged)
Any other need which will arises (in the extreme unlike event the previously mentioned projects all came to an end before 7fc, DrG keeps a list of "nice to have"/LT todo's in the Contract Crew Github project -

https://github.com/orgs/jbx-protocol/projects/5

- this hasn't been updated recently tho)

Specification

How exactly will this be executed? Be specific and leave no ambiguity.

Renew DrGorilla.eth payout of 15000$/cycle (transferred to the Exhausted Pigeon project (421), home of the gorilla), for a standard 8 cycles duration
Execute a one-time transfer of 2m $JBX from the multisig balance to DrGorilla.eth

NB: If JBP-418 is approved, pay Exhausted Pigeon (421) 22500$/cycle for 5 cycles instead

Rationale

Why is this specification appropriate?

"We are not rekt" && "We use DrG code" => "code good": under this logic fallacy, DrG tries to express his obsession for safe and efficient coding practices. And column-aligning source code (which is obviously prettier). By having acquired an extensive protocol knowledge (as part of the protocol came from his keyboard), DrG is a good asset for JuiceboxDAO.
Compensation is inlined with Sr blockchain SWE freelance market rates (a bit below average, a tad less than 200$/h) - DrG asked chatGPT which agreed: https://chat.openai.com/share/e332b52e-645f-4f46-8fad-09a696a80e33
Having a $JBX allocation increases the exposure to the JuiceboxDAO treasury, better aligning long-term incentives (DrG is open to deploying a vesting contract for these, if the DAO sees it as needed during debates/temp check)

Risks

What might go wrong?

DrGorilla might disappear or starts producing low quality code.

DrGorilla might start acting like an actual gorilla (again), and subsequently throw faeces on people.

Timeline

When exactly should this proposal take effect? When exactly should this proposal end?

Next cycle start.

Votes