Skip to main content

​
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: 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.

​
Security Measures

​
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.

​
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.

​
Kamino Lend

Lend Smart Contract

​
Kamino Earn Vaults

Earn Smart Contract

​
Scope Oracle

Scope Smart Contract

​
Liquidity Vaults

Liquidity Vaults Smart Contract

​
Farms

Farms Smart Contract

​
Limit Orders

Limit Orders Smart Contract

​
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
View Scope Smart Contract

​
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.

​
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.

​
Verifiable Build

In addition to being open source and formally verified, Kamino Lend and Kamino Earn have been Verifiably Built. Verified builds ensure that the executable program deployed on Solana network is cryptographically proven to match Kamino’s audited source code. This means that the program running onchain corresponds exactly to Kamino’s audited source code, enhancing trust and transparency.

​
Disclaimer

The information on this page is provided for informational purposes only and should not be interpreted as a warranty or guarantee. While Kamino implements rigorous security measures, no system can be fully immune to risk. For more details, please refer to our Terms & Conditions.