Milestones that verify themselves

A funder escrows USDC against one milestone of a GitHub repository. The contributor is paid when a merged pull request passes the hard facts, checked in an Intel TDX enclave, and two AI reviewers from different vendors certify how much of the milestone it completes. The contract pays the lower of the two shares. No AI verdict moves money on its own.

The judge buys its second opinion from the verifier and passes it on. The verifier signs its verdict with a key that only exists inside its enclave, and the contract checks that signature itself.

1. Fund. The funder pins the repo by its numeric GitHub id, the contributor's GitHub id, the CI checks, a deadline, and the exact wasm hash of every enclave program, then sends the budget plus the review fee.
2. Bind. The contributor posts a public gist naming a NEAR account. An enclave checks the gist belongs to the milestone's GitHub id; from then on money can only go there.
3. Claim. The checker reads GitHub inside TDX: merged, right repo and branch, right author, checks passed, nothing under .github/, the complete file list, an independent approval.
4. Review. The judge (GLM) and the verifier (Qwen) each report what share of the milestone is done. Their models' signatures are checked in the enclave; the verifier's verdict is signed again, by its own key.
5. Pay. The lower share is paid. More than 30 points apart, any objection, or no new progress: the money waits for the funder. After the deadline, the funder takes back what was never certified.

Every claim in the README comes with a command. scripts/verify-execution.py <tx> checks any review's TDX attestation off-chain, down to Intel's signature.