JBTiered721DelegateStore Postmortem

Author: jango
Date: 2023-06-06
Severity: Low
Status: Resolved

Shared via Discord

While refactoring the Defifa Governor today, I discovered a low severity bug in the JBTiered721DelegateStore. The lockVotingUnitChanges flag in JBTiered721Flags is not respected if a new tier is passed with its useVotingUnits flag set to false while its price is positive.

This bug was introduced in the version 3.2 deploy of the JBTiered721Delegate that included the useVotingUnits flag, making it possible to align a tier’s voting units to its price by default.

As a result of the bug, the current JBTiered721Delegate requires the trust of the project owner to serve as a safe and predictable token for onchain governance.

I recommend publishing a version 3.3 that fixes this, and I recommend JBM move to deploying new projects with a version 3.3. Here’s a candidate PR: https://github.com/jbx-protocol/juice-721-delegate/pull/139. There is no spec change needed from clients’ perspectives.

My thoughts:

I try as hard as I can to make sure each version of this JBTiered721Delegate contract that is deployed is the last of its kind, ensuring dependability for contracts and clients that choose to composes onto the schema. When imperfections are discovered, especially ones that increase the probability of mis-programmed treasury outcomes, I believe Juicebox ecosystem toolmakers and documenters should move quickly to continue offering the best contracts possible, while explaining the risks and guiding folks to more peace-of-mind. Times of lower protocol dependence should especially be taken advantage of towards these ends.

We’ve invested into building and exercising versioning systems that offer better contract versions to new and existing projects with highly mitigated risk. We know the tradeoffs of versioning depend greatly on the which piece of the spec is being evolved, and that improvements to Delegates are the least intrusive. We know we are striving for dependability and reducing systemic risks, while acknowledging that we are on a mission to make the most useful foundation for programmable projects to build treasuries upon, which sometimes takes influence from unforseen circumstances and new ideas.

It’d give me peace of mind if we had a framework in place for turning over a small proposed risk-oriented diff in a 72hr window. I assume none of us want to be spending ongoing time on things like this, we’d rather be building the projects which put stress on the foundation. The stress seems to be yielding fewer and fewer cracks. If we keep pace, one day soon the foundation may prove entirely dependable.