Veda

Veda is a DeFi vault / yield infrastructure protocol that tokenizes strategy vaults (often ERC‑4626 “vTokens”) to deliver yield from underlying DeFi strategies across multiple chains. ### Protocol identification

• Name: Veda (sometimes described as a “vault infrastructure” or “yield operating system”).
• Website: veda.tech (institutional-facing vault infrastructure).
• Docs: docs.veda.tech, including architecture and vault deployment sections.
• Category: DeFi yield / vault infrastructure, sitting as an abstraction layer over lending, DEX, staking, and structured products.
• Launch date: The public “Introducing Veda” post is dated June 22, 2025; this is the best available proxy for protocol launch.
• Chains:
• Ethereum – core deployments and major partner vaults (Ether.fi Liquid, Lombard, etc.).
• Base, Sei – described as live for Veda‑powered vaults in 2026.
• A Plasma chain is mentioned in your brief, but I found no independent confirmation tying “Plasma” deployments to the same Veda protocol contracts; Not verifiable as of 2026‑09‑04.
• Native token: I found no clear evidence of a live, tradable Veda governance or utility token; sources focus on vault tokens (vTokens) and partner assets (eETH, LBTC, etc.). Not verifiable as of 2026‑09‑04. ### Main contracts & verification Public sources describe Veda’s architecture around an immutable BoringVault primitive with separate Manager, Vault, and Auditor roles, often implemented as ERC‑4626 vaults that mint vTokens representing strategy exposure. However:
• Specific Ethereum contract addresses for core Veda vault/manager/auditor contracts are not listed in independent analytics, media, or explorer-based write‑ups.
• Without direct on‑chain queries or explorer lookups, I cannot reliably identify or cross‑check main contract addresses or their verification status. Therefore: Main contract addresses and their explorer verification status are Not verifiable as of 2026‑09‑04. ### Fork lineage & upstream relationships
• Veda is built around BoringVault, described as the “immutable vault primitive behind $5B+ in DeFi yield strategies” and referred to as “the most widely adopted vault standard in DeFi”. This indicates Veda uses BoringVault as upstream infrastructure rather than being a simple fork of a single vault protocol.
• Available materials characterize Veda as a purpose-built abstraction / yield layer, not as a fork of a well-known vault protocol like Yearn or Idle.
• I found no evidence of:
• Malicious modifications in Veda relative to upstream BoringVault.
• Documented exploit history specifically tied to Veda forks.
• Formal audits explicitly covering “Veda vs upstream BoringVault changes” in publicly listed audit repositories. Given the lack of audit PDFs or explicit diff analyses, fork-related audit coverage and any malicious-modification history are Not verifiable as of 2026‑09‑04.

Veda presents as a real product, not just a marketing landing page: its main site says it provides “smart contracts to SDKs and APIs” for institutional DeFi vaults, and its docs include concrete deposit/withdrawal flows, vault discovery, and metrics endpoints. The documentation also describes actual user-facing mechanics such as approvals, deposits through a Teller contract, instant withdrawals when enabled, and queued withdrawals when liquidity is insufficient, which is consistent with a mature product surface rather than a static brochure. An open API appears to exist.

Veda’s docs expose /v1/vaults, chain-specific vault lookup, and a latest metrics snapshot endpoint, and the docs explicitly say vaults are discoverable “across every chain.” Separate developer documentation also states that Veda provides an API service for external invocation of read-only contract methods. For UX maturity, the presence of structured docs, chain-specific vault pages, and operational deposit/withdrawal instructions is a positive signal. I did not verify live app flows, broken links, fake metrics, or template reuse from the web snippets alone, so those items are Not verifiable as of 2026-09-04.

For Plasma specifically, Veda has a dedicated Plasma vault deployment page and Plasma is described by Veda as a supported vault provider environment. For Ethereum, the docs and Privy integration page both indicate Ethereum support among major EVM chains.

Veda has an active Immunefi bug bounty program. It started on 21 January 2026 and is listed as live through at least 18 August 2026. The program covers smart contracts, requires a PoC, and requires KYC for payout processing.

Critical smart contract bugs are rewarded at 10% of the funds directly affected, capped at $1,000,000 with a minimum payout of $100,000. High-severity issues involving theft or permanent freezing of unclaimed yield/royalties are rewarded in the $10,000–$25,000 range. Payouts are handled by the Veda team directly and paid in USDC on Ethereum.

Publicly reported results are not listed on the program page, so program outcomes are not verifiable from the available sources.

Scope: Dune/on-chain verification was unavailable; therefore current balances, allocations, bridge volumes, asset composition, counterparty concentration and chain percentages are Not verifiable as of September 5, 2026. External protocol dependencies — material risk. Veda is an allocation/vault layer. Its documentation identifies integrations with lending, DEX, staking and restaking venues, including Aave, Morpho, Euler, Balancer, Uniswap, Gearbox, Fluid, EtherFi and Karak. A failure, exploit, insolvency, oracle error or liquidity freeze at any active venue could impair NAV; the specific active venues and weights are not independently verified. Plasma / bridge risk. Veda states that the Plasma pre-deposit vault initially deployed capital to Aave on Ethereum, then bridged assets to Plasma.

Veda also states it can convert deposits into stablecoins and uses “industry-leading bridging solutions,” but does not identify the bridge(s) or provide independently verifiable current exposure. Bridge smart-contract, mint/burn, relayer, finality and destination-chain risks therefore remain material. Oracle and accounting risk. Veda’s controls include rate providers, bounded exchange-rate updates, Merkle-whitelisted actions and delayed withdrawals. These reduce arbitrary-strategy and flash-loan risks but do not eliminate dependency on underlying protocol pricing/oracles, stablecoin pegs, liquidity and strategist/admin operations.

The exact oracle providers and vault-specific configurations are Not verifiable as of September 5, 2026. Stablecoin, LST/restaking, custody and institutional counterparties. Stablecoin exposure is inherent to the Plasma product; exact issuers, denominations and concentration are Not verifiable as of September 5, 2026. Selected-vault LST/restaking, RWA issuer/SPV, CEX, market-maker and custodial exposure is likewise Not verifiable as of September 5, 2026. Veda describes contracts as non-custodial, but this does not remove bridge, strategist, administrator or underlying-protocol counterparty risk. Contradiction / data-quality callout: DeFiLlama currently reports Veda across 13 chains, while the supplied scope lists only Ethereum and Plasma; it reports approximately $1.966B on Ethereum and $666.5M on Plasma.

These are aggregator figures, not on-chain verification, and the discrepancy is unresolved. Failure scenarios: underlying-protocol exploit or insolvency; stablecoin depeg; oracle/accounting mispricing; bridge compromise or stuck migration; Plasma liquidity/finality failure; withdrawal queue freeze; or privileged-key/strategist failure.

Veda’s custody is organized as a non-custodial smart-contract system: user assets are held in the BoringVault contract or in DeFi positions controlled by it, while deposits and withdrawals are executed onchain through Veda’s contracts rather than by a centralized custodian. The BoringVault is the core custody contract, the Teller handles deposits/withdrawals and mints/burns vault shares, and the Manager can rebalance only into pre-approved strategies enforced by allowlist logic. Withdrawal rights are programmatic rather than discretionary: Veda documents both instant withdrawals (when buffer liquidity is sufficient) and a BoringQueue fallback with time delay and solver fulfillment, so withdrawal availability depends on vault configuration and liquidity.

On the segregation question, Veda and its linked materials state cryptographic segregation / client entitlement separation as an intended structural property, but a chain-level verification is not available here; therefore this remains Not verifiable as of 2026-09-06. Likewise, there is no reliable independent evidence here that withdrawals are paused, so withdrawal_paused is Not verifiable as of 2026-09-06.

A 2024 Ordinals/BTC-related project also named Veda was publicly described as indefinitely postponed after a 'vulnerability' controversy, but this appears to be a different project name-collision and is not verifiably the Ethereum/Plasma vault protocol asked about.

Veda’s key management is split between onchain permissions and offchain operational controls. Onchain, the vault architecture is designed so that only pre-registered actions can execute: the Manager stores allowed operations in a Merkle tree and each action must prove inclusion before it runs, while the Teller, Accountant, and optional hooks add transfer, pricing, and compliance checks. Offchain, Veda says its production controls include role-based access, MFA for privileged access, peer-reviewed infrastructure changes, direct confirmation for signing, timelocks on sensitive roles, and admin keys kept in cryptographically secured devices.

Veda’s docs also say vaults are tenant-scoped via the API key and that a vault can be deployed on one or more chains with the same vault address on each chain. The material does not provide a detailed public inventory of who holds each admin key, how threshold signing is set up, or whether Ethereum and Plasma use different key custody models; those specifics are Not verifiable as of 2026-09-04.

As of September 5, 2026 — scope. The only deployment independently matched to Veda’s Plasma product is the Ethereum pre-deposit BoringVault PlasmaUSD, 0xd1074E0AE85610dDBA0147e29eBe0D8E5873a000. A distinct Plasma-chain deployment is Not verifiable as of September 5, 2026. The Ethereum contract is explorer-verified, directly deployed, and not a standard proxy: its constructor is BoringVault(address owner, name, symbol, decimals) and no proxy-admin interface is exposed. Architecture / privileged paths ``text User -> Teller (not independently identified) -> BoringVault | | Accountant/oracle Authority | | Queue/Solver withdrawal Manager -> manage(target,data,value) | approved strategy targets/decoders (Arctic design) ` The core vault exposes privileged manage, enter, exit, setAuthority, transferOwnership, and setBeforeTransferHook. manage can execute arbitrary calldata and native value from the vault when authorization passes; enter/exit` mint/burn shares and move assets.

The Arctic architecture is intended to constrain manager actions through Merkle-approved targets, selectors, arguments, and value transfer, but that control is external to the minimal vault. Admin / upgrade risk. No proxy upgrade path was identified for the Ethereum vault; implementation upgrades would require migration to a new vault. Owner renunciation appears in third-party explorer data as the zero address, but current owner, authority, role membership, proxy-admin type, and decoded authority events were not independently re-queried because Dune is unavailable: Not verifiable as of September 5, 2026. Timelock address and on-chain delay: Not verifiable as of September 5, 2026. Exit / freeze / compromise assessment. Users do not have a direct unrestricted vault withdrawal; exits depend on authorized Teller/Queue paths and available liquidity.

The architecture supports delayed, permissioned withdrawals and an Accountant pause that can stop deposits and withdrawals. If manager/authority keys or an unrestricted Teller/Accountant role were compromised, the worst case is malicious strategy execution, accounting manipulation, withdrawal denial, or temporary freezing; direct full drainage depends on the deployed authority/manager configuration and is Not verifiable as of September 5, 2026. Audits exist for the architecture, but deployment-specific audit scope and unresolved severities are not confirmed.

Multiple architecture/component audits referenced in Veda docs as A‑4, A‑8, A‑10, A‑18, A‑36 (BoringVault architecture and submodules).

Veda’s audit page lists a “Full Architecture” initial audit covering the core Boring Vault architecture, including BoringVault, Teller, Accountant, Queue, Solver, and decoder/sanitizer contracts. The page links the report as “A-4” on Macro’s audit library. The page does not expose the report text in the search result, so critical/high/medium counts, fix status, and whether every deployed contract is covered are not verifiable from the provided material.

The Plasma/Veda materials also state that deposits into Plasma’s sale vaults used Veda’s audited contracts, but a bytecode-match confirmation for deployed addresses is not verifiable as of 2026-08-29.

Report: Boring Vault Arctic v1. Auditor: 0xMacro. Scope: Boring Vault Arctic architecture update; Plasma repository. Covers deployed code: Not verifiable as of September 4, 2026; no bytecode-to-report match was established.

Security Assessment - Veda Yield Streaming

Security Assessment Report - Veda Incentive Teller System

Veda – Security Assessment Fuzzing and Invariant Testing

Report: Yield Streaming. Auditor: Certora. Scope: Solidity code implementing Yield Streaming. Covers deployed code: Not verifiable as of September 4, 2026; audit scope is code-level and no deployed bytecode match was found. Certora reported no significant security issues, while noting issues detailed in the report.

Report: Fuzz and Invariant Testing. Auditor: Certora. Scope: Foundry/Medusa fuzzing and invariant testing of Veda smart contracts. Covers deployed code: Not verifiable as of September 4, 2026; testing artifacts do not establish deployed-bytecode matching.

Report: Incentive Teller System. Auditor: Certora. Scope: Code changes for the Incentive Teller System, including teller functions for deposits, withdrawals, bridging, queueing, and controlled asset movement. Covers deployed code: Not verifiable as of September 4, 2026; no deployed bytecode match established.

Aggregate audit claims for BoringVault and Veda infrastructure.

Full security review of BoringVault Arctic version (Veda docs reference Spearbit audit PDF).

Report: Boring Vault Arctic. Auditor: Spearbit (Cantina). Scope: Full security review of the Boring Vault Arctic architecture. Covers deployed code: Not verifiable as of September 4, 2026; no deployed-address/bytecode match was established.

Veda appears to be a real operating DeFi startup, but several core details are still only partially verifiable from public sources. The named founders are Sun Raghupathi (CEO), Joseph Terrigno (CTO), and Stephanie Vaughan (COO); Veda’s own team page also lists TuongVy Le as General Counsel and Josh Kessler as Chief Growth Officer. The most credible public evidence of prior track record is Sun Raghupathi’s LinkedIn, which shows he previously worked at Sommelier Protocol as Head of Research and Development / Data Scientist and lists co-founding Seven Seas Capital; Veda’s press release and podcast also describe the team as coming from prior DeFi vault work.

On credibility, the available evidence suggests a public, venture-backed team rather than an anonymous or purely on-chain pseudonymous project: Veda says it was founded in early 2024, LinkedIn lists the company as privately held with 11–50 employees, and the team page includes named executives with identifiable backgrounds and credentials. The co-founders are publicly named in multiple independent media/interview sources, which lowers the likelihood of it being a web-front only project. Reality-check limitations remain important.

Not all claimed credentials are independently verified here, and I could not confirm a real office, legal domicile, or whether the operating entity is onshore/offshore from the available sources. Likewise, I could not verify past hacks, security incidents, or prior project outcomes beyond the general claim that the team has worked on Sommelier/vault infrastructure. Not verifiable as of 2026-09-04: office location, incorporation jurisdiction, offshore/onshore structure, and any prior incident history.

Net assessment: Veda looks like a legitimate, publicly staffed DeFi business with named founders and recognizable backgrounds, not an obvious anon or fake front, but the strongest remaining diligence gaps are corporate structure, physical presence, and independent confirmation of the founders’ full prior-record claims.

Veda’s reputation appears generally positive among DeFi risk/ranking sources, with Hindenrank rating it B / 21-22 out of 100 and describing a clean operational history, but also flagging systemic risk from its scale and principal-agent risk from the curator model. The strongest external validation in the results is its bug bounty presence on Immunefi and the fact that it has an audited, minimal-core vault architecture according to Veda’s own docs; however, the protocol website’s claims about being the “largest”/“most battle-tested” are unverified marketing claims here because I could not independently confirm them from non-protocol sources. On founders and investors, the results indicate Veda was co-founded by Stephanie Vaughan and Josh Kessler, and a press release says the project raised $18M led by CoinFund.

That funding and institutional positioning are consistent with the generally favorable sentiment in the coverage, which describes Veda as infrastructure for major yield products and institutional onchain yield. I found no clear fraud, rug-pull, insolvency, sanctions, or regulator-action allegations in the supplied results. The closest cautionary notes are about concentration/systemic risk, vitality risk (Hindenrank calls it “safe but stale” in one piece), and the dependency on downstream DeFi protocols, not accusations of misconduct. Unresolved concerns: reliance on a single vault codebase at large scale, curator discretion over strategies, and possible stale-growth concerns if activity slows.

I also found one ambiguous/low-credibility item about “token distribution controversy,” but it is not clearly about this Veda protocol and is not verifiable as of 2026-09-04.

As of September 5, 2026, the prior classification of Veda as a perpetual DEX is contradicted by current evidence. Veda is a vault/infrastructure protocol: BoringVaults custody deposits, deploy assets through curator-approved Merkle-whitelisted actions, and tokenize strategy exposure. Economic model: Strategy and assets are product-specific, not protocol-wide. Documented examples include stablecoin lending on Aave (PlasmaUSD pre-deposit vault) and broader integrations with Aave, Morpho, Euler and other approved venues.

Yield is therefore primarily external protocol yield, staking yield, or strategy PnL; subsidy/incentive contribution is Not verifiable as of September 5, 2026. Organic yield cannot be reliably separated from incentives: Not verifiable as of September 5, 2026. No protocol-wide market-neutral/directional classification is possible; strategies may differ.

Leverage, looping, restaking and external exposure are vault-specific; aggregate leverage is Not verifiable as of September 5, 2026. Withdrawals and controls: Deposits mint vault shares at an Accountant exchange rate. Newly issued shares have a brief anti-MEV lock. Withdrawals may use a delayed, solver-based queue with configurable maturity; instant liquidity depends on available buffers.

Exact lock periods, fees, minimums, caps, slippage rules and per-vault gates are Not verifiable as of September 5, 2026. Revenue: DeFiLlama reports 30-day fees of $4.04m and protocol revenue of $839,409, but these are analytics-platform figures, not on-chain-verified. TVL: DeFiLlama reports $1.743b total across 13 chains; Ethereum $623.9m (35.8%) and Plasma $31.89m (1.8%). Dune comparison and product-level on-chain TVL are Not verifiable as of September 5, 2026. APY: DeFiLlama shows an average supply APY of 1.15% across four pools; PlasmaUSD shows 3.17% current APY versus 3.56% 30-day average. Longer APY history, volatility and sustainability are Not verifiable as of September 5, 2026.

As of 2026-09-05, no standalone Veda treasury/reserve wallet, reserve policy, liability ledger, or proof-of-reserves attestation was identified. On-chain balances via Dune are Not verifiable as of 2026-09-05 because Dune MCP is unavailable; do not treat protocol TVL as reserves. What is supported by available evidence

• Veda is vault infrastructure. Funds are held in individual BoringVault contracts, then deployed into whitelisted DeFi strategies; assets remain on-chain across custody, strategy positions, and withdrawal queues.
• The architecture describes Merkle-whitelisted strategy execution and configurable withdrawal queues, but the specific administrator, signer/multisig, upgrade authority, and control relationships for Ethereum and Plasma are Not verifiable as of 2026-09-05.
• A documented Plasma-related Ethereum pre-deposit vault is PlasmaUSD at 0xd1074E0AE85610dDBA0147e29eBe0D8E5873a000; this is a customer/product vault, not verified as a Veda treasury wallet.
• Audits and a 2026 Certora assessment exist for protocol components, but these are security reviews—not reserve attestations or solvency opinions. Contradiction / interpretation callout
• CoinDesk reported Veda “overseeing” more than $3.7B in TVL in June 2025, while current aggregator snapshots report approximately $1.28B (DeFiLlama) and $1.72B (OAK). These figures are not directly comparable because they may use different dates, chain coverage, and definitions; neither establishes liquid reserves or liabilities. Conclusion: Veda appears to operate non-custodial, product-specific vaults rather than a single reserve-backed treasury. A protocol-level reserve balance, composition, custody/control map, formal reserve policy, and liabilities are Not verifiable as of 2026-09-05. No reserve/liability value is reported in the structured fields.

Veda does not have a native transferable token. The protocol’s own docs state that Veda does not have a native token; the “Veda” items found on market-data sites appear to be either unrelated listings or non-authoritative price pages, so tokenomics such as ticker, contract address, total/circulating supply, FDV, emissions, unlocks, allocations, staking rewards, and holder concentration are Not verifiable as of 2026-09-04. The most reliable available source for this specific point is Veda’s GitHub docs, which explicitly says the protocol has no native token.

Because there is no verified native token, there is no confirmed token utility, governance role, revenue-share, buyback, burn, or staking design to report for Veda itself. The same docs also indicate Veda’s BVM design excludes a native-token-based consensus layer. For controls and risk functions, no verified on-chain token exists to assess for mint/blacklist/fee-switch permissions, so those controls are Not verifiable as of 2026-09-04.

Likewise, DEX liquidity depth and main listings are Not verifiable as of 2026-09-04 for a Veda native token. A separate source from Plasma describes XPL as Plasma’s native token, not Veda’s; this is important because Veda appears to be infrastructure used within Plasma, not the token issuer.

For Veda, a Bitcoin crash below $10,000 is a severe market stress event, but the protocol-specific downside is not verifiable as of 2026-09-04 from the available sources. Veda vaults can hold BTC exposure through wrapped and staked representations such as wBTC and LBTC, and they can deploy those assets into approved strategies across chains including Ethereum; however, the sources do not provide chain-by-chain TVL, exact BTC inventory, or a loss-waterfall for a BTC crash scenario. The main risk channel is straightforward: if a Veda vault has BTC-linked assets, a collapse to $10,000 would likely trigger large mark-to-market losses, possible strategy underperformance versus benchmarks, and potentially lower share value for vault users.

Veda also states that its vault architecture includes onchain safety checks that limit update frequency and constrain how much rates can change between updates, plus rebalancing deviation checks and pause logic during abnormal conditions, which may dampen abrupt mechanical changes but do not eliminate underlying asset-price risk. A key limitation is that the available sources do not confirm whether Veda currently has material BTC exposure on Ethereum or Plasma, nor do they quantify how much of TVL is exposed to BTC versus other assets. Therefore, the exact impact on user principal, fee income, or withdrawal liquidity is Not verifiable as of 2026-09-04.

The safest institutional interpretation is:

• If BTC exposure is low or hedged: impact is likely contained to relative underperformance and temporary rebalance stress.
• If BTC exposure is material and unhedged: a BTC move below $10,000 could create severe NAV impairment and possible withdrawal pressure.
• If the vault uses leveraged or basis-sensitive BTC strategies: stress could be amplified, but this is Not verifiable as of 2026-09-04.

For a 20% depeg in the largest collateral asset, the direct loss to a Veda vault is approximately 20% of that asset’s exposure in the vault. Because the available sources do not provide a verifiable, chain-by-chain asset allocation for Veda on Ethereum or Plasma, the protocol-level dollar impact is Not verifiable as of 2026-09-04. What can be said from the sources is that Veda is a vault infrastructure protocol used to allocate capital into strategies such as Aave, Curve, and Uniswap-style liquidity provision, and some deployments use withdrawals with a buffer or queued solver-based fulfillment rather than immediate redemption.

That means a depeg shock would primarily matter through the specific vault’s underlying portfolio composition and its liquidity mechanics, not Veda as a single pooled balance sheet. For stress analysis, the relevant formula is:

• Vault loss ≈ 0.20 × exposure to the depegging collateral
• If the asset is also used as borrow collateral or in levered strategies, the effective loss can be larger due to forced rebalancing, liquidation, or withdrawal delays, but that cannot be quantified from the provided sources. The only explicit concentration/control clue in the sources is that one collateral vault documented by Rings cannot exceed 10% of the TVL of the venue where it deposits, which limits venue concentration but does not tell us Veda’s own asset mix. Given the missing allocation data, the prudent conclusion is: a 20% depeg is a material downside shock whose dollar impact depends on the vault’s largest collateral weight; the exact loss and any contagion effect are not verifiable from the supplied sources.

For Veda, a “top counterparty insolvent” stress is best interpreted as a failure of one of the external protocols, custodians, or other off-vault counterparties that the vault allocates capital to, because Veda describes its vaults as deploying assets into external yield strategies and emphasizes collateral-quality assessments plus stress testing for liquidation cascades. If a downstream counterparty becomes insolvent, the expected loss path is: the affected position is impaired first, then the vault’s NAV falls, then depositor withdrawal value/available liquidity may be reduced or delayed depending on how the strategy and withdrawal mechanics are implemented.

For Veda, I found no verifiable evidence in the provided sources that the DAO or its owners committed fraud. The search results are mostly generic DAO-fraud explainers and unrelated legal/security articles, not protocol-specific evidence about Veda on Ethereum or Plasma. For this stress scenario, the risk assessment is therefore Not verifiable as of 2026-09-04.

I cannot confirm a fraud event, a malicious treasury drain, or owner misappropriation from the supplied material, and I should not infer one without protocol-specific evidence. The only relevant general pattern is that DAO fraud can occur through treasury theft, misleading fundraising, or compromised governance keys, but those are *general mechanisms*, not evidence that they happened for Veda.

• Status: Not verifiable as of 2026-09-04
• Scope: Ethereum, Plasma
• Finding: No protocol-specific fraud evidence provided

Veda’s own documentation describes it as a vault primitive / vault infrastructure for pricing, accounting, securing, optimizing, and automating capital, but the provided sources do not disclose a chain-specific primary yield source for Veda vaults on Ethereum or Plasma. Because of that, the request to assess a “primary yield source negative 30d” stress scenario is Not verifiable as of 2026-09-04 from the supplied evidence. Veda’s flow-of-funds docs do confirm that vault assets can be allocated across multiple DeFi protocols and chains, so a negative 30-day return in one underlying leg would be a strategy-level stress input rather than a protocol-wide on-chain fact.

The only explicit negative-yield discussion in the results concerns Ethena’s funding-rate-driven model, not Veda, so it cannot be used as evidence for Veda’s actual yield source. For an institutional risk memo, the correct treatment here is: primary yield source = Not verifiable as of 2026-09-04, therefore the 30-day negative-yield stress cannot be quantified from these sources alone.

As of September 13, 2026: Control model: No verifiable evidence of a live Veda DAO, governance token, Snapshot/Tally deployment, public proposal process, or token-holder control of upgrades/parameters was found. Therefore, DAO governance is assessed as false; the observable model is company/role-controlled, not DAO-controlled. Voting concentration and top holders via Dune: Not verifiable as of September 13, 2026 (Dune MCP unavailable; no on-chain query or execution IDs). Company/control evidence: Veda Tech Labs Inc. identifies itself as a Delaware corporation in its Terms of Service and controls the Veda interface and protocol-related services.

The SEC Form D identifies the issuer as Veda Tech Labs Inc., incorporated in Delaware in 2024, SEC CIK 2027203. Named executive officers/directors are Stephanie Weichsel, Joseph Terrigno, Sunand Raghupathi, and director Evan Feng. A Delaware corporate registration number was Not verifiable as of September 13, 2026.

The Terms select New York law and mandatory individual arbitration. Contracts/funds: Veda documentation describes permissioned strategists and Manager/Merkle constraints over permitted destinations, functions, parameters, and ETH transfers. The current security page claims that arbitrary customer-fund transfers are unavailable, sensitive roles are timelocked, and emergency operators can pause activity but cannot redirect funds; these are unverified marketing claims, not independently verified contract facts. Proposal process, multisig, signers, threshold, independence, upgrade powers: Not verifiable as of September 13, 2026. No public signer set, threshold, timelock address/delay, DAO proposal mechanism, or independently confirmed admin architecture was located. Contradiction / risk callout: Veda’s marketing/security materials describe strong timelock and no-arbitrary-withdrawal controls, while the requested contract-level verification is unavailable.

These claims should not be treated as confirmed governance safeguards.

Assessment (as of September 4, 2026): Veda identifies the operating entity as Veda Tech Labs Inc., a Delaware corporation. SEC Form D filings identify incorporation in Delaware, formation in 2024, and principal addresses in New York/Delaware. The protocol is presented as non-custodial vault infrastructure, not as a broker-dealer or investment adviser.

Veda’s Terms expressly state that it is not registered with a governmental agency in another capacity and that certain vaults may rely on U.S. securities-law exemptions, including Regulation D or Regulation S, with possible accredited-investor/qualified-participant limits. ToS / restrictions: New York law governs; disputes generally require individual JAMS arbitration, with class-action and jury-trial waivers. Users must comply with applicable securities, commodities, banking, AML, privacy, and sanctions laws.

Restricted territories and sanctioned persons are excluded, VPN circumvention is prohibited, and users bear responsibility for legal eligibility, taxes, and transactions. Veda disclaims fiduciary duties and generally limits liability to $100. KYC/AML: The privacy policy states that Veda may conduct AML/CTF, identity, and address verification.

However, the public Terms indicate that eligibility and KYC requirements can be vault- or partner-specific; this is not clearly a universal protocol-level KYC regime. Permissioned/KYC-screened vaults are supported, but permissionless use remains contemplated. Classification / actual risk: Legal form and contractual disclaimers reduce—but do not eliminate—regulatory exposure.

Actual classification may depend on whether Veda or affiliates exercise control, provide transaction/custody functions, market yield products, or operate specific vaults involving securities, commodities, or investment-advisory activity. The non-custodial label is therefore not determinative. Warnings, enforcement, litigation, sanctions: No regulator enforcement action against Veda or Veda Tech Labs Inc. was identified in the reviewed SEC, sanctions, court, and public-search sources. The SEC materials located are policy/industry submissions, not enforcement.

No public court case or sanctions designation against the entity was identified. Protocol-level sanctions screening is not the same as the entity being sanctioned. Data protection: The policy references GDPR/UK GDPR, CCPA/CPRA, and Cayman Islands data-protection law; it covers wallet, device, IP, usage, and transaction data, international transfers, retention, access/erasure, and human review of significant automated decisions.

GLEIF LEI registry unavailable at scan time. OFAC SDN screening of 'Veda Tech Labs Inc', 'Veda': no match. SEC litigation and administrative release feeds: no mention.

Veda does not appear to issue its own stablecoin; the available evidence describes Veda as vault infrastructure that supports third-party stablecoins such as USDT, USDC, USDS, DAI, and related yield-bearing variants, including on Ethereum and Plasma. No verifiable evidence was found of a depeg event for a Veda-issued stablecoin, and because Veda is not identified as issuing one, depeg_count, last_depeg_date, and max_depeg_pct are not verifiable as of 2026-09-06. The protocol should be treated as stable in the narrow sense that it does not appear to have its own stablecoin issuance, but the stablecoin-used depeg question is not verifiable as of 2026-09-06.

Veda’s principal risks are concentrated in smart-contract correctness, privileged operations, cross-chain execution, accounting, and withdrawal liquidity. Public controls are substantial—audits, Merkle-authorized actions, rate bounds, delayed withdrawals, and a live bounty—but they reduce rather than eliminate loss risk. Current TVL, chain allocation, deployed addresses, and exposure split between Ethereum and Plasma are Not verifiable as of September 5, 2026 because on-chain verification was unavailable.

Veda’s top strengths are its multichain, protocol-agnostic vault infrastructure, its modular/minimal-core architecture, and its non-custodial design that keeps user funds in auditable smart contracts. It also stands out for configurable compliance and risk controls plus strong composability, letting vault shares plug into other DeFi primitives.

• Cross-chain reach: Veda is designed to work across multiple chains and ecosystems, including EVM, SVM, and MoveVM, which reduces dependence on any single network.
• Protocol-agnostic architecture: It sits above lending, DEX, and staking protocols, so partners can source yield from different venues without rebuilding their stack.
• Modular, minimal core: Independent commentary highlights a minimal, auditable core with modular delegation of strategy complexity, which improves maintainability and reviewability.
• Non-custodial, verifiable vaults: User assets remain in smart contracts and are viewable onchain, supporting transparency and reducing reliance on centralized custody.
• Compliance and composability: Veda supports whitelists, curator roles, and permissioned deposits for institutional guardrails, while vault shares can be used as collateral in other protocols, including Aave. Two additional strengths often cited are arbitrarily complex strategy support and developer tooling/white-label infrastructure, which make Veda attractive for institutions and app builders launching custom yield products.