Host API

Overview

TEE contracts execute as WebAssembly (WASM) components within a sandboxed Wasmtime runtime hosted by a T3N node. By default, contracts have no direct access to the operating system, network, filesystem, clock, randomness, or other system resources. To minimize the attack surface and enforce least-privilege access, TEE contracts interact with the outside world exclusively through a strongly typed Host API implemented by the T3N node using the WASM Component Model. This capability-based model ensures that contracts can access only the resources and functionality explicitly exposed by the host runtime.

If a capability is not defined in the Host API, the contract cannot do it.

Host interfaces

TEE contracts can only interact with the outside world through explicitly defined host interfaces, and all interfaces are gated by authorisation checks — a contract cannot access capabilities it has not been granted.

Interface	What it does	Use it when	Gating	z-namespace
`kv-store`	Read / write / delete entries in the contract’s namespaced key-value maps. Writes participate in the same atomic transaction as the rest of the call.	Persisting contract state.	Namespace is bound to the contract; no cross-contract reads.	✅
`tenant`	Tenant-scoped lifecycle and metadata reads.	Multi-tenant contracts that need to know which tenant they’re running under.	Standard per-contract authorisation.	✅
`logging`	Emit `info` / `debug` / `error` log lines.	Diagnostics.	None.	✅
`http`	Outbound HTTP / HTTPS requests.	Calling a third-party API from your contract.	Per-contract egress allowlist of host names.	✅
`http-with-placeholders`	Outbound HTTP where the host substitutes `{{profile.<field>}}` markers in headers / body from the calling user’s profile before sending. The plaintext value never enters WASM.	Sending user PII (email, phone) to an upstream API without giving the contract read access to it.	Egress allowlist (shared with `http`) plus a per-contract `placeholder_allowlist` naming which profile fields may be substituted.	✅
`signing`	Three signing primitives: (1) cluster ECDSA — Keccak-256 + secp256k1 — via `sign` / `sign-as-user`; (2) per-wallet signing via `sign-with-wallet` for any wallet the calling DID owns; (3) SD-JWT Verifiable Credential issuance via `sign-sd-jwt-vc` (ES256 / P-256). `sign-as-user` produces an EIP-191 personal-sign signature (host applies the prefix); the contract passes raw bytes.	Producing an Ethereum-compatible signature, signing a transaction on behalf of a user, or issuing a Verifiable Credential.	Per-contract allowlist on `sign-as-user`. `sign-with-wallet` additionally verifies the wallet address is in the caller’s wallet set.	Coming soon
`outbox`	Enqueue an HTTP request to be delivered after the current transaction commits. Delivery is at-most-once with an idempotency-key dedupe window, driven by a single leader.	Triggering an external side-effect (payment, webhook) that must not double-fire if the contract is replayed.	Per-contract allowlist of upstream hosts.	Coming soon
`vp`	Sign and submit Verifiable Presentations (OID4VP). Verifier accepts SD-JWT + Key Binding envelopes against a trusted-issuer registry.	Issuing or verifying W3C-style Verifiable Credentials.	Trusted issuers maintained by the cluster operator.	Coming soon
`did-registry`	Link an authenticator (email, OIDC subject, …) to a Decentralised Identifier on chain.	Onboarding a user with a new login method.	Standard per-contract authorisation.	Coming soon
`agent-auth`	Update which TEE contracts / functions an agent is authorised to invoke.	Managing delegated agent permissions.	Standard per-contract authorisation.	Coming soon
`user-profile`	Encrypt and store user profile data.	Persisting PII alongside a DID.	Standard per-contract authorisation.	Coming soon
`user-removal`	Remove all data associated with a user.	GDPR / account deletion flows.	Admin-only by default.	Coming soon
`contracts-call`	Synchronously call another contract’s exported function. The inner call executes inside the same transaction as the outer call; on inner failure the inner writes are discarded but the outer call may continue.	Composing contracts (e.g. a workflow contract calling a payment contract).	Per-pair `(caller, target)` allowlist with `allowed_functions` and `max_depth`. Reentrancy and depth overruns return typed errors (`reentrant`, `depth-exceeded`).	System-only
`stash`	Drain the binary blob attached to the current multipart request into content-addressed storage and hand the contract a reference to it.	Accepting a file or large payload uploaded alongside the contract call.	Per-contract allowlist; default deny. Single-use per request — a second call returns `AlreadyConsumed`.	System-only
`agent-registry`	Register or update the agent URI for a DID.	Publishing where a user’s agent is reachable.	Standard per-contract authorisation.	System-only
`authorisation`	Ask the host whether a given action / host is currently permitted.	Pre-flighting a sensitive operation before doing the work.	None (pure read).	System-only
`otp`	Verify a one-time password and track its status.	Email / SMS code verification flows.	Standard per-contract authorisation.	System-only
`config/read`	Read a cluster-level configuration value by key (typed `read-u64` / `read-string`).	Reading a non-secret cluster knob set by the operator.	None — configs are public metadata.	System-only
`provider-config`	Read operator-managed provider configuration and, if the contract is on the matching secret row’s allowlist, the merged secret bag.	Calling an external provider (KYC, OAuth) whose API key the operator has configured.	Per-contract allowlist on each secret row.	System-only
`time` / `clock`	Read wall-clock and monotonic time.	Any time-dependent logic — there is no other source of time inside WASM.	None.	System-only
`node-config`	Read node-level configuration values exposed to contracts.	Reading host-published runtime knobs.	None.	System-only

Overview

How T3N works

Use Cases

Data Owner Guide

Overview

Host interfaces

​Overview

​Host interfaces

Overview

Host interfaces