HESO ships one verification and signing engine, written in Rust. Every language binding — the Python SDK, the TypeScript SDK, the Node native addon, and the browser verifier — calls into that same core. This page maps it out: what each surface is for, which one to use, and where to find the per-package reference.
One core, four surfaces
The Rust core is the single source of truth for canonicalization (RFC-8785 JCS), the BLAKE3 content hash, and the Ed25519 signatures. Python, Node, and the browser WASM build all bind to that one implementation. There is no separate copy of the crypto in JavaScript or Python to drift out of sync.
Because every surface runs the same compiled logic, a verdict is byte-identical everywhere. The same receipt produces the same seven-gateresult on your server and in a reviewer’s browser. That is what lets a receipt be checked offline. You verify the artifact itself, not a service’s claim about it.
import { verifyActionReceipt } from "@hesohq/core"import { verifyActionReceipt as verifyInBrowser } from "@hesohq/core/browser" // Same Rust core, same verdict — whether this line runs in Node// (native addon) or in a reviewer's browser (WASM).const verdict = verifyActionReceipt(receipt)
The wire format the core reads and writes is fixed: the algorithm string alg = "heso-action/v2+ed25519" and action_version = "heso-action/2.0". Those two strings are the first two gates the verifier checks, so every surface agrees on exactly which bytes it is willing to trust.
Identical results mean the cryptography and canonicalization match across runtimes: the same hash, the same signature check, the same re-derived trust level. A verified receipt proves the operator authorized the action under a known policy, and at L1 that a person approved it with a device-held key — the same result on every surface, because every surface runs the same engine.
Choosing a surface
Pick by runtime, then by what you need to do. Gating runs where your agent runs. Verifying can run anywhere, including a browser with no HESO infrastructure.
| Package | Runtime | What it does |
|---|---|---|
heso | Python | Gate, sign, and audit your agent in-process — decorators and a proxy that capture each action and run it through policy. |
@hesohq/sdk | TypeScript / Node | Verify plus gate, the cloud client, and the wire types — a thin wrapper over @hesohq/core. |
@hesohq/core | Node (native addon) | The low-level surface: verify, sign, redact, and key management. |
@hesohq/verify-wasm | Browser (WASM) | Verify-only — re-run the seven gates locally, in any browser, with no network call. |
If you are gating an agent
Use the Python SDK if your agent is Python — it wraps your tool and LLM calls in-process and signs each action into a receipt. From Node, @hesohq/sdk gives you the gating helpers and the cloud client in one package.
If you are verifying receipts
- In Node, call @hesohq/core directly, or use @hesohq/sdk if you also want the cloud client and types.
- In a browser, use @hesohq/verify-wasm — verify-only, ESM, with an async init. This is the surface the HESO web console itself uses to verify receipts client-side.
@hesohq/core also exposes a "@hesohq/core/browser" entry point that re-exports @hesohq/verify-wasm. Import from there when you want one package name across server and browser code paths.
Packages
Each surface has its own reference page covering its full function list. Start with the one that matches your runtime.
Versioning
Every HESO package is at 0.1.0 today — the Python SDK heso, the three Node packages (@hesohq/sdk, @hesohq/core, @hesohq/verify-wasm), and the bundled Rust core. Runtime floors are Python >= 3.10 for the Python SDK and Node >= 18 for the Node packages.
The package versions move fast, but the wire format is the contract that stays stable: the algorithm is heso-action/v2+ed25519 and the action version is heso-action/2.0. A receipt signed today is verifiable by any surface that recognizes those two strings.
import heso # The Python SDK bundles the same Rust core as the heso._core wheel.# Gate operations run in-process — no subprocess, no re-implemented crypto.heso.init(team="acme")
These packages are pre-1.0, so library APIs may change between releases. Pin your versions, and read the verdicts reference so you handle every verification outcome instead of assuming success.
Next steps: