En “HFT Layer-1” er ikke hurtigere crypto. Det er et nyt regelsæt for en børs.

Hvert par år forsøger nogen at “gøre markeder hurtigere” ved at ændre på selve infrastrukturen. Pitch’et er altid teknisk: lavere latenstid, højere throughput, færre hops, bedre UX.

Men i det øjeblik du fjerner den offentlige kø, accelererer du ikke bare en blockchain. Du skriver et nyt regelsæt for en børs.

I praksis er den offentlige mempool en rodet, uperfekt form for transparens. Alle kan se ventesalen. De kan udlede, hvad der sandsynligvis sker som det næste. Når du erstatter det med streamede transaktioner og preconfirmation, flytter du ordering power opstrøms til den, der kontrollerer admission og sequencing. Den aktør bliver et de facto matching layer — uanset om de kalder sig validator, sequencer, builder eller noget fjerde.

Jeg har bygget og drevet systemer, hvor hastighed var afgørende, inkl. mit eget arbejde med trading systems med indikatorer og automation. Jeg har også ledet organisationer, hvor driftssikkerhed var vigtigere end elegance — fx da jeg havde ansvar for operations på tværs af engineering, produktion og supply chain i electrification og energy storage. Læren er den samme: hastighed er billig, tillid er dyr. Når du komprimerer tid, forstærker du fejl. Når du privatiserer ordering, skaber du et nyt sted at udtrække rent — medmindre du designer til auditérbarhed og fair allokering fra dag ét.

Dette essay er et tidløst operator-perspektiv på “HFT Layer-1”-designs. Ikke som crypto-teater. Som market structure.

Den tekniske ændring, der bliver til en governance-ændring

En offentlig mempool er en offentlig kø. Den er støjende og kan games, men den er læsbar. Deltagere kan overvåge den, bygge strategier omkring den og i det mindste diskutere fairness med et fælles datagrundlag.

Fjern den, og du skaber en informationsasymmetri by design. Nu er der et privat intake. Der er preconfirmation, som i praksis er et løfte om fremtidig ordering. Der er streamet flow, som i praksis er et privilegeret feed.

På det tidspunkt er kerneproduktet ikke længere “blockspace”. Produktet er:

• Ordering policy: hvem kommer ind først, og efter hvilke regler.
• Allokering: hvordan prioritet sælges, optjenes eller fordeles.
• Dispute handling: hvad der sker, når preconfirmation kolliderer med endelig inclusion.
• Accountability: hvem der efterfølgende kan dokumentere, hvad der skete — med beviser.

Derfor bør disse designs vurderes som et exchange launch — ikke som en benchmark-graf.

Når ordering er privat, bliver MEV “forretningsmodellen”

Operatører kan lide at lade som om, at MEV er en bug. I private ordering-systemer er det ofte forretningsmodellen — bare ikke altid navngivet sådan.

Hvis én part kontrollerer ordering og kan forpligte sig via preconfirmation, kontrollerer de forskellen mellem “jeg så flowet først” og “jeg reagerede først”. Den forskel er spreadet. Det kan vise sig som eksplicitte fees, implicit slippage eller uigennemsigtig priority pricing. Uanset hvad: nogen indkasserer den.

Der findes kun tre holdbare udfald:

1. Du accepterer rent collection og behandler det som prisen for execution quality, som at betale for et venue. Fair nok — men så skal du også regulere det internt med regler, audits og håndhævelse.
2. Du commoditizer ordering via transparente auktioner og verificerbar fairness. Svært, men muligt, hvis allokeringsmekanismen er læsbar og auditérbar.
3. Du foregiver decentralisering samtidig med at du centraliserer magten. Det er den ustabile vej. Den ender med reputationsskade, regulatorisk pres og at de mest sofistikerede deltagere går et andet sted hen.

I bestyrelsesterminologi er spørgsmålet ikke “Er det hurtigt?” Spørgsmålet er: “Hvem ejer ordering — og hvad forhindrer dem i at beskatte alle andre?”

Hurtigere markeder kræver broker-grade controls — ikke mere TPS

Når du har designet den offentlige ventesal væk, arver du et andet sæt svære problemer. Det er de samme problemer, som alle seriøse venues, brokers eller clearing-nære systemer håndterer:

• Pre-trade risk limits: ikke efter handlen. Før. Maks. ordrestørrelse, maks. notional, maks. message rate, maks. åben eksponering.
• Credit throttles: hvad der sker, når en agent handler på delegeret kapital. Du har brug for dynamiske credit lines, ikke statiske balancer.
• Kill switches: pr. konto, pr. strategi, pr. API key — og venue-wide. Ikke “pause chainen”. En præcis stopknap. Jeg skrev om dette design pattern i AI value and the stop button, og det gælder her også.
• Surveillance: detektion af manipulation, abusive quoting patterns, wash-adfærd, cross-venue games. Hvis du ikke kan detektere det, subsidierer du det.
• Incident playbooks: når preconfirmations fejler, når ure driver, når en sequencer opfører sig forkert, når der opstår network partitions. “Vi fikser det” er ikke en plan.

Da jeg byggede IBHQ, en SaaS-platform til Introducing-Broker-forretninger, var det tilbagevendende tema control planes. Brokers lever og dør på risk gates — ikke på pæne UIs. Venue’et kan være hurtigt, men hvis du ikke kan håndhæve limits ved admission, ender du med at give nøglerne til det mest aggressive flow. Så betaler alle andre gennem blowups, clawbacks eller skjulte omkostninger.

Hastighed uden gates er ikke innovation. Det er leverage.

En enkel beslutningslinse: Hvem er dommeren — og kan vi auditere spillet?

Hvis du er bestyrelsesmedlem, ejer eller operatør, der vurderer et private-ordering L1-design, ville jeg drive diskussionen ind i fem konkrete spørgsmål. Du kan bruge dem allerede i dette kvartal — uanset om du bygger venue’et, integrerer med det eller allokerer kapital til det.

1) Hvad er ordering policy — i almindeligt sprog?

Hvis svaret kræver et whitepaper at afkode, har du et governance-problem. Ordering rules skal kunne forklares til en risk committee på fem minutter.

2) Hvordan allokeres prioritet — og kan det verificeres?

Er det first-come-first-served baseret på receipt time? Er det auktioneret? Er det relationship-baseret via et privat stream? Uanset hvad, vil du have to egenskaber: forudsigelighed og auditérbarhed.

3) Hvad er dispute-modellen mellem preconfirmation og finality?

Preconfirmation er et løfte. Løfter kræver remedies. Hvad sker der, når løftet brydes? Hvem betaler? Hvordan produceres evidens? Hvis den eneste remedy er “social consensus”, driver du en klub — ikke et marked.

4) Hvor ligger risk gates — og hvem kontrollerer dem?

Venue-level gates bør være indbygget og håndhævet ved kanten. Participant-level gates bør kunne konfigureres og bevises. Hvis alle gates er eksterne, får du systemiske events. Hvis alle gates er interne og uigennemsigtige, får du trust decay.

5) Hvordan måler I execution quality uden self-reporting?

Du har brug for uafhængige metrics. Ikke kun TPS. Tænk i slippage-distributioner, inclusion-forudsigelighed, cancellation-effektivitet og tail-adfærd under stress.

Det er samme mindset, jeg har brugt i industrielle kontekster. I power electronics kan du ramme en lab spec og stadig fejle i felten, hvis du ikke kontrollerer varians, stress cases og error budgets. Driftssikkerhed er en kontrakt, du håndhæver — ikke en feature, du påstår. Jeg sagde det direkte i Ruggedization is a reliability contract. Markeder er ikke anderledes.

Den ubekvemme sandhed: Deltagere accepterer centralisering, hvis reglerne er rene

Mange builders antager, at brugere kun går op i decentralisering som princip. I praksis går seriøse deltagere op i:

• Fill quality.
• Forudsigelige regler.
• Lav dispute-risiko.
• Klar recourse, når noget går i stykker.

De vil acceptere et mere centraliseret ordering layer, hvis det giver dem de outcomes — især når alternativet er en støjende offentlig kø, hvor de bliver picked off.

Men det virker kun, hvis venue’et behandler ordering og preconfirmation som regulerede overflader, også når ingen regulator tvinger jer. Med andre ord: I skal styre jer selv som en børs, fordi I reelt er ved at blive en.

Det betyder transparente policies, audit logs, surveillance og reelle konsekvenser ved misbrug. Det betyder også at indrømme en sandhed, mange teams undgår: hvis I vil have “institutional” flow, så ender I med at shippe broker-grade controls — og I kommer til at sige nej til nogle deltagere.

Min holdning: Design regelsættet først — og ship derefter hastigheden

En “HFT Layer-1” er ikke en performance-opgradering. Det er et market redesign. Vinderne bliver ikke teams med den bedste latency-historie. Vinderne bliver teams, der kan svare operationelt på, hvem der kontrollerer ordering, hvordan rents begrænses, og hvordan fejl håndteres.

Hvis du bygger en, så start ikke med throughput. Start med governance: ordering policy, auditérbar allokering, dispute mechanisms og risk gates, der virker under stress.

Hvis du integrerer med en, så start ikke med connectivity. Start med måling af execution quality, limit frameworks og en kill switch, du kan trigge med én handling.

Hastighed er let at købe. Tillid er dyrt at fortjene. Private ordering-systemer kan være det værd — men kun hvis regelsættet er eksplicit, håndhæveligt og auditérbart.