Cookie Jar
Cookie Jars let a garden's community hand out small, capped allowances without a proposal for every withdrawal. Where vaults hold an endowment, a jar holds spending money; it's the difference between a treasury and a kitchen tin everyone trusts each other to dip into.
The jars use Greenpill Dev Guild's Cookie Jar fork,
derived from Cookie-Jar DAO's v3 contracts. When a
garden is minted, the mint asks the Green Goods Cookie Jar module to deploy one jar per supported
asset through CookieJarFactory. That call is best-effort: with no module configured it
is skipped, and a failing factory call is caught so the garden still mints. A garden can therefore
exist with no jars, so read them from the module (getGardenJars) and handle an empty list rather
than assuming an address per asset. Only people wearing the garden's gardener hat can
claim: the module configures each jar with an empty allowlist and ERC-1155 gating on that hat, so
the jar checks the hat directly. Each asset also has its own per-claim limit.
Two kinds of jar
The same Cookie Jar contracts back two separate surfaces, and they do not share a data path:
- Garden jars are the ones this page describes: created by the module at mint, owned by the garden, gated by the gardener hat, claimed from the installed app's wallet, and funded from the admin Hub or a garden's public funding card. Apps read them straight from the module.
- Campaign jars are seasonal jars deployed through the factory directly, with an allowlist of claimants. The apps show only the ones whose creator the deployment registry trusts (its owner and its allowlist). The indexer follows the factory, and the public Cookies page and the admin Cookies workspace read those indexed records. Nothing about a campaign jar's allowlist applies to a garden jar.
How it flows
Garden jars are created with the garden when the module call lands, filled by funders and routed yield, and emptied a little at a time by the people doing the work.
A jar pays out only what it booked through deposit, whether for a claim or for its owner's
emergency withdrawal. Tokens sent to it by plain transfer can never leave, so always fund a jar
through deposit. The yield resolver does the same. When a jar refuses the deposit,
because it is paused or the amount is below its minimum, that portion goes to the garden's treasury
instead.
Where it lives in the code
| Layer | Source |
|---|---|
| Module | packages/contracts/src/modules/CookieJar.sol |
| Factory interface | packages/contracts/src/interfaces/ICookieJarFactory.sol |
| Mint-time call | packages/contracts/src/tokens/Garden.sol, through notifyCookieJar in packages/contracts/src/lib/GardenHooks.sol, which skips a missing module and catches a failed call |
| Garden jar reads | packages/shared/src/hooks/cookie-jar/useGardenCookieJars.ts, useAccessibleCookieJars.ts, and useUserCookieJars.ts, which call CookieJarModule.getGardenJars |
| Garden jar writes | useCookieJarDeposit.ts, useCookieJarWithdraw.ts, and useCookieJarAdmin.ts in the same folder |
| Campaign jar reads | packages/shared/src/modules/data/campaign-cookie-jars.ts (indexed CampaignCookieJar records from trusted creators) with useCampaignCookieJar.ts and useCampaignCookieJarCampaigns.ts |
The jars themselves come from that fork. The module above is the Green Goods side that creates and configures a garden's jars; campaign jars never pass through it.
Checked-in deployment projection
| Network | Status | Recorded components |
|---|---|---|
Sepolia Testnet (11155111) | Deployed | cookieJarFactory, cookieJarModule |
Arbitrum One (42161) | Deployed | cookieJarFactory, cookieJarModule |
Networks without recorded components are omitted; per-network state lives in the deployment status projection.
Indexer boundary
Configured indexer contracts: CookieJarFactory.
A deployment artifact does not by itself prove product activation, live indexing, or partner-service health. This projection regenerates from checked-in artifacts via node scripts/docs/generate.mjs.
Working with it locally
The fork mode (bun run dev -- fork) runs a local fork of
Arbitrum One with the factory and module present, so jar creation and claim flows run locally
without real funds.
Implementation and upstream sources
- Greenpill Dev Guild Cookie Jar is the implementation used by Green Goods.
- Cookie-Jar DAO v3 is that fork's upstream.
- ERC-1155, the multi-token standard behind a jar's membership gating.
Next steps
- Hats Protocol explains the gardener hat that decides who can claim.
- Octant covers the vault's endowment, the long-term money next to a jar's spending money.
CookieJar.solshows how the module sets up a garden's jars.- The public Cookies page shows campaign jars in the product.