Contain the generated code. Mediate its physical effects.

System definition

Endstop has two independent boundaries: one confines hostile generated code; the other mediates its physical proposals. The tables below specify each subsystem.

Consolidated implementation checklist and roadmap →

We write the interpreter ourselves. The published verified VMs we evaluated proved a much larger machine than we run, arrived with a 2022 toolchain and a licence problem, and stopped at C rather than machine code. All seven properties of our own interpreter discharge, memory safety last, on 2 August 2026, to the depth a bounded model checker reaches. Physical-board loader/VM bring-up, UART diagnostics and workload-local counter timings have passed; what has been measured against the core's register-transfer description is in §2. The work in front of us is integration and measurement.

The effect path

Within the specified program interface, every admitted effect follows one path: the instruction set exposes no file, socket, allocator or unmediated output verb.

1. The agent (114), running off-board on untrusted host compute (110), sends a program over a serial interface (120) that carries programs in and verdicts out.
2. The program executes in the interpreter (134) under a fuel bound. It terminates by construction; there is no analysis to defeat, only a counter that reaches zero.
3. It may invoke exactly three capabilities through the capability table (136): read state, propose a setpoint, request a signature. There is no file, no socket, no allocator, no fourth verb.
4. Each proposed effect is checked by the envelope monitor (138) against limits validated offline, covering multi-point position, predicted stopping position, rate and acceleration ceilings, a spectral resonance limiter and a deadman.
5. Effects that pass are constructed by the trusted side and emitted (144) to the target driver stage (152). A failed check requests the configured safe reaction. The product design records every verdict and periodically seals the chain; the current emulator keeps a bounded journal sealed on request.

Two boundaries carry that path, and they do different jobs. The serial interface is the first: it keeps the loader, the interpreter and the monitor out of reach of whatever is running the model, so our code is not that machine's to patch. The second is the one the safety argument rests on. Step 2 executes the submitted program on the gate's own core, in the same address space as the loader and the monitor. Nothing physical stands between them. What separates them is the interpreter's semantics (fuel, the three-entry table, memory bounds) together with the RV32 physical-memory-protection configuration that holds the monitor's state out of the program's reach.

Memory safety in the interpreter is proven. The protection configuration has held in physical denial probes on the board. In the fabric-gate prototype, output permission already sits in fabric logic the processor cannot write itself into; the next isolation milestone moves the monitor's state there and puts the actuator path behind it.

The other side is deliberately thin. The part running the model is an inference engine: tokens in, tokens out, no interpretation of what it emits and nothing wired to it. So a misaligned model, a jailbreak, a prompt injection and an attacker in full control of that accelerator all arrive here as the same object, which is a hostile program at the loader. We removed the host from this boundary, so there is no separate class of host-compromise attack to answer.

Two timescales, because the physics demands it

The fast control loops belong to the servo drive, and we leave them there. Current loops typically run at 8–20 kHz and velocity loops at around 5 kHz, all of it beneath us. What crosses the network is setpoints, typically at 500 Hz or as PWM.

So enforcement splits. The slow path validates the envelope offline, once, the way every certified safety configuration in industry is validated. The fast path is a constant-time comparison against that envelope on every cycle, using table lookups with no allocation and no search.

ISO 13855 converts the complete reaction time into required guard distance at the applicable approach speed. The relevant quantity is not an isolated monitor target: it is capture, phase delay, computation, output, drive response and mechanical stopping time together. Endstop has measured the monitor against the target core's RTL and in 12, 24, 48 and 96 MHz board workloads; a pilot must derive its allowable budget from the machine-specific hazard analysis and replace every remaining component with hardware measurements.

The interpreter no longer treats every instruction as the same amount of timing work. It keeps step fuel, which proves termination, separate from tick credits, which use a versioned target-specific cost table. The VM reserves an instruction's complete charge before executing it; an unaffordable capability call therefore cannot enter the callee. Forward-only programs can be rejected at load time when the fixed overhead plus every instruction charge exceeds the tick allowance.

The initial table comes from a retained no-cache NEORV32 RTL characterization. With a 25% engineering margin and rounding, charges range from 320 credits for a byte store to 480 credits for capability-call stubs, plus 416 credits of fixed invocation overhead. This is simulator characterization, not physical hardware or WCET. The capability rows are harness stubs, so operational timing admission remains disabled until deployed callees are bounded and an independent privileged deadline/watchdog prevents output commit on model error. The dated record is in the fuel-cost artifact; the full table is on the silicon page.

A second thing that was projected is now run. The design has been synthesised, placed and routed for the part the pilot targets: it takes 130 of 208 block RAMs and 6.1% of the logic; the multiplier maps onto dedicated hardware, and 25 MHz closes on every router seed we tried, the worst by 3.6×. Neither the fit nor the closure had been demonstrated by anyone before. The frequencies come from an open toolchain’s timing model, and the board has since run the soft core at up to 96 MHz; the silicon page carries every run and every part we tried.

The older figures of 216, 159 and 376 instructions per tick divided a period by a single dispatch measurement. They are retained as historical workload arithmetic, not current admission limits: instruction mix changes the cost, capability implementations were not included, and the monitor shares the core. MAX_STEP_FUEL remains 1,024, but it is only the platform-independent ceiling on dispatched instructions. A program receives an independently configured tick-credit allowance beneath that ceiling.

The trusted side constructs the effect

The agent names an effect, and the trusted side constructs it. A gate that validates a byte string is validating a field it believes is the amount, the joint index, the destination. Encodings are adversarial: the same bytes mean different things under different parsers, and the attacker chooses the encoding.

The agent supplies an index into a pre-approved intent set and quantised parameters. The gate serialises the transaction or the setpoint itself.

Effects are named, not described

That is the design decision that came directly out of adversarial review, and it replaced an earlier design that inspected agent-supplied bytes.

Quantisation matters as much. We publish the residual: snapping parameters to a coarse grid and emitting on a fixed schedule reduces the bandwidth of any channel an agent might modulate, from arbitrary to countable.

Here is the count. The physical command is a 16-bit PWM at prescaler 8 — about 3,000 distinct steps across a servo's pulse range — emitted on a 50 Hz frame. An agent that owned every commanded position outright could modulate at most log₂(3000) × 50 ≈ 580 bits per second, and less as the intent grid is made coarser than the hardware or the loop runs slower. On the bounty, getting any value out through it, at any rate, is a win.

What is trusted, and what is merely present

A trusted computing base is only meaningful if you enumerate it. Ours is 1206 measured lines, and the parts outside it are listed with equal precision.

Deliberately small, deliberately dull hardware

An in-order RISC-V soft core on an FPGA, running from on-chip memory. No operating system. No DMA engine. No network stack. No cache by default, so timing is predictable and the speculative-execution attack classes do not exist to begin with.

Everything the device can do is visible on the pin map, and that is what makes an independent audit tractable. The I/O surface is specified as the complete effect vocabulary: a serial link in, PWM or step/direction out, a relay drive that sits in series with the existing safety chain, and an SPI secure element holding keys.

Signing runs off the control path entirely. The product record is designed to append events to a hash chain at control rate and periodically sign a chain head; it does not sign every verdict, so signing speed sets how often a head is sealed, not the control rate, and the control loop never waits on it.² The signer is written: a real Ed25519 that builds for the board in under 80 KB with no heap and uses 6.5 KB of stack, its message-building and journal plumbing machine-checked and retained for the source-audit release, its field arithmetic from a Coq-verified backend. The emulated implementation seals its bounded journal on request; continuous durable chaining under a periodic-seal policy is the next milestone.