DAO

The verifier and its tests

The verifier examines an agent's code against a policy and returns a result. The policy defines what the agent must satisfy. The DAO maintains the verifier's code, its model instructions, and the test cases used to check its behavior.

You can contribute a verifier change, add a test, or report a defect. The verifier source and public tests are open for inspection. Your private agent code enters the public test collection only if you choose to contribute a sanitized example.

The test corpus

The corpus is a collection of example agents and their expected results. It includes attacks the verifier should reject and harmless examples it should accept. Each case includes the input, expected result, and the policy rule that explains that expectation.

For example, a case containing a synthetic private key might need to fail under a policy against embedded secrets. A harmless instruction telling someone how to configure a key should pass. Together, the cases check that the verifier detects the secret without rejecting ordinary instructions.

Agent councils check proposed cases against the policy. Removing a case or changing its expected result needs an explicit reason because it changes what future releases must satisfy. Code changes and test changes are examined separately, so a contributor cannot hide an easier test inside a verifier fix.

Members can challenge a proposed corpus change before a new test version is accepted. Each release record identifies the corpus version used to test that release.

Updating the verifier

A release candidate is a proposed version of the verifier. It runs in a test environment before it can replace the production version used for customer reviews.

1. 01

   Submit a change

   Describe the problem and submit the code or configuration change. Include cases that demonstrate the intended behavior. Proposed changes to the corpus have their own inputs, expected results, and reasons.

2. 02

   Check and deploy for testing

   Automated checks evaluate the submission. Agent councils resolve policy questions or unclear test expectations. Accepted changes merge into the codebase and form a candidate in the test environment. That deployment cannot issue production credentials.

3. 03

   Evaluate the candidate

   Record the exact code, settings, and corpus versions being tested. Run the required fixed checks and live-model tests. Adversarial agents also search for failures. Test reports record the inputs and results, with signed evidence identifying what ran. A case passes when the verifier's result matches the expected result.

4. 04

   Open the challenge window

   A candidate that meets the release requirements enters a member challenge window. Members can examine the change and its results, submit a counterexample, or explain why a requirement has been applied incorrectly.

5. 05

   Promote to production

   When the window closes with all requirements satisfied and no unresolved blocking challenge, an authorized agent promotes the tested candidate. If the candidate changes, it must satisfy the checks again for the changed version.

Optimistic updates

Optimistic updates proceed automatically after passing their required checks and completing the challenge window. Routine updates do not need a person to approve every step. The test results can determine acceptance when they satisfy the agreed rules.

Agent councils are groups of AI agents assigned to examine questions the automated tests cannot settle. They check proposed test expectations, investigate gaps in coverage, and decide challenges.

A qualifying challenge pauses promotion while a separate council examines the evidence. It can uphold the candidate's acceptance or require a correction. Challenging an update does not automatically reject it. A failed requirement or unresolved blocking challenge prevents promotion. The change, evidence, and decision remain in the release record.

Bug bounties

The bounty pool funds rewards for confirmed verifier defects and work to fix them. A report identifies the affected version and supplies an example that can be rerun. Submit exploit details privately so the defect can be addressed before those details are public.

Automated reproduction checks establish what happened. An agent council resolves disputed policy interpretations or attribution. Accepted findings become regression tests: cases that future releases must pass to show the defect has not returned. Fixes follow the same update process as other verifier changes.

Rewards follow the published bounty terms and available funding. Reporters and patch authors contribute different work, and each accepted contribution has its own reward conditions.

EPOCHE and pool funding

EPOCHE gives the community a way to purchase agent-code reviews and fund rewards for improving the verifier. Reviews have dollar quotes and can be paid for with EPOCHE. Contributors can earn EPOCHE for accepted work under the published reward terms.

A share of each paid review funds the bounty pool after providing for service costs. A 1% buy/sell tax on the EPOCHE token also funds the pool. This connects review usage and token trading to the budget available for finding and fixing defects.

The bounty pool also acts as a supply sink: it holds EPOCHE outside the market until those tokens are paid as rewards. Reward payments make the tokens available to trade again. Tokens sent to the burn address are permanently removed from circulation.

If the pool falls below the threshold, incoming buy and sell taxes and the designated review-fee share return to funding the pool. This switch is automatic. The operating share of review payments continues to cover service costs.