> ## Documentation Index
> Fetch the complete documentation index at: https://docs.panofx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security model

> The invariants the contracts, the relay and the node hold, and the test that enforces each.

* **No Panofx-controlled key can move a taker's, resolver's, or LP's funds.** Ever. The keeper's submitter key holds gas money only. The multisig can pause, set fee token and bps per corridor up to 5, set the treasury, and set the gas-fee formula parameters; nothing else.
* **The reactor's and the executor's balances of every token are zero after every call.** Fork test.
* **The executor delivers at least the taker's signed `minOut` to the signed `recipient` and charges at most the signed `maxGasFee`, or reverts.** Fork test over both fee-token directions.
* **The executor accepts only offers whose hash the taker signed and whose validation data names this executor and this taker.** Fork test with a swapped offer and a swapped taker.
* **An offer executes only for its named taker, only before its deadline, only once.** Fork tests for each.
* **The protocol fee never exceeds 5 bps and is only ever in the dollar token.** Fork test that a controller returning 6 bps reverts in the reactor.
* **A node signs nothing while disconnected, degraded, or above verified inventory.** Unit and integration tests with fault injection.
* **Solana: an offer is a signed message; any change to the message invalidates it.** Relay and client reconstruct and compare bytes before trusting it.
* **Hosted surfaces screen addresses; contracts and the relay protocol do not.** No identity data exists to leak.

## What the relay checks before ranking

Every offer is checked against what the chain will enforce: balance, allowance, nonce, reservation
against other open quotes, the pause flag, and every term of the order against the RFQ. The winning offer
is then simulated end to end before the taker sees a price. The list of reasons is under
[Why the relay rejected an offer](/resolvers/operate/rejections).

## What the keeper checks before submitting

The keeper leader simulates the settlement with the taker's signature attached. A revert becomes a
`requote` to the taker and nothing moves. A revert the keeper traces to the resolver's side counts toward
that resolver's [demotion](/resolvers/operate/reliability).

## Abuse controls

| Control                                               | Where             |
| ----------------------------------------------------- | ----------------- |
| Taker proof of control, 24 hours, per wallet          | `POST /v1/quotes` |
| In-flight RFQs per taker (4)                          | Relay             |
| RFQs per second per resolver (100, burst 200)         | Relay to node     |
| Per-IP budgets on quotes, executions and registration | Relay             |
| Resolver registration, signed by the key              | Relay             |
| Automatic demotion on reverts or a low score          | Relay             |
| Minimum ticket per corridor                           | Relay and node    |

## The remote console

The paired-browser channel has its own threat model: what the relay can and cannot see, what a phishing
link can do, and what a stolen browser can do. See [Remote console](/protocol/remote-console#threat-model).