Author: gulan
Date: 2022-05-

Thesis

What’s the idea?

• To provide a clear default limit for ongoing recurring proposals that do not specify a cycle expiration
• To limit reserve rate allotments to 2 decimal places in accordance with the current UX configuration restrictions

Motivation

Why now? What problems does this solve?

• JBP-197 clearly limited the active recurring payout proposals to seven cycles, but did not address future proposals. The Juicebox community/governance implementer’s have relied on authors to specify the final cycle where the payouts will sunset, however sometimes this specification is still missed. In the cases where the proposal does not specify a sunset cycle, the bookkeeper, @gulan, has limited the payouts to 7 cycle in alignment to the ‘90 day’ informal expiration policy. This proposal seeks to codify the 7 cycle limit when authors do not specify a sunset clause.
• The Juicebox ’Reserved JBX’ list regularly changes and proposals have done a great job at specifying allotments. However, as it stands the Juicebox UX does not allow for more that 2 decimal places. In cases where this limitation has not match the proposal specification, the configurer @twodam has informally rounded the allotments. This proposal seeks to codify the rounding to two decimals where authors include 3 decimal places.

Specification

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

1. When proposal authors do not specify a sunset clause in a recurring payout proposal, the bookkeeper shall limit the number of payout cycle’s to a maximum of 7.
   1. This proposal shall not be used to limit the creativity of authors in anyway (e.g. authors can create payouts for shorter or longer than 7 cycle).
   2. This proposal shall only be used in case where the author does not mention a sunset clause.
2. When proposal authors specify a change to the ‘Reserved JBX’ list that includes three decimal places (e.g. 0.123’, the bookkeeper shall round down the third decimal to 0 and reallocate any remaining percentage to the juice-box multisig (dao.juicebox.eth).
3. This proposal should be reconsidered if necessary when:
   1. Bookkeeping Automatons (currently being worked on by @jigglyjams) flow has eliminated its need
   2. The UX & Contract team has allowed for more decimal places to be configured for the reserve list

Rationale

Why is this specification the best way to address this thesis?

The best method’s to avoid the above situations is to provide authors with feedback during the drafting stages. However, even with feedback, authors may not modify proposals to reflect required changes by the time proposal moves to snapshot and is locked. The above specification is a catch all for these situations.

The current grey area is awkward for the bookkeeper as no specific proposal requires the limitation but instead the bookkeeper relies on informing questioners of historical precedent.

Risks

The bookkeeper could use the authority of this proposal to falsely modify proposals to punish their enemies or reward their friends.