Iedereen bouwt agents en wallets. Bijna niemand vraagt zich af of de transacties ook daadwerkelijk worden afgewikkeld.
Agents betalen nu al voor dingen op Ethereum. Niet in een demo. x402 veranderde HTTP 402 in een live betalingsstroom, en agent‑wallets worden nu geleverd met sleutels en bestedingslimieten. Teams bouwen op de aanname dat een machine zelf haar verplichtingen kan afwikkelen zonder dat er een persoon in de buurt is.
De industrie heeft snel bewogen om agents de middelen te geven om te betalen, maar sloeg het deel eronder over. Een betaalrail gaat ervan uit dat de betaling doorgaat, en Ethereum is nooit op die aanname gebouwd. Inclusie is best effort: je dient in, en je hoopt dat het in het volgende blok terechtkomt. Een mens kan daaromheen werken door te zien dat een transactie vastloopt, de fee te verhogen en opnieuw te proberen. Je kunt een agent bouwen die hetzelfde doet. Wat je niet kunt bouwen is zekerheid: een retry is dezelfde gok nog een keer, in een markt die al is verschoven.
Geen van dit maakt veel uit bij één transactie. Het maakt enorm veel uit bij tienduizend per dag, wanneer elke handeling wacht op de vorige.
Ethereum wikkelt waarde af. Het plant waarde nog niet in.
Op Ethereum wordt blockspace toegewezen via een live veiling die ongeveer elke twaalf seconden wordt beslecht. Wanneer je een transactie indient, koop je geen gegarandeerde plek in het volgende blok. Je stapt in een competitie, en de uitkomst daarvan – zowel of je überhaupt wordt opgenomen als wat je uiteindelijk betaalt – blijft onbekend tot het al voorbij is. Dat ontwerp is elegant voor een permissionless netwerk. Het is ook vreemd ten opzichte van hoe institutionele financiën werken.
Instituten zitten al op Ethereum. Wat ze niet kunnen, is de strategieën draaien die garanties nodig hebben. Wanneer een desk niet vooraf kan weten of een transactie op tijd zal worden uitgevoerd of wat het zal kosten om zover te komen, kan ze er geen omvang achter zetten, dus blijft die activiteit off‑chain of verhuist naar een plek die de commitment wél maakt.
Jarenlang was het antwoord op de beperkingen van Ethereum throughput: meer transacties per seconde, meer rollups die de vraag uitwaaieren. Throughput is een maat voor hoeveel. Het zegt niets over wanneer. Dat is een probleem van tijd, niet van ruimte, en extra ruimte lost het niet op.
De kloof dichten
Verschillende benaderingen gaan nu richting implementatie, elk op een andere laag van het probleem.
Preconfirmations laten een proposer zich committeren om een transactie op te nemen of uit te voeren voordat het blok is gefinaliseerd. Dat is het meest directe antwoord op het timingprobleem: de agent hoeft niet langer te “indienen en hopen”. Maar de commitment moet iets betekenen. Er is brede validator‑deelname nodig, geloofwaardige economische backing en afdwingbare consequenties wanneer een proposer niet levert. Systemen die preconfirmations koppelen aan gestakete onderpand en slashing‑voorwaarden veranderen een belofte in een afdwingbare verplichting.
Inclusion lists werken op protocolniveau en beperken wat een builder mag weglaten. Dat maakt ze een krachtig middel tegen censuur. Maar ze lossen een ander probleem op: een transactie moeilijker te negeren maken is niet hetzelfde als je committeren aan wanneer hij wordt uitgevoerd. Een inclusion list legt een ondergrens vast. Ze legt geen schema vast.
Forward‑markten verlengen dat schema verder de toekomst in. Ze stellen instituten en applicaties in staat blockspace te reserveren voordat ze het nodig hebben, zoals energie, bandbreedte en rekencapaciteit vooruit worden gecontracteerd. Dat verandert toekomstige capaciteit in iets waar een koper omheen kan plannen, in plaats van er in real time om te concurreren. De ontwerpvragen hier gaan over marktstructuur: transparante toegang, door validators afdwingbare levering en mechanismen die voorkomen dat capaciteit wordt opgekocht door een klein aantal grote kopers.
Elke benadering kan beperkingen hebben waaromheen moet worden ontworpen. Samen vormen ze de contouren van een markt waar agents en instituten daadwerkelijk op kunnen bouwen: proposer‑commitments die iets betekenen, protocol‑niveau garanties tegen uitsluiting en forward‑capaciteit die met institutionele vraag meeschakelt. Individuele benaderingen hebben ontwerpvragen om op te lossen. De richting is duidelijk.
Een agent die een positie over twee venues afwikkelt, moet weten dat het tweede been landt voordat hij zich aan het eerste committeert. Zonder dat draait hij geen strategie. Hij plaatst een weddenschap en wacht af.
Ethereum heeft al geloofwaardige settlement gebouwd. De volgende uitdaging is om toegang tot die settlement vooraf programmeerbaar te maken. Als agents kapitaal op machine‑snelheid gaan coördineren, kan blockspace niet iets blijven waar ze alleen op bieden en hopen het te krijgen. Het moet iets worden dat ze kunnen inplannen.