Stargate Finance · DeFi Risk

DeploymentsEthereum · $120.0M

Risk profile at a glance

0 red · 0 yellow · 3 green

Categories & evidence

184 factors · 13 categories

Code & audits Green 12 25 of 25

RD-F-009 red Formal verification coverage No formal verification (Certora, Kani, Halmos) evidence found for Stargate v2 contracts. No FV report in the repo, no FV tooling configuration files identified. LayerZero v2 endpoint itself was subject to a Certora assessment (Aug-Sep 2023) but this covers the messaging layer, not Stargate's pool contracts. RD-F-001 yellow Audit scope mismatch Two v2 audit PDFs exist in the `audits/` folder of the GitHub repo (Zellic FINAL and OtterSec Final). Etherscan confirms StargatePoolUSDC at 0xc026395860Db2d07ee33e05fE50ed7bD583189C7 is source-verified at `v0.8.22+commit.4fc1097e` with "Exact Match." However, the Zellic report is inaccessible via web fetch (HTTP 403 on reports.zellic.io), so the specific commit SHA cited in the reports cannot be independently verified against the deployed bytecode. Zellic's public page confirms a June 2024 r... RD-F-002 yellow Audit recency Zellic v2 final audit published June 2024 (per Zellic site listing). OtterSec audit similarly circa 2024. Assessment date is 2026-04-26, giving approximately 22-24 months since last audit of core contracts. This exceeds the 365-day green threshold. No re-audit of the deployed codebase post-2024 has been publicly identified (Hacken May 2025 covers only VeChain integration). RD-F-024 yellow Code complexity vs audit coverage Stargate v2 is a monorepo (50.3% Solidity, 44.6% TypeScript). Two audits were performed by Zellic and OtterSec prior to May 2024 launch. No specific LOC-per-audit-day metric is available without PDF access. Protocol has expanded significantly post-audit to 80+ chains. The ratio of new deployment surface to audit coverage is a concern, though core contracts are unchanged. RD-F-183 yellow Bug bounty scope gap on highest-TVL contracts Immunefi bounty lists 15 assets in scope on Ethereum: FeeLib variants (ETH, USDC, USDT, METIS, mETH), StargatePool variants (Native, USDC, USDT, METIS, mETH), StargateMultiRewarder, and StargateStaking. **TokenMessaging (0x6d6620eFa72948C5f68A3C8646d58C00d3f4A980) — the contract that routes cross-chain messages for all bridging — is not explicitly listed in the Immunefi in-scope asset list based on available data.** StargatePool contracts hold the primary TVL (~$92M aggregate as of 2026-05-07; down from ~$345M v2-peak), and those are in scope. The message-routing contract being potentially out-of-scope is a meaningful gap regardless of pool TVL magnitude. Score retained yellow: scope-gap concern is structural, not TVL-dependent. RD-F-003 gray Resolved-without-proof findings Zellic identified at least one "severe business logic bug" in Stargate v2 regarding token balance desynchronization across chains (per public Zellic writeup summary). The protocol's security page and no rekt.news entry suggest the finding was resolved. However, with the audit PDF inaccessible, individual finding IDs and their on-chain resolution proofs cannot be verified. The issue appears resolved given no exploit has occurred, but curator verification of the finding table is pending. RD-F-010 gray Static-analyzer high-severity count No published Slither, Mythril, or Semgrep output found for Stargate v2. Source is verified on Etherscan allowing tool runs, but no public analysis output has been found. The invariant test suite in `packages/stg-evm-v2/test/invariant/` indicates some property-based testing exists. Without a published static analysis run, this factor cannot be affirmatively assessed. RD-F-016 gray Divide-before-multiply pattern No published Slither output available. From source review, StargatePool uses SharedDecimals scaling for cross-chain amounts — arithmetic paths involve conversion factors. Without a Slither run on the deployed source, cannot affirmatively clear. Marking gray pending tool run. RD-F-020 n/a EIP-712 domain separator missing chainId Source inspection of TokenMessaging.sol shows no EIP-712 signature implementation. Stargate v2 does not use EIP-712 signed messages for its cross-chain flow — message authentication is handled by LayerZero's DVN network. N-A for the core bridge flow. RD-F-021 n/a UUPS _authorizeUpgrade correctly permissioned Stargate v2 contracts are non-upgradeable (no proxy pattern, no UUPS, no TransparentUpgradeableProxy). Constructors are used for initialization. No `_authorizeUpgrade` function exists or is needed. Factor is N-A for this architecture. RD-F-023 n/a Constructor calls _disableInitializers() N-A for Stargate v2 — no proxy pattern is used. `_disableInitializers()` is an OZ pattern specifically for implementation contracts deployed behind proxies to prevent direct initialization. Since Stargate v2 uses direct (non-proxy) deployments, this guard is unnecessary.

RD-F-004 green Audit count Two distinct firms audited v2: Zellic and OtterSec. Hacken audited the VeChain integration only. Three firms total, two covering the core v2 codebase. Meets the green threshold (≥2 firms).

RD-F-005 green Audit firm tier Zellic is classified as Tier-1 per the methodology template (explicitly listed: "Tier-1 (Trail of Bits / OpenZeppelin / ConsenSys Diligence / Certora / Sigma Prime / Spearbit / Zellic)"). OtterSec is a named, established firm with public track record — Tier-2. At least one Tier-1 audit exists.

RD-F-006 green Audit-to-deploy gap Zellic audit published circa June 2024; Stargate v2 mainnet deployed approximately May 29, 2024 (per web research). This implies the audit completed close to or around the deployment date — possibly audit completed pre-deploy (common pattern). Gap is estimated at ≤60 days, within green threshold. However, with precise dates unconfirmable from public data, confidence is medium.

RD-F-007 green Bug bounty presence & max payout Active Immunefi program with $10M maximum payout (10% of directly affected funds, min $100K). Launched September 2024. Program is active and one of the largest in DeFi. Exceeds the $500K threshold for green.

RD-F-008 green Ignored bounty disclosure No post-mortem documents an ignored disclosure for Stargate v2. No direct Stargate v2 exploit has occurred per Rekt database. The Kelp DAO exploit (Apr 2026) affected a different protocol using LayerZero with 1/1 DVN; Stargate uses 2/2 DVN and was not directly drained. No evidence of ignored bounty disclosures found.

RD-F-011 green SELFDESTRUCT reachable from non-admin path Direct source inspection of StargateBase.sol, StargatePool.sol, StargateOFT.sol, TokenMessaging.sol shows no SELFDESTRUCT opcode or `selfdestruct()` call. The contracts are non-upgradeable and do not use proxy patterns that could expose this.

RD-F-012 green delegatecall with user-controlled target Source inspection of all fetched Stargate v2 contracts (StargateBase, StargatePool, StargateOFT, TokenMessaging, Transfer.sol) reveals no `delegatecall` usage. The architecture uses direct function calls and interface calls.

RD-F-013 green Arbitrary call with user-controlled target Transfer.sol uses low-level `call` assembly for native ETH transfers and ERC20 calls via encoded function selectors, but these target fixed token contract addresses, not user-supplied targets. No unfiltered user-controlled call target found.

RD-F-014 green Reentrancy guard on external-calling functions StargatePool's core functions (deposit(), redeem(), redeemSend()) are protected by the custom `nonReentrantAndNotPaused` modifier inherited from StargateBase. This modifier uses a 3-state status variable (NOT_ENTERED=1, ENTERED=2, PAUSED=3) and reverts on reentrant calls. Equivalent to OpenZeppelin's ReentrancyGuard pattern.

RD-F-015 green ERC-777/1155/721 hook without reentrancy guard Stargate v2 primarily handles ERC-20 tokens (USDC, USDT, ETH native) and uses standard SafeERC20/IERC20 patterns. No ERC-777, ERC-1155, or ERC-721 integration found in core contracts. The TIP-20 standard used for cross-chain tokens is a custom standard, not ERC-777.

RD-F-017 green Mixed-decimals math without explicit scaling StargatePool.sol uses a `sharedDecimals` mechanism with explicit `_ld2sd()` (local decimals to shared decimals) and `_sd2ld()` (shared to local) conversion functions. This explicitly normalizes decimal differences between chains. The constructor takes both `_tokenDecimals` and `_sharedDecimals` parameters.

RD-F-018 green Signed/unsigned arithmetic confusion SafeCast (OZ) is imported in StargateBase.sol specifically to handle safe integer conversions. No evidence of signed/unsigned confusion patterns from source inspection of core contracts. However, without a full symbolic execution tool run, confidence is medium.

RD-F-019 green ecrecover zero-address return unchecked Source inspection of TokenMessaging.sol, StargatePool.sol, StargateBase.sol, and StargateOFT.sol shows no `ecrecover` calls. Stargate v2 does not use `ecrecover` in its cross-chain message verification — it delegates signature verification to LayerZero's DVN infrastructure (off-chain).

RD-F-022 green Public initialize() without initializer modifier Source inspection of all core contracts confirms no `initialize()` function exists in any inspected contract (StargatePool.sol, StargateBase.sol, StargateOFT.sol, StargateOFTAlt.sol, TokenMessaging.sol, StargateMultiRewarder.sol). Architecture is non-upgradeable constructor-based. This attack surface does not exist for Stargate v2.

Governance & admin Gray 0 24 of 24

RD-F-025 gray Admin key custody type yellow RD-F-026 gray Upgrade multisig signer configuration (M/N) yellow RD-F-027 gray Single admin EOA green RD-F-028 gray Low-threshold multisig vs TVL **RED** [★ CRITICAL] RD-F-029 gray Multisig signers co-hosted yellow RD-F-030 gray Hot-wallet signer flag yellow RD-F-031 gray Signer rotation recency yellow RD-F-032 gray Timelock duration on upgrades **RED** RD-F-033 gray Timelock on sensitive actions **RED** RD-F-034 gray Guardian/pause-keeper distinct from upgrader green RD-F-035 gray Role separation: upgrade ≠ fee ≠ oracle yellow RD-F-036 gray Flash-loanable voting weight green RD-F-037 gray Quorum achievable via single-entity flash loan green RD-F-038 gray Proposal execution delay < 24h N-A RD-F-039 gray delegatecall/call in proposal execution without allowlist green RD-F-040 gray Emergency-veto multisig present yellow RD-F-041 gray Rescue/emergencyWithdraw without timelock **RED** [★ CRITICAL] RD-F-042 gray Admin has mint() with unlimited max yellow RD-F-043 gray Admin = deployer EOA after 7 days green RD-F-044 gray Admin wallet interacts with flagged addresses gray RD-F-045 gray Constructor args match governance proposal gray RD-F-046 gray Contract unverified on Etherscan/Sourcify green RD-F-047 gray Governance token concentration (Gini) yellow RD-F-167 gray Deprecated contract paused but pause reversible by live admin yellow

Oracle & external dependencies Gray 0 17 of 17

RD-F-048 gray Oracle providers used Oracle providers used | No oracle in bridge execution path. FeeLibraryV07 uses Chainlink AggregatorV3Interface for stablecoin peg detection in fee calculations only. FeeLibV1 (GitHub repo) uses no oracle at all — fixed fee zones. | StargatePool.sol source inspection (no oracle imports); StargatePoolNative.sol (no oracle); FeeLibraryV07 on BaseScan 0x9d1b1669c73b033dfe47ae5a0164ab96df25b944 imports AggregatorV3Interface; FeeLibV1 source has no oracle. | GREEN RD-F-049 gray Oracle role per asset Oracle role per asset | Where used (FeeLibraryV07): Chainlink serves as Primary/Only for USDC, USDT, ETH in fee parameter calculation. Role is: fee-tier adjuster (Normal/Drift/Depeg states), NOT bridge execution gating. | FeeLibraryV07 BaseScan analysis; `_getPriceDiffAndDeviationState()` and `PriceDeviationState` enum (Normal/Drift/Depeg); poolIdToPriceFeed mapping per pool ID. | YELLOW RD-F-050 gray Dependency graph (protocols depended upon) Dependency graph | Primary external dependencies: (1) LayerZero v2 EndpointV2 — message routing; (2) Nethermind DVN + LayerZero DVN — message verification; (3) Circle USDC — collateral asset; (4) Tether USDT — collateral asset; (5) Chainlink feeds (FeeLib only, fee calc). Protocol cannot bridge without LayerZero. Collateral is entirely in third-party stablecoins subject to blacklist/freeze. | StargateBase.sol external calls to ILayerZeroEndpointV2; L2BEAT Stargate v2 dependency analysis; USDC... RD-F-051 gray Fallback behavior on oracle failure Fallback behavior on oracle failure | No fallback oracle in FeeLibraryV07. If Chainlink feed reverts or returns zero, `require(price >= 0)` would pass for price=0, and fee calculation would use zero-price. No secondary source, no circuit breaker that reverts on oracle failure specifically. FeeLibV1 has no oracle — no failure mode. | FeeLibraryV07 source: `(, int256 price, , ,) = AggregatorV3Interface(priceFeed).latestRoundData(); require(price >= 0)` — no revert on stale/zero. | RED RD-F-052 gray Breakage analysis per dependency Breakage analysis | See dependency graph section above. Bridge execution unaffected by oracle failure (oracle only in fee path). A stale FeeLib oracle could produce incorrect fees. A LayerZero outage = full bridge liveness failure. DVN collusion/compromise = full fund loss. Circle/Tether freeze = collateral lockup. | StargateBase.sol delegates all bridge exec to LayerZero; fee oracle separate from execution oracle. | YELLOW RD-F-053 gray Oracle source = spot DEX pool (no TWAP) Oracle source = spot DEX pool (no TWAP, no fallback) | NOT TRIGGERED. Bridge execution path has no DEX oracle. FeeLibraryV07 uses Chainlink (not spot DEX) for fee calculation only. No TWAP is needed or used because no DEX-based price feeds are present. | FeeLibV1.sol source inspection (no external oracle calls); StargatePool.sol (no oracle); FeeLibraryV07 source uses AggregatorV3Interface not DEX pool. | GREEN RD-F-054 gray TWAP window duration TWAP window duration | No TWAP used anywhere. Not applicable. | StargatePool.sol, FeeLibV1.sol, FeeLibraryV07 source inspection — no TWAP calls. | NOT_APPLICABLE RD-F-055 gray Oracle pool depth (USD) Underlying oracle pool depth | No DEX pool oracle. Chainlink feeds used in FeeLib are USDC/USD, USDT/USD, ETH/USD — deep-market Chainlink feeds with large aggregation networks, not DEX-pool-backed. | FeeLibraryV07 uses AggregatorV3Interface for major Chainlink feeds; no single-venue pool. | GREEN RD-F-056 gray Single-pool oracle (no medianization) Single-pool oracle (no medianization) | FeeLibraryV07 reads a single Chainlink aggregator per pool. Chainlink aggregators themselves are multi-node medianized, so single-aggregator ≠ single-node. Bridge execution has no oracle. | FeeLibraryV07 source: one priceFeed address per pool in poolIdToPriceFeed mapping. Chainlink aggregator contracts internally medianize across nodes. | YELLOW RD-F-057 gray Circuit breaker on price deviation Circuit breaker on price deviation | Partial. FeeLibraryV07 has PRICE_DEPEG_THRESHOLD (150 bps) that switches the fee tier to Depeg state, disabling drift fees. This is a soft circuit breaker on fee behavior, NOT a bridge halt. Does not prevent token release. | FeeLibraryV07 `_getPriceDiffAndDeviationState()` returns PriceDeviationState.Depeg when deviation > 150bps; this affects fee calculation only. | YELLOW RD-F-058 gray Max-deviation threshold (bps) Max-deviation threshold | FeeLib depeg threshold: 150 basis points (1.5%). Drift threshold: 10 basis points. These govern fee tier transitions only. No price deviation circuit breaker on bridge execution itself. | FeeLibraryV07 BaseScan: PRICE_DEPEG_THRESHOLD = 150 bps, implied DRIFT threshold ~10 bps from code structure. | YELLOW RD-F-059 gray Oracle staleness check present Oracle staleness check | RED FINDING. FeeLibraryV07 calls `latestRoundData()` but discards `updatedAt` return value. No check of the form `require(updatedAt >= block.timestamp - maxAge)`. The contract accepts any price regardless of how stale. | FeeLibraryV07 BaseScan: `(, int256 price, , ,) = AggregatorV3Interface(priceFeed).latestRoundData();` — 4th return value (updatedAt) ignored. `require(price >= 0)` is the only validation. | RED RD-F-060 gray Chainlink aggregator min/max bound misconfig Chainlink aggregator min/max bound misconfig | Chainlink USDC/USD, USDT/USD feeds have documented minAnswer/maxAnswer that could peg at floors during extreme depeg events. For stablecoin fee adjustment purposes (not bridge execution), a floor at 0.95 USD for USDC would lock the FeeLib in Depeg state. However, since this only affects fee tiers not fund release, the impact is bounded to fee miscalculation not fund loss. | Chainlink USDC/USD Ethereum Mainnet feed; FeeLibraryV07 function uses pri... RD-F-061 gray LP token balanceOf used for pricing LP token balanceOf pricing (donation-manipulable) | Not applicable. Stargate pools use pool balance ratios for internal equilibrium fee calculations (tvlSD / poolBalanceSD), not external `balanceOf` for pricing. No donation attack vector on fee calculation. FeeLibraryV07 separately uses Chainlink for depeg detection. | StargatePool.sol: `_buildFeeParams()` uses internal state variables tvlSD and poolBalanceSD, not external balanceOf calls. | GREEN RD-F-062 gray External keeper/relayer not redundant External keeper/relayer dependency not redundant | RED FINDING. Stargate's bridge liveness depends on LayerZero DVN executors for message delivery. The Dec 2024 6-hour outage was caused by "an error in the DVN network's executors" — a single executor error froze ~29,700 transactions. While multiple DVN operators exist, there is no documented executor redundancy failover. The AI Planning Module (AIPM) for credit management is also a single off-chain system with no documented fallback. | Crypto... RD-F-180 gray Immutable oracle address Immutable oracle address (no admin-replaceable wrapper) | NOT TRIGGERED. Where oracles are used (FeeLibraryV07), the `setTokenPriceFeed(uint256 _poolId, address _priceFeedAddress) external onlyOwner` function allows the owner to replace oracle addresses per pool without a full contract upgrade. The oracle address is stored in `poolIdToPriceFeed` mapping, not as an `immutable` variable. | FeeLibraryV07 BaseScan source: `mapping(uint256 => address) public poolIdToPriceFeed` and `setTokenPriceFe... RD-F-181 gray Permissionless-pool lending oracle Permissionless-pool lending oracle | NOT APPLICABLE. Stargate is not a lending protocol. It does not accept collateral or have a borrowing mechanism. No oracle feeds asset prices for collateral/LTV calculations. | Protocol type: bridge (OFT native-asset); StargatePool.sol implements deposit/withdraw not borrow/lend. | NOT_APPLICABLE

Economic risk Gray 0 13 of 13

RD-F-063 gray TVL (current + 30d trend) TVL ~$92M aggregate across v2 chains as of 2026-05-07 (DefiLlama). Down materially from v2 launch peak (~$345M in Q1–Q2 2024) and below A-grade $100M floor under rubric v1.7.0. Legacy v1 ~$5–10M residual. Stargate remains a top historical bridge by cumulative volume ($70B+) but current scale has contracted significantly. TVL trend not precisely quantified for 30d but live snapshot confirms multi-month declining trajectory. RD-F-064 gray TVL concentration (top-10 wallet share) On-chain per-depositor breakdown not retrieved. Structural observation: Stargate pools hold LP tokens representing depositor shares; LP tokens are issued 1:1 with deposits (StargatePool.sol). Pool contracts themselves are the on-chain holders of underlying assets, making LP holder concentration the relevant measure. Historical note: Alameda Research held a significant early STG stake (pre-FTX collapse, 2022–2023) — that governance token concentration risk, not pool-deposit concentration. No o... RD-F-065 gray Liquidity depth per major asset Stargate is a bridge, not a DEX — standard 2%/5% price-impact slippage depth is not the right framing. Adapted interpretation: pool depth for bridging execution. Ethereum USDC pool: $12.3M (Etherscan, 2026-04-26). Arbitrum USDC: ~$18M (2025 search estimate). Per Stargate docs, slippage is kept minimal on stablecoin routes via the Delta Algorithm / AIPM. Dynamic equilibrium fees apply when pools are imbalanced, increasing cost for transfers from depleted chains. Risk: AIPM is an off-chain, Sta... RD-F-066 gray Utilization rate (lending protocols) Not applicable — Stargate has no lending/borrowing module. `borrow.present = false` (data cache). RD-F-067 gray Historical bad-debt events Not applicable — no collateralized lending. No bad-debt concept applies to bridge liquidity pools. (Pool imbalance risk is captured under RD-F-064/065, not as "bad debt.") RD-F-068 gray Collateralization under stress Not applicable — no collateralized positions exist. Bridge pools hold 1:1 bridged stablecoin assets; no leverage. RD-F-069 gray Algorithmic / under-collateralized stablecoin Not applicable — Stargate is not a stablecoin issuer. Protocol holds/bridges USDC and USDT issued by Circle and Tether respectively. Secondary exposure: protocol TVL is >80% in USDC/USDT; a material depeg of either would reduce pool value. However, that is an asset-counterparty risk (Cat 3 / Cat 8), not an algorithmic stablecoin design risk. Factor = N/A. RD-F-070 gray Empty cToken-style market (zero supply/borrow) Not applicable — Stargate is a bridge; no cToken or Compound V2 fork architecture exists. `borrow.present = false`. LP token accounting is 1:1 (not share-price-based), and pools are live with active liquidity (~$12.3M Ethereum USDC alone). No empty-market donation attack vector applies to this architecture. RD-F-071 gray Seed-deposit requirement for new market listing Not applicable — no market listings; bridge architecture does not create new lending markets. New chains are added via governance/admin with LP bootstrapping, not via permissionless market listing. RD-F-072 gray Market-listing governance threshold Not applicable — no lending market listing mechanism. New chain integrations go through multisig/admin. RD-F-073 gray Oracle-manipulation-proof borrow cap Not applicable — no borrow caps or oracle-dependent borrowing. Stargate pools hold stablecoins without leverage. RD-F-074 gray ERC-4626 virtual-share offset (OZ ≥4.9) Not applicable — StargatePool.sol uses 1:1 LP minting (not ERC-4626 share-based accounting). No virtual share offset is relevant. RD-F-075 gray First-depositor / share-inflation guard Not applicable via ERC-4626 path (no share price appreciation mechanism). Structural note: 1:1 LP minting eliminates the classic first-depositor inflation attack vector because share price does not change with pool balance — LP tokens always redeem 1:1. However, a "donation" to the pool contract (direct transfer of USDC to pool address) could inflate the implied redemption value of outstanding LP tokens — this is a distinct risk. No explicit minimum deposit or seed-deposit guard identified in...

Operational history Gray 0 15 of 15

RD-F-076 gray Protocol age (days) green RD-F-077 gray Prior exploit count yellow RD-F-078 gray Chronic-exploit flag (≥3 incidents) green RD-F-079 gray Same-root-cause repeat exploit green RD-F-080 gray Days since last exploit green RD-F-081 gray Post-exploit response score yellow RD-F-082 gray Post-mortem published within 30 days red RD-F-083 gray Auditor re-engaged after last exploit not_applicable RD-F-084 gray TVL stability (CoV over 90d) yellow RD-F-085 gray Incident response time (minutes) yellow RD-F-086 gray Pause activations (trailing 12 months) green RD-F-087 gray Pause > 7 consecutive days green RD-F-088 gray Re-deployed to new addresses in last year yellow RD-F-089 gray Insurance coverage active yellow RD-F-166 gray Deprecated contracts still holding value yellow

Real-time signals Gray 0 22 of 22

RD-F-090 gray Mixer withdrawal → protocol interaction yellow RD-F-091 gray Partial-drain test transactions gray RD-F-092 gray Unusual mempool pattern from deployer wallet gray RD-F-093 gray Abnormal gas-price willingness from attacker wallet gray RD-F-094 gray New contract with similar bytecode to exploit template gray RD-F-095 gray Known-exploit function-selector replay gray RD-F-096 gray New ERC-20 approval to unverified contract from whale gray RD-F-097 gray Sybil surge of identical-pattern transactions gray RD-F-098 gray TVL anomaly — % drop in <1h yellow RD-F-099 gray Oracle price deviation >X% from secondary gray RD-F-100 gray Flash loan >$10M targeting protocol tokens gray RD-F-101 gray Large governance proposal queued gray RD-F-102 gray Admin/upgrade transaction in mempool yellow RD-F-103 gray Bridge signer-set change proposed/executed red RD-F-104 gray Stablecoin depeg >2% on shared-LP venue green RD-F-105 gray DNS/CDN/frontend hash drift yellow RD-F-106 gray Cross-chain bridge unverified mint pattern red RD-F-107 gray Admin EOA signing from new geography/device gray RD-F-108 gray GitHub force-push to sensitive branch gray RD-F-109 gray Social-media impersonation scam spike yellow RD-F-110 gray Unusual pending/executed proposal ratio gray RD-F-182 gray Security-Council threshold reduction (RT) red

Dev identity & insider risk Gray 0 16 of 16

RD-F-111 gray Team doxx status Team doxx status | Real-name / fully identified. Bryan Pellegrino, Ryan Zarick, Caleb Banister are publicly identified with full professional histories, LinkedIn profiles, university origin (UNH), investor attestations (Sequoia, a16z), and active social media. | Crunchbase, LinkedIn, Sequoia spotlight (sequoiacap.com/article/bryan-pellegrino-spotlight-layerzero/), a16z podcast, UNH Today article (unh.edu/unhtoday/2022/05/changing-game), X @PrimordialAA | **GREEN** RD-F-112 gray Team public accountability surface Team's public accountability surface | Extensive. Pellegrino: 4+ verifiable trails (LinkedIn, Sequoia, a16z, CardPlayer.com poker career, multiple conference appearances, Web Summit Vancouver). Zarick: Sequoia profile, LinkedIn. Banister: LinkedIn, The Org, IQ.wiki. All three have 6+ year continuous public web presence. | Multiple sources cited per identity register above | **GREEN** RD-F-113 gray Team other-protocol involvement history Team members' other protocol involvement history | Pellegrino: OpenToken (2016–2019, token-creation platform — no rug or scandal found), Coder Den, BuzzDraft (mobile apps). No prior DeFi protocol rug affiliations found. Zarick and Banister: LayerZero and Stargate as primary DeFi protocol involvement. | Pellegrino bio (tradersunion.com/persons/bryan-pellegrino/, rootdata.com), OpenToken search (no rug evidence) | **GREEN** RD-F-114 gray Deployer address prior on-chain history Deployer address prior on-chain history | 499 transactions; earliest activity ~May 2023; Stargate v2 contract deployments (Initialize Bus Queue, token bridging) May 2024; last activity Nov 2024. Normal development history. No rug-precursor pattern (no flash deploy → drain → abandon). | Etherscan 0x4A79AdC4539905376D339c69b6A7092D0598cc24 (fetched 2026-04-26) | **GREEN** RD-F-115 gray Prior rug/exit-scam affiliation Prior rug / exit-scam affiliations | No rug or exit-scam linked to any named team member found. OpenToken (Pellegrino's prior company) was a legitimate token-creation platform with no known scandal. No hits in REKT news or public rug databases for Pellegrino, Zarick, or Banister. | REKT News (no Pellegrino/Zarick/Banister entries), OpenToken search results | **GREEN** RD-F-116 gray Contributor tenure at admin-permissioned PR Contributor tenure at time of admin-permissioned PR | stargate-protocol/stargate-v2 GitHub org has "no public members" listed per search results. V1 contributors included Ryan Zarick, Isaac Zhang, Caleb Banister, Carmen Cheng, T. Riley Schwarz. Last commit 2026-04-23. Core founders (Zarick, Banister) have 4+ year tenure on LayerZero/Stargate codebase. | GitHub stargate-protocol org (search result); 00-profile.md (last commit 2026-04-23) | **YELLOW** — GitHub org membership is private; individ... RD-F-117 gray ENS/NameStone identity bound to deployer ENS / NameStone identity bound to deployer | No ENS or NameStone name bound to `0x4A79AdC4539905376D339c69b6A7092D0598cc24`. No Etherscan label shown. | Etherscan address page (fetched 2026-04-26) — "No labels found" | **YELLOW** — minor gap; deployer is otherwise identifiable via Coinbase Prime funding chain and Stargate contract creation tx RD-F-118 gray Handle reuse across failed/rugged projects Handle reuse across failed/rugged projects | No evidence of Bryan Pellegrino (@PrimordialAA), Ryan Zarick, or Caleb Banister (@cb_LayerZero) recycling handles from prior rugged/failed projects. All handles are consistently associated with LayerZero Labs. | X profiles, IQ.wiki, Crunchbase — continuous identity | **GREEN** RD-F-119 gray Commit timezone consistent with stated geography Repo commit times consistent with stated geography | LayerZero Labs is based in Vancouver, BC (Canada, Pacific timezone). Commit-time timezone analysis not independently performed (requires GitHub API commit-time histogram). Team members appear in Vancouver-based media and Web Summit Vancouver (Pellegrino). No anomalous timezone pattern reported publicly. | Techcouver.com (Pellegrino at Web Summit Vancouver), LinkedIn (Vancouver listed) | **GRAY** — commit-time histogram not independently com... RD-F-120 gray Video-off/voice-consistency flag Video-off / voice-consistency flag | No video-off or voice inconsistency flags found. Bryan Pellegrino appears on video in multiple a16z, Sequoia, and conference recordings. Ryan Zarick and Caleb Banister have public YouTube appearances (e.g., "While You Build Casinos, We Build Real Finance" YouTube video). | a16z podcast, YouTube (youtube.com/watch?v=Ha2l1ecmI2Y), Sequoia spotlight | **GREEN** RD-F-121 gray Contributor OSINT depth score Contributor OSINT depth score | Curator score: 4/5. Pellegrino: exceptional depth (poker career, prior companies, investor relationships, conference circuit, 117k X followers). Zarick and Banister: good depth (Sequoia profiles, LinkedIn, UNH origin). Supporting team members (Litan, Hafizi) have more limited public footprint (named but not independently verifiable). | Full source list per identity register above | **GREEN** RD-F-122 gray Contributor paid to DPRK-cluster wallet Contributor paid to wallet routing to known DPRK cluster | No evidence of protocol payment routing to DPRK-labeled addresses. Named signers are institutional founders; the Kelp DAO exploit was an external infrastructure attack, not a payment-routing compromise. Individual signer wallet addresses are not publicly confirmed, preventing full 3-hop analysis. | Chainalysis Kelp blog post (no team-wallet link); OFAC SDN list search (no Pellegrino/Zarick/Banister entries) | **NOT_ASSESSED** — signer... RD-F-123 gray Sudden admin-rescue/ACL change without discussion Sudden admin-rescue / ACL change absent issue/PR discussion | LayerZero Foundation acquisition (Aug 25, 2025): 7-day discussion + 3-day vote on Stargate DAO forum (governance.discourse.group post #682), then DAO approval at 95%. OneSig migration proposal (July 2025 forum post) proposed before execution with 3/6 threshold preserved. Post-acquisition operational ownership transfer to LayerZero Foundation occurred per DAO directive. Safe API returned `not_found` for multisig, blocking on-chain A... RD-F-124 gray Deployer wallet mixer-funded within 30 days Deployer wallet mixer-funded within 30 days of deploy | Deployer `0x4A79AdC4539905376D339c69b6A7092D0598cc24` first funded Nov 2023 from Coinbase Prime 1 (institutional custody, OFAC-clean). The Stargate v2 USDC pool was deployed ~May 2024 (creation tx `0x62bbb947...`). First funding predates deploy by ~5 months, not from a mixer. No Tornado Cash, Railgun, or mixer interactions in 499-tx history. 30-day pre-deploy window: clean. | Etherscan (0x4A79... fetched 2026-04-26), funding tx `0x5eee27... RD-F-125 gray Deployer linked within 3 hops to DPRK/Lazarus Deployer address linked within 3 hops to DPRK/Lazarus cluster | Deployer funded by Coinbase Prime 1 (hop 1 = US regulated CEX = clean terminal). The Kelp DAO DPRK exploit (Apr 2026) targeted LayerZero's off-chain RPC nodes (external infrastructure attack), not deployer or team wallets. No public Chainalysis, Arkham, or OFAC source labels the deployer or multisig as proximate to Lazarus cluster. Full 3-hop trace from deployer not completable without paid API access. **CRITICAL GUIDANCE APPLIED... RD-F-184 gray Real-capital social-engineering persona Real-capital social-engineering persona (≥$1M deposits to build credibility) | No evidence found of any "team contributor" or "external integrator" persona using ≥$1M capital deposits on Stargate or LayerZero protocol to build social-engineering credibility. The Kelp DAO Lazarus attack used RPC node compromise + DDoS, not a long-term social-engineering capital buildup on Stargate specifically. The Drift Protocol UNC4736 pattern (which motivated F184) has not been documented for Stargate. | Ch...

Fork / dependency lineage Green 17 10 of 10

RD-F-133 yellow Dependency manifest uses unpinned versions OpenZeppelin contracts are specified as `"@openzeppelin/contracts": "^4.8.1"` and `"@openzeppelin/contracts-upgradeable": "^4.8.1"` — **caret (^) notation allows automatic minor and patch version updates** (i.e., any version ≥4.8.1 <5.0.0). This is unpinned by the methodology definition and is a risk for security-critical libraries. LayerZero libs use tilde (~) allowing only patch updates, which is less concerning. The `ethers` package uses `^5.7.2` — caret for a JS utility library. RD-F-135 yellow Shared-library version with known-vuln status OpenZeppelin 4.8.1 is in the vulnerable range for CVE-2023-40014 (GHSA-g4vp-m682-qqmp) — affects ERC2771Context when used with custom trusted forwarders where `calldata < 20 bytes`. Patched in OZ 4.9.3. **Stargate v2 does not appear to use ERC2771Context or meta-transaction forwarder patterns** (no such imports found in inspected source files), which substantially reduces exploit risk from this CVE. However, the caret-pinned dependency means the exact deployed version could be anywhere in the... RD-F-127 n/a Upstream patch not merged N-A for an original codebase (no upstream protocol to merge patches from). Stargate v2 is not a fork. However, the LayerZero v2 library dependency is the relevant upstream here — see RD-F-135 for library version analysis. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) N-A — Stargate v2 is not a fork of another protocol. No upstream fork-parent vulnerability disclosures apply. The LayerZero infrastructure vulnerability (Kelp DAO exploit, Apr 2026) involved off-chain DVN compromise, not a smart contract vulnerability in the OFT library itself. RD-F-129 n/a Code divergence from upstream (%) N-A — no upstream fork exists. Stargate v2 is an original protocol. RD-F-130 n/a Fork depth (generations from original audit) N-A — not a fork at any depth. RD-F-131 n/a Fork retains upstream audit coverage N-A — not a fork. Audit coverage question is addressed in Cat 1 (RD-F-001/004). RD-F-132 n/a Fork has different economic parameters than upstream N-A — not a fork.

RD-F-126 green Is-a-fork-of Stargate v2 is an original codebase — not a fork of Compound, Aave, Uniswap, or any other DeFi protocol. It was built from scratch by the Stargate/LayerZero team as a native-asset OFT bridge. Codebase origin confirmed as original in the protocol profile.

RD-F-134 green Dependency had malicious-release incident (last 90d) No malicious release incident found for OpenZeppelin, LayerZero, or other Stargate v2 npm/package dependencies in the trailing 90 days (assessed window: Jan 26 – Apr 26, 2026). Web search and security advisory feeds show no such incidents for these specific packages.

Post-deploy hygiene & change mgmt Gray 0 13 of 13

RD-F-136 gray Deployed bytecode matches signed release tag yellow RD-F-137 gray Upgrade frequency (per 90 days) yellow RD-F-138 gray Hot-patch deploys without timelock (last 30 days) yellow RD-F-139 gray Post-audit code changes without re-audit **RED** [★ CRITICAL] RD-F-140 gray Fix-merged-but-not-deployed gap green RD-F-141 gray Test-mode parameters in deploy green RD-F-142 gray Storage-layout collision risk across upgrades green RD-F-143 gray Reinitializable implementation (no _disableInitializers) green RD-F-144 gray CREATE2 factory permits same-address redeploy gray RD-F-145 gray Deployed bytecode reproducibility yellow RD-F-146 gray New contract deploys in last 30 days yellow RD-F-168 gray Stale-approval exposure on deprecated router gray RD-F-185 gray Bridge rate-limiter / chain-pause as positive mitigant yellow

Cross-chain & bridge Gray 0 12 of 12

RD-F-147 gray Protocol has bridge surface Protocol uses a cross-chain bridge | YES. Stargate Finance IS the bridge. It transfers USDC, USDT, ETH, and other assets cross-chain via LayerZero OFT v2. TVL ~$92M aggregate across 7+ chains (DefiLlama, 2026-05-07; down from ~$345M peak in 2024). | Profile §7; StargatePool.sol; StargateOFT.sol; `has_bridge_surface: true`, `is_a_bridge: true`. | GREEN RD-F-148 gray Bridge validator count (M) Bridge validator count (M) | 2 required DVNs (Nethermind + LayerZero Labs). This is the total required verifier count — both must agree. Note: LayerZero Labs DVN address on Ethereum: 0x589dedbd617e0cbcb916a9223f4d1300c294236b; Nethermind DVN: 0xa59ba433ac34d2927232918ef5b2eaafcf130ba5. [Deferred to F179 for LZ-specific encoding per taxonomy note.] | L2BEAT Stargate v2 analysis: "currently configured as a 2/2 of the required (Nethermind, LayerZero) custom Multisigs"; LayerZero DVN metadata API... RD-F-149 gray Bridge validator threshold (k-of-M) Bridge validator threshold (k-of-M) | 2/2 required. BOTH Nethermind and LayerZero DVNs must attest for a message to be verified. This is significantly stronger than Kelp DAO's 1/1 configuration. However: (1) LayerZero Labs is one of the two required DVNs AND is the OApp owner post-acquisition — a single-entity path exists if LayerZero Labs infrastructure is simultaneously compromised; (2) no optional DVN tier is configured as a redundant backup; (3) the threshold can be changed by the OApp ow... RD-F-150 gray Bridge validator co-hosting Bridge validator co-hosting (same ASN/datacenter) | Both DVNs (Nethermind and LayerZero Labs) are independent companies with separate infrastructure. Nethermind is a UK-based blockchain infrastructure firm; LayerZero Labs is a San Francisco-based company. No evidence of shared hosting. The Kelp attack showed that LayerZero Labs' own RPC nodes can be compromised by sophisticated state actors — but this is operator-level compromise, not co-hosting. | Nethermind public infrastructure page; Layer... RD-F-151 gray Bridge ecrecover checks result ≠ address(0) Bridge signature verification checks ecrecover != address(0) | LayerZero v2 does NOT use ecrecover in the Wormhole/traditional sense. DVN verification works via hash commitments: DVNs call `ReceiveUln302.verify()` to store `payloadHash` indexed by their address. There is no `ecrecover` call that could return `address(0)`. The Wormhole bug class (unsigned message accepted because ecrecover(invalid_sig) = address(0)) does not apply to this architecture. However, the analogous risk — whether a D... RD-F-152 gray Bridge binds message to srcChainId Bridge binds message to srcChainId | YES. LayerZero v2 uses `srcEid` (endpoint ID) in the packet struct which is globally unique per chain. The Endpoint enforces per-channel nonce ordering keyed to `(srcEid, sender, dstEid, receiver)`. Messages from one chain cannot be replayed on another chain's channel. | LayerZero v2 docs: "Packet containing srcEid, sender, dstEid, receiver, guid, and message payload"; Endpoint enforces lossless per-channel delivery. | GREEN RD-F-153 gray Bridge tracks nonce-consumed mapping Bridge tracks nonce-consumed mapping | YES. LayerZero v2 EndpointV2 implements gapless strictly monotonically increasing nonce per channel. Exactly-once delivery is enforced: "deleting the verified hash of a packet from the lossless channel after it is delivered and disallowing verification of nonces less than or equal to the lazy inbound nonce." | LayerZero v2 docs: `getInboundNonce()`, "exactly-once delivery enforcement"; LayerZero v2 deep dive: "each channel maintains a logical clock... ga... RD-F-154 gray Default bytes32(0) acceptable as valid root Default-value (bytes32(0)) acceptable as valid bridge root | NOT TRIGGERED. LayerZero v2 does not use Merkle roots for verification. It uses keccak256 payloadHash commitments. Each DVN independently computes and stores a non-default payloadHash. There is no initialization pattern where bytes32(0) is a valid root. The Nomad $190M bug required a single Merkle root to be initialized as bytes32(0) and accepted as valid proof for any message — this attack surface does not exist in LayerZero v2's h... RD-F-155 gray Bridge validator-set rotation recency Bridge validator set rotation recency | RED FINDING. No public record of DVN set changes for Stargate v2 since deployment. The 2/2 Nethermind + LayerZero configuration was set at v2 launch (~Q1 2024) and no rotation has been documented. More critically: the OApp owner can change DVNs without any timelock, meaning the effective "rotation" can happen instantly at admin discretion. The lack of rotation history is itself a signal — no governance process for DVN changes exists. | Profile: no docum... RD-F-156 gray Bridge uses same key custody for >30% validators Bridge uses same key custody for > 30% of validators | Concerning but not definitively red: LayerZero Labs controls the OApp admin role AND is one of two required DVNs. Post-acquisition (Aug 2025), LayerZero Labs has full administrative power over Stargate AND is a required attestor. This is effectively >50% of the security model concentrated in one entity. While LayerZero Labs and their DVN infrastructure are separate from the OApp admin, the acquisition means the same corporate entity contr... RD-F-157 gray Bridge TVL per validator ratio Bridge TVL per validator ratio | ~$92M TVL (DefiLlama, 2026-05-07) divided by 2 required DVNs = ~$46M per DVN. This remains a meaningful concentration per verifier, though down materially from the ~$172.5M per DVN figure at v2 launch peak (~$345M TVL). Historical anchor: peak v2 TVL of ~$345M implied $172.5M/DVN, which exceeded the Kelp exploit setup ($292M/1 DVN under 1/1 config); current ratio is roughly 6x safer per-DVN than Kelp's 1/1, but still well above multi-DVN-stack bridges. With only 2 independent operators required, each represents the full ~$92M attack surface if either can be coerced or compromised in coordination with the other. Score retained gray (no v1.6 score-input flip): qualitative concern persists but TVL contraction reduces acute magnitude. | Profile: TVL ~$92M (down from ~$345M peak); L2BEAT: 2 required DVNs. RD-F-179 gray LayerZero OFT DVN config (count, threshold, diversity) LayerZero OFT DVN configuration (count, threshold, diversity) | 2/2 configuration: Nethermind DVN + LayerZero Labs DVN. Both must attest. Evaluation: (1) Count = 2 (minimum viable multi-DVN); (2) Threshold = 2/2 (full consensus required — strong, not just majority); (3) Diversity: PARTIAL CONCERN — Nethermind is an independent firm with separate infrastructure; however LayerZero Labs is both the DVN operator AND the OApp admin post-acquisition. True independence requires organizational and in...

Threat intelligence & recon Gray 0 8 of 8

RD-F-158 gray Known-threat-actor cluster has touched protocol red RD-F-159 gray Attacker wallet pre-strike probe (low-gas failing txs) gray RD-F-160 gray GitHub malicious-dependency incident touching protocol deps gray RD-F-161 gray Protocol-impersonator domain registered (typosquat) yellow RD-F-162 gray Known-exploit-template selector deployed by any address gray RD-F-163 gray Avg attacker reconnaissance time for peer-class protocols red RD-F-164 gray Leaked credential on paste/sentry site gray RD-F-165 gray Protocol social channel has scam-coordinator flag yellow

Tooling / compiler / AI Green 13 5 of 5

RD-F-170 yellow Solc version used (known-bug versions flagged) Two compiler versions are configured: **0.8.22** (5000 optimizer runs) and **0.8.17** (20000 runs, viaIR=true). Deployed contracts confirmed on Etherscan as `v0.8.22+commit.4fc1097e`. Known bug in 0.8.22: **VerbatimInvalidDeduplication** (introduced 0.8.5, fixed in 0.8.23) — causes incorrect deduplication of verbatim blocks by the Yul optimizer. Critically, this **only affects Yul verbatim blocks, not Solidity source compilation**. Since Stargate v2 compiles from Solidity source (not Yul verb... RD-F-172 yellow Repo shows AI-tool co-authorship in critical files **GitHub commit search confirms 14+ commits with "Co-authored-by: Copilot" spanning February 2025 through October 2025.** Affected commits include: "Add off chai checker GH action," "Allow wiring single paths," "Allow unwiring a single asset from the mesh," and various configuration/deployment commits. These appear to be tooling and configuration changes rather than core Solidity contract logic. However, without reviewing every co-authored commit, cannot rule out Copilot co-authored changes t...

RD-F-171 green Bytecode similarity to audited upstream with behavior deviation Stargate v2 is an original codebase, not a copied or near-cloned protocol. No evidence of AI-generated code being copied from an audited upstream with behavioral deviations. The Copilot co-authorship (see RD-F-172) is for configuration and deployment scripts, not for wholesale copying of audited contract logic with subtle mutations.

RD-F-173 green Team self-disclosure of AI-generated Solidity No public team disclosure found of AI-generated Solidity being used in security-critical paths. The Copilot co-authorship found in commits appears to be for tooling, CI/CD, and configuration scripts rather than Solidity contract source. No blog post, tweet, or documentation mentions AI-generated Solidity in security-critical code.

RD-F-174 green Dependency tree uses EOL Solidity version Neither 0.8.22 nor 0.8.17 is EOL. Both are in the maintained 0.8.x release series. The latest stable Solidity is 0.8.28+ (as of Apr 2026). Using 0.8.22 means missing ~6 patch releases worth of bug fixes (including the VerbatimInvalidDeduplication fix in 0.8.23), but neither version is End-of-Life. Not a critical concern for Solidity-source compilation.

Response & disclosure hygiene Gray 0 4 of 4

RD-F-175 gray Disclosure channel exists green RD-F-176 gray Disclosure SLA public yellow RD-F-177 gray Prior known-ignored disclosure yellow RD-F-178 gray CVE/GHSA advisory issued against protocol green

rubric_version v1.7.0 graded_at 2026-05-12 04:38:07 factors 184 protocol stargate