Real-world apps: what to build on Necter
Most real apps are not “all on-chain”. They are an ordinary web or mobile app with a small, trusted core: the rules and records that several parties need to agree on and that nobody, including you, should be able to change quietly. That core is what you put on Necter. Everything else stays on normal hosting.
This page explains the split, lists what a module can and cannot do today, and walks through examples.
What runs on Necter and what runs off-chain
Section titled “What runs on Necter and what runs off-chain”A stateful module runs in NDSR (Necter Distributed State Runtime) on validators. Every call is executed by several validators, they must produce the same receipt, and SecureWeave consensus finalizes the result before any state change is kept. So the module’s state is a record that no single operator controls.
Put on Necter:
- Rules that decide who gets what: order status changes, escrow release, auction winners, transfer limits.
- Records that others will check later: balances of points, issued certificates, vote tallies, usage totals.
- Hashes of anything private or large, so it can be proven later without being published.
Keep off-chain:
- Anything that talks to the outside world: card payments, email, push, shipping and other web APIs.
- Anything fast or private: page rendering, search, chat delivery, personal data.
- Files and media.
The usual shape is a hybrid: a frontend, a thin backend on ordinary hosting (for example DockHive) that handles users, speed, privacy and outside services, and NDSR modules for the rules and records that must be trustworthy. Money and Solidity contracts belong on Necter EVM, which is planned and not live yet.
What a module can do today
Section titled “What a module can do today”- Host functions:
storage.get,storage.set,storage.del,crypto.hash(Keccak-256),hive.call(call another module),hive.emit(record events),console.logandabort. Host functions - Per-module key-value state: keys up to 256 bytes, values up to 64 KiB, at most 1 MiB written per execution. A failed call writes nothing.
- Deterministic logic in Rust, Go, TypeScript, JavaScript or Python, compiled to Hive Bytecode (.hbc).
- Composition: at most 8 distinct modules called per execution, so an app can be split into a few focused modules (inventory, orders, escrow) that call each other.
- Agreed writes: state changes are kept only after SecureWeave consensus across validators.
What it cannot do, by design
Section titled “What it cannot do, by design”| Limit | What it means for your app |
|---|---|
| No network I/O | A module cannot charge a card, send email or push, or call a webhook. Your backend does that and reports the result to the module. |
| No clock | A module does not know the time. Deadlines are passed in the input (for example a timestamp signed by your backend) or expressed as counters and phases. Execution revision 3 adds ctx.time(), agreed by validators within ±300 s. |
| No randomness | Draws and shuffles use a seed from the input or commit-reveal: each party commits a hash, then reveals the value, and the module combines them. |
| No built-in caller identity | POST /v1/execute needs no account, so a module cannot tell who called it. Apps verify users themselves, usually with a signature in the input. Only hashing is native, so a signature check is code inside the module and costs gas: about 9.6 M for secp256k1 recovery and about 2.5 M for ed25519 (measured here). A common pattern is for the module to accept only calls signed by your backend’s key, and for the backend to authenticate users. Execution revision 3 adds network-verified signed calls and ctx.caller(). |
| State is effectively public | Every validator holds a copy. Store hashes, ids and amounts, not names, addresses, messages or other personal data. |
| Writes wait for consensus | A state change takes seconds, not milliseconds. Show the user a pending state and confirm when the call finalizes. |
| No file or media storage | Store files on ordinary storage and put their hash in the module. |
A web page can call POST /v1/execute directly: the testnet RPC accepts it from any origin, without
cookies, limited per visitor IP. Keep secrets server-side: calls that need an API key, or that your modules
accept only when signed by your backend, go through your backend, as in the store below. With execution
revision 3, a browser can sign calls with the user’s wallet and the module sees the wallet as its caller:
Signed calls.
Call from a browser
Examples
Section titled “Examples”Each card lists the parts that go on Necter, the parts that stay off-chain, and who needs to trust the state.
Online store
On Necter: inventory counts, orders and their status, escrow records, refunds, loyalty points, seller reputation.
Off-chain: product pages and images, search, card payments, email, shipping APIs.
Why on Necter: buyers and sellers can both check that an order, refund or rating was recorded as agreed.
Marketplace
On Necter: listings, bids and auctions, settlement rules, dispute records, reviews tied to completed orders.
Off-chain: recommendations, buyer and seller chat, analytics.
Why on Necter: sellers trust the auction result and buyers trust that reviews come from real orders.
Chat app
On Necter: group membership, moderation logs, paid features, message hashes as proof of sending.
Off-chain: live delivery and message contents.
Why on Necter: members can check who was added or removed and that a message existed, without the operator rewriting history.
Ticketing
On Necter: ticket ownership, transfer rules (resale price cap, transfer count, cut-off before the event), check-in records.
Off-chain: seat maps, payments, QR rendering, door scanners, email delivery of tickets.
Why on Necter: organisers, fans and venues all see the same owner for each ticket, and anti-scalping rules apply to everyone.
Loyalty across merchants
On Necter: a shared points ledger, earn and redeem rules, each merchant’s issued and redeemed totals for settlement.
Off-chain: point-of-sale integration, customer accounts, marketing, the money settlement itself.
Why on Necter: merchants that do not trust each other settle from one ledger none of them controls.
Supply-chain provenance
On Necter: each handoff of a batch, signed by the party making it, plus hashes of certificates and inspection reports.
Off-chain: the documents and photos, ERP and warehouse systems, tracking devices.
Why on Necter: buyers and auditors can check the chain of custody without trusting any single supplier’s database.
Voting and polls
On Necter: the voter list (as a hash or Merkle root), one ballot per voter, phases, public tallies. Commit-reveal hides votes until the reveal phase.
Off-chain: voter sign-up and identity checks, the voting UI, results pages.
Why on Necter: voters and observers can recount the result from the recorded ballots. Ballots are not secret once revealed.
Games
On Necter: turn validation, match results, leaderboards, item ownership. Use commit-reveal or an agreed seed for dice and shuffles.
Off-chain: rendering, real-time movement, matchmaking, voice and chat.
Why on Necter: players trust that results and rankings follow the rules and were not edited by the game server. Worked example
SaaS usage metering
On Necter: usage totals per customer per billing period, the pricing rules, hashes of issued invoices.
Off-chain: collecting raw usage, the product itself, card billing, dashboards.
Why on Necter: customers can check that their bill matches recorded usage and published prices.
Escrow and freelance milestones
On Necter: the agreed milestones, delivery hashes, approvals, dispute records, the amount due at each step.
Off-chain: holding and paying out the money (a payment provider today, Necter EVM later), files, messaging.
Why on Necter: client and freelancer both rely on a record of what was agreed and approved that neither can change.
Certificates and credentials
On Necter: a registry of approved issuers, certificate hashes, revocations.
Off-chain: the certificate documents, holder details, the issuing portal.
Why on Necter: employers and schools can check a certificate against the issuer’s record without calling the issuer. Related example
DAO treasuries planned
On Necter EVM: the treasury, proposals, votes and payouts as Solidity contracts.
Off-chain: discussion forums, proposal drafts, notifications.
Why on Necter: members need funds to move only when a vote passes. This needs Necter EVM, which is planned and not live.
Worked architecture: an online store
Section titled “Worked architecture: an online store”The store’s website and backend run on ordinary hosting such as DockHive. Three NDSR modules hold the trusted
core: inventory, orders and escrow. The backend signs each call so the modules accept writes only from it,
and it handles card payments, email and shipping itself.
flowchart TD
B[Browser] -- "browse, checkout" --> D[Backend on DockHive]
D -- "card payment, email, shipping" --> X[Outside services]
D -- "signed call: place_order" --> O[orders module]
subgraph NDSR["NDSR modules on validators"]
O -- hive.call --> I[inventory module]
O -- hive.call --> E[escrow module]
end
NDSR -- events --> N[Indexer]
N -- "order_placed, stock_changed, escrow_released" --> D
- The buyer checks out in the browser. The backend takes the card payment through its payment provider.
- The backend calls
orders.place_orderwith the order id, items and amount, signed with its key. Theordersmodule checks the signature, callsinventoryto reserve stock andescrowto record the amount as held. If any step fails, nothing is written. - Validators agree on the result through SecureWeave. The call returns events such as
order_placed. - An indexer collects events from the modules and feeds them to the backend, which updates its database, emails the buyer and books shipping. Today the indexer is your own process; with execution revision 3 the backend can subscribe to the Hub’s event API instead.
- On delivery the backend calls
orders.mark_delivered;escrowrecords the release, and the backend pays the seller through its payment provider. A refund follows the same path in reverse.
Anyone can later check an order’s history against the modules’ state and receipts, while product pages, card numbers and addresses never leave your own systems. Use an order id in every state-changing call so a retry cannot apply it twice.