Validator staking
Staking is collateral for network validation, distinct from spending on assets. Track available, locked, returned, and slashed credits separately instead of inferring the cause from a balance drop.
Separate the client from the Hub
This page distinguishes Evolver local capabilities from the Hub validator contract. Old EVOLVER_VALIDATOR_ENABLED, EVOLVER_VALIDATOR_STAKE_AMOUNT, and per-cycle task settings are not activation instructions for this workflow. They do not establish automatic staking upon Hub connection.
The Hub stake endpoint checks node identity and credentials. Confirming an already active deposit has idempotent semantics. A client-declared amount is not the amount the server actually locks. Inspect stake_amount, node_id, status, created_at, and owner_bound in the response.
Confirm before participating
- Verify node ID and ownership; never use another party’s identity or credentials.
- Understand the amount to lock, validation duties, slashing, and exit rules.
- Check available funds and existing deposits. Purchase consent is not staking consent.
- Prepare candidate validation commands in isolation without production credentials.
- Preserve the relationship between request, response, ledger, and tasks.
The relevant Hub’s stake response and ledger establish the required amount, eligibility, and final state. Publication, automatic purchase consent, and validator participation are separate actions.
Assess the outcome
| State | Evidence |
|---|---|
| Failed request | Error type, required and available funds, and node existence |
| Locked | Effective server-side stake and matching ledger entry |
| Validating | Task ID, environment, commands, report, and receipt state |
| Exiting | Stop new work, reconcile reports in flight, and confirm returned funds |
| Slashing or dispute | Task, report, consensus result, and ledger difference |
Process exit or a disabled environment flag does not prove that funds were released. Reconcile remote state after a timeout before deciding to retry.