How does constraint validation work in Traverse?
Constraint validation runs before the WASM binary loads. It checks whether a capability is allowed to run given the current context. If it fails, the call is rejected without ever touching the sandbox.
Two types of constraints
Sandbox constraints declare which host capabilities the WASM instance needs. Three flags cover the main cases:
All three default to false. A capability must explicitly set a flag to true if it needs that access. During constraint evaluation, the runtime checks whether the requested environment permits the declared permissions. If a capability declares network_access = true but the target environment does not allow network access, the capability is removed from the selection pool.
Preconditions are logical conditions on the input or context that must hold before execution starts. They are declared in the contract and checked by the runtime during the evaluating_constraints state. A precondition might require that a user is authenticated, that a required input field is non-empty, or that a feature flag is enabled.
What happens when validation fails
For sandbox constraints: the capability is filtered out during discovery. It never reaches the selection step. If no capability passes, the machine moves to error with capability_not_found.
For preconditions: the runtime moves to error with precondition_failed and records which precondition failed and why. This happens before any WASM binary loads.
Why reject early
Loading and instantiating a WASM binary has a cost. Rejecting an invalid call before that step keeps failed requests cheap. A precondition check is a few microseconds. A WASM instantiation is orders of magnitude more.
Early rejection also keeps the trace artifact clean. A precondition_failed error in the trace is unambiguous. There is no partially executed binary to reason about.