Overview

HZB Network connects application demand with professional delivery through Web3 models, developer tools, HIVM controlled execution and a global builder network.

The product layer includes Web3 LLM, Data Mesh, APIs/SDKs, contract assistance and enterprise knowledge. The network layer includes TaskSpec, Proof of Build, Builder Graph and Venture Cell.

Products and protocols progress through research, prototype validation, pilots and release. Capability pages describe their development scope.

01 · Prerequisites & scope

Use Node.js 20+ and two terminal windows. The example listens on 127.0.0.1 and returns fixed data. It performs no model inference, contract analysis or transactions. Do not submit sensitive data.

02 · Save the example files

Save the server and one client in the same local directory. No npm packages are required; the Python example uses the standard library.

03 · Start and call

node hzb-demo-server.mjs

node hzb-client.mjs
# Or, with Python 3.9+:
python hzb-client.py

curl http://127.0.0.1:8787/v1/tasks \
  -H "Authorization: Bearer local-demo-key" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: first-read-only-task" \
  --data-binary @task-request.json

In Windows PowerShell, use curl.exe and put the command on one line. Stop the server with Ctrl+C when finished.

04 · Read the response

{
  "demo": true,
  "task_id": "demo_<generated-id>",
  "status": "fixture_complete",
  "policy": {
    "decision": "permit_read_only",
    "external_writes": false
  },
  "execution_performed": false,
  "output": {
    "kind": "static_fixture"
  },
  "receipt": {
    "steps": [
      "validate_input",
      "check_read_only_policy",
      "return_fixture"
    ],
    "source_verified": false
  }
}

demo=true and execution_performed=false identify the demo boundary. fixture_complete means a fixed response was returned, not that inference, an audit or an external task completed.

05 · Next steps

Platform layers

This reference architecture organizes HZB product responsibilities; it is not a deployed production topology. Models generate candidates while separate components handle authorization, tool execution and reconciliation.

1. 01Application / client
2. 02Identity & scope
3. 03Models + Data Mesh
4. 04HIVM Policy Gate
5. 05Controlled adapters
6. 06Output & receipts

Responsibilities & handoffs

Code structure: the delivered demo

examples/
  hzb-demo-server.mjs   HTTP routes → validation → read-only policy → fixture receipt
  hzb-client.mjs        Node.js fetch client + timeout + error handling
  hzb-client.py         Python standard-library client
  task-request.json    Local HTTP request sample
  hivm-plan.json       Conceptual instruction plan (not executable)
  README.md            Scope and run instructions

The demo implements input validation, a read-only policy gate and a fixed receipt. Real models, retrieval, tool execution, durable queues and production authentication are out of scope.

Application overview

Evidence-led Q&A for protocol researchers, DApp teams and communities. HZB Web3 LLM is designed to bind answers to networks, contract versions and observation times so conclusions can be reviewed.

Features & capabilities

Technical value & HZB differentiation

Data Mesh supplies permission-scoped context, specialist models propose explanations, and separate checks inspect citations. The proposed differentiator is delivery of the state supporting an answer, with HZB-Bench evaluating attribution, freshness and appropriate abstention.

Architecture & data flow

1. 01Question & scope
2. 02Data Mesh retrieval
3. 03Model routing
4. 04Citation checks
5. 05Evidence-led answer
6. 06Feedback & evaluation

Integration design example

This JSON is a conceptual task contract for discussing fields and permissions. It is neither a live endpoint schema nor a request accepted by the local demo server. Use the linked local quickstart for runnable code.

{
  "application": "web3-llm",
  "question": "Explain the upgrade permissions of the supplied contract.",
  "context": {
    "chain_id": 1,
    "block_ref": "<observed-block>",
    "source_ids": [
      "<authorized-document>"
    ]
  },
  "output": [
    "answer",
    "citations",
    "unresolved_items"
  ]
}

Technical roadmap

Progress is organized around prototyping, validation and integration, with advancement determined by acceptance results. These phases are not completed milestones or fixed launch dates.

Further reading & integration

Application-category reference; HZB architecture and roadmap follow this proposed design: ChainGPT official products

Application overview

An assisted review workbench for Solidity developers and security teams. It is designed to combine automated checks, model explanations and review evidence into a single findings queue, supporting rather than replacing professional audits.

Features & capabilities

Technical value & HZB differentiation

HZB-Solidity and HZB-Risk are intended to combine located rule findings, semantic explanations and reproduction checks. HIVM would constrain tool permissions while receipts bind source hashes, compiler versions and check configurations for repeatable review.

Architecture & data flow

1. 01Source & scope
2. 02Parse & rule checks
3. 03Model-assisted analysis
4. 04Isolated validation
5. 05Human triage
6. 06Report & regression

Integration design example

This JSON is a conceptual task contract for discussing fields and permissions. It is neither a live endpoint schema nor a request accepted by the local demo server. Use the linked local quickstart for runnable code.

{
  "application": "contract-auditor",
  "artifact": {
    "source_hash": "<sha256>",
    "compiler": "<pinned-version>"
  },
  "checks": [
    "access-control",
    "reentrancy",
    "upgradeability"
  ],
  "policy": {
    "external_writes": false
  },
  "output": [
    "findings",
    "evidence",
    "review_status"
  ]
}

Technical roadmap

Progress is organized around prototyping, validation and integration, with advancement determined by acceptance results. These phases are not completed milestones or fixed launch dates.

Further reading & integration

Application-category reference; HZB architecture and roadmap follow this proposed design: ChainGPT official products

Application overview

Turn natural-language requirements into inspectable specifications, candidate contracts and test plans. Designed for DApp prototypes, permission modules and standardized interfaces, with constraints confirmed before generation.

Features & capabilities

Technical value & HZB differentiation

HZB proposes using TaskSpec to align code, tests and review with the same acceptance criteria. HIVM GENERATE would not grant EXECUTE permission. Combined with the auditor, this supports development artifacts with validation records rather than unreviewed generated text.

Architecture & data flow

1. 01Clarify intent
2. 02TaskSpec
3. 03Templates & generation
4. 04Compile & test
5. 05Independent review
6. 06Authorized deployment

Integration design example

This JSON is a conceptual task contract for discussing fields and permissions. It is neither a live endpoint schema nor a request accepted by the local demo server. Use the linked local quickstart for runnable code.

{
  "application": "contract-generator",
  "spec": {
    "kind": "role-based-registry",
    "roles": [
      "admin",
      "editor"
    ],
    "upgradeable": false
  },
  "deliverables": [
    "spec",
    "source",
    "tests"
  ],
  "policy": {
    "deploy": false,
    "human_review_required": true
  }
}

Technical roadmap

Progress is organized around prototyping, validation and integration, with advancement determined by acceptance results. These phases are not completed milestones or fixed launch dates.

Further reading & integration

Application-category reference; HZB architecture and roadmap follow this proposed design: ChainGPT official products

Application overview

A planned creative workbench for the HZB green character and community ideas, spanning briefs, collectible artwork, traits and metadata. Creation, moderation and on-chain minting are separate stages so creators can review before publishing.

Features & capabilities

Technical value & HZB differentiation

The HZB design connects brand creation to traceable delivery through input permissions, model versions, asset hashes and review records. HHA can supply campaign briefs and builders can submit work for task-based PoB review. Owning an NFT would not automatically grant IP or commercial rights.

Architecture & data flow

1. 01Brief & rights
2. 02Image candidates
3. 03Selection & review
4. 04Traits & metadata
5. 05Publication preview
6. 06Separate mint approval

Integration design example

This JSON is a conceptual task contract for discussing fields and permissions. It is neither a live endpoint schema nor a request accepted by the local demo server. Use the linked local quickstart for runnable code.

{
  "application": "nft-generator",
  "brief": {
    "theme": "HZB community builders",
    "reference": "<licensed-ip-asset>",
    "traits": [
      "role",
      "background"
    ]
  },
  "output": [
    "image_candidates",
    "metadata_draft"
  ],
  "policy": {
    "mint": false,
    "rights_review_required": true
  }
}

Technical roadmap

Progress is organized around prototyping, validation and integration, with advancement determined by acceptance results. These phases are not completed milestones or fixed launch dates.

Further reading & integration

Application-category reference; HZB architecture and roadmap follow this proposed design: ChainGPT official products

Application overview

Read-only on-chain analysis for protocol operations, research and risk investigation. Interpret addresses, transactions, events and asset flows within an explicit time window, separating observed facts, heuristic labels and leads requiring further verification.

Features & capabilities

Technical value & HZB differentiation

HZB-Chain Intelligence would combine Data Mesh and analytics tools to connect explanations with replayable queries at the same snapshot. Critical states can use same-block source comparisons, with evidence retained in reports. Analysis would not directly become a trading instruction.

Architecture & data flow

1. 01Address & block range
2. 02Read & decode
3. 03Source & state checks
4. 04Flow & anomaly analysis
5. 05Evidence report
6. 06Research review

Integration design example

This JSON is a conceptual task contract for discussing fields and permissions. It is neither a live endpoint schema nor a request accepted by the local demo server. Use the linked local quickstart for runnable code.

{
  "application": "onchain-analysis",
  "query": {
    "chain_id": 1,
    "address": "<public-address>",
    "from_block": "<start>",
    "to_block": "<end>"
  },
  "mode": "read_only",
  "output": [
    "flows",
    "source_blocks",
    "uncertainties"
  ]
}

Technical roadmap

Progress is organized around prototyping, validation and integration, with advancement determined by acceptance results. These phases are not completed milestones or fixed launch dates.

Further reading & integration

Application-category reference; HZB architecture and roadmap follow this proposed design: ChainGPT official products

Application overview

A common integration path for DApps, wallets, developer tools and enterprise systems. Developer API is intended to expose models, retrieval, code analysis and task state through stable contracts, enabling selective integration.

Features & capabilities

Technical value & HZB differentiation

The design delivers results alongside their execution basis. Request IDs, task states and receipts support diagnosis; Credits meter services while token-related network roles remain separately defined. Current runnable documentation is a local fixed-data demo, not a production API.

Architecture & data flow

1. 01DApp backend
2. 02Auth & validation
3. 03Capability routing
4. 04Policy & budget
5. 05Task state & result
6. 06Receipt & usage

Integration design example

This JSON is a conceptual task contract for discussing fields and permissions. It is neither a live endpoint schema nor a request accepted by the local demo server. Use the linked local quickstart for runnable code.

{
  "application": "developer-api",
  "capability": "<selected-capability>",
  "request_id": "<client-request-id>",
  "context": {
    "project": "<project-id>"
  },
  "policy": {
    "external_writes": false
  },
  "output": [
    "task_status",
    "result",
    "receipt"
  ]
}

Technical roadmap

Progress is organized around prototyping, validation and integration, with advancement determined by acceptance results. These phases are not completed milestones or fixed launch dates.

Further reading & integration

Application-category reference; HZB architecture and roadmap follow this proposed design: ChainGPT official products

Application overview

For research, development and business tasks requiring multiple steps. HIVM Agents are designed to govern intent, reasoning and tool actions separately, making inputs, permissions, states and evidence inspectable at each step.

Features & capabilities

Technical value & HZB differentiation

The focus is a trusted action boundary, not unrestricted autonomy. Policy Gate and Verification Router are designed to independently check candidate actions, while wallets or enterprise signing services retain signing authority. Receipts document a process, not universal input correctness or commercial acceptance.

Architecture & data flow

1. 01Intent & TaskSpec
2. 02Task compilation
3. 03Read, analyze, generate
4. 04Policy & simulation
5. 05Authorized execution
6. 06Reconcile & attest

Integration design example

This JSON is a conceptual task contract for discussing fields and permissions. It is neither a live endpoint schema nor a request accepted by the local demo server. Use the linked local quickstart for runnable code.

{
  "application": "hivm-agents",
  "plan": [
    {
      "op": "READ",
      "source": "<authorized-source>"
    },
    {
      "op": "ANALYZE",
      "output": "research_summary"
    },
    {
      "op": "VALIDATE",
      "claim": "source_attribution"
    },
    {
      "op": "ATTEST",
      "scope": "recorded_process"
    }
  ],
  "policy": {
    "allowed_ops": [
      "READ",
      "ANALYZE",
      "VALIDATE",
      "ATTEST"
    ],
    "external_writes": false
  }
}

Technical roadmap

Progress is organized around prototyping, validation and integration, with advancement determined by acceptance results. These phases are not completed milestones or fixed launch dates.

Further reading & integration

Application-category reference; HZB architecture and roadmap follow this proposed design: ChainGPT official products

Application overview

For Web3 enterprises, protocol teams and service providers turning internal documents into searchable, citable knowledge. The priority is what each user is authorized to see, with answers traceable to document versions and passages.

Features & capabilities

Technical value & HZB differentiation

HZB-Embed, Data Mesh and enterprise identity controls are intended to work together. Retrieval, reranking and generation remain scoped, with project-isolated feedback and revocation propagated to indexes and caches. HHA scenarios may provide task samples without default sharing or training on private customer data.

Architecture & data flow

1. 01Authorized ingestion
2. 02Parse & inherit ACLs
3. 03Index & versions
4. 04Identity-filtered retrieval
5. 05Cited answers
6. 06Audit & refresh

Integration design example

This JSON is a conceptual task contract for discussing fields and permissions. It is neither a live endpoint schema nor a request accepted by the local demo server. Use the linked local quickstart for runnable code.

{
  "application": "enterprise-knowledge",
  "tenant_id": "<tenant>",
  "principal": "<authenticated-user>",
  "query": "Summarize the current release process.",
  "sources": [
    "<authorized-collection>"
  ],
  "policy": {
    "enforce_document_acl": true,
    "training_use": false
  },
  "output": [
    "answer",
    "citations",
    "document_versions"
  ]
}

Technical roadmap

Progress is organized around prototyping, validation and integration, with advancement determined by acceptance results. These phases are not completed milestones or fixed launch dates.

Further reading & integration

Application-category reference; HZB architecture and roadmap follow this proposed design: ChainGPT official products

Overview

Solidity addresses code understanding and assistance; Chain Intelligence addresses on-chain research; Risk supports risk and permission analysis; Agent handles orchestration; Embed enables semantic retrieval.

Before a call, define the target network, code and dependency versions, time range, sources and authorization.

Outputs should retain citations, scope and remaining questions. Profiles use different output conventions; formal interfaces will be released by version.

Choose by task

Capability & use cases

Understand contract logic, draft candidate code and tests, and identify dependency and permission issues.

Development · Test repair · Preliminary review

Inputs & outputs

Example request shape

{
  "capability": "hzb-solidity",
  "goal": "From requirements to contract review",
  "context": {
    "network": "local-demo",
    "source": "contract Example { address public owner; }"
  },
  "permissions": {
    "actions": [
      "read",
      "analyze"
    ],
    "external_writes": false
  }
}

Changing capability in the local demo only changes the receipt identifier. Output remains a fixed fixture; distinct real model behavior is not implemented here.

Capability & use cases

Organize address behavior, fund flows and protocol state with source and time context.

Address analysis · Protocol research · Data queries

Inputs & outputs

Example request shape

{
  "capability": "hzb-chain-intelligence",
  "goal": "Make on-chain activity understandable",
  "context": {
    "network": "local-demo",
    "source": "contract Example { address public owner; }"
  },
  "permissions": {
    "actions": [
      "read",
      "analyze"
    ],
    "external_writes": false
  }
}

Changing capability in the local demo only changes the receipt identifier. Output remains a fixed fixture; distinct real model behavior is not implemented here.

Capability & use cases

Combine vulnerability knowledge, permission structures and anomalies into reviewable findings.

Permission analysis · Risk summaries · Anomaly review

Inputs & outputs

Example request shape

{
  "capability": "hzb-risk",
  "goal": "Risk signals with evidence and context",
  "context": {
    "network": "local-demo",
    "source": "contract Example { address public owner; }"
  },
  "permissions": {
    "actions": [
      "read",
      "analyze"
    ],
    "external_writes": false
  }
}

Changing capability in the local demo only changes the receipt identifier. Output remains a fixed fixture; distinct real model behavior is not implemented here.

Capability & use cases

Break down tasks, select permitted tools and assemble candidate actions for controlled execution through HIVM.

Research workflows · Operations · Task coordination

Inputs & outputs

Example request shape

{
  "capability": "hzb-agent",
  "goal": "Turn complex goals into structured workflows",
  "context": {
    "network": "local-demo",
    "source": "contract Example { address public owner; }"
  },
  "permissions": {
    "actions": [
      "read",
      "analyze"
    ],
    "external_writes": false
  }
}

Changing capability in the local demo only changes the receipt identifier. Output remains a fixed fixture; distinct real model behavior is not implemented here.

Capability & use cases

Support semantic retrieval and knowledge connections across whitepapers, developer docs, code and languages.

Enterprise knowledge · Code retrieval · Multilingual search

Inputs & outputs

Example request shape

{
  "capability": "hzb-embed",
  "goal": "Connect documents, code and knowledge",
  "context": {
    "network": "local-demo",
    "source": "contract Example { address public owner; }"
  },
  "permissions": {
    "actions": [
      "read",
      "analyze"
    ],
    "external_writes": false
  }
}

Changing capability in the local demo only changes the receipt identifier. Output remains a fixed fixture; distinct real model behavior is not implemented here.

Before data reaches a model

Data Mesh connects authorized data to model context while distinguishing originals, indexes, retrieved passages and citations. Sources, versions, chains and access policies travel with the data.

1. 01Authorized sources
2. 02Normalize & chunk
3. 03Embed index
4. 04Access-filtered retrieval
5. 05Context & citations

Retrieval context example

{
  "query": "Which roles may upgrade this contract?",
  "scope": {
    "project": "demo",
    "network": "local-demo"
  },
  "context": [
    {
      "source_id": "authorized-document-1",
      "version": "example-v1",
      "retrieved_at": "<ISO-8601 timestamp>",
      "excerpt": "<authorized passage>",
      "access_scope": [
        "project:demo"
      ]
    }
  ],
  "policy": {
    "require_citations": true,
    "exclude_unauthorized_sources": true
  }
}

Quality & boundaries

Traceable citations do not establish source correctness. Distinguish freshness, authorization, relevance and model inference, and qualify conclusions when evidence is insufficient.

Overview

The research architecture defines READ, ANALYZE, GENERATE, SIMULATE, VALIDATE, AUTHORIZE, EXECUTE and ATTEST instruction semantics. Tasks are compiled into plans with permissions, policies and evidence requirements.

A Policy Gate returns permit, deny or escalate decisions. Models propose actions while authorization and execution components control external operations.

Execution receipts, idempotency keys and reconciliation support task tracking. A receipt proves an action occurred; it does not automatically establish quality, intellectual property or commercial value.

Task execution path

1. 01READ / ANALYZE
2. 02GENERATE
3. 03SIMULATE / VALIDATE
4. 04AUTHORIZE
5. 05EXECUTE / ATTEST

The eight instruction semantics follow the HIVM research direction. The JSON below is a readable plan illustration, not a released bytecode specification. Denial and uncertain state require separate stop or reconciliation paths.

Structured plan example

{
  "schema": "hzb-hivm-concept-v1",
  "status": "architecture-example-not-executable-bytecode",
  "task": "Review authorized contract permissions",
  "plan": [
    {"op": "READ", "resource": "authorized-source"},
    {"op": "ANALYZE", "purpose": "identify privileged roles"},
    {"op": "GENERATE", "artifact": "candidate-review-plan"},
    {"op": "SIMULATE", "mode": "read-only"},
    {"op": "VALIDATE", "checks": ["scope", "budget", "expiry"]},
    {"op": "AUTHORIZE", "decision": "permit-read-only"},
    {"op": "EXECUTE", "allowed_tools": ["read_authorized_source"], "external_writes": false},
    {"op": "ATTEST", "artifact": "reviewable-receipt"}
  ],
  "on_uncertain_state": "pause-and-reconcile",
  "note": "Architecture illustration only. No published HIVM bytecode or runtime is implied."
}

Define the task before execution

TaskSpec collects goals, context, capabilities, permissions, budgets and deliverables. It is an architecture-level task description, not the same contract as the local HTTP demo.

Conceptual structure

{
  "schema": "hzb-task-spec-concept-v1",
  "status": "illustrative-template",
  "goal": "Review roles and permissions in an authorized contract",
  "capability": "hzb-solidity",
  "context": { "network": "bnb-chain", "compiler": "0.8.24", "source": "YOUR_AUTHORIZED_CONTRACT" },
  "permissions": { "actions": ["read", "analyze"], "external_writes": false, "human_approval_required": true },
  "constraints": { "max_tool_calls": 10, "timeout_seconds": 120 },
  "deliverables": ["permission-summary", "source-citations", "human-review-checklist"],
  "note": "Conceptual example only. This is not a published API schema and does not execute actions."
}

Acceptance & evidence

Execution receipts describe actions, while acceptance records assess whether delivery meets goals. Keep them separate: executed does not automatically mean correct or accepted.

Overview

Authorization should cover tools, resources, actions, expiry, budget and termination conditions. High-risk operations require a designated approver.

Simulation checks a candidate action against constraints. It cannot remove the effects of external state changes, so required conditions need rechecking before execution.

When state is uncertain, pause and reconcile the actual result rather than repeating an operation that may already have taken effect.

Three Policy Gate decisions

if tool not in granted_tools: DENY
if resource not in granted_scope: DENY
if authorization_expired or budget_exceeded: DENY
if external_write or high_risk_action: REQUIRE_HUMAN_APPROVAL
else: PERMIT_SCOPED_ACTION

# Before execution, recheck authorization and external state.
# After an uncertain result, PAUSE and RECONCILE; do not blindly retry.

The demo defaults to read-only

The local example returns 403 for anything beyond read/analyze and has no click-to-approve execution bypass. Real high-risk approval must bind the approver, action, resources and expiry rather than rely on a boolean flag.

Protocol scope

This page documents the implemented hzb-docs-demo-v1 local protocol at http://127.0.0.1:8787. It is not an HZB public endpoint. local-demo-key is a public example string, not a production credential.

Request headers

Authorization: Bearer local-demo-key
Content-Type: application/json
Idempotency-Key: first-read-only-task

POST requires a 1–80 character idempotency key containing letters, digits, underscores or hyphens. The example does not auto-retry. Reusing a key requires identical request-body bytes.

Request fields

Complete request

{
  "capability": "hzb-solidity",
  "goal": "Prepare a human-review checklist for an authorized contract",
  "context": {
    "network": "local-demo",
    "source": "contract Example { address public owner; }"
  },
  "permissions": {
    "actions": ["read", "analyze"],
    "external_writes": false
  }
}

Demo limits

The example limits bodies to 64 KiB and stores at most 100 idempotency records in memory, cleared on restart. These are implementation limits, not HZB production quotas, rate limits, an SLA or a reliability commitment.

Before you run

Start the local server using Quickstart. These are ordinary client examples, not an official SDK package, and need no unpublished npm or PyPI packages.

JavaScript · Node.js 20+

// Node.js 20+. Start hzb-demo-server.mjs first. Never use production secrets here.
import {randomUUID} from 'node:crypto';
const baseURL = 'http://127.0.0.1:8787';
const response = await fetch(`${baseURL}/v1/tasks`, {
  method: 'POST',
  headers: {
    Authorization: 'Bearer local-demo-key',
    'Content-Type': 'application/json',
    'Idempotency-Key': randomUUID()
  },
  signal: AbortSignal.timeout(10000),
  body: JSON.stringify({
    capability: 'hzb-solidity',
    goal: 'Prepare a human-review checklist for an authorized contract',
    context: {network: 'local-demo', source: 'contract Example { address public owner; }'},
    permissions: {actions: ['read', 'analyze'], external_writes: false}
  })
});
const result = await response.json();
if (!response.ok) throw new Error(`${response.status} ${result.error?.code}: ${result.error?.message}`);
if (result.demo !== true || result.execution_performed !== false) throw new Error('Unexpected example response');
console.log(JSON.stringify(result, null, 2));

Python · 3.9+

"""Python 3.9+. Start hzb-demo-server.mjs first. Local static fixture only."""
import json
import uuid
import urllib.request
import urllib.error

payload = {
    "capability": "hzb-solidity",
    "goal": "Prepare a human-review checklist for an authorized contract",
    "context": {"network": "local-demo", "source": "contract Example { address public owner; }"},
    "permissions": {"actions": ["read", "analyze"], "external_writes": False},
}
request = urllib.request.Request(
    "http://127.0.0.1:8787/v1/tasks",
    data=json.dumps(payload).encode("utf-8"),
    headers={"Authorization": "Bearer local-demo-key", "Content-Type": "application/json", "Idempotency-Key": str(uuid.uuid4())},
    method="POST",
)
try:
    with urllib.request.urlopen(request, timeout=10) as response:
        result = json.load(response)
        if result.get("demo") is not True or result.get("execution_performed") is not False:
            raise ValueError("Unexpected example response")
        print(json.dumps(result, indent=2, ensure_ascii=False))
except urllib.error.HTTPError as error:
    print(error.code, error.read().decode("utf-8"))
    raise SystemExit(1)

cURL · HTTP request

curl http://127.0.0.1:8787/v1/tasks \
  -H "Authorization: Bearer local-demo-key" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: first-read-only-task" \
  --data-binary @task-request.json

Local server source

// HZB documentation example. Local, deterministic fixture; NOT a model or HIVM implementation.
// Node.js 20+. No external services, wallets, transactions or production credentials.
import http from 'node:http';
import {createHash, randomUUID} from 'node:crypto';
import {pathToFileURL} from 'node:url';

const capabilities = ['hzb-solidity', 'hzb-chain-intelligence', 'hzb-risk', 'hzb-agent', 'hzb-embed'];
const MAX_BODY = 64 * 1024;
export function createDemoServer() {
  const receipts = new Map(); // Memory only; erased on restart. Not production idempotency storage.
  return http.createServer(async (req, res) => {
    const requestId = randomUUID();
    const reply = (status, data) => {
      res.writeHead(status, {'Content-Type': 'application/json; charset=utf-8', 'Cache-Control': 'no-store'});
      res.end(JSON.stringify({demo: true, request_id: requestId, ...data}, null, 2));
    };
    const fail = (status, code, message) => reply(status, {error: {code, message}});
    if (req.method === 'GET' && req.url === '/health') return reply(200, {status: 'local-fixture-only'});
    if (req.headers.authorization !== 'Bearer local-demo-key') return fail(401, 'DEMO_UNAUTHORIZED', 'Use the public local-demo-key only with this local example.');
    if (req.method === 'GET' && req.url === '/v1/models') return reply(200, {data: capabilities.map(id => ({id, status: 'fixture-only'}))});
    if (req.method !== 'POST' || req.url !== '/v1/tasks') return fail(404, 'DEMO_NOT_FOUND', 'This example supports GET /v1/models and POST /v1/tasks.');
    if (!req.headers['content-type']?.startsWith('application/json')) return fail(415, 'DEMO_CONTENT_TYPE', 'Send application/json.');
    const key = req.headers['idempotency-key'];
    if (typeof key !== 'string' || !/^[A-Za-z0-9_-]{1,80}$/.test(key)) return fail(400, 'DEMO_IDEMPOTENCY_KEY', 'Provide a 1–80 character Idempotency-Key.');
    let payload, raw = '', size = 0;
    const chunks=[];
    try {
      for await (const chunk of req) {
        size += chunk.length;
        if (size <= MAX_BODY) chunks.push(chunk);
      }
      if (size > MAX_BODY) return fail(413, 'DEMO_PAYLOAD_TOO_LARGE', 'The local example accepts at most 64 KiB.');
      raw=Buffer.concat(chunks).toString('utf8');
      payload = JSON.parse(raw);
    } catch { return fail(400, 'DEMO_INVALID_JSON', 'Send a valid JSON object.'); }
    if (!payload || typeof payload !== 'object' || Array.isArray(payload) || typeof payload.goal !== 'string' || !payload.goal.trim() || !capabilities.includes(payload.capability)) return fail(422, 'DEMO_INVALID_TASK', 'Provide a goal and one of the fixture capability IDs.');
    const permissions = payload.permissions;
    if (!permissions || permissions.external_writes !== false || !Array.isArray(permissions.actions) || !permissions.actions.length || permissions.actions.some(action => !['read', 'analyze'].includes(action))) return fail(403, 'DEMO_POLICY_DENIED', 'Only explicit read/analyze permissions and external_writes=false are accepted.');
    const digest = createHash('sha256').update(raw).digest('hex');
    if (receipts.has(key)) {
      const previous = receipts.get(key);
      if (previous.digest !== digest) return fail(409, 'DEMO_IDEMPOTENCY_CONFLICT', 'This key already belongs to a different request body.');
      return reply(200, {...previous.result, replayed: true});
    }
    if (receipts.size >= 100) return fail(503, 'DEMO_STORE_FULL', 'Restart the local example to clear its 100-entry memory store.');
    const result = {
      task_id: `demo_${randomUUID()}`, schema: 'hzb-docs-demo-v1',
      capability: payload.capability, status: 'fixture_complete',
      policy: {decision: 'permit_read_only', external_writes: false},
      execution_performed: false,
      output: {kind: 'static_fixture', checklist: ['Confirm source ownership and authorization.', 'Review privileged roles and acceptance criteria with an engineer.'], note: 'Fixed example output. No AI inference, contract analysis, security audit or external execution occurred.'},
      receipt: {request_sha256: digest, steps: ['validate_input', 'check_read_only_policy', 'return_fixture'], source_verified: false},
      replayed: false
    };
    receipts.set(key, {digest, result});
    return reply(200, result);
  });
}
if (process.argv[1] && import.meta.url === pathToFileURL(process.argv[1]).href) {
  createDemoServer().listen(8787, '127.0.0.1', () => console.log('HZB local fixture: http://127.0.0.1:8787 — no real AI or external execution'));
}

Overview

Store credentials in secure server-side configuration. Separate authorization by environment, project and purpose; avoid exposing keys in browsers, logs or public code.

Clients should distinguish failed authentication, insufficient permission, exhausted quotas, invalid inputs and service errors. Retrying writes requires an idempotency key and execution-state checks.

Formal error codes, rate limits and authentication protocols will be published with the available API version.

From demo keys to production secrets

The public local-demo-key is only for the 127.0.0.1 example. Production secrets belong in server-side configuration or a secret manager with environment/project-scoped access, never frontend code or downloadable examples.

Before production integration

Demo error codes

Observe permission denial

{"permissions":{"actions":["read"],"external_writes":true}}

{
  "demo": true,
  "request_id": "<generated-id>",
  "error": {
    "code": "DEMO_POLICY_DENIED",
    "message": "Only explicit read/analyze permissions and external_writes=false are accepted."
  }
}

Timeout does not mean nothing happened

In real systems, reconcile external writes after a timeout before retrying. This demo performs no writes; replaying the same key and body illustrates idempotency, not a complete distributed implementation.

Overview

Enterprise integration begins with use cases, data authorization, existing systems and delivery criteria. Knowledge bases need document versioning, update ownership, access control and source citations.

Evaluate hosted APIs, dedicated environments or private deployment along with data retention, audit, operations and model updates.

Deliver implementations as verifiable workflows with explicit test samples, acceptance evidence and support scope.

Enterprise delivery checklist

Overview

HZB is HHA’s inaugural ecosystem. HHA is the first application designed to use HZB Network’s specialized model capabilities.

HHA organizes demand around Web3 discovery, due diligence, token design and incubation. HZB provides the model, tooling and controlled-execution direction.

The HHA application, HHA token, HZB Network platform and HZB token have distinct meanings and should be named consistently.

Overview

The HHA website describes access, payment, staking and governance uses. The on-chain supply is one billion tokens on BNB Chain.

The HZB whitepaper uses a 105 million supply framework for coordination, accountability, conditional PoB settlement and governance. Network, contract and release details depend on formal issuance materials.

Credits meter services such as models, data, APIs and tools. Service procurement and token-network participation need distinct rules.

Overview

Is HZB a blockchain? The materials focus on Web3 intelligence infrastructure and a builder network. HIVM is a controlled task runtime between models and tools.

How do I get API access? Prepare a use case and authorized data samples, then generate an integration brief. Test environments and credentials will accompany the access program.

How can I contribute? Start with research review, feedback, workflow design, tutorials and translation. Activity requirements depend on their actual announcements.

Overview

2026-09-10 · Documentation reorganized with reference architecture, capability pages, HTTP guidance and runnable local examples. This is a documentation/demo update, not a production API or SDK release.

2026-09-09 · Website material compilation: unified entries for products, HHA, HIVM, economics, integration and brand resources. This is the compilation date, not a product launch date.

Future API, SDK, contract and product versions will be documented as they are released.

Website privacy notice

This site provides public information, search, downloads and video, not online access applications or accounts. Hosting services may process necessary access records. Footer search terms appear in the URL; do not enter sensitive information. The full notice covers purposes, retention, security, external platforms and your rights.

Full Privacy Notice Read the HZB Privacy Notice

Website terms of use

Website terms cover public materials, documentation, downloads and videos. Development roadmaps are not available production services, and examples do not execute real asset transactions. Separate service agreements and software licenses apply where provided.

Full Terms of Use Read the HZB Terms of Use