defirisk.co
rubric v1.7.0

Veda (BoringVault)

Vault-infrastructure-as-a-service. Veda (formerly Se7en Seas) provides the BoringVault framework — a minimal immutable ERC-20 vault primitive plus a peripheral role-based stack (ManagerWithMerkleVerification, AccountantWithRateProviders, Teller/TellerWithLayerZero, RolesAuthority) used to build yield-strategy vaults. Deployed across 12+ chains; primary clients include ether.fi Liquid vaults, Lombard, Rings, and 100+ third-party operators. Not a user-facing yield aggregator — Veda is the infrastructure provider. Per-vault-governor model: each vault deployment has its own RolesAuthority controlling admin authority. BoringVault is NOT ERC-4626 (custom enter/exit with requiresAuth). Cross-chain share bridging via TellerWithLayerZero confirmed on mainnet. Original protocol (not a fork of another DeFi project; Se7en-Seas/boring-vault is same-team rebrand). $18M funding round June 2025 (CoinFund lead). Bug bounty on Immunefi ($1M max, launched 2026-01-21). Audited by 0xMacro (14+ engagements), Spearbit, Certora (2x), Sigma Prime.

Sector vault_infrastructure
TVL $1.1B
Reviewed May 17, 2026
Factors 184
Categories 13
Risk score 20.4
DeploymentsInk · $237.9M
01

Risk profile at a glance

0 red · 4 yellow · 9 green
25 24 17 13 15 22 16 10 13 12 8 5 4
02

Categories & evidence

184 factors · 13 categories
Code & audits Green 14 25 of 25
RD-F-001 yellow Audit scope mismatch 0xMacro A-4 (commit 939c77e) covers 45 core contracts. A-19 (commit b7ad406) covers LayerZeroTeller and FixedRateAccountant. Deployed liquidETH BoringVault (0xf0bb20865277abd641a307ece5ee04e79073416c) verified at v0.8.21+commit.d9974bed, consistent with repo. Peripheral stack (100+ DecoderAndSanitizer variants, 22+ chain deployments) not fully commit-matched across all incremental audits A-8 through A-45. Core-to-audit match is strong; peripheral coverage is partial. RD-F-002 yellow Audit recency A-19 (Oct-Nov 2024) is the most recent confirmed dated audit for a significant production component (LayerZeroTeller). A-45 (deposit cap) and A-44 (cross-chain solver decoders) are listed on docs.veda.tech but without explicit dates. GitHub last commit 2026-05-15 confirms active development beyond last confirmed audit. Estimated audit lag for latest peripheral components is 6-12 months — borderline yellow. Spearbit Arctic review and Certora dates unconfirmed. RD-F-006 yellow Audit-to-deploy gap A-4 signed April 1-5 2024; liquidETH BoringVault deployed approximately June 2024 (~60 days gap — borderline yellow at 60-day threshold). A-19 (Oct-Nov 2024) covers LayerZeroTeller; LayerZeroTeller at 0xe97365... deployed approximately February 2025 (~90-120 days gap). Both gaps are within or near the 61-180 day yellow band. RD-F-009 yellow Formal verification coverage Certora produced 2 formal verification reports (certora-boring-vault-0.pdf and certora-boring-vault-1.pdf) for BoringVault versions 0 and 1, stored in the audit directory. Exact invariant coverage percentage is not determinable from publicly accessible metadata (PDFs are binary, not parsed). Two Certora engagements indicates significant FV investment but specific coverage % is unconfirmed. Yellow: FV exists but coverage % cannot be verified. RD-F-012 yellow delegatecall with user-controlled target BoringVault's manage() calls target.functionCallWithValue(data, value) with requiresAuth guard. ManagerWithMerkleVerification passes strategist-supplied targets through merkle-proof verification before reaching vault.manage(). Merkle root is set by authorized admin only. This is NOT user-controlled delegatecall in the Parity-multisig sense — the allowlist is the merkle tree. However, calldata is partially user-sourced (strategist-supplied) even if target-constrained by merkle. Audited in A-4 with no critical findings. Yellow for architectural complexity rather than a direct exploit pattern. RD-F-013 yellow Arbitrary call with user-controlled target Same analysis as F012. The ManagerWithMerkleVerification accepts strategist-supplied targetData arrays and passes them through vault.manage(). While the merkle proof restricts which calls are allowed, the calldata is user-provided from strategists. The DecoderAndSanitizer validates calldata shape. A merkle root compromise would allow arbitrary calls. This is design-intentional and audited in A-4 with no critical findings. Yellow for architectural call-pattern complexity. RD-F-014 yellow Reentrancy guard on external-calling functions No published Slither reentrancy detector output is available. A-4 and A-8 audited the Teller and Accountant contracts with no high/critical findings. The enter()/exit() user-facing functions use requiresAuth. Without published tool output, the factor cannot be definitively assessed. Marked yellow ([?] confidence) rather than gray because the audit coverage provides partial assurance. RD-F-016 yellow Divide-before-multiply pattern No published Slither divide-before-multiply output. A-4 Medium finding M-3 specifically addressed decimal handling in rate calculations (an adjacent issue class); this was fixed. Without a current tool run, cannot confirm 0 remaining divide-before-multiply patterns in the deployed source. Yellow given the audit history of addressing this issue class but absence of current tool output. RD-F-024 yellow Code complexity vs audit coverage A-4 covered 45 contracts in a 5-day engagement (April 1-5, 2024). The boring-vault repo contains hundreds of Solidity files across DecoderAndSanitizer variants (one per external protocol integration), multiple accountant types, cross-chain tellers, helper contracts, and micro-managers — deployed across 22+ chains. The incremental audit series (13 documented engagements) covers new scopes piecemeal. Total code coverage relative to the deployed surface is not demonstrably complete. Yellow for ongoing complexity growth vs audit cadence. RD-F-183 yellow Bug bounty scope gap on highest-TVL contracts Immunefi program active with 52 assets in scope and $1M max payout. The publicly extractable portion of the Immunefi page lists out-of-scope items including 'Funds in other contracts, vaults, strategies, or positions' — which could introduce ambiguity for vault-specific peripheral deployments. The liquidETH BoringVault (0xf0bb20865277abd641a307ece5ee04e79073416c) is the highest-TVL contract; its explicit inclusion in the 52-asset scope could not be confirmed from the extracted page content. Yellow: scope likely covers primary vaults but explicit per-address confirmation is missing. RD-F-010 gray Static-analyzer high-severity count No published Slither/Mythril/Semgrep output is available in the boring-vault repo or audit PDFs. Source is verified on Etherscan and tool runs are feasible but have not been published. Static analysis tool run against the full verified source tree is needed to determine high-severity finding count. Marked gray [?] pending tool run. RD-F-018 gray Signed/unsigned arithmetic confusion No symbolic execution output (Manticore/Echidna) published. Solidity 0.8.21 has built-in overflow/underflow protection. No high/critical signed/unsigned arithmetic findings reported in A-4 or A-8. Cannot confirm absence without tool run. Gray [?].
RD-F-003 green Resolved-without-proof findings A-4 had 4 Medium findings (all addressed), 4 Low (3 addressed, 1 acknowledged), 2 Informational (unresolved but informational only). A-8 had 1 Low (fixed), 1 Informational (acknowledged). No high or critical findings in any audited scope. No finding marked 'Resolved' without verifiable on-chain proof for severity >= medium. The 2 unresolved items are informational-class only (MEV susceptibility, malicious-action acknowledgements) — not severity >= medium.
RD-F-004 green Audit count Confirmed distinct audit firms: (1) 0xMacro (13+ engagements), (2) Spearbit/Cantina (Arctic architecture review), (3) Certora (2 formal verification reports), (4) Sigma Prime (1 report). Additionally docs.veda.tech security page mentions Secure3 and Hexens as additional firms. At minimum 4 confirmed distinct firms with published audit artifacts.
RD-F-005 green Audit firm tier Certora (Tier-1 formal verification), Spearbit/Cantina (Tier-1 security firm), Sigma Prime (Tier-1 Ethereum security firm) all have confirmed audit artifacts in the Veda audit directory. At least three Tier-1 or equivalent firms have audited the codebase. 0xMacro is a recognized Tier-2 firm.
RD-F-007 green Bug bounty presence & max payout Active Immunefi bug bounty program launched 2026-01-21. Maximum payout $1,000,000 for critical smart contract vulnerabilities (10% of directly affected funds, minimum $100K). High tier: $10K-$25K. 52 assets in scope. Program is active and well-funded relative to TVL.
RD-F-008 green Ignored bounty disclosure No known security incidents. Rekt database has zero entries for Veda/BoringVault. No post-mortem documents an ignored disclosure. Protocol has no operational incident history to date.
RD-F-011 green SELFDESTRUCT reachable from non-admin path Source inspection of BoringVault.sol confirms no SELFDESTRUCT opcode. The contract uses immutable architecture with no self-destruct capability. The manage() function allows external calls only to requiresAuth callers (not user-controlled). No SELFDESTRUCT found in reviewed contracts (BoringVault, AccountantWithRateProviders, ManagerWithMerkleVerification, LayerZeroTeller).
RD-F-015 green ERC-777/1155/721 hook without reentrancy guard BoringVault.sol imports ERC721Holder and ERC1155Holder from OpenZeppelin — the standard safe-receipt pattern that does not introduce callback reentrancy risk. No ERC-777 integration detected. A-4 reviewed these integrations with no high/critical findings on callback paths.
RD-F-017 green Mixed-decimals math without explicit scaling AccountantWithRateProviders uses ONE_SHARE = 10 ** decimals as the normalization unit. A-4 Medium M-3 on decimal handling was fixed. The Accountant is explicitly designed to handle multi-decimal token normalization. The architecture normalizes consistently via the decimals parameter set at construction.
RD-F-019 green ecrecover zero-address return unchecked LayerZeroTeller.sol uses LayerZero OApp messaging, not ECDSA ecrecover directly. BoringVault.sol uses Solmate ERC20 permit() which implements the standard EIP-2612 ecrecover with address(0) guard (Solmate's confirmed implementation pattern). No unguarded ecrecover calls identified in reviewed source files.
RD-F-020 green EIP-712 domain separator missing chainId BoringVault.sol uses Solmate ERC20 permit() which implements standard EIP-712 DOMAIN_SEPARATOR including chainId per EIP-2612. Solmate's implementation is confirmed to include chainId in the domain separator. No custom EIP-712 implementation detected outside Solmate ERC20 permit.
RD-F-021 green UUPS _authorizeUpgrade correctly permissioned Not applicable in the UUPS sense — BoringVault, AccountantWithRateProviders, AccountantWithFixedRate, ManagerWithMerkleVerification, and LayerZeroTeller are all immutable non-proxy contracts. No UUPS _authorizeUpgrade function exists because the architecture deliberately avoids upgradeable proxies. Score green (N/A-equivalent: factor moot, no UUPS pattern present).
RD-F-022 green Public initialize() without initializer modifier No initialize() function found in any of the reviewed core contracts. BoringVault, AccountantWithRateProviders, AccountantWithFixedRate, ManagerWithMerkleVerification, LayerZeroTeller, and LayerZeroTellerWithRateLimiting all use standard constructors. The architecture is deliberately non-upgradeable (immutable primitives). No unprotected initialize() exists.
RD-F-023 green Constructor calls _disableInitializers() Not applicable — all core contracts use standard constructors, not proxy/initializer patterns. _disableInitializers() is an OZ pattern for UUPS/transparent-proxy implementations only. Since BoringVault and all peripherals are non-proxied, this protection is structurally unnecessary and correctly absent. Score green (N/A-equivalent).
Governance & admin Yellow 46 24 of 24
RD-F-032 red Timelock duration on upgrades TimelockController 0x80Ce8a917beec6Db0f632F2710916fcaA621874A: minDelay = 0 seconds (decoded from constructor args in deployment tx 0x85bd5824...). Zero enforced delay — the 3-of-5 Safe can propose and execute role changes or admin actions in the same block. The 3-of-5 Safe adds coordination cost but no time delay. Labeled 'Deployer Timelock V0.0' suggesting provisional/bootstrapping use, but it is now the live RolesAuthority owner. The separate ether.fi Timelock 0x9f26d4C9 has 3600s (1h) but is not confirmed linked to this vault cluster. RD-F-033 red Timelock on sensitive actions setManageRoot() in ManagerWithMerkleVerification requires only requiresAuth — no on-chain timelock. This is the most critical admin action (controls the entire strategist action set for ~$1.07B). pause()/unpause() on Manager: requiresAuth, no timelock. Rate updates in Accountant: minimumUpdateDelayInSeconds is a soft pacing guard, not a governance timelock. Admin role changes via RolesAuthority now route through TimelockController with minDelay=0 — effectively no delay. The 3-of-5 Safe path adds coordination cost but zero time delay for any of these actions. RD-F-040 red Emergency-veto multisig present No emergency-veto multisig found at the protocol level. Pauser.sol provides emergency pause on Manager but cannot veto TimelockController-scheduled operations. The TimelockController's controlling 3-of-5 Safe is also the proposer, executor, and admin — no external canceller role. A compromised 3-of-5 quorum can execute without any veto. RD-F-041 red Rescue/emergencyWithdraw without timelock [U18 RE-CITED — score unchanged] No discrete rescue/emergencyWithdraw function. The manage() + setManageRoot() pathway is the structural equivalent. Control path [U18 CONFIRMED]: 3-of-5 Safe (0xD6E47E0F34ECc031E676254fd8b0E61b656a15a5) → TimelockController (0x80Ce8a917beec6Db0f632F2710916fcaA621874A, minDelay=0) → RolesAuthority → setManageRoot(). The 3-of-5 Safe adds a coordination requirement (3-of-5 signer agreement) but does NOT add a time delay — a coordinated 3-of-5 can change the merkle root in a single transaction with zero enforced delay for user exit, authorizing the strategist to drain ~$1.07B in assets. This is structurally equivalent to an un-timelocked rescue/drain pathway. Critical for vault-infrastructure protocol at this TVL. RD-F-025 yellow Admin key custody type Per-vault RolesAuthority model. liquidETH cluster: deployer EOA owned RolesAuthority Jun 2024–Apr 2026. Ownership transferred Apr 20 + May 4 2026 to TimelockController (0x80Ce8a917beec6Db0f632F2710916fcaA621874A) with minDelay=0. TimelockController's sole proposer/executor = 3-of-5 Gnosis Safe 0xD6E47E0F34ECc031E676254fd8b0E61b656a15a5 (U18 confirmed). Categorical: nominally multisig+timelock but timelock delay = 0. RD-F-026 yellow Upgrade multisig signer configuration (M/N) [U18 RESOLVED — previously gray] TimelockController's sole proposer/executor is Gnosis Safe 0xD6E47E0F34ECc031E676254fd8b0E61b656a15a5 (Safe 1.4.1, created Dec 18 2025). Threshold = 3, owner_count = 5. Owners: 0xeC20A9462f7EdEc370AaD7c77bc999e054Ac4ba0, 0x6B3595C9A9262307075bA4a90EF6854a4802aC16, 0x162B522c4c8C4e246aebD23Ad236Da6831bB381a, 0x58a70365A6fD7A72172E2880Cb88CBcFcE2Db65d, 0x29d9dff059f3E321E1235ff74F3829Fa90D4eDd6. Signer identities not publicly attested to named individuals. Yellow: threshold and owners now known but identities unattested and no evidence of geographic/custody separation. RD-F-027 yellow Single admin EOA [U18 RE-CITED] Deployer EOA 0x0463e60c (ether.fi: Deployer 4) controlled RolesAuthority for ~24 months (Jun 2024–May 4 2026). Now transferred to TimelockController (minDelay=0) controlled by a verified 3-of-5 Gnosis Safe (U18 confirmed: threshold=3, owner_count=5). Single-key risk is eliminated by the 3-of-5 threshold. Not red because the 3-of-5 Safe provides genuine multisig protection (requires 3-of-5 signer coordination). Not green because: zero-delay timelock provides no exit-reaction window, and the 24-month historical EOA period is a material historical risk. RD-F-028 yellow Low-threshold multisig vs TVL [U18 RESOLVED — previously gray/protocol_opacity] Safe 0xD6E47E0F34ECc031E676254fd8b0E61b656a15a5 confirmed 3-of-5 (Safe Transaction Service mainnet API: threshold=3, owner_count=5). Five owner addresses confirmed. At $1.07B vault-infrastructure TVS with a zero-delay TimelockController (minDelay=0), a 3-of-5 threshold is below best-practice for this TVL tier (DeFi high-security posture typically requires 4-of-7 or higher with attested signer identities). Signer identities are not publicly disclosed — no ENS names or public team attribution for any of the 5 addresses. Not red because a genuine 5-owner Safe (not 1-of-2 or equivalent) provides non-trivial multisig protection requiring 3-signer coordination. Yellow reflects threshold adequacy gap relative to $1.07B TVL and the zero-delay execution pathway. RD-F-031 yellow Signer rotation recency Significant signer-set change: TimelockController deployed May 4 2026 (13 days ago) with Safe 0xD6E47E0F (3-of-5, U18 confirmed) as sole proposer/executor. Prior structure: deployer EOA directly. This is a major governance restructuring event within the last 30 days. The 3-of-5 Safe was created Dec 18 2025 (~5 months ago). Recent rapid change warrants yellow — new structure is young and untested under adversarial conditions. RD-F-034 yellow Guardian/pause-keeper distinct from upgrader Pauser.sol contract exists for emergency pause of ManagerWithMerkleVerification. MULTISIG_ROLE is documented as pause/unpause caller. Whether this role is held by a distinct address from the RolesAuthority owner (the 3-of-5 Safe via TimelockController) is not confirmed on-chain within time budget. Structural separation exists in code but on-chain role assignment verification incomplete. RD-F-035 yellow Role separation: upgrade ≠ fee ≠ oracle RolesAuthority assigns distinct roles: MINTER_ROLE (Teller), MANAGER_ROLE (strategist), MULTISIG_ROLE (pause). Separate Accountant for fee/rate management. However, the single 3-of-5 Safe/TimelockController (minDelay=0) that owns RolesAuthority controls all role assignments. Effective role separation is constrained by the single controlling Safe. RD-F-038 yellow Proposal execution delay < 24h No Governor proposal execution path, but the TimelockController with minDelay=0 is the admin execution pathway. Any role change or admin action can be proposed and executed in the same block by the 3-of-5 Safe — zero delay. Technically N/A for the Governor definition, but scored yellow because the effective admin-action delay is 0. RD-F-043 yellow Admin = deployer EOA after 7 days [U18 RE-CITED — score unchanged] Deployer EOA 0x0463e60c remained effective admin of the RolesAuthority from June 2024 through May 4 2026 (~23 months), far exceeding the 7-day transfer window. Transfer to TimelockController+Safe completed May 4 2026. [U18 CONFIRMED] The transfer went to a verified 3-of-5 Gnosis Safe — a proper multisig, not another EOA. Long-tail risk period is historical. Yellow because: (1) 23-month EOA period is a material historical risk; (2) the confirmed 3-of-5 receiving Safe is genuine but the current zero-delay TimelockController provides only nominal improvement over EOA-level response speed. RD-F-167 yellow Deprecated contract paused but pause reversible by live admin The 'old Teller' 0x5c135e8eC99557b412b9B4492510dCfBD36066F5 is listed as 'still active' in ether.fi documentation rather than formally deprecated/sunset. Admin (now the 3-of-5 Safe via TimelockController) retains control over all active contracts including old Teller. If still operational, this is a concurrent attack surface. RD-F-029 gray Multisig signers co-hosted Five signer addresses for Safe 0xD6E47E0F are now known (U18): 0xeC20A9462f7EdEc370AaD7c77bc999e054Ac4ba0, 0x6B3595C9A9262307075bA4a90EF6854a4802aC16, 0x162B522c4c8C4e246aebD23Ad236Da6831bB381a, 0x58a70365A6fD7A72172E2880Cb88CBcFcE2Db65d, 0x29d9dff059f3E321E1235ff74F3829Fa90D4eDd6. However, public identities, custody arrangements, and geographic distribution remain unattested — no ENS labels or team attribution for any of the 5 addresses. Cannot assess co-hosting or shared custody without on-chain graph analysis. RD-F-030 gray Hot-wallet signer flag Five signer addresses now known (U18 — see F029). Hot-wallet heuristics (Nansen tags, mixer history, on-chain activity pattern) not applied within assessment scope. Cannot confirm or deny without dedicated on-chain graph analysis. RD-F-036 n/a Flash-loanable voting weight No on-chain Governor, no DAO governance token with voting weight, no Snapshot space. Per-vault RolesAuthority model has no voting mechanism that could be flash-loan attacked. Not applicable by construction. RD-F-037 n/a Quorum achievable via single-entity flash loan No governance voting mechanism exists. Quorum concept is inapplicable. RD-F-039 n/a delegatecall/call in proposal execution without allowlist No on-chain Governor or proposal execution path. The BoringVault manage() uses call() constrained by Merkle verification — this is a code-security concern (Cat 1), not a governance-execution concern. Not applicable for the governance-executor pattern. RD-F-042 n/a Admin has mint() with unlimited max BoringVault uses enter() (MINTER_ROLE) for share minting via Teller — constrained by deposit flow and share lock period. No admin-callable unlimited mint() function. Not applicable. RD-F-044 gray Admin wallet interacts with flagged addresses Deployer EOA 0x0463e60c has ENS 'troglobyte.eth' and Etherscan label 'ether.fi: Deployer 4'. No mixer or flagged address interactions found in available sources. Full Chainalysis-style on-chain graph analysis not performed. RD-F-047 n/a Governance token concentration (Gini) No on-chain governance token with voting rights in the BoringVault system. VEDA token exists but no confirmed voting mechanism.
RD-F-045 green Constructor args match governance proposal No governance proposals exist. Constructor args verified on Etherscan for BoringVault 0xf0bb20865277: _owner=0x0463e60c, _name='Ether.Fi Liquid ETH', _symbol='liquidETH', _decimals=18. Matches public documentation.
RD-F-046 green Contract unverified on Etherscan/Sourcify BoringVault 0xf0bb20865277 verified on Etherscan (source visible). RolesAuthority 0x4df6b733 verified (Exact Match). LayerZeroTellerWithRateLimiting 0x9AA79C84 verified. eBTC BoringVault 0x657e8C86 verified. GitHub source is fully public. No unverified production contracts found.
Oracle & external dependencies Green 19 17 of 17
RD-F-049 yellow Oracle role per asset Chainlink feeds serve as rate provider inputs to the Accountant for denominating underlying asset values; the Accountant is the share-price oracle (primary, no fallback). Per-asset rate provider assignments visible in source but not fully enumerated on-chain (JS-blocked read tab). Role map partially derived from source inspection. RD-F-050 yellow Dependency graph (protocols depended upon) External protocol dependencies confirmed from profile: Aave v3, Uniswap v3 NFT Position Manager, Pendle, EtherFi liquidity pool, WETH — all accessed via ManagerWithMerkleVerification (merkle-leaf-gated calldata). LayerZero v2 used for cross-chain shares. Full per-vault merkle leaf scope not retrieved. RD-F-051 yellow Fallback behavior on oracle failure No protocol-level fallback oracle on Chainlink failure. If Accountant rate update fails bounds check or delay check, contract auto-pauses — halting deposits and withdrawals. No secondary oracle source is configured. Pause is the only circuit breaker. RD-F-052 yellow Breakage analysis per dependency Breakage analysis: (a) Chainlink feed stale → Accountant rate update produces stale NAV → auto-pause likely triggers, blocking vault access; (b) Aave v3 exploit → vault assets in Aave lost, vault NAV drops, withdrawal queue may not cover; (c) LayerZero outage → cross-chain bridging halted, source-chain shares unaffected; (d) Pendle/EtherFi exploit → vault position value drops; (e) rate updater key compromise → attacker can push rate within bounds to drain via redemption arbitrage. Medium finding M-4 (rate decimals) identified in sevenSeas-4 audit, no oracle manipulation finding. RD-F-057 yellow Circuit breaker on price deviation The AccountantWithRateProviders implements auto-pause as circuit breaker when new exchange rate exceeds allowedExchangeRateChangeUpper or falls below allowedExchangeRateChangeLower. No protocol-level circuit breaker on individual Chainlink feed staleness. The circuit breaker applies to the share-price oracle, not to underlying Chainlink feeds. RD-F-059 yellow Oracle staleness check present The AccountantWithRateProviders enforces minimumUpdateDelayInSeconds (minimum elapsed time between rate updates) but does NOT check Chainlink updatedAt freshness on underlying feeds. Chainlink staleness detection relies on the off-chain rate updater operator. No on-chain updatedAt > now - X check found in contract source. RD-F-062 yellow External keeper/relayer not redundant The exchange rate updater (caller of updateExchangeRate()) is an authorized single party (requiresAuth). If unavailable, the rate goes stale: minimumUpdateDelayInSeconds fires on the next update attempt, and the contract pauses. This is a keeper-equivalent single point of failure. Rate updater identity (hot wallet vs multisig vs automated) not confirmed on-chain — Cat 2 gap. RD-F-054 n/a TWAP window duration No TWAP oracles used. All oracle feeds are Chainlink aggregator (push oracle). TWAP window duration is not applicable. RD-F-055 n/a Oracle pool depth (USD) No DEX pool oracles used. All price feeds are Chainlink aggregators — pool depth is not applicable. RD-F-058 gray Max-deviation threshold (bps) The allowedExchangeRateChangeUpper and allowedExchangeRateChangeLower are stored in AccountantState struct as uint16 (basis points / 1e4). Specific values not retrieved — Etherscan read tab is JS-rendered and blocked. Curator must call accountantState() on 0x1683870f...fdbf1087 via RPC. RD-F-060 gray Chainlink aggregator min/max bound misconfig Chainlink feed minAnswer/maxAnswer bounds not retrieved per-feed. The Accountant reads IRateProvider.getRate() without explicit minAnswer/maxAnswer guard at the protocol layer. Per-feed bounds set by Chainlink, not Veda. RPC query per feed required. RD-F-181 n/a Permissionless-pool lending oracle Veda BoringVault is not a lending protocol. The Accountant rate is admin-pushed, not derived from permissionless pool creation. No permissionless market listing or isolation-tier config for oracle acceptance. Factor not applicable by protocol type.
RD-F-048 green Oracle providers used Chainlink price feeds used for underlying asset pricing (19 feeds confirmed in data cache: ETH/USD, BTC/USD, USDT/USD, USDC/USD, LINK/USD, UNI/USD, AVAX/USD, COMP/USD across Ethereum and L2s). The share-price oracle is AccountantWithRateProviders — an admin-authorized rate updater with bounded deviation checks. No Pyth, Redstone, or DEX TWAP primary oracles.
RD-F-053 green Oracle source = spot DEX pool (no TWAP) [★ CRITICAL] NOT triggered. Veda uses Chainlink price feeds (19 confirmed) and an admin-pushed AccountantWithRateProviders for share pricing. No primary oracle reads spot price from a DEX pool without TWAP. No spot-DEX oracle path identified in source or data cache.
RD-F-056 green Single-pool oracle (no medianization) Chainlink aggregators are internally medianized across multiple data sources. Veda does not add venue-level medianization on top (uses Chainlink's internal medianization). Not a single-pool oracle concern.
RD-F-061 green LP token balanceOf used for pricing No LP token balanceOf pricing. The Accountant uses IRateProvider.getRate() calls, not LP token balance reads. No donation-manipulation path via direct transfer to LP contract identified.
RD-F-180 green Immutable oracle address [★ CRITICAL-CANDIDATE PD-017] Rate provider addresses in AccountantWithRateProviders are stored in a MUTABLE mapping (mapping(ERC20 => RateProviderData) public rateProviderData). The setRateProviderData(ERC20 asset, bool isPeggedToBase, address rateProvider) external requiresAuth function allows authorized admins to replace any rate provider. Emits RateProviderUpdated event. Rate provider addresses are NOT immutable. Score: green — admin can replace oracle source if needed.
Economic risk Yellow 27 13 of 13
RD-F-064 yellow TVL concentration (top-10 wallet share) Chain breakdown shows Ethereum 55.32%, Ink (ether.fi L2) 22.14%, Optimism 13.61%. No public per-depositor or per-vault TVL breakdown. Ink chain is ether.fi's own L2, suggesting high concentration in the ether.fi vault cluster. ether.fi Liquid vault cited at ~$268M TVL on DefiLlama, likely >25% of total. Full top-10 depositor share cannot be computed without on-chain scan. Yellow due to inferred operator concentration without confirmed depositor-level data. RD-F-065 yellow Liquidity depth per major asset Veda uses a solver-based BoringQueue for withdrawals — no AMM pool or instant liquidity. Withdrawal maturity delay + solver capital determine exit throughput. No public data on maximum daily withdrawal capacity or solver depth. The $5.07B TVL decline from Aug 2025 to May 2026 was absorbed without a documented withdrawal crisis, which is mild evidence that the queue mechanism handled the unwind. However, a rapid coordinated exit could create queue backlog. Yellow due to absence of published solver-depth metrics. RD-F-074 yellow ERC-4626 virtual-share offset (OZ ≥4.9) BoringVault is NOT ERC-4626 — confirmed from GitHub source (enter()/exit() requiresAuth, no ERC-4626 deposit/redeem interface, no totalAssets()). The OZ ≥ 4.9 virtual-share-offset check does not apply directly. Per §6 instruction, assessed on custom-accounting equivalent: share amounts passed to enter() are externally set by MINTER_ROLE (Teller), which computes shares from Accountant exchange rate (depositAmount.mulDivDown(ONE_SHARE, accountant.getRateInQuoteSafe(asset))). The Accountant has allowedExchangeRateChangeUpper/Lower deviation bounds with auto-pause on violation — this provides rate-manipulation protection. However: (a) no virtual-share offset exists, (b) share-price integrity relies on trusted Accountant operator hygiene, (c) the mechanism is architecturally novel and not covered by the ERC-4626 standard guard. Yellow: not_applicable in strict ERC-4626 form, but the custom accounting introduces an equivalent structural question that partially resolves via the Accountant des RD-F-075 yellow First-depositor / share-inflation guard BoringVault's enter() mints shares where shareAmount is passed by MINTER_ROLE (Teller). Teller computes: shares = depositAmount.mulDivDown(ONE_SHARE, accountant.getRateInQuoteSafe(asset)). This means share price is driven by Accountant exchange rate, NOT by totalAssets/totalSupply ratio. Classic first-depositor donation attack (donate assets to vault → inflate share price → next depositor receives far fewer shares) is architecturally blocked because pricing is not derived from vault asset balance. However: (a) startingExchangeRate constructor parameter has no on-chain minimum — a vault deployed with a near-zero initial rate could allow abnormal initial share distribution; (b) no seed deposit is enforced at BoringVault level; (c) Share Lock Period (post-mint lock period) mitigates flash-loan manipulation. The protection is structural but relies on operator setting a reasonable startingExchangeRate. Yellow: first-depositor inflation in its classic form is blocked; residual risk from unco RD-F-066 n/a Utilization rate (lending protocols) Veda is a vault-infrastructure protocol with no lending markets. borrow.present=false confirmed in data cache. No utilization rate exists by design. PD-024 designates this factor not_applicable for non-lending protocols. RD-F-067 n/a Historical bad-debt events No lending or collateralized borrowing. Bad debt socialization cannot occur by design. PD-024 designates this factor not_applicable for non-lending protocols. RD-F-068 n/a Collateralization under stress No CDP or overcollateralized lending; no collateralization ratio metric exists. PD-024 not_applicable for non-lending protocols. RD-F-069 n/a Algorithmic / under-collateralized stablecoin Veda does not issue a stablecoin. It is a vault-infrastructure provider. No algorithmic or under-collateralized stablecoin design present. PD-024 not_applicable. RD-F-070 n/a Empty cToken-style market (zero supply/borrow) Veda is NOT a Compound V2 fork and operates no cToken-style markets. BoringVault is an original vault-infrastructure architecture (Se7en-Seas same-team rebrand; confirmed profile §5). The empty-market donation exploit requires a Compound cToken market structure. PD-024 explicitly designates RD-F-070 as Compound-fork-only N/A. No ★ critical penalty applies. RD-F-071 n/a Seed-deposit requirement for new market listing No lending market listing mechanism. Vault deployments are infrastructure deployments (BoringVault + Accountant + Teller stack), not market listings with seed-deposit requirements. PD-024 not_applicable. RD-F-072 n/a Market-listing governance threshold No on-chain governance market-listing mechanism. Vault deployments require infrastructure provider (Veda Labs) involvement. No permissionless market-listing governance vote exists. PD-024 not_applicable. RD-F-073 n/a Oracle-manipulation-proof borrow cap No lending/borrowing markets exist; no per-asset borrow caps. Oracle-manipulation-proof borrow cap check is not applicable. PD-024 not_applicable.
RD-F-063 green TVL (current + 30d trend) Current TVL $1.074B (DefiLlama API, 2026-05-17). 30-day change -11.63%; 90-day CoV 0.076 (mean $1.156B, std $88.4M). 12-month peak ~$6.145B (2025-08-30). TVL is above the $100M threshold and declining gradually, not in acute crisis. Green because protocol remains well above coverage thresholds and the 90d standard deviation is moderate relative to mean.
Operational history Green 7 15 of 15
RD-F-086 yellow Pause activations (trailing 12 months) One deliberate pause activation observed within trailing 12 months: ether.fi (vault operator) paused Teller contracts for Liquid (ETH, BTC, USD), sETHFI, and eBTC products on approximately April 19, 2026, as a precautionary response to the Kelp DAO LayerZero exploit ($292M). Veda's BoringVault architecture includes a built-in pause mechanism (Accountant pause state blocks deposits, withdrawals, and rate updates). The pause was executed by ether.fi's own RolesAuthority admin — this is a consumer-operator action, not a Veda Labs-operated pause. No Veda Labs-operated vault pauses found. The mechanism worked as designed (no exploit of Veda contracts). Yellow: 1 pause activation in trailing 12 months within a major BoringVault deployment. RD-F-089 yellow Insurance coverage active No active Nexus Mutual, Unslashed, or Sherlock insurance cover found for BoringVault/Veda. Web search 'Nexus Mutual OR Sherlock insurance coverage Veda BoringVault 2025 2026' returned no Veda-specific listing. Immunefi bug bounty (https://immunefi.com/bug-bounty/veda/) exists ($1M max) but is a vulnerability bounty, not insurance cover — distinct products. With ~$1.07B current TVL and no active insurance cover, this is a structural gap. Yellow: insurance cover is not universal at this TVL tier for vault-infra layers, and the Immunefi bounty provides partial economic protection for critical bugs, but the absence of coverage is notable. RD-F-081 n/a Post-exploit response score No prior exploit exists to score a post-exploit response against. Factor is structurally inapplicable. RD-F-082 n/a Post-mortem published within 30 days No prior exploit; no post-mortem to evaluate for timeliness. RD-F-083 n/a Auditor re-engaged after last exploit No prior exploit; no post-exploit re-audit event to evaluate. RD-F-085 n/a Incident response time (minutes) No prior incident to measure response time against. RD-F-087 gray Pause > 7 consecutive days The April 2026 ether.fi Teller pause is the only known pause event. Resumption date not publicly confirmed in available sources — cannot determine whether the pause lasted >7 consecutive days. ether.fi stated it would provide updates; no follow-up announcement found confirming resumption timing.
RD-F-076 green Protocol age (days) Protocol live since approximately March 2024 (~26 months to assessment date). PR Newswire announcement of $18M funding round (June 2025) explicitly states 'Since its March 2024 launch, the BoringVault vault standard has amassed over 100,000 users.' DefiLlama TVL series begins October 2024 and shows continuous operation. Earliest confirmed BoringVault deployment (ether.fi Liquid ETH) per Etherscan ~June 2024. Both data points exceed the 365-day threshold for A-grade eligibility.
RD-F-077 green Prior exploit count Zero Veda/BoringVault contract exploits confirmed across all sources. REKT leaderboard (295 entries) has no entry for Veda, BoringVault, or Se7en Seas. Proprietary hacksdatabase grep (case-insensitive: veda, boring, boringvault, se7en, sevenseas) returned zero file matches across all batches. Data cache sources.rekt.incidents=[] and sources.defillama.hacks=[]. April 2026 ether.fi Teller pause was a consumer-operator precautionary response to the Kelp DAO LayerZero exploit — Veda's own contracts were not exploited or compromised.
RD-F-078 green Chronic-exploit flag (≥3 incidents) Zero prior incidents. Chronic flag (≥3 exploits) does not apply.
RD-F-079 green Same-root-cause repeat exploit Zero incidents on record. Same-root-cause repeat exploit not applicable.
RD-F-080 green Days since last exploit No exploits on record; metric is inapplicable (no countdown). Green by default for zero-incident protocols.
RD-F-084 green TVL stability (CoV over 90d) Trailing 90-day CoV = 0.076 (mean $1.156B, std $88.4M, window 2026-02-17 to 2026-05-17). Low-to-moderate volatility within the measurement window. The broader 12-month TVL decline from ~$6.1B (Aug 2025) to ~$1.07B (May 2026) is an economic/market event driven by crypto market conditions and ether.fi Liquid withdrawals — not an operational failure. The 90-day trailing window used for this factor captures a stable plateau period. CoV 0.076 < 0.15 threshold for green.
RD-F-088 green Re-deployed to new addresses in last year No evidence of a full contract redeployment (retiring existing address set) within the last 12 months. The Se7en-Seas → Veda-Labs org rename is not a contract redeployment. Ongoing multi-chain expansion (new vault deployments on 22+ chains) is incremental new deployments, not replacement of existing contracts. GitHub last commit 2026-05-15 confirms active development without redeployment announcement. No changelog entry indicating address migration found.
RD-F-166 green Deprecated contracts still holding value No deprecated contracts identified. The Se7en-Seas/boring-vault GitHub fork relationship reflects a same-team organizational rename (Se7en Seas → Veda Labs), not a contract deprecation event. Data cache coverage_flags.has_legacy_v1=false. No protocol docs, GitHub issues, or public records indicate a deprecated contract set holding material value. No on-chain evidence of retired contract addresses with >$100K TVL was found.
Real-time signals Green 7 22 of 22
RD-F-106 yellow Cross-chain bridge unverified mint pattern LayerZeroTeller 0xe97365b41b340352d3d32ca2c7230330f19a1e73 is active on Ethereum mainnet enabling cross-chain share transfers. The oracle-deps analyst flagged F179 (LayerZero DVN config) as a documented HIGH-RISK monitoring gap for Veda's cross-chain teller — the exact DVN count, threshold, and operator diversity is unresolved per oracle-deps findings (data cache layerzero.present=false is advisory-only per U6). A misconfigured DVN (e.g., 1/1 analogous to KelpDAO $292M exploit in Apr 2026) would make unverified cross-chain mints possible, making this signal architecturally critical. Scored yellow reflecting the unresolved DVN uncertainty flagged by oracle-deps, not a confirmed exploit-in-progress. RD-F-090 gray Mixer withdrawal → protocol interaction T-09 phase-2 signal requiring Chainalysis/TRM wallet-clustering feed. Deployer wallet 0x0463e60c7ce10e57911ab7bd1667eaa21de3e79b funded by ether.fi Safe multisig (clean, not mixer-funded). Public-proxy web search returned no positive detection of mixer-proximate wallets interacting with Veda's primary contracts. Full attribution requires licensed feed not yet integrated. RD-F-091 gray Partial-drain test transactions Post-v1 signal infrastructure required. No partial-drain test-transaction pattern detected on primary Veda vaults in public on-chain data. No Veda incidents in hack database. This signal is folded into RD-F-098's tier-B precursor rule at v1. RD-F-092 gray Unusual mempool pattern from deployer wallet Post-v1 signal infrastructure (mempool listener) required. Deployer 0x0463e60c7ce10e57911ab7bd1667eaa21de3e79b is actively used for new vault deployments across 22+ chains (expected pattern for vault-infra-as-a-service). No anomalous approval or test sequences detected on public explorer data. RD-F-093 gray Abnormal gas-price willingness from attacker wallet Post-v1 signal infrastructure required. No abnormal gas-price-willing wallets targeting Veda contracts detected on public-observable sources. EVM-applicable factor; no incidents to anchor a baseline. RD-F-094 gray New contract with similar bytecode to exploit template Post-v1 signal infrastructure required. No exploit-template deployments targeting BoringVault selectors publicly reported. Veda's enter()/exit() architecture is non-standard (not ERC-4626), reducing generic attack-template overlap with known exploit databases. RD-F-095 gray Known-exploit function-selector replay Post-v1 signal infrastructure required. No known exploit-replay pattern targeting Veda contracts. No incidents in hack database. BoringVault's merkle-verification architecture is novel with no prior exploit template. RD-F-096 gray New ERC-20 approval to unverified contract from whale Post-v1 signal infrastructure required. No reports of high-TVL Veda depositors granting suspicious approvals to unverified contracts. Institutional-facing integrators (ether.fi, Lombard) reduce retail whale approval risk. RD-F-097 gray Sybil surge of identical-pattern transactions Post-v1 signal infrastructure required. No sybil surge pattern detected in public on-chain data. LayerZeroTeller shows normal deposit patterns with varying sizes and diverse depositors. RD-F-099 gray Oracle price deviation >X% from secondary T-09 phase-2 signal. Secondary source mapping for Veda's 19 Chainlink oracle feeds not yet deployed. Chainlink feeds (ETH/USD, BTC/USD, USDC/USD, USDT/USD; 19 feeds listed in data cache) are functioning with standard heartbeats (1-3600s volatile, 82800-86400s stables). No oracle deviation anomaly publicly reported. Signal infrastructure required before production monitoring. RD-F-100 gray Flash loan >$10M targeting protocol tokens T-09 phase-2 signal. No flash-loan attack against Veda's primary contracts publicly reported. Protocol uses Chainlink aggregator feeds (not DEX spot oracles) which are resistant to single-block manipulation, materially reducing flash-loan oracle attack surface compared to DEX-oracle-dependent protocols. Merkle-root verification constrains what operations the Manager can execute, limiting flash-loan attack vectors. RD-F-101 gray Large governance proposal queued Veda has no on-chain Governor contract (data cache governor_address = null, snapshot_space = null). Per-vault governance is via RolesAuthority admin ACL, not a Governor proposal queue. Signal requires an on-chain Governor with ProposalCreated/ProposalQueued events — structurally inapplicable to Veda's architecture. Admin ACL changes on RolesAuthority are an F102-class (mempool) signal, not an F101-class (governance proposal) signal. RD-F-102 gray Admin/upgrade transaction in mempool T-09 phase-2 signal requiring mempool listener + per-protocol admin-key map. Per-vault RolesAuthority admin keys execute privileged functions (role grants, merkle root updates, Accountant rate updates). No public admin upgrade activity reported on primary vaults. Mempool monitoring infrastructure not yet operational. RD-F-105 gray DNS/CDN/frontend hash drift T-09 phase-2 signal. Hash monitoring for veda.tech frontend not yet deployed. No DNS/frontend compromise publicly reported as of 2026-05-17. veda.tech resolves normally. No change-management feed established for Veda. Institutional-facing nature reduces but does not eliminate the DNS-hijack risk class. RD-F-107 gray Admin EOA signing from new geography/device Post-v1 signal requiring off-chain signing telemetry. Admin keys for per-vault RolesAuthority exist but geographic/device fingerprint monitoring is not feasible via public sources. No geographic anomaly reports for Veda Labs team. RD-F-108 gray GitHub force-push to sensitive branch Post-v1 signal requiring GitHub monitoring infrastructure. Veda-Labs/boring-vault is the canonical repo (last commit 2026-05-15 per data cache). No force-push or sensitive-branch compromise publicly reported. GitHub API monitoring not deployed. RD-F-109 gray Social-media impersonation scam spike Post-v1 signal requiring social-media monitoring infrastructure. No major impersonation scam spike publicly reported on X/Twitter (@veda_labs) or Discord. Institutional-facing nature (ether.fi/Lombard integrators as primary users) reduces retail phishing surface, but $1.07B TVL warrants eventual monitoring. RD-F-110 n/a Unusual pending/executed proposal ratio Veda has no on-chain Governor contract. No proposals exist to generate a pending/executed ratio. Signal structurally inapplicable to per-vault-RolesAuthority governance architecture.
RD-F-098 green TVL anomaly — % drop in <1h TVL $1,074,362,848 as of 2026-05-17T11:41:42Z. 30-day change -11.63% (gradual, market-correlated). 90-day CoV = 0.076 (mean $1.156B, std $88.4M, 90 samples). No single-hour >30% drop detected in the 90-day TVL daily series. The observed decline from $6.1B peak to $1.07B is gradual over ~9 months, not an anomalous drain. Tier-A signal threshold (>30% in 1h vs 30d baseline) is not met. Signal would not fire today.
RD-F-103 green Bridge signer-set change proposed/executed LayerZeroTeller at 0xe97365b41b340352d3d32ca2c7230330f19a1e73 (Ethereum mainnet, verified, ~1 yr 86 days old) is Veda's live bridge surface. No unscheduled signer-set change events observed on this contract as of 2026-05-17. LayerZero's post-KelpDAO security changes (multisig 3/5 → 7/10, OneSig deployment announced) are at the LayerZero infrastructure layer, not Veda's contract layer, and represent a positive mitigant. Signal would not fire today.
RD-F-104 green Stablecoin depeg >2% on shared-LP venue Veda vaults hold stablecoin-denominated assets (USDC, USDT oracle feeds present in data cache). No stablecoin depeg >2% on USDT or USDC as of 2026-05-17. Both trade at par on standard venues. Depeg condition required: >2% on ≥2 venues sustained ≥30min AND protocol exposure ≥5% TVL. Neither threshold is met. Signal would not fire today.
RD-F-182 green Security-Council threshold reduction (RT) RD-F-182 (batch-24): Security-Council threshold reduction event. Veda has no formal Security Council multisig at protocol level. Per-vault RolesAuthority owners function as de facto admin authorities. No threshold reduction event (e.g., from a 3/5 to 2/5 Safe threshold, or timelock removal) detected on Veda's LayerZeroTeller or primary vault admin multisigs as of 2026-05-17. LayerZero's own infrastructure threshold raised (3/5 → 7/10) post-KelpDAO — a positive mitigant, not a threshold reduction. Signal would not fire today.
Dev identity & insider risk Green 3 16 of 16
RD-F-123 yellow Sudden admin-rescue/ACL change without discussion No public governance forum exists for any Veda vault (no Snapshot, no Tally, no forum URL in docs or data cache). Merkle-root updates — which expand or modify the vault's permitted strategy actions, constituting functional ACL changes — are regularly committed to boring-vault main (e.g., 'update sonicLBTCv root', 'sei liquidUSD root', 'remove wrong address') without corresponding public discussion issues or PRs. The boring-vault GitHub issues page shows no open issues. Veda's documentation acknowledges this as the intended per-vault curator model (configurable: unilateral curator, pending-review period, or restricted). No emergency admin-rescue event (sudden owner change, unexpected RolesAuthority transfer) was detected in the 180-day lookback. Yellow (not red) because: (a) the operational model is disclosed, not covert; (b) no emergency admin-rescue event was detected; (c) routine merkle-root updates are the documented operating mode. The structural absence of any public discussion me RD-F-119 gray Commit timezone consistent with stated geography GitHub contributor graphs are JS-rendered and inaccessible via WebFetch. Commit-hour distribution analysis for pseudonymous contributors (imrtlfarm, Zokunei, RadioJulius) is not achievable without GitHub API access or programmatic tooling. Named founders (Raghupathi, Terrigno, Vaughan) are publicly stated to be based in New York, NY, consistent with US Eastern timezone. No anomalous timezone mismatch was detected from available commit metadata, but a rigorous commit-time heatmap analysis was not performed. RD-F-122 gray Contributor paid to DPRK-cluster wallet No on-chain payment streams to contributor wallets identified. Veda Labs is a US-incorporated company with off-chain payroll; personal contributor wallet addresses are unknown. Per process-learnings: 'F122 (contributor payments -> DPRK cluster) cannot be meaningfully assessed at OSINT tier for companies with off-chain payroll. Mark NOT ASSESSED for contributors beyond the deployer unless on-chain payment streams exist.' The deployer address (0x0463e60c) itself shows no DPRK-cluster proximity within available OSINT. RD-F-184 gray Real-capital social-engineering persona F184 definition: a 'team contributor' or 'external integrator' persona has deposited ≥$1M of real capital to the target protocol or peer protocols to build credibility ahead of a social-engineering attack. No such curator-flagged persona has been identified for Veda. The reference pattern (Drift Protocol / UNC4736 6-month conference and in-person build-up with real-capital deposits before durable-nonce pre-signing exploit) has no analogous evidence for Veda. The institutionally backed, doxxed, US-incorporated team structure is inconsistent with a social-engineering build-up scenario. Per process-learnings: 'Mark GRAY + note Drift comparator as reference; don't spend time confirming absence of something that by design leaves no public trace.' Curator confirmation required to convert to green or red.
RD-F-111 green Team doxx status Three co-founders publicly identified with real names: Sunand Raghupathi (CEO), Joseph Terrigno (CTO), Stephanie Vaughan (COO). General Counsel TuongVy Le also doxxed (SEC veteran, Anchorage Digital). All founders have LinkedIn profiles, media appearances, and verifiable prior employment history. Contributor-tier developers (imrtlfarm, Zokunei, RadioJulius) are pseudonymous but this does not affect the founder-tier doxx status for this factor.
RD-F-112 green Team public accountability surface CEO Raghupathi: LinkedIn (Fordham/Columbia), ResearchGate academic profile, podcast appearance on The Index (#513), X @sunandr_, prior roles at Sommelier Finance and Seven Seas Capital. CTO Terrigno: LinkedIn, Crunchbase, prior roles at Novetta and Sommelier Protocol, Columbia/Fordham. COO Vaughan: LinkedIn, Columbia Business School, USMC veteran record, X @GoodStephV. Each founder has 3+ independent verifiable public trails. GC Le: SEC senior role, Anchorage Digital, Bain Capital Crypto. Satisfies ≥2 distinct-domain source requirement per 12.10b.d.
RD-F-113 green Team other-protocol involvement history All three founders previously worked at Sommelier Finance (a DeFi yield protocol) and Seven Seas Capital. No prior rug or exit-scam affiliation found for any team member. Web search for 'Veda Labs Seven Seas rug scam exploit 2023 2024' returned no relevant hits. Sommelier Finance has no exploit record in the hacks database or REKT news. Seven Seas Capital is documented as having avoided losses during the March 2023 USDC depeg and July 2023 Curve exploit. Mike Silagadze (ether.fi CEO) as angel investor creates a client-concentration flag but not a rug-history signal.
RD-F-114 green Deployer address prior on-chain history Deployer 0x0463e60c7ce10e57911ab7bd1667eaa21de3e79b (labeled 'ether.fi: Deployer 4') has 2,139 transactions, is active across 33 chains, holds institutional DeFi token balances (ETHFI, mETH, wstETH, stablecoins), and has a professional deployment history consistent with ether.fi operations. No prior rug-linked contracts found. ENS troglobyte.eth is bound to the address. First tx matches funding event (~April 2024). Normal-dev-history classification.
RD-F-115 green Prior rug/exit-scam affiliation No prior rug or exit-scam affiliation found for any named team member (Raghupathi, Terrigno, Vaughan, Le). Sommelier Finance (prior employer of all three founders) has no exploit or rug record. Seven Seas Capital has no rug record. Contributor imrtlfarm's prior project (Immortal Farm) has no documented rug — it received a solidity.finance audit, indicating legitimate DeFi project intent. No REKT entry or hacksdatabase entry for any team member or affiliated project.
RD-F-116 green Contributor tenure at admin-permissioned PR Primary PR merger imrtlfarm has multi-year DeFi development history (Immortal Farm project with solidity.finance audit; beefy-protocol forks; 25+ repositories). The boring-vault codebase traces back to Se7en-Seas/boring-vault origin (March 2024+), meaning active contributors have been involved from early protocol stages. No new-contributor-with-immediate-admin-access-to-production pattern detected. josephterrigno (CTO) is a public org member with verified professional background.
RD-F-117 green ENS/NameStone identity bound to deployer Deployer 0x0463e60c7ce10e57911ab7bd1667eaa21de3e79b has ENS name 'troglobyte.eth' bound and visible on the Etherscan address page. The ENS is resolvable and associated with an ether.fi DeFi community persona. Factor applies normally for all-EVM protocols per scope instruction: 'All-EVM — F117 (ENS) applies normally.' Pseudonymous ENS binding (not real-name) satisfies the letter of the factor (ENS bound to deployer); full real-name linkage is not the F117 requirement.
RD-F-118 green Handle reuse across failed/rugged projects No evidence of social-handle reuse across failed or rugged projects. The 'Seven Seas Capital' / 'Se7en-Seas' brand predates the Veda Labs rebrand and is a same-team organizational rename, not a fraudulent alias change. No alias-switch pattern found for any named founder. Web OSINT returned no rugged/failed project association for any identified handle (@sunandr_, @GoodStephV, @veda_labs).
RD-F-120 green Video-off/voice-consistency flag CEO Sun Raghupathi appeared on The Index podcast (#513) — a recorded audio/video interview with no video-off or voice-inconsistency flag. COO Stephanie Vaughan has active X account @GoodStephV with public social presence. No 'video-off' pattern, timezone inconsistency in interviews, or voice-identity mismatch has been reported or flagged in public sources for any Veda Labs team member.
RD-F-121 green Contributor OSINT depth score Founders score approximately 4/5 on OSINT depth: LinkedIn with employment history (Sommelier, Seven Seas, prior corporate), educational record (Columbia, Fordham), conference/podcast presence, X accounts, and Crunchbase/RootData profiles. GC Le scores 4/5 (SEC record, Anchorage Digital). Contributor-tier (imrtlfarm, Zokunei, RadioJulius) scores 1/5 — pseudonymous, minimal OSINT. Overall protocol-level OSINT depth score reflects the strong founder tier. Founder depth is sufficient for a green finding here.
RD-F-124 green Deployer wallet mixer-funded within 30 days CRITICAL STAR FACTOR. Deployer 0x0463e60c7ce10e57911ab7bd1667eaa21de3e79b funded via Safe Smart Account (0xA9962a5B8E1F17F7667C3EF0f9D24b72F3DBB95A) with 0.5 ETH circa April 2024 (tx 0x7175fa566caf70b85b869d115982848f737387ad1d8340a9c325b5a6ee06a233). No Tornado Cash, Railgun, or mixer interaction detected in the transaction history or the 30-day pre-deploy window. Funding chain is Safe multisig (institutional ether.fi operational wallet) -> deployer EOA. This is clean institutional provenance. GREEN — no mixer-funded deployer.
RD-F-125 green Deployer linked within 3 hops to DPRK/Lazarus CRITICAL STAR FACTOR. No OFAC SDN match for deployer address, named founders, or any associated entity. No Chainalysis/Arkham public label indicating Lazarus or DPRK cluster proximity within 3 hops of deployer 0x0463e60c. Institutional backing (CoinFund lead, Coinbase Ventures, Anchorage Digital angel Mike Silagadze) provides strong corroborating clean-provenance signal — these VCs perform KYC on founders. Note: DPRK attackers (Lazarus Group) used ether.fi Liquid ETH vault as a drain venue in the Bybit hack (Feb 2025) — but attacker-as-user does NOT constitute team-side DPRK linkage and does NOT flag this factor. No DPRK escalation required. GREEN — no DPRK/Lazarus proximity.
Fork / dependency lineage Yellow 22 10 of 10
RD-F-133 yellow Dependency manifest uses unpinned versions .gitmodules uses floating branch tracking for all 5 submodules: solmate (transmissions11/solmate), openzeppelin-contracts (openzeppelin/openzeppelin-contracts), ccip (smartcontractkit/ccip), OAppAuth (Se7en-Seas/OAppAuth), forge-std (foundry-rs/forge-std). None are pinned to specific commits. In practice, Foundry builds are reproducible from the cloned repo's recorded submodule commit, but the manifest does not enforce pinning. Security-critical libraries (solmate, openzeppelin-contracts) are floating — this is a yellow finding. RD-F-135 yellow Shared-library version with known-vuln status Solmate (transmissions11/solmate) and OpenZeppelin contracts are used but version-pinned to floating branches (see F133). The exact deployed version cannot be confirmed from the manifest alone. No current high/critical CVE or GHSA advisory for solmate's core Auth/ERC20 or OZ contracts was identified. Yellow because floating-pin ambiguity prevents confirming the exact version has no advisory. RD-F-126 n/a Is-a-fork-of Veda-Labs/boring-vault is a same-team organizational rename of Se7en-Seas/boring-vault. The team (Sun Raghupathi, Joe Terrigno, Stephanie Vaughan) rebranded from 'Se7en Seas' to 'Veda Labs'. This is NOT a fork of any third-party DeFi protocol (not Aave, Compound, Yearn, Uniswap, etc.). BoringVault is an original architecture. Cat 8 upstream-protocol-fork factors are not applicable to an original codebase with a same-team organizational rename. RD-F-127 n/a Upstream patch not merged Not applicable. The Se7en-Seas repo is the same team's prior org. There is no external upstream protocol team publishing security patches that Veda could fail to merge. Any security patch is authored by the same team and appears in the Veda-Labs repo. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) Not applicable. No external upstream protocol publishes vulnerability disclosures for Veda to monitor. The Se7en-Seas org is the same team. No third-party upstream advisory path exists. RD-F-129 n/a Code divergence from upstream (%) Not applicable. Code divergence % from 'upstream' is not meaningful when the upstream is the same team's prior org name. Veda-Labs IS the current development org; Se7en-Seas is the historical name. Comparing code to itself under a different org name yields no meaningful signal. RD-F-130 n/a Fork depth (generations from original audit) Not applicable. BoringVault is an original codebase. Fork depth from any external protocol is 0 (no external protocol-fork ancestry). The Se7en-Seas/Veda-Labs split is an organizational rename, not a protocol-fork chain. RD-F-131 n/a Fork retains upstream audit coverage Not applicable. Veda is audited as an original protocol with its own audit history (0xMacro, Spearbit, Certora, Sigma Prime). There is no external upstream whose audit coverage needs to transfer to this fork. RD-F-132 n/a Fork has different economic parameters than upstream Not applicable. No third-party upstream protocol to compare economic parameters against. BoringVault parameters (exchange rate bounds, fee structure, merkle root scope) are Veda's own design without an external audited-default baseline.
RD-F-134 green Dependency had malicious-release incident (last 90d) No known malicious-release incidents in the last 90 days (as of 2026-05-17) affecting solmate, openzeppelin-contracts, ccip, OAppAuth, or forge-std. GitHub Security Advisory feed shows no active malicious-release advisory for these packages in the 90-day window.
Post-deploy hygiene & change mgmt Yellow 24 13 of 13
RD-F-138 red Hot-patch deploys without timelock (last 30 days) TimelockController with minDelay=0 is the live governance pathway for the verified 3-of-5 Safe. Any admin action by the Safe can be executed without enforced delay. Multiple rapid changes in April–May 2026 occurred with no timelock enforcement. Functionally equivalent to hot-patch capability without timelock. RD-F-136 yellow Deployed bytecode matches signed release tag No signed release tags found on Veda-Labs/boring-vault. Active development (last commit 2026-05-15) with no formal release tagging process visible. No changelog. Cannot link deployed bytecode to specific signed commits. RD-F-137 yellow Upgrade frequency (per 90 days) Non-upgradeable contracts replaced via re-permissioning rather than proxy upgrades. Multiple ownership transfers in April–May 2026. New TimelockController deployed May 4 2026. 40+ vault configurations in Mainnet directory. High operational change frequency. RD-F-139 yellow Post-audit code changes without re-audit 13+ audit engagements (11+ 0xMacro incremental A-4 through A-45, Spearbit Arctic, Certora x2, Sigma Prime). High audit frequency is a strong positive. However: audit dates not publicly disclosed; GitHub last commit 2026-05-15 (2 days ago) has no confirmed audit coverage; incremental model may leave integration-level gaps. Yellow not red due to high audit count. RD-F-145 yellow Deployed bytecode reproducibility Full source public on GitHub (Veda-Labs/boring-vault). Foundry-based with foundry.toml: Solidity 0.8.21, optimizer 200 runs. Bytecode reproducibility is theoretically achievable but no formal build artifact or verification workflow documented. No changelog or release notes. RD-F-146 yellow New contract deploys in last 30 days High deployment activity: 9+ transferOwnership calls April 20 2026; TimelockController deployed May 4 2026; 40+ vault configurations in Mainnet directory; GitHub last commit 2026-05-15. Active development and deployment creates ongoing fresh attack surface. RD-F-142 n/a Storage-layout collision risk across upgrades BoringVault is non-upgradeable (constructor-based, no proxy). Peripheral contracts replaced via new deployment, not proxy upgrade. Storage layout collision is not a risk in this architecture. RD-F-168 gray Stale-approval exposure on deprecated router Old Teller 0x5c135e8eC99557b412b9B4492510dCfBD36066F5 listed as 'still active' per ether.fi docs — not formally deprecated. If still active, stale approval concern is moot (not deprecated). Allowance scan pipeline not implemented for this assessment.
RD-F-140 green Fix-merged-but-not-deployed gap No known vulnerability with merged fix but undeployed patch. No public security advisories, no Rekt DB entries, no GHSA records for BoringVault.
RD-F-141 green Test-mode parameters in deploy No test-mode parameters found. BoringVault constructor uses production params. Accountant uses rate bounds enforced at construction. Deployer EOA no longer holds admin role as of May 4 2026.
RD-F-143 green Reinitializable implementation (no _disableInitializers) BoringVault and all peripheral contracts use constructors, not initializers. No proxy pattern, no initialize() function, no OZ Initializable inheritance. _disableInitializers() concern applies only to proxy implementation contracts — not applicable here.
RD-F-144 green CREATE2 factory permits same-address redeploy No CREATE2 factory deployment pattern detected. Contracts deployed via direct EOA transaction by ether.fi: Deployer 4.
RD-F-185 green Bridge rate-limiter / chain-pause as positive mitigant LayerZeroTellerWithRateLimiting (0x9AA79C84b79816ab920bBcE20f8f74557B514734) implements rate limiting on cross-chain share transfers. Share lock period (shareLockPeriod) prevents flash-loan-style deposit+bridge in one tx. Pauser.sol provides emergency pause on Manager. These are positive mitigants limiting extraction speed in an exploit scenario.
Cross-chain & bridge Green 7 12 of 12
RD-F-153 yellow Bridge tracks nonce-consumed mapping Nonce/replay protection is handled by the LayerZero v2 EndpointV2 at 0x1a44076050125825900e736c501f859c50fe728c. The LayerZeroTeller does not implement its own nonce-consumed mapping — delegation to LZ v2 endpoint is the standard pattern. LayerZero v2 endpoint-level nonce protection is widely deployed and audited, but cannot independently verify endpoint nonce logic. RD-F-148 gray Bridge validator count (M) LayerZero v2 is used (F148 maps to DVN count for LZ). DVN configuration not retrieved — LayerZero scan returned HTTP 429; Etherscan code tab does not surface per-pathway DVN config. See F179 for the LZ-specific assessment. F148 defers to F179 per taxonomy note. RD-F-149 gray Bridge validator threshold (k-of-M) DVN threshold (k-of-N) not retrieved. Maps to LZ v2 DVN required threshold. See F179 for primary LZ-specific assessment. RD-F-150 gray Bridge validator co-hosting DVN operator identity and co-hosting cannot be assessed without knowing which DVNs are configured. DVN config not retrieved. RD-F-155 gray Bridge validator-set rotation recency DVN operator identity and rotation history cannot be assessed without knowing which DVNs are configured. DVN config not retrieved. RD-F-156 gray Bridge uses same key custody for >30% validators Cannot assess DVN key custody concentration without knowing which DVNs are configured. RD-F-157 gray Bridge TVL per validator ratio Bridge TVL per validator ratio cannot be computed — DVN count unknown. Vault chain breakdown context available (Ethereum $594M, Optimism $146M, Ink $237M) but DVN count not retrieved. RD-F-179 gray LayerZero OFT DVN config (count, threshold, diversity) HONEST NULL + CURATOR FOLLOW-UP REQUIRED. LayerZeroTeller at 0xe97365b41b340352d3d32ca2c7230330f19a1e73 is confirmed LayerZero v2 OApp (not v1 trustedRemote — F179 applies). DVN configuration (required DVN count, optional DVNs, k-of-N threshold, operator diversity) was not retrieved. LayerZero scan returned HTTP 429. Etherscan source tab does not surface per-pathway DVN config. This is the HIGHEST-RISK unknown in Cat 10 — a 1/1 DVN threshold (Kelp DAO class, April 2026 $292M exploit) would be catastrophic. Curator must: (1) query LZ endpoint for DVN config per pathway; (2) assess whether default config is used (LayerZero default DVN set). Flag RED if 1/1 required DVN; YELLOW if 2+ DVNs with same operator; GREEN if ≥2 independent DVNs.
RD-F-147 green Protocol has bridge surface YES — Veda operates LayerZeroTeller (0xe97365b41b340352d3d32ca2c7230330f19a1e73) on Ethereum mainnet. Verified contract, Solidity 0.8.21, LayerZero v2 OApp pattern (ILayerZeroEndpointV2 interface). Profile has_bridge_surface=true. Cross-chain share bridging is a live feature.
RD-F-151 green Bridge ecrecover checks result ≠ address(0) [★ CRITICAL] NOT triggered. LayerZeroTeller uses LayerZero v2 DVN-based attestation via EndpointV2. No ecrecover call in this teller. The OApp inherits OAppReceiver.lzReceive() which validates origin.sender via _getPeerOrRevert() before calling _lzReceive. The Wormhole-class vulnerability (unchecked ecrecover return → address(0)) is not present in this architecture.
RD-F-152 green Bridge binds message to srcChainId LayerZero v2 OApp passes Origin struct containing srcEid (source endpoint ID) to lzReceive(). The _lzReceive override checks idToChains[_origin.srcEid].allowMessagesFrom and reverts if false. Source chain binding is enforced by both the OApp contract and the underlying LZ v2 endpoint.
RD-F-154 green Default bytes32(0) acceptable as valid root [★ CRITICAL] NOT triggered. LayerZero v2 OApp does not use a Merkle root acceptance model. The analogous zero-default risk (bytes32(0) as valid peer) is explicitly guarded: OAppCore._getPeerOrRevert() reverts when peer == bytes32(0). The Nomad-class vulnerability ($190M, default root accepted) is not present in this architecture.
Threat intelligence & recon Green 0 8 of 8
RD-F-158 gray Known-threat-actor cluster has touched protocol T-09 phase-2 advisory signal. No known-threat-actor wallet interactions found via public-observable sources. Web search 'Veda Labs BoringVault DPRK Lazarus threat actor 2025 2026' returned no Veda-specific results. Public Etherscan tags and Arkham/Nansen public labels do not show any flagged wallets interacting with Veda's primary contracts. Full attribution requires Chainalysis/TRM licensed cluster feed (not integrated). Note: Veda's $1.07B TVL makes it a plausible DPRK reconnaissance target (DPRK class has targeted large yield protocols), but no positive detection as of assessment date. RD-F-159 gray Attacker wallet pre-strike probe (low-gas failing txs) Requires real-time mempool monitoring + threat-actor cluster feed. No mempool probe activity (low-gas failing transactions) from known attacker wallets detected on Veda's primary contracts via public-observable sources. No mempool monitoring infrastructure deployed. RD-F-161 gray Protocol-impersonator domain registered (typosquat) F161 assessed first per scope instructions. Veda is institutional-facing (lower retail-typosquat profile than consumer protocols) but $1.07B TVL makes impersonation economically attractive. Official domain: veda.tech. Web search for 'Veda BoringVault veda.tech typosquat domain impersonation phishing 2024 2025 2026' returned no positive impersonator domain hits. WHOIS lookup for veda.tech was blocked by CAPTCHA on DomainTools and ICANN lookup tools, preventing automated registration-date and typosquat check. Domain registration date not deterministically retrieved; profile establishes ~March 2024 launch (~26 months before assessment). No impersonator domain positively identified — gap is tool infrastructure, not a confirmed typosquat. Curator action required: run domain monitoring sweep (CertStream CT log, DomainTools Iris, SecurityTrails) for veda.tech variants before v1 publication. RD-F-162 gray Known-exploit-template selector deployed by any address Post-v1 signal infrastructure required (exploit-template scanner). No exploit-template contracts targeting BoringVault selector patterns publicly reported. No Veda incidents in hack DB. The novel merkle-verification architecture means no standard exploit template exists for BoringVault class. RD-F-163 gray Avg attacker reconnaissance time for peer-class protocols No Veda-specific exploit incidents exist to compute a protocol-specific reconnaissance time. For yield-vault peer class: USPD baseline is 78 days; Drift Protocol (Apr 2026, $285M, DPRK) involved ~6 months of social engineering prior to exploit. Veda's per-vault-multisig and merkle-verification architecture creates a complex attack surface requiring extended reconnaissance. Curator estimate: 45–90 day reconnaissance window for a sophisticated actor targeting Veda's highest-TVL vault operator. This is a backward-looking analytical factor, not a real-time trigger. RD-F-164 gray Leaked credential on paste/sentry site Requires paste/cred-dump monitoring feed (not integrated). No publicly known credential leaks for Veda Labs or ether.fi vault automation infrastructure detected via web search as of 2026-05-17. Continuous monitoring requires dedicated feed subscription. RD-F-165 gray Protocol social channel has scam-coordinator flag Requires curator social watchlist infrastructure (not deployed). No Discord/Telegram scam-coordinator flags for Veda-adjacent channels found via web search. Veda has community channels; ether.fi/Lombard integrators have large communities that may be impersonation targets. Continuous monitoring requires dedicated social-watchlist subscription.
RD-F-160 green GitHub malicious-dependency incident touching protocol deps No GitHub security advisory flags a malicious release in Veda's dependencies (Solmate, Foundry toolchain, Chainlink interfaces) in the trailing 90 days as of 2026-05-17. Veda uses Foundry-based architecture (foundry.toml present; Solidity 0.8.21). Data cache changelog_present = false (no CHANGELOG tracking dependency updates, a minor hygiene gap). No public supply-chain advisory affecting boring-vault dependencies found.
Tooling / compiler / AI Green 0 5 of 5
RD-F-170 green Solc version used (known-bug versions flagged) Solidity 0.8.21 (v0.8.21+commit.d9974bed) used across all deployed contracts — confirmed from foundry.toml (auto_detect_solc = false, explicit pin) and Etherscan verification of liquidETH BoringVault and LayerZeroTeller. 0.8.21 is not on the known-bug list for high/critical bugs affecting ERC-20, Auth, or vault patterns. evm_version = cancun (supports EIP-1153 transient storage but contracts don't appear to use TSTORE/TLOAD). Stable production release.
RD-F-171 green Bytecode similarity to audited upstream with behavior deviation BoringVault is an original architecture with no externally-audited upstream to compare against. There is no bytecode-similarity-to-upstream pattern applicable. The codebase shows consistent authorship and architectural coherence (Solmate Auth, custom enter/exit pattern, merkle-gated manage path). No AI-copy pattern or behavioral deviation from an audited upstream is evident.
RD-F-172 green Repo shows AI-tool co-authorship in critical files GitHub commit history for the boring-vault repo does not show 'Co-authored-by: GitHub Copilot' or similar AI co-authorship trailers in the core contract commits reviewed (BoringVault.sol, AccountantWithRateProviders.sol, ManagerWithMerkleVerification.sol). Commit history is consistent with professional human-authored Solidity development. No AI co-authorship metadata detected.
RD-F-173 green Team self-disclosure of AI-generated Solidity No public disclosure by Veda Labs or Se7en Seas of AI-generated Solidity in production contracts found. Docs.veda.tech security page does not mention AI code generation. No GitHub PR or commit message announces AI-generated Solidity for core contracts. Team blog and X/Twitter (@veda_labs) show no relevant AI-code disclosure.
RD-F-174 green Dependency tree uses EOL Solidity version All core deployed contracts use Solidity 0.8.21, confirmed from foundry.toml and Etherscan verification. 0.8.21 is not EOL — it is a supported stable release. forge-std (test only, not deployed) and Solmate use compatible versions. No EOL Solidity version in production stack.
Response & disclosure hygiene Green 8 4 of 4
RD-F-176 yellow Disclosure SLA public Immunefi program applies 'Category 2: Notice Required' for responsible publication — this governs researcher public disclosure timing, not the team's acknowledgment-time SLA. No explicit acknowledgment-time SLA (e.g., '72h acknowledge') is published in the Immunefi program page, Veda docs (docs.veda.tech), or veda.tech. No SECURITY.md in the repo (data cache security_md_present=false). The absence of a stated response SLA means researchers have no formal guarantee of timely acknowledgment. Yellow: disclosure channel exists but no acknowledgment SLA is published.
RD-F-175 green Disclosure channel exists Active Immunefi bug bounty program exists and is reachable at https://immunefi.com/bug-bounty/veda/. Launched 2026-01-21. Critical: $100K–$1M max. High: $10K–$25K. 52 assets in scope. Submissions via https://bugs.immunefi.com/dashboard/new-submission. This constitutes a clear, public security-disclosure channel on a well-regarded platform.
RD-F-177 green Prior known-ignored disclosure No evidence of a disclosed vulnerability that was reported to the team and subsequently ignored before an exploit. Zero incidents in the record means no post-mortem could document this pattern. Green by absence of counter-evidence, consistent with clean incident record.
RD-F-178 green CVE/GHSA advisory issued against protocol No CVE, GHSA, or equivalent public advisory found for Veda-Labs/boring-vault or Se7en-Seas/boring-vault. Web search 'veda-labs boring-vault CVE GHSA GitHub advisory security vulnerability 2024 2025' returned no relevant advisories (results were for HashiCorp Vault CVEs and generic advisory DB pages — not Veda). GitHub advisory database search returned no Veda-Labs entries. Green.
rubric_version v1.7.0 graded_at 2026-05-17 12:41:23 factors 184 protocol veda