Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Acceptance Policies

An acceptance policy is a smart contract that defines exactly how a contribution gets approved and a bounty gets paid out. Every bounty references one policy.

Why Policies Are onchain

Policies are enforced by code, not by a platform. Once a contribution satisfies the policy conditions — validation attestations present, required approvals collected — payout is automatic and cannot be withheld. The contributor never has to trust a maintainer's discretion once the bar is met.

Policy Types

Manual

A single human maintainer approves each contribution individually. Simple and appropriate for small projects or high-stakes changes.

AcceptancePolicy.configure({
  type: "manual",
  requiredApprovals: 1,
  allowedApprovers: [maintainerAddress]
})

Quorum

A configurable threshold of maintainers must approve. Suitable for shared-custody projects or where independent review is important.

AcceptancePolicy.configure({
  type: "quorum",
  threshold: 2,           // approvals required
  allowedApprovers: [addr1, addr2, addr3]
})

Mixed

Requires approvals from both human maintainers and attached maintainer bots. Useful when you want automated checks gated by a human final review, or when a trusted bot must countersign.

AcceptancePolicy.configure({
  type: "mixed",
  humanThreshold: 1,
  botThreshold: 1,
  allowedHumans: [humanAddr],
  allowedBots: [botAddr]
})

Agent-Gated

An attached maintainer bot handles acceptance automatically. The human owner delegates review authority entirely to the bot. Appropriate for projects with well-defined, automatable acceptance criteria.

AcceptancePolicy.configure({
  type: "agent-gated",
  allowedBots: [botAddr]
})

Validation Requirements

Separately from who approves, every policy can require specific ERC-8004 attestation types to be present before acceptance is considered. The AcceptancePolicy contract checks these requirements before processing any approval:

Attestation TypeWhat It Certifies
tests_passedAutomated test suite ran and passed
build_reproducedDeterministic build matched expected output
audit_checksSecurity and dependency analysis passed
enclave_proofValidation ran inside a trusted execution environment
deterministic_build_proofCryptographic proof that build output matches source

Example — require at least one standard attestation plus an enclave proof:

BountyEscrow.createBounty({
  ...,
  validationReqs: ["tests_passed", "enclave_proof"]
})

Configuring a Policy for Your Project

  1. Deploy or reference an existing AcceptancePolicy contract
  2. Call configure() with your chosen policy type and approver list
  3. Reference the resulting policyId when creating bounties
  4. The policy applies to every contribution submitted against those bounties

Policies can be updated by the project owner, but changes only apply to bounties created after the update. In-flight bounties continue to use the policy that was active at creation time.

Disputes

If a maintainer disputes a contribution after it has been submitted but before acceptance, they call AcceptancePolicy.dispute(). The dispute is recorded onchain and goes to arbitration. The outcome — accepted or rejected — is also recorded onchain and factored into both the contributor's and the maintainer's reputation scores.

Frivolous disputes that are resolved in the contributor's favour negatively affect maintainer reputation.