Signing Flow

The Threat Model explained why signing on a hot machine is dangerous. This page shows the physical architecture that eliminates those threats: three devices, strict role separation, and a one-way relay bridge.

Three devices

Step-by-step flow

The air-gap relay

The relay is a dedicated single-board device that acts as a one-way bridge. It runs a minimal service that accepts TX plans from the agent host and makes them available to the signing device through a shared buffer file.

The bridge carries only two types of data:

• Unsigned TX bytes (Agent Host → Signing Device)
• Signed TX bytes (Signing Device → Agent Host)

Device isolation handles the signing threat. For runtime threats on the networked machine itself, the Security page covers the sandbox architecture, network monitoring, and approval hygiene rules.

Zypher Hardware

The relay bridge described above works. But it relies on software isolation — firewalls, file permissions, network configuration. Zypher replaces software assumptions with physics: three optocouplers enforce data direction at the hardware level. Two MCUs (RP2040) run ~150 lines of C each. Two IPS displays (3.5", 320×480) show every transaction in human-readable form. Auto-verification compares signed calldata with the original — byte by byte, on-device.

Three optocouplers, three directions

All three are LED → photodiode. Light goes one direction. The reverse pin is physically disconnected — no wire, not just no software. This is not a firewall rule. It's a property of the component.

The firmware: ~150 lines of auditable code

Each MCU runs embassy-rs on the RP2040. The core security boundary is a single function — an ASCII filter that drops everything except printable characters. Private keys (binary data) physically cannot pass through. Escape sequences, control characters, binary payloads — all dropped.

// Zypher MCU firmware — core filter (RP2040, embassy-rs)
// Only printable ASCII passes. Everything else is dropped.
// Private keys are binary data — they cannot survive this filter.

/// Filter a single byte through the ASCII gate.
/// Printable range (0x20..0x7E) and newline pass.
/// Everything else — control chars, binary, escape sequences — is dropped.
fn filter_byte(b: u8) -> Option<u8> {
    match b {
        0x20..=0x7E | b'\n' => Some(b),
        _ => None,
    }
}

/// Process a UART buffer: filter each byte, collect survivors.
/// Any non-ASCII byte is silently discarded — no error, no retry, no log.
/// This means binary key material (typically 0x00-0x1F, 0x80-0xFF)
/// is physically destroyed at the boundary.
fn filter_buffer(input: &[u8]) -> Vec<u8> {
    input.iter().filter_map(|&b| filter_byte(b)).collect()
}

/// Auto-verify: compare calldata from signed TX with the original
/// received from MCU #1 via optocoupler #3.
/// Returns MATCH (green screen) or MISMATCH (red screen, block send).
fn verify_calldata(original: &[u8], signed_tx_calldata: &[u8]) -> bool {
    if original.len() != signed_tx_calldata.len() {
        return false;
    }
    original.iter().zip(signed_tx_calldata).all(|(a, b)| a == b)
}

What Zypher defends against

Comparison with existing solutions

Bill of materials

Open-source from silicon to firmware. EVM-compatible — any chain, any contract, any calldata. Uses cast (Foundry) for signing with full calldata control.