Security
Formal verification, audits, stress testing, and more
| 18 External Audits | 4 Formal Verifications Completed | 3 Years Live in Production Without Incident |
|---|---|---|
| View Audits | View Formal Verifications | Go To Github |
Overview
Security extends across Kamino’s entire stack. From code correctness and smart contract verification, to code upgrades, transaction monitoring, market risk monitoring, and parameter stress testing. For Kamino, security is a continuous process of proactively considering threats across the entire protocol stack, while staying on top of industry best practices. We place extreme emphasis on layering security measures. Even if a single layer fails, additional security layers act as a safety net—the more layers, the better. Our battle scars have taught us that not even the best engineers and auditors are guaranteed to foresee every possible attack vector. No single security measure is absolutely bulletproof, so we take every step to cover as wide a surface area as possible. As time goes by, live production usage of Kamino battle tests the stack, revealing new ways for us to protect the smart contracts, and the rest of Kamino’s security system.Security Components
Kamino’s stack is composed of multiple components, each with its own security considerations:| Component | Description |
|---|---|
| Smart Contracts | Kamino Lend and Peripheral Contracts |
| Frontend | Kamino App, Web UI, Client Libraries |
| Middleware | API, Databases, Cron Jobs, etc. |
| Risk Monitoring | Risk Dashboard, Risk Consultants, Risk Curators |
| Operational Infrastructure | Cranks, Bots, Keepers, Liquidators |
| Third Party Dependencies | Libraries, Oracles, Exchanges, Price Feeds |
Although only the smart contracts hold funds, all components play a role in the overall security of the system, and therefore we approach security holistically, considering all components and their interactions. Below we cover all security measures employed by Kamino, including audits, formal verification, testing, and more. I’m
Security Measures
- Open Source
- Formal Verification
- Bug Bounty
- Security Audits
- Oracle Security
- Redundancy & Fallbacks
- Liquidation Stress Tests
- Market Risk
- Fuzzing (By Ackee)
- Verifiable Build
- Disclaimer
Open Source
Kamino Lend has been open source since its inception, allowing the community to review the codebase, and allowing users a transparent overview of the smart contract logic handling their funds. This is a critical component of Kamino’s security strategy, and we consider it a must-have for any DeFi protocol. Open source code allows for transparency, community contribution, and peer reviews, which can help identify potential vulnerabilities and improve the overall security of the system.Formal Verification
While testing and auditing are probabilistic approaches to security, for example an edge case can be missed or forgotten to be checked, formal verification is a mathematical approach that proves the correctness of the code. We use formal verification to prove that specific properties hold for our smart contracts, such as the inability to borrow more than the collateral provided or the inability to liquidate a position that is not undercollateralized. This provides a high level of assurance that our smart contracts behave as intended.| Report | Date | Link |
|---|---|---|
| Ottersec Formal Verification - Kamino Lend | 6 October 2025 | View Report |
| Certora Verification - Kamino Earn Vaults | 27 June 2025 | View Report |
| Certora Verification - Kamino Lend | 13 May 2025 | View Report |
| Certora Verification - Kamino Limit Orders | 21 February 2025 | View Report |
Bug Bounty ($1.5M)
Kamino has a $1.5M bug bounty program that rewards security researchers for finding and reporting vulnerabilities in the codebase. This is an important part of Kamino’s security strategy, as it allows us to leverage the expertise of the wider community to find and fix issues before they can be exploited.Security Audits
Full code audits are performed before the launch of a new smart contract and periodically for existing contracts. We use security teams that have proven track records in the industry to review our codebase and identify potential vulnerabilities. The auditors try to find cases based on their practical experience and fully review the entire codebase.| Total Audits | Auditors | Critical Vulnerabilities |
|---|---|---|
| 18 | 5 | 0 |
Kamino Lend
Lend Smart Contract| Report | Date | Link |
|---|---|---|
| Sec3 Audit - Kamino Lend | 6 February 2025 | View Report |
| OtterSec Audit - Kamino Lend | 6 September 2023 | View Report |
| Certora Verification - Kamino Lend | 21 February 2025 | View Report |
| RX Audit - Kamino Lend | 3 July 2023 | View Report |
Kamino Earn Vaults
Earn Smart Contract| Report | Date | Link |
|---|---|---|
| Sec3 Audit - Kamino Vaults | 6 February 2025 | View Report |
| Offside Labs Audit - Kamino Vaults | 12 April 2025 | View Report |
| OtterSec Audit - Kamino Vaults | 9 December 2024 | View Report |
| Certora Verification - Kamino Vaults | 27 June 2025 | View Report |
Scope Oracle
Scope Smart Contract| Report | Date | Link |
|---|---|---|
| Sec3 Audit - Scope | 16 December 2024 | View Report |
| OtterSec Audit - Scope | 16 December 2023 | View Report |
| Offside Labs Audit - Scope | 8 December 2023 | View Report |
Liquidity Vaults
Liquidity Vaults Smart Contract| Report | Date | Link |
|---|---|---|
| OtterSec Audit - Liquidity Vaults | 14 November 2023 | View Report |
Farms
Farms Smart Contract| Report | Date | Link |
|---|---|---|
| OtterSec Audit - Farms | 13 October 2023 | View Report |
| Offside Labs Audit - Farms | 8 December 2023 | View Report |
Limit Orders
Limit Orders Smart Contract| Report | Date | Link |
|---|---|---|
| Sec3 Audit - Limit Orders | 29 January 2025 | View Report |
| OtterSec Audit - Limit Orders | 7 November 2024 | View Report |
| Offside Labs Audit - Limit Orders | 29 November 2024 | View Report |
| Certora Verification - Limit Orders | 13 May 2025 | View Report |
Rolling Code Audits
Rolling code audits are a continuous process of reviewing the codebase as it evolves. We have ongoing contracts with security teams that review new Pull Requests (PRs) and changes to the codebase. This ensures that any new code is reviewed for security vulnerabilities before it lands in production.Oracle Security & Resilience
Oracles are a critical component of our system, as they provide the price feeds and other data that our smart contracts rely on. We use multiple oracles to ensure that we have redundancy and can mitigate the risk of a single point of failure. We also monitor the oracles for anomalies and have mechanisms in place to switch to backup oracles if necessary. Oracle Providers:- Chainlink
- Pyth Network
- Switchboard
- Redstone
- Kamino Scope
| Audits Completed | Volume Processed | Oracle Exploits |
|---|---|---|
| 8 | $19.33B | 0 |
Redundancy & Fallbacks
A complex system fails due to the unexpected failure of one of its many moving parts. We recognise this, and use many layers of redundancy for as many components and dependencies as possible. This is especially important for liquidators, oracle cranks, rebalancing bots, and other automated processes that interact with our smart contracts, live off-chain, or have third-party dependencies. We have implemented redundancy and fallbacks to ensure that if one component fails, another can take over. This includes multiple oracles, multiple liquidators, multiple cranks, and multiple RPCs. We also have mechanisms in place to detect and respond to failures as fast as possible.- RPC Redundancy
- Cloud Provider Redundancy
- Oracle Redundancy
- Liquidator Redundancy
- Oracle Crank Redundancy
Liquidation Stress Tests
While testing in the local environment is a good first step, it does not fully replicate the conditions of the mainnet. Things like RPC failures, congestion, priority fees, and other real-world conditions can impact the performance of Kamino’s system. Therefore, we perform stress testing in a live environment to ensure that our system can handle the load and respond quickly to changes in the market. This includes testing the system under high load, simulating falling prices and liquidations to see how quickly the system can respond, and testing the system’s ability to handle large volumes of transactions. This is not something that can be done in a local environment. Kamino has spent thousands of dollars on live stress tests.| Liquidations Volume | # Liquidations | Bad Debt |
|---|---|---|
| $120M+ | 100k+ | $0 |
| Report | Date | Link |
|---|---|---|
| Liquidations Report - $4.5M Liquidated | 18 February 2025 | View Report |
| Internal Liquidations Stress Test Report | 14 February 2025 | View Report |
Market & Protocol Risk Assessment
Kamino has a dedicated team of risk consultants and curators who monitor the market and protocol risks associated with the protocol’s system. These contributors assess the risks of different assets, market conditions, and potential vulnerabilities in the protocol. This helps us to proactively identify and mitigate risks before they can impact the system.Fuzzing (By Ackee)
Fuzzing is a technique used to find vulnerabilities in our code by providing random or unexpected inputs to the system. We instrument instruction handlers end-to-end to run fuzzing as large-scale property based tests, run invariants on an entire protocol level, and detect regressions between different versions.| Report | Date | Link |
|---|---|---|
| Ackee Blockchain Kamino Lend Fuzz Tests Report | 22 September 2025 | View Report |