Skip to content

Components

The Vero Protocol is decomposed into 15 components, each with an explicit contract: typed inputs and outputs, invariants written as testable MUST statements, and a fixture set an implementation can run to prove conformance. Components let implementers adopt Vero piecewise — and let the protocol evolve one contract at a time instead of rebuilding from the ground up.

Component kinds

Different kinds of components get different contract styles. Forcing one style onto all of them produces contracts that are either vacuous or obstructive.

Kind Contract style Conformance style
Codec — pure, deterministic Exact input/output specification Golden fixtures: language-neutral JSON, exact assertions
Capture — device-bound Output format + minimum quality gate Recorded-session fixtures; thresholds, not exactness
Transport — message flow Message schemas + state machine Session-transcript fixtures
Control loop — adaptive Messages normative; tuning informative Replayed calibrations; convergence bounds
Policy — configurable judgment Versioned profiles + threshold tables Decision-table fixtures: given scores → verdict

The codec components are the protocol's spine — locked hardest, with fixtures that survive any implementation rewrite. Capture components deliberately get looser contracts: that is where implementations should keep improving without protocol changes.

The component map

# Component Role Kind Specification
C1 Session Key Creator Verifier Codec Cryptography
C2 Session Key Encryption Verifier Codec Cryptography
C3 Trust Anchors (optional, post-V1 profile) Both Policy
C4 Relay Infrastructure Transport Session Protocol
C5 Environmental Detection & Calibration Joint Control loop Session Protocol
C6 Key & Parameter Transmission Verifier Transport Session Protocol
C7 Facial Scan (3D) Presenter Capture Entangled Vector
C8 Blink Encoder Presenter Codec + capture Signal Protocol
C9 3D Data Capture Presenter Capture Entangled Vector
C10 Packager Presenter Codec Session Protocol
C11 Facial Scan (2D) Verifier Capture Comparison & Decision
C12 Blink Decoder Verifier Codec Signal Protocol
C13 3D Data Interpreter Verifier Codec Comparison & Decision
C14 The Verifier Verifier Policy + codec Comparison & Decision
C15 Entangler Presenter Codec Entangled Vector

Notes on the load-bearing components

C1/C2 — two different "session keys"

The protocol uses two distinct key objects, and implementers must not confuse them. The session secret is 256-bit ECDH/HKDF material that encrypts and authenticates everything in transit. The optical challenge is a short value (default 20 bits) derived from the session secret and blinked as light — short because the optical channel is slow. The challenge's entropy defends against precomputation, not brute force; the defense against real-time synthesis is the decoder's realism and timing evidence (C12), not challenge length.

C4 — the relay is an interface, not a service

The relay is specified like TURN/STUN: message schemas, session state machine, and zero-knowledge guarantees. Anyone can host one. The reference deployment is exactly that — a reference. Zero biometric data transits the relay.

C8 — deterministic emission with a start gate

Emission MUST NOT begin while the presenter's eye is detected looking at the screen. Once begun, timing follows the Signal Protocol deterministically — the start is event-gated, the sequence is not.

The decoder proves the session key's light sequence is genuinely present in the verifier's own view of the presenter. Two conformance tiers:

  • Tier 1 — Independent extraction. Decode the key from the video knowing only the blink parameters; compare the result to the known key afterward. The protocol's pure form.
  • Tier 2 — Correlation with decoy margin. Correlate against the expected sequence; the result is valid only when the true key's score beats N decoy wrong-key sequences by the specified margin. The decoy panel is what makes a matched filter evidentiary rather than confirmatory.

Every session reports its achieved tier. V1's passing bar is Tier 2.

C15 — the Entangler

The presenter-side output contract. Face embedding (128 dims), depth features (32 dims), and light response (71 dims) are fused into a single 231-dimension vector and rotated by a session-key-derived orthogonal matrix. The entangled vector is the only biometric-derived artifact that leaves the device, and it is cryptographically bound to its session. C10 (Packager) then applies envelope encryption and transport framing — nothing more.

The contract template

Every component section in the specifications follows one skeleton:

## Cn: <name>
Role:        presenter | verifier | joint | infrastructure
Kind:        codec | capture | transport | control | policy
Inputs:      typed, with provenance — which component produced each
Outputs:     typed; capture components include the quality gate
Invariants:  testable MUST statements
Fixtures:    conformance/<component>/ — what a passing implementation proves
Version:     pinned by the protocol version

One protocol version pins the complete set — crypto suite, signal encoding, vector layout, model version, thresholds, and message schemas. Components iterate internally; interoperability is declared at a single number. Model weights are versioned protocol artifacts, pinned by hash: two implementations produce comparable vectors only with identical weights and preprocessing.