Standing pools for the
people you keep showing up for.

A standing pool for recurring generosity.

Not a campaign. Not a one-shot gift fund. Not a wish kind, either — Treasury is a standalone platform feature: a persistent pool that funds wishes of any kind (Item, Experience, Service, Fund, Donation) as life events arrive.

There’s a category of generosity that the consumer fundraising stack doesn’t serve: the recurring, predictable, long-tail flow of gifts a small group makes to the people inside it. A family that supports its members through baby showers, weddings, severance, illness, and milestones. A friend group that keeps showing up for each other’s birthdays. An alumni network that funds graduation gifts and emergency loans. An office that pulls together for a leaving present every six weeks. Each individual event is small enough that a one-shot campaign is overhead-heavy; the aggregate across a year is significant.

The pattern today is one of three: somebody-in-the-group is the bag-carrier and Venmo collects from the others (high friction, awkward asks, money sitting in someone’s personal account), or a one-shot fundraiser launches every time (campaign-fatigue, low-amount overhead), or nothing happens at all and the group just lets the moment pass. None of those are good.

A Treasury fixes the structural problem by inverting the cadence. Instead of asking each member each time, members commit to a deposit schedule once. The pool fills steadily on a cadence that’s low-friction to commit to (most pools land at $20–$50 per member per month). When a life event arrives — the baby is due, the wedding is six weeks out, a member loses their job — a founder proposes a deploy from the pool. Members vote. The pool funds the wish without anyone running a separate campaign.

The five-step mechanic.

Open, fund, propose, vote, deploy. Repeat as the year happens.

48 hours. Two yes-votes. Ties to no.

The quorum is calibrated for groups, not committees.

The 48-hour window is long enough that members in different time zones can participate, short enough that the proposal doesn’t stall. The two-vote minimum is the smallest quorum that still requires more than one consenting adult; below that the model collapses to a single-signer pool which we treat as the solo-treasury fast path. Ties default to no because the bias of the system should be toward inaction when the group is genuinely split. We considered other defaults and they all created perverse incentives.

Vote-tracking is real-time. Every member can see who has voted what, with a comment thread attached to the proposal for context. Once quorum clears, the deploy fires; remaining members can still see what was approved and post-facto comment. Veto-power is reserved for founders only and is logged publicly; founders rarely use it, and the few times they have, it’s been to catch a fraudulent proposal before the deploy clears.

Two roles. Clear contract.

Founders and members. Each role has a contract; neither has unilateral money power.

The contract is that no individual — not even a founder — can route money out of the Treasury to a personal account. The pool can only deploy onto named wishes, and named wishes can only resolve to merchant payouts, cause-fund payees, or named recipients with verified payment methods. The audit trail is end-to-end and is exportable on demand. Treasury balances are reconciliable with both Stripe and any member’s personal bank.

Per-occasion or named-wish-only.

Treasury founders can constrain deploys to specific occasion types or to a specific allowlist of wishes.

A family Treasury for baby showers, weddings, and severance funds doesn’t want the pool deploying to a member’s birthday concert ticket. A friend-group Treasury for birthdays doesn’t want it spent on a member’s rent. The deploy-type configuration is how founders enforce that intent at the system level rather than relying on social pressure.

Four shapes that actually work.

Treasuries we’ve seen the design hold up for.

A fast path for one.

Single-signer Treasuries are supported. The quorum logic skips and the cap structure stays.

A solo Treasury is one founder, no other members, recurring deposits routed from the founder’s own account. There’s no quorum (you’re voting with yourself) but the cap-per-occasion and cooldown machinery still apply. The use case is the founder who wants the structure of a Treasury — the pool, the deploy logging, the audit trail, the annual roll-forward — without the group dynamic. It’s a personal sinking-fund with a wishlist substrate underneath.

Solo Treasuries upgrade to multi-member at any time by simply inviting members. Existing balance carries forward; the founder retains founder rights; the new members vote on deploys from the next proposal forward. There’s no migration step.

iMessage, push, Stripe webhooks.

The plumbing that makes a Treasury feel like a group chat, not a bookkeeping app.

No incumbent has it.

A short tour of the adjacent shapes.

The closest adjacent shapes — Venmo group, Splitwise, GoFundMe, Honeyfund — were designed for different problems and don’t generalize to this one. Venmo and Splitwise handle one-off expense-splitting; GoFundMe handles one-shot fundraising campaigns; Honeyfund handles one-couple wedding registries. None of them are standing pools with quorum-based deploys onto a graph of life events.

Treasuries fold neatly into the rest of Gish: deploys onto product wishes, experience wishes (the honeymoon honeymoon shape is a natural fit), and cause campaigns. A family Treasury can fund a baby shower today, a sibling’s honeymoon next month, and an elder relative’s medical-payee outcome fund the month after — all from the same pool, all visible in the same audit trail.

How the pool actually moves.

A short tour of the plumbing under the social shape.

Funds collected via Treasury deposits sit in a Stripe-managed FBO (for benefit of) account, segregated by Treasury, with reconciliation reports available to every founder and member on demand. Gish does not commingle Treasury balances with corporate operating cash; the pool is structurally isolated from the platform’s own balance sheet. If Gish were to suspend operations tomorrow, the Treasury balances would be recoverable directly from the underlying processor; the platform sits on top of the substrate, not in front of it.

Each Treasury has a unique virtual ledger inside that account. Member deposits credit the ledger; approved deploys debit it; failed deposits reverse cleanly with notification; refunds (rare, only when a deploy reverses prior to settlement) credit back to the member who originated the contribution. The ledger reconciles to the Stripe balance daily and any discrepancy is escalated to engineering; we treat the reconciliation as a hard invariant.

Deploy mechanics depend on the deploy type. A product-wish deploy routes through the retailer’s standard checkout via the contribution rail. An experience-wish deploy issues a per-booking virtual card through Stripe Issuing with the same MCC allow-list and two-person rule that live experience-wishes use. A cause-fund deploy routes to a verified payee using the outcome-funds verification machinery. The Treasury layer doesn’t reinvent the payout primitive for each wish kind; it composes the existing Gish payout primitives over a quorum-gated pool.

For tax purposes, Treasury contributions are not tax-deductible by default — they’re member-to-member transfers within a pool. Deploys that route to a verified 501(c)(3) outcome fund are tax-deductible at the deploy-recipient level, and the receipt is attributed to the Treasury rather than to individual members. Founders can elect a member-level attribution model if the pool is structured to support it, but it adds complexity and is opt-in. Our default position is that Treasuries are social pools, not charitable vehicles, and the simple model is best.

What Treasuries don’t do.

A short list of the cases that don’t fit and the cases on the roadmap.

Treasuries are not an investment vehicle. The pool does not earn interest; it does not invest member contributions in any market instrument; it does not promise growth. The substrate is FBO cash, full stop. If a Treasury wants its pool to grow, members can deposit more; the platform does not provide a growth engine. This is a deliberate choice because the regulatory surface of providing yield on pooled member contributions is large and would raise the cost of operating a Treasury in ways that would be unrecognizable to a family group.

Treasuries are not currently available for cross-border pools where all members are not US-resident. International members can participate in a Treasury whose primary founder is US-based, but the deposit rail is limited to US-issued cards; we’re working on Wise integration for SEPA and bank-rail deposits but it isn’t live yet. The on-platform notifications and voting work globally; only the deposit rail is constrained.

Treasuries are not designed for high-frequency small-deploy use cases (think: every-time-you-go-to-dinner expense splitting). Splitwise and Venmo handle those cases well; Gish doesn’t try to. The cadence the Treasury model expects is several deploys per year, not several per week, and the quorum-vote overhead would feel heavy at higher frequencies. We’d rather be honest about the shape than overstretch.

The maximum Treasury size is currently 250 members. Larger pools work technically but the social dynamics of a quorum vote start to degrade past a few dozen voting participants; we may extend with delegated-vote machinery in future, but the immediate roadmap is to tune the existing experience for groups in the 5–100 member range, which covers the overwhelming majority of the use cases we’ve seen.