---
title: How it works
description: Roles, the settlement path, and what happens when a deposit does not match its quote.
---
import { MAX_FULFILL_ATTEMPTS } from "/snippets/vars.mdx";
Hular runs a single first-party operator. Quoting, inventory, and execution are all operator-run; the contract enforces a narrow set of rules around them. Nothing waits on a cross-chain message, because the destination payout is made from float that is already there.
## Roles
| Role | What it does |
| --- | --- |
| User | Requests a quote, deposits on the source chain, receives on the destination chain. |
| Escrow | Receives every deposit and holds it until the deposit settles past the deep-reorg check. Pays refunds from its own balance. Its funds leave only toward the solver or a refund address. |
| Solver | Holds the operator float on every chain and pays fulfillments, gas drops, and voucher redemptions from its own balance. Pulls settled deposits out of the escrow in threshold-sized batches. |
| Router | The entry-point contract for swap, permit, gasless, and same-chain deposits, and for partner funding. It forwards funds into the escrow and never holds float between transactions. |
| Executors | A pool of operator wallets funded with gas only. They sign and submit destination transactions and relay gasless deposits. All value moved comes from the vaults. |
| Voucher key | Signs referrer vouchers. Sends no transactions and holds no funds. |
| Owner | Manages the contracts: pause, withdraw, executor and aggregator allowlists, voucher signer rotation, router upgrades. |
Because both vaults pay out of their own balance, there is no ERC-20 approval held by any operator wallet, and a compromised executor cannot move float to itself: the only place it can move escrow funds is into the solver.
## Settlement path
```mermaid
flowchart LR
A[GetQuote] --> B[Deposit on source chain]
B --> C[Indexer matches quote hash]
C --> D[Confirmations accrue]
D --> E[Relayer claims order]
E --> F[Router pays recipient on destination]
```
The pricing pipeline reads median-aggregated prices from multiple independent providers, gas from the block stream, aggregator routing for token legs, and current inventory. It persists the canonical order parameters and returns their keccak hash.
The user calls `depositToken` or `depositNative` on the escrow, or `depositWithSwap` on the router, with the quote hash. On a gasless quote the user signs instead and the operator relays the deposit. Either way the funds land in the escrow and a `Deposit` event is emitted.
The indexer matches the event to the stored quote, records the deposit, and creates the order. A finality worker advances it once the required confirmations accrue.
A relayer worker claims the order, leases an executor, and submits the destination transaction. The solver pays the principal and any gas drop out of its own balance. The order is finalized when that transaction confirms.
The deposit stays in the escrow until its transaction settles past the per-chain deep-settlement depth. Settled deposits are then swept to the solver in batches once they cross a per-token threshold, and the sweep itself passes the same settlement check before the funds count as spendable float.
## Same-chain swaps
When source and destination chain are equal, the router performs the swap inside the deposit transaction and the order is marked fulfilled once it confirms. No relayer, no second transaction, no destination inventory. See [Same-chain swaps](/integration/same-chain-swaps).
## When a deposit does not match
The quote hash binds the deposit to exact parameters. A deposit with the wrong token, the wrong amount, or a reused quote is never fulfilled: the order is created directly in `pending_refund`. Fulfill failures land in the same place after {MAX_FULFILL_ATTEMPTS} attempts.
The refund worker deducts the fees already committed in the quote, defers while live gas exceeds that commitment, and pays the net amount back to the refund address from the escrow's balance on the source chain. See [Refunds](/concepts/refunds).
## Making transactions land
Every submission is pinned to one executor and one nonce, and its full intent is persisted on the order. If it stalls, the tracker re-signs the same nonce at a higher gas price while the fee budget allows, and burns the nonce when the transaction is stuck beyond its deadline. Solana uses durable nonces for the same purpose, so an in-flight transaction never expires.
Reverts and burns move the order into a consistency window rather than a guessed outcome. After a quiet period both hashes are re-polled and the order moves to the state matching what actually landed on chain.
Every state an order can reach, and which ones are terminal.
What the operator controls and what the contract enforces.