Tutti costruiscono agenti e wallet. Quasi nessuno si chiede se le transazioni vengano davvero finalizzate.
Gli agenti stanno già pagando per cose su Ethereum. Non in una demo. x402 ha trasformato l’HTTP 402 in un flusso di pagamento live, e i wallet per agenti ora sono distribuiti con chiavi e limiti di spesa. I team stanno costruendo partendo dall’assunzione che una macchina possa regolare i propri obblighi senza una persona vicino.
Il settore si è mosso in fretta per dare agli agenti i mezzi per pagare, ma ha saltato la parte sottostante. Un sistema di pagamento dà per scontato che il pagamento vada a buon fine, e Ethereum non è mai stata costruita su questa ipotesi. L’inclusione è “best effort”: invii, e speri che la transazione entri nel blocco successivo. Un essere umano può aggirare il problema osservando una transazione bloccata, alzando la fee e riprovando. Puoi costruire un agente che faccia lo stesso. Ciò che non puoi costruire è la certezza: un retry è la stessa scommessa piazzata di nuovo, in un mercato che nel frattempo si è già mosso.
Nulla di tutto questo conta molto su una singola transazione. Conta enormemente su diecimila al giorno, quando ogni azione dipende da quella precedente.
Ethereum regola valore. Non ne pianifica ancora il regolamento.
Su Ethereum, lo spazio di blocco è allocato tramite un’asta continua che si risolve circa ogni dodici secondi. Quando invii una transazione, non stai comprando un posto garantito nel blocco successivo. Stai entrando in una competizione, e il suo esito, sia se verrai incluso sia quanto pagherai alla fine, resta sconosciuto finché tutto è già concluso. Questo design è elegante per una rete permissionless. È anche estraneo al modo in cui funziona la finanza istituzionale.
Le istituzioni sono già su Ethereum. Quello che non possono fare è eseguire le strategie che richiedono garanzie. Quando un desk non può sapere in anticipo se una transazione verrà eseguita in tempo o quanto costerà farla passare, non può metterci dimensione, quindi quell’attività resta off‑chain o si sposta dove qualcuno è disposto a prendere l’impegno.
Per anni la risposta ai limiti di Ethereum è stata la capacità: più transazioni al secondo, più rollup che diramano la domanda. La capacità misura il “quanto”. Non dice nulla sul “quando”. Questo è un problema di tempo, non di spazio, e aggiungere più spazio non lo risolve.
Colmare il divario
Diverse soluzioni stanno ora entrando in fase di implementazione, ciascuna affrontando un livello diverso del problema.
Le pre‑conferme permettono a un proposer di impegnarsi a includere o eseguire una transazione prima che il blocco sia finalizzato. È la risposta più diretta al problema del timing: l’agente non deve più inviare e sperare. Ma l’impegno deve significare qualcosa. Servono un’ampia partecipazione dei validatori, solide garanzie economiche e conseguenze applicabili quando un proposer non mantiene la promessa. Sistemi che abbinano pre‑conferme a collaterale in staking e condizioni di slashing trasformano una promessa in un obbligo responsabile.
Le inclusion list operano a livello di protocollo, limitando ciò che un builder è autorizzato a escludere. Questo le rende uno strumento potente contro la censura. Ma risolvono un problema diverso: rendere una transazione più difficile da escludere non equivale a impegnarsi su quando verrà eseguita. Un’inclusion list imposta un pavimento. Non imposta un calendario.
I mercati forward estendono quel calendario più in là nel futuro. Consentono a istituzioni e applicazioni di prenotare spazio di blocco prima che ne abbiano bisogno, nello stesso modo in cui energia, banda e capacità di calcolo vengono contrattualizzate in anticipo rispetto alla domanda. Questo trasforma la capacità futura in qualcosa attorno a cui un acquirente può pianificare, anziché competere in tempo reale. Le questioni di design qui riguardano la struttura di mercato: accesso trasparente, consegna responsabilizzata dai validatori e meccanismi che impediscano che la capacità venga accaparrata da pochi grandi acquirenti.
Ogni approccio può avere vincoli da aggirare con il design. Insieme, danno la forma di un mercato su cui agenti e istituzioni possono davvero costruire: impegni dei proposer che valgono qualcosa, garanzie a livello di protocollo contro l’esclusione e capacità futura che scala con la domanda istituzionale. I singoli approcci hanno ancora questioni progettuali da risolvere. La direzione, però, è chiara.
Un agente che chiude una posizione su due venue deve sapere che la seconda gamba verrà finalizzata prima di impegnarsi sulla prima. Senza questo, non sta eseguendo una strategia. Sta facendo una scommessa e aspettando l’esito.
Ethereum ha già costruito un regolamento credibile. La prossima sfida è rendere programmabile in anticipo l’accesso a quel regolamento. Se gli agenti devono coordinare capitale alla velocità delle macchine, lo spazio di blocco non può restare qualcosa su cui semplicemente si fa un’offerta sperando di ottenerlo. Deve diventare qualcosa che possono programmare a calendario.