Security

​

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.

• Report delivered: October 3, 2025
• Audit window: July 16 → August 15, 2025
• Audited commit: 970ec76

​

Download the report

• Levery Security Audit Report

​

Audit scope (in-scope contracts)

• src/Levery.sol
• src/CompliantRouter.sol
• src/SoulboundPositionManager.sol
• src/utils/PermissionManager.sol
• src/utils/BaseSwapRouterPermit2.sol
• src/utils/PositionDescriptor.sol
• src/libraries/Descriptor.sol

---

​

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)

​

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. 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.

---

​

Next pages

• Architecture — components, trust boundaries, and execution flow
• Admin Guide — governance and operational controls for production deployments