Le protocole Rome détaille l’accès EVM sur Solana tandis que des démonstrations de prêt tournent sur le testnet

Le protocole Rome a publié les paramètres de connexion à son testnet Hadrian, offrant aux développeurs un environnement financé en USDC pour tester des applications à la manière d’Ethereum sur Solana, tandis que sa documentation énumère séparément un réseau mainnet appelé Rubicon.

Résumé

• Le testnet Hadrian de Rome fonctionne sur Solana Devnet, tandis que sa documentation mentionne séparément Rubicon comme réseau mainnet.

• Les implémentations de Compound v3 et Aave v3 restent des applications de référence, sans migration officielle confirmée.

• Hadrian utilise de l’USDC de test pour les frais de gaz, dont le prix est contrôlé via des paramètres configurables de l’opérateur.

• Rome indique avoir subi un audit Halborn ; sa documentation mentionne la compatibilité avec Ethereum et des limites d’exécution.

La publication du 18 octobre du protocole Rome identifie Hadrian comme un testnet tournant sur Solana Devnet (ID chaîne : 200010), avec un point de terminaison RPC, un explorateur et des instructions pour obtenir de l’USDC de test. La capture d’écran fournie oriente les développeurs vers le faucet de Circle et une interface de pont pour créditer leurs portefeuilles.

La documentation développeur du projet mentionne séparément Rubicon comme réseau mainnet (ID chaîne : 7531), avec un point de terminaison RPC différent. Sa page d’introduction décrit Rubicon comme utilisant de l’USDC réel, distinguant ainsi l’environnement de production des actifs de test d’Hadrian.

L’EVM de Rome exécute du code Solidity sur Solana

La documentation d’exécution de Rome décrit une Machine virtuelle Ethereum (EVM) implémentée sous forme de programme Solana. Un proxy reçoit des transactions signées au format Ethereum, les vérifie via un émulateur hors chaîne, puis les prépare pour exécution par les validateurs Solana.

Selon l’architecture décrite, les contrats Solidity peuvent appeler des programmes natifs Solana via des invocations entre programmes (CPI). Les développeurs peuvent utiliser des outils Ethereum familiers tout en exécutant leurs contrats dans le runtime Solana.

Vous aimerez peut-être aussi : Lighter lance un devnet EVM avec des blocs d’une seconde et le trading de contrats

La documentation décrit un état applicatif partagé entre utilisateurs EVM et Solana. L’affirmation selon laquelle aucun pont n’est requis concerne les interactions au sein de cet environnement ; toutefois, les instructions de financement d’Hadrian orientent séparément les utilisateurs vers un pont pour transférer de l’USDC de test dans le réseau.

Le guide d’exécution de Rome distingue deux modes de traitement : les opérations tenantes dans une seule transaction Solana utilisent une exécution atomique, où la transaction entière réussit ou est annulée globalement.

Pour les opérations plus complexes, le même guide décrit une exécution itérative sur plusieurs transactions Solana. Les comptes sont verrouillés pendant le traitement, et les effets mis en cache sont validés à la fin. Le projet fixe une limite de session à 160 étapes et restreint les appels à certains programmes Solana dans ce mode.

La capacité transactionnelle de Solana a fait l’objet de mises à jour réseau distinctes. Dans un rapport du 30 août, Jacob Creech a annoncé une transition prévue de transactions de 1 232 à 4 096 octets, comme précédemment rapporté par crypto.news. Le déploiement de Transaction V1 était prévu le 9 septembre, tandis que les réductions de durée de slot et Alpenglow étaient traitées comme des mises à niveau séparées.

Les implémentations Compound et Aave restent des applications de référence

Le guide Hadrian de Rome cite Uniswap, Compound et Aave comme applications de référence validées d’abord sur le testnet.

Le dépôt Aerarium du projet décrit une application de prêt Compound v3 avec deux itinéraires de portefeuille partageant un même pool de prêt. L’un accepte des transactions signées au format Ethereum via MetaMask ; l’autre utilise Phantom et une identité dérivée de Solana, sans nécessiter de clé Ethereum.

Selon ce dépôt, les deux itinéraires accèdent au même marché Comet, couvrant les dépôts en USDC, les dépôts de garantie, les emprunts, les remboursements et les retraits. L’adresse de l’application indiquée utilise un domaine devnet. GitHub

Le dépôt de l’interface Aave de Rome qualifie explicitement le produit de « démo » et le place sur Hadrian. Son dépôt de contrats associé décrit un fork du code d’Aave.

Ces documents précisent comment Rome présente ses implémentations. Ils ne prouvent pas qu’une organisation dirigeante de ces protocoles de prêt ait approuvé un déploiement en production ou transféré des positions utilisateurs existantes vers Rome.

Rome a développé d’autres applications financières via des partenariats. En mars 2025, le projet a annoncé une collaboration avec KiiChain sur les actifs tokenisés et les paiements transfrontaliers pour l’Amérique latine. Des dirigeants ont évoqué des projets liés à l’immobilier, aux matières premières agricoles et à l’accès à la liquidité Solana.

Les paiements de frais en USDC dépendent de la configuration de l’opérateur

Le guide réseau d’Hadrian désigne l’USDC comme jeton de frais et identifie le mint USDC Solana Devnet de Circle. Selon ce guide, les développeurs utilisant Solana doivent disposer d’USDC de test et de quelque SOL devnet.

Le faucet de Circle prend en charge à la fois Solana Devnet et Ethereum Sepolia. Le fournisseur précise que les jetons du faucet sont destinés aux tests et n’ont aucune valeur réelle ; il autorise actuellement 20 USDC de test par demande, sous réserve de ses limites.

La documentation de la chaîne d’applications de Rome permet à un opérateur de choisir un jeton SPL pour les frais et de diriger les revenus liés aux frais vers une trésorerie applicative.

La même documentation décrit un service de tarification convertissant le jeton de frais choisi en SOL pour couvrir les coûts transactionnels sous-jacents de Solana. Sa configuration peut puiser les prix depuis des pools Meteora ou utiliser un recours Pyth/Hermes.

La page des contraintes de Rome liste des prix minimaux configurables pour les frais et un multiplicateur au niveau du proxy. Le cadre publié décrit donc une tarification configurable, sans imposer un coût universel en dollars pour chaque transaction applicative.

Les affirmations relatives aux audits et à la compatibilité comportent des limites définies

Le dépôt EVM de Rome identifie un programme mainnet et indique qu’il a été audité par Halborn. Le dépôt fournit des instructions pour reconstruire le programme et le comparer au binaire déployé, les métadonnées de build et le hash de commit étant masquées lors de la comparaison.

La documentation de compatibilité du projet énumère des différences avec Ethereum, notamment la désactivation de la fonctionnalité d’exponentiation modulaire et un comportement des frais qui ne reproduit pas le calendrier par opération d’Ethereum.

La page des contraintes précise que les transactions Rome doivent déclarer à l’avance les comptes Solana qu’elles touchent. Elle fixe une limite de 64 adresses par transaction et environ 1,4 million d’unités de calcul par transaction. Le guide recommande de mesurer la consommation réelle de calcul Solana à partir des reçus de transaction, car la valeur « gaz utilisé » EVM ne reflète pas fidèlement cette ressource.

Le tableau des déploiements mainnet nomme un portefeuille multisignature Squads comme autorité de mise à jour.

D’autres projets d’interopérabilité ciblent séparément les marchés institutionnels. En août, Interstice Digital a annoncé un moteur d’échange transfrontalier reliant Canton à Ethereum, Solana et Robinhood Chain. FalconX fournit la liquidité, tandis qu’Interstice affirme ne pas détenir les actifs clients ni exécuter de transactions pour leur compte.

En savoir plus : Bitmine ajoute 12 535 ETH alors que le cours de l’Ethereum reste sous les 2 500 $