Repository navigation
feat: token allowlists, multisig ownership, timelock delays, and exposure limits (#1086 #1087 #1088 #1091) - #1
Open
software321dev wants to merge 256 commits into
Open
software321dev wants to merge 256 commits into
software321dev wants to merge 256 commits into
Conversation
…AST analyzer - Add AST types (AstContractNode, AstFunctionNode, SecurityCheckResult, BridgeSecurityIssue) - Create ReplayDetector — flags missing replay protection, origin checks, and reentrancy guards - Create OriginChecker — flags arbitrary .call()/.delegatecall() without address allowlisting - Create BridgeSecurityAnalyzer — orchestrates both detectors and produces unified security reports - Add singleton instance export (bridgeSecurityAnalyzer) matching existing analysis patterns - Add 17 unit tests across all 3 modules with 100% pass rate - Wire exports through analysis/index.ts barrel Closes MDTechLabs#746
- Create packages/rules/ package (@bridgewise/rules) with package.json, tsconfig, jest.config - Add DoubleSignChecker — tracks attestations by relayer+sequence, detects double-sign conflicts - Add SlashingMonitor — EventEmitter-based monitor with pre-sign verification middleware, risk scoring, and periodic health checks - Define full type system: AttestationRecord, DoubleSignEvent, PreSignResult, SlashingRiskReport - Add 22 unit tests covering conflict detection, risk scoring, event emission, and lifecycle management Closes MDTechLabs#745
…outing engine - Create libs/router/ package (@bridgewise/router) with package.json, tsconfig, jest.config - Add PathFinder with Dijkstra's algorithm for optimal bridge path discovery - Add CostCalculator for fee and latency estimation across chains (Stellar, Ethereum, Polygon, Arbitrum, Optimism, Base, BSC, Avalanche, Gnosis, Solana) - Support 3 routing strategies: cheapest, fastest, balanced - Handle edge constraints: liquidity, active status, provider exclusion, max hops - Support multi-hop routing through intermediate chain/asset nodes - Add 20 unit tests across PathFinder and CostCalculator Closes MDTechLabs#744
…verification engine - Create packages/verification/ package (@bridgewise/verification) with package.json, tsconfig, jest.config - Add HeaderVerifier — validates block header structure, chain continuity, state root transitions, generates state proofs - Add SyncCommitteeVerifier — BLS aggregate signature verification, quorum checks (2/3 threshold), committee period validation - Define full type system: BlockHeader, SyncCommittee, BLSSignature, StateProof, HeaderVerificationResult, LightClientConfig - Add 26 unit tests covering header validation, chain continuity, state transitions, BLS signature verification, quorum, and committee period checks Closes MDTechLabs#743
…ht-client [CORE] Implement On-Chain Light Client Header & State Verification Engine
…regator Hifeat: implement multi-chain gas & token price oracle aggregator
…rvice feat: implement production-grade multi-chain message relayer service
…rter feat: create structured CSV/JSON bridge audit trail exporter
…etector feat(indexer): add chain re-org detector and finality confirmation en…
…el, and challenge window monitor - apps/api/src/relayer: /api/v1/relayer/estimate-fee endpoint that estimates destination gas cost plus relayer margin for a cross-chain payload. - libs/indexer: WebSocketReconnector for RPC event listeners, reconnecting with exponential backoff and jitter and re-subscribing to missed block ranges on reconnect. - apps/dashboard: ChainHealthGrid component and useChainHealth hook showing per-chain RPC latency, sync height, and relayer wallet gas balance, with low/critical balance warnings and 15s auto-refresh. - packages/analyzers: ChallengeMonitor for optimistic bridge state root assertions, validating against canonical source-chain state and alerting once a dispute window has 20% or less time remaining. - Fix a pre-existing build break in transfer-state-machine.controller.ts (type-only import under isolatedModules) and an outdated pnpm-lock.yaml, both of which were failing CI on main independently of this change. Closes MDTechLabs#730 Closes MDTechLabs#731 Closes MDTechLabs#732 Closes MDTechLabs#733
…-733-relay-monitoring Relay fee estimation API, RPC reconnect backoff, chain health panel, and challenge window monitor
…melock feat: implement optimistic release timelock with guardian veto
feat: implement dynamic volume-based relayer fee module
… congestion monitoring integration
…TechLabs#747) - Add EVM and Soroban chain simulators with deterministic block production - Add bridge relay with replay protection and health control - Add fraud injector with 4 attack vectors (invalid state root, relayer tamper, relayer failure, double spend) - Add ChallengeMonitor integration for fraud detection lifecycle - Add end-to-end test suite with 21 tests across 7 describe blocks - Add dedicated jest config (node environment) and test:simulation script
…-config validator - contracts/tokens/BridgeWrappedToken.sol: ERC20Burnable + AccessControl with MINTER_ROLE/BURNER_ROLE restricted to the bridge vault. - contracts/core/BridgeReceiverBase.sol: OpenZeppelin Pausable circuit breaker; receiveMessage/withdrawLiquidity gated by whenNotPaused, pause/unpause under GUARDIAN_ROLE. - contracts/soroban/bridge_vault: RentExtended/StorageReclaimed telemetry events on TTL extension and temporary-storage cleanup. - packages/config/src/chain-schema.ts: strict, zero-dependency ChainConfig validator with descriptive errors and a startup assertion, plus tests. Added alongside the existing config utilities without modifying them.
…usable-receiver-soroban-telemetry-chain-schema feat: wrapped token, pausable receiver, soroban rent telemetry, chain-config validator
Closes MDTechLabs#734 - libs/crypto/src/merkle/tree-builder.ts: MerkleTreeBuilder that builds incremental binary Merkle trees from cross-chain message batches and generates compact inclusion proofs (branch, root, index, leaf hash). Supports both sha256 and keccak256 hash algorithms. - libs/crypto/src/merkle/proof-verifier.ts: ProofVerifier with verify(), verifyRawLeaf(), and static verifyProof() helpers — compatible with Solidity keccak256 and Rust/Soroban sha256 verification logic. - libs/crypto/tests/merkle.spec.ts: comprehensive unit tests covering valid proof generation/verification, tampered leaf rejection, odd-sized trees, single-leaf edge cases, and out-of-bounds guard rails.
…Chain-Automated-Liquidity-Rebalancing-Vault feat:Implement Cross-Chain Automated Liquidity Rebalancing Vault
…e-issues-734-737 feat(stellar-wave): implement Merkle proof service, closes MDTechLabs#734 MDTechLabs#735 MDTechLabs#736 MDTechLabs#737
…graph Closes MDTechLabs#1067 and MDTechLabs#1068. 60 new tests, all passing. Both features are new directories — no existing source file is touched. ## MDTechLabs#1067 — Soroban contract integration health `src/contracts/health/soroban/` runs four checks in order, because each is only meaningful if the previous one passed: 1. **Availability** — is the contract there? 2. **Network** — did the *expected* network answer? 3. **Interface** — are the methods the integration calls actually present? 4. **Read** — do safe reads succeed, and return something sensible? Three decisions worth review: **When the contract is absent, the later checks are skipped rather than failed.** Reporting "interface check failed" for a contract that does not exist buries the one fact that matters, and each skip records why. **A wrong network is `unhealthy`, not a warning.** A contract answering from testnet when the integration is configured for mainnet is worse than one that does not answer at all — the integration looks fine while reading someone else's state. **Severity is graded rather than binary.** A missing method or a wrong network means the integration cannot work, so `unhealthy`. A failing read on an otherwise correct contract is `degraded` — the wiring is right and the fault may be transient, and those warrant different responses. Every probe is bounded by a timeout. An integration that never answers is not healthy, and without a bound the health check would hang along with it. `src/monitoring/contracts/` aggregates results across integrations and keeps a short history, because one failing check cannot distinguish an RPC blip from an integration broken since deploy. `isPersistentlyFailing` is that distinction. A sweep that throws for one contract yields `unknown` for that one rather than failing the sweep — one unreachable integration must not hide the status of the others. An empty monitor reports `unknown`, not `healthy`: saying "healthy" when nothing is registered would hide a misconfiguration. ## MDTechLabs#1068 — Stellar bridge provider dependency graph `src/providers/dependencies/stellar/` models what each provider needs — RPC, Horizon, contracts, liquidity sources, APIs — and derives provider health from it. The problem is attribution. The symptom is "provider X is down"; the cause is usually one shared RPC endpoint or price API sitting underneath several providers. The graph makes that a lookup rather than an investigation: record the dependency unhealthy once and every dependent provider reports the reason rather than a bare failure. Grading, which is the point of the model: - a **critical** dependency unhealthy → provider **unhealthy**; it cannot serve - a critical dependency degraded, or a **non-critical** one unhealthy → provider **degraded**; it serves, worse - a critical dependency that has never reported → **unknown** That last one is deliberate. Claiming health for something never checked is how a dashboard ends up lying, so `healthyProviderIds` excludes unknown providers rather than handing them traffic. A provider declaring a dependency that is not registered is rejected at registration — it would otherwise have nothing to check and silently report healthy. `impactOf` answers "is this endpoint safe to take out of rotation?" without recording a failure first. `src/providers/health/` rolls this into a fleet view whose `rootCauses` groups failures by the dependency responsible, widest blast radius first: five providers failing for one reason is one problem, not five. ## Verification pnpm exec jest tests/contracts tests/providers 60 passed pnpm run build green (CI's gate) eslint on every new src file clean tsc --noEmit clean Note on staging: `node_modules` is tracked in this repository (13,336 files), and installing dependencies locally modifies thousands of them. Only the 13 files above are staged; nothing under `node_modules` is included.
Implements MDTechLabs#1066 and MDTechLabs#1065. MDTechLabs#1066 — Deterministic fingerprints for Soroban deployments over the fields that define a deployment's identity: contract address, network, wasm hash, spec version and a canonical digest of the interface surface. Observation-time context is deliberately excluded so the same deployment seen twice fingerprints identically. Approved fingerprints are stored per contract and network, revocation is retained for audit, and the verifier reports approved / mismatch / revoked / unknown separately with the specific differences. MDTechLabs#1065 — Upgrade detection compares each observation against the tracked fingerprint, classifies what changed (wasm, spec version, functions added or removed, events, error codes, redeploy), grades severity, records the event, flags every integration that depended on the previous deployment, and notifies the registered monitoring sinks. A removed function is critical; new code behind an unchanged interface is major, since nothing visible would otherwise stop it being trusted. 116 tests pass. tsc --strict and eslint are clean over the new files.
feat: implement Soroban transaction validation, rebuild, confirmation, and review services
…th-and-provider-dependency-graph Soroban contract integration health checks and Stellar provider dependency graph
…tract-upgrade-detection-and-deployment-fingerprinting feat(security): Soroban deployment fingerprinting and contract upgrade detection
feat: add Stellar bridge provider adapter interface
…tellar-route-revalidation feat: implement Stellar route revalidation
…tellar-provider-failure-attribution feat: implement Stellar provider failure attribution
…n-reconciliation feat(reconciliation): implement Stellar/EVM transfer state reconcilia…
Add StellarBridgeDryRunService that validates a Stellar bridge execution without submitting a transaction. Builds an invocation plan, simulates each step via Soroban RPC, runs the full 7-check pre-execution safety pipeline, and returns structured results. Key additions: - src/execution/dry-run/stellar/stellar-bridge-dry-run.service.ts Core dry-run engine: request validation, invocation planning, step simulation, safety pipeline execution, and deterministic SHA-256 execution hash computation. - src/execution/dry-run/stellar/types.ts DryRunExecutionPlanRequest, DryRunExecutionResult, DryRunPlanStep, DryRunSimulationSummary, and DryRunSafetyContextBuilder type definitions. - src/execution/dry-run/stellar/index.ts Barrel re-exports for the dry-run module. - tests/execution/dry-run/stellar-bridge-dry-run.spec.ts 11 tests covering plan building, simulation delegation, hash determinism, summary aggregation, safety pass/block, input validation, and result structure. Also removes stale markdown code fences from the invocation planner source file. Refs MDTechLabs#1070
Implements route explainability model for Stellar bridge routes to expose the factors that influenced route selection decisions. Features: - Fee contribution analysis with scoring - Speed contribution analysis with scoring - Liquidity contribution analysis with scoring - Reliability contribution analysis with scoring - Risk contribution analysis with scoring - Human-readable explanations for route recommendations - Deterministic explanation output - Configurable scoring weights and factor labels - Customizable positive/negative threshold Implementation: - src/routing/explainability/stellar/types.ts - Type definitions - src/routing/explainability/stellar/route-explainer.ts - Main explainer class - src/routing/explainability/stellar/index.ts - Module exports - src/routing/scoring/route-scoring-factors.ts - Scoring factor calculations - src/routing/scoring/index.ts - Scoring module exports - tests/routing/explainability/route-explainer.spec.ts - Explainer tests - tests/routing/explainability/route-scoring-factors.spec.ts - Scoring tests Acceptance Criteria: - Route explainability model implemented ✓ - Scoring factors exposed ✓ - Route recommendation can be explained ✓ - Explanation output is deterministic ✓
…oute-explainability-model feat: Implement Stellar Bridge Route Explainability Model
…ment-stellar-bridge-execution-dry Implement Stellar Bridge Execution Dry-Run Mode
Resonating changes added succesfully
All allocation for file eloquence have been inserted successfully
…ionality with tests
…ing for improved readability
…-issues-980-981-1030-1083 Feat/stellar minimal issues
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements mainnet-readiness and production-hardening controls for the BridgeWise protocol.
Issues
Changes
contracts/bridge/BridgeGateway.sol: token allowlist, per-token deposit caps, aggregate token/chain exposure limitscontracts/governance/BridgeMultiSigOwnable.sol: M-of-N multisig ownershipcontracts/governance/BridgeOwnable.sol: migrated to multisig ownershipcontracts/governance/TimelockGuardian.sol: minimum delay before executing sensitive admin actionscontracts/bridge/route.sol: route allowlist for chain/token pairscontracts/libraries/IPriceOracle.sol: new interface file required by existing oracle adapterTests
test/bridge/BridgeGateway.test.ts: allowlist, deposit caps, exposure limitstest/governance/BridgeOwnable.test.ts: multisig submit/confirm/executetest/governance/TimelockGuardian.test.ts: queue/execute/cancel timelock flow