Author: jango & filipv
After migrating to Controller3.0.1 to patch the original bug described in this postmortem, JuiceboxDAO should now complete its migration to Terminal3.1 and Controller3.1 in order to permanently fix all known risks and inefficiencies.
The DAO should also send a special transaction to distribute FC#11 payouts to make up for a bug that surfaced from the migration to Controller3.0.1.
Lastly, the DAO should permit projects to be made and registered in the Directory through the new JBController3.1.
The Controller migration to 3.0.1 patched the reserved rate bug outlined in the postmortem, while still keeping old interfaces for backward compatibility to Terminal 3.0. This allowed the DAO to fix the reserved rate bug was quickly. JuiceboxDAO should now use the best contracts available while offering them to new projects.
Changes how reserved tokens are stored and accounted to remove a class of potential user bugs that can occur when reconfiguring a funding cycle from one reserved rate to another. It removes backward compatibility with JBController, which JBETHPaymentTerminal3.0 requires out of the project’s controller.
Is resilient to payment failures between projects. When one project pays another during a transaction to distribute funds, funds will be returned to the original project’s treasury if the payee’s payments are paused or if there’s a bug in their pay extensions.
The 3.1 terminal also has a new affordance for adding to a project’s balance bypassing the refunding of held fees, and allows calls to
useAllowanceOf to pass in metadata to log in events.
Payout distribution bug patch
The original migration from Controller 3.0 to 3.0.1 also caused a reset to the DAO’s distribution limit for Funding Cycle #11. This proposal recommends sending a special one-time batched transaction to distribute the funds by first swapping back to the old 3.0 controller where the FC#11 distribution limit was specified, then distributing the available funds, then swapping back to the patch Controller 3.0.1. This is a one-time transaction and should be done before the migration to Controller 3.1.
Setting controller privilege
JBController3.1 was created and deployed in order to make reserved issuance more robust, and specifically to solve an issue with v3 JBX migration. JuiceboxDAO migrated to this controller as part of JBP-335, but new projects cannot be deployed with the updated JBController unless it is added to a list of trusted controllers, which can be done by calling
- Step 1: The multisig should call
setIsAllowedToSetFirstControllerin JBDirectory (
0x65572FB928b46f9aDB7cfe5A4c41226F636161ea) with the forthcoming JBController3.1. Await contract address confirmation from drgorilla, jango, 0xba5ed, and viraz. This allows new projects to be created and registered in the directory using the new controller.
- Step 2: Within Funding Cycle #11, the multisig should batch call special distribution functions to 1) swap back to the old 3.0 controller where the FC#11 distribution limit was specified using
setControllerOfin the Directory, 2) distribute the available funds from the Terminal3.0 that JuiceboxDAO currently uses, then 3) swap back to the patch controller 3.0.1 using
setControllerOfin the Directory. This is in order to fulfill the distribution of the cycle #11.
- Step 3: Queue Funding Cycle #12 on JBController3.0.1 (JBDAO’s current controller) to have
allowTerminalMigrationsflags set to true.
- Step 4: Within Funding Cycle #12 after distribution of payouts, the multisig should migrate to JBETHTerminal3.1 and JBController3.1 using the convenience wrapper Operator _befor_e submitting a subsequent cycle rule revisions for Funding Cycle #13, which should be made on JBController3.1. Await Operator contract address confirmation from drgorilla, jango, 0xba5ed, and viraz. This will get JuiceboxDAO on the up-to-date terminal and controller. Neither JBController3.1 or JBETHPaymentTerminal3.1 are backwards compatible. They must be upgraded together, otherwise some functionality will not work until the other is also upgraded.
- Step 5: On JBETHPaymentTerminal3.0, set JBETHPaymentTerminal3.1 as feeless by calling
setFeelessAddress. This allows payouts from one terminal to the other as project pay each other without incurring fees. Also, on JBETHPaymentTerminal3.1, set JBETHPaymentTerminal3.0 as feeless.
See the specification.