Trust model

One split runs through the system:

• Integrity. Can funds be underpaid or sent to the wrong place?
• Liveness. Can things be delayed?

Most of the integrity of an order is enforced by the hub contracts. For the rest you trust a small number of operated services, and this page names them.

What the contracts enforce

• The rate holds on every unit. Every solution is re-validated on the hub before it is applied, so a fill below the order’s rate cannot execute on any fraction of the order.
• The terms are fixed at build. The pair, the amount, the rate, the flat fee, the recipients and the deadline are signed when the order is built. The deposit must match them, and where the source chain has a deposit contract, it must come from the named depositor. On TRON, the deposit is matched to the order by its deposit address and exact amount.
• Your fees come from the chain. Khalani’s percentage fee, your commission and your commission wallet are read from the on-chain integrator registry when the order publishes, and stored with the order. After publish, nothing changes them for that order.
• Payouts go only to the order’s recipients, payoutAddr for the filled part and refundAddr for the refund, both fixed at build.
• A settled order cannot be settled again.
• Escrow is conserved. A solution can neither create nor destroy escrowed value: what an intent spends plus what remains always equals what it escrowed.

What you also trust

Two operated components affect integrity as well as liveness.

• Relayers. The hub credits the deposits that authorized relayers deliver to it, and spokes release the withdrawals they deliver. On TRON, an operated bridge service plays this role and holds the TRON-side funds.
• Intent sequencing. Solutions, cancels and settlements reach the hub through the sequencing service. The contract computes settlement amounts from the order’s signed terms and the fill state that service reports, so its report is part of what you trust.

Khalani’s services can also end an order before its deadline. It then settles like a cancel: the filled part is paid out and the rest refunded.

What happens when something stalls

Component	Role	If it stalls
API	Quotes, signs build terms, tracks orders, triggers settlement	New orders cannot be built. Published orders keep their terms; settlement waits for the service.
Intent sequencing	Applies solutions, advances the hub’s clock, cancels expired intents, submits cancels and settlements	Fills, cancels, expiry and settlement wait until it recovers. Refunds are delayed.
Relayers	Carry deposits to the hub and withdrawals to the spokes	Deposits and payouts wait.

Solvers are independent of all of these. If no solver fills an order, it is refunded at its deadline.

What this means for an order

Price and destination are fixed when the order is built, and the contracts enforce them. Timing depends on operated services. An outage delays an order but does not reprice or redirect it. When the order reaches its deadline or is cancelled, the unfilled share of the deposit is refunded, after the flat fee.