> For the complete documentation index, see [llms.txt](https://docs.pearlswap.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pearlswap.ai/how-it-works/guardians.md).

# The guardians

What each guardian verifies before it will sign, and what it refuses.

Three operators, two signatures to move anything, and no privileged member. Each runs the same software over its own infrastructure: its own Pearl full node, its own database, its own keys.

### Three keys, separated by purpose

| Key               | Use                                                                                                                                             |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| Pearl signing key | Its share of the escrow's script path                                                                                                           |
| Hyperliquid key   | Its share of the treasury's authorised signers                                                                                                  |
| Identity key      | Signs messages to peers and deposit-address attestations. Kept apart from the two above, so constant use never touches the keys that move funds |

### The checklist before a signature

A guardian treats every proposal as untrusted input. In order, it:

1. **Rejects anything built under a different configuration**, matched by hash. The guardian set, threshold, fees and limits are one document all three agree on; one guardian cannot quietly change a fee or a cap.
2. **Confirms the source exists, on its own node.** For a deposit: the output, its amount, its script, and enough confirmations. For a withdrawal or return: the transfer in the exchange's own ledger, with its sender and amount.
3. **Recomputes the destination from cryptography.** The Hyperliquid account committed in the deposit script, or the sender's signature bound to that one transfer — never a value supplied with the proposal.
4. **Recomputes every amount** from the agreed rules and compares.
5. **Rebuilds the payload** — the Pearl transaction or the exchange action — and compares it byte for byte with what was proposed.
6. **Checks its own history.** Has it already signed for this source? Would this conflict with something it signed before? A second payout is signed only under rules that make simultaneous execution impossible.
7. **Checks the invariant and the limits**: the reserve covering what circulates, the per-payment minimum and maximum, and a rolling cap. Breaching the reserve check stops the guardian rather than producing a signature.
8. **Writes down its intent to sign, and only then signs.**

Any step failing is a refusal with a reason, returned to the proposer and recorded. Refusals are normal: a guardian whose view lags refuses until it catches up.

### Adversarial testing

The refusal paths are tested as attacks rather than as error handling: a leading guardian that lies about amounts, destinations, sources, configuration or its own identity; attempts to have one payment made twice, under a new sequence number or a different leader; a compromised follower returning junk signatures; a guardian returning after an absence to re-propose something already settled. The suite also kills a guardian at each of the worst possible moments — holding a fully signed payment, immediately after submitting one, immediately after signing as a follower — and then requires the books to balance to the last unit.

### Liveness

Two guardians are a quorum, so one being down costs nothing but its turn. A returning guardian rebuilds its view from its own node and resumes. Losing two suspends new payments; it does not put escrowed funds at risk, because the threshold is a consensus rule rather than a policy the survivors could relax.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.pearlswap.ai/how-it-works/guardians.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.