Berachain est une Layer 1 EVM-identical dont la conception publique combine une exécution compatible avec Ethereum, l'architecture de consensus BeaconKit et la coordination économique Proof of Liquidity (PoL). Comprendre le projet demande plus que reconnaître un nom de jeton : il faut distinguer l'environnement d'exécution de la chaîne, son modèle d'incitations et les rôles différents de BERA, WBERA et BGT.
Qu'est-ce que Berachain
Berachain est une blockchain de Layer 1 que sa documentation officielle décrit comme EVM-identical. Cette formulation concerne d'abord l'environnement d'exécution : les contrats Solidity et les outils Ethereum familiers sont censés fonctionner selon les mêmes règles EVM, sans exiger un autre langage de contrats ni un environnement d'exécution sans rapport. L'identité EVM est une affirmation d'architecture, et non une garantie que toute application, tout déploiement ou tout outil externe soit automatiquement sûr.
La description technique publique sépare l'exécution du consensus. Berachain utilise Bera-Reth, une implémentation de Reth légèrement modifiée, pour exécuter les contrats intelligents, tandis que BeaconKit fournit un cadre de consensus modulaire. Cette distinction est importante : une application peut être compatible avec l'EVM au niveau de l'exécution, alors que la chaîne conserve ses propres choix de coordination des validateurs, de production de blocs, de versions logicielles et de mises à niveau du protocole.
Le troisième élément est Proof of Liquidity, généralement abrégé en PoL. PoL n'est pas un autre nom pour l'EVM ou BeaconKit ; c'est le système de coordination économique décrit par Berachain pour orienter les émissions et les incitations à travers les validateurs, les applications, les Reward Vaults et l'activité considérée comme utile par le protocole. Distinguer ces trois couches facilite l'analyse : l'exécution explique comment les contrats fonctionnent, le consensus comment le réseau se coordonne, et PoL décrit la conception des incitations autour de ce réseau.
Quel problème Berachain cherche-t-il à résoudre ?
Une Layer 1 classique doit équilibrer plusieurs enjeux liés : les développeurs ont besoin d'un environnement d'exécution utilisable, les validateurs d'un moyen de participer au consensus, et les applications d'infrastructure et de liquidité suffisantes. Ces enjeux sont associés, mais ne sont pas identiques. Une chaîne peut être techniquement compatible avec des outils connus tout en laissant applications et utilisateurs organiser l'alignement des incitations au moyen d'arrangements séparés, qui ne sont pas toujours visibles à la couche du protocole.
La documentation de Berachain présente PoL comme une tentative de faire des émissions une partie d'une boucle de coordination récurrente, plutôt que de les traiter uniquement comme un coût de sécurité ou une subvention temporaire d'activité. Le modèle décrit oriente une partie des incitations du réseau vers des Reward Vaults et des applications participantes afin de relier les décisions des validateurs et l'activité des applications à l'économie plus large de la chaîne. Il s'agit d'un objectif de conception du protocole, non d'une preuve indépendante qu'une application produit une valeur durable ou qu'une incitation restera disponible.
Ce cadre explique aussi l'usage de plusieurs actifs liés plutôt que d'un seul jeton pour toutes les tâches. L'actif natif, sa représentation enveloppée et un actif non transférable de gouvernance et de récompenses ont des rôles documentés distincts. Il ne faut donc pas ramener BERA, WBERA et BGT à une catégorie générale de « jeton Berachain », car cela masquerait les différences de mécanisme que la documentation demande de distinguer.
Comment fonctionne Berachain ?
Au niveau de l'exécution, Berachain vise à préserver la compatibilité avec l'EVM d'Ethereum et les interfaces de développement standard. Le code d'un contrat intelligent doit toujours être examiné dans le contexte du déploiement précis, des autorisations, du chemin de mise à niveau et des dépendances externes. La compatibilité rend une interface familière, mais ne supprime pas les problèmes ordinaires de logique de contrat, d'hypothèses d'oracle, de contrôle administratif ou d'intégration incorrecte.
Au niveau du consensus, BeaconKit est le cadre décrit dans les documents Berachain qui relie un environnement d'exécution EVM au processus de consensus. La documentation officielle le caractérise comme une architecture modulaire avec des composants liés à CometBFT. Au lieu d'en faire un slogan de performance, il est plus utile de vérifier, pour le déploiement étudié à un moment donné, la version logicielle applicable, l'ensemble des validateurs, la configuration du réseau et les règles de mise à niveau.
PoL ajoute un chemin économique autour de cette pile technique. Les documents officiels indiquent que les validateurs utilisent BERA pour contribuer à la sécurité de la chaîne et produire des blocs, puis qu'une partie des émissions de WBERA va aux opérateurs de validateurs et qu'une autre passe par le système d'allocation des récompenses vers les Reward Vaults. Le résultat n'est pas automatique : les contrats, paramètres, critères d'éligibilité des applications et décisions de gouvernance déterminent le fonctionnement d'un chemin précis et peuvent évoluer.
Que fait BERA dans le système Berachain ?
BERA est le ticker officiel de l'actif natif de gas et de staking des validateurs de Berachain. L'actif natif paie les transactions du réseau et est celui que les validateurs utilisent dans la conception documentée de l'ensemble actif et de la production de blocs. Ces éléments identifient des rôles de protocole ; ils ne constituent ni une instruction d'acquisition, de staking ou de participation, ni un jugement sur la valeur de l'actif.
La documentation distingue également BERA natif de WBERA, la forme enveloppée 1:1 que la documentation désigne comme le seul jeton d'émission pour Proof of Liquidity. BGT est un actif hérité que la documentation actuelle signale comme obsolète : il remplissait le rôle de gouvernance et de récompenses dans les versions antérieures de PoL. Les noms sont faciles à confondre, car les trois actifs sont liés à la même chaîne ; lors de la lecture d'une page de contrat, d'une interface ou d'une proposition, il faut d'abord établir quel actif est réellement cité avant de déduire les règles applicables.
Le rôle de BERA n'est pas non plus le mécanisme de PoL. BERA sert au gas et à la participation des validateurs, WBERA apparaît dans les flux d'émissions documentés, et BGT est un actif hérité obsolète qui n'influence plus l'allocation des récompenses, les récompenses de bloc ni les propositions d'écosystème. C'est précisément pourquoi une présentation de projet doit nommer le ticker dans son contexte plutôt que de réduire tout le réseau à un symbole de jeton.
Tant la distribution que le modèle de jeton ont changé depuis le lancement, de sorte que seule la documentation actuelle constitue une référence sûre. Le tableau officiel du modèle économique du jeton pour l'offre de genèse de 500 000 000 BERA attribue 34,3 % aux investisseurs et 16,8 % aux premiers contributeurs principaux, tandis que les 48,9 % restants sont affectés à la communauté ; cette part communautaire se divise elle-même en un airdrop de 15,8 %, 13,1 % pour d'autres initiatives communautaires et 20 % pour la recherche et le développement de l'écosystème. Chaque attribution est assortie d'un cliff d'un an, suivi du déblocage d'un sixième puis de 24 mois de libération linéaire. Plus important encore, la mise à niveau PoL Next exécutée sur le mainnet début juillet 2026 a mis fin au modèle à deux jetons : BGT a été déclaré obsolète et WBERA est devenu l'unique jeton d'émission, les enchères d'incitations étant désormais réglées sous forme stakée. Toute description de Berachain qui présente encore BGT comme l'actif de gouvernance et de récompenses en vigueur est antérieure à ce fork.
Écosystème et adoption : ce que montre la documentation
Les documents officiels de l'écosystème identifient des applications natives et des composants de protocole tels que BEX, Bend, HONEY, les Reward Vaults et le système de gouvernance. Ils illustrent la manière dont les documents du projet relient exécution, liquidité et incitations, mais une liste de noms ne prouve pas que chaque composant présente le même degré de maturité, de sécurité, de conditions de liquidité ou d'état opérationnel. Chaque contrat et chaque application doivent être examinés séparément.
Cet article ne transforme donc pas les mentions de l'écosystème en nombre d'utilisateurs, classement de performance, mesure de décentralisation ou affirmation sur l'adoption future. La question plus précise est la suivante : quel composant est étudié, sur quel réseau, sous quelle adresse de contrat et avec quelles autorisations, et comment son comportement décrit se relie-t-il à PoL ? La documentation officielle peut établir une architecture prévue ; l'examen d'un déploiement spécifique requiert des enregistrements on-chain actuels et du code versionné.
La trajectoire mesurée est sévère et doit être exposée sans détour. Au 2026-08-15, DefiLlama a enregistré environ 27,5 millions de dollars américains de valeur totale verrouillée sur Berachain, contre un pic supérieur à 3,35 milliards atteint après le lancement ; les frais de la chaîne et le volume des échanges décentralisés de la veille étaient en conséquence faibles. Le projet a publiquement changé de cap sur cette période : le 2026-01-14, une stratégie intitulée Bera Builds Businesses a été annoncée en même temps que le bilan annuel de la fondation, requalifiant les émissions en capital de croissance pour un petit nombre d'entreprises onchain, et le site décrit désormais Berachain comme un moteur de croissance pour les entreprises onchain. Des articles du début de 2026 ont également fait état de la suppression par la fondation de la majeure partie de son équipe de marketing grand public et du départ d'un développeur principal.
En quoi Proof of Liquidity diffère-t-il des incitations classiques réservées aux validateurs ?
La différence de mécanisme porte sur la destination et la coordination des incitations, et non sur l'affirmation qu'une chaîne serait toujours meilleure qu'une autre. Dans un modèle d'incitations réservé aux validateurs, les récompenses du protocole sont principalement associées à la sécurité du réseau et à la production de blocs. La documentation PoL de Berachain décrit un chemin plus large : les validateurs utilisent toujours BERA pour la sécurité de la chaîne, tandis qu'une partie des émissions passe par des contrats d'allocation et des Reward Vaults vers les applications et l'activité éligible.
Cela ajoute davantage d'éléments qu'une formule simple selon laquelle « les validateurs reçoivent tout ». Les contrats d'allocation des récompenses, les critères des vaults éligibles, les incitations fournies par les applications, les choix des validateurs et les paramètres de gouvernance influencent le chemin réel. Le modèle peut aligner les incitations de certains participants, mais il ajoute aussi des dépendances et des points de décision qui doivent être examinés dans leur forme effectivement déployée.
Il ne faut pas non plus confondre PoL avec une preuve que la liquidité est sûre, permanente ou répartie équitablement. La liquidité peut être fragmentée, les contrats peuvent avoir des autorisations différentes et les règles d'incitation peuvent changer. La question d'analyse utile consiste à savoir si un chemin d'incitation documenté correspond à l'application et au contrat précis que le lecteur évalue, et non si une étiquette générale règle toutes les questions techniques ou économiques.
Risques et limites
Le premier risque est conceptuel : EVM-identical, BeaconKit et PoL renvoient à des couches différentes ; une affirmation exacte sur une couche ne prouve donc pas automatiquement un résultat sur une autre. Une application compatible EVM peut encore contenir une vulnérabilité, le logiciel client de consensus peut nécessiter des mises à jour, et une conception d'incitations peut fonctionner différemment d'un schéma simplifié. Il faut examiner le code, le contrat, la configuration et le contexte de gouvernance exacts plutôt que de s'en remettre à une description globale du projet.
Il existe également des risques liés aux contrats et à la gouvernance. Un Reward Vault, un contrat d'enveloppement de jeton ou un contrat central d'allocation peut avoir des autorisations, mécanismes de mise à niveau, dépendances et conditions distincts d'autres composants. La documentation officielle liste des adresses de contrat, mais une adresse seule ne révèle pas si l'interface est à jour, si le code source est vérifié ou quelle implémentation se trouve derrière un proxy. Une comparaison actuelle et en lecture seule entre la table officielle de déploiement et la page correspondante de l'explorateur de blocs est nécessaire.
Enfin, la conception PoL dépend d'éléments changeants : comportement des validateurs, activité des applications, allocation des récompenses, versions logicielles et décisions de gouvernance. La documentation peut décrire le jeu de règles prévu à un instant donné, mais elle ne remplace pas la vérification des contrats et paramètres effectivement actifs. Aucune conclusion d'audit n'est formulée ici ; si un rapport existe, il doit être trouvé auprès de l'auditeur nommé et associé au code et au déploiement précis qu'il couvre.
Le fait de gouvernance le plus lourd de conséquences est une intervention dans la chaîne elle-même. Le 2025-11-03, lors d'un exploit de Balancer V2 ayant touché environ 128 millions de dollars américains sur plusieurs réseaux, les validateurs de Berachain ont coordonné l'arrêt de la production de blocs et l'équipe principale a livré un hard fork d'urgence dont le binaire bloquait les transferts depuis les adresses détenant les fonds dérobés, n'autorisant un mouvement que vers une adresse contrôlée par la fondation. La perte du côté de Berachain a porté sur BEX, un fork de Balancer v2, pour environ 12 millions de dollars américains ; le 2025-11-04, le projet a annoncé que les fonds des utilisateurs avaient été intégralement récupérés, pour un montant communiqué d'environ 12,8 millions. Un lecteur qui évalue la décentralisation devrait peser les deux moitiés : les fonds ont été rendus, et le mécanisme qui les a rendus est un arrêt coordonné assorti d'un gel d'adresses.
Le lancement a suscité des accusations auxquelles il n'a jamais été répondu formellement. Des chercheurs onchain ont identifié une adresse liée à un développeur principal pseudonyme, qui a reçu environ 200 000 BERA lors de l'airdrop et en a vendu une partie peu après la mise en service du mainnet, ce qui a provoqué des accusations d'opérations d'initié, tandis que de nombreux participants au testnet ont déclaré que leurs attributions étaient très inférieures à leurs attentes. Séparément, des commentateurs ont critiqué la conception initiale comme une boucle dans laquelle des investisseurs privés pouvaient staker des BERA, gagner l'actif de gouvernance, l'échanger contre davantage de BERA et vendre ; cette critique visait un mécanisme que le fork de juillet 2026 a depuis supprimé. Le présent article n'a trouvé aucune déclaration officielle de la fondation ou du développeur répondant aux accusations liées à l'airdrop, et n'en fournit pas.
Comment vérifier Berachain par vous-même ?
Commencez par la documentation officielle de Berachain et confirmez que la page d'architecture, la page du jeton BERA, la table des contrats déployés et l'organisation officielle du code renvoient au même contexte de projet. Lisez la date et le périmètre de chaque page. Distinguez une description de conception de haut niveau, un registre d'adresses, un dépôt de code source et l'enregistrement d'un contrat on-chain précis : chacun établit un type de fait différent.
Pour l'actif natif, établissez d'abord que BERA est natif de Berachain et n'est pas présenté comme une adresse unique de contrat ERC-20. La table officielle de déploiement liste WBERA, la représentation enveloppée 1:1, à l'adresse `0x6969696969696969696969696969696969696969`. Comparez cette adresse publiée exacte avec la page Berascan correspondante, l'explorateur de blocs, en vérifiant le réseau, le libellé, les informations de vérification du code lorsqu'elles sont disponibles et toute relation de proxy. Il s'agit d'un chemin de vérification en lecture seule qui ne requiert aucune transaction interactive.
Pour PoL ou un composant d'application, trouvez l'entrée officielle exacte du contrat au lieu de supposer qu'une adresse de nom semblable est correcte. Comparez ensuite l'adresse et les informations d'implémentation de l'explorateur de blocs avec le code source officiel ou l'ABI lié. Des redirections inattendues, des noms de réseau incohérents, des changements d'autorisations inexpliqués ou des pages demandant une action interactive sont des raisons de s'arrêter et de vérifier à nouveau la chaîne des sources avant de conclure.
Conclusion
Berachain se comprend le mieux comme trois couches liées mais distinctes : un environnement d'exécution EVM-identical, l'architecture de consensus BeaconKit et une conception d'incitations Proof of Liquidity. Ce cadre est plus précis que de traiter le projet uniquement comme un jeton ou un écosystème d'applications, et il aide à séparer les affirmations d'architecture des faits propres à un déploiement qui doivent être vérifiés indépendamment.
BERA est l'actif natif de gas et des validateurs, tandis que WBERA et BGT ont d'autres fonctions documentées dans le système plus large. L'étape la plus fiable n'est pas une recommandation d'action, mais une vérification des sources : partir de la documentation officielle, identifier l'actif ou le contrat exact et comparer son enregistrement on-chain actuel par le chemin d'explorateur de blocs en lecture seule indiqué.
Pages de marché associées
Pages Bitbase pour les jetons cités dans cet article :
- BERA : Voir le prix · Marché spot · Marché des contrats perpétuels
Articles associés
Autres articles Bitbase sur ce sujet :
- Séquenceurs de rollups et interopérabilité
- MegaETH, l'exécution Ethereum en temps réel
- Layer 1 vs Layer 2 : comment les blockchains passent à l'échelle
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] What is Berachain? (official documentation) docs.berachain.com
[2] What is Proof of Liquidity? (official documentation) docs.berachain.com
[3] BERA Token (official documentation) docs.berachain.com
[4] Deployed Contract Addresses (official documentation) docs.berachain.com
[5] BeaconKit (official documentation) docs.berachain.com
[6] Berachain official source-code organization github.com
[7] berachain bera www.coingecko.com
[8] berachain defillama.com
[9] Documentation Index > Fetch the complete d docs.berachain.com
[10] www.berachain.com www.berachain.com
[11] Documentation Index > Fetch the complete documentation index at: ht docs.berachain.com
[12] blog.berachain.com blog.berachain.com
