Skip to main content

JuiceboxDAO Operations Post Mortem

author - filipv

These errors are in the process of being mitigated. See the Notion Tracker and this summary on Discord.



Resolved. Felixander returned all 3.7109970336715117 ETH to JuiceboxDAO v1 in transaction 0x456a41c7902c949c4f2fe5f34e0b3798f8dfd2e447acc74a8707bf116a43c892.

What Happened?

felixander.eth was paid an extra 3.7109970336715117 ETH across two transactions:

What Went Wrong?

The first extra payment was caused by a bug with Juicebox v1. As Jango describes it:

aha. yeah i recognize this. it's a V1 bug recreated by:

  • being in FC#X with funds still not distributed.
  • reconfiguring FC#X+1.
  • distributing funds from FC#X.

That distribute call creates a new FC that overwrites the reconfiguration. bug stumbled upon in Slice earlier on too. lets be mindful to distribute from V1 before calling reconfigure to it this next time around. seems like it'll be among our last V1 reconfigures anyways.

This rolled over into a second extra payment due to the multisig failure decribed below.

Solving This

Felixander will have to transfer 3.7109970336715117 ETH back to JuiceboxDAO v1 (v1p1) via the addToBalance transaction. I shared a video tutorial detailing the steps to do this here.

Juicebox Rewards


Resolved. Juicebox referral returned 1.8119844678505186 ETH to @juicebox in transaction 0xe3fbb179b9220950f82e49b404d1a770e9728f6ad88cba72968c2bf474c53b38.

What Happened?

JBP-330 approved a one-time payout of $3,000 to Juicebox referral (v2p410), which was sent in transaction 0x95ec31ba8a78a18ecf0934d9c02513f8373bd02296acfecec233c99dc9fa02df.

Juicebox referral then received an extra $3,000 payout of 1.8119844678505186 ETH in transaction 0x3e3f920800b1b805fd2cbc932678a58e2e3765105e462659630e80def698d082 (see event #113).

What Went Wrong?

What was originally supposed to be a one-time payment rolled over into a second payment due to the multisig failure decribed below.

Solving This

I queued a transaction from the multisig which owns this project (0x7A05B46bFd5f26F3E40a28E4fE49DE338b63235E) to pay out 1.8119844678505186 ETH to v2p1 with preferAddToBalance enabled. After this takes effect, the payouts will have to be distributed from the project, and a new cycle will be queued to remove the payout.


What Happened?

WAGMI Studios received 3 $8,500 payouts approved by JBP-314:

  1. v1p1 -> v1p5 @ 0x9469aa6d691ba9db62cdc87f763827f6b44b323992042a25dee7ac5248c7da8f
  2. v2p1 -> v2p387 @ 0x07b07428942da6dc869d8b031ac235969f0bc4ad6bc7e317e9806ae13e0d931c
  3. v2p1 -> v2p387 @ 0x3696159562c1ec9bccaf11272ee8ed664c2b9c91d10c8de98d14259ec2ab8ccc

But then, due to a bookkeeping error, WAGMI studios received 2 unapproved $8,500 payouts:

  1. 4.965342738066261773 ETH — v2p1 -> v2p387 @ 0x95ec31ba8a78a18ecf0934d9c02513f8373bd02296acfecec233c99dc9fa02df (log 185)
  2. 5.133955976086274861 ETH — v2p1 -> v2p387 @ 0x3e3f920800b1b805fd2cbc932678a58e2e3765105e462659630e80def698d082 (log 122)

Summing to 10.099298714152536634 ETH. Some of this ETH was left in the @wagmi-studios project, and some of the ETH was paid out to sagekellyn.eth and mieos.eth in the following transactions:

  1. 4.175902021980110846 ETH — v2p387 @ 0x6e2c3afaaad12d49dc224494be698e5abe152631486796a7c8bed537f4a1792b:
    1. 3.492043502119130738 ETH -> sagekellyn.eth
    2. 0.582007251032196916 ETH -> mieos.eth
    3. 0.101851268828783192 ETH -> Fees
  2. 4.542612757707288829 ETH — v2p387 @ 0xfd00bf7cd209f9c7323ba868ac950a8869ca275f90727e21cac7d317b98160f3:
    1. 3.798700563303292015 ETH -> sagekellyn.eth
    2. 0.633116761289184890 ETH -> mieos.eth
    3. 0.110795433114811923 ETH -> Fees

Solving This

  1. sagekellyn.eth will have to transfer 7.290744065422422753 ETH to v2p1 via addToBalance.
  2. mieos.eth will have to transfer 1.215124012321381806 ETH to v2p1 addToBalance.
  3. @wagmi-studios will have to pay out 1.380783934465136959 ETH to v2p1 with preferAddToBalance set to true, or pay out the ETH to another wallet which can transfer it to v2p1.

I'll get on a call with Sage and Mieos to figure out the best way to execute this.

Multisig Failure

The multisig must queue, verify, sign, and execute any edits to JuiceboxDAO's projects at least 3 days before the next cycle starts for those edits to take effect.

On 2023-02-21, The multisig had several transactions queued and got them signed towards the end of this period, with ~4 hours left until the edit deadline. At the time, gas prices were high. @twodam shared several messages to this effect:

all signed, can be executed when gas price are low @jango

now it costs ~$500 to execute both reconfigure txns

Nobody executed the transactions before the edit deadline.

Process Improvements

Following these events, several process improvements were implemented to prevent the recurrence of issues like these:

  1. I wrote the Multisig Process which was then ratified through the DAO's governance process. Along with updating several multisig rules, it lays out guidelines and best practices to ensure that the queuing process happens smoothly.
  2. Nance's monitoring tools are improving. Thus far, an easier to read payouts table is being regularly posted in the #🧾|bookkeeping channel on Discord, and Jigglyjams is working on public view/edit functionality.
  3. Den may be improving. On a call with Den, 0xBA5ED and I described these issues and discussed potential improvements for monitoring deadlines.