Pavilion Bridge

How it works.

From Pearl’s proof of work to an exact payout. Follow what the bridge verifies, who signs, and the rules the reserve must obey.

Every block
carries its proof.

Pearl is proof of useful work, and every Pearl block header carries a zero knowledge certificate of that work. Pearl nodes check the work through that certificate alone. Pavilion Bridge checks it too, header by header, before anything reaches Ethereum.

How a Pearl block reaches Ethereum

Each Pearl header carries its zkPoW certificate. Attesters verify the header chain and its work from a pinned block, then sign a final checkpoint. Ethereum requires signatures from distinct registered vendors. Separately, the relayer supplies the transaction and its Merkle proof. PearlBridge checks inclusion, recipient and amount before minting wPEARL under a daily cap.

  1. Pearl blocks

    Each header carries its zkPoW certificate

    • Intel TDX

    • AMD SEV-SNP

    • AWS Nitro

    TEE attesters

    Each verifies every header’s certificate from a pinned block, then signs inside its enclave

  3. Quorum

    Signatures from distinct vendors

  4. PearlCheckpoints
    stores the final header
    PearlBridge
    parses the transaction

    Ethereum

    Checks the amount and recipient itself

  5. wPEARL

    Minted under a daily cap

  1. Pearl blocks carry the proof

    Each header travels with its zkPoW certificate, a Plonky2 proof of the work checked with Pearl’s own verifier. Pearl has hard forked at mainnet heights 71,935 and 99,000, so each certificate is checked under the rules for its height.

  2. Attesters verify from a pin

    Each attester keeps its own header chain, starting from a recent block pinned in its public config, and checks every header the way Pearl’s light client does: linkage, difficulty, timestamps and the certificate. Measured at about 9.5 ms a header, with 37 real mainnet headers verified as a chain and tampered headers refused.

  3. Attesters count work, not just blocks

    A block is final only under the required number of headers, and those headers must also carry real work: at least half the total work that the required block depth represents at the pin’s difficulty. pearld only supplies headers, so a lying node would have to mine to fool an attester. Finality comes from the signer’s measured config, never from an RPC.

  4. Attesters sign inside a TEE

    Attesters verify and sign inside trusted execution environments. A TEE signer’s keys stay inside its enclave. Under dstack its keys are derived inside the enclave from the config’s hash, so a different config gets different keys. A TDX signer under dstack publishes a quote that binds its keys to its exact config. The production design terminates TLS inside each TEE, so its operator cannot replace the responses it verifies.

  5. A quorum of vendors signs

    On Ethereum, TeeQuorumVerifier accepts a checkpoint only with signatures from keys registered under a quorum of distinct vendors, such as TDX, SEV-SNP and Nitro. Until enclave attestation moves onchain, governance vouches for each key and its vendor. Adding a signer is timelocked. Revoking one is immediate, because a compromised TEE must stop at once.

  6. Ethereum reads the transaction itself

    Only Pearl blocks that hold bridge transactions are checkpointed, at about 103k gas each with two signatures; relaying every header would cost about 56M gas a day and add no security while Ethereum cannot check certificates itself. The untrusted relayer brings the transaction and its Merkle proof. PearlBridge checks the proof against the attested header, rebuilds the deposit script, checks the recipient and amount itself and mints wPEARL under a daily cap. Attesters vouch only that a block is final.

What the quote proves

bridgectl signers checks each quote against a policy: a DCAP signature chain to Intel’s root, a TCB status of UpToDate by default, not a debug TD, boot measurements (MRTD and RTMR0–2) that pin dstack’s released OS image, and the key provider event. DCAP alone proves only a genuine TDX machine; the boot measurements close that gap.

Under Phala’s onchain KMS on Ethereum, keys are released only to a compose hash and machine that the app’s DstackApp contract allows, and every change to that contract is a public transaction.

What is still trusted

A captured quorum could still attest a fake block. It cannot change what a transaction says, and the daily mint cap limits the rate of unbacked minting. It could also fake a batch settlement, or fake a sweep so that burns are paid twice; watchtowers check every sweep on their own pearld, pause the bridge and sweep that second payout. TEEs across vendors are meant to make that capture harder.

The DstackApp owner is trusted like the signer, because code it allows boots with the same keys. Its changes are public transactions.

An onchain challenge that checks Pearl’s certificate is a separate design. It is not part of the signature verification described here.

The vault
has rules.

Signers alone can only start a delayed payout or a rekey. The covenant on Pearl fixes where PEARL can go next, and any one watchtower can send a wrong move back before it lands.

Exact payouts

  1. Vault

    OP_CAT covenant on Pearl. It allows only four moves: merge, withdraw, rekey and recovery.

  2. Withdraw

    Signer quorum, once the vault output is D blocks old. At most the cap; the rest stays in the vault.

  3. Batch output

    Locked to C = sha_outputs(payouts), the exact recipients and amounts of one Ethereum burn batch. Waits D2 blocks.

  4. Before D2 ends

    Any one watchtower can sweep a wrong batch.

    After D2

    Anyone can split it, only into exactly C.

  5. Split

    Anyone, after D2, only into exactly those payouts.

  6. Exact payouts

    One burn batch: up to 10 burns, first in, first out.

Watchtower sweep

  1. Vault

    OP_CAT covenant on Pearl. It allows only four moves: merge, withdraw, rekey and recovery.

  2. Withdraw

    Signers open a batch output Ethereum does not expect: the wrong C, or batch 2 before batch 1.

  3. Batch output

    Not the batch Ethereum expects. Waits D2 blocks.

  4. Before D2 ends

    Any one watchtower can sweep it.

    After D2

    Anyone could split it into C.

  5. Sweep

    Any one watchtower, reading Pearl and Ethereum from its own nodes, before D2 ends.

  6. Return output

    Bound to the vault.

  7. Merge back

    Signers merge it into the vault. The burns are queued again.

  8. Vault

    The swept funds are back in the vault.

Rekey veto

  1. Vault

    OP_CAT covenant on Pearl. It allows only four moves: merge, withdraw, rekey and recovery.

  2. Rekey

    Signer quorum. Never straight to new keys.

  3. Pending rekey

    Waits DRekey blocks.

  4. Before DRekey ends

    Any one watchtower can veto it.

    After DRekey

    Signers can finalize it.

  5. Veto

    Any one watchtower, back to the old vault. It vetoes a rekey into any vault governance has not registered.

  6. Old vault

    Back where it started.

  7. A separate path

  8. Vault

    Recovery opens only after a very long timelock.

  9. Recovery

    A k of m council, checked in script like the signers.

  10. Council

    The last resort if signers stall.

Exact payouts: signers can fund only a batch output locked to C, the exact payout list. After D2, anyone can split it into exactly those payouts.

The payout list
is fixed first.

Burns on Ethereum queue into batches of up to ten, first in, first out, and the bridge fixes each batch’s payout list as C = sha_outputs(payouts). A signer quorum can move at most the cap, only once the vault output is D blocks old, and only into a batch output locked to C. The rest stays in the vault.

Fixed by script
After a review window of D2 blocks, anyone can split the batch output, but only into exactly those payouts.
Checked by a watchtower
That C and the total match the batch Ethereum expects. The covenant cannot decide that correspondence for itself.

A wrong batch
goes back.

If signers open a batch output that is not the batch Ethereum expects, with the wrong C or batch 2 before batch 1, any one watchtower can sweep it before D2 ends. It reads Pearl and Ethereum from its own nodes, not from a provider.

Where the funds go
A sweep creates a return output bound to the vault. Signers merge it back, and the burns are queued again.
Tested on testnet
Testnet run 2 staged a rogue withdrawal: two signers sent 0.25 PEARL to a thief address. The watchtower swept it, the vault went back to 1.5 PEARL and the thief’s split never got in.

New keys
have to wait.

A rekey never moves the vault straight to new keys. It goes into a pending output that waits DRekey blocks. Before DRekey ends, any one watchtower can veto it back to the old vault; after, signers can finalize it. A watchtower vetoes a rekey into any vault governance has not registered, and the bridge on Ethereum follows only a registered one.

Tested end to end
A rekey to an unregistered vault is vetoed, and the bridge follows the vault there and back.
A separate recovery path
A k of m council, checked in script like the signers, can recover the vault only after a very long timelock. It is not an instant admin override.

Stealing PEARL needs the signer quorum and every watchtower to fail together. A watchtower is a conditional backstop: it must be live, honest, read its own nodes and act inside the window. A malicious one can sweep or veto legitimate moves and delay exits.

Consensus, with
proof behind it.

A quorum matters. Pavilion adds verified work inside TEEs and covenant rules around custody.

Verify first.
Then reach consensus.

Each attester checks Pearl’s ZK work proofs and finality before signing. TEEs protect the keys and the code doing those checks. Ethereum requires agreement across distinct registered vendors.

The quorum still matters: a captured quorum can sign a false checkpoint. Governance controls key registration, and Ethereum checks signatures rather than Pearl’s work certificate.

Signers propose.
The vault sets the route.

The covenant limits withdrawals to capped batches with exact payouts. One honest, live watchtower, reading both chains independently, can send a wrong batch back before the window closes.

Watchtowers must act in time. Signers and malicious watchers can delay exits. Key changes and recovery follow their own delayed paths.

Both paths still depend on Pearl’s consensus, correct contracts and scripts, independent chain data, and the bridge’s governance.

The wait is part
of the design.

Every crossing waits for confirmations and review. The route, the amount and the bridge’s limits determine when it can finish.

Confirmations follow exposure.
Required depth grows with all value minted from nearby Pearl blocks, across a block window and its neighbors, not just one deposit. Splitting a deposit does not avoid it.
Caps control the rate.
A daily mint cap can spread one deposit’s mint across days; only the eligible remainder can be claimed later. Withdrawal caps and delays also constrain normal exits. A daily cap is an exposure control, not a total loss guarantee if an attester quorum stays compromised.
Cancellation has a window.
A deposit’s timelocked refund is available only while it is unspent and unmerged, not after minting. A redemption is cancellable only while Queued. Cancelling a requeued swept request re mints wPEARL and can be held up by the daily cap.

Bridge Pearl

Pearl
Ethereum
PEARL

You receive0.00 wPEARL

Use an address you control on Ethereum.

Exchange rate
1 PEARL = 1 wPEARL
Network fee
Calculated in wallet