Deterministic WebAssembly Sandbox | Dweve Selvedge

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Compile Kera BNN workloads for Selvedge runtime.

Hash-chained event provenance for system events.

Reasoning proof certificates, not execution transcripts.

Selvedge publishes in the third round of the foundation release programme, after Knot and Ledger. Once it does, sandbox a WASM module and replay the proof envelope yourself.

Model Context Protocol tool execution surface.

Ed25519 sealed, SHA3-256 transcript, offline verify.

Graph IR binary neural networks, JIT and interpreter.

Component model runtime, WASI 0.2 Preview 2 host.

Selvedge runs untrusted code inside a capability-limited sandbox and records the execution in a sealed transcript. Containment limits what the code can touch; the transcript shows what actually happened and can be replayed for review.

Model Context Protocol server for agent tools.

Long-running agent runtime with a queue.

build, verify, run, replay. CI-friendly.

Linked into your application as a crate.

Agent tools, third-party plugins, Kera BNN inference, and regulated data work all enter through the same controlled boundary. Each runtime produces the same sealed evidence envelope, so deployment changes do not change the audit story.

Compute module, vs 1187-1494 us vanilla.

Selvedge Wasmtime starts 62 to 243x faster than vanilla Wasmtime at the API level. The honest trade is the hot path: vanilla holds the 22 ns repeated call, and the component model that produces the transcript runs slower there. Kera JIT is 2x faster warm for graph work. Figures are from the repository BENCHMARKS.md.

Every gate decision recorded and hashed.

max_execution_time_ns, separate from fuel.

max_memory_bytes, 256 MiB default, 4 GiB ceiling.

max_instructions, exhaustion halts the workload cleanly.

Clock, random, filesystem, network, environment, stdio, process, custom. Default deny.

A default-deny capability set gates every host call across eight WASI domains. Resource caps on memory, fuel, and time bound runaway behaviour. Every gate decision and resource read is in the transcript.

You need cryptographic evidence of what the workload did, not confidence in the runtime.

Allow file system, deny network, but no per-call record in the audit trail.

FP and wall-clock leak through. Replay produces approximately the same output, not exactly.

A sandbox stops escape. It does not prove the workload behaved correctly inside.

Conventional sandboxes stop bad code from escaping. They do not produce a record of what the code actually did inside. When an auditor asks, the answer is an assertion, not evidence.

Selvedge captures exactly what executed, input to output, every host call sealed.

Ledger records what happened in a system. Selvedge records what code ran.

AION issues certificates over solver steps, not execution runs.

How Selvedge differs from AION and Ledger

Same inputs plus same envelope means same output, always.

A fixed epoch and a seeded ChaCha20 PRNG replace host time and entropy.

Internal computation, storage and accumulation use binary, integer, fixed-point or adaptive integer/fixed-point representations. Floating point is accepted only at a declared external boundary and is explicitly converted before internal work begins; there is no internal floating-point fallback. The virtual clock remains fixed, so replay produces the same bytes.

Verifier replays offline with module bytes and envelope alone.

ed25519 signature over the envelope root. Not prose.

Every host call hashed into the chain. Edits break the chain.

Why the transcript is different from a log

Same flow on every execution. Replay is mechanical.

AION proof issued, ed25519 signed, envelope ready to ship.

Every host call and result hashed into a SHA3-256 chain.

Wasmtime or Kera executes inside the default-deny sandbox.

Module loaded, capabilities pinned, resource caps applied.

Selvedge runs WASM or Kera code inside a default-deny sandbox, hashes every host call into a SHA3-256 transcript chain, and wraps the result in a signed AION proof envelope. The envelope replays without the original sandbox.

Selvedge is a deterministic WebAssembly sandbox for untrusted code. Its permission manifest and sealed transcript run on hardware you control, so a counterparty can replay the record on its own machine and a dispute becomes a lookup rather than an assurance request.

Selvedge puts a program you did not choose in a room with no internet, no route to your files and nothing to learn about your machine. It leaves a receipt saying what came back and what the program was allowed to do, so you can check a later claim instead of taking somebody's word for it.

Selvedge runs code you did not write in a WebAssembly component host with no network, filesystem, environment or moving clock. Every completed run returns a record another party can replay, and an execution report stating what the code was allowed to do. Published under Apache 2.0.

Run untrusted code on hardware you control.

Publication is planned in fortnightly rounds. The repository and its documentation go live together.

It does one small job, here, and nowhere else.

Execution completed successfully in 18.4ms

The room, the receipt and the list are the whole promise.

Here it arrives as a list. Each job that used the faulty program names it by code, date and a short permission list, so you can see what was affected and how far it could have gone. If the people who made it are no longer trusted, withdrawal takes effect on a set refresh interval rather than whenever a certificate expires. The software is published under the Apache 2.0 licence.

The usual version of this conversation is an estimate. Somebody works out which release was probably running, on which days, for which people, and the answer arrives as a range with a caveat on it. That leaves the facts needed to scope a correction as a reconstruction rather than a record. The correction begins with a list that can be checked.

Every job records a short code for the exact program that did the work. Not its name, not its version number, the program itself, so two builds that share a name still have different codes. If that program later turns out to be faulty, the code is how every job it touched gets found.

When something turns out wrong, one code names the program.

The program itself is loaded fresh each time from its own code, and the receipt carries a code for that code, so the thing that ran today is provably the thing that ran last month. Nothing accumulates in between for anybody to worry about later.

A new Selvedge room costs so little that one per job is affordable, so nothing has to be shared. If something genuinely needs to carry across, it is handed over on purpose and it appears on the record as something that was handed over.

Each job gets a new room. Nothing from the last one is in it: no leftover notes, no half-finished work, no memory of who asked. That sounds obvious and it usually is not true, because keeping a room standing is cheaper than building a new one, so most systems keep the room and reuse it.

Finding nothing is weak evidence, because it depends on how hard somebody looked and how long they had before the meeting. A list of two permissions is strong evidence, because there was nothing else there to find.

It changes what happens when you ask a question later. Instead of somebody going through what the program did and reporting back that they found nothing worrying, the permission list is right there, and it is short.

Most records tell you what a program did. A Selvedge receipt also says what it was permitted to do, which is a different and more useful thing. A program that was never allowed near your files cannot have been near your files, and that is on the record whether or not anybody happened to be watching at the time.

A code is not a copy of the program; it names the exact thing that ran.

It also closes a small trick. A program that can read the clock can behave one way before a deadline and another way after it, and nobody would ever see the difference. A clock that never moves cannot be watched, so there is nothing to behave differently about.

It hands you a test you can run yourself. If something looks wrong, run it again with the same input. If the answer is the same, the program is behaving and the problem is somewhere else. If it is different, something changed, and the comparison says which part.

Most programs give slightly different answers each time, because they look at the clock, use a bit of chance, or notice how busy the machine is. A program running in Selvedge can do none of that. The clock inside is fixed and never moves, and anything random starts from the same number on every run. Ask twice, get the same answer.

Run it again tomorrow and see if it still agrees.

It is the same idea as a seal on an envelope, and it does more. A seal tells you the letter was opened. This tells you which page changed, and it still works when the letter has been copied a dozen times since. Each reader gets the same answer from the copied record.

That code is what makes a later argument short. If somebody shows you an answer a program gave last March and you want to know whether it is the answer that actually came out, you compare the codes. They match or they do not, and there is nothing in between to discuss.