DeFiPunk'd

Veda

Onchain Capital Allocator

TVL $1.1B
Type Onchain Capital Allocator
Chains Ethereum, Ink, Optimism, Hyperliquid L1, Plasma +7
View on DeFiLlama ↗
Control — orange Ability to exit — tentative orange Autonomy — tentative orange Open Access — tentative orange Verifiability — green Control Exit Autonomy Open Access Verifiable
Control criteria
Upgradeability Immutable Bug bounty immunefi.com Governance forum — Docs docs.veda.tech
About

Veda provides BoringVault-based onchain vault infrastructure. Users deposit supported assets through a Teller and receive vault shares representing a claim on assets custodied in the BoringVault or deployed into DeFi positions. Curators and strategists allocate capital through Manager Merkle roots and DecoderAndSanitizer constraints, while the Accountant publishes exchange rates with onchain rate-limit and bounds checks. Exits use instant-withdrawal variants when available or a solver-based withdrawal queue.

Risk analysis

One card per dimension, sorted by severity. Only Verifiability and Autonomy carry automated signals in Phase 0. See methodology for scope.

Audit a dimension yourself · DEFI@home Contribute an LLM-run assessment — any model, any dimension. Three agreeing runs merge automatically into the public record.

DEFI@home is a distributed audit network modeled on SETI@home: instead of CPU cycles, it crowdsources LLM reasoning. Paste a slice prompt into Claude, ChatGPT, Gemini, or any browsing-capable model, and submit the JSON output as a pull request. The quorum bot merges it once ≥3 independent runs (from different models) reach the same grade — no single model, and no single contributor, can move the needle alone. How it works →

  • Address discovery 4 addresses on file · 1 run Submit run ↗
  • Verifiability ✓ 4/4 models agree AI-only 3/4 with chat share link Submit run ↗
  • Control ✓ 3/3 models agree AI-only 3/3 with chat share link Submit run ↗
  • Ability to exit ✓ 3/3 models agree AI-only weak orange — weak consensus margin Submit run ↗
  • Autonomy ✓ 3/3 models agree AI-only weak orange — weak consensus margin Submit run ↗
  • Open Access ✓ 3/3 models agree AI-only weak orange — weak consensus margin Submit run ↗
  • Audit all 5 dimensions · one prompt Submit run ↗
  1. Verifiability green 4/4 models agree AI-only 3/4 with chat share link
    BoringVault / Teller / Accountant verified on Etherscan, source corresponds to public Veda-Labs/boring-vault repo, ≥4 audits from recognized firms (Spearbit, Certora, Sigma Prime, 0xMacro)
    Verdict

    Choosing green because the on-chain verification posture meets every named green requirement: every assessed contract reports etherscan-verified ABI, no proxy/implementation gap exists for the fund-holding contracts, a public source repo corresponds to the deployed contract names, and the in-repo audit folder contains independent reports from at least three rubric-recognized firms (Spearbit, Certora, Sigma Prime). The orange steel-man would require a specific stale-audit claim with named files; the red steel-man would require a verification or repo gap — neither is supported by the evidence. Per V5's evidence-discipline rule, the absence of a pinned commit SHA and per-audit dates is recorded in unknowns rather than auto-downgrading.

    Steelman argument
    Steelman argument All assessed contracts are verified, the source maps to a public Veda-Labs/boring-vault repo whose file tree corresponds to the deployed contract names, and ≥3 recognized firms (Spearbit, Certora, Sigma Prime) plus 0xMacro have produced audit reports in the in-repo audit folder — meeting the rubric's green anchor 'verified bytecode, public source repo whose contents correspond to the explorer-visible source, AND ≥1 audit from a recognized firm.'
    Evidence (6)
    V1
    BoringVault (0x917cee...), Teller (0x99dE9e...), Accountant (0xbe16605B...), and RolesAuthority (0x402DFF...) all return `abiSource: etherscan` via the defipunkd API, indicating verified bytecode on Etherscan. None are EIP-1967/transparent/UUPS proxies — defipunkd does not return a `proxy.implementation` for any of them, and Etherscan's listing for the BoringVault directly displays the source. The Safe at 0xCEA80... is a standard GnosisSafeProxy v1.3.0 whose implementation is independently published (Safe canonical implementation 0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552).
    V2
    A canonical public source repo exists at https://github.com/Veda-Labs/boring-vault (a fork from the original Se7en-Seas/boring-vault by the same founding team). The repo's `src/` tree contains BoringVault.sol, TellerWithMultiAssetSupport.sol, AccountantWithRateProviders.sol, and ManagerWithMerkleVerification.sol — matching the contract names returned by Etherscan for the deployed addresses. I did not pin a commit SHA in this run.
    V3
    Audit artifacts present in https://github.com/Veda-Labs/boring-vault/tree/main/audit: spearbit-boring-vault-arctic-0.pdf, 0xmacro-boring-vault-2.pdf, 0xmacro-boring-vault-arctic-0.pdf, 0xmacro-boring-vault-arctic-1.pdf, certora-boring-vault-0.pdf, certora-boring-vault-1.pdf, sigma-prime-boring-vault-0.pdf. The protocol's external pages additionally mention Hexens and Secure3 as commissioned firms (docs.veda.tech/audits).
    V4
    Recognized firms covered in the in-repo audit folder: Spearbit, Certora (formal verification), Sigma Prime — all three appear in the prompt's recognized-firm list. 0xMacro is not on the prompt's named list but is a reputable firm and provides three audit reports here. Multiple recognized firms covering the core architecture clears the V4 bar.
    V5
    I did not run a commit-level diff between the most recent in-scope audit commit and the currently deployed source in this run — so post-audit drift is not directly characterized. The BoringVault is a small contract (~100 lines per Veda's own description and the lucidly.finance comparison), and the architecture is intentionally minimal, lowering the surface area on which drift could be material. Default to V5-not-fired absent a specific named behavior change.
    V6
    Implementation vs proxy: BoringVault, Teller, Accountant, and RolesAuthority are direct (non-proxy) deployments, so the V6 question 'is the implementation also verified?' is degenerate — there is no separate implementation contract. The Safe at 0xCEA80... is a thin GnosisSafeProxy whose implementation 0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552 is the well-known canonical Safe v1.3.0 implementation (per V1's exemption for standard proxy patterns).
    Sources claude-opus-4-7 url ↗ gpt-5.5-thinking url ↗ claude-sonnet-4-6 (autorun) no url grok-4 url ↗ View raw submissions ↗
  2. Control orange 3/3 models agree AI-only 3/3 with chat share link
    T1 (drain via arbitrary manage()) reachable with no timelock by a 4-of-6 Safe; fails Security Council criteria
    Verdict

    Choosing orange because the green steel-man is defeated by a concrete bypass: BoringVault.manage(address,bytes,uint256) is a documented arbitrary-call function whose caller-eligibility lives in the RolesAuthority, and the Authority's owner — the 4-of-6 Safe — can set any address as a manage()-eligible role-holder in a single Safe transaction with no on-chain delay. That is T1 power on the fast path. It is not red because the actor is a 4-of-6 (threshold 4, six owners), which is stronger than the rubric's red anchors of 'single EOA or 2-of-3 multisig with no time cap,' but it fails the Security Council standard (≥7 signers, ≥51% threshold, ≥50% non-insider, publicly announced) at the size/membership level and is reachable with no timelock — squarely the rubric's orange anchor 'a multisig failing one or more Security Council criteria sits on a T1/T2 path.'

    Steelman argument
    Steelman argument The fund-holding contracts are not upgradeable; control is held by a 4-of-6 (66% threshold) Safe v1.3.0, not a single EOA or 2-of-3 — a stronger actor than the red tier's worst case — and the Merkle-verified Manager constrains the day-to-day strategist, even though the Authority owner can bypass it; the system fails Security-Council criteria but is far from the worst rugging shape.
    Evidence (7)
    C1
    BoringVault (0x917cee...) is a Solmate Auth contract with owner()=0x0; access is delegated to authority()=0x402DFF43b4f24b006BBD6520a11C169f81085039, a RolesAuthority whose owner()=0xCEA8039076E35a825854c5C2f85659430b06ec96. The Teller (0x99dE9e...) and Accountant (0xbe16605B...) point to the same Authority.
    C2
    BoringVault, Teller, and Accountant are non-proxy contracts (confirmed: no `proxy.implementation` returned by defipunkd ABI lookup; Etherscan listing shows compiler 0.8.21 with the BoringVault source directly verified at the address). They cannot be code-upgraded; however, the Authority can grant any role on the BoringVault and the Solmate Auth `setAuthority` write method on each module allows swapping the Authority itself.
    C3
    Execution path: 4 of 6 Safe signers co-sign Safe.execTransaction → RolesAuthority.setUserRole / setRoleCapability → privileged caller can invoke BoringVault.manage(address,bytes,uint256). No timelock contract sits between the Safe and the Authority (the Authority's owner() returns the Safe address directly; the Safe has nonce=321 and no enabled modules).
    C4
    Single Safe 0xCEA8039076E35a825854c5C2f85659430b06ec96, version 1.3.0, threshold=4, 6 owners: 0x95A2115018b84cfe0630C16CCA277E1569a84BEf, 0x4A4e996Dd8F36Dcf46b30A7F97877da922323EEb, 0x3DE2da610996eA5A72B9Af7cB8740caC48A9329f, 0x83954FBd07f8A868F4A72103e7bBCc8Ec59CeA1C, 0x544bDcBb88F2756000De227580aaad7376f3794E, 0x9eaC7114D1a1EaBc4732A886795cFD9E6E35843f. Powers held: full Authority ownership (role assignment, public-capability toggles), which transitively gives manage()-capability assignment on the BoringVault. Signer identity classification (insider vs non-insider) could not be verified from on-chain data alone.
    C5
    No on-chain governance (Governor / GovernorBravo / OZ Governor / Aragon) is present in the address book or reachable from the Authority. There is no token-weighted voting in this slice; the Safe is the sole policy actor.
    C6
    No separate emergency-pause guardian distinct from the Authority owner: Teller.pause() and Accountant.pause() are both `requiresAuth` and reachable by the same 4-of-6 Safe. No time-capped emergency role is configured separately on these modules.
    C7
    Highest reachable tier on the fast path = T1 (FUND-CRITICAL). The Safe can call RolesAuthority.setUserRole / setRoleCapability to grant any chosen address the role wired to BoringVault.manage(address,bytes,uint256). BoringVault.manage performs an arbitrary `target.call{value: value}(data)` from the vault — the ManagerWithMerkleVerification Merkle-proof check lives on a separate Manager contract and is only enforced when the Manager is the caller; the Authority owner can route manage() permission to any address, bypassing the Merkle restriction. Binding function: `BoringVault.manage(address target, bytes data, uint256 value)` (selector visible in the ABI as `manage(address,bytes,uint256)`).
    Sources claude-opus-4-7 url ↗ gpt-5.5-thinking url ↗ grok-4 url ↗ View raw submissions ↗
  3. Ability to exit tentative 3/3 models agree AI-only 3/3 with chat share link
    Exit via 7-day AtomicQueue; Teller.pause()/Accountant.pause() can halt deposits AND withdrawals indefinitely, gated by 4-of-6 Safe (no time cap)
    Verdict

    Choosing orange because the red steel-man relies on reading 'ANY actor can pause CLAIMS of finalized exits indefinitely' literally, but Teller.pause is a broad-scope halt of deposits, withdraw-request settlement, AND new placements rather than a targeted claims-only freeze, and the actor is meaningfully stronger than the explicit red anchor of 'single EOA / 2-of-3 multisig'. The green steel-man fails because there is no time cap on pause, no escape-hatch in the Teller, and the same Safe holds both pause and the T1 path identified in the control slice, so the user has no notice window against an adversarial admin. Per the rubric's orange anchor 'pausable with broad scope' applied to a non-Security-Council multisig holding the pause key, this maps to orange.

    Steelman argument
    Steelman argument Pause is broad-scope (it halts deposits AND withdrawals AND new request placement against the Teller) rather than a targeted claims-only pause, the actor is a 4-of-6 Safe and not a single EOA or 2-of-3, the documented queue maximum is exactly the 7-day rubric anchor (not over it), and the user's vault shares remain ERC-20-transferable so a secondary-market exit remains available; this is the 'pausable with broad scope by an unprivileged-EOA-free actor' shape.
    Evidence (7)
    E1
    User-facing exit functions: (a) Teller.bulkWithdraw(asset, shares, minAssets, to) — actually called by a permissioned solver; (b) the canonical user path is to submit an AtomicRequest to an AtomicQueue contract, where a solver fulfils it by calling bulkWithdraw on the user's behalf; (c) weETHs shares are themselves ERC-20-transferable (subject to deny-list hook), so a secondary-market sale is a fallback exit.
    E2
    Teller.bulkWithdraw and Teller.deposit/depositWithPermit/bulkDeposit are all `requiresAuth` (Solmate). In the deployed config the deposit selectors are set as public capabilities on the Authority, so users can call them directly; the solver role is also Authority-assigned. AtomicRequest placement is permissionless. Every settlement call reverts on `if (isPaused) revert TellerWithMultiAssetSupport__Paused()`.
    E3
    Pause guard on the Teller: `pause()` is `requiresAuth`, callable by any address the Authority allows; Authority owner = 4-of-6 Safe. No maxPauseDuration / auto-expiry exists in the ABI. The Accountant has the same pause shape and its rate-bound check auto-pauses the contract when exchange-rate movement exceeds the ±0.5% bounds (i.e., self-pauses on bad reports). Current state: Teller.isPaused()=false and Accountant.accountantState.isPaused=false at the read block.
    E4
    There is no distinct emergency-vs-governance pause path: the same Authority gates pause/unpause on the Teller and the Accountant, and the same 4-of-6 Safe is the Authority owner. There is no time-capped emergency-multisig with a different actor class.
    E5
    Documented withdrawal-queue maximum: 7 days (per ether.fi weETHs docs, 'No, it is a 7-day withdrawal period. While most withdrawals will complete well before this maximum window, this is an additional safety mechanism added by Veda'). I was not able to confirm a per-day withdrawal cap or queue-level pause on the AtomicQueue contract address itself in this run.
    E6
    No forced-exit / escape-hatch / permissionless emergency exit exists in the BoringVault or Teller ABIs. The closest fallback is the user transferring or selling their weETHs ERC-20 shares on a secondary market (subject to the BeforeTransferHook deny-list).
    E7
    Exit and request-placement functions are directly callable via a generic wallet / Etherscan write tab (the Teller's deposit/withdraw functions and the AtomicQueue's updateAtomicRequest are public-callable contract functions); no project frontend is structurally required for placement.
    Why is this consensus tentative?
    • weak consensus margin

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ gpt-5.5-thinking url ↗ grok-4 url ↗ View raw submissions ↗
  4. Autonomy tentative 3/3 models agree AI-only 3/3 with chat share link
    Opt-in nested restaking dependencies (Symbiotic/Cap/FalconX) plus a governance-mutable Merkle root and rate-provider surface (A9) without timelock; impacted TVS bounded but material on the delegated portion
    Verdict

    Choosing orange because (i) per the rubric carve-out 'Underlying-asset risk in opt-in, isolated markets is NOT autonomy-red on its own', the Symbiotic/Cap/FalconX nested chain is product-level risk the user explicitly opted into per ether.fi's disclosure and does not by itself force red; (ii) the live Accountant rate bounds plus Merkle-restricted manage are real mitigations that satisfy the orange tier's 'documented fallback that bounds impacted TVS'; (iii) but A9 fires concretely — the Safe can call setRateProviderData and update the Merkle root in one tx with no timelock, which is the rubric's orange anchor 'governance-mutable dependencies protected by a ≥7-day timelock' specifically NOT met. TVS weighting: this is one vault (weETHs, ~22,687 shares ≈ ~$90M order-of-magnitude) of many Veda deployments; for THIS vault, impacted TVS under a worst-case unmitigated external-dependency failure is ~25–60% of vault TVS (the portion sitting in the Cap/M11/FalconX delegation), bounded by the strategist's current allocation. The architecture pattern repeats across other Veda vaults with different external dependencies, so the platform-level grade should be read as 'architecture-level orange; specific TVS impact varies per-vault.'

    Steelman argument
    Steelman argument The dependency chain is opt-in (disclosed in the vault's product page before deposit), the Accountant's ±0.5%/6h rate-bound + auto-pause is a live, on-chain circuit-breaker that prevents oracle manipulation from washing out unclaimed yield, and the Merkle verification system blocks the strategist from interacting with unapproved protocols at execution time — but governance can still re-shape the dependency surface without a timelock or exit window.
    Evidence (9)
    A1
    External calls the BoringVault makes are gated by the ManagerWithMerkleVerification — each leaf encodes (DecoderAndSanitizer, target, valueIsNonZero, selector, packedAddressArgs), and the strategist must submit a Merkle proof for every action. For the weETHs vault, the documented targets include Symbiotic vaults and (per ether.fi's risk disclosure) downstream Cap Protocol / Pareto contracts with M11 Credit as intermediary borrower and FalconX as ultimate counterparty. The Accountant reads pricing via `rateProviderData(asset)` — pinned configs route assets either as 'pegged to base (WETH)' or via an IRateProvider contract.
    A2
    Off-chain actors reporting on-chain: (i) the Accountant's `updateExchangeRate(uint96)` is called by an off-chain strategist account, with on-chain bounds of ±0.5% per update and a 6h minimum delay (allowedExchangeRateChangeUpper=10050, allowedExchangeRateChangeLower=9950, minimumUpdateDelayInSeconds=21600); (ii) the AtomicQueue solver (permissioned via the Authority) is required to settle user withdraw requests by calling bulkWithdraw on the Teller. Both roles are off-chain operational keys gated by the same 4-of-6 Safe / RolesAuthority via role assignment.
    A3
    No bridge dependency is in scope for the weETHs Ethereum mainnet deployment — it is single-chain. Veda as a platform deploys to many chains (Ink, Optimism, Plasma, Hyperliquid L1, Base, Arbitrum, Berachain, Sonic, BSC, BOB, Scroll), but the weETHs vault itself does not require a non-canonical bridge for its own operation per the read data.
    A4
    Nested-collateral chain (opt-in, disclosed): weETHs deposits → Symbiotic restaking networks (slashable) → Cap Protocol / Pareto vault → M11 Credit (intermediary borrower) → FalconX (ultimate counterparty). Per ether.fi's risk disclosure, slashing, M11 default, FalconX mishandling, or Cap Protocol smart-contract failure each could impair principal. This is per-vault, isolated risk that users explicitly opted into when depositing to this product.
    A5
    Fork lineage (silent check): the Veda-Labs/boring-vault repo is a fork of Se7en-Seas/boring-vault, the original BoringVault implementation by the same founding team — not a stale fork of an unrelated project.
    A6
    Live, on-chain fallback mechanisms: (i) Accountant rate-bound + 6h-delay check is LIVE (constants are non-zero on the live contract and the `AccountantWithRateProviders__Paused` error exists) and auto-pauses on violation; (ii) Teller shareLockPeriod is currently 0 for this vault — LIVE but configured to zero, so the documented MEV protection is not enforcing today; (iii) Merkle-restricted manage on the Manager is LIVE for strategist-originated calls but does not bind an Authority-granted alternative caller (see control slice); (iv) deny-list hook on share transfers is LIVE.
    A7
    Out of scope — the weETHs vault deploys on Ethereum L1, so consensus and sequencing are substrate, not a protocol-level A7 dependency.
    A8
    Keeper / solver / oracle-poster liveness: (i) if the strategist stops calling updateExchangeRate, the published rate goes stale but the Accountant's `getRateSafe()` will continue returning the last-published rate (no on-chain forced-pause for stale data was visible in the ABI's view methods), degrading rate quality; (ii) if the AtomicQueue solver stops settling requests, queued users wait beyond the 7-day target — withdrawals stall but the user's claim isn't destroyed. Neither failure causes immediate principal loss.
    A9
    Governance-mutable external dependency surface: the Safe / Authority owner can (i) call Accountant.setRateProviderData(asset, isPegged, rateProvider) to swap the IRateProvider address for any supported asset, with no on-chain timelock or exit window; (ii) update the Manager's Merkle root to add new target contracts the BoringVault may call; (iii) addAsset / removeAsset on the Teller to register new external assets and their accounting paths. All three are `requiresAuth` and reachable in a single Safe transaction.
    Why is this consensus tentative?
    • weak consensus margin

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ gpt-5.5-thinking url ↗ grok-4 url ↗ View raw submissions ↗
  5. Open Access tentative 3/3 models agree AI-only 3/3 with chat share link
    Deposit is currently public-callable and multiple independent frontends exist, but the Teller exposes Auth-gated deny-list write methods (allow/deny From/To/Operator) updatable by a 4-of-6 Safe — configurable compliance
    Verdict

    Choosing orange because the green steel-man is undermined by a concrete on-chain capability the 4-of-6 Safe can exercise without delay: denyFrom / denyTo / denyOperator on the Teller will cause the BeforeTransferHook to revert share transfers for the targeted address, which is the exact mechanism by which a settled AtomicQueue withdrawal would route shares from the user to the solver. Per the rubric's guideline on committees, a small set (6 signers) with informal/unpublished replacement procedure should be 'treated as a single-party operator' — pushing the literal red anchor 'enforces an on-chain blocklist updatable by a single party' into range. The reason it lands orange not red is that the deny-list is opt-out (default-off) rather than a whitelist-required-for-entry, and multiple independent A3b paths (Kraken, ether.fi, Binance Web3, Bybit Web3, direct Etherscan) are documented to route to the same on-chain contract.

    Steelman argument
    Steelman argument The configurable-compliance feature exists by design (Veda markets 'Configure address whitelists, deposit permissions, curator roles'), but at the contract level it is opt-out (no address is denied by default), deposit is currently a public capability, and multiple operationally independent frontends route to the same contract, so the protocol is practically reachable without the publisher's cooperation — the orange anchor of 'configurable but not currently restrictive admission' fits.
    Evidence (8)
    A1
    No on-chain whitelist on user entry: the Teller has no isAccredited / isKYCed / allowlist gate on deposit(); deposit() is `requiresAuth` (Solmate) but the deployed Authority sets the deposit selector as a public capability (verified inferentially: depositNonce()=42277 and Etherscan shows 63,809 transactions and ~17,891 holders on the BoringVault — incompatible with a permissioned-only deposit). The BoringVault holds no whitelist either; share transfers are gated only by the BeforeTransferHook deny-list view.
    A2
    Off-chain operators in the admission path: (i) DEPOSIT placement is unconditional given a supported asset and unpaused state; (ii) WITHDRAWAL REQUEST placement on the AtomicQueue is unconditional; (iii) downstream SETTLEMENT of withdrawals depends on a permissioned solver calling bulkWithdraw on the Teller — admission-permissionless, but liveness-dependent (the liveness concern is recorded in the dependencies slice, not here).
    A3-passive
    Veda Tech Labs publishes terms of service at https://veda.tech/terms — I was unable to extract verbatim clause text in this run, so I record only the existence of the ToS document, not its content, as evidence.
    A3-active
    I did not observe any runtime IP geo-block or wallet-screening banner on https://veda.tech in the fetch I performed; the home page rendered without geographical interception. This is a non-finding (absence of evidence) at the veda.tech root; per-product partner UIs (Kraken, ether.fi) may apply their own screening.
    A3b
    Independent access paths exist: (i) the protocol's contracts are usable directly via Etherscan write tabs and any wallet; (ii) per veda.tech and immunefi, Veda powers Kraken DeFi Earn (a separate exchange-operated UI), ether.fi Liquid Vaults (https://etherfi.gitbook.io documentation references the same BoringVault at 0x917cee...), and is distributed through Binance Web3 wallet and Bybit Web3 wallet — at least four operationally independent fronts route to the same contract.
    A4
    On-chain blocklist: the Teller exposes `fromDenyList(address)`, `toDenyList(address)`, `operatorDenyList(address)` view functions and `allowFrom / allowTo / allowOperator / denyFrom / denyTo / denyOperator / allowAll / denyAll` write methods, all `requiresAuth`. The deny-list state is consulted in the `beforeTransfer(from, to, operator)` hook view that the BoringVault calls on every ERC-20 transfer. By default an address is NOT on the deny list, but the 4-of-6 Safe (via the Authority) can add any address to any of the three lists in one transaction.
    A5
    Read vs write access: read access (state views, balanceOf, totalSupply, accountantState) is fully public and unauthenticated. Write access for end-users (deposit / depositWithPermit / bulkDeposit / AtomicRequest) is currently public; write access for protocol operators (manage / pause / updateExchangeRate / setRateProviderData / setUserRole) is permissioned.
    A6
    ToS link present at https://veda.tech/terms (footer of veda.tech/), but I could not extract the verbatim jurisdictional / eligibility clause in this run; the ToS URL is recorded in unknowns rather than as a paraphrased finding. Veda Tech Labs Inc.'s separate SEC/CFTC public input (sec.gov filing dated 2026-03) frames vault-based architectures as a compliance pathway, which contextually suggests the ToS likely includes US-style eligibility carve-outs, but I do not infer that as a finding without the verbatim text.
    Why is this consensus tentative?
    • weak consensus margin

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ gpt-5.5-thinking url ↗ grok-4 url ↗ View raw submissions ↗

Stage

Preview of the Phase-3 maturity framework. DeFiPunk'd will adopt DeFiScan v2's stages verbatim; the section is rendered below in its intended shape so the structure is visible today.

Veda has not yet been assessed under the DeFiScan v2 stage framework.
The walkaway test is the central criterion. Once stages land, protocols reach Stage 1 only if users can exit in the presence of malicious operators even when the emergency council disappears.
Scope of assessment
Stages are assessed per-protocol against DeFiScan v2's criteria: governance structure, upgradeability path, timelock durations, emergency-council scope, and the walkaway test. The analysis depends on onchain discovery (roles, owners, timelocks) and deeper review of deployed contracts — neither of which DeFiPunk'd automates at Phase 0.
Stage 0 requirements pending
Governance is largely off-chain, contracts are upgradeable with short or no timelock, and the protocol depends on a multisig or team with full discretion. At Phase 0 DeFiPunk'd does not automatically evaluate these; the assessment lands with crawler-based onchain discovery.
Stage 1 requirements pending
Users can exit or opt out on their own terms even if the team disappears. Upgrades run through a meaningful timelock with an emergency security council clearly scoped. The walkaway test is the headline criterion.
Stage 2 requirements pending
Protocol is fully permissionless and immutable, or upgrades require a supermajority of token holders with a long timelock and no emergency override. This is the terminal stage of the DeFiScan v2 framework.
Learn more about DeFiScan v2 stages →
Stages are an opinionated assessment of maturity, not a rating of security or safety. A protocol can sit at Stage 2 and still carry substantial technical or economic risk; the framework exists to incentivize decentralization, not to rank protocols.

Contract surface

Every contract in scope for this protocol — pooled from DeFiLlama's TVL adapter (mechanical) and DEFI@home discovery submissions (LLM-curated). Verified-source flags come from Etherscan + Sourcify; owner / multisig metadata is read on-chain when available. Reviewer audit context, not a slice score. A lending protocol's adapter set will list third-party collateral tokens alongside its own contracts; attribution is the grader's job.

  • 214addresses
  • 29verified source
  • 14proxies
  • 5of 13 owners are Safes

TVL adapter pinned at 683d369. Sourcecode fetched 2026-05-06. Control fetched 2026-05-14.

arbitrumERC1967Proxy0x7189…dc27TVL✓proxy0x0c6c…97323/6 Safe
arbitrumClonableBeaconProxy0x2f2a…5b0fTVL✓proxy——
baseFiatTokenProxy0xcbb7…33bfTVL✓proxy——
baseERC1967Proxy0x6c24…2aa2TVL✓proxy——
baseWBTCOFT0x0555…2b9cTVL✓———
baseWETH90x4200…0006TVL✓———
berachainWBTCOFT0x0555…2b9cTVL✓—0xfead…186c—
berachainOFTTokenERC200x2f6f…7590TVL✓—0x64a8…737e—
bobWBTC0x03c7…cfa3TVL————
boringVaultsV0Arbitrumaccountant0x05a1…a32bTVL————
boringVaultsV0Arbitrumaccountant0x1b29…c13fTVL————
boringVaultsV0Arbitrumlens0x5232…4a1bTVL————
boringVaultsV0Arbitrumteller0xe19a…42d1TVL————
boringVaultsV0Arbitrumteller0xe2ac…fb1fTVL————
boringVaultsV0Arbitrumvault0x86b5…0161TVL———vault
boringVaultsV0Baseaccountant0x05a1…a32bTVL————
boringVaultsV0Baseaccountant0x0d05…8198TVL————
boringVaultsV0Baseaccountant0x1b29…c13fTVL————
boringVaultsV0Baseaccountant0x1c21…4156TVL————
boringVaultsV0Baseaccountant0x2863…3dceTVL————
boringVaultsV0Baselens0x5232…4a1bTVL————
boringVaultsV0Baseteller0x2ea4…b9b3TVL————
boringVaultsV0Baseteller0x5c13…66f5TVL————
boringVaultsV0Baseteller0x66b9…e98aTVL————
boringVaultsV0Baseteller0xe19a…42d1TVL————
boringVaultsV0Baseteller0xe2ac…fb1fTVL————
boringVaultsV0Basevault0x42a0…af85TVL———vault
boringVaultsV0Basevault0x5401…d57cTVL———vault
boringVaultsV0Basevault0x86b5…0161TVL———vault
boringVaultsV0Basevault0xf0bb…416cTVL———vault
boringVaultsV0Berachainaccountant0x0b24…0b0dTVL————
boringVaultsV0Berachainaccountant0x4fae…cce9TVL————
boringVaultsV0Berachainlens0x5232…4a1bTVL————
boringVaultsV0Berachainteller0xa697…27dfTVL————
boringVaultsV0Berachainteller0xf16c…53d7TVL————
boringVaultsV0Berachainvault0x46fc…a77eTVL———vault
boringVaultsV0Berachainvault0xb837…944eTVL———vault
boringVaultsV0Bnbaccountant0x2863…3dceTVL————
boringVaultsV0Bnblens0x5232…4a1bTVL————
boringVaultsV0Bnbteller0x2ea4…b9b3TVL————
boringVaultsV0Bnbvault0x5401…d57cTVL———vault
boringVaultsV0Bobaccountant0x22b0…e7d5TVL————
boringVaultsV0Boblens0xb1db…75aeTVL————
boringVaultsV0Bobteller0x19ab…16d3TVL————
boringVaultsV0Bobvault0x9998…8779TVL———vault
boringVaultsV0Ethereumaccountant0x05a1…a32bTVL————
boringVaultsV0Ethereumaccountant0x0639…30a7TVL————
boringVaultsV0Ethereumaccountant0x075e…1f75TVL————
boringVaultsV0Ethereumaccountant0x0d05…8198TVL————
boringVaultsV0Ethereumaccountant0x126a…156bTVL————
boringVaultsV0Ethereumaccountant0x1683…1087TVL————
boringVaultsV0Ethereumaccountant0x1b29…c13fTVL————
boringVaultsV0Ethereumaccountant0x1c21…4156TVL————
boringVaultsV0Ethereumaccountant0x1d4f…1e0cTVL————
boringVaultsV0Ethereumaccountant0x2863…3dceTVL————
boringVaultsV0Ethereumaccountant0x2e0e…811dTVL————
boringVaultsV0Ethereumaccountant0x37e6…c45bTVL————
boringVaultsV0Ethereumaccountant0x3a59…3668TVL————
boringVaultsV0Ethereumaccountant0x58cd…ff5bTVL————
boringVaultsV0Ethereumaccountant0x6049…a2ecTVL————
boringVaultsV0Ethereumaccountant0x6b2d…c35fTVL————
boringVaultsV0Ethereumaccountant0x737f…3f18TVL————
boringVaultsV0Ethereumaccountant0x95fe…7cfeTVL————
boringVaultsV0Ethereumaccountant0x9a22…e043TVL————
boringVaultsV0Ethereumaccountant0xa76e…a0beTVL————
boringVaultsV0Ethereumaccountant0xb532…c5aaTVL————
boringVaultsV0Ethereumaccountant0xb647…0f95TVL————
boringVaultsV0Ethereumaccountant0xbae1…e2baTVL————
boringVaultsV0Ethereumaccountant0xbe16…afbeTVL————
boringVaultsV0Ethereumaccountant0xc315…d3e7TVL————
boringVaultsV0Ethereumaccountant0xc873…18f5TVL————
boringVaultsV0Ethereumaccountant0xe485…3d53TVL————
boringVaultsV0Ethereumaccountant0xe803…5114TVL————
boringVaultsV0Ethereumaccountant0xea23…e6b0TVL————
boringVaultsV0Ethereumaccountant0xeb44…b790TVL————
boringVaultsV0Ethereumaccountant0xf1ec…f986TVL————
boringVaultsV0Ethereumlens0x5232…4a1bTVL————
boringVaultsV0Ethereumlens0x9098…a396TVL————
boringVaultsV0Ethereumlens0xa2c8…34fbTVL————
boringVaultsV0Ethereumlens0xc67a…6903TVL————
boringVaultsV0Ethereumlens0xe0ef…57feTVL————
boringVaultsV0Ethereumteller0x0baa…614bTVL————
boringVaultsV0Ethereumteller0x1645…d1c8TVL————
boringVaultsV0Ethereumteller0x221e…ef64TVL————
boringVaultsV0Ethereumteller0x258f…71b2TVL————
boringVaultsV0Ethereumteller0x2ea4…b9b3TVL————
boringVaultsV0Ethereumteller0x31a5…f5b8TVL————
boringVaultsV0Ethereumteller0x358c…776aTVL————
boringVaultsV0Ethereumteller0x417e…4d35TVL————
boringVaultsV0Ethereumteller0x4e7d…ef1eTVL————
boringVaultsV0Ethereumteller0x5989…3f36TVL————
boringVaultsV0Ethereumteller0x5c13…66f5TVL————
boringVaultsV0Ethereumteller0x63b2…2bb0TVL————
boringVaultsV0Ethereumteller0x63ed…e884TVL————
boringVaultsV0Ethereumteller0x66b9…e98aTVL————
boringVaultsV0Ethereumteller0x7c34…dcd1TVL————
boringVaultsV0Ethereumteller0x7c75…e584TVL————
boringVaultsV0Ethereumteller0x929b…8474TVL————
boringVaultsV0Ethereumteller0x99de…b861TVL————
boringVaultsV0Ethereumteller0x9e88…2d48TVL————
boringVaultsV0Ethereumteller0xa55a…f76eTVL————
boringVaultsV0Ethereumteller0xa5c0…d098TVL————
boringVaultsV0Ethereumteller0xb02d…328eTVL————
boringVaultsV0Ethereumteller0xb6f7…12b0TVL————
boringVaultsV0Ethereumteller0xbbf9…0103TVL————
boringVaultsV0Ethereumteller0xc7bf…7c75TVL————
boringVaultsV0Ethereumteller0xc8c5…1fe2TVL————
boringVaultsV0Ethereumteller0xe19a…42d1TVL————
boringVaultsV0Ethereumteller0xe2ac…fb1fTVL————
boringVaultsV0Ethereumteller0xe6a0…0de2TVL————
boringVaultsV0Ethereumteller0xe973…1e73TVL————
boringVaultsV0Ethereumteller0xead0…35fdTVL————
boringVaultsV0Ethereumvault0x08c6…364cTVL———vault
boringVaultsV0Ethereumvault0x1293…aa7cTVL———vault
boringVaultsV0Ethereumvault0x165c…36c7TVL———vault
boringVaultsV0Ethereumvault0x294e…fbadTVL———vault
boringVaultsV0Ethereumvault0x309f…8aafTVL———vault
boringVaultsV0Ethereumvault0x3521…c997TVL———vault
boringVaultsV0Ethereumvault0x42a0…af85TVL———vault
boringVaultsV0Ethereumvault0x5401…d57cTVL———vault
boringVaultsV0Ethereumvault0x5e27…7089TVL———vault
boringVaultsV0Ethereumvault0x5f46…0726TVL———vault
boringVaultsV0Ethereumvault0x699e…6490TVL———vault
boringVaultsV0Ethereumvault0x6bf3…3ddfTVL———vault
boringVaultsV0Ethereumvault0x7223…4273TVL———vault
boringVaultsV0Ethereumvault0x86b5…0161TVL———vault
boringVaultsV0Ethereumvault0x917c…9d88TVL———vault
boringVaultsV0Ethereumvault0xaf13…5837TVL———vault
boringVaultsV0Ethereumvault0xbc0f…8265TVL———vault
boringVaultsV0Ethereumvault0xca87…39e4TVL———vault
boringVaultsV0Ethereumvault0xd107…a000TVL———vault
boringVaultsV0Ethereumvault0xe770…eee9TVL———vault
boringVaultsV0Ethereumvault0xeda6…4e70TVL———vault
boringVaultsV0Ethereumvault0xef41…aa09TVL———vault
boringVaultsV0Ethereumvault0xf0bb…416cTVL———vault
boringVaultsV0Ethereumvault0xf153…8cb7TVL———vault
boringVaultsV0Ethereumvault0xf6d7…2cb3TVL———vault
boringVaultsV0Ethereumvault0xfe0c…978fTVL———vault
boringVaultsV0Hyperevmaccountant0x7439…ece2TVL————
boringVaultsV0Hyperevmlens0x5232…4a1bTVL————
boringVaultsV0Hyperevmteller0x29c0…3158TVL————
boringVaultsV0Hyperevmvault0x9ba2…b160TVL———vault
boringVaultsV0Inkaccountant0x0c4d…dc67TVL————
boringVaultsV0Inkaccountant0x427a…8b22TVL————
boringVaultsV0Inkaccountant0x8c9c…eaf7TVL————
boringVaultsV0Inkaccountant0x9c24…54c9TVL————
boringVaultsV0Inklens0x5232…4a1bTVL————
boringVaultsV0Inklens0x9098…a396TVL————
boringVaultsV0Inkteller0x4863…dedbTVL————
boringVaultsV0Inkteller0x50e9…c522TVL————
boringVaultsV0Inkteller0xc151…29fcTVL————
boringVaultsV0Inkteller0xc46f…f6a0TVL————
boringVaultsV0Inkvault0x63d1…868eTVL———vault
boringVaultsV0Inkvault0x9761…1ccaTVL———vault
boringVaultsV0Inkvault0xcaae…789fTVL———vault
boringVaultsV0Inkvault0xdbd8…a271TVL———vault
boringVaultsV0Plasmaaccountant0x737f…3f18TVL————
boringVaultsV0Plasmalens0xc67a…6903TVL————
boringVaultsV0Plasmateller0x4e7d…ef1eTVL————
boringVaultsV0Plasmavault0xd107…a000TVL———vault
boringVaultsV0Scrollaccountant0x0d05…8198TVL————
boringVaultsV0Scrollaccountant0x1b29…c13fTVL————
boringVaultsV0Scrollaccountant0xc315…d3e7TVL————
boringVaultsV0Scrollaccountant0xea23…e6b0TVL————
boringVaultsV0Scrollaccountant0xeb44…b790TVL————
boringVaultsV0Scrolllens0x5232…4a1bTVL————
boringVaultsV0Scrollteller0x221e…ef64TVL————
boringVaultsV0Scrollteller0x5c13…66f5TVL————
boringVaultsV0Scrollteller0x9e88…2d48TVL————
boringVaultsV0Scrollteller0xcc9a…a8faTVL————
boringVaultsV0Scrollteller0xe19a…42d1TVL————
boringVaultsV0Scrollvault0x08c6…364cTVL———vault
boringVaultsV0Scrollvault0x5f46…0726TVL———vault
boringVaultsV0Scrollvault0xf0bb…416cTVL———vault
boringVaultsV0Sonicaccountant0x0639…30a7TVL————
boringVaultsV0Sonicaccountant0x3a59…3668TVL————
boringVaultsV0Sonicaccountant0xa76e…a0beTVL————
boringVaultsV0Sonicaccountant0xc1a2…8acbTVL————
boringVaultsV0Soniclens0x5232…4a1bTVL————
boringVaultsV0Soniclens0xe0ef…57feTVL————
boringVaultsV0Sonicteller0x258f…71b2TVL————
boringVaultsV0Sonicteller0x31a5…f5b8TVL————
boringVaultsV0Sonicteller0x358c…776aTVL————
boringVaultsV0Sonicteller0xace7…f079TVL————
boringVaultsV0Sonicvault0x309f…8aafTVL———vault
boringVaultsV0Sonicvault0xbb30…bfbdTVL———vault
bscWBTCOFT0x0555…2b9cTVL✓———
ethereumERC1967Proxy0x386e…5fb6TVL✓proxy——
ethereumFiatTokenProxy0xcbb7…33bfTVL✓proxy0xce56…16e6—
ethereumERC1967Proxy0x1570…a138TVL✓proxy0xd7cd…4f243/5 Safe
ethereumBoringVault0x657e…c642TVL✓———
ethereumTransparentUpgradeableProxy0xec53…1f83TVL✓proxy0x369e…91111/2 Safe
ethereumEtherFiGovernanceToken0xfe0c…c0ebTVL✓———
ethereumBoringVault0x9397…6663TVL✓———
ethereumTransparentUpgradeableProxy0xd5f7…adfaTVL✓proxy——
ethereumTransparentUpgradeableProxy0x73a1…acf5TVL✓proxy——
ethereumFiatTokenProxy0xa0b8…eb48TVL✓proxy0xfcb1…ae3a—
ethereumUSDe0x4c9e…68b3TVL✓—0x3b0a…18625/11 Safe
ethereumTetherToken0xdac1…1ec7TVL✓—0xc6cd…a828—
ethereumWBTC0x2260…c599TVL✓—0xca06…beb7—
ethereumWETH90xc02a…6cc2TVL✓———
Ethereumvault (weETHs)0x917c…9d88discovery———vault
hyperliquidWHYPE0x5555…5555TVL————
inkUSDC0x2d27…eaedTVL————
legacyVaultsEthereumid0xea1a…a221TVL————
mantleTransparentUpgradeableProxy0xe682…e8faTVL✓proxy0x71a1…50376/14 Safe
plasmaUSDT00xb8ce…5ebbTVL————
scrollWBTC0x3c1b…0cf1TVL✗———
scrollWETH0x5300…0004TVL✗———
sonicTransparentUpgradeableProxy0xecac…11c1TVL✓proxy0xd217…28a4—
sonicBoringVault0x3bce…7812TVL✓———
sonicBoringVault0xd3dc…97aeTVL✓———
sonicFiatTokenProxy0x2921…8894TVL✓proxy0xfb5c…58b8—
sonicMintedERC200x309c…ebc7TVL✓———

Protocol Info

Links

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Website
https://veda.tech
Twitter
@veda_labs
GitHub
2 repositories
Docs
https://docs.veda.tech/

Security

[:] Source: DEFI@home quorum
Audits
25 audits
Bug bounty
https://immunefi.com/bug-bounty/veda/information/
Security contact
help@veda.tech

Technical

[:] Source: DEFI@home quorum
Deployed contracts
https://github.com/Veda-Labs/boring-vault/tree/main/deployments
Upgradeability
Immutable

Provenance

[defillama] Source: DeFiLlama
Review status
listed
Updated
2026-06-01 11:27 UTC