Venus Protocol
Compound v2 fork lending protocol on BNB Chain (BSC) — the largest BSC lending venue. Operates a Core Pool (multi-asset shared-liquidity Compound-style) and Isolated Pools (per-asset risk segregation). Includes XVS governance token with LayerZero OFT bridge across 7 chains, ResilientOracle multi-source price aggregator, ACM (Access Control Manager), Diamond Comptroller, and VAI overcollateralized stablecoin.
DeploymentsBNB Chain · $1.3B
01
Risk profile at a glance
1 red · 8 yellow · 4 green 02
Categories & evidence
184 factors · 13 categoriesCode & audits Yellow 21 25 of 25
RD-F-003 red Resolved-without-proof findings Code4rena 2023-05-venus M-10 (exchange-rate manipulation via donation/direct transfer) was explicitly disputed by Venus — assessed as 'no negative side effects' and not remediated. Post-mortem confirms: 'This vector was identified in a prior Code4rena audit but was assessed as having no negative side effects and was not remediated.' The finding was not marked Resolved — it was dismissed. Result: two exploits using this exact mechanism (Feb 2025 ZKSync ~$716K, March 2026 BNB Chain ~$2.15M). RD-F-183 red Bug bounty scope gap on highest-TVL contracts Venus docs claim a bug bounty exists but no platform URL, scope document, or payout cap is published. Immunefi returns 404. Data cache confirms bug_bounty.platform=null. At $1.26B TVL, the Core Pool Diamond Comptroller and vToken contracts are almost certainly not in scope of any published bounty. This is structurally analogous to the Kelp DAO OFT adapter out-of-scope finding — the unquantified/unpublished bounty removes whitehat disclosure incentives for the most consequential contracts. RD-F-001 yellow Audit scope mismatch 48+ audit reports across 11 firms cover the protocol broadly, but the Code4rena 2023 M-10 finding (exchange-rate manipulation via donation) was dismissed without remediation and subsequently exploited in Feb 2025 and March 2026. The dismissed finding represents a scope mismatch in effect — the audited-but-dismissed pattern allowed a live exploit on deployed bytecode. Newest features (Flash Loan, E-Mode) have recent audit coverage but deployed bytecode commit-hash match is unverified. RD-F-006 yellow Audit-to-deploy gap Pattern of multi-firm concurrent auditing before VIP deployment. Flash loan: Certik Oct 2025, Hashdit Oct 2025, Quantstamp Dec 2025. Specific deploy tx timestamps per audit component not independently verified via Etherscan; deploy-to-audit gap could exceed 60 days for some components. Conservative yellow due to unverified timestamps. RD-F-007 yellow Bug bounty presence & max payout Venus docs state 'we offer a bug bounty program' but no URL, platform, or payout cap is published. Immunefi search returns 404. Data cache confirms bug_bounty.platform=null and bug_bounty.max_payout_usd=null. At $1.26B TVL, the absence of a quantified platform-hosted bounty is a material gap. RD-F-008 yellow Ignored bounty disclosure No formal bug-bounty channel disclosure was ignored (no bounty program is confirmed). However, Code4rena 2023 M-10 audit finding was dismissed without remediation — the functional equivalent of an ignored disclosure. Two resulting exploits confirm the consequential nature of the dismissal. Applied to the audit-channel equivalent per factor spirit. RD-F-013 yellow Arbitrary call with user-controlled target Timelock.sol uses target.call(callData) without an allowlist — any address can be targeted by queued proposals. However, execution requires full Governor Bravo proposal lifecycle (quorum, voting period, timelock delay), providing economic and temporal friction. This is the standard Compound-style design shared by most major governance systems. Yellow not red due to governance friction layer. RD-F-016 yellow Divide-before-multiply pattern No published standalone Slither divide-before-multiply output. Multiple audit firms have reviewed the codebase statically 2023-2025 without flagging this as a critical open issue. Code4rena 2023 identified arithmetic issues (incorrect blocksPerYear constant) suggesting complex math paths exist. Low confidence yellow due to absence of dedicated tool run. RD-F-022 yellow Public initialize() without initializer modifier Core Pool VToken.sol initialize() is public with admin check inside body (ensureAdmin(msg.sender)) and state guard (accrualBlockNumber==0), but no OZ initializer modifier. Isolated Pools VToken.sol correctly uses initializer modifier + _disableInitializers() in constructor. The Core Pool pattern is weaker than OZ standard but the combined admin+state guards prevent the one-tx unauthorized re-init exploit. Yellow (not red) because the state guard effectively prevents unauthorized re-initialization post-deploy. RD-F-023 yellow Constructor calls _disableInitializers() Isolated Pools VToken.sol confirmed: constructor calls _disableInitializers(). Core Pool VToken.sol (legacy Compound-derived): no _disableInitializers in the constructor path. Diamond.sol does not call _disableInitializers(). Split in hygiene between Core Pool (legacy pattern) and Isolated Pools (modern OZ pattern). RD-F-009 gray Formal verification coverage No evidence of Certora, Kani, Halmos, or equivalent formal verification on Venus Protocol contracts. Cantina 2024 engagement was for Multichain Governance (audit, not FV). No FV report found in audits directory or documentation. RD-F-010 gray Static-analyzer high-severity count No published standalone Slither/Mythril/Semgrep output on deployed bytecode found in public sources. Audit firms include static analysis in their engagements but do not publish raw tool output. Cannot triage without tool run. Marked gray per methodology (needs tool run). RD-F-021 n/a UUPS _authorizeUpgrade correctly permissioned Venus does not use UUPS proxy pattern for core contracts. Core Pool uses Unitroller (transparent-proxy-style) and Diamond for Comptroller. Isolated Pools uses OZ upgradeable proxy. UUPS pattern not present; factor is not applicable.
RD-F-002 green Audit recency Most recent audits were the flash loan suite in October 2025: Certik (2025-10-14, audit #153), Quantstamp (October 2025, audit #154), Hashdit (2025-10-16, audit #155). Earlier in the same window: eMode by Certik (2025-09-19) and Quantstamp (2025-09-03), and Solidity 0.8 upgrade by Certik (2025-08-24) and Quantstamp (2025-08-29). Multiple components audited within 365 days of the 2026-04-28 assessment. Pattern of continuous multi-firm auditing (Certik + Quantstamp + Hashdit + Fairyproof) is present. Core vToken base code (legacy) is older but the recurring multi-firm review pattern over current features is satisfied.
RD-F-004 green Audit count 11 distinct audit firms: Certik, PeckShield, OpenZeppelin, Hacken, Fairyproof, Quantstamp, Pessimistic, Cantina, Code4rena, HashEx, Hashdit. 56+ reports in main repo, 18+ in isolated-pools. Largest audit surface in this M3a batch.
RD-F-005 green Audit firm tier Tier-1 firms: OpenZeppelin, Cantina, Code4rena. Tier-2: Certik, PeckShield, Quantstamp, Hacken, Pessimistic. Boutique/emerging: Fairyproof, HashEx, Hashdit. Multiple Tier-1 firms engaged.
RD-F-011 green SELFDESTRUCT reachable from non-admin path No selfdestruct usage found in VToken.sol, VTokenInterfaces.sol, MarketFacet.sol, SetterFacet.sol, Diamond.sol per direct source inspection. Compound v2 lineage does not use selfdestruct in core lending logic. No audit report flags selfdestruct as a finding.
RD-F-012 green delegatecall with user-controlled target Diamond.sol uses delegatecall in fallback to dispatch to facets, but targets are determined by admin-controlled _selectorToFacetAndPosition mapping (not user-supplied). SetterFacet shows no user-controlled external call targets. No user-controlled delegatecall target found in source inspection.
RD-F-014 green Reentrancy guard on external-calling functions VToken.sol implements nonReentrant on mint(), redeem(), borrow(), repayBorrow(), liquidateBorrow(). Isolated Pools VToken similarly guards all core operations. Standard Compound v2 _notEntered guard pattern confirmed.
RD-F-015 green ERC-777/1155/721 hook without reentrancy guard Venus Core Pool operates with BEP-20/ERC-20 standard tokens. No ERC-777 callback hooks or ERC-1155/ERC-721 integrations found in the core lending architecture. Standard token transfer interface only.
RD-F-017 green Mixed-decimals math without explicit scaling Compound v2 architecture uses expScale (1e18) and mantissa conventions throughout. VToken storage uses initialExchangeRateMantissa and 1e18 scaling. No mixed-decimals finding in any of the 56+ audit reports.
RD-F-018 green Signed/unsigned arithmetic confusion No signed/unsigned confusion finding in any available audit reports. Compound v2 lineage uses uint256 throughout core accounting. Newer code uses Solidity 0.8.25 (built-in overflow protection). Legacy 0.5.x uses established patterns.
RD-F-019 green ecrecover zero-address return unchecked No ecrecover usage in core lending contracts (VToken.sol, Diamond.sol). GovernorBravo uses EIP-712 for vote-by-signature with standard pattern. No ecrecover-zero-address finding in any audit report.
RD-F-020 green EIP-712 domain separator missing chainId GovernorBravo implements EIP-712 for vote-by-signature. Standard Compound v2-style Governor Bravo includes chainId in domain separator. No domain separator omission finding in any governance audit (Cantina, Quantstamp).
RD-F-024 green Code complexity vs audit coverage 56+ audit reports from 11 firms for main repo, 18+ for isolated-pools. Multiple firms auditing the same components simultaneously provides cross-validation. The density of audit coverage relative to codebase complexity is exceptional for a lending protocol.
Governance & admin Yellow 26 24 of 24
RD-F-032 red Timelock duration on upgrades Three-tier timelock: Critical VIP = 1 hour (3600s, confirmed from constructor args on BscScan), FastTrack VIP = 6 hours (21600s), Normal VIP = 2 days (172800s). At $1.26B TVL, the 1-hour Critical VIP timelock is materially inadequate. Factor threshold: green >=48h, yellow 24-47h, red <24h. Critical tier (1h) is deep in red territory. RD-F-038 red Proposal execution delay < 24h Critical VIP total time: 6h voting + 1h timelock = 7 hours. This is below the 24-hour red threshold. Fast-track VIP: 24h + 6h = 30 hours (yellow range). Normal VIP: 24h + 48h = 72h (green). The Critical VIP path — which can execute any VIP classified as critical — provides only 7 hours for the community to detect and respond. RD-F-047 red Governance token concentration (Gini) Community forum post documents 745,057 XVS delegated from 0x6027...AdD339d to Venus Labs as of October 2025. Quorum = 600,000 XVS. Venus Labs holds sufficient delegated XVS to pass any VIP unilaterally (745K > 600K quorum). Approximately 600K of the delegated XVS is alleged to be bootstrapped governance tokens from Binance/Swipe era, never returned. Gini coefficient not computed (Dune 403) but qualitatively >0.85. RD-F-026 yellow Upgrade multisig signer configuration (M/N) Guardian multisig 0x1C2CAc6ec528c20800B2fe734820D87b581eAA6B is confirmed as GnosisSafeProxy (Safe Singleton L2 1.3.0). Threshold (M) and owner count (N) are not resolvable from BscScan explorer view — Safe API returns 403. M/N recorded as unknown; curator must call getThreshold() and getOwners() via direct RPC. RD-F-028 yellow Low-threshold multisig vs TVL Guardian Safe 0x1C2CAc6ec528c20800B2fe734820D87b581eAA6B is a multisig but M/N threshold unconfirmed. At $1.26B TVL peer norm is 5/8 or higher. Cannot assess adequacy without threshold value. Curator must verify via RPC call to getThreshold()/getOwners(). RD-F-033 yellow Timelock on sensitive actions Mint (VAI): governance VIP path, timelocked. Rescue/sweepToken: Isolated Pools VToken sweepToken to owner() (timelock). Upgrade: Diamond Comptroller via VIP/Timelock. setOracle: ACM-gated. Pause: Guardian multisig can pause immediately (no timelock — intentional emergency mechanism). Pause is untimed by design; all other sensitive actions timelocked. Yellow per taxonomy: 4/5 timelocked (pause is the deliberate exception). RD-F-039 yellow delegatecall/call in proposal execution without allowlist Timelock.sol executeTransaction uses call (not delegatecall): target.call.value(value)(callData). No target allowlist enforced. Any address can be called if a VIP passes. The call pattern (not delegatecall) means execution context is the target contract's storage, limiting self-referential damage. Combined with the 1-hour Critical VIP window and guardian cancel capability, assessed as yellow. Not red because delegatecall is the catastrophic variant (Beanstalk class). RD-F-041 yellow Rescue/emergencyWithdraw without timelock Isolated Pools VToken sweepToken: require(msg.sender == owner()) → sends to owner() (timelock). Core Pool admin functions (_reduceReserves, etc.) route through Timelock via VIP execution. No direct EOA-callable fund drain found in verified source. Yellow because 30+ Core Pool vToken admin assignments not individually verified; old Compound v2 delegator pattern admin chain less transparent than new OZ Upgradeable. RD-F-042 yellow Admin has mint() with unlimited max VAI.sol has unlimited mint(address usr, uint256 wad) gated by auth modifier (wards[msg.sender] == 1). No supply cap on VAI. VAI minting authorization requires governance VIP to add new wards (Normal Timelock, 48h delay). XVS has fixed 30M supply, no mint. Yellow: VAI is uncapped but mint authorization is governance-timelocked — not single-EOA accessible. RD-F-029 gray Multisig signers co-hosted Cannot assess — signer list for guardian Safe unknown (M/N unresolved). No Chainalysis/TRM cluster feed available. RD-F-030 gray Hot-wallet signer flag Cannot assess — signer addresses for guardian Safe unknown. RD-F-031 gray Signer rotation recency Safe signer-set change history not enumerable without Safe API or direct event-log inspection. Recent transaction activity visible on BscScan but AddedOwner/RemovedOwner/ChangedThreshold events not extracted within budget. RD-F-044 gray Admin wallet interacts with flagged addresses Cannot assess without Chainalysis/TRM cluster feed. Guardian Safe 0x1C2CAc6... BscScan shows routine protocol operations. No flagged interactions visible in public view. RD-F-167 gray Deprecated contract paused but pause reversible by live admin Venus has had significant architectural evolution (VBep20 → Diamond Comptroller → Isolated Pools). Enumerating all deprecated contracts with live admin pause power requires full vToken set enumeration — deferred to code-security-analyst. ACM governs current contracts; legacy contracts not assessed within budget.
RD-F-025 green Admin key custody type Full DAO+Timelock. Governance flows GovernorBravoDelegator (on-chain vote) to one of three Timelocks (Critical 1h, FastTrack 6h, Normal 2d). AccessControlManager provides granular per-function permissions. No single admin EOA in the governance execution path.
RD-F-027 green Single admin EOA GovernorBravo admin is 0x1C2CAc6ec528c20800B2fe734820D87b581eAA6B — confirmed GnosisSafeProxy (not an EOA). Normal Timelock admin transferred from deployer (AcceptAdmin event block 17924603, May 2022) to 0xeAEb3137...9886fCfcb. No current EOA holds primary admin role.
RD-F-034 green Guardian/pause-keeper distinct from upgrader Guardian multisig 0x1C2CAc6ec528c20800B2fe734820D87b581eAA6B holds cancel/pause powers. Upgrader role is GovernorBravo->Timelock path (different contract addresses). These are distinct addresses and code paths. Historical use: guardian cancelled governance attack in September 2021.
RD-F-035 green Role separation: upgrade ≠ fee ≠ oracle ACM (AccessControlManager 0x4788629abc6cfca10f9f969efdeaa1cf70c23555) grants per-function role hashes (keccak256(contractAddress, functionSig)). Upgrade, fee collection, and oracle config roles are distinct function selectors on distinct contracts — enforced through the ACM architecture by design. DEFAULT_ADMIN_ROLE assigned to deployer at construction, last tx ~300 days ago (likely renounced or transferred).
RD-F-036 green Flash-loanable voting weight GovernorBravoDelegate uses xvsVault.getPriorVotes(voter, proposal.startBlock) for voting weight — checkpointed balance at proposal-start block. XVS token implements checkpoints mapping and getPriorVotes. Flash-loan attack on voting not possible: staked vault balance cannot be flash-borrowed and the checkpoint is historical.
RD-F-037 green Quorum achievable via single-entity flash loan Quorum = 600,000 XVS (2% of 30M supply). Voting uses checkpointed staked vault balances — not live token balanceOf. Flash loans cannot reach quorum by construction. Additionally, XVS price makes a 600K notional a large value to flash-borrow even if the voting mechanism allowed it.
RD-F-040 green Emergency-veto multisig present Guardian multisig 0x1C2CAc6ec528c20800B2fe734820D87b581eAA6B has cancel power on GovernorBravo proposals. Guardian is a Gnosis Safe (not EOA). Historical use confirmed: guardian cancelled a governance attack in September 2021 (Chainalysis blog).
RD-F-043 green Admin = deployer EOA after 7 days Protocol launched November 2020. Current admin path: GovernorBravo (contract) → Timelock (contract). Deployer 0x1ca3Ac3686071be692be7f1FBeCd668641476D7e is confirmed as original Timelock constructor admin but AcceptAdmin event (block 17924603, May 2022) shows transfer to another address. Protocol has been live 65 months — deployer EOA abandoned as admin.
RD-F-045 green Constructor args match governance proposal GovernorBravo, all three Timelocks have verifiable constructor args on BscScan matching documented governance topology. Delays confirmed: Critical=3600s, FastTrack=21600s, Normal=172800s. No evidence of silent deviation in observable governance contracts.
RD-F-046 green Contract unverified on Etherscan/Sourcify GovernorBravoDelegator verified (BscScan Exact Match). NormalTimelock verified (Solidity v0.5.17). CriticalTimelock verified. FastTrackTimelock verified. AccessControlManager verified (Solidity v0.8.13). No unverified core governance contract identified. All four primary governance contracts have public ABI.
Oracle & external dependencies Green 20 17 of 17
RD-F-052 yellow Breakage analysis per dependency Individual oracle failure for major assets (BTC, ETH) is absorbed by 3-tier fallback. Full oracle freeze requires all three tiers to fail simultaneously. Demonstrated breakage: (a) LUNA 2022 — Chainlink paused feed, stale price exploited for $11M bad debt before maxStalePeriod triggered revert; (b) THE 2026 — multi-source convergence after 37-min sustained manipulation, $3.7M loss. Thin-liquidity collateral oracles remain the primary residual breakage vector. RD-F-053 yellow Oracle source = spot DEX pool (no TWAP) [★ CRITICAL] Current architecture for major assets uses Chainlink + Binance + RedStone — no single-DEX spot oracle for BTC/ETH/USDC/USDT/BNB. However: (1) 2021 XVS attack exploited TWAP oracle with thin liquidity (~$100M bad debt); (2) 2026 THE attack bypassed 3-tier ResilientOracle via sustained multi-venue manipulation until BoundValidator accepted convergence (37-min delay, then accepted — $3.7M loss). Two in-sample oracle-manipulation exploits. TwapOracle.sol exists in oracle repo, used for some PancakeSwap-priced assets. Thin-liquidity collateral oracle manipulation surface is live and demonstrated. RD-F-054 yellow TWAP window duration ChainlinkOracle and BinanceOracle do not use TWAP (point-in-time). TwapOracle.sol exists in VenusProtocol/oracle repo for PancakeSwap AMM pools. TWAP window for PancakeSwap-based assets not confirmed from available sources. THE incident used multi-source convergence (functionally TWAP-manipulation-equivalent). No TWAP window < 30 min confirmed as active for major assets; thin-liquidity TWAP exposure unconfirmed. RD-F-055 yellow Oracle pool depth (USD) Chainlink feeds: multi-source aggregation (no single pool depth concern). BinanceOracle: centralized exchange depth (Binance). RedStone: multi-source. THE attack (2026): ~$30M notional collateral created against thin THE order book; liquidation dumped into empty order book. Post-mortem notes 'illiquid collateral demands proportionally stricter parameters.' Systematic liquidity-floor gating for market listings not confirmed as implemented. RD-F-057 yellow Circuit breaker on price deviation BoundValidator implements a soft circuit-breaker: if price deviation exceeds configured anchor ratio bands, that tier is rejected and next tier is tried. No hard circuit breaker (automatic market pause on >X% deviation). THE incident: BoundValidator rejected Binance feed for ~37 minutes then accepted convergence — it did not permanently block the inflated price once both sources agreed. No automatic market-pause trigger for sustained anomalies. RD-F-058 yellow Max-deviation threshold (bps) BoundValidator upper/lower anchor ratios are configurable per asset via governance. Example from docs: BNB uses 0.99–1.01 (±1%). Exact configured bps for all assets not confirmed. THE attack bypassed BoundValidator by sustaining buy pressure until both feeds converged within bands. Post-2026 proposals tighten maxStalePeriod (74 slots) but don't directly recalibrate BoundValidator bands for illiquid assets. RD-F-059 yellow Oracle staleness check present ChainlinkOracle.sol: explicit maxStalePeriod check — reverts if block.timestamp - updatedAt > maxStalePeriod. BinanceOracle.sol: same check. Concern: AVAX/USD and COMP/USD BSC Chainlink feeds have 86400s (24h) heartbeat at 0.5% deviation threshold — if maxStalePeriod is set >24h, stale prices up to 24h old are accepted. Oracle Configuration Update governance proposal (2026) confirms prior maxStalePeriod configs were too wide (CAKE was 24h despite 60s heartbeat, reduced to 120s). Residual risk: any asset where maxStalePeriod was not yet tightened. RD-F-060 yellow Chainlink aggregator min/max bound misconfig ChainlinkOracle.sol validates only positive prices (answer <= 0 reverts). No upper-bound check for anomalously high prices. No explicit Chainlink aggregator minAnswer/maxAnswer validation. BoundValidator provides indirect upper bound via anchor ratio, but this is cross-validated against another oracle (not the Chainlink aggregator's own min/max). LUNA 2022 incident involved Chainlink pausing at a floor value — current maxStalePeriod check mitigates the specific LUNA scenario (stale pause triggers revert) but upper-bound gap remains. RD-F-062 yellow External keeper/relayer not redundant Core lending operations (borrow, liquidation, interest accrual) do not rely on external keepers — triggered per-interaction (Compound v2 pattern). The LayerZero default DVN acts as a single-point relayer for XVS bridge messages — not redundant. Bridge is for governance token only, not lending TVL. No Gelato or Chainlink Automation dependency for core protocol functions confirmed. RD-F-181 yellow Permissionless-pool lending oracle TwapOracle.sol exists in VenusProtocol/oracle repo for PancakeSwap AMM pools. PancakeSwap is not fully permissionless-pool-creation in the Uniswap v3 sense. The THE attack (2026) demonstrates that thin-liquidity assets accepted as collateral can be exploited via multi-venue price manipulation — functionally equivalent to the permissionless pool oracle attack surface. Isolated pools require governance-approved market listing, providing some gating. Whether any active market uses a fully permissionless-created pool for oracle pricing not confirmed.
RD-F-048 green Oracle providers used Venus uses a three-tier ResilientOracle architecture (deployed at 0x6592b5DE802159F3E74B2486b091D11a8256ab8A on BSC). Providers: Chainlink (primary for most assets), RedStone (primary for BNB), Binance Oracle (fallback), plus in-house correlated-token oracles for LSTs/LRTs. 14 Chainlink feed addresses confirmed in data cache. Multi-chain deployments (Ethereum, Arbitrum, Optimism) use SequencerChainlinkOracle + RedStone.
RD-F-049 green Oracle role per asset Three explicit oracle roles per asset: MAIN (most trusted), PIVOT (sanity checker), FALLBACK (backup). TokenConfig struct in ResilientOracle.sol stores address[3] oracles indexed by OracleRole enum (MAIN=0, PIVOT=1, FALLBACK=2). Example: BNB uses RedStone (main), Chainlink (pivot), Binance (fallback). Roles are governance-configurable per asset via VIP.
RD-F-050 green Dependency graph (protocols depended upon) Dependency graph confirmed: (1) Chainlink AggregatorV3 feeds on BSC (14 in data cache); (2) Binance Oracle feed registry; (3) RedStone push oracle; (4) LayerZero endpoint + default DVN (XVS bridge only); (5) underlying BEP-20 token contracts. No Aave, Uniswap, or Curve dependencies identified. ResilientOracle at 0x6592b5DE802159F3E74B2486b091D11a8256ab8A on BSC.
RD-F-051 green Fallback behavior on oracle failure ResilientOracle implements cascading three-tier fallback via try-catch pattern. If main oracle fails (zero price, revert, or BoundValidator rejection against pivot), fallback is tried against pivot. If all three tiers fail or diverge, transaction reverts with 'invalid resilient oracle price' — no last-known-price acceptance. Try-catch prevents individual oracle reverts from halting execution. OpenZeppelin May 2023 audit found zero critical/high findings.
RD-F-056 green Single-pool oracle (no medianization) ResilientOracle with BoundValidator provides medianization at the protocol adapter layer across 3 diverse providers. Chainlink uses multi-node aggregation (not single pool). BNB has RedStone (main), Chainlink (pivot), Binance (fallback) — three independent sources. Major assets do not rely on a single pool or single exchange. For thin-liquidity assets, multi-source can still converge if all venues are manipulated simultaneously (demonstrated in THE attack).
RD-F-061 green LP token balanceOf used for pricing Venus's primary oracle stack (Chainlink/RedStone/Binance) does not use LP token balanceOf for pricing. In-house correlated token oracles (AnkrBNBOracle, SlisBNBOracle, etc.) use staking exchange rates, not raw LP balanceOf. No evidence of donation-manipulable LP-balanceOf pricing in active markets.
RD-F-180 green Immutable oracle address [★ CRITICAL per T-14] ResilientOracle stores feed addresses in governance-replaceable mappings. Functions confirmed in source: setOracle(asset, oracle, role), setTokenConfig(TokenConfig), enableOracle(asset, role, bool). Oracle addresses are NOT EVM immutable. Governance (via VIP + applicable Timelock tier) can replace any oracle for any asset. Compound-fork pattern preserves this replaceability — oracle is an external call to a mutable mapping. GREEN: no immutable oracle address risk.
Economic risk Yellow 36 13 of 13
RD-F-067 red Historical bad-debt events Four documented bad-debt incidents: (1) May 2021 XVS oracle manipulation: ~$100M bad debt (4,100 BTC + 9,600 ETH); (2) May 2022 LUNA/UST collapse (stale Chainlink oracle): ~$11–14M bad debt; (3) February 2025 ZKSync donation attack: ~$717K net bad debt; (4) March 2026 BNB Chain THE donation attack: ~$2.15M bad debt. Total approximately $114M across four distinct incidents. The 2021 and 2022 bad debt was never fully repaid from on-chain reserves. The March 2026 bad debt repayment proposal (~$2.2M from Treasury + Risk Fund) was in community discussion as of March 20, 2026, with execution status unconfirmed as of 2026-04-28. Incidents 3 and 4 are same-root-cause repeats (Compound-fork donation attack), post-Code4rena-2023 disclosure. This is the clearest red factor beyond F070 itself. RD-F-070 red Empty cToken-style market (zero supply/borrow) [CRITICAL ★] Venus has been exploited twice via the Compound-fork vToken donation/exchange-rate inflation attack: (1) February 2025, ZKSync Era: ~$717K net bad debt; (2) March 15, 2026, BNB Chain Core Pool (vTHE market): ~$2.15M bad debt, $3.7M extracted. Root cause in both cases: vToken getCash() returned balanceOf(address(this)) allowing attackers to inflate the exchange rate 3.81x via direct ERC-20 donation transfers, bypassing the supply cap check. Code4rena 2023 audit flagged this vulnerability; Venus dismissed it as 'intentional with no negative side effects.' VIPs 600–602 proposed the internalCash storage-variable fix across all chains (March 20, 2026). Critical gap: vBNB (native BNB market in Core Pool on BSC) is IMMUTABLE and cannot receive the patch — explicitly identified in community governance forum with no mitigation response. Additional follow-on syncCash initialization proposal (April 10, 2026) required for Ethereum and Arbitrum isolated pool markets (15 Ethereum + 3 Ar RD-F-064 yellow TVL concentration (top-10 wallet share) 99.44% of TVL ($1.255B of $1.262B) is on BSC (BNB Chain). Single-chain concentration creates systemic exposure: a BSC network halt, regulatory action, or validator crisis would affect near-total protocol TVL. Wallet-level top-10 depositor concentration is not available from free-tier data (Dune returns 403). Historical evidence from the 2021 XVS incident confirms that a single large borrower / coordinated set can cause $100M+ bad debt on the Core Pool's shared-liquidity model. Chain-level concentration confirmed as yellow; wallet-level flagged but unquantified. RD-F-065 yellow Liquidity depth per major asset Major assets (BNB, USDT, USDC, BTCB, ETH) have deep BSC DEX liquidity sufficient for orderly liquidation. Long-tail and governance-token collateral is demonstrably insufficient. March 2026 THE exploit: 254 bots executed 8,048 liquidation transactions against the THE/Thena market, yet $2.15M bad debt remained because THE's thin DEX liquidity (DEX price moved from $0.26 to $0.51 through recursive on-chain manipulation) could not absorb the position at scale. This is a live, high-confidence data point for thin-liquidity collateral failure. Isolated pool architecture theoretically ring-fences this risk, but the March 2026 exploit hit the Core Pool (shared liquidity), amplifying the systemic exposure. RD-F-068 yellow Collateralization under stress Venus enforces liquidation via Comptroller with 50% close factor (standard) and forced liquidation at 100% when flagged. The Core Pool uses shared liquidity; a single large market disruption propagates across the pool (evidenced in 2021). Protocol has since added supply caps, borrow caps, collateral factor reductions, and Risk Stewards for dynamic parameter adjustment. The Risk Fund for Isolated Pools is funded at ~50% of pool income. However, the Core Pool lacks automatic bad debt tracking at the moment (per Risk Fund docs), relying on treasury funding for shortfall resolution. Curator simulation not performed (PH curation required). Historical record shows the protocol has breached 100% collateralization under stress (2021 XVS: >$100M bad debt created). Not confirmed to be currently below 110% under standard parameters; flagged yellow given history. RD-F-069 yellow Algorithmic / under-collateralized stablecoin VAI is Venus's USD-pegged synthetic stablecoin. It is over-collateralized by construction: minting requires at least 200% collateral backing (50% collateral factor applied to Venus-supplied collateral). VAI has a Peg Stability Module (PSM) allowing 1:1 swaps with USDT/USDC at low fees to mechanically anchor the peg. VAI is NOT an algorithmic under-collateralized design (not Terra/LUNA style). However, XVS (governance token) can be used as collateral to mint VAI. XVS is subject to governance-driven emission, concentration, and price manipulation risk (2021 incident: XVS pumped 90% to enable $100M+ bad debt). An XVS price collapse could force VAI-collateral liquidations, creating an indirect soft-algorithmic feedback loop. This is a second-order risk, not a primary algorithmic design flaw. Score: yellow (soft loop risk, not a hard algorithmic design failure). RD-F-071 yellow Seed-deposit requirement for new market listing Isolated Pool market listings require an initialSupply parameter in the AddMarketInput struct, providing a seed deposit before the market goes live. This partially mitigates the zero-supply empty-market condition. However, the March 2026 THE exploit demonstrates the donation attack is effective on active markets with substantial supply (THE market had 12.2M tokens in genuine deposits, representing 84% of the 14.5M supply cap, before the attack). A seed deposit alone does not prevent the donation attack on active markets. For Core Pool markets, no governance-required minimum seed deposit mechanism was identified in public documentation. The seed deposit mitigates the pure zero-supply empty-market scenario but does not cover the active-market donation pathway that was exploited. RD-F-073 yellow Oracle-manipulation-proof borrow cap The March 2026 THE incident directly evidences a failure of borrow cap protection when the underlying collateral market can be manipulated via donation. The 14.5M THE supply cap was bypassed by inflating the exchange rate rather than increasing supply count — circumventing the borrow cap indirectly. The attacker borrowed $14.9M against a market capped at $14.5M tokens. Even had a stricter oracle-based borrow cap been in force, the exchange rate inflation (3.81x) would have allowed proportionally larger borrowing against the manipulated collateral value. Risk Stewards (February 2026) aim to enable dynamic cap adjustment but were not operational at the time of the exploit. Current score: yellow (mechanism present but demonstrated insufficient for thin-liquidity manipulable collateral). RD-F-074 yellow ERC-4626 virtual-share offset (OZ ≥4.9) Venus uses OpenZeppelin contracts version 4.9.3 (confirmed in data cache: oz_contracts_version: 4.9.3). OZ 4.9.x introduced the virtual-share offset (decimal offset) in ERC4626 as the canonical first-depositor inflation mitigation. If VenusERC4626 inherits from OZ 4.9.3 ERC4626Upgradeable, the virtual-share offset should be present by default. However, the Venus ERC-4626 vault documentation does not explicitly confirm the virtual-share offset is active — it references ERC4626Upgradeable without naming the offset mechanism. Without source code inspection confirming the offset pattern, confidence is medium-low. Score: yellow (likely protected via OZ 4.9.3 but not confirmed from documentation alone). Curator should verify via source read of VenusERC4626.sol. RD-F-075 yellow First-depositor / share-inflation guard Three layers to assess: (1) ERC-4626 vaults — OZ 4.9.3 provides first-depositor guard via virtual-share offset if properly inherited (see RD-F-074; unconfirmed from docs alone). (2) Isolated Pool vToken markets — initialSupply seed deposit required at market listing (partial guard). (3) Core Pool vToken markets — the March 2026 exploit demonstrated the first-depositor guard is insufficient for active markets: donation attack effective on market with 12.2M tokens of genuine supply by inflating exchange rate via direct transfer. The internalCash patch (VIPs 600–602) is the intended fix, but is unconfirmed as fully deployed, and vBNB is immutable/unpatched. Residual: the active-market donation pathway is the exploited surface; the first-depositor empty-market guard does not address it for markets with existing depositors. Score: yellow (partial guard present, active-market pathway remains exposed in vBNB).
RD-F-063 green TVL (current + 30d trend) TVL $1.262B as of 2026-04-28 (DefiLlama API). 30-day change +2.62% (flat-to-slight-up). 1-day change -1.95%. Protocol exceeds the $100M coverage floor by 12.6x. 99.44% concentrated on BSC; 7 other chains <1% combined. 2025 annual average supply ~$2.53B (Messari Q3 2025), indicating current snapshot is ~half the 2025 average following market contraction and the March 2026 THE incident. TVL metric itself is healthy; concentration risk captured separately in RD-F-064.
RD-F-066 green Utilization rate (lending protocols) Protocol-wide utilization rate: 41.85% ($528M borrowed / $1.262B supplied) as of 2026-04-28 (DefiLlama borrow data). This is elevated vs the 2025 annual average of 30.48% (Messari Q3 2025) but within normal DeFi lending ranges. No utilization-driven liquidity crisis is evident at the protocol level. Per-market breakdown not available from free-tier API for all Core Pool markets, introducing some uncertainty on individual market utilization. BNB borrow is approximately 39% of total borrow by volume (Q3 2025, Messari), indicating some borrow-book concentration.
RD-F-072 green Market-listing governance threshold New market listings require a Venus Improvement Proposal (VIP) vote via Governor Bravo on BSC — not permissionless. The Risk Stewards framework introduced (deployment parameters proposed February 27, 2026) enables automated supply/borrow cap adjustments within DAO-defined bounds without a full VIP for routine parameter changes, while retaining governance control for new listings and major parameter changes. This represents a moderately high governance threshold appropriate for a $1.26B protocol. The March 2026 THE incident occurred on a VIP-listed market, but this reflects oracle and liquidity risk in market selection rather than a listing governance failure per se.
Operational history Yellow 48 15 of 15
RD-F-077 red Prior exploit count 4 distinct protocol-exploiting incidents: (1) 2021-05-18 XVS oracle manipulation ~$95-100M bad debt partial recovery; (2) 2022-05-12 LUNA stale-price oracle $13.5M bad debt partial recovery; (3) 2025-02-27 ZKSync donation attack $716K bad debt partial recovery; (4) 2026-03-15 BNB Chain THE donation attack $2.15M bad debt no confirmed recovery. Threshold: >=2 exploits with unrecovered loss = red. Venus has 4 exploits and unrecovered losses confirmed across multiple incidents. September 2025 phishing ($27M at risk, $13.5M recovered) classified as user-phishing not a protocol smart contract exploit and excluded from this count. RD-F-078 red Chronic-exploit flag (≥3 incidents) 4 distinct protocol-exploiting incidents confirmed across Venus Protocol lifetime (2021, 2022, 2025-02, 2026-03 - most recent: $3.7M loss via donation-attack supply-cap bypass on BNB Chain THE market). Threshold: >=3 incidents = red. Note: CHRONIC badge per PD-022 requires >=3 same-root-cause exploits in 24 months with >=2 post-disclosure; that threshold is not separately met (only 2 donation-vector incidents confirmed: 2025-02 ZKSync wUSDM and 2026-03 THE). F078 fires on total incident count alone. RD-F-079 red Same-root-cause repeat exploit Two incidents with same root-cause cluster: Compound-fork donation-attack / vToken exchange-rate manipulation. (1) 2025-02-27 ZKSync: attacker donated USDM to wUSDM vault inflating exchange rate, exploited Venus ZKSync for $716K bad debt. (2) 2026-03-15 BNB Chain: attacker directly transferred THE to vTHE contract bypassing mint() supply cap, inflated exchange rate 3.81x, $2.15M bad debt. Both post-Code4rena 2023 disclosure of the exact mechanism (M-10 finding, dismissed by Venus team as 'intended behavior'). Root-cause cluster: Donation Attack / Supply Cap Bypass (Compound-fork vToken exchange-rate inflation). This is the most severe F079 finding class: dismissed audit finding exploited twice. RD-F-080 red Days since last exploit Most recent exploit: 2026-03-15 (BNB Chain THE donation attack). Assessment date: 2026-04-28. Days since last exploit: 44 days. Threshold: <90 days = red. RD-F-089 red Insurance coverage active No active third-party insurance coverage found on Nexus Mutual, Unslashed, Sherlock, or equivalent. Venus operates its own Risk Fund for bad debt socialization but this is not external insurance. Data cache has no insurance fields populated. Protocol has $1.26B TVL with zero external coverage. Score: red. RD-F-081 yellow Post-exploit response score Curator scored most recent incident response (2026-03-15 THE exploit) on four dimensions: (1) Compensation completeness 1/5 — bad debt repayment proposal posted 2026-03-20 but vote/execution outcome unconfirmed; liquidated users not compensated. (2) Disclosure transparency 3/5 — post-mortem in 2 days, root cause stated, contracts named; Code4rena finding not acknowledged; no code diff linked. (3) Root-cause analysis depth 3/5 — attack flow technically described; systemic cross-deployment issue not addressed in post-mortem. (4) Operational recovery speed 4/5 — borrows paused ~3h post-attack; collateral factors zeroed on 6 markets; bad debt governance proposal within 5 days. Composite: ~2.75 = yellow (score 2-3 range). RD-F-083 yellow Auditor re-engaged after last exploit Venus THE post-mortem (2026-03-17) references 'mid-term complete core pool re-audit planned' but provides no specific firm, timeline, or engagement confirmation. No evidence found of a formal re-audit commissioned and completed in the 44 days between the March 2026 exploit and assessment date. Hashdit flash loan audit (2025-10-16) predates the THE incident. Score: yellow (re-audit planned, not confirmed as engaged/completed for exploited code). RD-F-084 yellow TVL stability (CoV over 90d) Data cache shows TVL at $1.262B on 2026-04-28 with +2.62% 30d change and -1.95% 1d change. March 2026 exploit occurred 44 days before assessment within the 90-day window, creating incident-driven volatility spike in the CoV calculation window. Full 90-day daily series not computed from available data. Based on 1d/30d trend data and incident timing, CoV likely exceeds 0.15 green threshold due to the incident but appears below 0.35 red threshold (protocol resilient; TVL recovered). Score: yellow (CoV estimate 0.15-0.35; incident within window). RD-F-085 yellow Incident response time (minutes) Most recent incident (2026-03-15 THE exploit): William Li publicly posted attacker address in real time; Venus issued first official statement approximately 2 hours after Li's alert. THE borrows paused approximately 3 hours after Li's alert. The 2-hour window for first statement falls in the 61-240 minute yellow band (>60 min threshold for green, <240 min threshold for red). Score: yellow. Note: this is the second-fastest response in Venus's history; the September 2025 phishing incident had a faster 13-hour full recovery, but first statement timing was not precisely confirmed. RD-F-086 yellow Pause activations (trailing 12 months) At minimum 2 documented pause activations in trailing 12 months (April 2025 – April 2026): (1) March 2026 THE incident — THE borrows/withdrawals paused, collateral factors zeroed on 6 markets; (2) September 2025 phishing incident — protocol paused to prevent attacker from moving phishing proceeds. Both pauses had documented reasons and operational rationale. Threshold: 1-2 pauses with documented reason = yellow. Score: yellow. RD-F-166 gray Deprecated contracts still holding value No formally deprecated contract addresses with residual balances have been identified from public sources as of 2026-04-28. Venus has evolved its architecture (v1/v2 to Diamond Comptroller and Isolated Pools) via in-place upgrades rather than discrete deprecated addresses with stuck TVL. Without confirmed deprecated contract addresses and on-chain balance reads, this factor cannot be assessed. Flagged for code-security-analyst to verify original v1/v2 Comptroller addresses on BscScan.
RD-F-076 green Protocol age (days) Venus Protocol mainnet launched November 2020. As of 2026-04-28, approximately 65 months (~1,978 days) live. Threshold: >=365 days = green. XVS token BscScan creation confirms November 2020 launch.
RD-F-082 green Post-mortem published within 30 days THE incident (2026-03-15): post-mortem published 2026-03-17 = 2 days post-incident. ZKSync incident (2025-02-27): post-mortem published 2025-03-27 = 28 days post-incident. Both within the 30-day threshold. Most recent post-mortem (2 days) is commendably fast. Score: green.
RD-F-087 green Pause > 7 consecutive days September 2025 phishing incident: protocol resumed full operations within 13 hours (same day). March 2026 THE incident: protocol partially resumed within hours (THE borrows paused but broader protocol operational); full resumption within days. No evidence of any pause exceeding 7 consecutive days in trailing 12 months. Score: green.
RD-F-088 green Re-deployed to new addresses in last year No evidence of full protocol redeployment to new address sets in trailing 12 months. Venus upgrades occur via Diamond Comptroller facet upgrades and VIP governance processes within the existing contract deployment. No migration announcement observed. Governance forum does not show a redeployment proposal. Score: green.
Real-time signals Green 7 22 of 22
RD-F-090 yellow Mixer withdrawal → protocol interaction March 2026 THE-market attacker funded with 7,400 ETH withdrawn from Tornado Cash (June 2025), then interacted with Venus Core Pool for 9 months accumulating THE tokens. September 2025 Lazarus attacker laundered 2,301 ETH via Tornado Cash post-attack. Both incidents resolved as of 2026-04-28. Signal WOULD have fired continuously June 2025–March 2026 if live. No known active mixer-funded wallet interacting with Venus at assessment date. Scored yellow: historical confirmed mixer-to-protocol interaction with documented attacks; current posture resolved. RD-F-099 yellow Oracle price deviation >X% from secondary Threshold: primary/secondary oracle deviation >1% sustained 4 blocks. During March 2026 THE attack: Resilient Oracle BoundValidator reverted for approximately 37 minutes (Binance feed at ~$4 vs actual $0.26-$0.51, >700% deviation). BlockSec analysis: 'no monitoring system escalated this anomaly.' This is a documented real-world instance where RD-F-099 WOULD have fired at first block if wired. Current posture (2026-04-28): Chainlink feeds operative (ETH/USD 60s heartbeat, USDT/USD 900s heartbeat, BTC/USD 30s heartbeat). No active oracle deviation detected. Scored yellow: signal is applicable and would have caught March 2026 attack; documented infrastructure gap (monitoring not wired for this deviation class). RD-F-091 n/a Partial-drain test transactions v1-deferred per T-09 §3.3 (folded into RD-F-098 tier-B precursor rule; not a separate signal at v1). No partial-drain test transactions documented preceding March 2026 or September 2025 Venus incidents. RD-F-092 n/a Unusual mempool pattern from deployer wallet v1-deferred per T-09 §3.3 (PH; low count ~3 S). Venus deployer 0x1ca3ac3686071be692be7f1fbecd668641476d7e is a historical deployer; no evidence of recent unusual mempool patterns from deployer in available public data. RD-F-093 n/a Abnormal gas-price willingness from attacker wallet v1-deferred per T-09 §3.3. March 2026 THE attack did not use flash loans or abnormal gas-price competition; used patient capital accumulation over 9 months. No abnormal gas-price data publicly available for Venus-targeting wallets. RD-F-094 n/a New contract with similar bytecode to exploit template v1-deferred per T-09 §3.3. September 2025 phishing used attacker contract 0x7fd8...202a. No public bytecode similarity scan for Venus-targeting exploit contracts available at OSINT tier. Compound-fork donation-attack pattern is a known template but requires production exploit-template DB. RD-F-095 n/a Known-exploit function-selector replay v1-deferred per T-09 §3.3. The Compound-fork donation attack vector (direct ERC-20 transfer to vToken contract bypassing supply cap) is a documented replay pattern. If a known-exploit-replay signal were wired, the direct-transfer-to-vToken selector pattern would be the trigger. Not available in v1 production pipeline. RD-F-096 n/a New ERC-20 approval to unverified contract from whale v1-deferred per T-09 §3.3. September 2025 Lazarus attack involved victim signing a malicious delegation transaction (approval to attacker contract) — exactly the pattern RD-F-096 monitors. Not wired in v1 production pipeline. RD-F-097 n/a Sybil surge of identical-pattern transactions v1-deferred per T-09 §3.3. No documented sybil pattern for Venus in available sources. Assessment date 2026-04-28. RD-F-106 n/a Cross-chain bridge unverified mint pattern v1-deferred per T-09 §3.3. XVS LayerZero bridge uses burn-and-mint OFT model. Single DVN configuration is a structural concern (Cat 10) but no active unverified-mint event documented. Detection logic for cross-chain mint-without-proof is not in v1 pipeline. RD-F-107 n/a Admin EOA signing from new geography/device v1-deferred per T-09 §3.3. Guardian address 0x1C2CAc6ec528c20800B2fe734820D87b581eAA6B — signing geography not publicly determinable. Off-chain; no reliable public data source at OSINT tier. RD-F-108 n/a GitHub force-push to sensitive branch v1-deferred per T-09 §3.3. VenusProtocol/venus-protocol last commit 2026-04-27 (day before assessment). No force-push indicators publicly detected. Requires GitHub permissioned API access per-protocol. v1-deferred. RD-F-109 n/a Social-media impersonation scam spike v1-deferred per T-09 §3.3. Venus has documented phishing ecosystem targeting users (September 2025 Lazarus attack, SlowMist analysis). A social-media impersonation signal would be applicable given Venus's high BSC brand recognition. Requires social-media monitoring vendor. v1-deferred. RD-F-110 n/a Unusual pending/executed proposal ratio v1-deferred per T-09 §3.3 (derived from RD-F-101 analytics). Governor Bravo at 0x2d56DC... has normal VIP lifecycle. No unusual proposal ratio detected in available public data.
RD-F-098 green TVL anomaly — % drop in <1h Current TVL $1.262B, +2.62% 30d, -1.95% 1d per DeFiLlama. Threshold: TVL_now/TVL_baseline_30d < 0.70 over 60-min window (tier-A) or 7% sub-15-min drop to unknown EOA (tier-B precursor). March 2026 THE attack caused sub-1% aggregate protocol TVL drop (too small for tier-A fire); tier-B precursor would have fired during the borrow/extract phase. No active anomaly as of 2026-04-28. Retroactive coverage: tier-B would have fired during March 2026 attack; tier-A did not meet threshold at protocol-aggregate level.
RD-F-100 green Flash loan >$10M targeting protocol tokens Threshold: >$10M flash loan from Aave/Balancer/Uni receiver interacting with protocol oracle/lending/governor. March 2026 THE attack used patient capital accumulation (7,400 ETH Tornado Cash-funded position built over 9 months), NOT an external flash loan from a flash-loan provider. RD-F-100 would NOT have fired for this attack. Applicable to future attacks. No active flash-loan targeting event as of 2026-04-28.
RD-F-101 green Large governance proposal queued Governor Bravo at 0x2d56DC077072B53571b8252008C60e945108c75a on BSC. No anomalous governance proposals in queue as of 2026-04-28. September 2, 2025 social-engineering attack (compromised Zoom client -> attacker tricked user into delegating wallet control, ~$13M at risk) was detected by Chainalysis Hexagate ~18h before execution; Venus team paused markets within 20 minutes of the malicious tx, force-liquidated the attacker's wallet within ~7 hours, and recovered stolen funds, with a follow-up governance vote freezing $3M of remaining attacker assets. October 2025 delegation controversy (0x6027 to Venus Labs, 745K XVS) is a static concentration issue, not an active malicious-pattern proposal. Bad-debt repayment VIPs (March 2026) were legitimate emergency responses -- no malicious calldata pattern.
RD-F-102 green Admin/upgrade transaction in mempool No admin/upgrade tx pending in mempool publicly detected as of 2026-04-28. Critical Timelock at 0x939bD8d64c0A9583A7Dcea9933f7b21697ab6396 has 1-hour delay — narrowest detection window in M3a batch. The signal is applicable but operationally aggressive: any admin tx appearing in mempool would need to be acted on within 60 minutes. Current posture: no active admin tx. Signal infra note: mempool listener for BSC requires BSC RPC endpoint (not Ethereum mainnet).
RD-F-103 green Bridge signer-set change proposed/executed Venus LayerZero XVS bridge uses single default DVN per docs — structurally concerning (Cat 10 finding) but not a current signer-change event. No bridge signer-set changes publicly detected as of 2026-04-28. The lending protocol Core Pool has no bridge signer set. Applicable only to the XVS token bridge surface.
RD-F-104 green Stablecoin depeg >2% on shared-LP venue Venus Core Pool holds USDT (Chainlink 900s heartbeat 0x1B9...320), USDC (Chainlink 900s 0x51597...163), and BUSD. No active stablecoin depeg >2% as of 2026-04-28. The 2022 LUNA/UST collapse caused $11-14M bad debt via Chainlink LUNA/USD feed pause — oracle staleness variant of depeg risk, not a current exposure. Current USDT and USDC pegs stable per Chainlink.
RD-F-105 green DNS/CDN/frontend hash drift Venus frontend (app.venus.io) served via Cloudflare CDN, DNS on Cloudflare nameservers, AWS certs with auto-renew. SPF/DKIM configured per risk management docs. September 2025 phishing used fake Zoom client, not DNS hijacking. No frontend hash drift detected. Structural gap: no publicly published frontend hash baseline by Venus (production pipeline would need to establish baseline). Current posture: no drift detected.
RD-F-182 green Security-Council threshold reduction (RT) Batch-24 Cat 6B signal. Threshold: Security Council multisig executes threshold reduction or timelock removal within 14 days. Venus Pause Guardian at 0x1C2CAc6ec528c20800B2fe734820D87b581eAA6B (type unconfirmed — multisig vs EOA). Three Timelock tiers: Normal 48h, Fast-track 6h, Critical 1h. No documented threshold reduction or timelock removal events on Venus guardian or timelocks in recent months. 2021 governance attack context (stopped by Hexagate 18h before execution) is the closest historical analogue — that attack did not succeed in changing thresholds. Current posture: no active threshold reduction event.
Dev identity & insider risk Green 10 16 of 16
RD-F-112 yellow Team public accountability surface Brad Harrison has high accountability surface: 5+ documented conference appearances (Consensus 2025, EFDevcon Nov 2024, Crypto Valley Conference 2024, CoinMarketCap Capital Conference), YouTube video interviews, X account @bradherenow, LinkedIn. Joselito Lizarondo: Medium blog, X @joselito, public AMAs. However, the broader Venus Labs development team has thin public accountability surface — only one GitHub org public member (@therealemjy / Maxime Julian) identified. No individual developer LinkedIn profiles for the broader Venus Labs team were surfaced via public search. Yellow because leadership accountability is solid but development team surface is opaque beyond CEO level. RD-F-115 yellow Prior rug/exit-scam affiliation Unresolved 2021 XVS price-manipulation insider allegations. An anonymous account (@venus.insider on Medium, corroborated by coinfomania.com reporting) identified on-chain circumstantial evidence connecting: (a) the primary XVS manipulation wallet (0xef044206db68e40520bfa82d45419d498b4bc7bf) to the same Binance deposit address used by the Venus team for a $3.5M buy-back in April 2021; (b) the January 2021 Cannon Incident exploiter wallet to the same Binance deposit address; (c) Swipe's ecosystem reserves wallet to the same address. Venus official post-mortem stated 'no insider trading'; the Swipe team and Joselito Lizarondo subsequently departed from Venus. The allegations were never formally investigated by a third party and the shared-deposit-address evidence was not directly rebutted. This is unverified but rises above noise given the convergent on-chain evidence. Not a confirmed rug — scored yellow (elevated caution) rather than red (confirmed affiliation). RD-F-121 yellow Contributor OSINT depth score Brad Harrison: strong OSINT depth (LinkedIn, 5+ documented conference appearances, YouTube, CoinDesk speaker profile, X active). Joselito Lizarondo: strong historical OSINT depth (personal blog, Medium AMAs, Entrepreneur.com, X). @therealemjy (Maxime Julian): visible via GitHub public members only; limited OSINT depth found. Broader Venus Labs team: individual contributor OSINT depth not assessable from public data — no individual developer profiles beyond CEO were surfaced. Aggregate curator score: 3/5 (leadership excellent; development team depth opaque). Yellow because contributor OSINT depth below top-2 leadership is thin for a $1.26B TVL protocol. RD-F-123 yellow Sudden admin-rescue/ACL change without discussion Two documented instances of admin-level actions without preceding community governance discussion. (1) September 2021: The Venus Deployer address (acting as governance Guardian) cancelled a passed on-chain governance proposal ('Forming the Bravo Team') immediately after it passed 1.29M vs 1.19M votes on September 14, 2021. The cancellation was announced post-hoc in a community thread. No preceding governance-forum discussion or VIP preceded the cancellation decision — the Guardian exercised unilateral veto over a completed on-chain vote. (2) October 2025: Address 0x60277AdD339d936C4Ab907376afEE4f7aC17D760 delegated ~745,057 XVS to Venus Labs on October 14, 2025 without prior community discussion. Community members raised governance integrity concerns; Venus Labs did not officially respond. Assessment YELLOW rather than RED: (a) the Sept 2021 action was defensive against a hostile takeover attempt with bribed votes; (b) it predates the modern VIP/ACL framework; (c) no concurrent code de RD-F-116 gray Contributor tenure at admin-permissioned PR Venus Protocol has active GitHub commits through 2026-04-27 (per data cache). VenusProtocol org has one publicly listed member (@therealemjy / Maxime Julian). Contributor tenure for the most recent admin-permissioned PR (to governance-contracts or venus-protocol main repo) cannot be confirmed without direct GitHub API contributor history access for privileged file paths. The protocol has sustained 5+ years of development activity, suggesting an established contributor base, but individual tenures are not publicly confirmable from available data. RD-F-117 gray ENS/NameStone identity bound to deployer No ENS or NameStone name found bound to the primary deployer address 0x1ca3Ac3686071be692be7f1FBeCd668641476D7e. Venus Protocol is BSC-native (BEP-20 ecosystem); ENS is Ethereum-native. No BSC-equivalent name service binding found. The absence of ENS on a BSC-primary deployer is not a risk signal — it is expected for BSC-native deployments. Gray because the factor is not applicable in the negative sense for BSC-native addresses. RD-F-119 gray Commit timezone consistent with stated geography Venus Labs states US-based leadership (Brad Harrison: Fairfax Station, VA per LinkedIn). At least one contributor (@therealemjy / Maxime Julian) appears European. Globally distributed team is consistent with a protocol operating since 2020 with multiple audit engagements across international firms. GitHub commit-time distribution not analyzable from available public data without API access. No anomalous timezone clustering or commit-time patterns inconsistent with stated geography found in available evidence. DPRK-implant signal (unusual commit hours inconsistent with stated geography) not detected. Assessment: not assessable without GitHub API data; gray rather than forced green.
RD-F-111 green Team doxx status Founding team (Joselito Lizarondo) is real-name doxxed with extensive public trail: personal blog lizarondo.com, X @joselito, Entrepreneur.com author profile, multiple public AMAs (2020-2021). Current leadership (Brad Harrison, Venus Labs CEO) is real-name doxxed: LinkedIn profile (linkedin.com/in/bdharrison/, 292+ connections, Fairfax Station VA), conference speaker at Consensus 2025, Crypto Valley Conference 2024, EFDevcon Bangkok Nov 2024, multiple YouTube video interviews with face visible. GitHub public org member @therealemjy (Maxime Julian) identified. Leadership-level doxxing is strong; development team depth beyond top leadership is thin.
RD-F-113 green Team other-protocol involvement history Joselito Lizarondo: prior role as CEO/founder of Swipe (legitimate crypto debit-card business, acquired by Binance in majority-stake deal 2020). Swipe underwent Binance due diligence. No prior rug affiliations. Brad Harrison: prior roles in banking infrastructure and digital product (mentioned: BuzzFeed, Groupon, YouTube product work, bank fintech). No prior DeFi rug affiliations found for any team member. Venus Labs team beyond leadership: prior involvement history not assessable from public data, but no adverse signals found.
RD-F-114 green Deployer address prior on-chain history Deployer 0x1ca3Ac3686071be692be7f1FBeCd668641476D7e has BscScan public name tag 'Venus: Deployer'. 556 total transactions. Active from approximately November 2019 through last recorded activity 2024-03-27 (vesting contract deployments, proxy upgrades). No prior rug or exit-scam-labeled protocol deployments identified. History is consistent with legitimate protocol development and ongoing maintenance. The address was also used as the governance Guardian to cancel a hostile takeover attempt in September 2021, which is an administrative action but not a rug pattern.
RD-F-118 green Handle reuse across failed/rugged projects No evidence of any Venus team member's social handle being associated with a prior rugged or failed project under a different alias. @joselito (Joselito Lizarondo) is cleanly associated with Swipe Wallet (legitimate business with Binance acquisition). @bradherenow (Brad Harrison) is clean with consistent Venus Labs / DeFi identity. No handle-reuse flag identified across the team.
RD-F-120 green Video-off/voice-consistency flag Brad Harrison has multiple documented in-person conference appearances with video: Consensus 2025 (in-person speaker), EFDevcon Bangkok November 2024 (Venus Protocol X post confirms in-person attendance), Crypto Valley Conference June 2024 (X post), CoinMarketCap Capital Conference. YouTube video interviews are publicly available with face visible (e.g., 'The Evolution of Sustainable DeFi' video). No video-off or voice-consistency anomalies found. Joselito Lizarondo similarly has extensive AMA history. No curator-flagged inconsistencies in public appearances.
RD-F-122 green Contributor paid to DPRK-cluster wallet No on-chain payment path from Venus Protocol treasury to any DPRK-cluster-labeled or Lazarus-labeled wallet identified. Venus Labs received a $1.7M DAO reimbursement in 2025 via transparent on-chain governance vote (VIP approved by XVS token holders). This payment was on-chain via the Governor/Timelock system, publicly visible, and went to Venus Labs (not to any flagged wallet). No Lazarus cluster association identified with any Venus Labs payment recipient address from public sources.
RD-F-124 green Deployer wallet mixer-funded within 30 days Deployer 0x1ca3Ac3686071be692be7f1FBeCd668641476D7e was funded by intermediate wallet 0x76aFd2A963c081ba5EC2b9827A194d37dF914d59, which received its initial BNB from Binance Hot Wallet on approximately 2020-09-27 (BscScan confirmed). No Tornado Cash, Railgun, or similar mixer interactions identified on the deployer or its immediate funder within 30 days of the November 2020 protocol deployment. The funding chain is clean: Binance Hot Wallet (CEX) → intermediate wallet → deployer. Note: the March 2026 exploit attacker address received 7,400 ETH via Tornado Cash, but this is an external attacking EOA, not a protocol deployer or privileged address, and does not apply to RD-F-124.
RD-F-125 green Deployer linked within 3 hops to DPRK/Lazarus No DPRK or Lazarus Group proximity found in any public source, Chainalysis publication, OFAC SDN list lookup, or OSINT. Deployer funding chain traces: Deployer ← 0x76aFd2… (intermediate, 25 transactions, Sept 2020 origin) ← Binance Hot Wallet (OFAC-compliant major centralized exchange, not DPRK-associated). Team leadership consists of publicly identified Western individuals: Joselito Lizarondo (Filipino-American entrepreneur, Swipe/Binance affiliation), Brad Harrison (US-based, Harvard/Cambridge academic background). No OFAC SDN list entries found for any Venus-associated entity. No Chainalysis report or public DPRK cluster attribution found connecting Venus, Venus Labs, or any Venus-privileged address to the Lazarus Group or DPRK-affiliated clusters. BSC's Binance infrastructure affiliation does not create Lazarus proximity.
RD-F-184 green Real-capital social-engineering persona No curator-flagged or publicly documented instance of a 'team contributor' or 'external integrator' persona using >=1M real-capital deposits to build credibility ahead of a social-engineering attack on Venus Protocol. The March 2026 THE token attacker accumulated ~12.2M THE tokens over 9 months (wallet funded by 7,400 ETH via Tornado Cash), representing potential real-capital deployment. However, this is a classic oracle-manipulation attack via external asset accumulation — not a social-engineering persona infiltrating the Venus development team or governance structure (which is the F184 class per the Drift Protocol UNC4736 precedent: in-person conference attendance + durable-nonce pre-signing by infiltrated contributor). No evidence that any Venus Labs contributor or external integrator gained insider trust via real-capital deposits as a precursor to insider access. The Drift-class pattern (6-month conference build-up, durable-nonce pre-signed) has no analogous documented instance in
Fork / dependency lineage Yellow 30 10 of 10
RD-F-127 red Upstream patch not merged Compound v2 upstream has addressed the empty-market donation vulnerability. Venus Core Pool vToken exchange-rate accounting remains in the pre-patch Compound v2 state: getCashPrior() reads raw balanceOf without accounting for direct transfers separate from mint(). Code4rena 2023 M-10 flagged this; Venus dismissed it; Feb 2025 and March 2026 exploits confirmed the upstream patch was not merged. Post-March-2026 remediation is planned but not confirmed deployed. RD-F-128 red Upstream vulnerability disclosure (last 90d) The March 15, 2026 exploit (44 days before assessment date 2026-04-28) is within the 90-day window and represents active exploitation of the Compound-fork donation vector. The donation vector is now publicly known to be live in unpatched Compound v2 forks, effectively constituting an active disclosure affecting any unpatched Compound fork. This protocol was hit within the 90-day assessment window. RD-F-129 yellow Code divergence from upstream (%) Substantial divergence from Compound v2 baseline: Diamond proxy Comptroller, Isolated Pools architecture, Venus Prime, LayerZero XVS bridge, Multichain Governance, Two-Kinks interest rate model, ERC-4626 vaults, ACM access control, VAI stablecoin. Despite divergences, core vToken exchange-rate accounting remains Compound v2-derived. Quantitative line-count diff not determinable without local git clone. RD-F-132 yellow Fork has different economic parameters than upstream Venus uses substantially different economic parameters from Compound v2 defaults: BNB Chain-specific assets, different collateral factors, isolated pools with per-pool risk parameters. All deviations are audited by Venus-specific engagements. Yellow because the parameter deviations are extensive and the Compound-fork donation exploit demonstrates that inherited economic mechanics (exchange-rate accounting) remain load-bearing regardless of parameter changes. RD-F-133 yellow Dependency manifest uses unpinned versions isolated-pools/package.json uses @openzeppelin/contracts: ^4.8.3 (caret — allows minor updates). venus-protocol/package.json uses @openzeppelin/contracts: 4.9.3 (pinned). Main repo is correctly pinned; isolated-pools caret on OZ 4.8.x allows silent minor-version updates.
RD-F-126 green Is-a-fork-of Isolated Pools README explicitly states: 'Compound Fork Commit: https://github.com/compound-finance/compound-protocol/tree/a3214f67b73310d547e00fc578e8355911c9d376'. Core Pool is documented Compound v2 fork from November 2020. Fork lineage confirmed with specific upstream commit SHA.
RD-F-130 green Fork depth (generations from original audit) 1-hop fork: direct descendant of Compound v2. Venus is not a fork-of-a-fork. Upstream commit SHA a3214f67b73310d547e00fc578e8355911c9d376 directly identified.
RD-F-131 green Fork retains upstream audit coverage Venus commissioned fresh independent audits for its fork and extensions — 11 firms across 56+ reports for main repo, 18+ for isolated-pools. Not relying on Compound v2 original audits. Comprehensive Venus-specific audit record exists.
RD-F-134 green Dependency had malicious-release incident (last 90d) No malicious release incident for OpenZeppelin contracts (4.9.3 or 4.8.x) or other Venus dependencies (hardhat 2.22.18, ethers 5.7.0) in the last 90 days. OZ contracts are highly scrutinized with no recent supply-chain incidents.
RD-F-135 green Shared-library version with known-vuln status OpenZeppelin 4.9.3 (main repo, pinned) and ^4.8.3 (isolated-pools) are current stable releases in the 4.x series. No CVE or GHSA affecting these versions identified. Protocol does not use Solady (which had a recent advisory).
Post-deploy hygiene & change mgmt Yellow 40 13 of 13
RD-F-139 red Post-audit code changes without re-audit [CRITICAL] Code4rena 2023 audit flagged the donation/vToken exchange-rate inflation vulnerability. Venus assessed it as low-severity with no negative side effects and did not remediate. Exploited on zkSync Era February 2025 ($716K bad debt). Venus patched zkSync but NOT the BNB Chain Core Pool. BNB Chain exploited March 2026 ($2.15M bad debt via THE market). Canonical post-audit-acknowledged-but-not-deployed pattern. Two post-disclosure same-vector exploits. RD-F-140 red Fix-merged-but-not-deployed gap After February 2025 zkSync exploit, Venus merged a patch for zkSync VToken contracts. The same patch was NOT deployed to the BNB Chain Core Pool — confirmed by March 2026 exploit of identical vector on BNB Chain. Fix was merged for one deployment but not applied to the highest-TVL deployment (BNB Chain Core Pool $1.25B TVL). RD-F-137 yellow Upgrade frequency (per 90 days) Extremely high upgrade frequency — 12+ audit engagements in 2025 alone (unified comptroller, block rate, Solidity 8 upgrade, e-mode, flash loan). Diamond Comptroller facets replaced via VIPs. Estimated 5-15 VIPs per 90d affecting bytecode. High frequency is not inherently bad but creates ongoing code-drift surface. RD-F-142 yellow Storage-layout collision risk across upgrades Diamond Comptroller uses Diamond storage pattern — inherently storage-layout sensitive. Solidity 8 upgrade audits conducted in Aug-Sep 2025 (Certik + Quantstamp) suggest attention to storage layout. Isolated Pools use OZ upgradeable. Diamond storage collision risk not independently verified within budget. RD-F-143 yellow Reinitializable implementation (no _disableInitializers) Isolated Pools VToken.sol: _disableInitializers() called in constructor at line 115 (confirmed). Core Pool VToken.sol (old Compound v2 delegator pattern): uses manual require(accrualBlockNumber == 0 && borrowIndex == 0) guard — not OZ _disableInitializers(). VBep20Delegate.sol: empty constructor. Yellow: partial — isolated pools use correct pattern; legacy Core Pool uses manual guard (functional but not OZ canonical). RD-F-145 yellow Deployed bytecode reproducibility Venus is a Hardhat-based repo (hardhat_config_present=true, foundry_toml_present=false per data cache). No foundry.toml for deterministic compilation. Hardhat compilation is reproducible given exact config. Changelog present. Full bytecode reproducibility not verified within budget. RD-F-146 yellow New contract deploys in last 30 days March 2026 THE incident triggered a multi-chain patch fix VIP. This likely deployed patched contracts to multiple chains within 30 days of profile date. GitHub last commit 2026-04-27 (one day before profile) indicates active deployment activity. Fresh attack surface from recent deploys. RD-F-185 yellow Bridge rate-limiter / chain-pause as positive mitigant Guardian multisig can pause lending markets immediately (no timelock) — this is a positive mitigant for the core lending protocol. XVS bridge (LayerZero OFT) rate-limiter not confirmed from available docs or sources. Partial: market pause capability confirmed; bridge rate-limiter unconfirmed. RD-F-136 gray Deployed bytecode matches signed release tag Bytecode-to-signed-release-tag matching not performed within budget. Changelog present (data cache: changelog_present=true). 48+ audits exist. Full bytecode match deferred to code-security-analyst (RD-F-001 scope). RD-F-144 n/a CREATE2 factory permits same-address redeploy No CREATE2 factory deployment pattern identified for core governance or lending contracts. Diamond facet upgrades replace facet addresses. Not a material concern for this protocol architecture. [v1-deferred: only curator_note evidence available; downgraded per §14 Pass 3] RD-F-168 gray Stale-approval exposure on deprecated router Venus has significant architectural evolution (VBep20 → Diamond Comptroller → Isolated Pools; PSM deprecated). Stale user approvals to deprecated routers/contracts not assessed — requires allowance scan across multiple contract generations. Not assessed within budget.
RD-F-138 green Hot-patch deploys without timelock (last 30 days) March 2026 THE incident triggered a governance VIP patch fix (not a unilateral admin action). Even emergency patches use the Critical VIP path which still requires at minimum 1h timelock. No evidence of bypassing the declared timelock path.
RD-F-141 green Test-mode parameters in deploy No evidence of test-mode parameters in production. Timelock delays, quorum, and proposal threshold match documented governance topology. No deployer-as-admin in current governance path.
Cross-chain & bridge Yellow 20 12 of 12
RD-F-148 yellow Bridge validator count (M) LayerZero OFT V2 architecture — validator count determined by DVN configuration. Current configuration: single default LayerZero DVN (operated by LayerZero Labs). Effective validator count = 1. Venus docs explicitly acknowledge: 'Bridge relies on a single relayer, the default by LayerZero.' No confirmed upgrade to multi-DVN as of 2026-04-28. RD-F-149 yellow Bridge validator threshold (k-of-M) Single DVN = effective 1-of-1 threshold. This is the Kelp DAO 1/1 DVN configuration pattern (Kelp DAO $292M Apr 2026). Rate limiter in BaseXVSProxyOFT provides partial containment: per-tx USD limit, daily 24h limit, per-chain mint cap. Contingency: emergency wallet authorization via VIP in DVN downtime. These mitigants reduce maximum single-event loss but do not change the fundamental 1/1 threshold. RD-F-151 yellow Bridge ecrecover checks result ≠ address(0) [★ CRITICAL] OFT V2 does NOT use ecrecover for message validation. Sender validation uses keccak256(_srcAddress) == keccak256(trustedRemoteLookup[_srcChainId]) in BaseXVSProxyOFT. Classic ecrecover zero-address bug does not apply. However, the analogous failure mode is that the entire trust chain collapses to the single DVN: if the LayerZero DVN is compromised, no cryptographic proof at the contract level prevents forged lzReceive calls. The architecture replaces ecrecover with DVN-layer trust — assessed in F179. Marked yellow (not green) because the trust model substitution creates its own failure mode. RD-F-156 yellow Bridge uses same key custody for >30% validators Single DVN operated by LayerZero Labs = 100% key custody under one operator. Exceeds the >30% threshold trivially. This is a structural feature of the single-DVN configuration, not a multi-validator co-custody arrangement. Partially mitigated by rate limiter and mint caps. RD-F-157 yellow Bridge TVL per validator ratio XVS bridge TVL (governance token only) is a fraction of the $1.26B lending TVL. Exact per-chain XVS bridged amount not confirmed from data cache. Single DVN secures the full XVS cross-chain bridge. Rate limiters (daily/per-tx caps) and per-chain mint caps provide quantitative loss containment. Bridge TVL-per-validator ratio is not the primary risk surface here — governance token value versus bridge security cost is. RD-F-179 yellow LayerZero OFT DVN config (count, threshold, diversity) SINGLE DEFAULT DVN (1/1 configuration). Venus XVS bridge uses OFT V2 (BaseOFTV2 from @layerzerolabs/solidity-examples v2). DVN configuration not overridden in contract — uses default LayerZero DVN. Venus docs explicitly confirm: 'Bridge relies on a single relayer, the default by LayerZero.' Operator diversity = 0 (single operator = LayerZero Labs). This matches the Kelp DAO 1/1 DVN pattern (Kelp DAO $292M Apr 2026). Mitigants: (a) bridge guards XVS governance token only, not $1.26B lending TVL; (b) BaseXVSProxyOFT rate-limiter (per-tx + daily caps + per-chain mint cap); (c) emergency wallet authorization via VIP in DVN downtime. YELLOW (not RED) because bridge is governance-token-only and rate limiters provide containment. Would be RED if this were the primary lending TVL bridge. RD-F-150 n/a Bridge validator co-hosting Single DVN by definition — co-hosting concern is inapplicable. There is only one DVN operator (LayerZero Labs); no question of multiple validators sharing ASN/datacenter arises. Not a meaningful factor with 1-validator configuration. RD-F-155 n/a Bridge validator-set rotation recency Single DVN configuration means no validator-set rotation exists — there is only one validator (LayerZero Labs default DVN). The concept of a signer-set change does not apply. Venus governance can update trustedRemote configuration via VIP, but that is an OApp routing config change, not a validator-set rotation.
RD-F-147 green Protocol has bridge surface Venus uses LayerZero OFT V2 for XVS token bridge. XVSProxyOFTSrc deployed at 0xf8F46791E3dB29a029Ec6c9d946226f3c613e854 on BSC (source verified on BscScan). XVSBridgeAdmin proxy at 0x70d644877b7b73800E9073BCFCE981eAaB6Dbc21. Burn-and-mint model across BSC, Ethereum, Arbitrum, opBNB, zkSync Era, Optimism, Base (7 destination chains). Bridge is for governance token XVS only, not lending TVL.
RD-F-152 green Bridge binds message to srcChainId BaseXVSProxyOFT validates messages via trustedRemoteLookup[_srcChainId] — source chain ID is explicitly part of the trusted-remote key. Each pathway is independently configured. Cross-chain message binding to srcChainId is confirmed at the contract level.
RD-F-153 green Bridge tracks nonce-consumed mapping LayerZero endpoint handles nonce management at the protocol layer (sequential nonce assignment per pathway). OFT V2 uses _blockingLzReceive with nonce tracking at the endpoint level. retryMessage() in BaseXVSProxyOFT uses nonce_ parameter for failed message identification. Replay protection inherited from LayerZero V2 endpoint, not re-implemented in the Venus contract. Confidence: medium — nonce implementation details rely on LayerZero protocol docs, not Venus-specific source.
RD-F-154 green Default bytes32(0) acceptable as valid root [★ CRITICAL] Not applicable. Venus XVS bridge uses LayerZero OFT V2 message passing, not a Merkle root-based inbox. No acceptRoot(), prove(), or Merkle tree acceptance logic exists in XVSProxyOFTSrc or BaseXVSProxyOFT source code. The Nomad $190M bug class (default bytes32(0) accepted as valid root) is structurally inapplicable to LayerZero OFT V2 architecture.
Threat intelligence & recon Yellow 27 8 of 8
RD-F-158 yellow Known-threat-actor cluster has touched protocol Lazarus Group (DPRK-attributed) wallets directly held positions in Venus Core Pool during September 2025 phishing attack. Attacker wallet (partial 0xa21...23A7f) was force-liquidated within 12h by emergency governance vote; $13.5M recovered. SlowMist attribution: Lazarus-class social engineering (fake Zoom + malware). Signal WOULD have fired at attack initiation. As of 2026-04-28 no active Lazarus wallet interaction with Venus core contracts detected — positions fully liquidated. Scored yellow (not red) because the incident is resolved and positions liquidated; historical DPRK touch is documented but current threat cleared. The Lazarus wallet is a confirmed entry in any curated threat-actor cluster. RD-F-161 yellow Protocol-impersonator domain registered (typosquat) Venus has confirmed active phishing ecosystem targeting its users. September 2025 Lazarus attack used fake Zoom client ($13.5M targeted, recovered). Venus X account published formal Phishing Post-Incident Analysis (2026). SlowMist documented the attack as Lazarus-class social engineering. The breadth of the phishing apparatus implies brand impersonation infrastructure. No confirmed specific typosquat domain name confirmed from OSINT searches (WHOIS requires DomainTools API — structural gap). Venus is a top-3 BSC DeFi brand by TVL; brand impersonation probability is elevated. Scored yellow: documented phishing ecosystem, no confirmed active typosquat domain registration within 90 days from public OSINT sources. RD-F-162 yellow Known-exploit-template selector deployed by any address The Compound-fork donation attack vector (direct ERC-20 transfer to vToken contract inflating exchange rate) is a documented exploit template affecting Venus twice in 14 months: Feb 2025 ZKSync ($716K bad debt) and March 2026 BSC ($2.15M bad debt). A Code4rena audit identified the vulnerability in 2023 (Venus dismissed it). The pattern is known and has been deployed against Venus itself — making it a documented exploit-template-in-use-against-this-protocol. Post-March 2026 patch applied to affected markets. Multi-chain exposure (Ethereum, Arbitrum, zkSync Era, opBNB, Base, Optimism, Unichain deployments) means the template remains applicable until all chains confirm patching. Scored yellow: documented exploit template with Venus-specific in-sample instances; multi-chain patch confirmation pending. RD-F-163 yellow Avg attacker reconnaissance time for peer-class protocols March 2026 THE attack: attacker conducted approximately 270 days (9 months) of patient accumulation from June 2025 to March 2026 — the longest documented pre-strike reconnaissance window among M3a batch protocols. The 270-day window exceeds the USPD-class benchmark (78 days) by 3.5x. The accumulation was publicly visible on-chain throughout but no monitoring system flagged it (per BlockSec post-mortem). February 2025 ZKSync attack: same vector, reconnaissance timeline not publicly confirmed. Historical peer-class lending protocol average: 30–78 days. Venus's threat profile includes sophisticated actors capable of extended, low-signature reconnaissance far exceeding peer-class averages. RD-F-159 gray Attacker wallet pre-strike probe (low-gas failing txs) No publicly documented mempool probe activity (low-gas failing txs) preceding March 2026 or September 2025 Venus incidents. March 2026 attack proceeded from 9-month accumulation to execution without documented probe txs. September 2025 Lazarus attack used social engineering, not on-chain probe txs. Requires partner mempool feed to assess at the wallet-cluster level; not available at OSINT tier. RD-F-164 gray Leaked credential on paste/sentry site No publicly available evidence of Venus Protocol infrastructure credential leaks on paste sites or Sentry alternatives. September 2025 attack vector was social engineering (fake Zoom client), not credential leak from paste site. Requires paste-monitoring feed not available at OSINT tier. Structural data gap. RD-F-165 gray Protocol social channel has scam-coordinator flag Venus Discord and Telegram not confirmed in available public sources (profile §9 gap flagged). No scam-coordinator flags found in OSINT searches. Structural data gap — Discord/Telegram channel addresses required to monitor. Protocol profile notes Discord and Telegram channels not confirmed.
RD-F-160 green GitHub malicious-dependency incident touching protocol deps No GitHub security advisory flagging a malicious npm/PyPI/crates.io release in Venus Protocol dependency tree found in available public sources. OpenZeppelin v4.9.3 (per data cache field oz_contracts_version) has no known current CVEs. Last commit 2026-04-27 indicating active maintenance. No supply-chain compromise incidents found.
Tooling / compiler / AI Green 7 5 of 5
RD-F-174 yellow Dependency tree uses EOL Solidity version Solidity 0.5.16 and 0.5.17 are EOL (Solidity active support is 0.8.x series). Used for legacy contracts in production since 2020. No high-severity known bugs apply to these versions for Venus's usage patterns. Primary risk is forward-compat (new EIP support, compiler warnings) rather than current live vulnerability. Yellow for the EOL compiler status despite no active bug risk.
RD-F-170 green Solc version used (known-bug versions flagged) venus-protocol/hardhat.config.ts: solc 0.5.16 and 0.8.25 (evmVersion: cancun). isolated-pools: 0.8.25 (paris), 0.6.6, 0.5.16. BscScan confirms Timelock at v0.5.17. No high-severity known bugs for 0.5.16, 0.5.17, or 0.8.25. TransientStorageClearingHelperCollision bug (0.8.28-0.8.33) does not apply — Venus uses 0.8.25 and viaIR is not enabled.
RD-F-171 green Bytecode similarity to audited upstream with behavior deviation Venus is a documented fork of Compound v2 — bytecode similarity to upstream is intentional and documented. Divergences (Diamond Comptroller, Isolated Pools, Prime) represent genuine architectural evolution, not deceptive near-copies. No bytecode-deviation finding in any audit report.
RD-F-172 green Repo shows AI-tool co-authorship in critical files No AI-tool co-authorship in commit messages found in available commit history sample (Jan 2026). Recent commits from toolsvenus (automated release bot), fred-venus, Debugger022 follow standard developer commit patterns. No 'Co-authored-by: GitHub Copilot' or similar AI attribution found.
RD-F-173 green Team self-disclosure of AI-generated Solidity No team blog post, tweet, or documentation mentions AI-generated Solidity in security-critical code. Venus Labs governance forum communications reviewed — no AI disclosure found.
Response & disclosure hygiene Red 75 4 of 4
RD-F-175 red Disclosure channel exists No public disclosure channel of substance exists: (1) Immunefi immunefi.com/bug-bounty/venus/ returns 404; (2) No Sherlock program found; (3) No SECURITY.md in main GitHub repo (security_md_present: false in data cache); (4) Venus docs security page only states 'We offer a bug bounty program' with zero URL, email, platform or submission mechanism; (5) GitHub Security Advisories: zero published advisories; (6) README directs researchers to 'contact administrators of our Telegram chat' — not a formal channel. At $1.26B TVL this is a critical disclosure gap. Score: red. RD-F-176 red Disclosure SLA public No acknowledgment-time SLA published anywhere in Venus's public documentation, forum, or repository. The only security guidance is 'contact Telegram admin' — no timeline, no acknowledgment commitment, no SLA of any kind. Score: red. RD-F-177 red Prior known-ignored disclosure Evidence is unambiguous and constitutes a double ignored-disclosure: (1) Code4rena 2023 Isolated Pools contest flagged M-10: donation mechanic allows manipulating vToken exchange rate. Venus disputed and dismissed — characterized as 'intended behavior with no negative side effects.' (2) Feb 2025 ZKSync exploit ($716K) used this exact vector. Venus ZKSync post-mortem published but did not generalize fix to BNB Chain deployments. (3) March 2026 BNB Chain exploit ($2.15M) used the same vector on an unpatched deployment. This is the most severe F177 scenario: public competition audit finding dismissed, subsequently exploited twice on unpatched deployments, with the second exploit occurring 13 months after the first demonstration.
RD-F-178 green CVE/GHSA advisory issued against protocol GitHub Security Advisories for VenusProtocol/venus-protocol shows zero published advisories (confirmed by WebFetch: 'There aren't any published security advisories'). No NVD CVE found for Venus Protocol in available search results. Score: green. Note: the Code4rena M-10 finding is a public competition audit disclosure, not a formal GHSA/CVE advisory.
rubric_version v1.7.0 graded_at 2026-05-12 04:38:07 factors 184 protocol venus