• Stake 1 JBX for x months to receive y veJBX.
• Holders allocate their veJBX to projects. Tokens can be reallocated by their hodlers to new projects once every z week(s).

Bonus:

• veJBX is allocated by holders to projects on a particular 'category', and a holder can allocate their veJBX to projects on any number of categories.

i.e. a front-end ranking system can read from a project's veJBX allocation in the rankings category, but holders can also allocate their veJBX simultaneously to any other project in the fundraise-rankings category, jbx-fee category, or any other category namespace that anyone publically designates for whatever reason. - Bonus bonus: Changes to the z lock duration for each category can be made by the ENS owner of the category.

i.e. if I own jbx.eth I can allow veJBX holders to who allocated to a project within the `jbx` category to reallocate only every `z` week(s).

Pros:

• Simple. Amorphous. Open ended.
• Entities in Web3 can compose with veJBX rankings to do as they wish.
  • Front-ends can offer to sort by veJBX rankings, or the quadratic of veJBX rankings, or whatever.
  • Other contracts can compose with the veJBX contract to create special features for projects who've been allocated veJBX.
  • JuiceboxDAO may later wish to deploy a payment terminal core contract that uses veJBX allocation to increase JBX allocation from fees paid to projects with proportionally more veJBX (perhaps on the quadratic).
  • JuiceboxDAO may later wish to make it super simple for projects to direct payouts and reserved token to those who are giving it veJBX.
• Separate from core contracts.
• Creates a network effect by locking up JBX.
• veJBX holders could still have weight in JuiceboxDAO governance despite also having allocated to projects across any number of categories.
• All other projects on Juicebox could use the same system for its ve tokens.

Cons:

• No direct mechanical utility for veJBX at the onset.
• veJBX has zero value initially, so the proposition to lock JBX for veJBX probably seems silly at first.
• No direct solution for project fees.
  • We can build this later as noted above, although it'll take future dev work and convincing projects to migrate to the fork. We can also build this now if we're convinced but it might put off V2 a little bit.
  • Fees may actually be less of a concern in V2, where projects can withdraw funds from juicebox and later add them back in without paying fees. This allows groups who withdraw funds for bid on something to then later make all funds redeemable by token holders in case the campaign is unsuccessful.