Serverless functions with DockHive

DockHive, the agentic cloud from Hive Innovation Lab, uses Necter as the execution layer for its customers’ serverless functions. A customer writes a function in any HiveKit language, DockHive builds it to Hive Bytecode (.hbc), and every invocation comes back with a receipt that several independent machines agreed on.

The same pattern works for any platform that runs code on behalf of its own users. This page explains the design; the integration package is integrations/dockhive in the necter-sdk repository.

Two paths, one artifact

A function is an ordinary HiveKit module. DockHive deploys it once (POST /v1/modules, content-addressed) and can then run it two ways:

	Sync	Async
API	POST /v1/execute on the function’s own module address	POST /v1/projects/{id}/tasks on the DockHive Functions project
Who runs it	validators	a committee of 3 miners, audited by validators
Finality	SecureWeave quorum before the HTTP response	committee quorum, then validator finality
Latency	sub-second for small functions	one round (seconds to a minute)
Paid to	(network service)	miners, per compute unit, from the project vault
Use for	HTTP triggers, webhooks, API backends	queues, batch and fan-out jobs, scheduled work

Choose per call: the result is the same on both paths for the same input, because both run the same bytes under the same deterministic rules.

How the async path works

A mining project has exactly one worker module, and committee workers must be stateless, so they cannot call other modules. DockHive’s project worker is therefore a function host: each task carries the customer’s function (its manifest and code), the entry point and the input.

1. The host recomputes the function’s content address from the bytes it was given and rejects the task if it does not match the address named in the task. The receipt therefore binds which function ran.
2. It runs the function in a metered, memory-capped interpreter with the standard host functions (events, logs, crypto.hash, a request-scoped scratch storage, and the revision 3 ctx.* values for a task). Cross-module calls are not available, and nothing persists between invocations.
3. It returns {ok, output, error, events, logs, fuel_used}. A function that fails is still a finished task: the committee agrees on the failure and the work is paid, as a serverless platform bills a function that threw.

Miners earn per compute unit (1,000,000 gas, at least 1 per task). A typical small function costs 20 to 60 units on this path, against well under one unit when the same function runs directly on validators; the difference is the interpreter, and it is what miners are paid for.

Task inputs are public to their committee

Miners see what they compute. Send no secrets or personal data in function inputs. DockHive names its customers with a pseudonym (HMAC(secret, customer:project)) and keeps the mapping on its own side. Inputs must be canonical JSON: integers only, send decimals as strings.

Metering per customer

Every invocation is recorded with the DockHive customer, the customer’s project, the mode, the task or round id, the receipt hash, gas used and compute units. The integration aggregates them into usage records (function_invocations, function_compute_units) with one idempotency key per customer, metric and period, ready for DockHive’s billing service.

Using the integration

from dockhive_necter import HubClient, NecterFunctions

hub = HubClient("https://testnet-rpc.necter.network", api_key)   # developer API key, server-side only
fx = NecterFunctions(hub, project_id, "functions.db", tenant_secret)

f = fx.deploy(customer_id, "order-totals", hbc_bytes)             # new version if the code changed
r = fx.invoke(customer_id, "order-totals", "quote", cart)          # sync: finalized result + receipt
a = fx.invoke(customer_id, "order-totals", "quote", cart, mode="async", callback_url=hook)
fx.poll_pending()                                                  # advances async jobs, sends signed callbacks
fx.billing_records(period_start, period_end)                       # per-customer usage for billing

The API key needs the scopes modules:write (deploy functions) and tasks:submit (execute and tasks), and should be restricted to the platform’s project.

Run your own

1. Build the function host (integrations/dockhive/fn-host) and publish a project with it as the worker: task source api, a committee size, device classes and a per-unit reward (Project manifest, Register).
2. Create and fund the project vault (Vault).
3. Create a developer API key restricted to the project (Tasks).
4. Plug dockhive_necter (or the same three Hub calls) into your backend.

Submitting tasksThe task API, idempotency keys, waiting and status.

Committees and sortitionHow a committee is chosen and how it reaches quorum.