Small surface.Clear trust.
Follow the exact path from a verified GitHub claim to native Rialo payout or deadline refund.
Execution flow
A sponsor publishes an open workflow PDA. The contributor authenticates with GitHub, the server matches the numeric user ID to the exact public PR author, and the contributor signs a separate claim PDA. The sponsor page discovers confirmed claims from onchain workflow history. Its review exposes the identity, payout wallet, exact terms, claim PDA, and source transaction; multiple matches require an explicit choice. The app re-fetches the public PR and compares its stable author ID again before approval, preparation, and funding lock the exact RLO escrow.
Funding arms a native Rialo heartbeat. It rechecks the deadline, polls GitHub through REX, and completes payout or refund without another sponsor click. The workflow page keeps reading the decoded account while settlement is active and announces the confirmed terminal state without requiring a manual refresh.
01 PublishSponsorcreate_bountyCommit the public PR, exact RLO amount, deadline, and open beneficiary state.
02 AuthorizeContributor + sponsorverify_identityrequest_claimaccept_claimRecord the payout wallet, review every onchain proof, recheck the live GitHub author ID, and lock one sponsor-approved claim.
03 Lock escrowSponsorprepare_fundingfundStabilize workflow storage, transfer the exact bounty, and arm settlement.
04 SettleRialo runtimenative_heartbeatPR MERGEDpaid = trueDEADLINErefunded = true
Account roles
- Sponsor
- Publishes the terms, selects and reviews the exact contributor claim, approves its payout wallet, funds escrow, and retains immediate check and refund fallbacks.
- Contributor claim PDA
- Records the contributor wallet, canonical GitHub login, numeric user ID, and the sponsor-owned bounty it targets.
- Workflow PDA
- Persists immutable bounty terms, approved beneficiary, escrow amount, timers, and terminal flags.
- Rialo runtime
- Re-arms the native heartbeat, queries GitHub through REX, and delivers validator reports to the callback.
- Beneficiary
- Receives only the committed escrow after a unanimous merged proof and exact account match.
GitHub signal
MergePay locks the PR head SHA and target branch before funding. The custom REX WASM verifier then reads bounded public GitHub responses and evaluates the selected merge, CI, and review conditions inside validator-attested execution.
GET /pulls/{number}
GET /commits/{headSha}/status
GET /commits/{headSha}/check-runs
GET /pulls/{number}/reviewsSettlement & limits
The native heartbeat owns both terminal paths. A unanimous merged proof pays the contributor; reaching the immutable deadline first refunds the sponsor. Terminal flags and exact-amount accounting prevent a second release when a manual fallback races an automatic callback. Each terminal workflow exposes a shareable receipt containing the exact amount, destination, reserve, and decoded success flag.
GitHub OAuth verifies contributor identity when the claim is created. MergePay then issues a five-minute, one-time authorization bound to the OAuth session, numeric GitHub ID, receiving wallet, exact PR, and derived claim account. A session, wallet, or target change requires fresh verification. Sponsor review re-fetches the public PR and compares the stable numeric author ID again, failing closed if GitHub is unavailable or disagrees. These OAuth checks are application gates; the onchain program independently enforces sponsor authority, account ownership, exact terms, and the beneficiary lock. Public merge settlement uses fixed non-secret headers and requires no GitHub App installation token or private key.
MergePay remains an unaudited DevNet MVP. It trusts the tested Rialo runtime, REX validators, and GitHub's public REST responses. Its current product boundary is intentionally narrow:
- DevNet and test RLO only
- Public GitHub repositories only
- One PR and beneficiary per workflow
- Native RLO escrow only
- Workflow rent remains after settlement
- Embedded wallet is reviewer-only
- Live sponsor-side author review is enforced by the web app, not a new REX assertion in the approval instruction