nexus operates a bug-bounty and feature-bounty program on a platform that handles credentials, money movement, data classification, and tamper-evident audit. This document is the human process that vets contributors, enforces expert oversight, and prevents unvetted or AI-generated submissions from auto-claiming bounties. Every public bounty uses this ratified process, which has been dry-run end to end (record below).

• Anyone may submit to open-tier tasks after signing the contributor agreement (Developer Certificate of Origin sign-off, see CONTRIBUTING) and agreeing to the Code of Conduct.
• Any contributor touching sensitive paths or receiving a payout completes an intake step with identity verification proportionate to risk (real identity and payout-eligibility screening where legally required).
• We keep a contributor record: handle, verified identity tier, demonstrated areas of competence, claim history, and payout history.

Tier	Who	Examples
Open	Anyone who signed the agreement	Documentation, fixtures, low-risk tasks
Vetted	Passed intake; ideally landed one open-tier change	SDKs, integrations, compatibility work
Expert / invite-only	Pre-vetted, demonstrated domain expertise, co-designed with a maintainer	Money movement, auth, audit cryptography, policy, classification, hosted infrastructure

Each bounty declares its tier and a named maintainer owner so claimants know the bar before they begin. Directional payout bands map to tiers: smaller documentation and governance tasks are typically open/vetted; high-value work that moves money, changes authorization, or touches audit cryptography is expert/invite-only and stays in managed disclosure scope.

• Every bounty has a named maintainer owner accountable for acceptance, mapped to the CODEOWNERS sensitive-path rules in .gitlab/CODEOWNERS.
• Sensitive-path submissions require the security reviewer plus the domain expert — never CI alone. Passes CI is necessary but never sufficient.
• High-band bounties use a design-first flow: the contributor agrees a short specification and threat-model note with the owner before implementation.

• Claim lifecycle: claim/assignment → scope agreement → work → review → payout. Unassigned speculative Merge Requests against a high-tier bounty are closed, not reviewed.
• Mandatory AI-use disclosure: every Merge Request discloses whether and how AI tools were used (enforced by the Merge Request template). Undisclosed bulk generation is grounds for rejection and loss of standing.
• Demonstrated understanding: vetted and expert tiers require a human-authored design rationale; the owner may require a synchronous walkthrough for higher bands. A contributor who cannot explain their own change does not get it merged.
• Concurrency / rate limits: per-contributor concurrent-claim and submission rate limits prevent flooding.
• Required evidence: deterministic tests, current-state docs, a threat-model note when a trust boundary moves, and a compatibility/rollback note. Submissions missing these are returned, not merged.

• Payout is tied to acceptance criteria being met, with the owner’s sign-off recorded.
• Conflict-of-interest rules: a maintainer who is also a claimant on a bounty may not be its accepting owner.
• A dispute/appeal path exists, plus policy for partial work, duplicate claims, and abandoned claims.
• A standing/reputation system lets trusted contributors graduate tiers; slop submitters lose access.

Before opening any public bounty, the process was dry-run end to end on a simulated open-tier documentation bounty:

1. Claim: a test contributor signed the agreement (DCO sign-off) and claimed the mock bounty; the claim was assigned and scope agreed in the issue.
2. Work: the contributor opened a Merge Request using the Merge Request template, including the AI-use disclosure and demonstrated-understanding checklist, deterministic doc-lint evidence, and a rollback note.
3. Review: CODEOWNERS routed the Merge Request to the area owner; the reviewer confirmed the change and that CI passing alone was not treated as acceptance.
4. Sign-off: the owner recorded acceptance against the stated criteria.
5. Payout: the payout step was exercised against the recorded sign-off, and the contributor record (claim + payout history) was updated.

Outcome: the lifecycle, concurrency limits, AI-disclosure enforcement, and owner sign-off all functioned. Findings: none blocking. Expert-tier claims use the design-first specification and threat-model note before implementation.

• A managed bounty platform may be used as an intake and payout system, but this policy remains the source of truth for claim assignment, review, and payout sign-off.
• Automated AI-generation detection is not a primary control. Human expert review and demonstrated understanding are the gate.