> 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/overview.md). # The short version Two chains, one invariant, and a verification protocol over consensus-enforced custody. PRL exists natively on Pearl and as a spot asset on Hyperliquid. The two are kept interchangeable by one invariant: > Every PRL in circulation on Hyperliquid is matched, one for one, by native PRL held in escrow on Pearl. Two layers hold that up: **custody the chains enforce**, and **a verification protocol** that decides what is worth signing. ### Layer one: custody, enforced by consensus | | | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Pearl** | Escrowed coins sit at a Taproot output whose script path requires valid signatures from two of three guardian keys. Every node on the network validates it; a spend with one signature is not a policy violation, it is an invalid transaction. | | **Hyperliquid** | The treasury is a native multi-signature account listing the same three guardians. The exchange itself refuses any action below the threshold, including from the key that created the account. | Neither depends on our software behaving. Compromising a guardian's machine does not move funds; it buys an attacker one signature, which is not a spend. ### Layer two: the protocol that decides what gets signed Threshold custody alone is thin. Two signatures prove two keys agreed; they say nothing about whether the payment was owed, to whom, or whether it has already been made. That is what the protocol above it settles, and it is where the design actually lives. **Operations are deterministic.** Every payment is identified by its source — a specific Pearl output, or a specific Hyperliquid transfer — and derived from chain state by a pure function of that source and the shared configuration. Two honest guardians presented with the same source produce byte-identical payloads. A proposal is therefore not a request to be trusted: it is a claim to be reproduced. **Nothing in a proposal is believed.** A guardian re-reads the facts from its own node and its own view of the exchange, recomputes every amount, rebuilds the payload, compares it byte for byte, and signs only on an exact match. A leader that lies produces something nobody else can reproduce, so it gathers no signatures. **Destinations come from cryptography, never from a request.** * *Inbound:* a deposit address is a Taproot script that commits to the Hyperliquid account it credits. The destination is part of what makes the address, so a payment carries its own instruction and no mapping table exists to corrupt. See [deposit addresses](/how-it-works/deposit-addresses.md). * *Outbound:* the destination is an EIP-712 message signed by the account holding the PRL, bound to **one specific transfer**. A signature for one transfer cannot be applied to another, and no relay, leader or website can alter it. **At most once, by construction.** A guardian records its intent to sign before a signature exists, so a crash cannot lose or repeat a payment. It never signs two payouts for one source that could both execute: on Pearl because a replacement must spend the same coins, so the chain itself can accept only one; on Hyperliquid because a payout carries a short validity window and a replacement is signed only once the first is provably beyond use. Any two signing quorums intersect, and the guardian in the intersection enforces this, so the property holds without coordination. **No coordinator.** Whose turn it is to propose is a deterministic function of the source and facts both chains show, so all three compute the same answer without talking. If that guardian stalls, the turn passes on a timeout. There is no sequencer to capture, no queue to block and nothing to fail over. **Independence is structural.** Each guardian runs its own Pearl node, keeps its own database, and holds its own keys — including a separate identity key used to sign messages to peers, so routine communication never touches the keys that move funds. A guardian that disagrees does not stop the network; it simply does not sign. Next: [what a guardian checks](/how-it-works/guardians.md) · [the reserve](/how-it-works/reserve.md) · [who can do what](/how-it-works/trust.md) --- # 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/overview.md?ask=&goal= ``` `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.