Security & Responsible Disclosure

Last updated: 28 October 2026 | Applies to: Testnet

The short version

• Vanna runs on Testnet only, on Solana and Stellar. Testnet Assets have no value.
• Each Account sits under one health factor. On Testnet, new borrowing and moves are allowed only while the Account stays above 1.10, which is also the liquidation line; the app adds a 1.15 buffer.
• We have completed an internal security review of the Testnet contracts and an economic risk assessment. External audits are planned, and we will publish each report here when it is complete. Until then, the Protocol has not been externally audited.
• Found a vulnerability? Email hello@vanna.finance with "Security" in the subject line, and keep it private until we have fixed it.
• If you follow this policy in good faith, we will treat your research as authorised and will not take legal action against you.
• There is no bug bounty on Testnet. Any reward is a discretionary thank-you. We plan a formal bug bounty for mainnet.
• We will never ask for your seed phrase, private key or sign-in code.

1. How Vanna manages risk

Vanna lets you borrow more than you deposit, so the Protocol has to be able to see, price and, if needed, close everything in an Account. This section explains how it is designed to do that. The parameters describe the current Testnet and can change before mainnet.

Testnet code is still changing. This section describes how the Protocol is designed to work. Until external audits are published, do not rely on it as a guarantee of how the deployed Testnet contracts behave in every case.

1.1 One health factor

Every Account has one health factor: the value of everything in the Account, including collateral and the positions bought with borrowed funds, divided by what the Account owes. The risk engine is designed to check it before any action that adds risk, such as a borrow, a withdrawal or a new position, and to reject a transaction that would leave the Account below the required level.

• Borrowing line: 1.10. New borrowing, withdrawals and moves to approved venues are allowed only while the Account stays above 1.10. Our apps add a 1.15 buffer (section 1.2).
• Liquidation line: 1.10. At or below this level, an Account with debt can be liquidated. On the Stellar Testnet, a liquidation is full: the liquidator takes all remaining collateral.

1.2 Liquidation buffer

In the Protocol, the borrowing line and the liquidation line are both 1.10, so there is no on-chain buffer between borrowing and liquidation. An Account can borrow until it is just above 1.10, where a small price move or a little interest can take it to the liquidation line. Our apps add a 1.15 buffer: the room that prices can move, and interest can build up, before liquidation is possible. It gives you time to react, by adding collateral, repaying debt or closing positions. The app buffer does not cover transactions sent to the smart contracts another way, and a fast market can still cross it before you act.

1.3 Track Tokens

When borrowed funds go to an approved outside protocol, the position stays in the Account and counts in its health factor. The design is that a position opens only if the risk engine can see it, price it and liquidate it.

On the Stellar Testnet, Blend lending positions are recorded with a Track Token, an internal record of the position, not a Vanna token. Liquidity positions on Aquarius and Soroswap are counted, conservatively, from the pool tokens the Account holds. Both are valued with the venue's own data, such as exchange rates and pool reserves, and with asset prices from the Reflector oracle. On Stellar, extending this to perpetuals and other markets is in development.

1.4 Oracle prices

The Protocol values collateral, positions and debt with third-party price feeds: Kamino Scope on Solana, with Pyth as a fallback, and Reflector on Stellar. It is designed to stop a transaction that depends on a price when no usable price is available, rather than go ahead on a bad one. On the current Stellar Testnet, the Protocol uses Reflector's spot price, not a time-weighted average, and treats a price more than 10 minutes old as stale. If a feed has no fresh price, it can use a fallback price that we set, for up to 24 hours. Our Risk Disclosures explain how prices can go wrong.

1.5 Secured credit

On both the Solana and Stellar Testnets, the smart contracts keep borrowed funds inside the Account: they can move only to approved venues, not to an outside wallet, including yours. Withdrawals go only to your own wallet, and only if the Account stays above 1.10 afterwards. After each borrow and each move to a venue, the Protocol is designed to check the Account's health again and cancel the transaction if it would be at or below 1.10. On Solana this check cannot be switched off. On the Stellar Testnet, the admin can switch it off, so it may not always run. The admin can also approve new venues and upgrade the code, often with immediate effect (see our Risk Disclosures). This is how the Protocol lends more than you deposit while everything in the Account backs the loan.

1.6 Who builds and reviews the code

Vanna's smart contracts are led by co-founder Vatsal Salkiya, an Immunefi All-Star security researcher who has worked with five-plus audit firms, including Halborn and Cantina. On Immunefi he has made 27 submissions, 6 of them critical.

We will publish each full audit report here, with the status of each finding. Until then, please do not describe the Protocol as audited.

1.7 What we don't claim

• No review or audit removes all risk, and Testnet software can contain bugs.
• No protocol can promise that a position will never be liquidated. Vanna's tools aim to help you act earlier.
• Positions held at outside venues remain subject to those venues' own margin and liquidation rules.
• Hedged does not mean risk-free. Leverage magnifies losses as well as gains.

For how the Protocol works, see our docs and the liquidation guide. For the risks of using it, see our Risk Disclosures. Background reading: how composable credit works and cross margin vs isolated margin.

2. Responsible disclosure

We welcome reports from anyone who finds a weakness in our Services or the Protocol.

Ordinary bugs, such as something broken or confusing, can go to the app, our Telegram or hello@vanna.finance, as our Testnet & Rewards Terms explain. Anything that could let someone take or lock funds, get around a limit, act for another user or see their data is a security issue. Report it privately, as this section explains.

2.1 In scope

Our own integrations with Third-Party Services are in scope, for example how our contracts read a venue's or an oracle's response, and how Copilot handles content it did not write.

2.2 Out of scope

• Third-Party Services themselves: venues (Kamino, Jupiter, Phoenix, Blend, Soroswap, Aquarius), bridges such as Circle CCTP, wallets, our sign-in provider (Dynamic), oracles (such as Kamino Scope, Pyth and Reflector), RPC providers, our hosting and email providers, and the AI model behind Copilot. Report those to the provider.
• Any mainnet deployment, ours (when it exists) or anyone else's, and any test that involves funds you do not own.
• Social engineering, phishing and physical attacks on our team, contractors or users.
• Denial of service, spam, load testing, or anything that degrades the Services for others.
• Low-impact findings without a working exploit: scanner output, missing headers or cookie flags, SPF, DKIM or DMARC settings, clickjacking on pages with no sensitive action, self-XSS, logout CSRF, version disclosure.
• Getting around geo-blocking or other access restrictions, for example with a VPN. Our Terms of Use prohibit it.
• Points and Rewards abuse, such as farming, multiple accounts or referral gaming, unless it comes from a technical vulnerability. See our Testnet & Rewards Terms.
• Attacks that need privileged or admin keys, unless you show how an attacker could get them.
• Copilot prompts that only change what it says. A report must show a security impact: an unauthorised action, a guardrail bypass, or exposure of data.
• Manipulating a Third-Party Service's market or oracle. How the Protocol responds to wrong or stale prices is in scope.

2.3 How to report

Email hello@vanna.finance with "Security" in the subject line.

This is our general inbox. If you prefer, send a short summary first, without exploit details, and we will arrange a private way to share the rest.

Do not report vulnerabilities through GitHub issues, X, Telegram or any other public channel.

Include as much of the following as you can:

• the affected asset: contract or program address, URL, API endpoint, or app version;
• the network (Solana or Stellar) and any Testnet transaction hashes;
• what the issue is and what an attacker could achieve;
• step-by-step instructions to reproduce it;
• a proof of concept, such as code, a script or a test;
• your view of the severity;
• whether anyone else knows about it;
• how you would like to be credited, if at all.

If you see an attack in progress, make the subject line "Security URGENT". Reports in English are preferred.

We use the personal data in your report to handle it, to check whether you can receive a reward, and, with your permission, to credit you. If an issue affects a Third-Party Service, we may share the technical details with that provider so it can fix the issue. We will not share your name or contact details with them unless you agree or the law requires it. See our Privacy Policy.

2.4 What to expect

We assess severity on a four-level scale (Critical, High, Medium, Low), based on what the issue would mean if the same code held real funds.

These are targets, not guarantees. On Testnet, a fix may mean redeploying contracts or resetting Testnet balances. We will tell you when your issue is fixed and, with your permission, credit you publicly.

2.5 Safe harbour

If you follow this policy in good faith:

• we will consider your research authorised, including for the purposes of computer misuse and anti-hacking laws;
• we will not bring legal action against you, or ask law enforcement to act against you, for that research;
• we will not bring a claim against you under anti-circumvention laws for research on our own software, such as reverse engineering our app code. This does not cover geo-blocking, or anything that protects other users' Accounts or data;
• we waive, on a limited basis, any restriction in our Terms of Use and Testnet & Rewards Terms that would otherwise prohibit that research, such as rules on reverse engineering, automated access or using bugs. This waiver does not cover our rules on Restricted Jurisdictions, sanctions or geo-blocking. Points or Testnet Assets gained through research do not count, and we may remove them;
• if a third party takes legal action against you over research that followed this policy, we will make it known that you acted under it.

If you break this policy by accident and tell us straight away, we will still treat you as acting in good faith.

We cannot authorise testing of Third-Party Services, and we cannot bind third parties or public authorities. This safe harbour applies to the extent permitted by law. It does not stop us meeting our own legal duties, such as reporting a personal data breach to a regulator. If you are unsure whether something is allowed, ask us at hello@vanna.finance, with "Security" in the subject line, before you go ahead.

Good faith means you:

1. Act to find and report, not to harm or profit. Do no more than you need to show the issue exists. Do not keep access, plant backdoors, or move on to other systems.
2. Take no data. Do not view more than you need, and do not download, copy, change, delete, keep or share data that is not yours. If you reach personal data or another user's Account, stop and tell us. Delete what you obtained once we confirm we have your report.
3. Test only on Testnet, with your own resources. Use your own Accounts, wallets and Testnet Assets. Never test against mainnet funds, other users or their positions. If a test could move shared Testnet pools or prices, run it on a local deployment or fork.
4. Do not extort. Do not demand payment, or threaten to disclose or use an issue, in return for its details.
5. Keep it confidential until it is fixed. Do not share details with anyone until we confirm a fix and agree a disclosure date with you. A Testnet redeploy or reset is not a fix if the same code is going to mainnet. If we have not fixed a valid issue within 90 days, we will agree a date with you in good faith.
6. Stay within the law and this policy. Do not degrade the Services or get around geo-blocking. If you are a Restricted Person, which includes US Persons, do not use the Interface or the Testnet for research. You can still report what you find another way, for example by reviewing code or testing a local deployment.

2.6 Rewards on Testnet

There is no bug bounty on Testnet. For significant findings, we may thank you with public credit, a reward, or both. Whether we do, and the amount, form and timing of any reward, are for us to decide. We take into account severity, report quality, and what the issue would mean if the same code held real funds.

We will only consider a reward if:

• you are the first to report the issue, and it is not already known to us, for example from our internal review (we will tell you if it is);
• you followed this policy;
• you are not one of our team members or contractors, a member of their family, or anyone engaged to review the same code;
• you pass our identity and sanctions checks; and
• you are not a Restricted Person (see Restricted Jurisdictions). Being a US Person does not on its own rule you out, but only for a finding you made without using the Interface or the Testnet, for example by reviewing code or testing a local deployment.

We will not pay a reward, directly or through anyone else, where that would breach sanctions or any other law. You are responsible for any taxes on a reward.

Nothing in this section is an offer of a reward, and it does not create a right to payment. Our safe harbour in section 2.5 does not depend on whether we pay a reward.

We plan to launch a formal bug bounty, with published reward tiers, for mainnet.

3. Staying safe

3.1 Official links

Use only these:

Emails from our team come from an @vanna.finance address.

3.2 What we will never do

• message you first on X, Telegram or any other social platform to offer support, an airdrop, a token sale or help with your wallet;
• ask for your seed phrase, recovery phrase, private key or email sign-in code;
• ask you to "validate", "sync" or "unlock" your wallet, or to approve a transaction outside the Interface;
• ask you to send Digital Assets to anyone in order to receive a reward, refund or airdrop.

3.3 Protect yourself

• No token. Vanna has no token, and Points are not a token. Treat any "Vanna token" sale or Vanna airdrop as a scam.
• No real funds. Testnet needs none. Never send real Digital Assets to a Testnet address.
• Verify before you sign. Check the URL before you connect a wallet, and check contract addresses against the list in our docs. If a request to sign, approve or transfer is unexpected, reject it.

To report an impersonation account, fake site or scam, email hello@vanna.finance, as our Brand & Trademark page explains.

3.4 If there is an incident

If a security incident affects the Services, we will post updates on X (@vannaprotocol), on our Telegram channel and on this page, and in the web app where we can. Each update will say:

• what happened and what is affected;
• what you should do, if anything;
• what we are doing;
• when to expect the next update.

On Testnet, we may pause features, redeploy contracts, or reset Testnet balances or Points. See our Testnet & Rewards Terms.

Our incident updates will never ask you to send funds, share secrets, or use a "recovery" or "migration" site. Scammers copy incident news.

After a significant incident, we aim to publish a report once it is fixed: the cause, the impact, the fix, and what we changed. If an incident involves personal data, we will notify regulators and affected people where the law requires. See our Privacy Policy.

4. Changes to this page

We may update this page. The date at the top shows when it last changed. A report you made before a change is handled under the version that applied when you made it. Questions about this policy: hello@vanna.finance, with "Security" in the subject line.