- Permissioned access: only eligible accounts can trade in restricted pools.
- Compliant settlement: swap proceeds can only be received by the initiating wallet.
- Deterministic execution: the platform enables swapping only when it can compute an on-chain quote for the exact trade context.
- Audit-ready outcomes: every trade is traceable to a transaction hash, logs, and canonical pool state.
Trade screen

Swap panel
Select a pool, choose direction, enter amounts, review fees and gas, then execute the swap. The swap button is enabled only when an on-chain quote is available and the account passes policy checks.
Assets info
Asset profiles with project description, market/supply metrics, 24h change, and pricing sourced from trusted market price oracle feeds, enabling informed, accountable trading decisions.
Pool picker (pair + network)
Pools are identified by pair + network and may include pool-specific rules (fee behavior, oracle configuration,
and access policies). When the user select a pool, the Trade page binds the user’s session to that pool’s parameters.
What Levery guarantees during execution
Permissioned trading
Swaps execute only when the connected account meets the institution’s pool admission rules, including roles, compliance status, and any operator-defined access constraints.
Compliant settlement
Settlement is bound to the initiating account. The compliant router prevents proceeds from being redirected to
arbitrary recipients, ensuring custody and accounting controls remain intact.
On-chain determinism
Trades are enabled only when an on-chain quote can be produced and the submitted transaction matches the same pool
parameters and account context used for enforcement and pricing.
Levery separates execution correctness (on-chain quote + enforced checks) from display convenience (fiat
conversion and informational metrics). A UI estimate is never sufficient to enable execution on its own.
Execute a swap
Select a pool (pair + network)
The user opens the pair selector at the top of the swap card and selects a pool.A pool defines:
- the two assets,
- the network,
- the fee behavior (static or dynamic),
- and the permission policy that applies to swaps.
Choose direction (From → To)
The user selects the asset to spend in From and the asset to receive in To, and may use the flip control to reverse direction.Direction matters because fee logic, oracle deviation rules, and policy constraints can be direction-sensitive.
Choose an execution intent (Exact input or Exact output)
Levery supports two trade intents:
- Exact input: the user specifies the From amount. The platform computes an estimated output subject to slippage protection.
- Exact output: the user specifies the To amount. The platform computes an estimated maximum input subject to slippage protection.
Wait for an on-chain quote (required)
The Trade page continuously requests an on-chain quote for the selected pool, direction, and amounts. This quote is produced by simulating the swap against the pool’s current state and enforcement rules.Typical states include:
- Quoting…: the UI is fetching or refreshing a quote.
- Ready: a valid quote is available and the swap button can be enabled.
- Estimate only (swap disabled): the UI may show an indicative estimate, but execution is blocked because a deterministic on-chain quote is not available.
Fiat prices and indicative estimates can still be shown. However, execution is enabled only when Levery can reproduce the trade deterministically on-chain under the same context used for enforcement.
Review fees and gas before submitting
Review the badges below the inputs:
- Total fees: the estimated aggregate of LP fee and service fee for this trade intent and direction.
- Gas estimate: the network fee estimate (in the chain’s native token and converted to fiat for convenience).
Final gas paid depends on network conditions. Final fees depend on the pool’s on-chain execution rules and the exact deltas realized during the swap.
Approve spend permissions (if required)
If the input asset is an ERC-20 token, approvals may be required before swapping.Many Levery deployments use a hardened allowance model:
- Token → Permit layer approval (authorizes the permit contract to move tokens)
- Permit layer → Router approval (authorizes the compliant router to spend under strict rules)
Execute the swap and confirm the receipt
The user selects Swap and confirms the transaction in the connected wallet.After submission, the Trade page tracks the transaction until it is confirmed and then displays a receipt including:
- amount paid,
- amount received,
- fees charged,
- gas paid,
- and a link to view the transaction in a block explorer.
Exact input vs exact output
Exact input
The user specifies the amount to spend. Levery computes an estimated output and enforces a minimum amount out (
minOut) using slippage protection.Service fee behavior- Service fee is charged from the specified input amount before swap execution.
- The pool consumes the remaining amount after the service fee is withheld.
Exact output
The user specifies the amount to receive. Levery computes an estimated maximum input and enforces a maximum amount in (
maxIn) using slippage protection.Service fee behavior- Service fee is charged after execution, based on the actual input delta required to produce the exact output.
- The requested output amount remains exact (subject to the transaction not reverting).
Exact input is suitable when a precise spend amount is required. Exact output is suitable when a precise
receive amount is required (with a bounded maximum input).
Fees explained
Levery separates fees into two categories.LP fee (liquidity providers)
LP fees are paid to liquidity providers and depend on the pool configuration.
- Static pools: a fixed fee rate applies.
- Dynamic pools: fee rate can adjust on-chain based on market context (for example, deviation between pool price and an oracle reference), to support market integrity policies.
Service fee (protocol / operator)
The institution operating the Levery instance charge a service fee. This fee is collected on-chain and routed to the service fee vault for distribution according to institutional rules.Service fee timing depends on trade intent:
- Exact input: charged from input before swap execution.
- Exact output: charged after execution using the realized input delta.
Fees are enforced by on-chain logic. The UI displays estimates for transparency, but the final amounts are determined
by the transaction’s executed deltas.
Slippage protection and deadlines
Every swap includes two execution protections:-
Slippage tolerance
- Exact input swaps enforce a minimum output (
minOut). - Exact output swaps enforce a maximum input (
maxIn).
- Exact input swaps enforce a minimum output (
-
Deadline
- Transactions must execute before a deadline timestamp. After that, execution is rejected.
If the pool price moves beyond tolerance, the quote becomes stale, or the deadline expires, the transaction can revert
rather than execute at an unexpected price.
Pricing and data provenance
Levery uses two separate pricing concepts on the Trade page.Execution pricing (on-chain quote)
Execution pricing comes from an on-chain quote that simulates the swap against:
- the pool’s live state,
- the pool’s fee logic (including dynamic fees),
- and the institution’s on-chain enforcement rules.
Display pricing (fiat values + metrics)
Display pricing is used for fiat conversion, asset summaries, and historical context. It is sourced from the institution’s configured pricing feeds backed by oracle infrastructure and indexed for real-time and historical reference.This improves trust because pricing provenance is consistent, auditable, and not dependent on ad-hoc client-side API calls.
Compliance and settlement model
Levery is designed to provide DEX-like execution without losing compliance control:- On-chain admission checks: swaps are rejected if the account fails the pool’s access policy at execution time.
- Initiator-only settlement: swap proceeds cannot be delivered to arbitrary receivers.
- Context-bound quoting: quotes are computed for the same pool parameters and account context required for execution.
- Audit readiness: trades are traceable to transaction hashes and on-chain state transitions.
What to share with support
If a trade fails or is blocked, the user should share the pool (pair + network), the attempted amount, and the
transaction hash (if one was submitted). This lets the operator reconcile outcomes directly against on-chain records.
Troubleshooting
Swap button disabled
Common causes include a disconnected wallet, the wrong network, no executable on-chain quote (liquidity/RPC/config),
or the account not being permitted for the selected pool.
Transaction reverted
Common causes include slippage exceeding tolerance, an expired deadline, insufficient balance, missing approvals (or
allowance not yet reflected), or an on-chain policy rule rejecting execution.
Approval required
ERC-20 input assets may require approvals before swapping. Once the required approval step(s) are completed, the swap
can be quoted again and submitted for execution.
Quote error
Quote failures may mean the pool is unavailable, the quoter/RPC is unstable, or policy rejected execution. Retry, refresh, switch RPC, or pick another pool.