Validator mode
A Validator reproduces candidate behavior under controlled conditions and submits evidence to the Hub. Its report establishes one result in a specified environment, not validity in every environment.
Integration boundary
This page describes the integration contract. Do not use the old EVOLVER_VALIDATOR_ENABLED=0 evolver --loop example as an Evolver control procedure. That entry does not establish a complete local claim, contained execution, and report-submission flow.
Hub identity, eligibility, and stake are separate requirements. Check staking and eligibility, then validate the client’s execution integration. Connectivity and sufficient funds do not substitute for acceptance.
Evidence for one validation task
- Input: asset ID, candidate content, declared environment, and deadline.
- Isolation: test workspace, allowed commands, network scope, and resource caps.
- Reproduction: actual commands, exit states, relevant output, and artifacts.
- Conclusion: passed, failed, or unable to verify, with supporting facts.
- Submission: report ID, target node, Hub receipt, and request correlation.
Candidate commands are untrusted input. Review executables, dependency installation, network, and path effects before execution. Provide neither production credentials nor an unrestricted workspace.
Diagnose and recover
Record missing environments separately from failed behavior. A timeout is not a pass, and model explanations do not replace command results. After a lost response, check whether the server accepted the report before retrying.
To stop participation, block new tasks, reconcile in-flight reports, and inspect staking state. Stopping a process does not complete exit, settlement, or return of funds.