How Mergit verifies work
and releases money.

01The problem, stated precisely

Retroactive funding works. Verifying it doesn't scale.

Optimism's Retro Funding allocated over 100M OP to builders and proved the thesis: paying for impact after it happens beats paying for promises. But every round runs on human badgeholders reading submissions. Gitcoin distributes tens of millions and still fights sybils with identity heuristics. Both are slow because the same step is manual — someone has to decide whether the work is real.

That step is not actually subjective for most developer work. A merged pull request, a green CI run, a verified contract whose bytecode matches the merged commit — these are checkable facts. They were left to humans because reading a diff and judging whether it satisfies a spec required a human. That constraint no longer holds.

The cost of leaving it manual is concrete for a young chain: a developer who ships today gets paid next quarter, if ever. Ecosystems compete for builders, and payment latency is a recruiting metric.

02System architecture

Four components. Only one of them holds money, and it is the simplest one on purpose.

Why the split matters

The agent is the complicated, fallible, upgradeable part. The contract is the simple, immutable part. Keeping intelligence off-chain and custody on-chain means a bug in the agent can misjudge a bounty, and at worst misdirect that one bounty's payout, but cannot drain the escrow, touch other bounties, or alter an amount. That boundary is the whole security argument.

03The verification pipeline

Verification runs as a funnel: cheap deterministic checks reject most work before any model is invoked, and model judgement is confined to the one question that genuinely needs it.

Each stage emits a signal; the aggregate produces a confidence score. Only a run that clears every deterministic gate and exceeds the confidence threshold reaches settle(). Everything below the threshold is escalated to the funder rather than auto-rejected — a false negative costs a review, a false positive costs money, so the asymmetry is deliberate.

What gets recorded

The agent hashes the full evidence bundle and passes it to the contract, so any payout can be audited after the fact against what the agent claimed to have seen.

// evidence preimage — stored off-chain, hash recorded on-chain
repo:odiseo159-beep/celo-sentinel|task:giwa-escrow-demo|verifier:mergit-agent-v0

// emitted by MergitEscrow.settle()
BountySettled(bountyId, developer, verifier, paidToDeveloper, protocolFee, evidenceHash)

04Contract design

MergitEscrow is deployed and source-verified on GIWA Sepolia at 0xffcf20…5879. It is intentionally small: a bounty is a five-field struct and there are three state transitions.

         postBounty()              settle()
   ∅ ──────────────────▶ Open ─────────────────▶ Settled
        (locks ETH)        │      only verifier,
                           │      before deadline
                           │ refund()
                           └─────────────────▶ Refunded
                                  only funder,
                                  after deadline

Invariants the code enforces

• No owner, no pause, no upgradeability. There is no admin function. Nobody — including the author — can move funds held for someone else.
• The verifier's power is bounded to one choice. It selects the recipient. It cannot change the amount, settle twice, settle after the deadline, or touch a bounty it was not assigned. The contract does not stop it from naming an address it controls: that choice is the trust the next phase removes.
• The fee is immutable, set in the constructor and hard-capped at 5% (MAX_FEE_BPS) in code, so it cannot be raised on existing escrows.
• Funds are always claimable. Every bounty terminates in either a payout or a refund; there is no path where ETH is stranded.
• Reentrancy: checks-effects-interactions ordering plus a guard on both value-moving functions; status is written before any external call.

14 tests cover the permission matrix, double-settlement, deadline boundaries, fee arithmetic, isolation between concurrent bounties, and the invariant that the contract retains no dust after settlement.

05Trust model — and how it shrinks

The honest position: today the verifier is trusted to judge correctly.

It is not trusted with custody, amounts, or timing — the contract removes those. But a funder posting a bounty is trusting that the agent will not name the wrong developer. Claiming otherwise would be dishonest, so here is the actual reduction path.

06Stack and execution

Delivery plan

Economics

A percentage fee is taken only when a bounty actually settles — no settlement, no fee, so funders risk nothing on bounties nobody fills. Revenue therefore tracks work funded, not speculation. Later phases add fees on retroactive funding pools distributed through the agent, and verified-work history becomes a reputation primitive other protocols can consume.

07Verify these claims yourself