---
title: Trust model
description: What the operator controls, what the contract enforces, and the invariants an integrator can rely on.
---

Hular is operator-run. Custody of float, quoting, and execution all sit with a single first-party operator. This is a deliberate trade: it is what removes the message-passing wait and the guardian set, and it means the guarantees are narrower than a trust-minimized bridge's.

Be accurate about this with your users. The protocol does not claim to be trustless.

## What the operator controls

- Float on every chain, held in the solver vault it owns, and in-flight deposits held in the escrow until they settle.
- Pricing: the spread, the accepted size band, and which chains and tokens are quotable.
- Execution: when fulfillments, refunds, and relayed gasless deposits are submitted, and at what gas price.
- The owner keys that can pause the contracts, withdraw float, change the executor, aggregator, and voucher-signer allowlists, and upgrade the router. The router is UUPS-upgradeable; the escrow and solver vaults are not.

## What the contract enforces

These hold regardless of operator intent, and they are the reason a compromised executor is not a compromised vault.

| Enforced | Detail |
| --- | --- |
| Only allowlisted callers move float | Payouts are restricted to registered executors; withdrawals to the owner. |
| Escrow funds have two exits | The escrow releases only to the solver contract, and refunds only through a registered executor. A compromised executor cannot redirect escrow funds to itself. |
| Deposits release on settlement | A deposit leaves the escrow for the solver only after it settles past the per-chain deep-settlement depth, so a deep reorg cannot un-fund float already committed elsewhere. |
| Swap outputs meet their floor | A swap returning less than the committed minimum reverts. |
| Surplus stays in the vault | Output above the floor is retained by the solver, never redirected. |
| Vouchers are signed and single-use | A referrer voucher requires a valid voucher-key signature and can be redeemed exactly once, to the referrer address embedded in it. |
| No standing approvals | Both vaults pay from their own balance, so no operator wallet holds an allowance on user funds. A gasless deposit is authorized by a permit2 signature bound to one quote hash, not an open allowance to the operator. |

## Invariants for integrators

- **The quote hash binds the deposit.** A deposit that does not match the stored parameters is refunded, never fulfilled at a different price.
- **One active order per quote.** Enforced by a unique index. A duplicate deposit against the same hash does not produce two payouts.
- **Terminal states are final.** `fulfilled`, `refunded`, `refund_skipped`, `deposit_missing`, `refund_failed`, and `unsupported_deposit` do not change afterwards.
- **Executors are interchangeable.** Any executor can serve any order; removing one degrades nothing but coverage of its own in-flight transactions.

## Failure modes worth designing for

| Scenario | What your integration sees |
| --- | --- |
| Operator pauses a chain | `GetChains` reports `quote_enabled` false; new quotes on that chain fail. Existing orders continue. |
| Inventory exhausted on the destination | `GetQuote` fails with `insufficient inventory`. Nothing is deposited. |
| Price feed stale | `GetQuote` fails with `price unavailable`. Nothing is deposited. |
| Operator halts entirely | Deposits already made are refundable by the operator; new quotes stop. There is no user-callable escape hatch on the router. |

The last row is the one to weigh. Funds in flight depend on the operator continuing to run. Size your exposure accordingly and prefer smaller, faster settlement over batching value into single large orders.

See [Security](/resources/security) for the contract surface and audit status.