Kamino sur Solana expliqué

2026-08-24

Kamino sur Solana expliqué

Les documents officiels présentent Kamino comme un protocole Solana avec un marché de crédit peer-to-pool et des modules automatisés de liquidité concentrée. KMNO est indiqué comme son jeton natif, tandis que les paramètres actuels, les identifiants de programme et la disponibilité des produits sont à revérifier le jour de publication.

Qu'est-ce que Kamino sur Solana ?

Kamino est un protocole natif de Solana dont la documentation officielle décrit plusieurs mécanismes financiers reliés entre eux plutôt qu'un produit unique. Ses principaux supports publics couvrent un marché de crédit peer-to-pool, la liquidité concentrée automatisée, des produits liés à l'effet de levier, des contrôles de risque, l'architecture des oracles et le jeton KMNO. Ce profil traite ces supports comme une description de la conception du système et du périmètre documenté, non comme la preuve que chaque composant a le même statut actuel.

L'expression Kamino sur Solana compte parce que les programmes de contrats intelligents du protocole, les identifiants de jeton, les entrées d'oracles et la configuration de marché sont propres à cet environnement. Un simple nom de projet n'identifie ni un programme ni un jeton canonique. Avant toute affirmation sur l'état actuel, il faut le contexte officiel de publication, la documentation citée et une vérification des identifiants onchain le jour de publication.

Pour qui cherche what is kamino crypto, la réponse utile la plus courte sépare le protocole du jeton. Kamino est le protocole et ses modules documentés ; KMNO est son jeton natif déclaré. Cette séparation évite de traiter un ticker, une page web, une interface et un déploiement de contrat intelligent comme des objets interchangeables.

Que documente le marché de crédit Kamino ?

La documentation produit de Kamino décrit sa couche de crédit comme un marché peer-to-pool. Sur le plan architectural, des réserves partagées comptabilisent les actifs au sein d'un marché, tandis que les positions de dette garanties sont mesurées face à des conditions de santé programmées. Le modèle diffère d'un système reposant sur une contrepartie bilatérale nommée pour chaque position.

La documentation décrit aussi marchés et réserves comme structures à risque délimité. Un marché peut avoir son propre ensemble de réserves, son traitement des garanties, sa configuration d'oracles, ses plafonds et ses seuils. Ces réglages sont un contexte important, non des faits intemporels : la couverture des actifs, les plafonds, les seuils de prêt sur valeur et les paramètres de liquidation peuvent changer avec la documentation et la gouvernance.

La liquidation fait partie de cette conception. Lorsqu'une position de dette ne satisfait plus les conditions de santé du protocole, le mécanisme peut la réduire selon ses règles configurées. Il s'agit d'une description du système, non d'un guide pour ouvrir, modifier ou fermer une position. Cela montre aussi pourquoi les affirmations sur le marché de crédit dépendent des entrées d'oracles, des conditions de liquidité, des contrats intelligents et du comportement de l'infrastructure automatisée de liquidation.

Comment s'articulent les modules automatisés de liquidité ?

La documentation de liquidité de Kamino décrit des coffres automatisés de liquidité concentrée pour les pools Solana. La liquidité concentrée signifie que le capital est représenté dans une fourchette de prix choisie au lieu d'être réparti uniformément sur tous les prix possibles. Cette conception fait de la gestion de la fourchette un élément central du comportement du module quand les conditions de marché changent.

Les pages officielles emploient les termes auto-swap, auto-compound et auto-rebalance. Dans ce profil, ces étiquettes désignent des fonctions d'automatisation documentées : le système peut réajuster une composition d'actifs, traiter les éléments accumulés et déplacer une fourchette selon une stratégie. Elles n'établissent ni un résultat fixe, ni un maintien permanent dans la fourchette, ni une issue uniforme sur tous les pools et conditions de marché.

L'automatisation change qui effectue certaines tâches de gestion, pas l'exposition sous-jacente. Une position peut sortir de sa fourchette configurée, sa composition d'actifs peut évoluer avec le marché et un rééquilibrage peut introduire des considérations d'exécution, de calendrier et de liquidité. Le mécanisme documenté doit donc se lire à côté des risques de la liquidité concentrée, et non à leur place.

Quel rôle KMNO joue-t-il dans le système Kamino ?

KMNO est le ticker exact que la documentation officielle de Kamino nomme pour le jeton natif du protocole. Sa page de jeton identifie le jeton et son contexte Solana. Le rôle documenté du jeton se distingue d'une part de propriété dans une société, d'un droit fixe sur l'activité du protocole ou d'une affirmation sur un résultat futur.

Les recherches sur kamino crypto, what is kamino crypto et kamino tokenomics and use cases se lisent au mieux comme des demandes visant à distinguer le protocole, son jeton et les informations de jeton sensibles au temps. La page officielle KMNO est le premier endroit où vérifier le ticker et son rôle déclaré. Offre, circulation, allocation, vesting, identifiants de contrat ou de frappe et dispositifs de gouvernance sont des sujets mouvants et ne sont volontairement pas repris ici comme des faits permanents.

Le mot utilité doit rester étroit. Un rôle d'utilité documenté explique comment un projet présente un jeton au sein d'un écosystème ; à lui seul, il n'établit ni demande, ni traitement juridique, ni sécurité, ni liquidité, ni disponibilité, ni résultat particulier. La publication doit suivre une vérification récente des supports officiels KMNO et de tout identifiant annoncé formellement.

Kamino: écosystème et état actuel de la documentation

L'index de documentation officielle de Kamino organise aujourd'hui les contenus autour des domaines produit, sécurité et risque, développeurs et curateurs. Ses supports produit incluent les sujets de marché de crédit et de liquidité traités ici, tandis que des pages connexes décrivent des mécanismes axés sur l'effet de levier et des catégories liées aux RWA. Cette carte de l'écosystème aide à s'orienter, mais un menu de documentation ne prouve pas que chaque fonction est active, inchangée ou disponible dans tous les contextes.

Le vocabulaire RWA demande une lecture distincte. Une représentation tokenisée peut ajouter à la mécanique du protocole des questions d'émetteur, de conservation, de droits juridiques, de règlement, de contrepartie, de données de prix et de juridiction. La présence d'une catégorie RWA, la mention d'un actif ou l'étiquette d'un marché ne règle pas ces questions et n'établit pas les conditions actuelles d'un actif donné.

L'état actuel de la documentation est donc un fait du jour de publication. Confirmez la date, le périmètre et la source contrôlée par le projet pour tout marché, réserve, stratégie, actif, réglage de risque, rapport de sécurité ou identifiant de programme nommé. Des supports plus anciens peuvent rester un arrière-plan utile sans décrire encore la configuration actuelle exacte.

Schéma du marché de crédit Kamino et des modules automatisés de liquidité

Deux chiffres du jour de publication aident à mesurer la taille du système. DefiLlama a enregistré environ 1,13 milliard de dollars américains de valeur totale bloquée sur l'ensemble des produits de Kamino au 2026-08-15, dont près de 1,05 milliard dans le composant de prêt ; la même série se situait autour de 2,5 milliards de dollars américains au début de décembre 2025. Les échanges déclarés sur le jeton KMNO sont dispersés plutôt que concentrés : au 2026-08-15, CoinGecko recensait vingt marchés, Toobit représentant environ 18,8 % du volume de 24 heures, la plateforme Orca sur Solana environ 13,3 % et Phemex environ 9,9 %.

L'environnement du protocole n'a pas été uniformément coopératif. Au début de décembre 2025, Kamino a inscrit sur une liste noire des adresses appartenant à Jupiter Lend, ce qui a désactivé un outil permettant de déplacer des positions en un clic vers cette plateforme concurrente, et cette mesure a été critiquée comme un éloignement de la composabilité ouverte. Le cofondateur de Kamino, Marius Ciubotariu, a indiqué que le blocage répondait au fait que Jupiter présentait ses coffres comme dépourvus de risque de contagion, une formulation qu'il jugeait trompeuse compte tenu de l'exposition à plusieurs actifs ; le directeur des opérations de Jupiter, Kash Dhanda, a ensuite reconnu que la formulation de contagion nulle n'avait pas été pleinement exacte. Les deux récits sont les déclarations propres des parties, et aucune autorité n'a tranché entre elles.

Comment lire la description du protocole ?

Un modèle de lecture utile a quatre couches : le mécanisme du marché de crédit, les modules automatisés de liquidité, les contrôles d'oracle et de risque, et le jeton KMNO. Chaque couche a des hypothèses différentes et peut changer selon un calendrier différent. Une page de jeton ne confirme pas un paramètre de marché, une page d'interface ne prouve pas une correspondance d'oracle et un ancien article de recherche n'établit pas un déploiement actuel.

La documentation officielle prouve ce que Kamino dit documenter. Ce n'est pas un constat universel sur la sécurité, le statut juridique, la liquidité, la performance ou la disponibilité de chaque composant. Cette distinction compte surtout quand une page emploie des termes larges comme automatisé, protégé, institutionnel ou RWA.

Risques, entrées d'oracles et limites du système

Le risque de contrat intelligent reste pertinent car le protocole repose sur du code déployé, des mises à jour, des dépendances et une configuration. Une revue, un test ou un rapport d'audit est une preuve portant sur un périmètre annoncé et un instant donné ; il ne rend pas sans risque chaque version, intégration, dépendance ou évolution future. La source, le périmètre et la date actuels d'un document de sécurité doivent être vérifiés avant d'en parler.

Le risque d'oracle compte car le calcul de la santé des garanties et de la dette dépend de données de prix externes et des règles qui les sélectionnent, les valident et les actualisent. Des entrées retardées, indisponibles, périmées, perturbées ou inadaptées peuvent modifier la lecture d'une position par le système. Sources multiples, lissage, règles de validation ou repli peuvent servir de garde-fous, sans supprimer tous les modes de défaillance.

Le risque de liquidation est explicite dans la conception du crédit. Une position peut devenir éligible à la liquidation lorsque ses conditions de santé configurées sont franchies, et des conditions tendues peuvent compliquer l'exécution. Le risque de liquidité y est lié : une profondeur de marché limitée, un mouvement de prix rapide ou un stress corrélé peuvent compliquer la conversion des garanties et dégrader les conditions dans lesquelles opère un mécanisme de liquidation.

Le risque de levier mérite sa propre limite. Le levier peut amplifier les évolutions favorables comme défavorables et réduire la distance jusqu'à une condition de liquidation. Une exposition liée aux RWA peut ajouter des risques d'émetteur, de conservation, juridiques, de règlement et de contrepartie aux risques de protocole, oracle, liquidité et contrat intelligent.

La liquidité automatisée a ses risques de fourchette, composition d'actifs, calendrier et perte impermanente. Le rééquilibrage peut être utile comme fonction documentée sans garantir qu'une stratégie reste dans la fourchette, évite les pertes, dispose d'une liquidité suffisante ou reste prévisible en cas de stress de marché. Aucune couche d'automatisation ne dispense de comprendre les conditions dont elle dépend.

Un risque de cette conception n'est pas un défaut, mais l'arithmétique d'un pool partagé. Le 2026-04-20, le taux d'utilisation de la réserve USDC du Prime Market de Kamino a atteint 100 %, ce qui signifie que chaque unité déposée avait été empruntée, tandis que plusieurs autres coffres USDC dépassaient 95 % au même moment. Lorsque l'utilisation se situe à son plafond, les déposants ne peuvent pas retirer à la demande : ils doivent attendre le remboursement des emprunteurs ou l'arrivée de nouveaux dépôts. Il s'agit d'une propriété inhérente au prêt de participant à pool et non d'une défaillance du code, et elle apparaît généralement au moment précis où le plus grand nombre de personnes souhaite sortir.

L'historique des audits contient un constat qui doit figurer à côté de toute affirmation de passé irréprochable. La vérification formelle du code de prêt réalisée par Certora et publiée le 2025-03-25 a montré que l'arrondi dans le calcul du taux de change pouvait en principe permettre à un rachat de restituer plus de liquidité qu'il n'en avait été apporté ; Certora a également indiqué que la faille n'était pas exploitable sur Solana à l'époque, compte tenu de la taille de dépôt qu'elle aurait exigée, et le calcul a été ramené au schéma habituel consistant à multiplier avant de diviser. Les recherches menées pour cet article n'ont relevé aucune action en justice, aucune attaque du protocole et aucun épisode signalé de créance irrécouvrable, mais l'absence de constat est une preuve plus faible qu'un constat, et les deux doivent se lire ensemble.

Comment vérifier Kamino et KMNO

Commencez par la documentation contrôlée par Kamino et comparez le nom du projet, le domaine, le contexte de publication et le périmètre produit annoncé sur plus d'une page officielle. Un article recopié, une image de réseau social, une annonce de recherche ou un compte au nom voisin ne remplace pas un document contrôlé par le projet. Traitez les écarts entre pages officielles comme un signal invitant à chercher une clarification datée plutôt qu'à combler le vide par déduction.

Si un avis officiel identifie un programme ou un jeton, comparez l'adresse de contrat ou de frappe Solana indiquée avec l'enregistrement de l'explorateur de blocs officiel. Vérifiez que le réseau, le nom du projet, le ticker et le contexte de publication concordent. Une valeur copiée depuis une publication non affiliée, une ancienne capture d'écran ou un site imitateur ne doit pas être tenue pour canonique.

Le jour de publication, revérifiez à part les éléments mouvants : état des marchés et réserves, paramètres de garantie et liquidation, plafonds, mappages d'oracles, déploiements de programme, informations de jeton, périmètre des rapports de sécurité et toute condition liée aux RWA. C'est une méthode de vérification en recherche, non une marche à suivre pour utiliser un produit ou autoriser quoi que ce soit.

Conclusion

Kamino sur Solana se décrit au mieux, à partir de la documentation de première main, comme un protocole associant un marché de crédit peer-to-pool à des modules automatisés de liquidité concentrée et à une infrastructure de risque connexe. KMNO est documenté comme son jeton natif. L'explication courte la plus exacte garde ces couches distinctes au lieu de les réduire à une seule affirmation sur un jeton ou une interface.

La leçon durable consiste à séparer l'architecture stable de la configuration sensible au temps. Les risques de liquidation, d'oracle, de contrat intelligent, de liquidité, de levier et liés aux RWA sont au cœur d'une lecture attentive. Avant publication, les documents officiels actuels et toute adresse de contrat ou enregistrement d'explorateur de blocs doivent être vérifiés de nouveau.

Pages de marché associées

Pages Bitbase pour les jetons cités dans cet article :

- KMNO : Voir le prix · Marché des contrats perpétuels

Articles associés

Autres articles Bitbase sur ce sujet :

- MEV sur Solana et attaques onchain

- Staking sur Solana et économie des validateurs

- Erreurs de transaction Solana : blockhash expiré et transactions non incluses

Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il explique ce que fait un projet et quel rôle son jeton joue dans ce système ; il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance, et il ne vaut ni recommandation ni approbation d'un projet ou d'un jeton. Bitbase n'a pas effectué de diligence raisonnable sur le projet décrit ici, et le mentionner ne signifie pas que Bitbase référence ou prend en charge cet actif. Les cryptoactifs comportent un risque important, notamment la volatilité des prix, une liquidité faible, la défaillance des contrats intelligents, l'incertitude réglementaire et la perte possible de toute leur valeur. Rédigé en août 2026 ; le statut d'un projet, sa tokenomics, son équipe et ses contrats peuvent changer à tout moment. Vérifiez tout par vous-même via les canaux officiels, l'adresse du contrat et un explorateur de blocs, et méfiez-vous des sites imitant le projet et des liens d'hameçonnage.

Sources

[1] Kamino Docs: Borrow kamino.com

[2] Kamino Docs: Liquidity kamino.com

[3] Kamino Docs: Liquidity Features kamino.com

[4] Kamino Docs: KMNO kamino.com

[5] Kamino Docs: Security kamino.com

[6] Kamino Docs: Multiply Risks kamino.com

[7] Kamino Docs: Market Risk Overview kamino.com

[8] Kamino Documentation Index kamino.com

[9] securing kamino lending www.certora.com

[10] kamino www.coingecko.com

Articles connexes

Plus