Recurring payments, reduced to a primitive.
A trickle pays a fixed token amount to a recipient once per period — hourly, daily, or weekly. Fund its treasury and it pays until empty; refill it and it resumes. Missed periods are forgiven, never owed. One immutable contract. No fees, no token, no admin.
how it works
-
1 Create.
Pick a token, a recipient, an amount, and a period — say 5 USDC a day. You own the trickle; the recipient just receives.
-
2 Fund.
Deposit into the trickle's treasury — a week's worth or a year's worth, whenever you like. Anyone can top up any trickle: grandma included.
-
3 It trickles.
Each period, one payout of exactly the set amount. Anyone can trigger it — the recipient, you, or a keeper bot — and the contract self-limits to one payout per period, so no trust in the caller is needed.
Want it fully hands-off? Point a cron job, Gelato, or Chainlink Automation at
distribute() — the keeper key only ever needs gas and can never touch the funds.
why trickle
Fixed, not flowing.
A whole, fixed amount once per period — not a per-second stream. The recipient gets a payment they can point to, not a balance that creeps.
Forgiveness built in.
If the treasury runs dry or a period is skipped, nothing accrues. No debt, no back-pay, no growing liability — refill and it simply resumes from today.
Nothing to trust.
No protocol admin, no fees, no token, not upgradeable. One contract, deployed once, that nobody — including its author — can change or profit from.
Anyone can push the button.
distribute() is permissionless and self-limiting to one payout per period.
Recipients can claim themselves; a shared keeper can serve every trickle on the chain.
You stay in control.
Pause, change the amount, recipient, or period, or withdraw the remaining treasury at any time. Ownership transfers in two steps, so it can't be fat-fingered away.
an allowance, not a stream
Money streaming protocols are great at what they do: continuous, per-second flows for payroll and vesting, where elapsed time is money owed. Trickle is for the other kind of recurring payment — the kind meant to arrive as a discrete amount, on a schedule, with no debt when it doesn't. If your recipient should be owed for every second that passes, use a streaming protocol. If they should receive a fixed amount each period — and a missed period should just be missed — that's a trickle.
| Trickle | money streaming | fintech allowance apps | |
|---|---|---|---|
| payout shape | fixed amount, once per period | continuous, per-second | fixed, scheduled |
| missed periods | forgiven — never owed | accrue as debt | varies |
| fees | none | protocol fees on some | monthly subscription |
| protocol token | none | often | n/a |
| custody | your wallet, your keys | your wallet | the company holds the money |
| who triggers payouts | anyone (self-limiting) | recipient withdraws | the company |
| can the operator change the rules | no — immutable, no admin | some are upgradeable | yes, terms of service |
Categories, not call-outs — streaming and custodial apps are the right tool for plenty of jobs. This table is about which shape of recurring payment you want.
what people trickle
A kid's allowance 💧
The original trickle: 5 USDC a day from a dad to his kid. Fund a month at a time; missed days are just forgiven.
Stipends & grants
Fixed weekly amount to a contributor or grantee. If the program pauses, nothing accrues behind your back.
Patronage
Support a creator with a real recurring amount instead of a promise. They claim it themselves — no platform in between.
Trickle-vesting
The bluntest vesting schedule there is: a fixed amount per period until the treasury is empty.
Team stipends
One trickle per teammate for gas money or per-diems. One keeper cron pays everyone.
Family support
Anyone can fund any trickle, so grandparents can top up the same allowance the parents created.
trust through minimalism
The whole protocol is one small contract. Everything it doesn't have is the point.
Immutable & unowned.
Not upgradeable, no admin keys, no protocol pause switch. What you read is what runs, forever.
Strict isolation.
Every trickle's balance is accounted internally; one trickle can never spend another's funds.
sum(balances) == token.balanceOf(contract) is enforced by fuzz tests.
Permissionless by design.
Payouts are self-limiting — the contract, not the caller, decides what's due. A keeper key only needs gas; it can't redirect a cent.
Open source.
MIT-licensed, plain Solidity, small enough to read over coffee. Source going public with the mainnet deployment.
Trickle is thoroughly tested, including fuzzed invariants, but it has not had a third-party audit. It's a minimal contract — read it yourself before trusting it with meaningful amounts.
faq
What happens when the treasury runs empty?
Payouts stop. Nothing accrues, nothing is owed. Refill and payouts resume from the current period — every missed period is forgiven, permanently.
Who triggers the payouts?
Anyone. The recipient can claim in the app, you can send manually, or a keeper (a cron job,
Gelato, or Chainlink Automation calling distribute()) does it on a schedule.
The contract self-limits to one payout per period no matter who calls.
Is it automatic?
The contract enforces the schedule; something still has to send the transaction. A tiny keeper script — included in the repo — checks what's due and pays it in one batch. Its key only ever needs gas.
What tokens can I use?
Any standard ERC-20 — USDC is typical. Fee-on-transfer tokens are handled correctly (deposits credit what actually arrives); rebasing tokens are unsupported by design.
What chains does it run on?
Trickle targets low-fee L2s — Arbitrum One and Optimism — where a daily payout costs next to nothing.
Is there a fee? A token?
No and no. Trickle takes nothing, mints nothing, sells nothing. You pay only L2 gas.
Can I cancel or change a trickle?
Yes — you own it. Pause and unpause it, change the amount, recipient, or period, or withdraw the entire remaining treasury at any time. The protocol has no admin, but every trickle has an owner: you.