Guardian t-mining · Pearl Swap

enderpearl.ai/guardian

We are one of three signers. Moving anything takes two.

Pearl Swap holds native PRL in an escrow on Pearl and the PRL token supply in a treasury on Hyperliquid. Both need two signatures from three guardians, run by different operators on their own machines. Ours is t-mining. This page sets out what it checks before it signs, what we hold, what we never do, and who would have to do what for funds to move.

Guardian
t-mining at guardian.enderpearl.ai. Its own record
Operator
Enderpearl, independent. Not part of Pearl Research Labs or Pearl Swap.
Threshold
2 of 3, enforced by Pearl and by Hyperliquid.
Configuration
Epoch 1, 8a8615d2…, agreed 23 Sep 2026.
Networks
Pearl testnet2 and Hyperliquid testnet. Test networks only, for now.
The route of one payment, drawn on the tile. The row is where the PRL came from. The column is the one account it may go to, fixed by cryptography before anything moves. C = A·B

Our role in the 2 of 3

enderpearl.ai/guardian#role

Three guardians, run by different operators, each on its own machine with its own keys and its own Pearl node. Any two can sign a payment. We run one of the three, and our say is equal to each of the others.

3 keys, named in the escrow script and on the treasury2 needed
Who leads, payment by paymentIllustrative order
An illustrative order of turns to lead for six payments. Each guardian leads two of the six.
PaymentEnderpearlAnother guardianA third guardian
Payment 12ndLeads3rd
Payment 2Leads3rd2nd
Payment 33rd2ndLeads
Payment 43rdLeads2nd
Payment 52nd3rdLeads
Payment 6Leads2nd3rd
The real order comes from a hash of each payment and each guardian's id. Nobody picks it, and it is worked out afresh for every payment.

An id carries no privilege

Whose turn it is to lead a payment is a hash of the payment and the id. It is worked out afresh for every payment, and no guardian leads first or more often. Our id, t-mining, is a name and nothing more.

The leader proposes, the others check

The guardian whose turn it is builds the payment and proposes it. The other two rebuild it from their own view of both chains and sign only an exact match.

No coordinator

All three work out whose turn it is from the same chain facts, without asking each other. If the leader stalls, the turn passes to the next guardian in that payment's order after a timeout.

Both chains enforce it

enderpearl.ai/guardian#chains

Pearl enforces the escrow's rule, and Hyperliquid enforces the treasury's. The guardian software cannot relax either one. A compromised guardian gives an attacker one signature, and one signature is not a spend.

Pearl · the escrowPearl testnet2

A Taproot output that only its script can spend

The escrow holds the native PRL that backs every PRL token on Hyperliquid, one for one. It sits at a Taproot address, and a Taproot address can be spent two ways: with one key, or with a script it commits to.

Key path
Closed Its key is a point nobody knows the private key for.
Script path
Two signatures from three named keys.

Every Pearl node checks the script. A spend with one signature is an invalid transaction, and the network rejects it.

The script, for engineers

<key 1> OP_CHECKSIG
<key 2> OP_CHECKSIGADD
<key 3> OP_CHECKSIGADD  ours
OP_2 OP_NUMEQUAL
Output
P2TR, script path only. Tapscript leaf, version 0xc0, in BIP 342's k-of-n form.
Internal key
BIP 341's nothing-up-my-sleeve point, 50929b74…803ac0. No private key is known, so the key path is dead.
Key 3
Ours, c3679e6c…, printed in full with our keys below.
Pearl escrow (testnet2), P2TR, 2 of 3
tprl1pxzutjzl6dar32p8389gkhdylnq0659sv4r3xthpj8ytdst2jcuzq2mzte6
Hyperliquid · the treasuryHyperliquid testnet

A multi-signature account, native to the exchange

The treasury holds the supply of the PRL token on Hyperliquid. It is a multi-signature account, built into Hyperliquid itself, and it names the same three guardians.

Signers
Two signatures from the same three guardians.
Creator's key
Refused alone Like every single key, once the account is converted.

The exchange refuses any action on the treasury without two signatures, including from the key that created the account. The conversion to 2 of 3 is one way.

The account, for engineers

Type
Hyperliquid native multi-signature account, threshold 2 of 3 authorised signers.
Our signer
0xc87e6938…f3fd, printed in full with our keys below.
Token
PRL:0x214b38dd02161ada14b926ab13bbd5e3
Hyperliquid treasury (testnet), 2 of 3
0xefb6f8c559bca7b546b3dbc83f652a3fa1239c0d

Two signatures prove that two keys agreed. They do not prove the payment was owed, to whom, or that it was not already made. That is the work of the eight checks.

Check both addresses yourself

How our guardian decides

Eight checks, in order. Then one signature.

Our guardian believes nothing it is told. It runs these eight checks in this order, against its own Pearl node and its own reading of Hyperliquid. Any failure is a refusal with a reason, returned to the proposer and recorded.

enderpearl.ai/guardian#checks
  1. Configuration

    The same rules, matched by hash

    It rejects anything built under a different configuration. The guardian set, the threshold and the fees are one document all three operators agreed. Its hash is the fingerprint we publish, so one guardian cannot quietly change a fee.

    Refuses if

    the proposal was built under any configuration other than 8a8615d2…

  2. Source

    The source, seen on its own node

    It confirms the payment's source exists, on its own Pearl node or its own reading of Hyperliquid. For a deposit: the Pearl output, its amount, its script and 2 confirmations (the test-network setting). For a withdrawal: the transfer in Hyperliquid's own ledger, with its sender and amount.

    Refuses if

    it has not yet seen the source for itself, as on 23 September.

  3. Destination

    The destination, from cryptography

    It works out where the money goes from cryptography alone: the Hyperliquid account committed in the deposit script, or the sender's EIP-712 signature bound to that one transfer. A destination supplied with the proposal is never used.

    Refuses if

    the proposed destination differs from the one it derived.

  4. Amounts

    Every amount, recomputed

    It recomputes every amount from the agreed rules and compares. Amounts are counted in grains: 1 PRL is 100,000,000 grains.

    Refuses if

    any amount differs from its own figure.

  5. Payload

    Rebuilt, byte for byte

    It builds the payload itself, the Pearl transaction or the Hyperliquid action, and compares it with the proposal byte for byte. It signs only an exact match. A proposal that lies cannot be reproduced, so it gathers no signatures.

    Refuses if

    a single byte differs.

  6. History

    One payout per source

    It checks its own history. It never signs two payouts for one source that could both execute.

    Refuses if

    it already signed a payout for this source that could still execute.

  7. Reserve

    The reserve still covers what circulates

    PRL circulating on Hyperliquid must stay covered by native PRL in the escrow. It also checks the smallest payment, 10 PRL. There is no largest payment and no hourly cap.

    Refuses if

    the payment is under 10 PRL.

    Stops if

    the reserve would no longer cover what circulates. It stops, and produces no signature.

  8. Record

    Intent first, then the signature

    It writes down its intent to sign, and only then signs. A crash cannot make it forget what it signed.

    Then

    it signs.

One signature of the two needed.

A second guardian must reach the same result on its own view before anything moves.

Refusals are normal. A guardian whose view lags refuses until it catches up.

Upgrades to this software are reviewed by all three operators before anyone deploys.

The refusal of 23 September

enderpearl.ai/guardian#refusal

The evening the first payments ran on test networks, a guardian refused a withdrawal once. It was not ours. We tell it here because it shows the job every guardian does, ours included.

A guardian signs only for money it has seen for itself.

One withdrawal · test networks · test PRL

  1. Proposed

    One guardian proposed a withdrawal.

  2. Refused

    Another guardian refused it:

    “I have not seen this transfer on Hyperliquid.”

    Check 02 · the source, seen on its own node

  3. Confirmed

    Its own node then confirmed the transfer.

  4. Signed

    Only then did it sign.

It did not take the leader's word for the transfer. It waited until its own node confirmed it. A guardian whose view lags refuses until it catches up, and ours is built to do the same.

What we hold, and what we never do

enderpearl.ai/guardian#hold

Three keys, made on our own machine. They never leave it. We publish only the public halves.

  • Pearl signing key

    Our share of the escrow on Pearl.

    Public half · x-only, hex
    c3679e6cd3ed26d5775fc136bdef2aad0eda6018c04765658efecd3b9e5ab70a
  • Hyperliquid key

    Our share of the treasury on Hyperliquid. Its account is used for signing bridge payouts and nothing else.

    Public half · signer address
    0xc87e693808208c814b79a0ec024f314aa8d4f3fd
  • Identity key

    Signs our messages to the other guardians and the deposit addresses we vouch for. It is kept apart from the two keys that move funds, so constant use never touches them.

    Public half · Ed25519, DER, hex
    302a300506032b65700321004e6033092f793d3f8943fd3c3d52f164cf3bad27d759d0741bfe6e3ec25c27d4

Our guardian refuses to start if any of its keys is not the one the configuration names.

Our keys, and how to check them

Four things

We never

  1. Use our guardian's Hyperliquid account for anything else.

  2. Sign or run anything that arrives out of band: by email, by chat, or because someone says it is urgent.

  3. Move funds by hand.

  4. Send a private key to anyone. If asked, the answer is no, and the other guardians are told.

Our guardian acts only on what it verifies against its own view of the chains.

Fees, as configured

enderpearl.ai/guardian#fees

Fees live in the shared configuration for epoch 1. No guardian can change one alone, ours included. A changed fee is a changed fingerprint, and every operator sees it.

Fees and limits · epoch 1 · test networks
PaymentAs configured
Moving PRL to Hyperliquid1 PRL flat, whatever the amount
Moving PRL back to Pearl0.25% plus 0.0001 PRL
Smallest payment10 PRL
Largest paymentNo limit
Hourly capNone

Test-network figures are not a commitment to live fees. 1 PRL = 100,000,000 grains.

The fee sweep

What the bridge earns leaves the escrow by a separate operation, the fee sweep, to one address named in the configuration and nowhere else. Each guardian works out what was earned by itself, and refuses a leader that asks for more, points elsewhere, or replays a height already swept. It can never take PRL a circulating token is owed.

Small deposits can go back

Native PRL sent below the smallest amount can be returned. The owner of the Hyperliquid account the deposit address commits to signs a return to a Pearl address. Each guardian checks it, and the payout spends the deposit itself, so it can happen once.

Read live, in your browser GET guardian.enderpearl.ai/status · not read yet

The configuration our guardian runs

—

published 8a8615d2…

When a guardian is down

enderpearl.ai/guardian#liveness

Two guardians are a quorum. One down costs only its turn. Two down pauses new payments, and escrowed funds stay put. This holds whichever guardian is down, ours included.

Guardians answering, and what follows
AnsweringNew paymentsFunds at risk
3 of 3 Proceed. Each payment's leader proposes; the other two check and sign. Funds at riskNo
2 of 3 Proceed. The missing guardian costs only its turns. After a timeout, the next guardian in that payment's order leads. Funds at riskNo
1 of 3 Pause. One signature cannot move anything. Escrowed funds stay where they are. Funds at riskNo
0 of 3 Pause. Nothing moves until guardians are back. Escrowed funds stay where they are. Funds at riskNo
Ours, right now Checking reading from your browser
  • A returning guardian rebuilds its view from its own node, then resumes.
  • Each guardian checks its clock against Hyperliquid every ten minutes, and refuses some operations if it drifts by more than a minute.
  • On 19 Sep 2026, Pearl Swap rehearsed the guardian kit end to end with a guardian switched off mid-run.
Our guardian's full record

Who would have to do what

enderpearl.ai/guardian#threats

For each case: what it would take, and whether escrowed funds are at risk. The last row is the trust assumption. We state it plainly.

Threats to the escrow: what each would take, and whether funds are at risk
IfWhat it would takeFunds at risk
One guardian's host is compromised, ours or another's The attacker holds one signature. Moving anything would still take a second guardian, and both chains enforce that. Funds at riskNo
A guardian lies when it leads The other two would have to sign a payload they cannot reproduce. They sign only an exact match, so the lie gathers no signatures and the turn passes on a timeout. Funds at riskNo
A guardian is offline, or returns out of date The other two remain a quorum. A returning guardian rebuilds from its own node before it acts. Funds at riskNo
A payment is replayed, or a guardian crashes mid-payment Two payouts for one source would both have to execute. Each guardian writes down its intent before it signs and never signs two that could. Funds at riskNo
We are compelled, or we disappear We are one signer of three. Whoever compels us gets one signature at most, and our absence neither moves the escrow nor strands it. Funds at riskNot by us alone
Two guardians collude Two independent operators would have to act together. Two signatures from three keys is the rule, so they could move the escrow. Funds at riskYes

So the design is worth what the independence of the three guardians is worth. That is why we say who operates what, and publish our keys.

The questions we expect from holders, auditors and counsel.

Can Enderpearl freeze or move funds?

Not alone.

Moving anything takes two signatures from three keys, and each chain enforces that. Refusing to sign freezes nothing either: the other two guardians can sign a valid payment without us.

What if we are compelled?

We still hold one key of three.

We cannot hand over more than one signature, and one signature is not a spend. We never send a private key to anyone. If asked, the answer is no, and the other guardians are told.

What if we are hacked?

An attacker gets one signature.

One compromised guardian cannot move funds. To move anything, an attacker holding our machine would still need a second guardian. We would tell the other two at once.

What if we disappear?

Payments continue without us.

The other two guardians are a quorum, so our absence costs only our turns. The escrow is neither moved nor stranded. If a second guardian also stopped, new payments would pause and escrowed funds would stay where they are.

Is the guardian software audited?

Not yet.

An outside audit of the guardian software comes before real money. Until then, the bridge runs on test networks only: Pearl testnet2 and Hyperliquid testnet.

Check it yourself

Compare our published keys with the escrow and the treasury, and read our guardian's own record.