Il Protocollo di Roma dettaglia l'accesso EVM di Solana mentre le dimostrazioni di prestito vengono eseguite su testnet

Il Protocollo di Roma ha pubblicato i dettagli di connessione per il suo testnet Hadrian, offrendo agli sviluppatori un ambiente finanziato in USDC per provare applicazioni in stile Ethereum all'interno di Solana, mentre la sua documentazione elenca separatamente una rete mainnet chiamata Rubicon.

Riepilogo

• Il testnet Hadrian di Roma funziona su Solana Devnet, mentre la sua documentazione elenca separatamente Rubicon come mainnet.
• Le implementazioni di Compound v3 e Aave v3 rimangono applicazioni di riferimento, senza migrazioni ufficiali confermate dei protocolli.
• Hadrian utilizza USDC di test per il gas, con i prezzi delle transazioni controllati tramite impostazioni configurabili dell'operatore.
• Roma riporta un audit di Halborn, mentre la sua documentazione elenca la compatibilità con Ethereum e i limiti di esecuzione.

Il post del 18 ottobre del Protocollo di Roma identifica Hadrian come un testnet che funziona su Solana Devnet, con ID catena 200010, un endpoint RPC, un esploratore e istruzioni per ottenere USDC di test. Lo screenshot fornito indirizza gli sviluppatori al rubinetto di Circle e a un'interfaccia di bridge per finanziare i loro portafogli.

La documentazione per gli sviluppatori del progetto elenca Rubicon separatamente come mainnet, con ID catena 7531 e un diverso endpoint RPC. La sua pagina introduttiva descrive Rubicon come utilizzante USDC reale, distinguendo l'ambiente di produzione dagli asset di test di Hadrian.

Rome EVM esegue codice Solidity all'interno di Solana

La documentazione di esecuzione di Roma descrive una Ethereum Virtual Machine implementata come programma Solana. Un proxy riceve transazioni firmate in stile Ethereum, le verifica tramite un emulatore offchain e impacchetta le loro istruzioni per l'esecuzione da parte dei validatori di Solana.

Secondo l'architettura descritta dal progetto, i contratti Solidity possono chiamare programmi nativi di Solana tramite invocazione incrociata di programmi, o CPI. Gli sviluppatori possono utilizzare strumenti Ethereum familiari mentre i loro contratti vengono eseguiti all'interno del runtime di Solana.

La documentazione descrive uno stato dell'applicazione condiviso tra utenti EVM e Solana. La sua affermazione che non è necessario un bridge riguarda le interazioni all'interno di quell'ambiente; le istruzioni di finanziamento di Hadrian indirizzano separatamente gli utenti a un bridge quando portano USDC di test nella rete.

La guida all'esecuzione di Roma distingue due modalità di elaborazione. Le operazioni che rientrano in una transazione Solana utilizzano l'esecuzione atomica, dove l'intera transazione ha successo o viene annullata insieme.

Per operazioni più impegnative, la stessa guida descrive l'esecuzione iterativa su più transazioni Solana. I conti sono bloccati durante l'elaborazione e gli effetti memorizzati vengono confermati alla fine. Il progetto elenca un limite di sessione di 160 passaggi e restrizioni su quali chiamate di programma Solana possono utilizzare quella modalità.

La capacità di transazione di Solana è stata oggetto di modifiche separate alla rete. In un rapporto del 30 agosto, Jacob Creech ha delineato un piano di passaggio da transazioni di 1.232 byte a un formato di 4.096 byte, come riportato in precedenza da crypto.news. L'annuncio ha programmato la Transazione V1 per il 9 settembre e ha trattato le riduzioni del tempo di slot e Alpenglow come aggiornamenti separati.

Le implementazioni di Compound e Aave rimangono applicazioni di riferimento

La guida di Hadrian di Roma nomina Uniswap, Compound e Aave come applicazioni di riferimento validate prima sul testnet.

Il repository Aerarium del progetto descrive un'applicazione di prestito Compound v3 con due percorsi di portafoglio che condividono un unico pool di prestito. Un percorso accetta transazioni firmate in stile Ethereum tramite MetaMask; l'altro utilizza Phantom e un'identità derivata da Solana senza richiedere una chiave Ethereum.

Secondo quel repository, entrambi i percorsi accedono allo stesso mercato Comet, coprendo depositi USDC, depositi collaterali, prestiti, rimborsi e prelievi. L'indirizzo dell'applicazione elencato utilizza un dominio devnet. GitHub

Il repository dell'interfaccia Aave di Roma chiama esplicitamente il prodotto una demo e lo colloca su Hadrian. Il suo repository di contratti associato descrive un fork del codice di Aave.

Quei materiali stabiliscono come Roma presenta le sue implementazioni. Non stabiliscono che l'organizzazione di governo di nessuno dei protocolli di prestito abbia approvato un'implementazione in produzione o spostato le posizioni degli utenti esistenti a Roma.

Roma ha perseguito altre applicazioni finanziarie attraverso partnership. Nel marzo 2025, il progetto ha annunciato un lavoro con KiiChain su asset tokenizzati e finanza di pagamento cross-chain per l'America Latina. I dirigenti hanno descritto piani che coinvolgono immobili, materie prime agricole e accesso alla liquidità di Solana.

I pagamenti in gas USDC dipendono dalla configurazione dell'operatore

La guida della rete di Hadrian specifica USDC come il suo token di gas e identifica il mint USDC di Circle su Solana Devnet. Gli sviluppatori che ricevono finanziamenti da Solana devono testare USDC e un po' di SOL devnet, secondo la guida.

Il rubinetto di Circle supporta sia Solana Devnet che Ethereum Sepolia. Il fornitore descrive i token del rubinetto come asset di test senza valore reale e attualmente elenca una distribuzione di 20 test USDC per richiesta, soggetta ai suoi limiti.

La documentazione della catena applicativa di Roma consente a un operatore di selezionare un token SPL per i pagamenti in gas e instradare le entrate delle commissioni di transazione a un tesoro dell'applicazione.

La stessa documentazione descrive un servizio di pricing che converte il token di gas scelto contro SOL per i costi di transazione sottostanti di Solana. La sua configurazione può attingere ai prezzi dai pool di Meteora o da un fallback Pyth/Hermes.

La pagina delle limitazioni di Roma elenca i prezzi minimi del gas configurabili e un moltiplicatore a livello proxy. Il framework pubblicato descrive quindi una pricing configurabile, senza stabilire un costo universale in dollari per ogni transazione dell'applicazione.

Audit e affermazioni di compatibilità hanno limiti definiti

Il repository EVM di Roma identifica un programma mainnet e afferma che Halborn lo ha auditato. Il repository fornisce istruzioni per ricostruire il programma e confrontarlo con il binario distribuito, con i metadati di tempo di build e commit-hash mascherati durante il confronto.

La documentazione di compatibilità del progetto elenca le differenze rispetto a Ethereum, inclusa la funzionalità di esponenziazione modulare disabilitata e il comportamento del gas che non riproduce il programma per operazione di Ethereum.

La pagina delle limitazioni afferma che le transazioni di Roma devono dichiarare gli account Solana che toccano prima dell'esecuzione. Elenca un limite di transazione di 64 indirizzi e circa 1,4 milioni di unità di calcolo per transazione. La guida raccomanda di misurare il consumo effettivo di calcolo di Solana dalle ricevute di transazione perché il numero di gas utilizzato EVM non rappresenta fedelmente quell'uso delle risorse.

La sua tabella di distribuzione mainnet nomina un portafoglio multisignature Squads come autorità di aggiornamento.

Progetti di interoperabilità separati hanno mirato ai mercati istituzionali. Ad agosto, Interstice Digital ha annunciato un motore di swap cross-chain che collega Canton con Ethereum, Solana e Robinhood Chain. FalconX fornisce liquidità, mentre Interstice ha dichiarato di non detenere asset dei clienti né eseguire transazioni per conto degli utenti.