# How It Works?

Overra Network operates through a structured, deterministic authorization and enforcement flow. Containment is not triggered through administrative credentials or centralized systems. It is authorized cryptographically and enforced locally.

The process follows five stages.

***

### 1. Authority Registration

Each endpoint registers a single wallet as its root authority.

**During setup:**

* The wallet connects to the dApp.
* The public key is recorded by the local agent.
* The device is bound to that authority.

Only this registered wallet can authorize state transitions. No private keys are stored. No centralized accounts are created.

***

### 2. Authorization Request

When containment is required, the user initiates a request through the dApp.

**The system constructs a structured authorization payload containing:**

* Requested action (containment or release)
* Device identifier
* Unique nonce
* Timestamp
* Expiration window

This message is then signed by the registered wallet. The signature proves authority.

***

### 3. Local Verification

The signed payload is transmitted to the local agent.

**The agent verifies:**

* Signature authenticity (Ed25519)
* Authority match
* Nonce uniqueness
* Timestamp validity
* Expiration window compliance

If any validation step fails, the request is rejected.

State does not change.

Verification occurs entirely on the device.

***

### 4. Deterministic State Transition

If verification succeeds, the system transitions state.

**The endpoint operates under a finite model:**

* **NORMAL**
* **CONTAINED**

A valid containment authorization transitions the device from NORMAL to CONTAINED.

A valid release authorization transitions from CONTAINED back to NORMAL.

No partial transitions exist.

***

### 5. Containment Enforcement

Upon state transition, the containment engine executes predefined actions.

**These may include:**

* Restricting network interfaces
* Revoking active sessions
* Freezing designated applications
* Locking the system environment

Actions are predefined and non-extensible. The execution order is deterministic.

***

### 6. Audit Logging

Every authorization attempt successful or rejected is recorded in append-only logs.

**Logs include:**

* Timestamp
* Requested action
* Verification result
* State transition outcome

This ensures traceability and accountability.

***

### Operational Summary

The complete flow can be summarized as:

`Wallet → Signed Authorization → Local Verification → State Transition → Enforcement → Audit Log`

**Containment is therefore:**

* Cryptographically authorized
* Locally verified
* Deterministically enforced
* Transparently recorded

Overra transforms containment from manual reaction into a verifiable security primitive.


---

# 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/how-it-works.md?ask=<question>
```

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.