# Verification Engine The Verification Engine is the cryptographic gatekeeper of Overra. It validates every authorization request before any state transition is permitted. No containment action may execute without passing this verification pipeline. All verification occurs locally within the Rust-based agent. *** ### Verification Objectives **The Verification Engine ensures that:** * Authorization originates from the registered wallet. * The request has not been replayed. * The request is time-bound and valid. * The payload has not been modified. * The request applies only to the bound endpoint. If any validation step fails, the request is rejected and state remains unchanged. *** ### Verification Pipeline **Each authorization request undergoes the following validation sequence:** 1. Payload parsing 2. Signature verification 3. Authority matching 4. Nonce validation 5. Timestamp validation 6. Expiration window enforcement Validation is sequential and deterministic. Failure at any stage terminates the process. *** ### 1. Payload Parsing The agent first parses the structured authorization payload. **The payload must:** * Contain all required fields * Follow expected schema * Include valid data types Malformed or incomplete payloads are rejected immediately. *** ### 2. Signature Verification Overra uses Ed25519 for digital signature validation. **The agent verifies:** `Verify(public_key, message, signature) → Boolean` **If verification returns false:** * Authorization is rejected * No state mutation occurs * Event is logged This step ensures authenticity and integrity. *** ### 3. Authority Matching The public key used to verify the signature must match the registered authority. **If the public key differs:** * Authorization is rejected This prevents cross-device authorization reuse and unauthorized control. *** ### 4. Nonce Replay Protection Each authorization request includes a unique nonce. **The agent:** * Checks if nonce exists in the nonce store * Rejects request if nonce has been used * Stores nonce if verification continues The nonce store persists across restarts. This prevents replay attacks. *** ### 5. Timestamp Validation The payload includes a UNIX timestamp. The agent validates that: The timestamp is within acceptable bounds of system time. Requests with invalid or unreasonable timestamps are rejected. *** ### 6. Expiration Window Enforcement Each authorization includes an expiration window in seconds. **The agent verifies:** CurrentTime ≤ Timestamp + Expires Expired authorizations are rejected. This prevents delayed execution of previously signed requests. *** ### Deterministic Approval **If all verification checks succeed:** * The request is approved * The state controller is invoked * A state transition may occur **If any check fails:** * The request is rejected * The state remains unchanged * A log entry is created There are no partial approvals. *** ### Failure Handling **On verification failure:** * No containment actions execute * No state mutation occurs * The event is logged with failure reason Failure does not degrade system integrity. *** ### Security Guarantees **The Verification Engine guarantees:** * Only the registered wallet can authorize containment * Replay attacks are prevented * Expired authorizations cannot execute * Malformed payloads are rejected * Authorization is bound to a specific device Verification is independent of centralized services. The enforcement boundary remains local and deterministic. *** ### Engine Summary The Verification Engine transforms wallet signatures into enforceable authority. **It ensures that containment is:** * Cryptographically valid * Time-bound * Replay-resistant * Deterministic Without successful verification, containment cannot occur. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://overra.gitbook.io/overra-docs/architecture-technical-core/verification-engine.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.