> ## Documentation Index
> Fetch the complete documentation index at: https://docs.levery.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> Explore our guides and examples to get the most out of Levery.

## Security-first, audit-backed

Levery is designed for regulated environments where **authorization**, **controls**, and **auditability** are non-negotiable.
Security is treated as an explicit, governable part of the system: enforcement happens **before state changes**, ownership is
**strongly bound**, and configuration changes are **observable and reviewable**.

***

## Independent security audit

Levery’s smart-contract suite has been audited by **Runtime Verification**, a security firm recognized for combining conventional
audit techniques with **mathematically grounded methods** (including property-oriented analysis and symbolic execution) to validate
critical system behavior.

### Download the report

* **[Levery Security Audit Report](https://amp.runtimeverification.com/public-report/levery)**

***

## Trusted ledger safeguards

Levery inherits core properties of on-chain execution that materially reduce institutional risk:

* **Atomic settlement:** actions either settle fully or revert with state unchanged.
* **Deterministic execution:** identical inputs produce identical outcomes across validators.
* **Tamper-evident history:** validation, transfers, and accounting are permanently recorded, enabling post-event reconstruction.

This removes common counterparty and reconciliation failure modes found in intermediated execution paths. Residual risks become
**programmatic**, which makes them measurable, testable, and governable through explicit controls.

***

## Global security standard

Levery’s posture is built around **explicit invariants** and **fail-closed** behavior under abnormal conditions.

### Invariant 1 — Authorization precedes state change

Every swap or liquidity mutation is gated by authorization and policy checks **before any state transition**. If a precondition fails,
execution reverts and leaves state unchanged.

Typical preconditions include:

* entry through an approved execution surface (router / position manager)
* deterministic identity extraction from request data
* permission and (optional) pool-required role validation
* global and pool-level pause checks

### Invariant 2 — Liquidity ownership is strongly bound

Liquidity positions are issued as **non-transferable (soulbound) tokens**, binding ownership to verified entities and preventing
unauthorized transfer of liquidity rights.

Security impact:

* prevents unapproved secondary transfers of LP ownership
* supports institutional governance and entity-level policies
* enables deterministic ownership attribution in monitoring, risk, and audit tooling

### Invariant 3 — Oracle-informed guardrails (optional)

Oracles, when configured, provide inputs for deviation guardrails and fee dynamics. Oracle policy is security-relevant and should be
treated as governed configuration:

* acceptable oracle sources per pool
* freshness expectations and staleness policy
* incident response procedures (pause/rotate/fallback)

<Warning>
  Oracle inputs can affect execution quality and market behavior. Treat oracle configuration as a monitored control
  surface with a documented playbook.
</Warning>

### Invariant 4 — Bounded fee dynamics

Fees are expressed in **parts-per-million (ppm)** and bounded by design.

A useful mental model:

$$
F_{dynamic} = clamp\big(F_{base} + \alpha \cdot deviation,\ 0,\ MAX\_PPM\big)
$$

Where:

* `MAX_PPM = 1,000,000` (100%)
* `F_base` is the configured baseline fee (global or per pool)
* `α` is the deviation factor
* `deviation` is derived from pool vs. oracle price (when enabled)

This keeps fee behavior predictable and reviewable even under extreme inputs.

### Invariant 5 — Circuit breakers enforce fail-closed behavior

Levery supports operational circuit breakers designed for rapid containment:

* **Global pause** (protocol-level emergencies)
* **Per-pool pause** (venue-specific incidents such as oracle anomalies, asset risk, abnormal market conditions)

When paused, the system behaves **fail-closed**: user actions that would mutate state do not proceed.

### Invariant 6 — Deterministic arithmetic and rounding

Arithmetic and rounding behavior is handled deterministically to prevent ambiguous outcomes and to support reproducible post-event analysis.

***

## Trust boundaries and governance surface

A secure deployment starts with a clear model of trust boundaries: settlement vs. policy vs. external inputs vs. administration.

<Mermaid
  chart={`flowchart LR
subgraph settlement ["Settlement"]
CORE["AMM settlement & accounting"]
end

subgraph policy_enforcement ["Policy Enforcement"]
POLICY["Levery policy & fee logic"]
PERM["Permission registry"]
end

subgraph external_inputs ["External Inputs"]
ORC["Oracles (optional)"]
end

subgraph operations ["Operations"]
ADM["Admin keys / multisig"]
VAULT["Fee vault / distribution"]
end

PERM --> POLICY
ORC --> POLICY
ADM --> POLICY
POLICY --> CORE
POLICY --> VAULT
`}
/>

A practical governance question follows immediately:

> Who can change policy inputs, and how quickly can the institution detect and respond to abnormal configuration or inputs?

***

## Operational security

Levery is designed to be **governed**, not “set and forget.” Security-sensitive configuration should follow production change-management.

### Separation of duties

A strong baseline for institutional deployments:

* **Provider authority:** protocol-level controls, critical address management, global policy, emergency procedures
* **Institution authority:** pool configuration, venue-level toggles, role definitions, market parameters
* **Compliance operator:** permission assignment and entitlements, ideally isolated from fee/pool parameter control

### Key management

Recommended production posture:

* multisig for privileged roles with explicit signing policy
* hardware-backed keys and least-privilege access
* periodic access review and key rotation procedures

### Incident response

Have tested playbooks for:

* oracle incident → pool pause + oracle rotation/fallback
* abnormal execution patterns → pause + investigation + rollback
* admin key compromise → emergency pause + key rotation

***

## Continuous monitoring and attestations

Because policy enforcement and parameter changes are committed on-chain, institutions can rely on **verifiable evidence** rather than assertions.

Monitor continuously:

* permission/role changes (who / what / when)
* pool configuration changes (fees, oracle assignments, pause state)
* circuit-breaker activations and limit breaches
* fee routing flows (recipients + amounts)
* abnormal revert rates and execution anomalies

This enables:

* automated alerts and compliance dashboards
* automated attestations (e.g., “only approved entities interacted with pool X during period Y”)
* precise post-event reconstruction for risk committees and supervisors

***

## Scope and non-goals

Levery’s on-chain security model does **not** replace:

* custody and key management products
* identity provider integrity and AML screening guarantees
* infrastructure hardening (RPC, indexing, hosting)
* endpoint/device security (phishing, malware, account compromise)

Levery’s role is to provide **deterministic enforcement and auditable execution**, integrating cleanly into institutional controls.