{"id":1204,"date":"2026-01-14T16:23:22","date_gmt":"2026-01-14T14:23:22","guid":{"rendered":"https:\/\/ackee.xyz\/blog\/?p=1204"},"modified":"2026-01-14T16:29:13","modified_gmt":"2026-01-14T14:29:13","slug":"kamino-lend-fuzz-tests-summary","status":"publish","type":"post","link":"https:\/\/ackee.xyz\/blog\/kamino-lend-fuzz-tests-summary\/","title":{"rendered":"Kamino Lend Fuzz Tests Summary"},"content":{"rendered":"

Kamino Lend is a decentralized lending platform deployed on the Solana blockchain that enables users to lend and borrow assets with flexible terms and interest rates.<\/p>\n

Kamino engaged Ackee Blockchain Security to perform fuzz testing focused on the Kamino Lend protocol with a total time donation of 6 engineering days in a period between January 20 and January 30, 2025. Manual code review was not performed.<\/p>\n

Kamino then engaged Ackee Blockchain Security to perform a second fuzz testing round of the Kamino Lend protocol with a total time donation of 15 engineering days in a period between June 23 and July 28, 2025.<\/p>\n

Revision 2.1 was a review of the fixes of findings from the previous revision.<\/p>\n

METHODOLOGY<\/span><\/h2>\n

The fuzz testing followed this systematic approach:<\/p>\n

    \n
  1. Code and architecture analysis<\/strong>\n
      \n
    1. \n
        \n
      1. High-level review of the Solana program specifications, Rust sources, and instruction handlers to understand the program\u2019s size, scope, and functionality.<\/li>\n
      2. Analysis of Solana program entry points to identify instruction processors, account validation logic, and critical operations.<\/li>\n
      3. Comparison of the Rust implementation and given specifications, ensuring that the program logic correctly implements everything intended.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n
      4. Fuzz testing with Trident<\/strong>\n
          \n
        1. Interface Analysis<\/strong>\n
            \n
          1. Detailed examination of Solana instruction handlers and their account parameters<\/li>\n
          2. Identification of Program-derived Addresses (PDAs), account ownership, and cross-program invocation patterns<\/li>\n
          3. Mapping of account state transitions and Solana runtime data flows<\/li>\n<\/ol>\n<\/li>\n
          4. Initial behavior exploration<\/strong>\n
              \n
            1. Writing simple Trident fuzz tests to observe Solana program instruction execution<\/li>\n
            2. Understanding account validation constraints and Solana runtime limitations<\/li>\n
            3. Identifying unexpected program behaviors, panics, or edge cases in instruction processing<\/li>\n<\/ol>\n<\/li>\n
            4. Invariant definition<\/strong>\n
                \n
              1. Writing invariants based on expected Solana program properties and account state requirements<\/li>\n
              2. Defining security-critical conditions for account ownership, balance constraints, and authority validation<\/li>\n
              3. Establishing assertions for account state consistency and program-derived address integrity<\/li>\n<\/ol>\n<\/li>\n
              4. Complex stateful fuzz testing <\/strong>\n
                  \n
                1. Writing complex Trident fuzz tests that model stateful interactions across multiple Solana instructions<\/li>\n
                2. Testing transaction sequences and their effects on account states and program data<\/li>\n
                3. Exploring interdependencies between instruction handlers and cross-program invocations<\/li>\n<\/ol>\n<\/li>\n
                4. Extended fuzz testing campaigns<\/strong>\n
                    \n
                  1. Running extended Trident fuzz testing campaigns to explore all edge cases in instruction execution<\/li>\n
                  2. Allowing the fuzzer to explore deep account state combinations and program execution paths<\/li>\n
                  3. Maximizing Rust code coverage and Solana instruction handler path exploration<\/li>\n<\/ol>\n<\/li>\n
                  4. Dashboard analysis<\/strong>\n
                      \n
                    1. Continuous analysis of the Trident fuzz testing dashboard throughout the process<\/li>\n
                    2. Monitoring for program panics, instruction failures, and Rust code coverage metrics<\/li>\n
                    3. Identifying patterns that indicate potential Solana program vulnerabilities or runtime issues<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n
                    4. Vulnerability assessment<\/strong>\n
                        \n
                      1. Classification of discovered Solana program issues by severity and impact on protocol security<\/li>\n
                      2. Development of proof-of-concept transaction sequences for critical findings<\/li>\n
                      3. Recommendations for Rust code remediation based on Trident fuzz testing results<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

                        SCOPE<\/span><\/h2>\n

                        The fuzz testing was performed on commit 829c1f3<\/code> and the scope was the following:<\/p>\n