Test networks only, for now Pearl Swap and our guardian run on Pearl testnet2 and Hyperliquid testnet. No real funds move through the bridge yet.
Independent operator on Pearl
Pearl Swap is the bridge between native PRL on Pearl and PRL on Hyperliquid. Our guardian checks every payment against its own Pearl node and its own reading of Hyperliquid before it signs. It cannot move anything alone, and neither can anyone else.
Two jobs, both on Pearl. We say who operates what, and we publish our keys.
Every PRL token on Hyperliquid is matched one for one by native PRL in an escrow on Pearl. Three guardians hold the keys to it. Any two can move it. One cannot, and that includes ours.
Pearl's proof of work is matrix multiplication, the arithmetic of machine learning. Securing the chain and useful computation are the same act. We mine by doing that work.
We publish figures about our machines only when they are measured and public. There are none yet.
How Pearl's useful work worksIt believes nothing it is told. Before it signs a payment, it runs eight checks against its own Pearl node and its own reading of Hyperliquid. Four of them carry the idea.
It confirms the source on its own node, recomputes every amount from the agreed rules and rebuilds the transaction byte for byte.
The account committed in the deposit script, or the sender's EIP-712 signature bound to that one transfer. Never a value supplied with the proposal.
It writes down its intent to sign, and only then signs, so a crash cannot make it forget.
It checks its own history and never signs two payouts for one source that could both execute.
Any failure 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.
All eight checks, in our wordsTest networks only, for now. Nothing in the bridge runs on real networks yet, and the guardians refuse mainnet.
Pearl Swap ran the guardian kit as three hosts on one machine, including a guardian switched off mid-run.
Each operator set up its own server, its own Pearl node and its own keys.
It answers at guardian.enderpearl.ai: public DNS, a valid Let's Encrypt certificate, and a TLS proxy in front of a guardian process that listens on localhost only.
One shared configuration for all three guardians. It adds the fee sweep and returns for small deposits, and removes the largest-payment and hourly caps. Earlier copies, f22e5e61… and f24767e2…, are superseded.
8a8615d24a920f6f3805c299318be5761beca9df218e4bb60a5f61d20bb67c06
The first payments ran through the bridge on Pearl testnet2 and Hyperliquid testnet, using test PRL sent by the Pearl team.
An outside audit of the guardian software comes before any real funds. Until then, the bridge runs on test networks only.
The trust assumption
Any two of the three guardians can move the escrow. So two colluding guardians could move it. That is the assumption, and we state it plainly.
Two signatures from three named keys move the escrow on Pearl and the treasury on Hyperliquid. Every Pearl node enforces the escrow script. Hyperliquid refuses any treasury action without two, including from the key that created the account.
Not us, and not anyone else. Each chain enforces the rule itself. One guardian down costs only its turn. Two down pauses new payments without putting escrowed funds at risk.
The three guardians are run by different operators, on their own machines, with their own keys. We publish ours, and our guardian's record is public.
You do not have to take our word for the parts that matter. Compare our published keys, and read our guardian's own record.
Our three public keys, the configuration fingerprint for epoch 1, the escrow and treasury addresses, and how to verify each one yourself.
Read live from guardian.enderpearl.ai in your browser: what it has signed and led, its configuration and its Pearl height. When it cannot be read, the page says so.