On NEAR

Pay for merged pull requests, not invoices

Put USDC in a pool for your repository and label the pull requests you'll pay for. On merge, GitHub signs a token and the contract checks it before paying the author.

Open the console Verify a payout yourself
How it works

How it works

What happens when a pull request merges.

  1. Fund a pool

    Send USDC to the contract for one repository. You set the most a single pull request can earn and the date the pool closes. Whatever is left after that date goes back to you.

  2. Merge with a pay label

    A workflow in your repository reads the label, asks GitHub for a signed token that names the pull request, its author and the amount, and sends it to the contract.

  3. The author is paid

    The contract checks GitHub's signature and pays the NEAR account the author linked. If they haven't linked one yet, the award waits for them.

Live from the contract

Running on NEAR today.

Read from the contract as this page loads.

Pull requests paid
–
 
Merge to payout
–
 
Signature check on-chain
–
of NEAR's 300 TGas per-call limit
Contributors paid
–
 

Open the console →Re-check the latest payout's signature →

Who it's for

One merge. Three people served.

The company paying

Pays for accepted work only.

  • Fund one pool per repository, once.
  • Every award is capped on-chain, whatever the label says.
  • Unspent funds go back to funders after the pool expires.
See the pools →

The contributor

Paid seconds after the merge.

  • No invoice to send and nothing to chase.
  • Link a NEAR account once, with a token GitHub signs for you.
  • If you haven't linked yet, your award waits for you.
Check your payout account →

The bookkeeper

A ledger they can reconcile alone.

  • One CSV row per payment, each with its transaction.
  • A statement for any month, with totals and a due date.
  • Amounts exactly as the contract recorded them.
Open the statement →

Trust model

What you trust, and what you don't.

You trust

  • GitHub's signing keys. The contract accepts only tokens signed by keys registered in it. A new key waits 48 hours, and funders can withdraw meanwhile.
  • The workflow file the pool pins. It turns labels into amounts; the cap limits what a wrong rate can cost.
  • Whoever can merge. A merge is the approval, exactly as it is today.

You don't trust

  • This website. It only reads the chain. You can verify every payout without it.
  • Whoever submits the transaction. Who is paid and how much are inside GitHub's signature, so they can't change either.
  • The submitting key. It can call award, link and pay on this contract, and nothing else.

Get started

Two ways in.

Pay contributors from your repository

  1. Fund a pool with the repository, the workflow, a cap per award and an expiry date.
  2. Copy award.yml into the repository and set the rate card as a variable.
  3. Label pull requests pay:small, pay:medium or pay:large and merge as usual.
Setup guide

Get paid for your pull requests

  1. Copy link.yml into any repository you own.
  2. Run it once with your NEAR account. GitHub signs that the account is yours.
  3. Every labelled pull request of yours that merges is paid to that account.
Check your account