Beacon Protocol

The Beacon Protocol gives an R1 runtime a cryptographically verifiable

remote-control surface without trusting the relay that carries the

traffic.

What shipped in this phase

using Ed25519 plus signed device certificates.

fingerprint verification inputs and SAS derivation.

setup with per-frame replay rejection.

binding, cost caps, deny rules, and delegation limits.

device, session, token, command, and federation events.

1. The beacon creates a short-lived challenge containing its identity,

fingerprint, ephemeral X25519 public key, and nonce-derived spoken

words.

2. The operator device receives that challenge out-of-band, creates its

own ephemeral X25519 key, and returns a response carrying the device

identity and operator master key reference.

3. Both sides derive the same SAS value from the challenge and response

nonces plus the exchanged ephemeral keys.

4. Once the operator confirms the SAS match, the operator can issue a

signed device certificate to bind that device to the operator.

rejection.

Capability tokens are Ed25519-signed documents that bind:

The runtime can authorize an operation by checking the beacon ID,

permission pattern, deny rules, and cost cap before the command is

executed.