GitHub bounty escrow · NEAR testnet
Code ships.
Payment follows.
PATCHPAY locks NEAR in an on-chain escrow and releases it only when a Trusted Execution Environment verifies that the right pull request was actually merged. No chasing invoices. No “the check is in the mail.”
On-chain escrow
Funds locked by contract
TEE-verified merges
Intel TDX attestation
One-time payout
No double-spend, ever
Live board
The marketplace, straight from the chain
How it works
Three steps. Zero trust required.
01
Lock the bounty in escrow
The creator deposits NEAR into the on-chain escrow contract with the reward, the repository, the target branch, and the deadline. Funds are locked by code — not by promises.
02
Ship the pull request
A developer does the work and opens a PR. The PR body carries one claim line — Claim: <their-near-account> — declaring which NEAR account should receive the payout. That line is plain text, not proof: the contract and the verifier independently check that the claim exactly equals the account that submitted the PR, and payout always goes to the submitter's own transaction — never to an address read from PR text.
03
The merge triggers payment
OutLayer's TEE workers verify the actual merge against the bounty's conditions and produce an Intel TDX attestation. The contract validates the result and releases the reward through its payout state machine — to the submitter, and only the submitter. Live on NEAR testnet today; the full TEE-to-contract callback loop is proven in tests, with async callbacks a known testnet limitation.
Verification
Inside the TEE: what gets checked
When a developer submits a PR, the escrow contract calls outlayer.testnet with the verifier WASM pinned by SHA256. A worker runs the verifier inside Intel TDX, fetches the PR from the GitHub API, and checks every condition. The result comes back with an attestation binding the exact code, input, and output. The verifier is live on OutLayer's testnet workers today — the full asynchronous TEE-to-contract callback is proven in tests, and is a known testnet limitation we document openly.
The contract then independently re-checks the binding — bounty ID, per-submission nonce, eligibility — before any NEAR moves. The worker can never move funds itself.
Inspect a proof in the public proof center →- 01Exact repository — owner and name
- 02Target branch — base.ref must match
- 03Merged == true — server-side GitHub fact
- 04Expected author — when the bounty names one
- 05Claim line — PR body contains Claim: <submitter>
- 06Merge timestamp — within the bounty deadline
Payout flow
Paid means confirmed.
01
VerificationPassed
The verifier said yes. Payout is queued — the bounty is NOT marked paid yet.
02
PayoutPending
The reward transfer is in flight, awaiting the transfer-result callback.
03
PayoutSucceeded
The transfer landed. This is the only state that means “paid”.
04
PayoutFailed
The transfer failed. Funds stay locked in escrow; anyone can retry. Never silently lost.
The contract never marks a bounty paid before the transfer callback confirms the funds landed. If a transfer fails, the bounty enters PayoutFailed — funds stay locked in escrow and the transfer is retried with a bounded attempt budget. No silent loss, no stuck-forever.
Questions
Asked, answered.
Always the NEAR account that called submit_pr. The payout receiver is never taken from PR body text — the body claim must exactly equal the submitter, or verification fails. Front-running a PR number cannot redirect funds.
Put the next merge on the ledger.
Create a bounty in minutes. Your NEAR stays locked until the merge is proven — then the developer is paid through a payout state machine that only marks “paid” after the transfer lands.