Cross-chain defense · read-only evidence watchtower

XRBC Bridge Integrity Watchtower

v4.0.0 · Defense-in-depth · No bridge execution

Bridge Integrity Watchtower

Rank monitored XRPL bridge routes by transparent caution factors, inspect a sourced history of cross-chain failures, and separate operational state from evidence quality. Advanced local tools can test supplied transaction records and reserve claims, but nothing on this page can quote, route, approve, deposit, bridge, sign, or submit a blockchain transaction.

Rank caution transparentlyA published 0–100 model exposes every scored factor; higher means more caution, never a probability of failure.

Separate state from evidenceOperational state, incident history, score, coverage, and freshness remain distinct so unknown data cannot become a favorable signal.

Follow primary evidenceGovernment, official operator, on-chain, and technical sources are labeled by tier and timestamp instead of blended into an unexplained claim.

Preserve local findingsAdvanced users can create deterministic JSON evidence and a local SHA-256 digest without sending a bridge transaction.

Hard boundary: this is an observation and evidence page. It intentionally contains no transfer button, bridge quote, deposit address workflow, route execution, contract approval, wallet signature, or transaction payload.

“Near-real-time” applies only when a configured public feed has refreshed successfully and its source timestamp remains inside the published 48-hour freshness window. A stale, missing, disputed, or secondary-source fact is shown as such and never converted into “safe.”

Free public protection tool · no wallet · no network request

Stop Before You Send: 60-Second Bridge Safety Screen

Answer only from evidence you independently checked. A bridge operator's own unsupported claim is not confirmation. One failed control means stop; one unknown control means pause and investigate.

Not evaluated

This screen never clears a bridge as safe. It is a fail-closed interruption tool designed to expose missing trust assumptions before funds leave a wallet. It does not inspect a wallet, open a bridge, or prepare a transaction.

Route under review: No directory route selected

1. Exact route identitySource chain, destination chain, asset, XRPL vault or door, destination contract, and network IDs match durable official documentation and independent on-chain evidence. 2. Current operations and exitDeposits, withdrawals, redemption, and any emergency pause state were checked through a current official status source; no unexplained halt or backlog exists. 3. Verification and signer modelThe proof, witness, validator, or DVN model; distinct participants; quorum; finality; replay protection; and compromise threshold are documented and independently reviewable. 4. Reserve and liability evidenceAssets actually held, wrapped or minted liabilities, pending withdrawals, fees, and unresolved claims reconcile. A TVL label alone is not proof of solvency. 5. Admin, upgrade, and pause authorityOwners, multisigs, timelocks, upgradeability, pausers, emergency recovery roles, and key-rotation controls are disclosed; a single hidden key cannot silently change the route. 6. Deployed-code and audit matchThe audit covers the currently deployed implementation and configuration after the latest material upgrade or incident. Open findings and scope exclusions are visible. 7. Dependencies and monitoringRPCs, oracles, relayers, front end, DNS, libraries, indexers, and off-chain infrastructure are mapped; independent monitors can detect inconsistent messages or abnormal balance changes. 8. Walkaway and recovery testIf the operator disappears today, users have a documented, technically credible way to redeem or exit; incident communications, evidence preservation, and recovery responsibilities are defined.

Non-negotiable stop signals

Bridge warning signals and protective responses
Observed signal	Why it matters	Protective response
Vault, door, contract, chain, or asset mismatch	A valid transaction sent to the wrong route can be irrecoverable.	STOP
Active exploit, unexplained halt, disputed reserves, or withdrawals disabled	Operational failure can strand assets even when code appears normal.	STOP
Signer, witness, validator, or proof threshold can be forged or controlled	False cross-chain messages can authorize unbacked minting or release.	STOP
Source and destination parsers disagree about the same event	Cross-layer interpretation gaps can turn an invalid event into a valid release.	STOP
Critical evidence is stale, missing, or contradictory	Unknown status is not evidence of normal operation.	PAUSE
Audit predates deployed code, configuration, or incident remediation	The reviewed system is not necessarily the system holding funds now.	PAUSE

If a transfer may be affected

Stop sending funds. Do not send a second transaction to “unlock,” “verify,” or “recover” the first.
Preserve evidence. Record transaction hashes, chain IDs, token and contract addresses, destination, amount, UTC time, screenshots, error text, and the exact website domain.
Use independently verified operator channels. Ignore unsolicited direct messages and never reveal a seed phrase or private key.
Report suspected crime. U.S. victims can use FBI IC3; the FBI also publishes cryptocurrency fraud guidance.

Free public safety intelligence · no wallet required

Bridge Caution Board

Scores summarize observed warning factors in the currently loaded evidence. They are not failure probabilities, investment ratings, endorsements, or forecasts. Only route-specific v2 assessments with sufficient coverage and confidence receive a comparative rank; legacy records remain visible but unranked.

Built-in snapshot

Research only—no bridge access. Source links lead to documentation, incident reports, or government notices. This page does not link to an execution route or prepare any bridge action.

Built-in snapshot only

The dated built-in research snapshot is available. Live refresh stays disabled until the deployment ships both atomic feed files and pins their Ed25519 publisher key in this release.

XRPL routes eligible for rank0

High / critical caution0

Insufficient evidence0

Historical incident records0

Median evidence coverage—

Last successful refreshBuilt-in only

XRPL-connected route ranking

Eligible v2 routes are ranked from greatest observed caution to least. Ranking requires at least 75% weighted evidence coverage, confidence of 0.65, and confirmed route identity. Legacy and low-confidence records remain visible but receive no rank.

XRPL-connected bridge route caution ranking
Rank	Bridge / route	Caution	Evidence	Operational state	Protective action	Incidents	Freshness

Published caution formula

The v2 index is route- and version-specific. Each dimension is adjusted upward for uncertainty, weighted, and capped at 100. Unknown evidence never subtracts caution.

Validation and proof model22%

Keys, permissions, and governance20%

Upgradeability and change control14%

Collateral, solvency, and exit liquidity13%

Incident history and remediation15%

Audit scope and evidence freshness10%

Current operational status6%

Bands: 0–24 lower observed caution; 25–49 elevated; 50–74 high; 75–100 critical. Confidence is published separately. Critical floors are 95 for confirmed active exploitation, forged/replayed messages, unauthorized mint/release, or verified collateral deficit; 85 for compromised control authority or security-disabled withdrawals; and 75 plus unverified status for unresolved route identity conflicts or expired critical telemetry.

Uncertainty adjustment: each dimension uses e = x + (100 − x) × 0.5 × (1 − q), where x is evidenced caution and q is 0–1 source confidence. Confidence below 0.40 forces the dimension to Unknown before adjustment.

Migration rule: built-in v1 factors are retained only as legacy diagnostics. They cannot become high-confidence v2 values through automatic conversion and are not eligible for ranking.

Failure rate rule: the page does not calculate a “failure rate” unless a complete incident numerator and an auditable operating-time or transfer denominator exist. None of the built-in records currently meet that standard.

Curated cross-chain incident timeline

This is a bounded evidence library—not a complete census. Fiat values can be estimates taken at different times and are not added into a misleading industry-loss total.

Feed architecture, source tiers, and update limits

Tier 1Validated on-chain evidence, government notice, or official operator postmortem.

Tier 2Established security research or analytics with a stated method.

Tier 3News or discovery lead requiring independent confirmation.

UnknownMissing, stale, conflicting, or unsupported; never treated as favorable.

NIST IR 8475 — Web3 security perspectiveSupports treating bridges, wallets, smart contracts, servers, oracles, and dependencies as separate attack layers requiring continuous monitoring.

NIST Cybersecurity Framework 2.0Informs the Govern, Identify, Protect, Detect, Respond, and Recover control view. This page is an adaptation, not NIST certification.

CISA Secure by DesignInforms fail-closed defaults, customer-protection outcomes, vulnerability transparency, and clear ownership of security consequences.

Ethereum.org bridge risksGrounds explicit trust assumptions: counterparty, custodial, censorship, smart-contract, user, chain, and operator risks.

XRPL XLS-38 cross-chain bridge specificationGrounds XRPL-native bridge concepts including doors, witnesses, attestations, quorum, claims, and replay-sensitive claim IDs.

RAID 2024 bridge-security systematizationInforms the attack-surface taxonomy across permissions, logic, events, front ends, verification mechanisms, and cross-domain communication.

NIST SP 800-30 Rev. 1 — risk assessmentInforms explicit threat, vulnerability, likelihood, impact, uncertainty, and evidence-quality fields. The caution index is an XRBitcoinCash method, not a NIST score.

OWASP Smart Contract Security Weakness EnumerationSupports precise control checks for authorization, upgradeability, oracle and event handling, replay resistance, and unsafe external dependencies.

W3C PROV-O provenance modelSupports source attribution and derived-record lineage so an observation can be traced to who asserted it, when, and from which evidence.

RFC 8785 JSON Canonicalization SchemeDefines the canonical JSON approach used for deterministic evidence digests and the future signed snapshot pipeline.

Method boundary: these sources shape the questions and taxonomy. None endorses XRBitcoinCash, this implementation, any listed bridge, or any score.

Vetted read-only adapter candidates for the future proxy

WanBridge operator API: token-pair hash/pairs, TVL, signer-group identity, and transaction status. The current XRP address conflict must remain a blocking observation until reconciled.
Across, LI.FI, Socket, Connext, and deBridge status feeds: operational and incident-status context with per-source timestamps; an empty history means unknown, never zero incidents.
AxelarScan and Wormholescan: backend-only operational observations until CORS, quotas, retention, and redistribution rights are confirmed.
DefiLlama: licensed server-side use only. No Pro key may appear in browser code, URLs, logs, exports, or client-visible errors.
CISA KEV, NVD, FBI/IC3, DOJ, and OFAC: cached corroboration and component/compliance context. Government publication feeds do not produce bridge failure rates, and sanctions are never mixed into the technical caution score.

Production update path: the browser reads only same-origin curated JSON. Licensed or rate-limited upstream services, CISA KEV, NVD, operator status pages, and chain-specific RPCs belong behind a cached read-only proxy with schema validation, per-source timestamps, complete-snapshot digests, sourced tombstones, and partial-failure isolation. Incident resolution must use the structured resolutionState field; prose such as “not restored” is never parsed as proof of recovery. CISA/NVD can identify vulnerable components; they do not by themselves prove a bridge incident.

Current integrity boundary: a SHA-256 field inside the same JSON detects accidental inconsistency but does not authenticate its publisher. Dynamic records remain advisory and cannot receive a favorable comparative rank unless a future snapshot carries a valid Ed25519 signature from a pinned key. The browser also remembers accepted revision numbers only on that browser; the durable append-only audit record belongs on the server.

Deployment security checklist: serve an HTTP Content-Security-Policy that uses nonces or hashes and includes frame-ancestors 'none'; add HSTS, X-Content-Type-Options: nosniff, a restrictive Permissions-Policy, and Referrer-Policy: no-referrer; self-host and version-pin the reviewed Xaman SDK instead of depending indefinitely on an unversioned remote script. This source file cannot claim those response headers are deployed.

Free public safety directory · reusable XRBC gate for advanced tools

Bridge Warnings Stay Public; Advanced Watchdog Tools Require 10 XRBC

Anyone can browse listed bridges, status colors, known incidents, vault addresses, contracts, review dates, and source links without a wallet. A Xaman-selected account with an observed balance of at least 10 XRBC unlocks local custom profiles, technical scans, deposit analysis, reconciliation, evidence exports, and bridge-review submission files. Account selection is not proof that the visitor controls its keys.

Public access active

Reusable participation gate

Connect Xaman and Check the Selected Account

XRBC remains in the wallet. This page does not transfer, lock, burn, escrow, consume, or take custody of the tokens.

Not checked

Wallet stateNot connected

XRPL account—

XRBC balance—

Amount shortNot checked

Advanced accessLocked

Balance verificationNot checked

Connection modeReady

Selected bridgeNone selected

Connect Xaman to check whether the selected account's public XRBC balance meets the reusable 10 XRBC interface requirement. Public bridge safety information remains available without connecting.

Network and authorization disclosure: after consent, the browser sends the selected public XRPL account and the public XRBC issuer/currency identifiers from your IP address to xrplcluster.com and s1.ripple.com. Those operators can observe the request metadata. Xaman account selection plus a public balance lookup does not prove key control. The 10 XRBC check is a client-side interface gate only; any future protected server endpoint must use its own nonce/signature authentication, authorization, balance check, and rate limits.

Advanced controls are locked. Public bridge profiles, warnings, incident reports, published addresses with verification state, and source links remain free.

Xaman wallet identification

This artifact deliberately refuses an unversioned remote SDK. After an audited SDK file and its exact SRI digest are deployed, desktop authorization can use Xaman's QR flow and mobile can use Xaman authorization. Until then, public safety tools remain available and the local 10 XRBC gate stays locked.

Optional future server-side advanced API

The current release is complete as a public observatory and local analysis workspace. The browser gate controls only local interface features. If protected remote functions are added later, the backend must independently re-verify wallet ownership, XRBC balance, request limits, payload size, and duplicate submissions for every request.

Free public bridge research is active. Wallet connection is optional and creates no XRPL transaction.

Use every bridge at your own risk. Caution scores and evidence bands are research classifications—not guarantees, endorsements, legal findings, or predictions. Bridge software, operators, contracts, addresses, and status can change after review.

XRBitcoinCash does not operate the listed bridges and is not responsible for losses, failed transfers, malicious interfaces, incorrect third-party data, delayed updates, or decisions made from this monitor.

Current review state

Custom Review Workspace State

These values describe only the gated local case workspace below; they do not override the public bridge ranking or establish live bridge health.

No analysis

Overall stateNot reviewed

Backing ratioUnknown

Critical findings0

Last local analysis—

XRP LedgerValidated source transaction

Bridge vaultActual balance must increase

Relayers / witnessesEvidence and signatures

Destination chainMatching mint or release

Seven-stage bridge integrity workspace

Build, Test, Reconcile, and Preserve

Use Beginner mode for plain explanations, Guided mode for the recommended workflow, or Expert mode for full technical fields.

Advanced tools locked

Public safety access stays open: the monitored bridge directory, status colors, incident warnings, addresses, contracts, and supporting sources do not require a wallet. Controls that create custom profiles, run technical analysis, export evidence, or prepare bridge submissions require the reusable 10 XRBC gate.

Privacy-first local workspace: only display mode, current step, and selected public directory record are saved automatically in this browser. Technical inputs, findings, wallet identifiers, activity logs, and evidence are never restored from browser storage. The gated Download PRIVATE Project file intentionally contains raw source code, transaction/metadata/event JSON, notes, endpoint configuration, reserve/liability values, and possibly account identifiers; store it securely and do not publish it. The separate evidence pack is privacy-reduced. If an older release left a technical workspace here, this version neither loads nor deletes it automatically: private backup recovery remains gated, while permanent local deletion is always available after explicit confirmation and never requires a wallet. Public refresh requests only the two same-origin curated JSON feeds named above. No request runs until a visitor deliberately refreshes or starts monitoring.

Stage 1

Identify the Bridge

Tell the monitor which account should receive funds and which chain should create the matching representation.

Not configured

Bridge profile

Choose a bridge from the monitored directory

Selecting an entry automatically fills the destination chain, XRPL vault or door account, contract/module, asset, endpoints, and known warning notes.

Blue: lower observed caution in the dated evidence; never a safety guarantee Yellow: elevated caution, insufficient evidence, changed support, or warning signals Red: high or critical caution from sourced incident, halt, insolvency, address conflict, or material control failure; confirmation tier remains visible

No bridge selected

Use the directory instead of typing technical addresses. Unknown or externally discovered bridges remain yellow until their accounts and contracts are independently verified.

The built-in dated snapshot is available. Refresh checks same-origin curated directory and incident feeds only.

Directory update sources and limitations

The same-origin files /xrpl-bridge-directory.json and /xrpl-bridge-incidents.json are the browser-facing curated feeds. Each must supply snapshotType:"complete", normalizationVersion:"XRBC-BRIDGE-NORMALIZATION-2.0", a schema envelope, an unambiguous signed source registry binding every origin to a controllerId, controlGroup (common ownership or control), and sourceClass, plus revision, monotonic revisionSequence, recordCount, canonical recordsSha256, full manifestSha256, and updatedAt. Controller, origin, and control-group diversity are measured separately; favorable corroboration requires at least two control groups, so two domains or brands under common control are not counted as independent. Every removal must retain a structured tombstone with id, removedAt, reason, HTTPS sourceUrl and archiveUrl, controllerId, controlGroup, sourceClass, evidenceSha256, and matching removedRecordSha256/archiveSha256. New tombstones must hash-bind the exact prior accepted record and be dated after the prior snapshot. The manifest covers the normalized records, source registry, tombstones, schema, versions, record count, revision, sequence, and update time. Dynamic v2 route records must use an exact operational state from operational-confirmed, paused-confirmed, incident-confirmed, deprecated-confirmed, unverified-claim, or unknown; operations evidence must bind that exact state, and only operational-confirmed can be rank-eligible. A favorable comparative rank additionally requires a valid Ed25519 signature from a key pinned in this release and durable monotonic replay continuity outside ordinary browser storage. This standalone release keeps a cross-tab synchronized browser guard as a rollback alarm, but deliberately withholds favorable dynamic ranks until an append-only server-side continuity service is implemented. Partial, malformed, truncated, replayed, older, invalidly signed, or non-persistable payloads are rejected or withheld from favorable ranking without erasing the prior safety baseline. The publisher attests the signed control-group mapping; production curation must verify corporate ownership and shared governance before each release. The legacy DefiLlama bridges endpoint is not called: its current documented bridge API is paid and the old URL is not a dependable public integrity source. Bithomp, chain RPCs, government vulnerability feeds, and licensed aggregators may be normalized later by the read-only proxy; no private key belongs in this page.

Removal continuity: every tombstone also carries its record kind, exact affected route IDs, prior resolution state, prior severity, prior safety floor, and retained technical-route fingerprint. Those fields must equal the prior browser-accepted risk projection. Unresolved incident removals keep blocking their routes, and a tombstoned route identity cannot reappear under a fresh ID to escape its history.

Atomic release contract: both feeds must share the exact datasetId, datasetRevision, release revision, monotonic sequence, millisecond UTC timestamp, RFC 8785 canonicalization identifier, and cross-digest bundle. Each complete normalized manifest must verify under the same pinned Ed25519 publisher key before either feed can advance. Any mismatch retains the previously accepted pair. Browser tabs read-compare-merge the local guard and synchronize storage changes; that is defense in depth, not an authoritative append-only ledger.

Bridge name Destination blockchain Destination network / chain ID XRPL bridge vault or door account XRPL destination-tag policy

A correct vault with a wrong tag can route value incorrectly. “Unknown” never receives a favorable source-record result.

Required DestinationTag Destination contract or module Route mechanism

The built-in transaction analyzer currently supports only the Payment-to-vault mechanism and fails closed for every other model.

XRPL asset XRPL issuer Destination token contract / denom Bridge fee model

Only a route-evidenced flat source-asset model is supported by this release.

Bridge fee asset Exact bridge fee value

Percent, destination-gas, tiered, or dynamic fees require a separate invariant pack and must not be forced into this field.

Published signer/evidence threshold Maximum single withdrawal (% of reserves)

Compared with optional destination-event telemetry during reconciliation.

Maximum hourly reserve drain (%)

Compared with optional destination-event telemetry; missing telemetry produces an explicit warning.

New bridge review submission: verified advanced users can prepare a structured JSON submission for a new bridge or a correction to an existing record. This beta creates a local submission file; it does not publish or change a directory classification automatically.

Official documentation, status, or incident URL Review request and supporting details

Stage 7

Generate and Verify the Bridge Evidence Pack

After every required stage has been rerun, the privacy-preserving evidence index binds each raw input by SHA-256, includes derived findings and timestamps, and is canonicalized for a final SHA-256 digest. Raw private inputs stay out of this evidence file and are available only in the separate full project download. Nothing is uploaded by this page.

Deterministic local record

Schema—

SHA-256—

Generated—

Findings recorded0

No evidence pack has been generated.

Important boundaries

What This Page Can and Cannot Establish

Defensive analysis

It can expose inconsistent supplied or sourced facts

Useful

Examples include a payment sent to the wrong destination, no increase in the bridge vault, a destination mint without a consistent source record, duplicate source hashes, or supplied liabilities exceeding supplied reserves.

It cannot prove intent from a coding omission

Caution

A missing check may result from negligence, misunderstanding, poor testing, unsafe design, or deliberate conduct. Intent requires evidence beyond a local code screen.

Public source may not equal deployed software

Caution

Production monitoring should compare signed build hashes, image digests, contract versions, signer lists, and relayer attestations with the reviewed source.

Unknown is not safe

Rule

Unavailable metadata, endpoint disagreement, unverified supply, or an unreadable contract state should remain unknown or blocked rather than being converted into a favorable score.

Local audit trail

Activity Log

The log records local actions taken during this browser session and saved project.

Bridge Integrity Watchtower

Stop Before You Send: 60-Second Bridge Safety Screen

Bridge Caution Board

XRPL-connected route ranking

Bridge Warnings Stay Public; Advanced Watchdog Tools Require 10 XRBC

Connect Xaman and Check the Selected Account

Custom Review Workspace State

Build, Test, Reconcile, and Preserve

Identify the Bridge

Choose a bridge from the monitored directory

No bridge selected

Review the Data Endpoints

Required Security Invariants

Screen Public Bridge Source Code

Check a Supplied XRPL Deposit Record

Compare Supplied Cross-Chain and Reserve Records

Generate and Verify the Bridge Evidence Pack

What This Page Can and Cannot Establish

It can expose inconsistent supplied or sourced facts

It cannot prove intent from a coding omission

Public source may not equal deployed software

Unknown is not safe

Activity Log