Skip to content

What is Necter?

Necter is a network for verifiable computation. You write a small program (a module) with a HiveKit SDK; HiveKit compiles it to Hive Bytecode (.hbc) and NDSR executes it deterministically. Necter runs it on machines you don’t own: validator servers and, for mining projects, committees of miners on phones, laptops, desktops and servers. Every execution produces a receipt whose hash is identical on every honest machine, so results can be compared, agreed on and audited instead of trusted.

Piece What it is
NDSR (Necter Distributed State Runtime) The node runtime: a sandboxed, gas-metered engine that executes Hive Bytecode deterministically and signs a receipt for every call. Validators run it as a server; the miner apps embed it. More
HiveKit SDKs for Rust, Go, TypeScript (AssemblyScript), JavaScript/TypeScript (embedded engine) and Python. Each ships a hivec CLI that builds a .hbc artifact. Install
Modules (.hbc) Hive Bytecode: compiled code plus a manifest, addressed by its Keccak-256 content hash (manifest_address). Format
Projects A worker module plus a signed project manifest (economics, committee size, requirements, store listing), registered on-chain and funded through a vault. Projects are what miners mine. Deploy
Hub The public API at https://testnet-rpc.necter.network: modules, projects, tasks, committees, accounts, explorer, faucet, and the WebSocket relay miners connect to. API
Miners The Necter Miner app or CLI. It keeps a device key, connects outbound to the relay, executes tasks it is offered and signs votes. Mine
Validators Always-on NDSR nodes that finalize rounds with SecureWeave, NDSR’s consensus layer, randomly re-execute (audit) committee work, attest reward receipts and keep module state. Validators
Contracts NECTA token + faucet, ProjectRegistry, ProjectVault (per project) and Staking on Ethereum Sepolia. Testnet
flowchart LR
  D[Developer] -- submits task / schedule --> H[Hub]
  H -- offer + lease --> M1[Miner 1]
  H -- offer + lease --> M2[Miner 2]
  H -- offer + lease --> M3[Miner 3]
  M1 & M2 & M3 -- signed votes --> H
  H -- bundle --> V[Validators<br/>SecureWeave]
  V -- SecureWeave finality votes, random audit --> H
  V -- SecureWeave-attested epoch receipt --> H
  H -- settleEpoch --> PV[(Project vault)]
  PV -- Merkle claims --> M1 & M2 & M3
  1. A project’s tasks come from its API (your backend submits them) or from a schedule the Hub runs.
  2. For each task the Hub draws a committee of miners by stake- and reputation-weighted sortition from a validator-attested snapshot. Nobody, the Hub included, can choose who runs a given input.
  3. Each member executes the task in NDSR and signs a vote naming the receipt hash.
  4. Validators check the votes and finalize through SecureWeave, NDSR’s BFT consensus layer. They re-execute a random share of rounds (and every contested one), and sign a finality record listing the miners who were right.
  5. At the end of each epoch validators attest a reward receipt; the Hub settles it on the project’s vault, and miners claim their share with Merkle proofs. Wrong or double votes can be slashed.
  • Deterministic by construction. No clocks, randomness, filesystem or network inside a module; floats are NaN-canonicalized; gas is metered identically on NDSR’s native engine and on the portable engine used by 32-bit phones. The same call gives the same receipt everywhere. Details
  • Verified, not trusted. Results carry signatures and hashes; committees are recomputable from public data; finality needs a validator quorum; payouts need an attested receipt.
  • Anyone can run it. Miners need no inbound port and no Sepolia ETH (bonding, claims and payout changes are gasless). A phone is a valid committee member.
  • Developers set the economics. Each project picks its reward token, reward per unit or per epoch, daily emission, fee split, collateral and committee size, and funds its own vault.