3 augustus 2026

Overzicht

runner.exchange is een token-launchpad op Robinhood Chain. Iedereen kan meteen een token lanceren. Aankopen en verkopen worden geprijsd door een bonding curve, en zodra een curve zijn graduation-drempel haalt, graduert het token: de curve wordt omgezet in een permanent vergrendelde liquiditeitspool die eigendom is van het launchpad. Er wordt geen LP-token aangemunt en er is geen enkele terugtrekroute. Die laatste zin is het hele product. Elke ontwerpbeslissing volgt daaruit. Ik heb beide helften gebouwd: de Solidity-contracten en de handelsinterface.

Het probleem waartegen het is gebouwd

De launchpad-categorie heeft een reputatieprobleem dat ze zelf heeft verdiend. De klassieke mislukking is de rug: er wordt liquiditeit aangeleverd, het token stijgt, en dan verdwijnt de liquiditeit. De meeste platformen pakken dit aan met beloftes — een lockperiode, een multisig, een engagement van het team, een audit-badge. Het uitgangspunt hier is dat een belofte het verkeerde instrument is. Als liquiditeit kan worden teruggetrokken, is de enige vraag of iemand ervoor kiest. Daarom zit de gegradueerde pool intern in het launchpad-contract en heeft ze helemaal geen withdraw-functie. Geen timelock. Geen vertrouwde bewaarder. Er is geen codepad dat ze verwijdert. De tagline op de site zegt het mechanisme gewoon: elk token verdient zijn uitgang. Een token handelt op zijn curve tot het genoeg reëel handelsvolume heeft verzameld om te gradueren, en dan wordt zijn liquiditeit voor altijd vergrendeld en gaat de handel ertegen verder.

Ontwerpen in een vijandige context

Een handelsinterface ontwerpen is anders dan de meeste producten, omdat een deel van je gebruikers actief vijandig is en de rest snel beweegt met geld.

• De interface is monospaced en typografisch, dichter bij een terminal dan bij een fintech-app. Dat is geen nostalgie. Cijfers in een proportioneel lettertype zijn moeilijker te vergelijken in één oogopslag, en dit is een scherm waar een verkeerd gelezen cijfer geld kost.
• Mechanieken worden benoemd, niet gepromoot. De infopagina begint met hoe graduation werkt en wat de eigenaar wel en niet kan, niet met rendementen. In een categorie die op hype draait, is de beperkingen beschrijven de pitch.
• Laadtoestanden zijn ontworpen, niet afwezig. Chain-data komt laat en in willekeurige volgorde binnen. Skeleton-kaarten en een expliciete "feed laden"-status bestaan zodat een traag blok nooit leest als een kapotte pagina of, erger, als een nulsaldo.
• De launch-flow is een formulier dat zichzelf uitlegt. Kiezen tussen bonding-curve-modus en instant-listing is de belangrijkste beslissing die een maker neemt, dus beide opties worden volledig beschreven op het moment van de keuze, niet in documentatie.

Wat de eigenaar niet kan

Het vertrouwensmodel van een launchpad wordt bepaald door zijn adminrechten, dus daarover moet je expliciet zijn. De eigenaar kan het fee-tier-schema na graduation aanpassen, on-chain begrensd op 3% in totaal, en dat heeft effect op live pools — een eerlijke consequentie van dynamische fees. De eigenaar kan de handel niet pauzeren, niet aan de ETH van de curve of de reserves van vergrendelde pools komen, geen tokens minten of verplaatsen, de gesnapshot parameters van een live curve niet wijzigen en de contracten niet upgraden. Na deployment ligt het eigenaarschap bij een multisig Safe achter een timelock-controller, en de deployment-runbook behandelt de overdracht als een poort: het systeem geldt pas als live nadat runner.owner() == timelock on-chain is geverifieerd. Opschrijven wat je niet kan, is nuttiger dan opsommen wat je belooft niet te doen.

Architectuur

Contracten. Een Foundry-project met vastgepinde toolchain-versies en gecompileerd via-IR. Eén singleton launchpad-contract bevat zowel de curve-logica als de vergrendelde automated market maker, met per launch een ERC-20-token met vaste supply. Curveparameters moeten voldoen aan een exacte integer-landing-gelijkheid die on-chain wordt gecontroleerd — ze worden door een script gegenereerd, nooit met de hand geschreven, zodat een curve niet kan worden gedeployed in een staat waarin de graduation-wiskunde niet sluit. Testen. Unit-, fuzz- en invariant-suites over de curve, de hook en de router, inclusief een apart audit-testbestand en een pin-poisoning-test. Invariant-testing is hier belangrijker dan unit-testing: de eigenschap die moet blijven gelden is niet "deze functie geeft het juiste getal terug" maar "het saldo van het contract dekt altijd elke live curve, elke vergrendelde pool en alle niet-geïnde fees". Een operations-script controleert precies die solvabiliteitseigenschap op het gedeployde contract. Indexer. De handelsinterface bevraagt de chain niet één keer per gebruiker. Een gedeelde in-memory snapshot wordt op een timer ververst en aan elke client geserveerd, met een configureerbare reorg-diepte zodat een gereorganiseerd blok niet als spooktransacties opduikt. Drie omgevingsvariabelen ruilen latentie tegen RPC-kost, waarbij het server-syncinterval de enige echte kosteknop is. In productie wordt de snapshot bewaard in Netlify Blobs, waar het verliezen ervan een rescan kost en niets anders.

Gebruikte technologieën

• Contracten: Solidity 0.8.30 met Foundry, gecompileerd via-IR; unit-, fuzz- en invariant-testsuites.
• Frontend: Next.js met wagmi v2 en viem voor chain-interactie, TanStack Query voor data, lightweight-charts voor prijsgrafieken.
• Extra's: LiveKit voor live audio in de handelsruimtes, React Three Fiber voor visuele stukken, Supabase voor off-chain data.
• Infrastructuur: Netlify met Blobs voor de indexer-snapshot; een Safe achter een timelock-controller als eigenaar van de contracten.
• Operations: deployment-runbook, on-chain verificatiebundels en een script voor de solvabiliteitscheck.

Uitdagingen en lessen

Permanentie moet structureel zijn. Het zou veel eenvoudiger zijn geweest om een timelocked withdraw te shippen en dat "vergrendelde liquiditeit" te noemen. De functie volledig weghalen is een moeilijker ontwerp, want het sluit opties af — ook het herstellen van je eigen fouten. Dat is de prijs van een garantie die echt is, en de reden waarom de parametergeneratie en het invariant-testen zo streng moesten zijn. Je kan geen pool patchen die je niet kan aanraken. Chain-data is geen database. Blokken reorganiseren, RPC-endpoints rate-limiten, en een naïeve interface die per gebruiker pollt maakt van een populaire launch een zelfveroorzaakte outage. De indexer met een gedeelde snapshot en een expliciete confirmatielag was het verschil tussen een demo en iets dat zijn eigen traffic overleeft. Het beste beveiligingswerk is leesbaar. Een security review die niemand leest, beschermt niemand. De adminrechten neerzetten als een korte, begrensde lijst — inclusief het ene recht dat behouden blijft en waarom het gebruikers raakt — doet meer voor vertrouwen dan een audit-badge, omdat een lezer het echt tegen de code kan checken.

Resultaat

Een launchpad waarvan de centrale claim verifieerbaar is in plaats van beloofd: liquiditeit die graduert in een pool zonder uitgang, fees die na de graduation blijven doorlopen, en een eigenaar wiens rechten een korte lijst zijn die een scepticus in een minuut kan lezen. De interface is gebouwd voor wie cijfers snel leest, en de contracten voor wie ze probeert te breken.