What can you build?
Necter is a good fit when you need a result that many independent machines agree on, that anyone can re-check later, and that is paid for per verified run. Everything a module needs must be in its input or its own state: no clock, no network, no randomness. That rules out some things (calling web APIs from a module) and makes others easy (verifying signed data, deterministic scoring, reproducible batch jobs).
Worked examples
Section titled “Worked examples”Each one has the problem, why Necter fits, an architecture sketch, complete code that was built and run on
ndsr for these docs, how to publish it, how an app consumes the result, and costs.
Ideas by difficulty
Section titled “Ideas by difficulty”Content fingerprinting
Hash documents or media manifests and publish the agreed digest as a timestamp-free proof of content.
Deterministic price feeds
Median and outlier rejection over reports your backend collects; store the latest value for dapps.
Game referees
Resolve matches from moves and a seed so no player or server can fake the outcome.
Leaderboards and achievements
Replay-proof score submission, per-player bests and top-N tables with events for every change.
Rule engines and eligibility checks
Apply published rules (age, region, limits) to signed attributes and return only a verdict and a hash.
Signed-data verification
Check EIP-191 or ed25519 signatures on records, receipts or device data before anyone acts on them.
IoT and sensor validation
Reject replays, tampered and physically impossible readings; pay miners per verified batch.
Reproducible data pipelines
Transform, validate and aggregate datasets in chunks; publish the digest of the result for audits.
Seeded simulations
Monte Carlo or agent simulations driven by a scheduled task’s seed; anyone can replay a run.
Composable registries
Small stateful modules (names, ledgers, escrows of points) that call each other with hive.call.
Scoring and ranking
Credit-style or reputation scores computed from submitted, signed evidence with a published model.
Proof checking
Verify Merkle proofs, hash chains or succinct proofs submitted by users before accepting their claims.
Picking the execution mode
Section titled “Picking the execution mode”| You need | Use |
|---|---|
| Shared, persistent state (balances, tables, latest values) | A stateful module called with /v1/execute on validators |
| Heavy, repeated pure computation that independent miners should run and be paid for | A mining project with a stateless worker |
| Both | Committees verify; your backend writes the verified result into a stateful module |