Crypto grants should pay for verified delivery

An omnichain grant should release funds against verified deliverables on each chain, with the evidence and approval rule agreed before work begins. That means separating proof that a transaction happened from proof that the funded work met its goal. A transfer or contract call can be checked on-chain; whether a product works as promised may need human review.

How do milestone payments work across chains?

A grant is divided into milestones, and each tranche is released only when its stated acceptance conditions are met. The agreement should name the deliverable, the evidence the recipient must provide, who reviews it and what happens if the review is disputed. For a software release, evidence might include a deployed contract address and transaction record, alongside documentation or a demonstration for checks that a transaction cannot establish.

Funds can sit in escrow until approval, or a program can send smaller tranches as milestones clear. Escrow gives the funder more control but can leave the recipient waiting; upfront payment shifts more delivery risk to the funder. A fuller comparison of the messaging, token and liquidity choices appears in this omnichain explainer.

What evidence should trigger a release?

Each milestone needs evidence that matches the work, rather than a generic “complete” status. A contract can verify a transaction, balance or code condition, but it cannot reliably judge usability, documentation quality or whether a feature serves its intended users. Those checks need a named reviewer or another agreed review process.

Write the release conditions so both sides can apply them without guessing. A useful grant schedule specifies:

• The deliverable and acceptance criteria for each milestone.
• The evidence required, such as a transaction hash, deployed address, report or demonstration.
• The reviewer, review window and process for requesting changes or disputing a decision.
• The tranche amount, recipient address, payment asset and release method.

Keep the on-chain rule narrow: it can hold funds and execute an approved release, while people assess work that requires judgment. If a third party attests to completion, the grant terms should say who appointed that party and how a challenged attestation is handled.

How should a grant handle delays and disputes?

A cross-chain message may arrive later than expected, so the payment logic should distinguish “pending” from “failed.” Releasing a second payment because the first message appears delayed can create a duplicate; the system should track a unique milestone and payment identifier before retrying. The agreement should also specify which chain and asset govern settlement, and how the recipient confirms the payment arrived.

Set a dispute window and a route to pause unreleased funds while a claim is reviewed. Transfers already completed may be difficult or impossible to reverse, so staged payments limit the amount exposed before acceptance. If the payment asset can change in market value, state whether the grant is measured in that asset or in a separate accounting unit.

For most programs, the workable design is a short milestone schedule, modest tranches and evidence that combines verifiable chain data with human review where needed. Before funding, both parties should be able to identify the exact condition that releases each tranche and the person who resolves a disagreement. The next payment then follows the accepted evidence or the stated dispute process.