Witnesses, trust and the vote

The assets locked in a bridge sit in the door account. So the main question for any bridge is: who holds the door's keys?

In a full setup, no single person does. The witness servers' signing keys go onto the door account as a list of signers. The door's own master key is switched off. From then on, the witnesses as a group control the locked funds. A set number of them must agree before anything moves.

That design removes one point of failure and creates a new kind of trust. If enough witnesses were dishonest or hacked together, they could sign for things that never happened. The docs put the burden on users of the issuing chain to judge how reliable a bridge's witnesses are.

A few things to know:

• Anyone can run a witness server. Each one also needs its own node on the chains it watches.
• A new sidechain may start with one witness run by the sidechain itself. That is a single point of trust.
• xrpl.org warns that operating a witness can carry legal and regulatory risk, and tells operators to seek independent advice.

Where it stands. XChainBridge has been open for voting since server version 2.0.0, released in January 2024. It has not been enabled. It needs more than 80% of trusted validators for two weeks, like any amendment.

Other bridges exist today that do not use this amendment. The XRPL EVM sidechain's docs list Axelar, IBC and Wormhole as its bridge options.

Production setup, from XLS-38.

1. Start the witness servers.
2. Each door account sends XChainCreateBridge on its own chain.
3. Each door account sends SignerListSet with the witnesses' signing keys.
4. Each door account disables its master key with AccountSet.

After step 4, the witnesses as a collective have total control of the bridge. XLS-38 states the risk plainly: if a quorum of witnesses collude, they can steal funds from the door account.

Changing a bridge. XChainModifyBridge must be sent by the door account, so it needs witness signatures. The operators coordinate off the ledger. It changes only SignatureReward and MinAccountCreateAmount. The signer list is changed with a normal SignerListSet.

Witness server. It is a separate program, not part of xrpld. Its config names both chains' endpoints, the bridge, a signing key and a RewardAccount per chain. The operator must also run an xrpld node synced to each chain it watches.

Rewards. SignatureReward is split among the witnesses whose keys are on the current signer list. Rewards are paid on the destination chain.

Related fix. fixXChainRewardRounding makes reward shares always round down. It shipped in rippled 2.2.0 in June 2024 and is also not enabled.

The vote.

An amendment can stay open for voting as long as its code remains in the server. xrpl.org calls an amendment "vetoed" if its code is removed without it being enabled. That has not happened here.

See How amendments happen.

Live count: Amendments page.