Kamino Bug Bounty Rules

1 Overview and at a glance

Kamino unifies lending, liquidity and leverage on Solana. This program rewards reproducible vulnerabilities affecting covered production systems. Rewards reflect demonstrated impact and a feasible exploit.

• Prove a real production risk. Reports must affect an in-scope asset and demonstrate an eligible impact from realistic production states. Critical and High findings must demonstrate funds at risk. Any on-chain attack must be feasible under actual Solana execution conditions.

• Eligibility comes before severity. A serious impact does not override scope, exclusions or proof requirements.

• No minimum payouts. Percentage rewards are capped and use the amount actually at risk before effective intervention, not total exposed balances.

• One underlying vulnerability, one reward. Multiple impacts or markets do not multiply the bounty.

• Report safely through Sherlock. Do not harm users or exploit live systems to establish impact.

2 Severity and rewards

All amounts are in USD. For percentage-based rewards, the payout is the lower of the calculation and the applicable cap. There are no guaranteed minimums.

Eligible impact	Reward	Cap per vulnerability
Smart-contract theft or fraudulent extraction of principal, unclaimed yield or rewards	10% of funds at risk	$1,000,000
Smart-contract irreversible loss, destruction or permanent freezing of principal, unclaimed yield or rewards	5% of funds at risk	$100,000
Web/app theft — Critical	10% of funds at risk	$100,000
Other web/app Critical or High impacts, excluding temporary disruption	Amount assessed case by case	Critical: $100,000; High:$50,000
Temporary freezing or material operational disruption, smart contracts or web/app	Payment and amount discretionary	$10,000

Bad debt and wrongful liquidations use the applicable smart-contract category according to the demonstrated outcome. They do not create separate rewards.

Smart-contract rewards follow the financial outcome in the table, including for unclaimed yield and rewards; a severity label does not introduce a separate minimum, rate or payment.

Web and app impact levels

Critical: theft, malicious wallet transactions or unauthorized financial actions on another user’s behalf. Command execution on production servers or exposure of sensitive production secrets qualifies at this level only where the report demonstrates a feasible path to a Critical financial impact.

High: persistent content tampering or takeover of an in-scope subdomain only where the report demonstrates a feasible path that places funds at risk and does not establish a Critical outcome. These mechanisms alone do not establish High severity.

Critical and High classification requires demonstrated funds at risk; a hypothetical link to financial harm is insufficient. Confidential user-data disclosure and unauthorized changes to sensitive non-financial user details are not eligible Critical or High impacts in themselves. Classification follows the demonstrated financial outcome, not the technical mechanism. For eligible non-theft findings, Kamino determines the amount within the cap from impact, exploit prerequisites, affected users, duration and recoverability. This discretion concerns the amount, not eligibility.

Temporary freezing and outages

A freeze recoverable through a contract upgrade is temporary. Pure outages do not qualify as Critical solely because an application is unavailable, and do not make all deposits funds at risk. The $10,000 discretionary category uses duration, affected users, workarounds and recovery difficulty; no percentage-of-funds calculation applies. Additional theft or irreversible loss is assessed under the applicable category.

Other discretionary awards

Kamino may award up to $2,000 per report for useful findings outside standard eligibility, including non-exploitable bugs, artificial-state reports and bugs facilitating excluded social engineering.

For a genuine out-of-scope finding with demonstrated High or Critical impact, Kamino may choose a larger award. Both payment and amount are entirely discretionary. Normal reward formulas and caps are indicative benchmarks only for this exception.

Neither discretionary category creates an entitlement or precedent, or replaces the standard reward for an otherwise eligible finding.

Funds at risk

Funds at risk is the maximum amount demonstrably extractable, irreversibly lost or permanently frozen through the reported vulnerability before effective intervention. Assess the applicable outcome using conditions at submission.

The intervention window is determined case by case from the relevant detection and mitigation capabilities then in place, including detection, response and the time to make mitigation effective. Count feasible cumulative exploitation during that window, including the full amount lost atomically or before intervention could take effect.

Total TVL, contract balances and allocated rewards do not themselves establish funds at risk. For yield or reward impacts, count only affected unclaimed yield or rewards, excluding principal and projected accrual beyond the window.

USD valuation

Use the average USD token price over the seven days immediately preceding submission, or available trading history if shorter. Average prices, not balances, and exclude exploit-induced distortions. For an independent depeg already present at submission, use the lower of that average and the reliable price at submission. Valuation determines the reward amount, not eligibility.

Multiple impacts and markets

For multiple eligible impacts from one vulnerability, use the highest applicable calculated reward, not the sum. Discretionary caps are not guaranteed amounts.

Across multiple covered markets, aggregate only funds jointly reachable before intervention, accounting for funding and timing constraints. Do not double-count funds; apply the rate and cap once.

3 Scope

Chain: Solana mainnet. Only the following program deployments and web domains are covered, subject to the production, dependency and integration rules below. Primacy of Impact does not apply.

Product	Mainnet program address	Source reference
Kamino Liquidity	6LtLpnUFNByNXLyCoK9wA2MykKAmQNZKBdY8s47dehDc	Closed source; deployed program is the scope reference. SDK for interaction only.
KLend	KLend2g3cP87fffoy8q1mQqGKjrxjC8boSyAYavgmjD	klend
KFarms	FarmsPZpWu9i7Kky8tPN37rs2TpmMrAZrC7S7vJa91Hr	kfarms
KVault	KvauGMspG5k6rtzrqqn7WNn3oZdyKqLKwK2XWQ8FLjd	kvault
Scope	HFn8GnPADiny6XqUoWE8uRPPxb29ikn4yTuPa9MF2fWJ	scope

Web domains: app.kamino.finance and kamino.com. Other domains and hosts are not included.

Scope’s interface code is covered as part of Scope without separate interface listings. This does not independently bring third-party programs into scope. Kamino Liquidity remains closed source; no contract source or source reference will be supplied.

Production requirements

Listed programs remain covered through production upgrades under the same address. New program addresses require explicit inclusion. Assessment uses the deployment and conditions at submission.

Covered production instances are markets or vaults officially listed and accessible through Kamino’s normal user-interface workflow. Test, experimental and otherwise unlisted instances are out of scope, even when deployed on mainnet or accessible by explicitly supplying a public key, URL parameter or direct link. Such access does not make an instance a covered production instance. Disabled features, including disabled referral fees, and hypothetical future configurations do not qualify unless an unprivileged attacker can demonstrably reach the vulnerable state from production.

4 Proof requirements and safe testing

Smart contracts

Provide a working, reproducible PoC on a local Solana validator or a full-featured test execution environment such as LiteSVM. Signature verification and relevant transaction and runtime checks must be enabled.

Starting accounts must faithfully represent mainnet production data, balances, owners, authorities and configuration. The attack must be realistically executable on Solana: demonstrate feasible funding, permissions, preparation steps and compliance with relevant transaction and runtime constraints. For attacks relying on observing, front-running, back-running or sandwiching a victim transaction, substantiate how the attacker obtains the necessary information and can achieve the required ordering through a submission route available under the production conditions at submission. Merely arranging transactions in the desired order in a local test does not prove that the attack is feasible.

An attacker-reachable vulnerable state need not have occurred previously on mainnet. Reproduce the transactions leading to it. Directly editing accounts, inventing balances or authorities, bypassing checks or assuming excluded privileged actions does not establish eligibility.

Web and app

Provide reproducible browser steps, HTTP requests or a script demonstrating impact against the deployed configuration or faithful production test conditions. Editing your own browser display or disabling checks is not proof of a vulnerability. Pure web findings need neither a Solana validator nor mandatory exploit code where browser or request-based reproduction is sufficient.

For any claimed on-chain financial impact, the on-chain portion must also meet the smart-contract PoC and realistic Solana execution requirements.

Safe testing

Use safe, authorized conditions and the minimum demonstration necessary to establish impact. A report does not require actual user losses or a live outage.

• Perform on-chain exploit tests only on local forks or faithful local test environments, never against mainnet or public-testnet deployments. Ordinary read-only inspection of public blockchain data is permitted.

• For web findings, use your own accounts and data in authorized conditions or a faithful test environment. Do not access or modify other users’ private data.

• Do not test live third-party oracles, programs, websites, extensions or other third-party systems without authorization.

• Do not cause actual losses, damage, denial of service or other disruption. Do not generate significant automated traffic against project assets. Manually verify automated scanner findings before reporting.

• Do not conduct phishing, social engineering or unauthorized physical or electronic intrusion, threaten or harass anyone, or violate applicable laws.

Reports relying on damaging prior exploitation by the reporter are excluded.

5 Out of scope and trust assumptions

Admin-controlled configurations

Authorized administrators are trusted to follow the configuration review and validation process, including checks performed off-chain. Reports that require an administrator to select unsafe parameter values or combinations that are not deployed in an in-scope production instance at submission are excluded. The absence of on-chain enforcement of those configuration constraints does not by itself establish an eligible vulnerability, even if the contract technically permits an administrator to set the unsafe combination.

This exclusion does not cover an otherwise eligible exploit of a configuration actually deployed in an in-scope production instance, or a vulnerability allowing an unprivileged attacker to reach the unsafe state from production without an excluded privileged action. The report must demonstrate that path under the ordinary proof requirements.

Social engineering

An exploit requiring attacker–user interaction, directly or through attacker-supplied material, that induces a departure from the product’s normal workflow is excluded. This includes crafted links on genuine Kamino domains. Ordinary interaction such as a wallet approval within the normal workflow is not, by itself, social engineering.

Authorized roles and token authorities

Attacks requiring a victim’s authorized signer or executor to deliberately misuse legitimate permissions are excluded, including misuse of transaction timing or submission routes.

Onboarding a token extends the trust model to all its mint, freeze and extension authorities. These authorities are trusted not to misuse their powers to harm Kamino or its users, regardless of the resulting impact. For example, a freeze authority blocking Kamino’s accounts and causing KLend denial of service is therefore excluded.

These assumptions do not exclude a vulnerability that grants unauthorized permissions or lets a role exceed its legitimate powers.

Token-2022

Issues specific to Token-2022 behavior or extensions are excluded unless they demonstrate theft or other irrecoverable loss and meet all other requirements. The authority trust assumptions still apply. Temporary disruption from those features is excluded from the $10,000 category; optional small goodwill remains available. A Kamino bug is not excluded merely because an affected token uses Token-2022.

Fees and interest rates

Loss or avoidance of protocol fees alone, including origination and flash-borrow fees, is excluded. Separately demonstrated eligible user-fund impacts are assessed normally.

Changing supply or borrowing to move utilization and rates while the configured interest model operates correctly is excluded. Calculation or accounting defects with an eligible impact remain assessable.

Oracles

Simply assuming that a trusted third-party oracle publishes incorrect data does not qualify. Exploitable defects in Kamino’s handling of oracle data, including bypassing configured freshness checks or incorrectly interpreting a valid price, remain assessable. Feasible oracle-manipulation and flash-loan attacks are not excluded merely because an oracle is involved.

Generic recommendations to add checks do not establish eligibility. This rule takes precedence over a general exclusion of stale-price or oracle-check findings.

Dependencies and integrations

A dependency-related report must demonstrate a directly exploitable defect in Kamino’s actual use or integration of the dependency, with an eligible production impact. An affected version, dependency vulnerability or standalone dependency PoC is insufficient. Defects solely in out-of-scope external programs or services, and infrastructure failures such as Solana or RPC outages, are excluded. This applies to smart contracts, including Anchor, and web/app deployments.

Reports relying on a newly disclosed dependency vulnerability are excluded during the first seven calendar days (168 hours) after its initial CVE publication. If no CVE exists, the period starts with the maintainer’s first public security advisory describing it; a later CVE for that issue does not restart the period.

Expiry of this window creates neither eligibility nor a reward entitlement. All ordinary requirements still apply. Known-issue and duplicate rules concern the Kamino vulnerability; an upstream advisory alone does not establish that the same Kamino-specific vulnerability was previously reported or documented.

Other exclusions

Standard rewards also exclude impacts requiring pre-existing access to leaked credentials or privileged addresses; independent stablecoin depegs not caused by the reported code bug; basic economic or governance attacks, lack of liquidity, Sybil attacks and centralization risks; unused secrets; recommendations without an eligible demonstrated impact; and test/configuration-only findings without a production impact.

Apply these alongside the specific rules above. They do not exclude an otherwise eligible bug that itself exposes in-use production secrets or grants unauthorized permissions.

6 Previous audits known issues and duplicates

Completed audits are available in the Kamino audit repository. Unfixed vulnerabilities described in those audit reports before submission are not eligible for another reward.

Vulnerabilities already known to Kamino before submission are excluded. Kamino shares a confidential list of known issues with Sherlock. When prior knowledge must be established, Kamino provides Sherlock with supporting evidence demonstrating that the same vulnerability was known before the researcher’s submission. Neither the confidential list nor that evidence will be shared with the researcher or made public. Prior public disclosure is not required for this exclusion.

A previously rejected allegation does not by itself establish a known vulnerability.

Duplicate reports of the same unfixed vulnerability do not qualify for another bounty. A previously fixed bug later reintroduced into production may qualify again: demonstrate both the effective fix and reintroduction. Apply current impact, funds at risk and ordinary rates and caps, with no discount solely because it is a regression.

Duplicates are assessed by the underlying vulnerability or root cause and submission priority. The same vulnerability appearing in multiple places does not create separate rewards.

7 Reporting disclosure and payment

Reporting and assessment

Submit reports and handle related communications and payments through Sherlock’s designated process. Kamino makes final determinations in good faith against the published rules applicable at submission.

Investigating, reproducing, acknowledging, mitigating or fixing an issue does not itself establish eligibility or a payment obligation. A later fix or rule change cannot retrospectively disqualify an otherwise eligible report.

Coordinated disclosure

Report vulnerabilities exclusively through Sherlock. Do not publicly disclose exploit details or discuss a submitted vulnerability with third parties without Kamino’s explicit permission, coordinated through Sherlock.

For vulnerabilities requiring remediation, public disclosure must wait until Kamino has verified the issue, deployed the fix and authorized disclosure. An accepted-risk, unresolved or rejected report also requires explicit permission before public disclosure; rejection or a decision not to fix is not itself permission. Premature disclosure may disqualify a report from a reward.

Payment terms

Rewards are denominated in USD and paid in USDC on Solana through Sherlock’s designated process. The funds-at-risk valuation in section 2 determines the USD reward; it is separate from the payment asset and network.

KYC requirements

KYC is required before a successful submission can be paid. Researchers must provide:

• Full name.

• Date of birth.

• Proof of address: a redacted bank statement showing the address or a recent utility bill.

• A copy of a passport or other government-issued identification.

Provide identity documents through the designated KYC process, not in the vulnerability report or a public discussion.

8 Resources and applicable platform rules

• Kamino website

• Previous audit reports

• Sherlock criteria for bug bounty report validity

• Sherlock bug bounty platform rules

Read the linked Sherlock rules before submitting. These Kamino program rules take precedence wherever they conflict with Sherlock’s general validity criteria or platform rules, including scope, proof requirements, rewards, exclusions and the assessment process. General rules apply where consistent with these program-specific terms.