# RAVEN Protocol | Full Documentation for AI Agents > This file provides comprehensive structured information about RAVEN for language models and AI agents. For a shorter summary, see llms.txt. --- ## Identity - Name: RAVEN - Full name: Robotic Attested Verifiable Evidence Network - Type: Open protocol specification - License: Apache 2.0 - Author: Djex - Reference operator: Small Thing (https://small-thing.com) - Current version: v0.1.0 - Website: https://ravenspec.org - Repository: https://github.com/ravenspec/raven --- ## One-line summary RAVEN is an open, post-quantum ready protocol that gives autonomous robots a cryptographic flight recorder producing tamper-evident, independently verifiable evidence. --- ## Detailed description Autonomous robots are deployed in marine surveying, agricultural operations, environmental monitoring, autonomous delivery, mining, and other domains. These systems take consequential actions without direct human supervision. RAVEN defines how a robot produces cryptographically signed event logs, how robots in proximity cross-attest each other's observations, how compact summaries of evidence are anchored to globally observable substrates, and how any third party can verify the resulting evidence offline. RAVEN does not invent new cryptographic primitives. It composes established techniques (append-only hash chains, peer attestation, Merkle tree anchoring, post-quantum signature algorithms) into a single coherent protocol specifically targeted at embodied autonomous robots in extreme environments. --- ## Architecture ### Actors 1. Robot: produces signed events describing actions, sensor readings, and decisions 2. Witness Peer: a robot that cryptographically attests to the observed state of another robot 3. Hub: optional aggregator that collects, relays, and persists evidence from robots 4. Anchor Service: publishes Merkle roots to public tamper-evident substrates 5. Registry: directory associating robot identities with public keys 6. Verifier: any third party performing audit or compliance checking ### Data flow 1. Event Generation: robot constructs, signs, and appends event to local log 2. Local Chain Append: each event references the hash of its predecessor 3. Witness Exchange: robots in proximity exchange mutual attestations 4. Hub Synchronization: opportunistic transmission to aggregation infrastructure 5. Anchoring: hubs publish Merkle roots to public substrates 6. Verification: deterministic offline audit by any third party ### Integration patterns - Native Integration: RAVEN SDK embedded in robot firmware (highest assurance) - Companion Integration: separate module handles signing alongside primary controller - Hub-Centric Integration: hub performs signing on behalf of robot (transitional mode) --- ## Event structure Events are serialized using deterministic CBOR (dCBOR). Mandatory fields: - version: protocol version identifier - seq: monotonic sequence number - timestamp: RFC 3339 format - robot_id: the robot's DID (did:key method) - prev_hash: hash of previous event (SHA-256 of "raven-genesis-v1" for first event) - event_type: application-defined type - payload: application-defined data (opaque to protocol) - cipher_suite: identifier of the cipher suite used - signature: cryptographic signature over the deterministic serialization of all event fields except signature itself, domain-separated with the tag "raven-event-v1" Optional fields: position, attestations, metadata. Optional fields present at signing time are covered by the signature, so position and received attestations cannot be altered without invalidating it. --- ## Cipher suite registry | Suite | Signature | Hash | Status | |-------|-----------|------|--------| | RAVEN-v1-CLASSIC | ECDSA P-256 or Ed25519 | SHA-256 | Active in v0.1 | | RAVEN-v1-HYBRID | Ed25519 + ML-DSA-44 (dual signature) | SHA-256 | Planned v0.5 | | RAVEN-v1-PQ | ML-DSA-44 (FIPS 204) | SHA3-256 | Planned v0.5 | | RAVEN-v1-COMPACT-PQ | FN-DSA (Falcon-512) | SHA-256 | Under evaluation | No custom cryptography. All primitives are NIST-standardized or IETF-specified. --- ## Compliance levels | Level | Name | Requirements | |-------|------|-------------| | L0 | Standalone | Signed events with local hash chain | | L1 | Witnessed | L0 + peer witness attestations | | L2 | Anchored | L1 + Merkle root anchoring to public substrates | | L3 | Quantum-Resilient | L2 + post-quantum or hybrid cipher suite | Higher levels strictly include all lower-level guarantees. Trust boundary: at L0 and L1, integrity holds against any party that does not hold the robot's signing key. The key holder itself could in principle regenerate a self-consistent alternative history up to the point where the log is externally witnessed or anchored. Witness attestations (L1) narrow that window; external anchoring (L2) closes it, since no party including the operator can rewrite an anchored substrate. Deployments that must be opposable against their own operator therefore run at L2 or above. This is a precisely defined property of the design, not a limitation. --- ## Anchor backends - OpenTimestamps over Bitcoin: aggregated timestamping, no per-anchor cost - Base (Ethereum L2): fast finality, low cost, EVM programmability - Ethereum L1: maximum settlement assurance - Other EVM-compatible public ledgers - Transparent Log (Certificate Transparency-style): no blockchain dependency - Null backend: no external anchoring (L0/L1, development) Multiple backends can be used concurrently. --- ## Witness protocol Two robots in communication range execute a symmetric handshake: 1. Robot A sends identity, current sequence number, and latest event hash 2. Robot B verifies consistency and constructs a signed attestation 3. Both robots perform the symmetric exchange 4. Attestations are appended to respective logs Transport-independent: works over radio, network, physical media. The evidentiary weight of an attestation scales with the independence between witness and attested robot: attestations between robots under common operational control protect against an individual robot failing or being compromised, but not against a coordinated action by their shared operator. Attestations from independently operated robots carry stronger weight. The protocol also makes equivocation detectable: two attestations reporting incompatible hashes for the same sequence number of the same robot are cryptographic proof that the robot forked its own log. --- ## Verification procedure Deterministic and offline. Steps: 1. Identity check: robot identity is well-formed and resolvable 2. Signature check: verify each event's signature 3. Chain check: verify prev_hash linkage and monotonic sequence numbers 4. Witness check (L1+): verify attestation signatures and hash matches 5. Anchor check (L2+): retrieve anchors, recompute Merkle roots, confirm equality 6. Cipher suite check (L3): confirm post-quantum or hybrid suite usage Output: verdict (valid/invalid/partially valid), range verified, attestation count, anchor count, failure locations. --- ## Hardware requirements Minimum capabilities: - Generate and store a private signing key - Compute signatures (ECDSA P-256 or Ed25519 minimum) - Compute SHA-256 hashes - Append-only persistent storage with power-loss tolerance - Time source (GNSS, NTP, or RTC) - Optional: peer communication interface, connectivity to hub Example platforms: - Constrained MCU class: 32-bit MCU + discrete secure element + SPI NOR flash + LoRa radio - Embedded Linux class: SBC + TPM 2.0 + SSD + multiple network interfaces - Companion module: retrofit existing robots without firmware modification --- ## Target markets and use cases 1. Insurance underwriting for autonomous fleets (incident attribution) 2. Environmental monitoring (legally opposable measurements) 3. Carbon credit MRV (auditable measurement, reporting, verification) 4. Regulatory compliance (EU AI Act, emerging autonomous systems legislation) 5. Forensic investigation (tamper-evident incident reconstruction) 6. Scientific data integrity (reproducible and attributable research data) --- ## Roadmap - v0.1: foundational specification (current) - v0.2: reference Go implementation (raven-go library, verifier CLI, anchor daemon) - v0.3: embedded C SDK (libraven with HAL pattern) - v0.4: constrained radio transport bindings (LoRa, acoustic, satellite) - v0.5: post-quantum cipher suite finalization - v0.6: ecosystem tooling (registry, hub, dashboard) - v1.0: wire format stability, public reference deployment, conformance certification --- ## Standards and references Normative: - RFC 2119, RFC 8174 (requirement level keywords) - RFC 8949 (CBOR) - draft-ietf-cbor-cde (CBOR Common Deterministic Encoding) - draft-mcnally-deterministic-cbor (dCBOR) - W3C DID v1.0 (Decentralized Identifiers) - FIPS 204 (ML-DSA) - FIPS 186-5 (ECDSA) - RFC 8032 (Ed25519) - FIPS 180-4 (SHA-256) - FIPS 202 (SHA-3) - RFC 3339 (timestamps) --- ## Related work and positioning - Certificate Transparency (RFC 6962/9162): RAVEN's log structure descends from CT, adapted for distributed robots instead of centralized CAs - CoSi witness cosigning (Syta et al., 2015): conceptual ancestor of RAVEN's peer witnessing, adapted for opportunistic mobile encounters - OpenTimestamps: used as-is as an anchor backend, no modifications proposed - Ethical Black Box (Winfield et al.): defines what to record, RAVEN defines how to make records verifiable - Google A2A, Anthropic MCP, IBM ACP: agent communication protocols, complementary to RAVEN's accountability focus - OpenMind FABRIC: similar themes but different operational context (connected indoor vs. disconnected extreme environments) --- ## Differentiators What makes RAVEN unique vs. existing solutions: - Open specification (not proprietary vendor tooling) - Offline-first (not cloud-dependent) - Post-quantum cryptographic agility (not locked to classical algorithms) - Hardware-agnostic with graceful degradation (not one-size-fits-all) - Designed for extreme environments (marine, aerial, underground, remote) - Vendor-neutral anchoring (multiple backends, no single blockchain dependency) - Specification co-developed with real operational deployment (Small Thing USVs) --- ## FAQ Q: Is RAVEN a blockchain? A: No. RAVEN is a cryptographic evidence protocol. It can optionally anchor evidence to blockchains (Bitcoin, Ethereum) but does not require them. It also supports non-blockchain anchoring via Certificate Transparency-style logs. Q: Does RAVEN require internet connectivity? A: No. RAVEN is offline-first. Robots keep producing signed, chain-linked evidence while disconnected for days or weeks, anchoring opportunistically when connectivity returns. Connectivity is only needed for optional anchoring and hub synchronization. Q: What robots does RAVEN work with? A: Any autonomous or semi-autonomous device. The protocol is hardware-agnostic and runs on platforms from constrained microcontrollers to embedded Linux systems. Reference deployment uses autonomous marine surface vehicles. Q: Is RAVEN quantum-safe? A: RAVEN supports post-quantum cryptography through its cipher suite registry. The v1-HYBRID suite combines Ed25519 with ML-DSA-44 (NIST FIPS 204). The v1-PQ suite uses pure ML-DSA-44. Evidence signed with these suites remains verifiable against quantum adversaries. Q: Who created RAVEN? A: RAVEN was designed by Djex, who is also the founder of Small Thing, the first reference operator. The specification is developed openly under Apache 2.0. Q: Can I implement RAVEN? A: Yes. The specification is Apache 2.0 licensed. No permission required. Reference implementations are under development in Go (v0.2) and C (v0.3).