Github Bounty

The GitHub Bounty is the entry point of zkPull’s protocol.

It allows project owners to create on-chain bounties directly linked to GitHub repositories and issues, while ensuring contributors can claim rewards without relying on manual approval or trust in the owner.

Each bounty represents a verifiable contract: if the contribution is valid and merged, the reward is enforceable.


How a GitHub Bounty Is Created

When creating a bounty, a project owner defines:

  • Issue Title Clear description of the problem to be solved.

  • GitHub Repository Link Public repository where the issue and pull request will live.

  • Issue Description Scope, acceptance criteria, and expectations for contributors.

  • Reward Amount (mUSD) Funds are escrowed on-chain at creation time.

  • Deadline Defines the time window for valid contributions.

  • Maximum Claims Limits how many contributors can successfully claim the bounty.

Once created:

  • Funds are locked in a smart contract

  • The bounty becomes publicly discoverable

  • Rules cannot be arbitrarily changed after posting


On-Chain Escrow & Fund Safety

zkPull uses non-custodial escrow for all bounties.

Key properties:

  • zkPull never holds user funds

  • Rewards are locked at bounty creation

  • Payouts are governed entirely by smart contract logic

This guarantees:

  • Contributors are protected from withheld rewards

  • Project owners pay only for validated results

  • Platform operators cannot interfere with payouts


Contributor Workflow

From a contributor’s perspective:

  1. Browse available GitHub bounties

  2. Select an issue aligned with their expertise

  3. Submit a pull request on GitHub

  4. Wait for the repository owner to merge the PR

  5. Submit the PR URL to zkPull for verification

At no point does the contributor need:

  • Off-chain agreements

  • Manual confirmation

  • Direct communication for payout approval


Claim Conditions & Rules

A bounty can only be claimed if all conditions are satisfied:

  • Pull request is merged into the target repository

  • PR is linked to the correct issue

  • GitHub username matches the contributor

  • Claim is submitted before the deadline

  • Claim limit has not been exceeded

These conditions are objectively verified, not subject to human judgment.


Why GitHub Bounty Is Non-Trivial

Traditional bounty platforms rely on:

  • Manual verification

  • Centralized decision-making

  • Trust in platform operators or project owners

zkPull’s GitHub Bounty is different because:

  • GitHub data is verified cryptographically (via zkTLS)

  • Enforcement is decentralized (via AVS)

  • Rewards are permissionless and automatic

This transforms GitHub issues into trust-minimized economic primitives.


Example Scenario

  • Project owner posts a 10,000 mUSD bounty

  • Funds are escrowed on-chain

  • Contributor submits a PR and it gets merged

  • Contributor submits PR URL

  • zkPull validates the contribution

  • Reward becomes instantly claimable

No approvals. No delays. No disputes.

Last updated