Revue de l'AMA Alkanes : L'accent du DeFi sur Bitcoin L1 ne réside peut-être pas dans la création d'un nouvel actif, mais dans la couche d'exécution Cette AMA Alkanes — « Bitcoin DeFi Info & Questions » — contient une quantité considérable d'informations. À première vue, il s'agit d'une discussion informelle de la communauté, mais elle clarifie en réalité le récit le plus central d'Alkanes aujourd'hui : il ne s'agit pas d'un autre protocole BRC-20, Runes ou token classique, mais d'une couche d'exécution programmable pour le DeFi sur Bitcoin L1. La position d'Alkanes est claire : elle hérite du mécanisme de transfert d'actifs de Runes/UTXO, mais chaque alkane est fondamentalement un programme WASM exécuté par un indexer en dehors de la couche de consensus Bitcoin. Autrement dit, elle tente d'apporter, sous forme de méta-protocole, des capacités de contrat intelligent similaires à l'EVM sur Bitcoin L1. C'est pourquoi l'animateur a posé une question très directe au départ : les récits autour des actifs sur BTC L1 sont aujourd'hui froids, et de nombreux projets BRC et Runes ne suscitent plus d'intérêt — pourquoi continuer ? La réponse centrale est la suivante : Alkanes ne vise pas à reproduire un standard d'actif, mais à transformer les données sur la chaîne Bitcoin en actifs et couches d'applications exécutables et composites. Son objectif n'est pas de « recréer un autre protocole meme », mais de permettre l'émergence sur Bitcoin L1 de primitives DeFi telles que les AMM, le prêt/emprunt, les launchpads et la liquidité inter-protocoles. L'AMA a également abordé de nombreux points concernant les données de DIESEL et Uncommon Goods. Un point clé est qu'il ne faut pas se fier uniquement au nombre de mint ou au volume de transactions, car les incitations de DIESEL pourraient stimuler un grand nombre d'activités liées à Uncommon Goods. Autrement dit, les données chain-on doivent être analysées en détail ; sinon, il est facile de confondre les comportements induits par DIESEL avec une demande naturelle pour un actif spécifique. La question de la gouvernance des indexers a également été essentielle. Certains ont demandé : si l'interprétation WASM d'Alkanes dépend des indexers, les développeurs peuvent-ils décider quelles fonctions DeFi sont autorisées ou non ? La réponse a été modérée. Au début, les développeurs peuvent effectivement ajuster le protocole, surtout lorsque des changements réels surviennent au niveau du consensus Bitcoin et qu'une adaptation est nécessaire. Toutefois, ils soulignent également qu'Alkanes approche d'une phase où modifier arbitrairement les indexers ou censurer des fonctions deviendra de plus en plus difficile. À l'avenir, le cœur du système se tournera vers la gouvernance communautaire et vers la formation d'un consensus entre des indexers opérant en production. En matière de sécurité, ils ont mentionné qu'une récente attaque ou anomalie a en réalité servi de test de pression. L'équipe estime que cet événement les a aidés à mieux comprendre les limites du système, et a démontré l'importance d'une réponse rapide, d'une collaboration open source et de la participation des développeurs externes. Un axe particulièrement intéressant est celui des bibliothèques de contrats standards. Ils espèrent qu'à l'avenir, des modèles de contrats Alkanes équivalents à OpenZeppelin seront disponibles, permettant aux projets de réduire l'écriture de code personnalisé risqué et d'utiliser davantage des contrats fondamentaux éprouvés. Seule cette approche permettra à l'écosystème Alkanes d'accéder à une phase DeFi à plus grande échelle. Une autre information majeure : l'équipe a indiqué avoir déjà développé une implémentation/forçage Rust de Bitcoin Core, intégrant une couche secondaire d'indexation capable d'exécuter le logiciel WASM/indexer utilisé par Alkanes. Actuellement, il s'agit davantage d'un processus CLI/systeme, mais à l'avenir, s'il est couplé à un portefeuille UI/QT, il pourrait servir à démontrer la demande réelle pour des nœuds économiques. L'interopérabilité entre Runes et Alkanes a également été un point central. Ils ont clarifié que le proto-burn n'est pas simplement un pont unidirectionnel de Runes vers Alkanes. Plus intéressant encore : la structure de données Runestone peut contenir simultanément des informations Runes, Protorrunes et Alkanes, ce qui permet théoriquement des swaps atomiques, des carnets d'ordres et une liquidité inter-méta-protocoles sans passer par BTC ou frBTC. Cela revêt une importance particulière pour les actifs Runes : si beaucoup d'entre eux souffrent de faible liquidité et peu d'applications, ils peuvent utiliser ce chemin pour accéder à l'écosystème d'actifs Alkanes comme FIRE, DIESEL ou d'autres. La fin a abordé https://t.co/NReXbFe1yB. Son positionnement ressemble à celui de https://t.co/org8XMjhvv sur Bitcoin : le bonding se fait hors chaîne, puis un pool de liquidité est créé sur Alkanes. Ce qui est intéressant, c'est qu'ils mentionnent une conception « curve stack » visant à rendre l'ordre du mint hors chaîne plus vérifiable, afin d'éviter le black box du virtual mint. En conclusion, ils ont évoqué les Fire bonds, le coût du mint DIESEL et les risques de surpaiement, mais l'animateur a reporté ces sujets à la prochaine session. Mon sentiment global : le récit le plus important d'Alkanes aujourd'hui n'est pas un token unique, mais l'infrastructure programmable du DeFi sur Bitcoin L1. À court terme : voir si des applications comme DIESEL, FIRE, https://t.co/NReXbFe1yB, les AMM et le prêt/emprunt peuvent réussir. À moyen terme : l'audit, les bibliothèques de contrats standards, les implémentations multiples d'indexers et la gouvernance. À long terme : voir si suffisamment de développeurs et de nœuds économiques accepteront que Bitcoin L1 puisse non seulement héberger des actifs, mais aussi un environnement d'exécution composite. Si ce chemin est emprunté avec succès, Alkanes ne sera peut-être pas « un autre protocole sur Bitcoin », mais une nouvelle fondation pour le DeFi sur Bitcoin.