juicebox

Synopsis

I think Juicebox V4 and all of its components are ready to be deployed to Ethereum Mainnet, Optimism, Arbitrum, and Base. We’ve spent the past year on finishing touches and audits, with many meaningful improvements made along the way. We could always spend more on audits, but there comes a point where we have to acknowledge we’ve done our absolute best and that its time to publish for public use.

The Juicebox V4 deployment will include the deployment of the $NANA revnet which receives fees from the ecosystem – in the same way $JBX does in V3. The proposed configuration for the revnet is simple:

1,000 $NANA issued per ETH, cut by 38% every 360 days, split limit of 62% operated by dao.jbx.eth. Cash out tax rate of 0.1.

To quote from https://rev.eth.sucks/memo, “There is no such thing as an a priori ideal tuning of a revnets rules, just as there was never an apriori perfect Bitcoin halvening timeframe or fixed supply number. A successful tuning is one that manages to convey the right incentives – either on purpose or on accident – to stimulate growth over time.”

In general I think:

1. Juicebox DAO should own the majority of the revenue (62%, golden ratio, why not), and distribute the remaining 38% to fee payers and whoever else wants to partake in the $NANA revnet.
2. Issuance should decay slowly but meaningfully. We want to accumulate funds into the treasury and issue new $NANA instead of rushing to scarcity and a buyback outcome, as this will facilitate greater access to loans.
3. A cash out tax rate of 0.1 allows plenty of access to revenues and loans for $NANA holders.

It’s also nice to open up the discussion with a very simple configuration and use it to weigh tradeoffs of other ideas folks may have.

The deployment will also include the deployments of $REV, $CPN, and $BAN. Juicebox DAO should expect to be recipients of splits from those revnets, but should not expect to be split operator like it is for $NANA. There are no guarantees.

JuiceboxDAO will want to legitimize a new multisig that exists with the same address across chains, using the same signers. This is the one that’ll be set as the $NANA Operator, and it will be subject to the same rules and governance processes as the current multisig.

Specification

There is no hard specification here. The proposal serves as a forum to discuss the readiness of the code and the $NANA values, and ultimately a vote of confidence.

The todo list would be: - Make a new multisig across chains with the same signers and policy as the current multisig. - Jango and 0xBa5ed will lead the deployment the protocol. - Recommend clients use the resulting production contract addresses.

The deploy scripts being run can be found in:

- nana-core https://github.com/Bananapus/nana-core - nana-buyback-hook https://github.com/Bananapus/nana-buyback-hook - nana-swap-terminal https://github.com/Bananapus/nana-swap-terminal - nana-721-hook https://github.com/Bananapus/nana-721-hook - nana-suckers https://github.com/Bananapus/nana-suckers - nana-address-registry https://github.com/Bananapus/nana-address-registry - nana-project-handles https://github.com/Bananapus/nana-project-handles - nana-fee-project-deployer https://github.com/Bananapus/nana-fee-project-deployer - revnet-core https://github.com/rev-net/revnet-core - croptop-core https://github.com/mejango/croptop-core - banny-retail https://github.com/mejango/banny-retail

Timeline

As soon as the vote passes.