Rome Protocol a publié les détails de connexion de son testnet Hadrian, offrant aux développeurs un environnement financé en USDC pour essayer des applications de style Ethereum au sein de Solana, tandis que sa documentation répertorie séparément un réseau mainnet appelé Rubicon.
Résumé
- Le testnet Hadrian de Rome fonctionne sur Solana Devnet, tandis que sa documentation répertorie séparément Rubicon comme mainnet.
- Les implémentations de Compound v3 et Aave v3 restent des applications de référence, sans migrations officielles de protocole confirmées.
- Hadrian utilise des USDC de test pour le gas, avec une tarification des transactions contrôlée via des paramètres d'opérateur configurables.
- Rome rapporte un audit Halborn, tandis que sa documentation liste la compatibilité Ethereum et les limites d'exécution.
La publication du 18 octobre de Rome Protocol identifie Hadrian comme un testnet fonctionnant sur Solana Devnet, avec l'ID de chaîne 200010, un point de terminaison RPC, un explorateur et des instructions pour obtenir des USDC de test. La capture d'écran fournie dirige les développeurs vers le faucet de Circle et une interface de bridge pour approvisionner leurs portefeuilles.
La documentation développeur du projet répertorie Rubicon séparément comme mainnet, avec l'ID de chaîne 7531 et un point de terminaison RPC différent. Sa page d'introduction décrit Rubicon comme utilisant de vrais USDC, distinguant l'environnement de production des actifs de test de Hadrian.
La EVM de Rome exécute du code Solidity au sein de Solana
La documentation d'exécution de Rome décrit une Ethereum Virtual Machine implémentée comme un programme Solana. Un proxy reçoit des transactions signées de style Ethereum, les vérifie via un émulateur hors chaîne et empaquette leurs instructions pour exécution par les validateurs Solana.
Selon l'architecture décrite par le projet, les contrats Solidity peuvent appeler des programmes Solana natifs via invocation inter-programmes, ou CPI. Les développeurs peuvent utiliser des outils Ethereum familiers tandis que leurs contrats s'exécutent au sein du runtime de Solana.
La documentation décrit un état d'application partagé entre les utilisateurs de l'EVM et de Solana. Son affirmation selon laquelle aucun bridge n'est nécessaire concerne les interactions au sein de cet environnement ; les instructions de financement de Hadrian dirigent séparément les utilisateurs vers un bridge lorsqu'ils apportent des USDC de test dans le réseau.
Le guide d'exécution de Rome distingue deux modes de traitement. Les opérations qui tiennent dans une seule transaction Solana utilisent l'exécution atomique, où la transaction complète réussit ou est annulée dans son ensemble.
Pour les opérations plus exigeantes, 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 liste une limite de session de 160 étapes et des restrictions sur les appels de programmes Solana pouvant utiliser ce mode.
La capacité de transaction de Solana a fait l'objet de changements réseau distincts. Dans un rapport du 30 août, Jacob Creech a présenté un passage prévu de transactions de 1 232 octets à un format de 4 096 octets, comme crypto.news l'a précédemment rapporté. L'annonce programmait Transaction V1 pour le 9 septembre et traitait les réductions de temps de slot et Alpenglow comme des mises à niveau distinctes.
Les implémentations de Compound et Aave restent des applications de référence
Le guide Hadrian de Rome nomme 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 parcours de portefeuille partageant un même pool de prêt. Un parcours accepte des transactions signées de style 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 parcours 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 d'application listé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 établissent comment Rome présente ses implémentations. Ils n'établissent pas que l'organisation de gouvernance de l'un ou l'autre des protocoles de prêt ait approuvé un déploiement en production ou déplacé des positions d'utilisateurs existantes vers Rome.
Rome a poursuivi d'autres applications financières par le biais de partenariats. En mars 2025, le projet a annoncé un travail avec KiiChain sur les actifs tokenisés et la finance de paiement inter-chaînes pour l'Amérique latine. Les dirigeants ont décrit des plans impliquant l'immobilier, les matières premières agricoles et l'accès à la liquidité de Solana.
Les paiements de gas en USDC dépendent de la configuration de l'opérateur
Le guide du réseau Hadrian spécifie l'USDC comme son jeton de gas et identifie le mint USDC de Circle sur Solana Devnet. Les développeurs qui financent depuis Solana ont besoin d'USDC de test et d'un peu de SOL devnet, selon le guide.
Le faucet de Circle prend en charge à la fois Solana Devnet et Ethereum Sepolia. Le fournisseur décrit les jetons du faucet comme des actifs de test sans valeur réelle et indique actuellement une distribution de 20 USDC de test par demande, sous réserve de ses limites.
La documentation de la chaîne d'application de Rome permet à un opérateur de sélectionner un jeton SPL pour les paiements de gas et d'acheminer les revenus des frais de transaction vers une trésorerie d'application.
La même documentation décrit un service de tarification qui convertit le jeton de gas choisi par rapport au SOL pour les coûts de transaction Solana sous-jacents. Sa configuration peut tirer les prix des pools Meteora ou d'un repli Pyth/Hermes.
La page des contraintes de Rome liste des prix de gas minimum configurables et un multiplicateur au niveau du proxy. Le cadre publié décrit donc une tarification configurable, sans établir un coût universel en dollars pour chaque transaction d'application.
Les affirmations d'audit et de compatibilité comportent des limites définies
Le dépôt EVM de Rome identifie un programme mainnet et indique que Halborn l'a audité. Le dépôt fournit des instructions pour reconstruire le programme et le comparer au binaire déployé, avec les métadonnées de build-time et de commit-hash masquées lors de la comparaison.
La documentation de compatibilité du projet liste les différences avec Ethereum, notamment la fonctionnalité d'exponentiation modulaire désactivée et un comportement de gas qui ne reproduit pas le calendrier par opération d'Ethereum.
La page des contraintes indique que les transactions Rome doivent déclarer les comptes Solana qu'elles touchent avant l'exécution. Elle liste un plafond 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 le chiffre de gas EVM utilisé ne représente pas fidèlement cette utilisation de ressource.
Son tableau de déploiement mainnet nomme un portefeuille multisignature Squads comme autorité de mise à niveau.
Des projets d'interopérabilité distincts ont ciblé les marchés institutionnels. En août, Interstice Digital a annoncé un moteur d'échange inter-chaînes reliant Canton à Ethereum, Solana et Robinhood Chain. FalconX fournit la liquidité, tandis qu'Interstice a déclaré qu'il ne détient pas les actifs des clients ni n'exécute de transactions pour le compte des utilisateurs.
