What is Traverse's performance like?

Traverse runs WASM at near-native speed and adds a small, predictable overhead for contract validation. For the business logic Traverse is designed for — pricing rules, eligibility checks, tax calculations — the validation cost is a rounding error next to the capability's own computation time.

Where the overhead comes from

There are three validation passes per call: precondition check before execution, the WASM execution itself, and postcondition check after. The pre and post checks are JSON schema validation against the contract definition. They do not execute arbitrary code. On modern hardware, a schema check against a typical business logic payload takes microseconds.

WASM execution speed

WASM runs close to native machine speed. Rust compiled to WASM is a good fit for computation-heavy logic like pricing engines, scoring models, or rules evaluation. The Wasmtime runtime Traverse uses applies optimizations at load time, so repeated calls to the same capability amortize the startup cost.

State machine overhead

The runtime drives a state machine through seven phases on each call. The state transitions themselves are cheap. The phases that take real time are the WASM execution phase and the validation phases. Discovery and selection are registry lookups — fast if the registry is small, still bounded if it is large.

When performance matters

• High-frequency trading or real-time streaming: measure first, but Traverse is not designed for microsecond-latency pipelines
• Batch processing: WASM startup cost per call amortizes well in batch scenarios
• Web requests: pricing or eligibility on a web request adds sub-millisecond overhead
• AI agent pipelines: network latency to the LLM dominates, validation overhead is irrelevant

See is Traverse production ready for a broader readiness assessment.