Milestones & governance

Upgrade timing: development and production

Development-guard upgrades require two reviewer attestations and have no waiting period after those approvals. Development mode has no automatic expiry. Production upgrades require a six-hour holder challenge; an escalated challenge opens a 72-hour vote. Six-hour voting maturity is a separate production rule.

The active replacement Devnet factory was deployed directly under the immediate development guard. It does not need the old factory’s 48-hour migration. That retired factory and its pending proposals remain unchanged as historical accounts. Production still requires its separate six-hour challenge guard.

Adoption, milestone, reimbursement and sponsor-refund periods are separate custody rules. They do not change when the loader upgrade authority moves.

Agree the work

The repo owner proposes a reward, submission deadline and immutable milestone document containing objective, acceptanceCriteria, ossImpact and evidenceRequired. Publish it at a GitHub blob URL pinned to a full commit. The onchain SHA-256 must match its exact text.

The governance agent assesses feasibility, measurable acceptance criteria, budget and benefit to the repository’s OSS field. Reject malice, fraud, unrelated work, duplicate compensation and hidden related-party recipients. Missing evidence requires abstention. Plan approval locks budget but never authorizes payment.

Review completion

Workers submit a hash of their published evidence record before the deadline. The agent independently checks every criterion and the exact contributor identity. Completion approval has its own two-day challenge window. Anyone can then execute the authorized payout to its fixed recipient. The repo owner does not have an additional payout veto.

Failed work fuels the community

An agent-approved reopening keeps the reward and criteria, increments the work revision, removes any old award, and makes the work a community bounty. A fresh 21-day submission period begins after two-day notice. Former submissions cannot authorize the new revision. The last failed award recipient cannot immediately reclaim the reopened work.

The developer and factory authority cannot receive community rewards. Developer commitments converted into community work remain protected; cancelling cannot move that budget back to discretionary developer spending.

Quorum and operator control

Custody requires a Squads v4 2-of-3 vault. The founder has confirmed ownership of all current reviewer wallets. The threshold enforces multiple keys, not independent operators. Membership, threshold and the existing custody timelock are checked onchain. Upgrades use a separate guard. Founder-controlled governance can coordinate approvals; do not treat it as independent review.

The agent has no keys. It evaluates evidence and prepares unsigned actions. A member proposes the exact reviewed instruction; configured reviewers approve it. Quorum execution waits at least two days, and milestone/adoption approvals then enter their own two-day challenge window. Governance actions expire within seven days; stale revisions and replayed claims fail.

Two reviewers may still collude or approve bad evidence. Squads does not prove the quality of work. The official devnet Squads deployment is upgradeable by its operator; the immutable mainnet binary is used in local integration tests. Pilot upgrade authority should belong to the quorum vault; irreversible revocation follows audit and stabilization.