The Problem: Software Is Brittle

Imagine you're designing a financial trading system, a power plant controller, or any safety-critical device. You want to enforce hard constraints: never exceed this position size. Never enter this mode without authorization. Never write to this register.

Software can enforce these rules—if the code is correct. But code is bugs. Bugs are exploitable. A single memory corruption, a single logic error, and your constraint is violated.

What if, instead of trusting software, you built the constraint into the hardware itself? A rule that cannot be violated, because the silicon physically prevents it?

This is the concept of hardware interlocks: governance gates implemented in FPGA fabric or custom silicon, where the hardware itself is the enforcement mechanism.

The Interlock Pattern

A hardware interlock is a finite state machine that:

  1. Verifies preconditions – checks that the system is in a safe state
  2. Locks critical resources – prevents certain operations unless conditions are met
  3. Enforces state transitions – ensures you can't skip steps or go backwards
  4. Generates proof – creates a cryptographic record of decisions

Example: a circuit breaker that prevents capital deployment unless a series of checks have passed:

```verilog module circuit_breaker ( input clk, reset, input [31:0] risk_score, input [63:0] capital_available, input check_passed, // From external validation

output reg can_deploy, output reg [63:0] max_position_size );

// State machine reg [2:0] state; localparam IDLE = 0, WAITING = 1, CHECKED = 2, ARMED = 3, LOCKED = 4;

always @(posedge clk) begin if (reset) begin state <= IDLE; can_deploy <= 0; max_position_size <= 0; end else begin case (state) IDLE: begin can_deploy <= 0; if (capital_available > 0) state <= WAITING; end

WAITING: begin // Wait for external check if (check_passed) state <= CHECKED; end

CHECKED: begin // Verify risk score if (risk_score < 32'd1000) begin state <= ARMED; can_deploy <= 1; // Compute max position as 5% of capital max_position_size <= capital_available / 20; end else begin state <= IDLE; // Risk too high, reset end end

ARMED: begin // Once armed, cannot go back without external command if (capital_available == 0) begin state <= LOCKED; can_deploy <= 0; end end

LOCKED: begin // Final state: cannot deploy can_deploy <= 0; end endcase end end

endmodule ```

This interlock enforces:

A software bug that tries to set `can_deploy = 1` without going through the state machine will fail—the hardware path doesn't exist.

Multi-Gate Hierarchical Governance

Real systems need multiple independent gates, not just one. The pattern scales:

```verilog module governance_stack ( input clk, reset, input [31:0] proposal_id, input [63:0] proposal_data,

// Individual gate signals output gate_1_pass, output gate_2_pass, output gate_3_pass,

// Master enable (only high if all gates pass) output can_execute );

gate_risk_limit g1 ( .clk(clk), .reset(reset), .data_in(proposal_data), .gate_pass(gate_1_pass) );

gate_auth_check g2 ( .clk(clk), .reset(reset), .proposal(proposal_id), .gate_pass(gate_2_pass) );

gate_policy_check g3 ( .clk(clk), .reset(reset), .data_in(proposal_data), .gate_pass(gate_3_pass) );

// Master: ALL gates must pass assign can_execute = gate_1_pass & gate_2_pass & gate_3_pass;

endmodule ```

Each gate is independent. If any gate fails, the whole chain fails. This mirrors the security principle: defense in depth. No single component can grant access; all must agree.

FPGA vs. Custom Silicon

FPGA Implementation:

Custom Silicon (ASIC):

For most applications, FPGA interlocks are sufficient. The speed difference (1 ns vs. 0.1 ns) matters only if your gate logic is in the critical path of every transaction. For governance (which typically checks once per operation, not per bit), FPGA latency is negligible.

Cryptographic Proof: Linking Hardware to Trust

A hardware interlock is useless if the results aren't trustworthy. How do you prove that a gate actually evaluated a condition correctly?

HMAC-based proof:

```verilog module gate_with_proof ( input clk, reset, input [63:0] data_in, input [255:0] hmac_key,

output gate_pass, output [255:0] proof_hash );

// Compute gate decision wire gate_decision = (data_in < 32'd1000); assign gate_pass = gate_decision;

// Compute HMAC(key || data_in || decision || timestamp) wire [511:0] proof_data = {hmac_key, data_in, gate_decision, clk_counter[31:0]}; sha256_hmac u_hmac ( .data(proof_data), .key(hmac_key), .hash(proof_hash) );

endmodule ```

Every gate evaluation produces a proof hash. That hash is sent to external software (or another hardware module) for verification. If someone claims the gate said "yes" but the hash doesn't match, you know they're lying.

This creates an audit trail: proof of every decision, signed by the hardware.

Real-World Application: Financial Position Limits

Consider a trading system with these constraints:

Each gate is a small FPGA module. When new position is proposed:

  1. Gate 1 checks size against capital
  2. Gate 2 recomputes total leverage
  3. Gate 3 checks sector concentration
  4. Gate 4 verifies stop-loss exists

All four must pass. If any fails, the position is rejected at the hardware level. Software can try to override, but the output wire stays low—the position never actually executes.

A hardware engineer audits the gates once. Then you can have bugs in the trading logic, the risk engine, even the data pipeline—but positions will never violate the hard constraints. The gates are orthogonal to the business logic. They don't care how you make decisions; they only care that the decisions don't violate constraints.

Timing and Latency

Hardware gates add latency. A 4-gate stack with HMAC proof:

For a trading system that makes decisions every millisecond, 6 µs is negligible. For a microsecond-scale HFT system, it's a problem.

Solutions:

Lessons for Hardware Governance

  1. Interlocks are not a magic bullet. They prevent certain classes of bugs (state machine violations, register overwrites). They don't prevent algorithmic errors.
  1. Design gates independently. Each gate should be ignorant of the others. This allows composition and reduces interdependency bugs.
  1. Cryptographic proofs are mandatory. Without them, external software can't trust the gate output. With them, you have an audit trail.
  1. Test corner cases obsessively. A gate that passes 99% of the time and fails 1% of the time is worse than no gate—it gives false confidence.
  1. Combine hardware interlocks with software contracts. Hardware prevents the impossible. Software documents the intended behavior.

The metaphor is apt: a hardware interlock is like a circuit breaker in an electrical panel. The breaker can't prevent an electrical code violation in the wall wiring, but it can prevent the house from burning down when something goes wrong. It's a last-resort safety device, not a substitute for good design.

For systems where the consequences of failure are high—financial loss, safety risk, integrity violation—hardware interlocks are no longer optional. They're essential infrastructure.