Two ways to run a module

Once a module is deployed, Necter can run it in two ways. Choosing the right one is the most important design decision for anything you build.

	Validator rounds	Committee tasks (mining projects)
Endpoint	`POST /v1/execute`	`POST /v1/projects/{project_id}/tasks`, or a schedule run by the Hub
Who executes	Every validator (4 on the testnet), answer on a quorum of identical receipts	A committee of miners drawn by sortition (3–31 members + backups), finalized by validators with random audits
Module state	Yes: `storage.*` persists on the validators, kept in sync between them	No: the worker must be stateless (no `storage.*`, no `hive.call` imports)
Cross-module calls (`hive.call`)	Yes	No
Who is paid	Nobody per call	Miners per verified compute unit, plus the developer and treasury shares, from the project vault
What you need	A deployed module	A deployed stateless worker, a signed project manifest registered on-chain, a funded vault, operator listing review (testnet)
Auth	None (rate-limited per IP), or an API key	The developer’s API key (`tasks:submit`), or anyone if the project sets `public_tasks`
Gas cap	`gas_limit` up to 50,000,000 per call (default 1,000,000)	`max_gas_limit` from the project manifest (up to 10^10)
Typical use	Shared state: registries, ledgers, leaderboards, oracles that store prices, composing modules	Heavy or repeated pure computation: aggregation, validation, verification, scoring, simulations

Validator rounds

sequenceDiagram
  participant C as Your app
  participant H as Hub
  participant V as Validators (4)
  C->>H: POST /v1/execute {module, function, input, gas_limit}
  H->>V: same request to every validator (fresh round nonce)
  V-->>H: signed votes (receipt hash, state transition)
  H-->>C: output, events, receipt_hash once 3 of 4 agree

Each validator executes the call against its copy of the module’s state and signs a vote. The Hub answers as soon as floor(2n/3)+1 validators agree on one receipt hash. Calls that touch the same module’s state are ordered: no two rounds on a stateful module are ever in flight at once. Pure modules (no state imports) run in parallel. A call can have executed even if its response was lost, so never retry a state-changing call blindly; make your functions idempotent (for example with a request id, like the leaderboard does with match ids).

Committee tasks

sequenceDiagram
  participant D as Developer backend
  participant H as Hub
  participant M as Committee (miners)
  participant V as Validators
  D->>H: POST /v1/projects/{id}/tasks
  H->>M: offer (slot drawn by sortition) → accept → lease
  M-->>H: result + signed vote
  H->>V: bundle of votes + audit block
  V-->>H: finality votes (audit = contested or random 10 %)
  H-->>D: task finalized: output, receipt_hash

The Hub draws the committee for a slot (project, epoch, seq) from a validator-attested snapshot of bonded miners before the task’s input exists, so it cannot pick who runs a given input. Miners vote on the receipt hash; validators verify the votes, re-execute a random share of rounds and every contested one, and sign a finality record. If no committee can be formed (too few miners, no attested snapshot, or the vault is empty), the task runs as an ordinary validator round instead (validator fallback): you still get a result, but no miner earns units for it. Committees, Finality

Using both together

Many applications combine them: miners do the heavy, stateless verification (paid per task), and a small stateful module on the validators records the verified results. For example a telemetry project can verify signed sensor batches in committees and have your backend write accepted digests into a ledger module with /v1/execute. See DePIN & IoT telemetry.

Stateful mining projects (execution: "validators") are coming soon.