CSPR <> EVM Bridge

Key themes observed across findings#

• Domain separation and replay protection for relayer signatures/attestations (contract + relayer hashing must be chain- and deployment-bound).

• Cross-chain correctness in multi-chain deployments, including chain-scoped event identifiers and correlation keys to prevent mis-attribution or suppression.

• Event verification gaps (e.g., ensuring expected topics/fields are validated, ensuring receipt/log inclusion checks are complete where required).

• Finality and reorg safety, especially where indexing/relaying relies on near-head chain data or lacks reorg reconciliation.

• Token registry/mapping lifecycle safety (updates, reverse mappings, uniqueness, and sentinel-value pitfalls).

• DoS/performance amplification risks (heavy endpoints, missing hard timeouts, unbounded in-memory sets/queues, and DB hot paths).

• Operational security (configuration/secrets handling, logging/metrics exposure, and reliability of third-party event sources like CSPR.cloud).

Main recommendations#

• Bind all relayer-signed payloads to a strict domain: incorporate chainId and contract deployment (address(this) or EIP-712 verifyingContract) into all attestation hashes verified by the EVM locker and ensure Casper-side hashing/ID rules are consistent with off-chain logic. This prevents cross-chain and cross-deployment signature replay.

• Harden replay protection and event identity across both chains: ensure deduplication/correlation keys include chain context and stable deposit identifiers (avoid collisions from (blockNumber, txIndex, logIndex)-style keys in multi-chain deployments).

• Make the Casper to EVM trust model explicit and hardened: since this direction typically lacks cryptographic state proofs, enforce stronger operational controls (conservative finality assumptions, robust peer authentication, strict relayer set governance, and clear incident/backfill procedures).

• Improve correctness of event verification: validate all required event fields/topics for lock/burn/processed checks, and ensure proof/receipt verification logic matches the intended security model.

• Add/clarify recovery semantics for partial failures: avoid "commit then hope" flows where one chain finalizes state changes but the destination execution can fail without a protocol-level resolution path; ensure admin/recovery mechanisms are explicit, auditable, and safe.

• Reduce DoS amplification and improve long-term liveness: add caching/rate limiting to expensive read endpoints, enforce hard timeouts and bounded retries, cap in-memory collections, and ensure persistence/replay guards are robust across restarts and multi-process deployments.

• Strengthen token mapping lifecycle invariants: ensure mapping updates clear stale reverse mappings, enforce uniqueness constraints where required, and avoid sentinel-value patterns that cause ambiguous "registered/unregistered" states.

Main components#

• EVM Chains (source/destination)

  • Run the MultiSigERC20Locker contracts.

  • Emit Lock/Burn events (for EVM > Casper flows).

  • Accept Unlock/Mint submissions (for Casper > EVM flows) when presented with enough valid relayer signatures.

• CLI / RELAYER (bridge-cli)

  • The "bridge brain." It has two core workers and shared infrastructure:

• Evm2Casper Worker

  • Polls EVM logs for lock/burn events.

  • Builds attestations from observed on-chain data.

  • Uses MPT proof verification for EVM data paths (stronger cryptographic verification).

  • Submits Casper-side actions (mint/unlock) once attestation rules are satisfied.

• Casper2Evm Worker

  • Observes Casper events (commonly via CSPR.cloud WebSocket).

  • Builds attestations for Casper > EVM actions.

  • Submits EVM-side unlock/mint calls once enough relayer signatures are collected.

• SignatureCoordinator (M-of-N threshold signing)

  • Collects signatures from authorized relayers and enforces the configured threshold.

  • Provides coordination/guardrails to reduce duplicate submissions and handle retries.

• Crypto Layer

  • Defines the exact hashing/signing scheme (Keccak256 + signing) and verification logic.

  • Must match the on-chain verifier logic exactly; otherwise signatures/attestations can fail or be replayable.

• P2P Server

  • Relayers communicate over P2P for coordination and signature exchange.

  • Uses authentication mechanisms (mTLS/challenge-response/message auth) to prevent unauthorized peers from participating.

• Casper Network

  • Runs two key contracts:

    • EthClient

      • Stores/checks EVM block header data used by bridge flows.

    • TokenFactory

      • Executes Casper-side mint/burn/unlock logic based on the bridge rules and relayer inputs.

• API (bridge-api) + MySQL

  • Indexers

    • EVM Indexer: polls per chain and stores observed bridge activity.

    • Casper Indexer: consumes Casper events (often via CSPR.cloud WS) and stores activity.

  • REST API (Express)

    • Exposes read-only endpoints like /tokens, /txs, /stats, /chains for explorers, dashboards, and integrations.

• MySQL Database

  • Persists transactions, token metadata/mappings, per-chain info, and sync cursors.

The two bridge directions#

1) EVM to Casper

• Observe: EVM lock/burn event appears on an EVM chain.

• Verify: relayer fetches logs/receipts and (in the stronger path) verifies inclusion using MPT proofs.

• Attest: relayer builds an attestation describing the event.

• Submit: relayer submits a Casper-side action to TokenFactory (mint/unlock).

2) Casper to EVM

• Observe: Casper-side event is detected (often through CSPR.cloud).

• Attest + Sign: relayers collectively sign an attestation (M-of-N).

• Submit: relayer submits the attestation + signatures to the EVM locker to execute unlock/mint.

Trust Boundaries#

• EVM RPC <> Relayer: if an RPC lies or is misconfigured, the relayer can ingest wrong chain data.

• CSPR.cloud <> Relayer/API: centralized event feed; without state proofs, correctness depends on relayer assumptions.

• Relayer <> Relayer (P2P): if auth/binding is weak, an attacker can spam/suppress/forge coordination messages.

• Relayer <> Contracts: signatures/attestations are an authorization mechanism, domain separation and replay protection are critical.

• Public API <> Internet: DoS or data poisoning can degrade observability and sometimes impact shared DB resources.

Key architectural asymmetry#

• EVM to Casper can use cryptographic inclusion proofs (MPT verification).

• Casper to EVM typically relies on M-of-N relayer consensus rather than Casper state proofs.

This asymmetry is important because it means Casper > EVM safety depends more heavily on relayer key security, threshold configuration, and operational controls, while EVM > Casper has a stronger path when proofs are verified correctly.

Review coverage#

Halborn re-reviewed all 116 findings against origin/master across three passes. The initial remediation review was performed at 91cbce7ffa59ed7f096fab9baf9c94e39e0e211e; the eight findings still open after that round were re-verified at 44e2aa739e7e1bed176c632740d8ec10dcf20ef4 (2026-08-06); and the three residuals remaining after that pass, together with a new configuration-layer observation raised in it, were re-verified at 8b01aa3de58e5362ea36d736801b9c45ab9e7b20 (2026-08-07). Verification was performed against those revisions rather than against the remediation merges alone, so the dispositions below also account for the commits that landed afterwards.

Current disposition and residuals#

• Live finding state: 108 Solved; 5 Risk Accepted; 3 Acknowledged. No finding remains partially remediated.
• Closed in the second pass: HAL-013 (plaintext bare-IP public node list removed; verification quorum defaults to two and fails closed on unset, with non-HTTPS public sources dropped under the production flag the image itself bakes in), HAL-024 (brace-expansion pinned to a backport carrying the ReDoS cap, both production closures audit clean), HAL-068 (P2P_ALLOW_PRIVATE_PEER_ENDPOINTS removed from every template and ignored in code, replaced by a fail-closed CIDR allowlist, with announce identity bound to the authenticated signer), HAL-076 (both documented metadata call sites timeout-bounded and length-capped, including the one feeding Prometheus labels) and HAL-077 (deployed database enforces require_secure_transport=ON with a pinned CA, superseding the earlier acceptance with a full fix).
• Closed in the third pass: HAL-070, fetchDeploysPage now throws on request failure on both the API indexer and the relayer REST fallback, so a transient error can no longer be mistaken for a drained backlog; the drain predicate excludes failure, the cursor is held and the failed page is retried, and the accompanying tests are genuine failure-path regressions rather than restatements of the fixed behaviour. HAL-079, the fifth call site is bounded with a ten-second abort and /rpc normalization is applied at all five named sites through a canonical helper, so the built-in default no longer yields a doubled suffix; the related unbounded CSPR.cloud REST fetches are bounded on both sides. HAL-110, the thirteenth destructive Casper admin command is gated by the confirmation helper with a -y/--yes flag and covered in the prompt, abort and bypass test matrix.
• Configuration-layer theme: the most durable observation of the engagement, and the one most worth carrying forward operationally. All three instances have now been addressed: HAL-068 and HAL-077 at the configuration layer, and the third, a Helm/Kubernetes surface shipping P2P_TLS_ENABLED: "false", in code. validateConfig() now raises a fatal error when NODE_ENV=production and P2P TLS is disabled, and because the image bakes that environment in, a deployment surface that merely disables TLS will refuse to boot rather than silently removing the mTLS compensating control that HAL-016 and HAL-038 rely on. One residual is recorded against both of those findings: the P2P_ALLOW_PLAINTEXT=true escape hatch is evaluated independently of environment, so it suppresses the guard in production as well, no runtime warning fires while it is active, and in the shipped dev values it sits directly beneath the disabled-TLS line, so copying that block to a production values file carries the bypass with it. Scoping the bypass to non-production and warning whenever plaintext P2P is active would complete the closure; as it stands the control can no longer be disabled implicitly, only explicitly.
• Risk decisions: Risk Accepted are HAL-004 and HAL-010 (no on-chain refund, expiry, or user cancellation; recovery is operator mediated), HAL-034 (signing key held as a process-lifetime string with no remote signer or zeroization), HAL-062 (duplicate submission under partition remains reachable but is bounded to gas by the on-chain processed-event guards), and HAL-100 (casperStateRoot remains a zero placeholder, with safety resting on the threshold attestation model). Acknowledged are HAL-088, HAL-094, and HAL-103; the HAL-094 rationale has been updated because the single-EVM assumption no longer holds against the current multi-chain relayer configuration.
• Post-report disclosure (2026-08-06): the client disclosed a shared AWS IAM policy/instance profile that had briefly let any single compromised host (including the API host and the WireGuard concentrator) read all relayer signing keys, narrowing the M-of-N threshold that HAL-100's risk acceptance relies on toward 1-of-N for the period it existed. This was an infrastructure/IAM-configuration exposure, not visible from source and outside this engagement's review scope; it is not a separate Halborn finding. It has since been remediated with one IAM role/instance profile per host and a verified, re-runnable isolation probe. Recorded on the HAL-100 finding for traceability; the underlying risk-acceptance rationale is otherwise unchanged.
• Reference corrections: 45 of the 105 client-supplied commit hashes are not ancestors of current master, reflecting squash and rebase during merge rather than missing work; landed equivalents were substituted where identified. The same applies to the second follow-up round, where the supplied hashes did not resolve in the published history. All verdicts therefore rest on the state of the head revision reviewed in each pass rather than on the cited commits.
• Follow-up attack surface: code introduced after the remediation rounds was not part of the original assessment and merits separate review, specifically the EVM WebSocket log listener added for fast chains, the Arbitrum Orbit chain onboarding with its CREATE2 deployment path and schema migrations, the codified security group definitions, and the Helm/Kubernetes deployment surface under infra/values/, which introduces a second deployment path alongside Ansible with its own configuration posture.