Skip to main content
Offer yield on Veda’s BoringVault strategies through Privy earn. Your app deposits, withdraws, and reads positions through the standard earn API, and Privy handles the Veda-specific contract interactions (Teller, Accountant, and BoringVault share token) for you.
Veda vaults are an Enterprise plan feature. Veda deploys and operates the vault contracts, and Privy registers them for your app — there is no self-serve vault deployment. Contact [email protected] to enable a Veda vault for your app. Once registered, the vault appears under Wallet infrastructure > Earn in the Privy Dashboard, where you can view its vault ID and details.
Before your vault is deployed, create a Privy wallet in the app that will use the vault, and share its address with Veda. This wallet will receive vault performance fees, and its address is embedded in the vault’s parameters at deployment, so the wallet must exist first.

​
Resources

Veda Docs

Official documentation for Veda and the BoringVault architecture.

Earn

Deposit, withdraw, and track positions across yield vaults with a single API.

​
How Veda works with Privy

Veda is served through Privy’s native earn API. Once a Veda vault is registered for your app, you interact with it through the standard earn endpoints — pass a vault_id to the deposit, withdraw, position, and vault-details endpoints. Under the hood, Veda differs from an ERC-4626 vault in a few ways:
  • BoringVault share token. A Veda vault is a BoringVault: the vault contract is also its own ERC-20 share token. It is not ERC-4626, so there is no fee-wrapper contract — the vault you deposit into is the underlying vault itself.
  • Teller entry point. Deposits and withdrawals route through a Teller contract, and pricing comes from an Accountant contract rather than ERC-4626’s convertToAssets. Privy handles all of this internally.
  • Instant deposits and withdrawals. Both operations settle synchronously in a single transaction.
  • Rewards auto-compound. Veda compounds reward incentives into the vault’s share price automatically. There is no separate incentive claim step for Veda vaults.
  • Share lock period. After a deposit, shares are locked for a short, vault-configured period. Withdrawals revert until the lock expires.
Because Veda goes through the standard earn API, the earn product docs — deposit, withdraw, get vault details, get vault position, and webhooks — all apply to Veda vaults. This guide highlights what’s specific to Veda.

​
Supported chains

Veda vaults are available across major EVM chains, including Ethereum, Base, Tempo, Arbitrum, Optimism, and Linea. Contact [email protected] for the current list of enabled vaults and chains for your app.

​
Read vault details and positions

Read vault APY and TVL with get vault details, and a wallet’s position with get vault position. A few fields behave differently for Veda:
For Veda vaults, user_apy, app_apy, and tvl_usd are sourced from Veda’s analytics API and may be null — most commonly for a newly enabled vault, whose performance data takes roughly 7–10 days to populate. Your app should handle null gracefully rather than rendering 0. available_liquidity_usd is always null for Veda vaults.
For Veda vaults, total_deposited and total_withdrawn are computed from the deposits and withdrawals initiated through Privy, not reconstructed from all onchain activity. They are accurate as a cost basis for Privy-initiated positions. assets_in_vault and shares_in_vault are always read live from the vault contract.

​
Withdraw with accrued yield

Withdrawals redeem shares back to assets — plus accrued yield — via the withdraw endpoint. Withdraw up to the wallet’s current assets_in_vault; for a full exit, read the position first and pass assets_in_vault as raw_amount.
Veda locks a wallet’s shares for a short, vault-configured period after each deposit, and a new deposit resets the lock on the entire position. A withdrawal requested while shares are still locked is rejected before any transaction is broadcast, with an error indicating when the shares unlock. Wait until the lock expires (or surface the unlock time to your user) before retrying.
A rejected status means the action failed before any transaction was signed — for example, insufficient shares or a still-locked position — and is safe to retry once the underlying condition clears. A failed status means a transaction was broadcast but reverted onchain; inspect the action’s steps for details.

​
Key integration tips

  1. No incentive claim. Veda auto-compounds rewards into the share price. Do not call the incentive claim endpoint for Veda vaults; yield shows up directly in assets_in_vault.
  2. Respect the share lock. Gate your withdraw UI on the lock, especially right after a deposit. Handle the rejected status and its unlock timestamp instead of assuming an immediate withdrawal will succeed.
  3. Handle null analytics. Treat user_apy, app_apy, and tvl_usd as optional — render a fallback while a newly enabled vault’s data populates.
Privy does not control DeFi vaults or underlying protocols. Vault information is provided for reference only and may change or be inaccurate. Earnings are generated from third-party vaults and are not guaranteed. Using vaults involves risk, including loss of funds. These materials are for general information purposes only and are not investment advice or a recommendation or solicitation to engage in any specific transaction. You are responsible for evaluating vaults at your own discretion. Privy does not provide investment, financial, legal, or tax advice.