Kamino $KMNO

$KMNO is a gem!Exploring Kamino's page, two things stood out. First, sentiment here is Gem 100% / Rug 0% across 34 posts — I didn't see a single skeptical take, which is unusual next to other project pages and makes the feed read more like a fan channel than due-diligence material. For a lending protocol that holds user funds, balanced signal matters more than unanimous praise.

Second, one post flagged circulating scam Kamino websites and advised verifying the URL via Kamino's official X bio before connecting a wallet. That's the most practically useful security note on this page, but it's buried in the feed. Suggestion for the TokenGems team: pin safety-critical posts like that to the top of project pages instead of letting them scroll away.

$KMNO — Kamino's Borrow and Multiply docs disagree on what a liquidation actually costs I read Kamino's public docs to work out what a liquidation would cost on a leveraged position, and got two different answers depending on the page. The Multiply Risks page says: close factor up to **10%** of the position per transaction, and a liquidation penalty of **~0.1%** ("reduced 90% from ~1% in September 2025"). But Multiply positions are Kamino Lend positions — Multiply's own How It Works page says the position ends up "with collateral and debt recorded on Kamino Lend" — and the Borrow docs describe something very different. The Liquidations page says each round closes a maximum of **20%** of the position's debt (100% above a ~95% insolvency threshold), and the liquidator bonus is dynamic: it starts at a per-reserve minimum (2% in the worked example) and scales up to the per-reserve max (8% in the example). The Fees page and the Borrow Concepts page both repeat the 20% close factor. On a $10,000 JitoSOL/SOL position at 8x, the Multiply page tells me a first liquidation round takes ~$1,000 and costs ~$10; the Borrow page tells me it can take up to $2,000 with a 2%+ bonus ($200+). That's a 20x gap in the number I'd use to judge how close to the threshold I'm willing to run — and on the Jito Market, Liquidation LTV is 90% under eMode, so the buffer is thin to begin with. Suggestion: one canonical liquidation-parameter table (close factor, min/max bonus, insolvency close factor) per market, linked from both the Multiply and Borrow docs, stating which values apply to Multiply positions and whether the September 2025 reduction overrides the reserve-level dynamic bonus. The KRAF dashboard already shows Liquidation LTV per loan; showing the applicable penalty range there too would close the loop. Question: on a JitoSOL/SOL Multiply position, is the first liquidation round 10% or 20% of debt, and does the liquidator bonus start at ~0.1% or at the reserve minimum (e.g. 2%)? Scope: public docs only, no wallet connected, no position opened. Drafted with AI-assisted research. Sources: kamino.com/docs/products/multiply/risks · /products/multiply/how-it-works · /products/borrow/liquidations · /products/borrow/fees

$KMNO is a gem!

Explored Kamino's Multiply and Leverage Vaults (specifically SOL-JitoSOL and USDC/USDT lending pools). What stands out is the automated collateral rebalancing and risk parameter dashboard — it provides clearer liquidation boundary visibility than standard borrow-lending protocols like marginfi or Solend.

Constructive critique & builder questions:

1. In high-volatility flash scenarios on Solana, how does the oracle latency fallback handle divergent Pyth vs Switchboard pricing feeds when collateral ratios approach the 85% liquidation threshold?

2. On the UI side, the 'Net APY' toggle doesn't dynamically reflect borrow fee spikes under maximum pool utilization until the confirmation modal. Exposing that real-time spread directly on the vault card before opening the position would drastically improve UX for active retail lenders.

$KMNO Kamino's best idea is unification — lending, borrowing, and automated vaults in one interface instead of three separate apps. Depositing JitoSOL as collateral, borrowing USDC against it, and routing into a yield vault without leaving the page is a genuinely smoother loop than the usual DeFi juggling. Elevation Mode for correlated assets is smart capital efficiency. Concern: leveraged Multiply positions are one click away from beginners who may not understand liquidation risk — risk disclosures should be more prominent before opening leverage. With $1.4B+ managed, 30+ audits, and zero bad debt, the security track record is strong, which matters more than APY headlines. Suggestion: show a risk score per vault upfront so users can match strategies to their comfort level.

$KMNO One thing that confused me as a Kamino Lend user: the fee documentation says there are no deposit, withdrawal or origination fees, but Kamino’s own MiCA whitepaper lists a liquidity-vault deposit fee, a withdrawal fee, and a loan origination fee of “e.g. 50 bps” for certain markets. Both are official documents, and they don’t agree. On top of that, the protocol’s interest spread is described as roughly 11–20% depending on the asset, with no per-reserve figure shown where I compare supply APYs. Could the team publish one fee page listing, per market, the origination fee (if any), the exact reserve factor and any vault deposit/withdrawal fees — and reconcile it with the whitepaper? Right now the true cost of a position is hard to verify before opening it.

$KMNO was poking at Kamino's "Get Vault APYs" dev recipe (kamino.com/docs/build/earn/get-vault-apys) today, read-only against the public API, no wallet. Found something worth fixing.

The recipe's first call is GET /kvaults/vaults with no params. That returns 186 vaults right now, and 38 of them are test vaults ("test vault", "testfail", "test t33", "jurox test" etc). The recipe then hits /metrics for every single one, so anyone copying it makes 187 calls and ends up showing junk rows next to real vaults.

Worst example: "Test Vault" (4nt9sW5E...) has about $0.002 deposited and 0 holders, but shows an 8.05% 7d APY. "test t33" (2uCaaSmJ...) shows a negative 7d APY with $0 in it. A dev building a yield dashboard off this would happily rank those.

The fix already exists in your own API reference: /kvaults/vaults?type=live returns just the 33 listed vaults, zero test ones. The recipe just doesn't use it.

Suggestions:

1. Switch the recipe's first call to ?type=live, and add a note that the unfiltered list includes every on-chain vault, test ones too.

2. Mention that apy7d, apy30d etc come back as strings, not numbers. The sample's apy7d * 100 only works because JS coerces it; anyone typing them as number or adding them up gets wrong results.

3. One line on which field the app actually displays (apy vs apyActual vs apyTheoretical vs apy7d) and whether it includes farm/KMNO incentives.

Easy check after the fix: run the recipe as written and every vault returned should be one you can see in the Kamino app. Happy to share the curl commands if useful.

$KMNO — Kamino Earn: distinguish position value from immediately withdrawable liquidity

The Earn withdrawal guide says larger withdrawals may require recalling capital from reserves, and high utilization can delay availability. The vault mechanics page describes a typical 5-10% unallocated buffer. That percentage describes a shared vault buffer, not a personal withdrawal quota or guaranteed exit capacity.

Could the withdrawal preview show three separate figures: requested amount, amount supported by the current liquid buffer, and amount dependent on reserve liquidity? Include a timestamp or slot, because other depositors can consume the buffer before execution.

Illustrative example: a 1,000,000 USDC vault with 50,000 USDC unallocated has a 5% buffer. A 60,000 USDC withdrawal exceeds that buffer by 10,000 USDC, but might still complete if reserves have sufficient recallable liquidity. "Above buffer" should therefore not automatically mean "withdrawal unavailable."

Question for the team: when liquidity is insufficient, is the request queued on-chain, partially executable, or rejected so the user must retry? The user guide explains the liquidity dependency but does not specify these transaction outcomes.

A worked example and explicit retry/queue behavior would make "Withdraw" easier to interpret before depositing.

Sources (reviewed 7 Oct 2026):

https://kamino.com/docs/learn/lend/withdrawing-assets

https://kamino.com/docs/products/lending-vaults/how-it-works

AI-assisted documentation review; no deposit or withdrawal performed for this review.

$KMNO I went through the unstaking process and checked both available routes for the same amount. The instant option was easy to understand, but comparing it with delayed unstaking required manually keeping track of the two quotes. The information is there, although it is not presented as one decision. Showing the amount received, waiting time, and difference between the two options together would make the choice much clearer, especially for someone using the product for the first time.

$KMNO is a gem!

$KMNO is up 73% in 30 days to a $245M market cap — so I checked what the protocol underneath actually earns.

From DefiLlama's series: $4.59M in fees and $604K in protocol revenue over the last 30 days — about a $10.1M annualized run-rate. That puts the token at ~24x annualized revenue (43x on FDV), while Holders Revenue shows $0: none of the $50.65M in cumulative revenue has ever been routed to KMNO holders.

What looks genuinely strong: utilization. $1.095B borrowed against $1.464B supplied is ~75%, versus the 25–45% range lending protocols usually run at. High utilization is why this revenue looks real rather than incentive-subsidized. The flip side: at 75% the buffer for lenders to exit is thin, and the fee trend is already softening — $4.59M over 30 days vs $1.01M over the last 7.

Timing matters here: 229M KMNO (~$10.8M, 2.81% of circulating supply) unlocks today, Sept 30, and insiders hold 55% of the 10B total supply on 12-month cliffs + 24-month linear vest, so the float keeps growing into 2027. The counterweight is the institutional pivot — fixed-rate 8% USDC borrowing against ONyc collateral went live Sept 25, the tGBP market on Sept 23, with BTC-backed credit and a New York office under the new CEO on the roadmap.

My question for the team: is there any plan to connect the ~$10M revenue to KMNO — a fee switch, a ve-model, buybacks? Right now holders price governance and seasons boosts only, and that gap is the entire bear case. A published revenue-to-token framework would give this page's metrics a real valuation floor.

$KMNO Kaminos unification of lending, borrowing, and automated vaults into one interface is an incredibly smooth loop for capital efficiency. However, the leveraged Multiply positions are just one click away from beginners who may not fully understand liquidation risks. I suggest making the risk disclosure and liquidation price metrics much more visually prominent before opening leverage. Showing a clear risk score upfront would help users match strategies to their comfort level.

$KMNO Reading through the KMNO takes here, I hit the same take twice in a row in the feed — same author, same text, back to back. If that's an edit creating a second post instead of replacing the first, it quietly undermines the feed: readers can't tell which version is current, and engagement splits across duplicates. Suggestion: dedupe by post on the feed, or mark edited takes with a visible 'edited' state and keep one canonical copy. (Checked the public feed on Oct 13; no wallet actions taken for this take.)

I explored Kamino’s documentation and noticed an opportunity to improve onboarding for new users.

The documentation covers Earn, Borrow, Multiply, and Swap, but much of the technical content focuses on vault curators, APIs, and developer tooling.

For someone discovering Kamino through $KMNO, it could be clearer where everyday lending and borrowing users should begin.

Suggested improvement: Add two prominent navigation paths:

New to Kamino: beginner guides covering lending, borrowing, risks, and governance.

Building on Kamino: APIs, SDKs, vault management, and integrations.

The information is already available. Making these paths more distinct could help new users find the right documentation faster.

Reference: https://docs.kamino.finance/

Kamino $KMNO markets "Verifiable Build" as a security guarantee. I checked it. The deployed Kamino Lend binary matches public commit a0876097, verify.osec.io confirms is_verified true. That part holds.

But verified only describes today's binary. The program is upgradeable (is_frozen false). It's controlled by a 5-of-10 Squads multisig with a 1-day timelock, and the Security page never mentions upgradeability at all. You can repeat this yourself. verify.osec.io/status/KLend2g3cP87fffoy8q1mQqGKjrxjC8boSyAYavgmjD shows is_frozen false, and the Solscan Program Multisig tab shows 5-of-10 with an 86,400s timelock.

So the multisig can ship a new unverified build about a day after deciding to. My question for the team: is there a public upgrade notification channel so users can review or exit before a new build takes effect? The fix I'd suggest: publish the upgrade authority, threshold and timelock right next to the Verifiable Build badge, and re-attest after every upgrade so verified can never silently go stale.

Just looking at how $KMNO handles the automated clmm range rebalancing and the k lend multiply loops. The system keeps liquidity in-range really well, but the analytics dashboard has a pretty bad blindspot like it shows the gross fee apy but completely hides the actual net costs like the pool fees and slippage that get eaten up during automated range shifts when the market gets crazy.

Can the devs just add a simple 'Net Yield vs Execution Slippage' log inside the vault analytics section? we really need a clear way to see the actual net gains after the automated rebalance costs take a bite out of it.

Also, when looping leverage via emode on multiply, sudden pool utilization spikes completely jack up the borrow rate curve. This destroys your expected yield before you can even react. Can we get a visual 'Pool Utilization Threshold Warning' right on the leverage slider that highlights those dynamic jump-rate triggers?

Having that data on the screen would make managing leveraged loops way safer

$KMNO

Explored Kamino's Automated Concentrated Liquidity Vaults (kTokens) and range rebalancing mechanics on Solana.

Specific Observation: Kamino's automated vault strategies rebalance LP ranges to keep capital actively earning swap fees. However, during choppy or mean-reverting market phases, frequent auto-rebalancing introduces substantial "rebalancing drag"—effectively selling the depreciating asset near the bottom of the range and re-buying at the top to re-center liquidity. While the vault dashboard clearly highlights gross fee APY, it lacks a dedicated metric disclosing historical rebalancing drag (realized inventory loss from auto-swaps) across 7-day and 30-day windows.

Constructive Suggestions:

Introduce a "Net Strategy Yield vs Static Range" metric on each liquidity vault card, explicitly subtracting auto-rebalance slippage and swap fees from gross fee rewards.

Provide a user-selectable "Rebalance Sensitivity" toggle (e.g. Tight Range vs Wide Volatility Buffer) allowing depositors to tailor rebalancing frequency to prevailing market volatility.

Question for the Team: Is the Kamino risk and quant team considering dynamic rebalancing thresholds that automatically widen during elevated Solana volatility regimes to reduce unnecessary turnover during sharp whipsaws?

$KMNO I checked Kamino’s Institutional Commodity Yield vault: $50.89M AUM, $4.30M instant liquidity, and a 7.39% projected annual return.

The docs explain that larger redemptions can enter a FIFO queue, while underlying commodity loans may require 1–3 months’ notice.

What’s missing is clearer visibility at the deposit stage: liquidity-buffer %, current queue size, and estimated withdrawal time.

An “exit liquidity” preview showing how much of a deposit could be withdrawn immediately—and the expected wait for the rest—would make the liquidity risk as transparent as the projected yield.

$KMNO

Went through Kamino's new AUTO/wYLDS fixed-rate Multiply page (simulator and info tabs, no wallet connected). Numbers shown: max leverage 4.5x, Max LTV 78%, liquidation LTV 80%, average leverage taken 3.74x, borrow 5.75% fixed for a 30-day term, 2.00M liquidity available, AUTO/wYLDS oracle at 1.02.

The math that the page doesn't show: at 4.5x the starting LTV is ~77.8%, so a ~2.8% drop in the AUTO/wYLDS oracle reaches the 80% liquidation LTV. At the average 3.74x the buffer is ~8.4%. Since AUTO is backed by consumer auto loans, the realistic risk is not daily volatility but a NAV markdown after defaults.

Questions:

1. Is the AUTO oracle NAV-based (reported by Hastra/Figure), how often does it update, and what is the largest single markdown so far?

2. Before the 3-day rollover window, is the next fixed rate shown in advance? And what is the exact auto-repay fee formula if a position can't roll?

Suggestion: show "price drop to liquidation" next to the leverage slider. Small thing: the Multiply page's browser tab title still reads "Solana Concentrated Liquidity Layer".

$KMNO I explored Kamino's automated liquidity vaults and multiply lending loops on Solana. The automated rebalancing mechanism across concentrated liquidity pools is effective at minimizing impermanent loss during sideways volatility. However, during rapid directional price expansions, the vault rebalancing frequency suffers from slight compute-budget throttling on Solana, leading to temporary unhedged exposure before target pool weights sync. Introducing dynamic priority fee adjustment hooks based on live network congestion metrics would significantly tighten execution precision for high-volume vaults.

$KMNO Kamino's automated concentrated liquidity (CLMM) vaults are a benchmark for Solana DeFi, but vault rebalancing logic during flash-wick events deserves a closer look. When high-volatility spikes trigger multiple rapid rebalance cycles within a tight window, the compounded swap fees from re-centering ranges can eat into single-sided LP yields faster than impermanent loss protection recovers them. Could Kamino introduce an adaptive volatility dampener that temporarily widens the rebalance trigger band during confirmed oracle deviation spikes (e.g. via Pyth pull oracles)? This would preserve capital efficiency for depositors during market stress.

$KMNO O — Kamino

I'm new to Solana DeFi, and this page taught me a lot — the existing takes go deep (fee docs, verifiable builds, withdrawal liquidity). But I noticed something as a first-time reader: nothing on this page tells you in plain words what Kamino actually does before the deep dives begin. "Multiply", "kTokens", "eMode" all assume prior knowledge.

Suggestion for the page itself: pin a one-line summary above the posts — something like "Kamino is Solana's lending protocol: deposit to earn yield, borrow against your collateral, or loop leverage with Multiply." The FAQ covers price and holders, but not what the product is. One sentence would let the next newcomer actually understand the deep takes instead of bouncing off them.

(Explored the KMNO page on tokengems.ai; no trades or deposits made for this take.)

$KMNO — Kamino

I'm new to Solana DeFi, and this page taught me a lot — the existing takes go deep (fee docs, verifiable builds, withdrawal liquidity). But I noticed something as a first-time reader: nothing on this page tells you in plain words what Kamino actually does before the deep dives begin. "Multiply", "kTokens", "eMode" all assume prior knowledge.

Suggestion for the page itself: pin a one-line summary above the posts — something like "Kamino is Solana's lending protocol: deposit to earn yield, borrow against your collateral, or loop leverage with Multiply." The FAQ covers price and holders, but not what the product is. One sentence would let the next newcomer actually understand the deep takes instead of bouncing off them.

(Explored the KMNO page on tokengems.ai; no trades or deposits made for this take.)

$KMNO Kamino Earn: the RockawayX EUROP vault page shows history the vault doesn't have yet.

On https://kamino.com/earn/lend/rockawayx-europ/vault-overview (checked 6 Oct 2026, no wallet connected):

- Deployment Date: 7 September 2026, about 29 days ago.

- Yet the page shows "Supply APY (90D Avg) 0.25%" and a "180D Growth" figure.

- Total Supplied $4.49M, Total Borrowed about $352, Utilization 0.01%, current Supply APY 0.00%.

- Interest Generated across all users: +$0.04.

0.25% a year on $4.49M would be roughly $890 over 29 days, so the 90D average doesn't describe what depositors in this vault actually earned. Kamino's docs say quoted APYs are trailing averages, but don't say what is shown when a vault is younger than the window.

Smaller point: the vault is labelled "Balanced" while its own strategy text calls it "conservative", and I couldn't find where Conservative / Balanced / Aggressive are defined in the docs.

Suggestion: for vaults younger than a window, show "since launch (29 days)" instead of 90D/180D, and add a note when utilization is near zero ("little borrow demand yet; second market coming").

Question: is the 90D figure taken from the Schuman EUROP Prime Market's history before this vault existed?

(Researched with AI assistance; numbers re-checked on 6 Oct 2026.)

$KMNO Borrowing USDC against SOL and JUP on Kamino Lend today, and ran into a real UX friction point around rate spikes.

When pool utilization pushed past the 85% kink, the borrow APR jumped from ~5% to over 30%. Because of that rate surge, my Health Factor degraded noticeably faster over a 48-hour window—purely from compounding debt accrual, not underlying price drop. Right now, the borrow modal only quotes an instantaneous APR percentage. For anyone holding a carry or swing position, there's zero visual projection showing the actual dollar-cost decay or how fast an ongoing rate spike will eat into your collateral over 24h/72h.

Another pain point with multi-asset collateral: if you deposit both SOL and JUP to back a single loan, there's no visibility into which asset the liquidation bot seizes first during a partial liquidation. I'd much rather have the protocol liquidate more volatile tokens before touching core yield-bearing SOL, but currently there’s no way to set a priority preference.

A simple daily debt-decay estimator inside the position view, plus a user-defined liquidation hierarchy for multi-collateral loans, would make risk management 10x clearer for active borrowers. Curious if the team has ever considered letting users set an automated rate cap to partially deleverage before borrow spikes get out of hand.

$KMNO is quietly becoming a powerhouse in Solana's DeFi. They're pioneering concentrated liquidity management and automated strategies, which could seriously boost capital efficiency across the ecosystem. Definitely one to watch for real yield.

$KMNO docs llms.txt only works on the canonical host**

Kamino has an LLM index and the Buildkit page (docs.kamino.finance/docs/build/agentic-finance/building-with-llms) tells agents to use it. Problem is the link kinda doesn't work. Checked 17 Oct 2026 with curl, no wallet connected:

- `https://docs.kamino.finance/llms.txt` with a normal client (`Accept: */*`) gives a 200 `text/html`, an 830 KB app shell, then bounces you to `https://kamino.com/docs`. No file.

- Same URL with `Accept: text/plain` gives a 200 `text/markdown` (53 KB), but it's got raw MDX in it, like `export const CopyBtn = ({text}) => { ... useState ... }`.

- `https://kamino.com/docs/llms.txt` is totally fine. Clean 56 KB `text/plain`.

So an agent that copies the link from the docs gets HTML or junk MDX. It would have to already know the other host and the magic Accept header, which kinda defeats the point of having an LLM index.

Can be fixed by a 301 `docs.kamino.finance/llms.txt` to `kamino.com/docs/llms.txt` (or serve the same bytes on both), always as `text/plain; charset=utf-8`, and strip the MDX/JSX out of the index., but is docs.kamino.finance even supposed to be a docs host, or should it just always redirect to kamino.com/docs?