How payouts work
A bounty advances on its own. You and your contributors do ordinary GitHub and wallet actions — label, assign, connect a wallet, merge — and the platform’s background workers handle every on-chain step, retrying transient failures automatically. Nobody presses a “release” button.
The lifecycle
Deploy and fund the escrow
Each repository gets its own escrow contract on Stellar. You deploy it once, then fund it with USDC. Every bounty in the repo draws from this shared balance.
Create a bounty
Label an issue rewarded plus a tier (low/medium/high) or manual. The bot reserves the reward amount from the escrow balance and comments to confirm. The amount is still editable at this point.
Assign a contributor
Assign someone on GitHub. The bot links them a page to connect a Stellar wallet. If no wallet is connected yet, the bounty parks and waits — no error, no timeout.
Lock the milestone
Once the contributor connects a wallet, a worker pushes the milestone to the escrow contract. The reward amount is now locked on-chain against that wallet.
Merge the PR
The contributor opens a PR whose body links the issue (Closes #123). When you merge it, GitHub fires an event and the automation re-checks every rule.
Release automatically
If the live rules pass — PR merged, issue closed, milestone on-chain, receiver matches the contributor’s wallet, not already paid — the escrow releases the USDC to the contributor. Typically within seconds.
What “trustless” actually means here
The platform never holds your keys. You sign the deploy and fund transactions in your own wallet; the contributor signs their wallet connection. The escrow contract — not a company — decides when funds release, based on on-chain state.
The rules that protect the money
Every release re-reads GitHub and the escrow contract before acting. A job queued minutes ago never acts on stale state. Specifically:
- The chain is read first. If the milestone already shows released, the only thing the system will do is fix its own database. It will never pay twice.
- Receiver must match. If the contributor changed wallets after the milestone was pushed, the stale milestone is re-pushed to the new wallet before any payout. A wallet change can’t wedge a bounty.
- Amount must match. If the on-chain amount doesn’t equal the recorded reward, the payout is blocked and logged — not force-paid.
- Author must match. The merged PR’s author must be the assigned contributor, verified live against GitHub, not just a recorded webhook.
When things park instead of failing
- Contributor hasn’t connected a wallet yet → the bounty parks and resumes the moment they connect.
- Trustless Work or GitHub returns a timeout or 5xx → the job retries with backoff until it succeeds.
- Issue closed before the milestone was pushed → the worker pushes it, then re-evaluates and releases.
This is why @trustless-oss retry is almost never needed. It only asks the state machine to run now against the same rules — it can’t force a payout the automation would otherwise refuse.
Next: Glossary · Set up your wallet