The problem Cookie Jar 🍪 solves

A petty cash drawer, also known as a till or kitty 🐈 is a small cash fund utilized by traditional businesses to pay for minor expenses.

A Cookie Jar is an onchain petty cash jar that allows whitelisted individuals in a high trust environment to take "cookies" for any expenses they might have occured.

Any organization or group (or even one person!) can fund a Cookie Jar as an experiment to see how it will be utilized by a whitelisted group, setting up an interesting new capital allocation mechanism that's only possible onchain.

This can be used by any organization - nimble high trust orgs, sub-DAOs, working groups, departments - in a variety of interesting ways! In the base case scenario, small expenditures no longer have to go through an onerous process of requesting a reimbursement - you simply take an amount and leave a note as to why. Having to bypass any complex proposal processes makes everyone in a trusted environment happier and more efficient!

A second order effect is that tasks that might seem burdensome due to the proposal process not being worth the effort can now be incentivized more easily with rewards being easily claimed as cookies! And Cookie Jars can be bootstrapped for other novel experimental purposes - we're excited to see how orgs will use them.

The Cookie Jar is a simple mechanism that helps strengthen teams - we want to trust each other to do things, and make sure the incentives are worthwhile. And who doesn't love a yummy cookie?

Just don't be a greedy cookie monster, because nobody likes that.

🍪🍪🍪

Challenges we ran into

Technical challenges we face included scope creep, building our own indexer, and contract architecture. As an example the list of types of groups we wanted to support kept increasing. Additionally, we considered refactoring to a modular (multi-contract) architecture from an inheritance architecture. Instead of creating ZodiacHatsCookieJar by inheriting from HatsAllowlist and ZodiacCookieJar, each cookie jar could be comprised of a core cookie jar contract plus an allowlist module contract and a giver module contract. The factory summongCookieJar function would then take 3 addresses instead of 1, ie (address _core, address _allowlist, address _giver) instead of (address _singleton). While we believe this could be a valuable improvement we determined that launching CookieJar, and gaining user feedback could would provide valuable feedback to use for the next iteration.