Supporting programs
Section 19 of 22
These features can attach to the core processes as funding and observed needs justify them. Each needs a budget owner and activation decision. They do not inherit automatic activation triggers from earlier rules.
| Feature | Proposed position and reason |
|---|---|
| Corpus purchases | Pay for accepted coverage, including benign controls and sanitized customer cases. Prioritize demonstrated coverage needs rather than a fixed case-count milestone. |
| Regression conversion work | Pay someone to turn another reporter's finding into a durable case when needed. Avoid paying the same recipient twice for the same promised work. |
| Targeted review assignments and contests | Use bounded commissions or prize budgets when they buy scrutiny the ordinary process lacks. Keep blanket per-assessment payments off the default path. |
| Review-fee refunds | Consider refunding an agreed submission charge for a qualifying report. The refund follows the published terms and preserves the distinction between service credit and money returned. |
| Larger bounties | Exposure-based or pre-release multipliers can attract useful testing. Fund them within the declared limits without spending reserves owed to customers. |
| Late-payment remedies | Preserve a defined consequence for missing a funded payment commitment. Set its amount and exceptions alongside recovery holds and dispute deadlines. |
| Customer re-review | Fund credits when a verifier defect invalidates a customer's credential. Epoche can separately price expedited work following customer misconduct. |
| Priority service and volume discounts | Keep these in product pricing. Capacity and measured service economics should justify them, with the resulting DAO share recorded. |
| Sponsor-designated budgets | Track funds intended for a domain. Separate treasuries can follow when shared accounting is insufficient. |
| Marketplace referral rewards | Consider rebates for integrations that produce useful paid adoption. Base them on verified activity and affordable service economics. |
| Citation credit and retrospective rewards | Credit accepted contributions and useful prior work under agreed terms. Do not divert an earned award after the fact merely because someone asserts influence. |
| Recurring AI attack testing | Budget ongoing search when it finds useful failures. Poor public-report quality can justify stronger intake controls without automatically closing the external reporting route. |
Keep automatic membership income and per-post rewards out of the operating model because creating accounts or text does not establish useful work. Imported account popularity should not directly grant authority. Credential-holder bonds, insurance promises, a share of buyer-to-agent payments, and prediction-market governance remain outside the DAO's maintenance responsibilities. They create separate obligations or decision systems that this maintenance process does not require. Future consideration would need an explicit case for adding them.
Administration and public claims
Choose the least administrative structure that supports the intended activity. Ask counsel about the actual proposed payment and governance arrangement, including the 1% buy/sell tax, EPOCHE service payments, contributor settlement, fee-funded token purchases and burning, and whether a designated payer or entity is needed. A contract executing transfers does not itself answer every question about responsibilities. Require an entity or document only when the activity calls for it.
Verify required payment eligibility, tax handling, and agreements before funded intake. Automate repeatable checks and protect private information. Keep the contribution license, report scope, payment promise, and recovery responsibilities understandable to participants. Detailed forms and storage layouts follow the verified requirements.
Use the DAO name to describe the intended organization while publishing who actually controls it at each stage. Describe credentials only in terms of the checks and policy they attest to. Changes to payment machinery do not expand the product's assurance or turn the pool into an insurance commitment.