Je bent hier · Markt-radar · alles van de routine komt hier binnen
📡 Markt-radar
Alles wat de routine r4m vindt komt hier binnen: vondsten van de tien sporen,
funding en subsidiedeadlines, juridische statuswijzigingen, audit-vonnissen, testbewijs,
bouwvoorstellen en prospects. Doel: 5 à 15 items per nacht, elk met bron en datum.
Gewijzigd op 31-08-2026. Tussen 30 en 31 augustus stond hier een poort: de routine diende items in en jij moest ze goedkeuren vóór ze verschenen. Dat werkte niet — de nachtrun van 31-08 vond drie volwaardige vondsten en ze bleven alle drie in de wachtrij hangen, zodat deze pagina van die nacht leeg bleef. De routine schrijft nu weer rechtstreeks, in dezelfde run. Wat hieronder staat is dus geen voorstel meer maar wat er gevonden is. De beslislus blijft bestaan voor de enkele vragen waar écht een keuze van jou nodig is.
laden…
40 · Dageraad — markt-radar, dagelijks aangevuld door de routine
1230 · ROSE📈 Markt-radar — hoe dit in de markt gezet wordt (dagelijks aangevuld)OPEN →
De nachtploeg (03:00) en day-and-night (4×/dag) posten hier hun geverifieerde marktvondsten: wat er in de markt beweegt, met bron, en hoe jij dat gebruikt om R4M te positioneren. Nieuwste bovenaan.
Schiften:
05-09
💶 FUNDING-BUUR OF PRIJSPROBLEEM — Didit geeft de uniciteitscontrole gratis weg, wij wilden er €0,10–0,30 per keer voor — Didit (identiteitsverificatie, San Francisco, gesteund door Y Combinator en Robinhood Ventures) publiceert op didit.me/solutions/gig-worker-verification (gelezen 05-09-2026) een volledig tarief voor de gig-niche: volledige KYC $0,33 per werker, AML-screening $0,20, samen $0,53, doorlopende AML $0,07 per werker per jaar, 500 gratis verificaties per maand — en “Face Search 1:N — Free, included in every workflow”. Dat 1:N is precies “dezelfde mens achter meerdere accounts”. Dit beantwoordt de vraag die sinds 29-08 drie keer open stond in het use-case-grootboek: wat betaalt een platform per her-verificatie. Antwoord: minder dan wij vragen, en de kerncontrole is gratis. Zo zet je dit in de markt: stop met “wij zijn goedkoper” in de gig-niche — dat argument is dood. Verkoop de twee dingen die Didit per constructie niet heeft: hun 1:N werkt binnen één platform, dus dezelfde mens op twee platformen blijft twee mensen, terwijl een eID-wortel één mens is over alle platformen heen; en hun controle is biometrie, dus artikel 9 AVG met verwerkingsgrond en DPIA, waar een attestatie op een eID-wortel geen biometrisch gegeven bij de klant legt. Voor één-burger-één-stem bij gemeenten is dat tweede punt geen nuance maar het hele verschil.
05-09
🚨 CORRECTIE OP HET EIGEN BORD — de VLAIO-kaart toonde negen dagen een deadline die zijn eigen tekst al had weerlegd — De kaart “VLAIO Innovatieve Starterssteun” op de Subsidies-tab droeg het label “sluit 07-09-2026 · nog 7 dagen”, terwijl de tekst in diezelfde kaart sinds 27-08 zegt: doorlopende indiening, geen sluitingsdatum, en die 07-09 was één pitchvenster. Het label is wat je ziet; de tekst moet je opendoen. Overmorgen was die valse klok vanzelf verstreken en had de regel eruitgezien als een gemiste kans van €50.000. Vandaag rechtgezet, met de correctie zichtbaar op de kaart zelf. De bron gaf opnieuw HTTP 403, dus dit is het doorzetten van de al geverifieerde correctie van 27-08, geen nieuwe verificatie. Zo zet je dit in de markt: niets naar buiten — dit is intern. Maar de echte actie op deze regel is wél extern en staat nog altijd open: bel één erkende VLAIO-partner (UNIZO of Voka) voor een plaats in een pitchronde, en laat die adviseur eerst de leeftijdscheck doen op het oudste gekoppelde ondernemingsnummer. Dat is de ja/nee-poort, geen datum.
05-09
⏱ FUNDING-KLOK — vier harde dagen voor Base Batches, negen voor Start it @KBC, en de infosessie is er al over drie — Vierde controle op rij aan de bron, alle drie ongewijzigd. Base Batches 004 sluit woensdag 9 september ($100K uit het Base Ecosystem Fund, ~10 teams; uitsluitsel 17-09, virtueel programma 21-09 tot 15-11). Start it @KBC sluit 14 september (equity-free, 65 plaatsen, één jaar) — maar de klok die nu telt is de online infosessie van dinsdag 8 september, over drie dagen, waar de programmamanager vragen beantwoordt. Daar hoort de solo-vraag gesteld, want vier controles lang zegt geen enkele bron of een eenmansdossier mag. imec.istart sluit 30-09, nog 25 dagen, knop actief, bedrag nog steeds niet door de bron bevestigd. Eurostars sluit 10-09 maar blijft onhaalbaar solo en gaf vandaag 403. Zo zet je dit in de markt: de goedkoopste handeling op het hele bord is je inschrijven voor die infosessie van 8 september — vijf minuten, en het bepaalt of negen dagen dossierwerk zin heeft.
05-09🧪 VOORSTEL + TEST — de beloofde “geautomatiseerde jargon-controle” bestond uit één assertie; nu 386 groen over alle consumerpaden — Het conformiteitsraamwerk belooft dat geen enkele gebruikerstekst munt-jargon bevat en dat “an automated jargon-check enforces it”. Die afdwinging dekte in werkelijkheid één endpoint op het gelukkige pad. Nieuwe tak voorstel/2026-09-05-jargonwacht-alle-consumerpaden (commit 8815819) dekt alle vijf de consumer-endpoints op hun gelukkige én foutpaden — 401, 403, 404 en 400 in negen varianten — plus het geval waarin iemand een 0x-adres in het IBAN-veld plakt. Uitkomst: nul lekken; de belofte hield al stand, ze was alleen nergens vastgelegd. De wacht is met een mutatie getoetst zodat hij aantoonbaar kán afgaan. Verificatie:
npm test 386 groen, 2 overgeslagen, 64 bestanden (was 383 in 63), typecheck schoon, server boot op 4021 met HTTP 200, npm run demo volledig door met alle vijf boekhoudinvarianten groen. Herhaalbaar met npx vitest run test/jargonwacht.test.ts. Zo zet je dit in de markt: niet als functie, wel als bewijsstuk — bij een stad of toezichthouder die vraagt hoe je garandeert dat gebruikers nooit met muntjargon geconfronteerd worden, is “er staat een test op die faalt zodra het gebeurt” een ander antwoord dan “dat doen we niet”. Franky beslist over de merge; de tak is niet samengevoegd.05-09📋 OCHTENDRAPPORT 05-09 — negen vondsten van de nacht, en de noordster kreeg voor het eerst een datum — Het rapport over het venster 04-09 08:30 → 05-09 08:30 staat live op de Ops-tab. De kern: het Europees burgerinitiatief voor een onvoorwaardelijk basisinkomen is sinds 07-07-2026 geregistreerd bij de Commissie en begint op 04-01-2027 een miljoen keer te tellen dat één mens maar één keer mag tekenen — de eerste keer dat de noordster van dit project en het product in hetzelfde dossier vallen. Verder in het rapport: trinamiX tegen Apple over de levendheidslaag (03-09), Concordium dat onze zin al hardop zegt maar attributen bewijst in plaats van uniciteit, CleverX als ledger-entry 25 met oordeel PARTIAL, en drie kaarten van de regio-bladen waaronder Alipay AI Pay dat al binnen Claude Code betaalt via een Payment MCP Server in plaats van via x402. App-status: 383 van 385 groen, geen versiedrift op v0.36.7, maar de suite blijkt twee runs na elkaar niet te verdragen. Klanten-pijplijn: 56 prospects, 4 op benaderen, 0 gecontacteerd, 0 reacties. Zo zet je dit in de markt: het burgerinitiatief is geen klant maar wel de eerste gedateerde aanleiding waarin het woord basisinkomen en het woord uniciteit in hetzelfde document staan — het is het verhaal waarmee je élk ander gesprek opent, want het bewijst dat de vraag institutioneel is en niet bedacht.
05-09🔍 AUDIT ⏱ — het ochtendrapport van vrijdag is nooit geschreven, en dat is een dag lang door niemand gezien — Vastgesteld op 05-09-2026 08:1x tijdens de rapportagefase. Er bestaat geen commit met de boodschap
r4m ochtendrapport 04-09-2026 en er stond geen blok or-20260904 in de lijst. De nachtfase van 04-09 draaide wél en leverde zes radar-items plus een volledig dagrapport; alleen de samenvatting ontbrak. Het gat is vandaag gedicht: het rapport staat nu alsnog in de lijst met de badge NAGELEVERD, opgebouwd uit de commits en het dagrapport van díé nacht. Waarom dit een vonnis is en geen voetnoot: er bestaat een ketencheck.py die vijf andere ketens bewaakt en meteen meldt wanneer er één stilvalt — de ochtendfase van deze routine zit er niet in. Een fase die niet draait, kan niet melden dat ze niet draait; precies het patroon waar de SEO-keten zeven weken en de Artes-monitor drie maanden in vielen. Zo zet je dit in de markt: niets — dit is intern. Maar het is wel een beslispunt voor Franky: hoort de ochtendfase in de ketencheck thuis, zodat een gemiste ochtend zichzelf de volgende dag meldt?05-09📊 SEO-VLOOT — 8 van de 18 domeinen bewogen vandaag, en twee sites gaan tegelijk de andere kant op — Gemeten op 05-09-2026 03:48 via
/api/seo-watch. Acht domeinen dragen de datum van vandaag, tien niet — derde dag op rij dezelfde vlag. De ketencheck zet de SEO-meting zelf op nul dagen geleden, dus de keten draait; het is de dekking die achterblijft. Twee bewegingen die eruit springen. boombedrijfbisschop.be springt op mobiel van 65 naar 82 op Core Web Vitals, maar zakt tegelijk zes punten op desktop naar 90 — winst en verlies in dezelfde meting. idgs.eu verliest acht punten op mobiel, van 72 naar 64, met de blokkeertijd die van 250 naar 520 ms gaat; onsite blijft 95 en desktop blijft 97, dus het zit in de scripttijd en niet in de bouw. channel-zero.be klimt zes punten naar 70 en staat daarmee weer boven de val van 03-09, maar houdt met onsite 68 de laagste score van de acht gemeten sites. Drie domeinen gaven vandaag geen mobiel CWV-cijfer terug: turbeau2rock.com, qmtex.net en gevelsteenbedrijf-v6.pages.dev. Zo zet je dit in de markt: niet R4M maar de vloot — de twee die vandaag bewegen zijn allebei klantensites, en een sprong van zeventien punten is een mail waard vóór de klant het zelf ziet.05-09🆔 IDENTIFICATIE-CASE — de noordster staat sinds 7 juli als wettelijk instrument geregistreerd, en het tellen van één-mens-één-handtekening begint op 4 januari — De Europese Commissie registreerde op 07-07-2026 het Europees burgerinitiatief "Introduction of Unconditional Basic Income (UBI) throughout the EU" (citizens-initiative.europa.eu, 07-07-2026, persbericht IP/26/1524). De campagne zelf zet de klok: de officiële verzameling begint op 04-01-2027 (eci-ubi.eu, opgehaald 05-09-2026). Een burgerinitiatief heeft 1.000.000 geldige steunbetuigingen uit minstens zeven lidstaten binnen twaalf maanden nodig, en één mens mag maar één keer tekenen. Dit is de derde poging. De organisatoren schrijven als reden dat AI en robotica het levensonderhoud van arbeid moeten loskoppelen.
De bril, en die verandert de kop. maX heeft dit instrument al volledig uitgewerkt — case 32, de Europese Commissie en ECAS in Brussel, tot en met bijlage III bij verordening (EU) 2019/788 en het gegeven dat dubbels pas ná de sluiting door 27 nationale diensten worden uitgehaald. Wat maX niet heeft is dít initiatief: nul treffers op de titel in de hele site. De vondst is dus geen nieuw mechanisme maar een datum en een onderwerp: het enige Europese instrument dat per mens telt draagt vanaf januari de noordster van R4M als inhoud, en de klok start over vier maanden.
⚠️ Eerlijke begrenzing, meteen zelf zeggen. Een privaat attest vervangt de wettelijke controle van steunbetuigingen niet — dat is een opdracht van de lidstaten onder verordening 2019/788, en dat mag nooit gesuggereerd worden. Wat R4M wél kan is de laag vóór de indiening: één mens tekent één keer, meetbaar op het tekenmoment, in plaats van maanden later uitgesorteerd. En: de organiserende burgercommissie staat niet met naam op de pagina's die vannacht leesbaar waren — de campagne publiceert alleen
🔌 Integratievorm — webbuild-widget plus OIDC-knop, op de campagnepagina en niet in het systeem van de Commissie. (1) Draait al: de eID/itsme-route via Signicat en de attestatie-ondertekening — het statusblad meldt vannacht
🧩 Productmix — V, O en D; de rail doet níet mee. Er stroomt hier geen geld, dus alleen de attestatiekant. Meter M1 op elke nieuwe mens, M2 op elke hercontrole. Trede: attest-only. Groeipad: klein starten met de telling vóór de poort; de rail pas bijschakelen als er vergoedingen voor campagnewerk gaan lopen.
Zo zet je dit in de markt: dit is de eerste keer dat de noordster en het product in één dossier vallen — R4M hoeft hier niets uit te leggen over basisinkomen, alleen over tellen. Openingszin: "U hebt tot 4 januari om te bepalen hoe u ziet dat iemand twee keer tekent. Vandaag ziet u dat pas maanden na de sluiting, en dan kunt u er niets meer aan doen." Franky beslist of dit een prospect wordt; deze routine maakt er geen aan.
De bril, en die verandert de kop. maX heeft dit instrument al volledig uitgewerkt — case 32, de Europese Commissie en ECAS in Brussel, tot en met bijlage III bij verordening (EU) 2019/788 en het gegeven dat dubbels pas ná de sluiting door 27 nationale diensten worden uitgehaald. Wat maX niet heeft is dít initiatief: nul treffers op de titel in de hele site. De vondst is dus geen nieuw mechanisme maar een datum en een onderwerp: het enige Europese instrument dat per mens telt draagt vanaf januari de noordster van R4M als inhoud, en de klok start over vier maanden.
⚠️ Eerlijke begrenzing, meteen zelf zeggen. Een privaat attest vervangt de wettelijke controle van steunbetuigingen niet — dat is een opdracht van de lidstaten onder verordening 2019/788, en dat mag nooit gesuggereerd worden. Wat R4M wél kan is de laag vóór de indiening: één mens tekent één keer, meetbaar op het tekenmoment, in plaats van maanden later uitgesorteerd. En: de organiserende burgercommissie staat niet met naam op de pagina's die vannacht leesbaar waren — de campagne publiceert alleen
info@basic-income.eu. Lees het officiële registerblad vóór je contact opneemt.🔌 Integratievorm — webbuild-widget plus OIDC-knop, op de campagnepagina en niet in het systeem van de Commissie. (1) Draait al: de eID/itsme-route via Signicat en de attestatie-ondertekening — het statusblad meldt vannacht
itsme_eid ✓ en attestations ✓. (2) Franky bouwt: een campagne-widget die per bezoeker één attest afgeeft en de hash onthoudt, 3 à 5 dagen. (3) De klant doet: die widget op zijn eigen pagina zetten, vóór de doorklik naar het officiële verzamelsysteem. (4) Standaard: OIDC plus SD-JWT. (5) Kleinste demo zonder toestemming: een publieke demopagina op de eigen sandbox, met eigen data.🧩 Productmix — V, O en D; de rail doet níet mee. Er stroomt hier geen geld, dus alleen de attestatiekant. Meter M1 op elke nieuwe mens, M2 op elke hercontrole. Trede: attest-only. Groeipad: klein starten met de telling vóór de poort; de rail pas bijschakelen als er vergoedingen voor campagnewerk gaan lopen.
Zo zet je dit in de markt: dit is de eerste keer dat de noordster en het product in één dossier vallen — R4M hoeft hier niets uit te leggen over basisinkomen, alleen over tellen. Openingszin: "U hebt tot 4 januari om te bepalen hoe u ziet dat iemand twee keer tekent. Vandaag ziet u dat pas maanden na de sluiting, en dan kunt u er niets meer aan doen." Franky beslist of dit een prospect wordt; deze routine maakt er geen aan.
05-09🆔 IDENTIFICATIE-CASE — de laag die bewijst dat er een echt gezicht voor de camera zit, ligt sinds eergisteren bij een rechter — trinamiX (dochter van BASF, Ludwigshafen) diende op 03-09-2026 een klacht in bij de U.S. District Court for the Western District of Texas tegen Apple: zeven octrooien over het onderscheiden van menselijke huid van maskers en andere materialen tijdens gezichtsauthenticatie, gericht op iPhone 15, 16 en 17 en iPad Pro (Biometric Update, 04-09-2026). De techniek in geschil kijkt niet naar 3D-diepte maar naar hoe geprojecteerd licht terugkaatst, om te bepalen of een oppervlak zich optisch als huid gedraagt in plaats van als silicone of plastic — met near-infraroodcamera's, gestructureerd licht en een model dat op dat onderscheid getraind is.
De bril.
Waarom dit ons raakt. Elke selfie-check, elke leeftijdsschatting en elke heropening van een gigwerker-account leunt op precies deze laag: presentation attack detection. R4M's wortel is een staatsdocument via eID en itsme, geen eigen levendheidsclassificator — dat verschil is vandaag scherper dan gisteren, en het is voor het eerst met een dossiernummer te onderbouwen.
⚠️ Eerlijke begrenzing. Een octrooiklacht is geen vonnis. Apple heeft niet geantwoord, en of dit ooit één product raakt is vandaag onbekend. Gebruik het als risicovraag, nooit als feit over Apple.
🔌 Integratievorm — OIDC-knop naast de bestaande controle, niet in de plaats ervan. (1) Draait al: de itsme/eID-OIDC-flow en de attestatie-uitgifte. (2) Franky bouwt: niets nieuws — alleen de tweede-route-flow documenteren, één dag. (3) De klant doet: de knop naast zijn selfie-check zetten voor wie er niet doorheen komt. (4) Standaard: OIDC plus SD-JWT. (5) Demo: de bestaande sandbox, geen klantdata nodig.
🧩 Productmix — V en D, alleen de attestatiekant, meter M1 bij eerste verificatie en M2 bij hercontrole. Trede: attest-only. Groeipad: begin als uitwijkroute voor afgekeurde gebruikers, groei naar de standaardroute als de klant merkt dat de uitval verdwijnt.
Zo zet je dit in de markt: bij BE- en NL-klanten die vandaag volledig op een selfie-check leunen. Openingszin: "Uw levendheidscontrole is sinds deze week ook een licentievraag. Hebt u een tweede route als die ene leverancier morgen moet aanpassen?"
De bril.
trinamiX geeft nul treffers in de maX-site; Face ID komt voor maar in een ander verband; liveness staat in het dossier als techniek, nergens als octrooirisico.Waarom dit ons raakt. Elke selfie-check, elke leeftijdsschatting en elke heropening van een gigwerker-account leunt op precies deze laag: presentation attack detection. R4M's wortel is een staatsdocument via eID en itsme, geen eigen levendheidsclassificator — dat verschil is vandaag scherper dan gisteren, en het is voor het eerst met een dossiernummer te onderbouwen.
⚠️ Eerlijke begrenzing. Een octrooiklacht is geen vonnis. Apple heeft niet geantwoord, en of dit ooit één product raakt is vandaag onbekend. Gebruik het als risicovraag, nooit als feit over Apple.
🔌 Integratievorm — OIDC-knop naast de bestaande controle, niet in de plaats ervan. (1) Draait al: de itsme/eID-OIDC-flow en de attestatie-uitgifte. (2) Franky bouwt: niets nieuws — alleen de tweede-route-flow documenteren, één dag. (3) De klant doet: de knop naast zijn selfie-check zetten voor wie er niet doorheen komt. (4) Standaard: OIDC plus SD-JWT. (5) Demo: de bestaande sandbox, geen klantdata nodig.
🧩 Productmix — V en D, alleen de attestatiekant, meter M1 bij eerste verificatie en M2 bij hercontrole. Trede: attest-only. Groeipad: begin als uitwijkroute voor afgekeurde gebruikers, groei naar de standaardroute als de klant merkt dat de uitval verdwijnt.
Zo zet je dit in de markt: bij BE- en NL-klanten die vandaag volledig op een selfie-check leunen. Openingszin: "Uw levendheidscontrole is sinds deze week ook een licentievraag. Hebt u een tweede route als die ene leverancier morgen moet aanpassen?"
05-09⚙️ PROTOCOLWACHT — beide protocollen ongewijzigd sinds gisteren, en dat is vannacht de hele uitkomst — Gemeten op 05-09-2026 03:0x op de commits- en tags-API van
x402: sinds de meting van 04-09 kwamen er twee commits bij, allebei van 04-09 en allebei géén spec —
x401: laatste commit blijft
Zo zet je dit in de markt: een stille week aan de protocolkant is de week waarin de achterstand niet groeit. Dat is precies het moment voor het
x402-foundation/x402 en proof/x401.x402: sinds de meting van 04-09 kwamen er twee commits bij, allebei van 04-09 en allebei géén spec —
5df361d (fix(java): buffer response body until settlement succeeds, #3074) en 2cc7e9a (chore(go): release, #3359). Hoogste tag blijft pypi-x402@v2.22.0, de spec blijft v2. Geen achterstand, geen versiedrift. De receiverAuthorizer-vondst en de upfront-familie van 04-09 blijven de laatste beweging.x401: laatste commit blijft
f739b0e van 01-07-2026 — nu 66 dagen stil, tags nog steeds leeg. Geen nieuw feit, dus bewust geen apart item.Zo zet je dit in de markt: een stille week aan de protocolkant is de week waarin de achterstand niet groeit. Dat is precies het moment voor het
vct-profiel voor het uniciteitsattest dat op 02-09 als voorstel werd opgeschreven — werk dat niemand inhaalt terwijl je het doet.05-09💸 x402-lijn — de concurrent zegt onze zin al hardop, en zijn attest bewijst iets anders dan het onze — Concordium publiceerde op 28-07-2026 "x402 Explained: How AI Agents Pay, and Who Is Paying" en zet zijn positie in één regel: "x402 tells the agent how to pay. Concordium tells the seller who is paying." Hetzelfde stuk stelt vast dat x402 identiteit bewust weglaat: "Identity, KYC, and compliance do not appear in the specification. This is the protocol's philosophy, not an oversight." Hun integratie draait sinds juni 2026, gebouwd met Boosty Labs: de verkoper kan in de betaalstroom een attestatie opvragen met zero-knowledge-bewijzen (concordium.com, 28-07-2026).
De bril. maX kent Concordium al sinds 02-09 als "de eerste partij die aantoonbaar hetzelfde probleem in dezelfde laag aanpakt". Dit is dus geen ontdekking maar een aanscherping, en ze zit in wat het attest precies zegt: het artikel noemt leeftijd en rechtsgebied. Dat zijn attributen. Nergens staat dat dezelfde mens maar één keer voorkomt.
⚠️ Eerlijke begrenzing. Dit is een leesbevinding uit hun eigen artikel, geen test van hun product. Wat ze intern wél afdwingen weten we niet, en dat mag je in een gesprek niet omdraaien tot een verwijt.
Zo zet je dit in de markt: "wie is dit" en "hoeveel keer is dit dezelfde" zijn twee verschillende vragen, en Concordium beantwoordt de eerste. Gebruik hun eigen zin als opening en zet de tweede vraag ernaast: "U weet wie er betaalt. Weet u ook of het dezelfde is als vorige week onder een andere sleutel?"
De bril. maX kent Concordium al sinds 02-09 als "de eerste partij die aantoonbaar hetzelfde probleem in dezelfde laag aanpakt". Dit is dus geen ontdekking maar een aanscherping, en ze zit in wat het attest precies zegt: het artikel noemt leeftijd en rechtsgebied. Dat zijn attributen. Nergens staat dat dezelfde mens maar één keer voorkomt.
⚠️ Eerlijke begrenzing. Dit is een leesbevinding uit hun eigen artikel, geen test van hun product. Wat ze intern wél afdwingen weten we niet, en dat mag je in een gesprek niet omdraaien tot een verwijt.
Zo zet je dit in de markt: "wie is dit" en "hoeveel keer is dit dezelfde" zijn twee verschillende vragen, en Concordium beantwoordt de eerste. Gebruik hun eigen zin als opening en zet de tweede vraag ernaast: "U weet wie er betaalt. Weet u ook of het dezelfde is als vorige week onder een andere sleutel?"
05-09🚨 FUNDING — nog vier dagen voor Base, en de tijdlijn draagt nu ook het einde: demodag 17 november — Base Batches 004, vandaag opnieuw aan de bron nagelezen op base.org/batches: Applications Close — Sep 9, Acceptances Sent — Sep 17, Virtual Program — Sep 21 – Nov 15 en nieuw op dit bord: Demo Day — Nov 17. Harde datum, nog vier dagen. Het nieuwe stuk is niet de klok maar het einde ervan: je weet nu waar de verplichting ophoudt, niet alleen waar ze begint. En praktisch: tussen vandaag en de sluiting liggen nog twee werkdagen (maandag 7 en dinsdag 8 september).
Start it @KBC: deadline 14-09-2026 vandaag bevestigd aan de bron, online infosessie op 08-09-2026, en het programma is expliciet zonder geld en zonder aandelen — "FREE (no strings attached)", twaalf maanden, negen Belgische hubs. Wat er nog steeds niet staat: of een solo-oprichter toegelaten wordt. Dat blijft de vraag voor de infosessie van maandag, en die vraag is nu vier nachten oud.
Bronnenvondst erbij: het oude adres
Zo zet je dit in de markt: Base noemt agents en payments letterlijk als doelgebied, en dat ís deze rail. Dit is geen marktvondst maar een handeling met een klok erop.
Start it @KBC: deadline 14-09-2026 vandaag bevestigd aan de bron, online infosessie op 08-09-2026, en het programma is expliciet zonder geld en zonder aandelen — "FREE (no strings attached)", twaalf maanden, negen Belgische hubs. Wat er nog steeds niet staat: of een solo-oprichter toegelaten wordt. Dat blijft de vraag voor de infosessie van maandag, en die vraag is nu vier nachten oud.
Bronnenvondst erbij: het oude adres
startit.be/en/apply geeft HTTP 301 naar startit-x.com/en/accelerate/start-it-kbc. De merknaam is verhuisd — dat hoort in docs/BRONNEN.md en is precies het soort omleiding waar x402 V2 twee maanden in verdween.Zo zet je dit in de markt: Base noemt agents en payments letterlijk als doelgebied, en dat ís deze rail. Dit is geen marktvondst maar een handeling met een klok erop.
05-09⚖️ REGELGEVING — de verplichte MiCA-dubbelcheck: 331 vergunde aanbieders in Europa, nul in België — Vaste controleregel sinds 29-08: nooit één register alleen lezen, want het Belgische toezicht is verdeeld en één register lezen leidde toen tot een foute nul.
ESMA-kant: het MiCA-CASP-register telt 331 vergunde aanbieders met stand 02-09-2026, tegen 325 op 12-08-2026 — het register groeit ongeveer wekelijks. ⚠️ Zachtheid van dit cijfer, expliciet: de verzamelpagina van ESMA gaf vannacht HTTP 404, dus deze telling komt van registertrackers die het ESMA-register overnemen, niet van ESMA zelf. Behandel het als richtgetal, niet als bron.
FSMA-kant: België ging de MiCA-fase in zonder één vergunde CASP en heeft er nog steeds geen. Na het aflopen van de overgangsregeling op 01-07-2026 zette de FSMA zes entiteiten op zijn lijst van frauduleuze aanbieders: Aurum Foundation, Bank Bit, Bithf Pro, Dxago, Global Dynamic Trade en ZeriaFunding.
Wat dit met onze eigen trigger doet. Trigger 5 in
Zo zet je dit in de markt: de Belgische nul is géén marktnul. Onder MiCA vergunt de thuistoezichthouder en reist de vergunning mee over de 27 lidstaten — een gesprekspartner die zegt "er is hier niemand vergund" heeft het register van het verkeerde land gelezen.
ESMA-kant: het MiCA-CASP-register telt 331 vergunde aanbieders met stand 02-09-2026, tegen 325 op 12-08-2026 — het register groeit ongeveer wekelijks. ⚠️ Zachtheid van dit cijfer, expliciet: de verzamelpagina van ESMA gaf vannacht HTTP 404, dus deze telling komt van registertrackers die het ESMA-register overnemen, niet van ESMA zelf. Behandel het als richtgetal, niet als bron.
FSMA-kant: België ging de MiCA-fase in zonder één vergunde CASP en heeft er nog steeds geen. Na het aflopen van de overgangsregeling op 01-07-2026 zette de FSMA zes entiteiten op zijn lijst van frauduleuze aanbieders: Aurum Foundation, Bank Bit, Bithf Pro, Dxago, Global Dynamic Trade en ZeriaFunding.
Wat dit met onze eigen trigger doet. Trigger 5 in
SIGNALS_ADAPT.md vraagt om "FSMA publiceert eerste CASP-vergunningen". Die is niet afgegaan — en dat is precies waarom hij elke nacht gemeten wordt in plaats van verondersteld.Zo zet je dit in de markt: de Belgische nul is géén marktnul. Onder MiCA vergunt de thuistoezichthouder en reist de vergunning mee over de 27 lidstaten — een gesprekspartner die zegt "er is hier niemand vergund" heeft het register van het verkeerde land gelezen.
05-09📦 OMZET-LOPENDE-BAND — ledger-entry 25, en voor het eerst is het oordeel PARTIAL omdat de koper onze helft van het probleem al verkoopt — €100-moment #10 (B2B expert-interviews via inbox402) door het who-pays-filter van
Koper met naam: CleverX — 8 miljoen geverifieerde professionals in 150+ landen — naast User Interviews en de expert-netwerken van GLG-klasse. Prijsanker, vers aan de bron op 05-09-2026: $75–250 per uur voor B2B-professionals, $200–500+ voor executives en senior specialisten, $500–1.500+ voor C-suite en moeilijk bereikbare experts. Eén interview is dus een €100-moment in één uur.
Het gat staat opnieuw in de etalage van de verkoper zelf. Hun eigen pagina van 06-07-2026 beschrijft de controle als "LinkedIn profile cross-matching, employment database checks, company email validation, and/or manual review" en schrijft er zelf bij dat verificatie bij rekrutering fraude "reduces… but does not eliminate". Nergens staat één-mens-één-account, dubbele-accountpreventie of ontdubbeling over studies heen. Het cijfer erbij: 2 tot 8% van de deelnemers valt alsnog af bij de kwaliteitscontrole op een geverifieerd panel, tegen 15 tot 30% op een niet-geverifieerd panel (cleverx.com, 06-07-2026).
Waarom ⚠️ PARTIAL en geen PASS, en waarom dat de nuttigste uitkomst is. De duurste B2B-fraude is de gefakete functietitel — en dát is precies wat CleverX wél verkoopt en waar hun hele verificatie op gebouwd is. R4M's uniciteit lost de andere helft op: dezelfde mens die twee keer meedoet onder twee profielen. Die helft is bij hen niet geprijsd en niet beloofd. Koper bestaat, euro naar de burger bestaat, maar wij zijn hier de aanvulling en niet de vervanging. Dat verzwijgen zou het gesprek in de eerste vijf minuten laten stranden.
⚠️ Ook eerlijk: CleverX is een Amerikaans bedrijf (San Francisco volgens de meeste bronnen, Newark DE volgens één — vestiging niet hard vast te stellen) en heeft geen eID-wortel in zijn markt. Dat maakt het een koper om te verifiëren, niet een outreach-kandidaat voor een Belgische eenmanszaak.
Zo zet je dit in de markt: niet als "uw verificatie deugt niet", maar als de tweede vraag naast hun eerste: "U bewijst dat deze persoon inkoopverantwoordelijke is. Bewijst u ook dat het niet dezelfde persoon is als respondent 41 in dezelfde studie?"
USE_CASE_LEDGER.md en de doctrine-toets.Koper met naam: CleverX — 8 miljoen geverifieerde professionals in 150+ landen — naast User Interviews en de expert-netwerken van GLG-klasse. Prijsanker, vers aan de bron op 05-09-2026: $75–250 per uur voor B2B-professionals, $200–500+ voor executives en senior specialisten, $500–1.500+ voor C-suite en moeilijk bereikbare experts. Eén interview is dus een €100-moment in één uur.
Het gat staat opnieuw in de etalage van de verkoper zelf. Hun eigen pagina van 06-07-2026 beschrijft de controle als "LinkedIn profile cross-matching, employment database checks, company email validation, and/or manual review" en schrijft er zelf bij dat verificatie bij rekrutering fraude "reduces… but does not eliminate". Nergens staat één-mens-één-account, dubbele-accountpreventie of ontdubbeling over studies heen. Het cijfer erbij: 2 tot 8% van de deelnemers valt alsnog af bij de kwaliteitscontrole op een geverifieerd panel, tegen 15 tot 30% op een niet-geverifieerd panel (cleverx.com, 06-07-2026).
Waarom ⚠️ PARTIAL en geen PASS, en waarom dat de nuttigste uitkomst is. De duurste B2B-fraude is de gefakete functietitel — en dát is precies wat CleverX wél verkoopt en waar hun hele verificatie op gebouwd is. R4M's uniciteit lost de andere helft op: dezelfde mens die twee keer meedoet onder twee profielen. Die helft is bij hen niet geprijsd en niet beloofd. Koper bestaat, euro naar de burger bestaat, maar wij zijn hier de aanvulling en niet de vervanging. Dat verzwijgen zou het gesprek in de eerste vijf minuten laten stranden.
⚠️ Ook eerlijk: CleverX is een Amerikaans bedrijf (San Francisco volgens de meeste bronnen, Newark DE volgens één — vestiging niet hard vast te stellen) en heeft geen eID-wortel in zijn markt. Dat maakt het een koper om te verifiëren, niet een outreach-kandidaat voor een Belgische eenmanszaak.
Zo zet je dit in de markt: niet als "uw verificatie deugt niet", maar als de tweede vraag naast hun eerste: "U bewijst dat deze persoon inkoopverantwoordelijke is. Bewijst u ook dat het niet dezelfde persoon is als respondent 41 in dezelfde studie?"
05-09🧪 TEST — 383 van 385 groen op een schone start, en de suite blijkt twee runs na elkaar niet te verdragen — Gemeten op
Nieuw en niet eerder gemeld: de suite is niet meteen herstartbaar. De eerste run gaf 380 van 385 met drie tijdsoverschrijdingen van 5.000 ms (
Zo zet je dit in de markt: niet naar buiten, wel naar binnen. Zolang dit er staat, is elk testgetal dat níet uit een schone start komt onbruikbaar als bewijs — en dat raakt elke claim die we op "383 groen" bouwen.
main in /Volumes/8TB MM4/Rails4Mankind, werkboom schoon, read-only. Schone run: 63 bestanden, 383 geslaagd, 2 overgeslagen, 8,10 s. Geen versiedrift: repo v0.36.7 (VERSION, package.json én laatste tag) tegen live v0.36.7 op r4m-franky.fly.dev. De vier meetbare checks staan op waar: app_live, itsme_eid (sandbox), attestations, double_entry_ledger; settlement_adapter en email_login blijven configured zonder eigen verificatie, precies zoals hun eigen noot zegt. /api/public/reconciliation geeft HTTP 200. Netwerk base-sepolia, stage pilot, 2 attestaties op 1 unieke mens.Nieuw en niet eerder gemeld: de suite is niet meteen herstartbaar. De eerste run gaf 380 van 385 met drie tijdsoverschrijdingen van 5.000 ms (
portal, ratelimit, evidence). De tweede run, direct erna, liet dertien bestanden vallen — inclusief blokken die met de zaak niets te maken hebben (bounties 16 van 16, gate-verify 7 van 7). De derde run was weer volledig groen. Dat patroon wijst op een blijvende luisteraar of gedeelde toestand uit de vorige run, niet op kapotte code. Herhaalbaar: npm test driemaal snel na elkaar in de engine-repo. Niet gefixt — wijzigen aan de engine mag alleen op een voorstel/-tak, en dit is de vind-fase.Zo zet je dit in de markt: niet naar buiten, wel naar binnen. Zolang dit er staat, is elk testgetal dat níet uit een schone start komt onbruikbaar als bewijs — en dat raakt elke claim die we op "383 groen" bouwen.
05-09📋 STAND VAN DE SPOREN — negen items, en vier sporen die eerlijk leeg blijven — Wat er wél is: twee identificatie-cases (het EU-burgerinitiatief voor basisinkomen en de trinamiX-klacht tegen Apple), de protocolwacht op beide protocollen, de x402-aanscherping op Concordium, de fundingklok met een nieuw einde erin, de verplichte MiCA-dubbelcheck, ledger-entry 25 en de app-status.
Wat leeg blijft, met de reden erbij.
💶 Spoor B — geld-case: leeg, zesde run op rij. Het voorstel van 02-09 staat nog altijd open en onbeantwoord: draai de richting om en vertrek van de 56 bestaande prospects met de vraag welke geldstroom er vandáág al loopt, in plaats van te wachten tot het nieuws er een aanreikt. Dat wijzigt het mandaat en is aan Franky. Zonder die beslissing blijft dit blok elke nacht leeg — het is een methodeprobleem, geen marktprobleem.
📡 IoT-lijn: leeg. De CRA-meldplicht van 11-09-2026 staat al sinds 27-08 op de radar en is over zes dagen; geen nieuw feit, en een bekende klok opnieuw als nieuws brengen is precies wat de urgentie-regel verbiedt.
🤖 Agentic payments: leeg. De kandidaten van vannacht — RentAHuman, Human API, de agent-huurt-mens-markt — staan al in
⚡ Spoor D — nieuw toepassingsgebied: leeg. Geen kandidaat haalde de lat van echt bedrijf plus gedateerde bron plus concrete inplugweg. Niet opgevuld.
🎯 Spoor E — prospect: geen apart item. De enige echte kandidaat van vannacht is de campagne achter het burgerinitiatief, en die staat al in het eerste item — er twee items van maken zou dezelfde vondst twee keer tellen.
🔐 Spoor G — Secure Mail: niet gedraaid, dat spoor is voorbehouden aan maandag en vandaag is zaterdag. Geen inhaalpoging.
Doorloop-API: bereikbaar, 47 items, nul op
Oppervlakte-check: beide oppervlakken HTTP 200 (
Formaat-noot: deze negen items dragen lokale letterbadges en geen Google-favicons — het bestand volgt de beslissing van commit
Wat leeg blijft, met de reden erbij.
💶 Spoor B — geld-case: leeg, zesde run op rij. Het voorstel van 02-09 staat nog altijd open en onbeantwoord: draai de richting om en vertrek van de 56 bestaande prospects met de vraag welke geldstroom er vandáág al loopt, in plaats van te wachten tot het nieuws er een aanreikt. Dat wijzigt het mandaat en is aan Franky. Zonder die beslissing blijft dit blok elke nacht leeg — het is een methodeprobleem, geen marktprobleem.
📡 IoT-lijn: leeg. De CRA-meldplicht van 11-09-2026 staat al sinds 27-08 op de radar en is over zes dagen; geen nieuw feit, en een bekende klok opnieuw als nieuws brengen is precies wat de urgentie-regel verbiedt.
🤖 Agentic payments: leeg. De kandidaten van vannacht — RentAHuman, Human API, de agent-huurt-mens-markt — staan al in
cases-db.json, verdienmodel.html en de radar, inclusief de vaststelling dat RentAHuman zijn eigen aantallen tegenspreekt. Geen nieuw feit. Trigger 3 (verdien-kant) niet afgegaan: geen enkele partij voegde vannacht een uniciteits- of anti-sybillaag toe aan een platform dat mensen laat verdienen.⚡ Spoor D — nieuw toepassingsgebied: leeg. Geen kandidaat haalde de lat van echt bedrijf plus gedateerde bron plus concrete inplugweg. Niet opgevuld.
🎯 Spoor E — prospect: geen apart item. De enige echte kandidaat van vannacht is de campagne achter het burgerinitiatief, en die staat al in het eerste item — er twee items van maken zou dezelfde vondst twee keer tellen.
🔐 Spoor G — Secure Mail: niet gedraaid, dat spoor is voorbehouden aan maandag en vandaag is zaterdag. Geen inhaalpoging.
Doorloop-API: bereikbaar, 47 items, nul op
goedgekeurd (28 uitgevoerd, 12 beantwoord, 5 afgevoerd, 2 afgevinkt) — niets te verwerken.Oppervlakte-check: beide oppervlakken HTTP 200 (
r4m-founder 98.018 b, r4m-core-v2-k7x9 229.155 b), geen nieuwe of gewijzigde R4M-links waargenomen. r4m-max.pages.dev bewust niet gemeten (Cloudflare Access).Formaat-noot: deze negen items dragen lokale letterbadges en geen Google-favicons — het bestand volgt de beslissing van commit
09e5b74, niet de routine-opdracht, die het Google-formaat nog steeds voorschrijft. Dat beslispunt staat sinds 01-09 open.04-09🔍 AUDIT ⏱ — de middagfase van vandaag heeft geen enkel spoor nagelaten, en dat is pas om 19:05 gezien — Fase BOUWEN hoort om 13:00 te draaien en laat normaal drie sporen na: een briefing in
ops/daily/JJJJ-MM-DD-1300.md, een commit, en een run-regel in het voortgangsdossier van de oprichter. Voor 02-09 en 03-09 staan die alle drie er. Voor 04-09 staat er geen enkele: tussen 06:56 en 18:49 is er in geen van beide repo's gecommit, er is geen middagbriefing, en het voortgangsdossier staat nog op 03-09. Wat er precies misging valt niet te bewijzen — de planner bewaart maar één laatste-run-tijdstip en dat draagt nu de avondrun. Wat vaststaat is de afwezigheid. De avondrun heeft de fase om 19:05 ingehaald. Zo zet je dit in de markt: niet naar buiten, maar wel naar binnen — dit is exact het gat dat R4M bij anderen aanwijst. Een keten die stilvalt zonder iets te melden is geen keten, en de enige reden dat dit vandaag boven water kwam is dat een tweede run ernaar keek. Dat is dezelfde redenering als de ketencheck van 08:30, één laag dieper.04-09💶 FUNDING — de twee lopende deuren om 19:05 een tweede keer aan de bron nagelezen, allebei ongewijzigd — De ochtendrun telde de klok al; deze hercontrole hoort bij de ingehaalde middagfase en is bewust een tweede lezing op dezelfde dag, want een deadline kan tussen 03:00 en 19:00 schuiven. Base Batches 004 staat op
base.org/batches woordelijk op "Applications close September 9." met de tijdlijn 17-09 uitsluitsel en 21-09 tot 15-11 virtueel programma; het aanvraagformulier geeft HTTP 200. Start it @KBC draagt op startit.be nog altijd "Application deadline: 14.09.2026", met de online infosessie op 08-09-2026 ervoor. Eurostars Call 11 sluit op 10-09 en blijft bewust zonder vlag: het consortium vraagt twee onafhankelijke organisaties uit twee landen, en een harde datum die je solo niet kán halen is ruis, geen urgentie. Zo zet je dit in de markt: niets nieuws te melden is hier het bericht — de vijf dagen tot Base zijn echt en het formulier staat open, dus de enige beweging die vandaag telt komt van Franky zelf.04-09
🔍 AUDIT ⏱ — FSMA is vanavond onbereikbaar, en daarmee valt de helft weg van de MiCA-dubbelcheck — De avondronde van de bronnen (04-09-2026, 19:0x) meet www.fsma.be als onbereikbaar: geen 404 en geen omleiding, maar
Empty reply from server. Vier varianten geprobeerd met twee clients en een browser-user-agent — de Engelse pagina, de Nederlandse, de vorm zonder www en de kale wortel. Alle vier hetzelfde. Gisteravond gaf diezelfde bron nog 200 met 183.910 bytes. Ook de Nationale Bank (www.nbb.be) faalt, met een 520. Waarom dat telt: de vaste controleregel van 29-08-2026 zegt dat het ESMA-register altijd naast de FSMA-lijst gelegd moet worden, nooit een van de twee alleen, omdat het Belgische toezicht verdeeld is tussen FSMA en de Nationale Bank. Op 29-08 leidde het lezen van een enkel register tot een foute nul-conclusie. Vanavond kan die regel dus niet nagekomen worden. Wat de ronde wel opleverde: tot nu stond de EU-kant in de tabel als casptracker.eu, een spiegel en niet het register zelf. Getest en gemeten: registers.esma.europa.eu/publication/searchRegister?core=esma_registers_mica_casp geeft 200 met 174.714 bytes en draagt Belgische vermeldingen. Die officiele ESMA-bron is als aanwas opgenomen. Zo zet je dit in de markt: niets — dit is huishouding, geen vondst. Het punt is dat een MiCA-conclusie die vanavond op een enkel register gebouwd wordt, per definitie de regel van 29-08 breekt. Morgen een tweede meting voor er een oordeel valt over de rij; een verbindingsweigering op een heel domein is meestal tijdelijk.04-09
🔍 AUDIT ◐ — het eigen voorstel over de omvangdrempel corrigeert zich voor de tweede avond, nu omhoog — Sinds 01-09 ligt bij Franky het voorstel om naast de statuscode ook de omvang van een antwoord te meten en een 200 onder een paar duizend bytes te markeren als lege schil. Gisteravond stelde deze ronde dat al bij:
chainalysis.com/blog/x402-agentic-payments-adoption/ kromp van 290.713 naar 214.920 bytes zonder dat titel of artikeldatum wijzigden, en de conclusie was dat een daling geen signaal is. Vanavond staat diezelfde pagina op 294.013 bytes — ruim tachtigduizend hoger dan gisteren en boven de oorspronkelijke meting. Het artikel is onveranderd, met dezelfde datum van 03-06-2026. Drie metingen, twee richtingen, nul inhoudswijziging. Een drempel op verandering zou hier drie keer op rij vals alarm gegeven hebben. Een drempel op absolute omvang niet: mydividend.ai geeft vanavond voor de vijfde ronde exact 2.274 bytes, tot op de byte gelijk aan de vier vorige metingen en aan zijn eigen /about. Zo zet je dit in de markt: dit is het argument dat R4M zelf gebruikt tegenover klanten die met heuristieken werken — een meetwaarde die in beide richtingen schommelt zonder onderliggende gebeurtenis is geen bewijs, hoe vaak je hem ook meet. Hetzelfde verschil tussen ruis en bewijs zit tussen gedragsdetectie en een attestatie op een echte mens. Het voorstel zelf blijft ongewijzigd bij Franky liggen, nu vier avonden.04-09🔍 AUDIT ◐ — de oppervlakte-check meet voor de derde avond een schil, en de radar-URL bleek een omleiding —
r4m-core-v2-k7x9.pages.dev gaf vanavond 229.155 bytes — tot op de byte gelijk aan gisteravond, op een dag waarop er wel degelijk gedeployd is. De twee rijen die op 03-09 als aanwas zijn opgenomen laten zien wat er onder die onbewogen schil gebeurde: marktradar.html ging van 471.264 naar 500.242 bytes (+28.978) en cases-db.json van 5.083.566 naar 5.175.106 (+91.540). Derde avond op rij dezelfde meting — geen vermoeden meer. Er kwam vanavond een tweede punt bij: de radar-rij …/marktradar.html leidt met een 308 door naar /marktradar zonder extensie. Regel 1 van de bronnentabel zegt dat een 301 of 308 betekent dat de doel-URL overgenomen wordt; dat is gebeurd. Zonder die stap meet de rij elke avond een omleiding in plaats van een pagina. Zo zet je dit in de markt: huishouding, geen vondst — maar wel dezelfde les als bij de klant: een groen vinkje op de verkeerde meetpunt is erger dan geen meetpunt, want het geeft rust die niet verdiend is.04-09🧪 TEST — bronnenronde 04-09: 30 van 31 bronnen levend, één onbereikbaar — Eenendertig bronnen, één opvraging elk, statuscode en omvang genoteerd. 30 op HTTP 200, 1 onbereikbaar (FSMA, zie het auditvonnis hierboven). Nul dood, één nieuwe omleiding overgenomen (de radar-URL, 308). Twee nieuwe rijen: het officiele ESMA-MiCA-register als aanwas, en de doel-URL van de radar. Stand van de wachtposten: de x402-tagwacht staat op pypi-x402@v2.22.0 en maX kent die tag nu ook — de achterstand van één tag die het dagrapport van vannacht meldde, is dicht. De ARF-tagwacht blijft op v3.0.0 (21-07-2026). x401 is onbewogen sinds 01-07-2026, nu 65 dagen, tags leeg. De SEO-keten leeft: verse meting
synced_at 2026-09-04 03:51:50, de opvraging groeide 7.695 bytes. Het commando dat dit herhaalt: python3 scratchpad/bronnen.py — één opvraging per rij uit docs/BRONNEN.md, code en omvang naast elkaar. Zo zet je dit in de markt: niets te verkopen, maar het is het bewijs dat de bewaking meetbaar is in plaats van beweerd.04-09✅ CORRECTIE op het auditvondst van vanochtend — het dagrapport van vannacht staat nu wél op GitHub — Het item van 04-09 hierboven meldde dat fase VINDEN haar drie bestanden (het dagrapport,
SIGNALS_ADAPT.md en ledger-entry 24) lokaal committe als c1ed81d en dat beide pushpogingen geweigerd werden, waardoor het werk op één schijf stond. Nagemeten vanavond: git ls-remote origin main geeft c1ed81df39e31e9aa3ece515ee29162492eff228 — precies dezelfde commit. De lokale main en origin/main staan gelijk en de werkboom is schoon. Het werk is dus alsnog op GitHub geland, hoogstwaarschijnlijk via de autopush-agent, ná het schrijven van dat ochtenditem. Het oude item blijft staan zoals de regel voorschrijft; dit is de correctie erop, niet de vervanging ervan. Wat er niet mee gebeurde: de commit draagt [skip ci], dus de deploy-job van de engine is niet gestart — de poort deed wat hij moest doen. Zo zet je dit in de markt: niets — maar het is het derde bewijs deze week dat een geweigerde push geen verloren werk is zolang iemand het naderhand nameet.04-09🔍 AUDIT ⏱ — het dagrapport van vannacht staat wél op deze Mac en niet op GitHub, en de reden is dat de poort werkte — Fase VINDEN schreef vannacht drie bestanden naar
Rails4Mankind (het dagrapport, SIGNALS_ADAPT.md en ledger-entry 24) en committe ze lokaal als c1ed81d. Beide pushpogingen werden door de omgeving geweigerd — zowel naar main als naar een aparte routine/-tak. Waarom dat niet fout is: harde poort 10 verbiedt een push naar de engine-main omdat .github/workflows/deploy.yml nog altijd luistert op on: push: branches: [main] zonder enige paths-ignore — vandaag opnieuw nagelezen. Een commit met alleen markdown start dan dezelfde job als een codewijziging en rolt de live betaalmotor opnieuw uit. Dat is precies het ⚠ theater-vonnis van 02-09. Wat er sindsdien wél gebeurde: vanaf 03-09 dragen de routine-commits [skip ci], en dat werkt aantoonbaar — de laatste door een routine gestarte deploy-run dateert van 02-09 01:28, daarna geen enkele meer. Mijn commit draagt diezelfde markering. Wat dit betekent voor vandaag: het werk is niet weg, maar het staat op één schijf. De fix ligt sinds 02-09 op voorstel/2026-09-02-deploy-poort-pad-filter en wacht nog altijd op goedkeuring — dat is nu de derde dag, en het is de enige handeling die dit definitief oplost. Zo zet je dit in de markt: niets, dit is huishouden. Maar het is wel het soort huishouden dat je aan een klant kunt tonen: de poort die de betaalmotor beschermt heeft vannacht gedaan wat hij moet doen, en het bewijs staat hier.04-09
⚙️ PROTOCOLWACHT x402 — er is nu een modus waarin de tussenpartij tekent wat de mens betaalt, en ons dossier kent het woord niet — Het
upto-schema laat de koper één keer tekenen voor een maximum; wie daarna het werkelijke bedrag vastlegt, is een aparte rol: de receiverAuthorizer. De spec zet er sinds 03-09-2026 een keuzetabel bij (docs/schemes/upto.mdx, PR #3356) met twee modi. Self-managed — de verkoper tekent zelf, aanbevolen. Facilitator-delegated — de verkoper laat het tekenen over aan de facilitator, en de spec schrijft er zelf bij dat die dan "authenticates your settle requests out of band": de controle op wat er van de mens afgaat verhuist buiten het protocol. Diezelfde dag werd die gedelegeerde modus ook code, in TypeScript én Go (PR #3346 en #3347, delegated receiver authorizer for SVM upto). Onder de Solana-variant ligt bovendien een escrow-kanaal: de koper zet het plafond vast in de payment-channels-programma, de server sluit af met een getekende voucher. De bril eerst, en die valt hier slecht uit: maX kent upto en auth-capture wel, maar receiverAuthorizer, payment-channels, Permit2 en settlement override geven samen nul treffers in de hele public/-map, en het dossier staat nog op tag pypi-x402@v2.21.0 terwijl er sinds 03-09 v2.22.0 is. Achterstand: één dag op de spec, één tag op de versie. Zo zet je dit in de markt: dit is de scherpste versie van jouw eigen stelling, door het protocol zelf opgeschreven. Een agent tekent voor een plafond, een tussenpartij vult het bedrag in, en nergens in die keten staat dat er één echt mens achter dat plafond zit. Zeg tegen een facilitator: "jullie mogen bij delegatie invullen wat de klant betaalt — waarop steunt de bewering dat die klant een mens is, en maar één keer bestaat?" Bron: upto.mdx, opgehaald 04-09-2026.04-09💸 x402-lijn — het protocol opent zich voor betaalwegen waar de betaler per constructie geen identiteit heeft, en noemt dat in de spec zelf een grens — PR #3145 (gemerged 02-09-2026) schreef de ontbrekende netwerk-onafhankelijke helft van de
upfront-betaalstroom in scheme_exact.md. Twee methoden: signed-transaction — de klant tekent, de facilitator verstuurt, en het netwerk zelf voorkomt dubbel gebruik. En payment-proof — de klant betaalt zélf en toont achteraf een bewijs, dat de afrekening dan bindt. Die tweede is er expliciet voor Lightning, waar het bewijs een preimage is en geen keten-transactie. De PR-tekst benoemt bij de afwegingen letterlijk payer-identity limits. De bril: upfront komt in maX één keer voor, Permit2 en payment-channels nul keer — de mechaniek onder de betaalkant is in ons dossier een zwarte doos. Zo zet je dit in de markt: hoe breder x402 uitwaaiert over netwerken, hoe zwakker het verband tussen een betaling en een mens — op Lightning is het bewijs een getal en verder niets. Dat is geen bezwaar tegen x402, het is de reden dat de attestatie-kant een aparte laag moet zijn en niet een eigenschap van de keten. Gebruik het als openingszin bij elke facilitator: "jullie spec noemt payer-identity een grens — wij zijn die grens." Bron: PR #3145.04-09
📦 OMZET-LOPENDE-BAND — ledger-entry 24, en het gat staat opnieuw in de etalage van de verkoper zelf — €100-moment #9 (UX-onderzoek en gebruikerstests) door het who-pays-filter: ✅ PASS. Koper met naam en adres: TestingTime (Zürich, actief in de BE/NL-markt), plus UserTesting en User Interviews. Vandaag aan hun eigen etalage nagemeten: "On average, you earn €40 per study" en 985.000+ testers. Wat op diezelfde pagina volledig ontbreekt: één regel over identiteitscontrole, uniciteit, fraude of dubbele accounts. Dat is exact dezelfde vorm bewijs als bij intrinsiQ in entry 23 — de sectorgrens bestaat als belofte, niet als controle. Pad naar €100: twee tot drie gemodereerde sessies, remote, 30 tot 60 minuten, herhaalbaar. Doctrine: alle vier de pijlers groen — de tester wordt betaald voor wat hij bewust dóét, opt-in, betaler bij naam. ⚠️ Eerlijke begrenzing: TestingTime en UserTesting hebben de klantrelaties; de instap is verified-supply-partner voor hun BE/NL-pool, niet frontale concurrentie. TestingTime kwam in de hele maX-site nog niet voor. Zo zet je dit in de markt: derde entry op dezelfde primitief na survey-respondenten (22) en focusgroepstoelen (23) — één bouwstuk, een frequentievenster op de attestatie-hash, bedient alle drie. Volgende run: €100-moment #10. Bron: testingtime.com, opgehaald 04-09-2026.
04-09🧪 TEST — 383 van 385 groen, geen versiedrift, en de vier meetbare checks staan alle vier op waar — Testsuite op
main: 63 bestanden, 383 geslaagd, 2 overgeslagen (385), in 6,30 s. Versie: repo v0.36.7 (VERSION, package.json en de laatste tag zijn het eens) en live v0.36.7 — geen versiedrift. De checks uit /api/public/status, letterlijk: app_live ✓, itsme_eid ✓ (sandbox), attestations ✓, double_entry_ledger ✓; settlement_adapter en email_login staan op configured zonder verificatie, precies zoals hun eigen noot zegt. /api/public/reconciliation antwoordt HTTP 200. Netwerk base-sepolia, stage pilot — testnet, geen echte waarde. Identiek aan gisteren; dat is hier het bericht. Herhaalbaar met npm test in Rails4Mankind en curl -s https://r4m-franky.fly.dev/api/public/status.04-09💶 FUNDING — de klok herteld op de dag van vandaag, en de enige die vandaag telt is Base — Vier harde datums op het bord, alle vier vandaag opnieuw tegen de kalender gelegd. Base Batches 004 — sluit 09-09-2026, nog 5 dagen (het bord stond op 6). Virtueel programma 21-09 tot 15-11, uitsluitsel 17-09, geen co-oprichterseis in drie controles. Dit is de enige regel die vandaag een handeling vraagt. Eurostars Call 11 — sluit 10-09-2026 om 14:00 CEST, nog 6 dagen, aan de bron herbevestigd, en bewust géén vlag: elk consortium telt minstens twee onafhankelijke organisaties uit twee Eurostars-landen, dus solo onhaalbaar. Een harde datum die je toch niet kán halen is ruis. Doel blijft Call 12. Start it @KBC — sluit 14-09-2026, nog 10 dagen, infosessie op 08-09. imec.istart — sluit 30-09-2026, nog 26 dagen, terecht niet urgent. Niets nieuws geopend dat de moeite is: de ECCC-oproep CYBER-11-EULEG (€20M, deadline 14-01-2027) werd gisteren al nagekeken en eerlijk afgeschreven — consortia van overheden en CERT's, geen eenmanszaak. Zo zet je dit in de markt: vijf dagen is nog schrijftijd voor Base, en "agents" plus "payments" staan letterlijk in hun doelgebied. Bron: Eureka · base.org/batches.
04-09📋 STAND VAN DE SPOREN — vijf items, en vier sporen die leeg blijven omdat de bril het antwoord al vond — Wat er wél is: twee protocolwacht-vondsten op x402 (de gedelegeerde ontvanger en de
upfront-familie), ledger-entry 24, de app-status en de fundingklok. Wat leeg blijft, met de reden erbij. 🆔 Identificatie-cases — leeg. De kandidaten van vannacht waren de Franse SREN-wet (staat op de radar van 03-09), Reddit's mens-verificatie, en de overname van iDIN door itsme; alle drie geven treffers in public/, iDIN zelfs in 36 bestanden. Geen nieuw feit, dus geen item. 💶 Geld-case — leeg, vijfde run op rij, en het openstaande voorstel van 02-09 is nog altijd niet beantwoord: draai de richting om en vertrek van de 56 bestaande prospects met de vraag welke geldstroom er vandáág al loopt, in plaats van te wachten tot het nieuws er een aanreikt. Dat wijzigt het mandaat en is dus aan Franky. Zonder die beslissing blijft dit blok leeg lopen — een methodeprobleem, geen marktprobleem. 🤝 x401 — laatste commit blijft 01-07-2026, nu 65 dagen stil. Geen item, wel gecontroleerd. 📡 IoT — leeg. De Data Act-datum van 12-09 en Cloudflare's standaardwijziging van 15-09 staan allebei al in het dossier; gisteren werd die laatste met dezelfde bril al afgeschreven. ⚡ Nieuwe use case en 🎯 prospect — leeg, geen kandidaat die de lat haalde (echt bedrijf, bron met datum, openingszin). ✉️ Secure Mail — niet aan de beurt, dat spoor draait op maandag. 🔁 Doorloop-versterking — geen nieuwe cases sinds gisteren (197 gisteren, 197 nu), dus niets te versterken. 🌐 Oppervlakte-check: r4m-founder 200 en r4m-core-v2-k7x9 200. 🔗 Doorloop-API: bereikbaar, 47 items, nul op goedgekeurd — niets te verwerken.03-09⚙️ PROTOCOLWACHT — de x402-controle die de facilitator uit de betalersrol moet houden, keek langs één van zijn eigen adressen — Commit
626df07e (PR #3336) landde 03-09-2026 om 07:02 UTC in x402-foundation/x402 — vier uur ná de protocolwacht van vannacht. Drie veiligheidscontroles staan bij naam in de changeset: unsafe_tx_or_op_source, facilitator_is_payer en facilitator_in_auth. Ze bestaan om te verhinderen dat een adres van de facilitator de rol van betaler, transactiebron of ondertekenaar inneemt. Het gat: getSigners() gaf via de publieke API de feeBumpSigner op als adres van de facilitator, terwijl de verzameling die de controles écht raadplegen (signingAddresses) dat adres nooit bevatte. Een facilitator met een feeBumpSigner ingesteld kon dus precies de rol innemen die de controle moest uitsluiten, terwijl hij dat adres zelf publiek als het zijne aangaf. De reparatie zet een aparte verzameling facilitatorSafetyAddresses naast de bestaande, bewust niet samengevoegd omdat de ondertekenaarskeuze in settle() die verzameling óók gebruikt. Omvang: patch op @x402/stellar, 3 bestanden, +69/−4, lost issue #3332 op. Bron: api.github.com/repos/x402-foundation/x402/commits/626df07e (03-09-2026), gevonden door de bronnenronde van 19:00 doordat de commits-API 13.320 bytes gegroeid was sinds gisteravond. Met de maX-bril: "feeBumpSigner" en "fee bump" komen in de hele public/-map niet voor (grep 03-09-2026). Stellar kent het dossier wél — facilitators sinds maart 2026, Stellar Development Foundation als premier-lid van de x402 Foundation — en de CAP-71-commit 7488a46 stond vanochtend al in het rapport. Deze laag is nieuw. Geen versiedrift: dit is code, geen spec. x402 blijft op spec v2, hoogste tag pypi-x402@v2.21.0. 🔌 Integratievorm: geen inplugpunt — dit is een positioneringsvondst, geen verkooplead. Wie hem wél als deur gebruikt, doet dat bij een x402-integrator die zelf een facilitator draait, via de bestaande attestatiekant (OIDC-knop of API-sleutel op hun backend), zonder dat er iets aan de rail hoeft te veranderen. 🧩 Productmix: attestatiekant alleen (V), rail doet niet mee; laagste trede; groeipad is pas aan de orde als een integrator zelf om rolscheiding vraagt. Zo zet je dit in de markt: dit is ons eigen argument, aangetroffen in de code van een ander. Een rolscheiding die publiek verklaard werd maar niet afgedwongen — wekenlang, tot iemand de verzameling las die de controle écht raadpleegt. R4M verkoopt de omkering: een attestatie waarbij de verklaring en de afdwinging hetzelfde object zijn, zodat ze niet uit elkaar kúnnen lopen. Openingszin bij een x402-integrator: "Uw facilitator verklaart zelf welke adressen van hem zijn. Wat controleert dat die verklaring klopt?"03-09🔍 AUDIT ⏱ — twee avonden na elkaar dezelfde blinde vlek, en twee keer was het de bronnenronde die hem ving — Op 02-09 kreeg de protocolwacht het vonnis ⏱ opletten: hij kijkt om 03:00 en nergens anders, terwijl commit
23173acb om 16:58 UTC landde. Dat heette toen een toevalstreffer van de gezondheidscheck. Vanavond gebeurde precies hetzelfde: 626df07e landde om 07:02 UTC, vier uur ná de controle van 03:00, en werd opnieuw door de avondronde gevonden — niet door de wacht die ervoor bestaat. Twee op twee. Daarmee verschuift het van incident naar patroon, en verandert het gewicht van het openstaande voorstel van 02-09 (neem de commits- en tags-API van x402 en x401 mee in de avondronde, waar ze toch al opgehaald worden — dat halveert het blinde venster van 24 uur naar ongeveer 8 en 16). Dat voorstel was gisteren een redenering; vandaag heeft het een score. Niet zelf doorgevoerd — dit blijft een keuze van Franky, en tot hij beslist blijft de wacht draaien zoals ze draait. Eerlijk erbij: de avondronde vindt deze commits omdat ze de bronnen tóch opvraagt voor de gezondheidscheck, dus de kost is bijna nul. Zo zet je dit in de markt: niet naar buiten. Dit is huishouden, en het hoort in het bord omdat een wacht die zijn eigen gat niet meldt geen wacht is.03-09🔍 AUDIT ◐ — de oppervlakte-check meldde vandaag nul verandering, terwijl er twee keer gedeployd werd — De oppervlakte-check meet
r4m-core-v2-k7x9.pages.dev op omvang. Vanavond: 229.155 bytes — exact hetzelfde getal als gisteravond, tot op de byte. Toch landden er vandaag twee deploys (13:27 bouwen, 08:12 ochtendrapport) en groeide de radar met 19 items. Nagemeten aan de bron in plaats van geloofd: de live marktradar.html telt 145 agenda-items, waarvan 19 met de kop 03-09, en de live cases-db.json is 5.083.566 bytes. De deploys staan er dus wel degelijk. Wat er misgaat: de check meet index.html, en dat is een schil die alleen beweegt als die schil zelf wijzigt. De inhoud zit in marktradar.html en cases-db.json, die de check nooit aanraakt. Op 31-08 bewoog het getal wél (+5.296 bytes) en is daar toen de conclusie "de radar- en subsidie-wijzigingen van vandaag" aan gehangen — dat was toeval, geen meting. Een check die op een goede dag toevallig gelijk heeft, is precies de soort die je op een slechte dag gerust stelt. Voorstel, niet doorgevoerd: vervang de bytetelling van index.html door de itemtelling van marktradar.html plus de omvang van cases-db.json. Dat is één extra opvraging en het meet wat er werkelijk verandert. Zo zet je dit in de markt: niet naar buiten — maar het is dezelfde fout als in de x402-vondst hierboven: een controle die iets anders raadpleegt dan wat ze beweert te bewaken.03-09🔍 AUDIT ⏱ — de uurlijkse audit staat 63 dagen stil en de routine leest hem nog elke dag —
ops/hourly/log.md heeft één regel, gedateerd 02-07-2026 05:23, en ops/hourly/last-audit.json draagt dezelfde tijdstempel. Dat is 63 dagen zonder beweging. De audit-digest van fase BOUWEN opent dat bestand elke middag en fase BIJWERKEN elke avond; ze vinden er al twee maanden hetzelfde. Er breekt niets — het duurzame archief ops/audit-private/audits.json draait wél door en staat op 66 vonnissen, bijgewerkt vandaag — maar er staat een stap in de routine die naar een bron kijkt die niet meer schrijft. De cijfers in die stilstaande momentopname zijn intussen onwaar: ze noemen v0.3.0, testnet base-sepolia en een payTo op het dEaD-adres, terwijl de engine live op v0.36.7 staat. Ze worden nergens gelezen als waarheid, maar ze liggen er wel. Twee eerlijke uitwegen, allebei een keuze van Franky: ofwel de uurlijkse audit terug aanzetten, ofwel de leesstap uit de routine halen en het bestand als archief markeren. Niet zelf gedaan — dit raakt de routinetekst, en die verander ik niet zonder vraag. Zo zet je dit in de markt: niet naar buiten.03-09📚 BRONNENRONDE 03-09 — 29 van 29 levend, en de Chainalysis-daling weerlegt een deel van ons eigen voorstel — Vierde avondronde. 29 bronnen opgevraagd, 29 keer HTTP 200. Nul dood, nul omgeleid, nul nieuwe doorverwijzing. Derde ronde op rij zonder reparatie. De drie EUDI-vervangers houden stand, de ARF-tagwacht blijft op v3.0.0 (21-07-2026) — geen versiedrift op EUDI. De x402-tagwacht blijft op
pypi-x402@v2.21.0, x401 onbewogen sinds 01-07-2026 (65 dagen). De SEO-keten leeft: verse meting synced_at 2026-09-03 11:22, de opvraging groeide 10.809 bytes. De vondst van de ronde staat hierboven: de commits-API groeide 13.320 bytes en dat leidde naar commit 626df07e. Wat het openstaande voorstel over een inhoudsdrempel bijstelt. Sinds 01-09 ligt bij Franky het voorstel om naast de statuscode ook de omvang te meten en een 200 onder een paar duizend bytes te markeren als ⚠ lege schil. Vanavond levert de ronde een tegenvoorbeeld dat de regel scherper maakt: chainalysis.com kromp van 290.713 naar 214.920 bytes — een kwart weg — maar titel en artikeldatum (03-06-2026) zijn onveranderd. Die daling is pagina-meubilair, geen inhoudsverlies. Een dalende omvang is dus geen signaal; een kleine absolute omvang wel. mydividend.ai geeft voor de vierde ronde exact 2.274 bytes op twee verschillende adressen — dát is een schil. Het voorstel blijft staan, maar in de vorm "drempel op absolute omvang", niet "alarm bij een daling". Openstaand, ongewijzigd: een vervangende primaire bron voor de AI Dividend, nu drie ronden open. Zo zet je dit in de markt: niet naar buiten — maar het is het bewijs dat de bronnenlijst zichzelf blijft bijstellen in plaats van alleen af te vinken.03-09💶 FUNDING — vannacht stond hier dat alleen de klok verandert; vandaag veranderde er meer — De funding-regel van 03:00 concludeerde “vier harde datums, en de klok is het enige dat verandert”. Dat klopte vannacht en klopt vanmiddag niet meer, want twee bronnen gaven bij hercontrole feiten prijs die nooit op het bord stonden. Base Batches 004 (sluit 09-09, hard, nog 6 dagen): de tijdlijn op base.org/batches noemt naast “Applications close September 9.” ook “Sep 17 — Acceptances Sent” en “Sep 21 – Nov 15 — Virtual Program”. Het programma is dus virtueel — geen reis, geen verhuizing, uitsluitsel al op 17 september. Dat was hier nooit vastgesteld en het haalt de laatste praktische twijfel weg voor een solo-oprichter in België. Start it @KBC (sluit 14-09, hard, nog 11 dagen): startit-x.com gaf de hele trechter — online infosessie 08-09, deadline 14-09, uitnodiging pitch 29-09, pitchdagen 14 en 15-10 in Antwerpen (drie minuten), selectie 16-10, start 28-10, 65 plaatsen, één jaar, gratis. De oude URL www.startit.be/en/apply antwoordt met een 301 naar de nieuwe. Eurostars (10-09 om 14:00 CEST) en imec.istart (30-09 middernacht) zijn woordelijk herbevestigd en ongewijzigd. Zo zet je dit in de markt: niet naar buiten — dit is het bord waarop Franky beslist. De les die wél naar buiten mag: een regel die “al gecontroleerd” heet, is niet hetzelfde als een regel die vandaag gecontroleerd is.
03-09
🔍 AUDIT — het advies van gisteren verving zichzelf: geen mail nodig, er is een infosessie op 8 september — De briefing van 02-09 gaf als tweede actie “één mail naar Start it X: is een solo-oprichter toelaatbaar?”. De hercontrole van vandaag vond een betere weg naar hetzelfde antwoord: de pagina kondigt een online infosessie op 8.09.2026 aan, zes dagen vóór de deadline, expliciet om vragen te laten beantwoorden door de programmamanager. Sneller, goedkoper, en je hoort er meteen bij hoe de jury leest. Wat NIET opgelost is: de claim “solo-oprichter is geen beletsel” staat er ook vandaag niet bij de bron — die ⚠ blijft staan. Vonnis ✓ echt, en dat “echt” hangt aan die tweede alinea: er is een betere weg naar het antwoord gevonden, het antwoord zelf is er nog niet. Zo zet je dit in de markt: dit is de discipline die R4M verkoopt in miniatuur — het verschil tussen “gecontroleerd” en “vandaag gecontroleerd”, en het weigeren om een gat dicht te praten omdat er toevallig goed nieuws naast lag.
03-09💡 VOORSTEL — een typo in de treasury-cap werd stil geslikt, en de cap was dan 5.000× ruimer dan bedoeld — Twee instellingen begrenzen wat de schatkist-sleutel in één keer en per etmaal mag uitbetalen. Er lag al een test op de handhaving van die plafonds, maar die zegt in zijn eigen kop dat hij alleen de standaardwaarden draait — de stap van wat de operator bedoelt naar het plafond dat echt geldt, stond nergens gemeten. Op de echte parser nagemeten, niet geredeneerd: wie het plafond op één dollar zet in de underscore-stijl die het bestand zelf overal gebruikt (
R4M_MAX_PAYOUT_MICRO=1_000_000), krijgt een leesfout en erft stilzwijgend het standaardplafond van vijfduizend dollar. Zonder één regel in het log. Het terugvallen blijft precies zoals het was — dat is juist gedrag — maar elke geweigerde waarde zegt nu luid dát ze genegeerd is en dat het plafond dus NIET aangescherpt is. Tak voorstel/2026-09-03-treasury-cap-typo-stil, commit 48a47db. Zes gevallen vastgepind, waarvan drie bestaand gedrag dat nog niet vastlag; tegenproef gedraaid, zonder de bronwijziging falen er precies drie. Zo zet je dit in de markt: niet als product, wel als houding — een plafond dat je niet gemeten hebt, is een plafond dat je gelooft.03-09
🧪 TEST — 389 van 391 groen op de voorstel-tak, en main staat onveranderd op 383 — Vanmiddag opnieuw gedraaid in
/Volumes/8TB MM4/Rails4Mankind. Op main: 383 groen, 2 overgeslagen, 63 bestanden — precies wat de nacht om 03:00 mat, dus daar is niets veranderd. Op de voorstel-tak van vandaag: 389 groen, 2 overgeslagen, 64 bestanden, de zes nieuwe gevallen erbij. Typecontrole schoon, server start schoon op v0.36.7, en de demo loopt end-to-end met de vijf boekhoudkundige invarianten (I1 geld behouden · I2 elke transactie sluit op nul · I3 saldi gelijk aan wat geboekt staat · I4 gefinancierd gelijk aan gehouden plus betaald plus fees · I5 niets uit het niets betaald) alle vijf groen. Geen versiedrift: VERSION, package.json, de laatste tag en de live /api/public/status staan alle vier op v0.36.7. Herhaalbaar met: npm test · npx tsc --noEmit · npm run demo. Zo zet je dit in de markt: dit getal is het enige antwoord op “werkt het?” dat geen mening is.03-09📊 SEO — channel-zero.be desktop 93 → 59 in één dag: de layout springt (CLS 0,003 → 0,939) — Gemeten. De Core Web Vitals-score voor desktop van channel-zero.be zakte van 93 naar 59. De oorzaak is Cumulative Layout Shift: 0,003 gisteren, 0,939 vandaag. Alles boven 0,1 is een fail; 0,939 betekent dat vrijwel het hele beeld verspringt terwijl de pagina laadt. Mobiel zakte mee, 71 → 65, maar dat blijft binnen zijn eigen band van 63–71 sinds juli.
Het schommelt, en dat is het patroon. Op 30-08 stond desktop-CLS ook al op 0,511, daarna drie dagen 0,003, nu 0,939. Iets dat er soms wel en soms niet is en geen afmetingen meegeeft. De homepage laadt 14 afbeeldingen, geen enkele lazy, geen modern formaat, plus een externe ticket-link die vandaag 404 gaf (leftfestival2026.tickoweb.be).
Waarom dit pijn doet. Dit is met afstand de site met het meeste verkeer van de vloot: 49 clicks op 1.290 vertoningen, en de term "channel zero" staat op positie 9,4 met 645 vertoningen. Dat is de grootste kans van alle zeven domeinen, en hij wordt afgeremd door traagheid — LCP mobiel staat op 10,9 s.
En ik kan er niets aan doen. channel-zero.be staat op
Het schommelt, en dat is het patroon. Op 30-08 stond desktop-CLS ook al op 0,511, daarna drie dagen 0,003, nu 0,939. Iets dat er soms wel en soms niet is en geen afmetingen meegeeft. De homepage laadt 14 afbeeldingen, geen enkele lazy, geen modern formaat, plus een externe ticket-link die vandaag 404 gaf (leftfestival2026.tickoweb.be).
Waarom dit pijn doet. Dit is met afstand de site met het meeste verkeer van de vloot: 49 clicks op 1.290 vertoningen, en de term "channel zero" staat op positie 9,4 met 645 vertoningen. Dat is de grootste kans van alle zeven domeinen, en hij wordt afgeremd door traagheid — LCP mobiel staat op 10,9 s.
En ik kan er niets aan doen. channel-zero.be staat op
fixbaar: false: Franky bezit het domein en de DNS, niet de site, en er is geen repo. Dit is meten en melden. Wil je die 645 vertoningen verzilveren, dan moet het via de partij die de site hostt — en dat is een gesprek, geen commit.Ouder — eerdere vondsten (22-08 t/m 02-09)
03-09
📰 OCHTENDRAPPORT donderdag — tien radar-items, en de scherpste vondst gaat over ons eigen dossier — Het rapport over het venster 02-09 08:30 → 03-09 08:30 staat op de Ops-tab. Kern: Frankrijk eist sinds 01-09-2026 van iedere gebruiker een leeftijdsbewijs met een door de toezichthouder goedgekeurde methode, x402 zet 16-09 een tweede handtekeningvorm (Stellar CAP-71) in stemming, en de maX-bril legde bloot dat "Really Simple Licensing" nul treffers geeft in de hele site terwijl er een uitgewerkt pay-per-crawl-dossier ligt. Tien items uit fase VINDEN (drempel 5), plus zes kaarten op de regio-radars. Backup-alarm schoon, ketencheck alle vijf ketens groen, doorloop-API 47 items met nul op "goedgekeurd". Zo zet je dit in de markt: de Franse wet is de eerste in Europa die van élke gebruiker leeftijdsvaststelling eist in plaats van alleen van wie jong lijkt — dat is precies de omslag van "document tonen" naar "claim ophalen" waar R4M op gebouwd is.
03-09
📊 SEO-VLOOT — channel-zero valt 34 desktoppunten in één dag, en de keten meldt zich groen op 8 van de 18 — Opgehaald uit
/api/seo-watch op 03-09-2026. Van 18 domeinen dragen er 8 een meting van vandaag; de andere 10 een oudere datum. Vier met beweging: boombedrijfbisschop.be CWV 98 (+22), onsite 84, 20 kliks — de grootste sprong van de vloot. channel-zero.be CWV mobiel 65 (−6), desktop 59 (−34, van 93), LCP mobiel 10,9 s, desktop CLS 0,939, kliks 49 (van 41), impressies 1.290 (van 1.053), positie 7,9; vier auto_fails blijven open (canonical, schema, robots, sitemap). michiel-haverans-yware.pages.dev CWV 71 (−3) en plastimet-webbuild-1.pages.dev CWV 71 (−2), beide gemeten 30-08. De ketencheck meldt de SEO-keten groen (0 dagen geleden), maar dat groen steunt op 8 van de 18 — tweede dag op rij dezelfde vlag. Zo zet je dit in de markt: niet naar buiten, dit is huiswerk — een desktopval van 34 punten met CLS 0,939 op een site met stijgende kliks kost geld op het moment dat het verkeer er is.03-09
🌏 REGIO-RADARS — zes kaarten kwamen na de nacht binnen, op hun eigen blad in plaats van hier — Twee zusterroutines schreven vóór 07:00 op
paginas["cn-radar"] en paginas["india-radar"], buiten de markt-radar om. Hier gemeld zodat het werk niet onzichtbaar blijft. China: UnionPay APOP (03-04-2026), Ant AMP (08-06-2026) en JD A2P2 (11-06-2026) stonden nog nergens in het dossier — alle drie dragen identiteit-, intentie- en autorisatiebeheer, en in geen van de drie komt x402 voor; A2P2 eist met ARI bewijs over agent-versie én toestel. De 意见 van CAC/NDRC/MIIT (08-05-2026) stelt een registratieplatform voor agents voor met digitale identiteit; de betaalvereniging publiceerde 25-08-2026 de eerste "know your agent"-richtlijn onder de Volksbank, met aansprakelijkheid bij de vergunninghouder. HKMA verleende 10-04-2026 de eerste stablecoin-vergunningen (HSBC, Anchorpoint). India: PA Directions 2025 par. 13(j) — handelaren aangebracht t/m 31-12-2025 volledig doorgelicht binnen een jaar na 15-09-2025, dus 15-09-2026, twaalf dagen weg, raakt trede 3 rechtstreeks. UPI × TIPS: RBI en ECB sinds 21-11-2025 in de realisatiefase van een directe India-eurozone-rail, afwezig in ons dossier. Correctie op onze eigen kaart van 02-09: Global Fintech Fest is 8-11 september volgens de organisatie zelf, niet 9-11. Zo zet je dit in de markt: drie Chinese protocollen die identiteit regelen zónder x402 tonen dat de agent-identiteitslaag geen westers probleem is maar een universeel — en dat wie hem in Europa eerst neerlegt, de standaard schrijft.03-09🔍 AUDIT — de deploy-poort heeft sinds gisteren een fix, en het zijn er nu tien takken die op één merge wachten — Vanochtend nagemeten in
/Volumes/8TB MM4/Rails4Mankind: .github/workflows/deploy.yml op main draagt nul paths-ignore-regels. De fix bestaat wel: fase BOUWEN zette hem gisteren op tak voorstel/2026-09-02-deploy-poort-pad-filter. Daarmee is het openstaande vonnis van 02-09 — de routine deployde drie runs lang de live engine terwijl haar eigen opdracht dat verbiedt — verschoven van een vraag naar een keuze. Het aantal voorstel/-takken op origin ging van negen naar tien, nog altijd geen enkele gemerged; voorstel/2026-08-29-dev-console-poort ligt er nu zes dagen terwijl live op v0.36.7 staat en het gat op productie open blijft. Bijgewerkt 03-09 13:20 (fase BOUWEN): het zijn er nu elf — deze fase levert per definitie een voorstel af en heeft er dus zelf een bijgezet (voorstel/2026-09-03-treasury-cap-typo-stil). Elf lokaal, elf op origin, nul gemerged, de oudste zes dagen. Vonnis: ◐ deels — gebouwd en getest, niet beslist. Zo zet je dit in de markt: niet naar buiten. Dit is het verschil tussen een routine die zegt dat ze een regel volgt en een die het aantoonbaar doet — en dat verschil is precies wat R4M aan klanten verkoopt.03-09
⚙️ PROTOCOLWACHT x402 — er komt een tweede handtekeningvorm bij, en de knop waarmee die aangezet wordt staat op 16 september — Commit
7488a46 (PR #3279) landde 02-09-2026 om 18:18 UTC in x402-foundation/x402, 12 bestanden. Aanleiding: Stellar Protocol 28 ("Adapter") haalde 27-08-2026 testnet en gaat 16-09-2026 in stemming op mainnet. Dat protocol zet de V2-arm van CAP-71 aan (SOROBAN_CREDENTIALS_ADDRESS_V2), en tot vandaag weigerde @x402/stellar die arm op twee plaatsen: de facilitator gooide invalid_exact_stellar_payload_unsupported_credential_type, en de handtekeningteller sloeg V2-entries stilzwijgend over. Beide accepteren nu V1 én V2. Bron: api.github.com/repos/x402-foundation/x402/pulls/3279 (opgehaald 03-09-2026) · CAP-71. Wat maX hierover al wist, en wat niet: het dossier kent Stellar als productie-facilitator sinds maart 2026 en de Stellar Development Foundation als premium-lid van de x402 Foundation. Wat er níét in staat is Protocol 28, CAP-71 of de stemdatum — het woord "Soroban" komt in de hele site niet voor. Dit is dus geen versiesprong maar een chain-uitbreiding die maX niet volgde. Zo zet je dit in de markt: gebruik de datum, niet de techniek. Op 16 september wordt een tweede niet-EVM keten volwaardig betaalbaar over x402, en dat is opnieuw een stuk betaal-kant dat af is terwijl de verdien-kant leeg blijft. De zin die dat verkoopt: "elke keten die erbij komt maakt het makkelijker om een agent te laten betalen, en geen enkele maakt het makkelijker om te bewijzen dat er een mens aan de andere kant staat." Let op de klok: een mainnet-stemming is geen deadline voor Franky — er is niets in te dienen. Dit is een datum om te kennen, geen datum om te halen.03-09
🆔 IDENTIFICATIE-CASE — sinds eergisteren moet elke Fransman zijn leeftijd bewijzen om op sociale media te komen, en de toezichthouder moet de methode goedkeuren — Beide kamers van het Franse parlement namen de wet aan op 21-07-2026 (Assemblée: 279 vóór, 81 tegen, na de Senaat dezelfde dag). Ze trad in werking op 01-09-2026: sindsdien kan niemand onder de 15 nog een nieuw sociaal-media-account aanmaken. Handhaving op bestáánde accounts start januari 2027. Frankrijk is het eerste EU-land met zo'n verbod. De kern voor ons zit in het staartje: om de min-15-jarigen eruit te houden moet het platform van iedereen de leeftijd vaststellen, en de gebruikte verificatiemethode moet door de Franse toezichthouder goedgekeurd zijn. Bronnen: therecord.media · Al Jazeera, 21-07-2026 · France 24. Waarom dit een R4M-vorm is en geen leeftijdsscanner: een platform dat aan deze wet voldoet met een ID-scan heeft de identiteit van al zijn Franse gebruikers in huis — precies wat de privacytoezichthouder niet wil en wat het platform aansprakelijk maakt. Wat het nodig heeft is één bit ("ouder dan 15") uit een bron die de staat vertrouwt, zonder de rest. Dat is een attestatie-oproep (meter M2), en de eerste keer dat de mens de wortel legt is een verificatie (M1). 🔌 Integratievorm: OIDC-knop naast de bestaande login, met een
age_over_15-claim in plaats van een identiteit. Opzetpad: (1) draait al — de OIDC-flow naar de eID-broker staat en itsme_eid meldde vannacht verified=true; (2) Franky bouwt de leeftijdsclaim als afgeleide attestatie bovenop het bestaande attest, schatting 3–5 dagen, want de wortel en de hash bestaan al en dit is een extra claimveld; (3) de klant zet één redirect-URL en één knop bij; (4) standaard is OIDC + de EUDI-lijn (eIDAS 2.0), niet iets eigens; (5) kleinste demo zonder toestemming van wie dan ook: een publieke testpagina die "ouder dan 15: ja" toont zonder één persoonsgegeven te bewaren. 🧩 Productmix: V (verificatie) + C (de uniciteitskern) — de rail doet hier niet mee, er stroomt geen geld. Landt op trede 1: pure attestatie. Groeipad: begin met het leeftijdsattest, schakel later "één mens, één account" bij, want dat is de vraag die het platform zelf al heeft en die deze wet niet stelt. ❓ Keuzevraag voor Franky, niet door mij te gokken: itsme dekt BE en NL. Voor Frankrijk is dit een EUDI-wallet-verhaal, en die wallets moeten er per eind 2026 zijn. Pitch je dit nu al aan Franse platforms als voorbereiding, of hou je het bij BE/NL-klanten met een Franse gebruikersgroep? Dat verschil bepaalt of dit een gesprek van deze maand is of van volgend jaar. Zo zet je dit in de markt: niet "wij doen leeftijdsverificatie" — daar zijn er tien van. Wél: "u moet straks van iedereen de leeftijd kennen en van niemand de identiteit bewaren; dat zijn twee tegengestelde eisen, tenzij de leeftijd uit een attest komt in plaats van uit een document."03-09
🆔 IDENTIFICATIE-CASE — een focusgroep kost €1.500 en er bestaat geen enkele regel die verhindert dat dezelfde man er drie keer in zit — Vandaag aan de bron nagemeten. Intotheminds (Brussel) publiceert twee cijfers: de deelnemer krijgt €50–200 voor een sessie van twee uur, en de opdrachtgever betaalt vanaf €1.500 excl. btw per focusgroep, met minimaal drie sessies aanbevolen — dus €4.500+ per studie. intrinsiQ (Gent), een Belgische veldwerkrecruiter, beschrijft op zijn deelnemerspagina de hele weg: mail-uitnodiging, screeningsformulier, telefoontje, vergoeding. Wat er niet staat, en dat is de vondst: geen enkele regel over hoe vaak iemand mag deelnemen, en geen panelomvang. De frequentiegrens die elk kwalitatief bureau zegt te hanteren ("niet vaker dan eens per zoveel maanden") staat nergens als afdwingbare regel — hij bestaat als screenervraag, en een screenervraag is een vraag aan de persoon die er belang bij heeft te liegen. Waarom dat geld kost en geen principe is: de beroepsrespondent is een gedocumenteerde industrieklacht, en één verpeste sessie kost moderator, zaal, acht vergoedingen en de tijd van de meekijkende klant. Het bureau koopt vandaag al de zekerheid die het niet krijgt. 🔌 Integratievorm: API-sleutel op de backend van de recruiter, één aanroep bij selectie. Opzetpad: (1) draait al — hash-dedup en de attestatie-endpoints staan,
attestations verified=true vannacht; (2) Franky bouwt een frequentievenster op de hash ("deze hash zat in de laatste N maanden in een groep"), schatting 2–4 dagen, want dit is een query op bestaande attestaties, geen nieuw bouwwerk; (3) de recruiter roept bij elke selectie één endpoint aan en krijgt ja/nee terug — hij hoeft niets over te dragen wat hij niet al heeft; (4) standaard: gewone REST met API-sleutel, geen protocolkeuze nodig; (5) kleinste demo zonder toestemming: twee testhashes en een venster van 90 dagen, live te tonen in een gesprek van tien minuten. 🧩 Productmix: C (uniciteitskern) + V, en optioneel de rail voor de uitbetaling — maar begin daar niet. Trede 1, met een echt groeipad: eerst het frequentievenster verkopen als antifraudelaag, later de vergoeding over de rail laten lopen (88% naar de deelnemer, dezelfde avond in plaats van een cadeaubon na vier weken). Zo zet je dit in de markt: de openingszin is hun eigen pagina. "U vraagt uw deelnemers zelf of ze recent aan onderzoek meededen. Wat gebeurt er met wie daarop nee zegt en het antwoord is ja?"03-09
📚 GAT IN HET EIGEN DOSSIER — maX heeft een compleet pay-per-crawl-verhaal en kent de standaard niet waarmee uitgevers dat regelen — Vanochtend gecontroleerd met de maX-bril:
grep op "Really Simple Licensing" geeft nul treffers in de hele site, terwijl cases-db.json een uitgewerkt dossier draagt over Cloudflare Pay Per Crawl, de Monetization Gateway, de miljard 402-antwoorden per dag en de blokkade van 15-09. RSL is de open standaard waarmee een uitgever machineleesbaar zet wát een AI-bedrijf met zijn tekst mag en wat dat kost — via robots.txt, HTML-metatags, HTTP-headers, RSS, mediabestanden en schema.org, in XML. Ondersteunde modellen: pay-per-crawl, pay-per-inference, attributie, abonnement en gratis. Achter de standaard staan Reddit, Yahoo, Vox Media, Ziff Davis, Internet Brands, USA Today, O'Reilly Media, Creative Commons, Cloudflare, Fastly en Akamai; de non-profit RSL Collective int en verdeelt de royalty's collectief, zoals een auteursrechtenorganisatie. Bron: rslstandard.org (opgehaald 03-09-2026). Waarom dit voor ons het interessantste woord van de nacht is: pay-per-inference. Pay-per-crawl rekent af per keer dat een bot de tekst ophaalt; pay-per-inference rekent af per keer dat een model die tekst gebruikt om iemand te antwoorden. Dat tweede is per definitie een gebeurtenis met een mens aan het einde — en niemand in die keten bewijst dat die mens bestaat of uniek is. Dat is exact de plek waar deze rail hoort. Wat het níét is: RSL is een licentietaal, geen betaalrail en geen identiteitslaag. Het zegt wat iets kost en wie de rechthebbende is; het zegt niets over wie betaalt of wie ontvangt. Het is dus geen concurrent en ook geen bedreiging — het is het ontbrekende woord in ons eigen verhaal. Zo zet je dit in de markt: in elk uitgeversgesprek is dit vanaf nu de brug. "U regelt met RSL wat uw tekst mag kosten en Cloudflare int het per crawl. Wat geen van beide u geeft, is het onderscheid tussen duizend opvragingen door één bot en duizend antwoorden aan duizend verschillende mensen — en dat is precies het verschil waar uw tarief op hoort te staan." Voorstel, geen uitvoering: RSL en RSL Collective horen als term in het bouwboek en in het uitgeversdossier; ik heb de copy niet aangeraakt, want dat is niet aan mij.03-09
🤖 AGENTIC PAYMENTS — het gat dat ons India-dossier twee dagen geleden benoemde, wordt volgende week door NPCI zelf op een podium gezet — Reuters via Business Recorder (drie bronnen, gepubliceerd rond 01-09-2026): NPCI bereidt het Unified Agent Protocol voor, te onthullen op het Global Fintech Fest in Mumbai in de week na 1 september. Het bouwt op twee bestaande UPI-mechanismen: UPI Circle (een rekeninghouder delegeert betaalbevoegdheid) en Reserve Pay (geld blokkeren voor meerdere afschrijvingen). Banken houden die blokkades nu op ₹10.000 (~$105) voor maximaal 90 dagen; die drempel wordt voor agent-gebruik heroverwogen. Het protocol krijgt "ingebouwde bestedingslimieten, audit trails en identity checks", en de klant zet regels voor wanneer en hoeveel een agent mag betalen. Eerste toepassing: kleine, frequente aankopen zoals boodschappen. Aansprakelijkheidskader: aangekondigd, niet uitgewerkt. Dit is een bevestiging, geen ontdekking — en dat is het punt. maX draagt sinds 01-09-2026 het dossier "R4M maX IN — De Vertrouwenslaag bovenop India's DPI", waarin met zoveel woorden staat dat agentic-UPI een publiek erkend gat is: geen mandaat- of uniciteitsbewijs boven de transactielimiet. Twee dagen later kondigt NPCI het protocol aan dat dat gat moet dichten — en de aankondiging noemt limieten, audit trails en identity checks, maar geen uniciteit. Delegatie regelt welke agent voor welke rekening mag betalen. Het regelt niet dat achter die rekening één echt, uniek mens staat. Zo zet je dit in de markt: dit is geen verkoopactie deze week — het is de datumstempel onder een dossier dat al geschreven is. De waarde zit erin dat het dossier vóór de aankondiging klopte. Dat is precies wat je aan een Indiase gesprekspartner laat zien: niet dat je het gat kent, maar dat je het benoemde voordat NPCI het toegaf.
03-09💶 FUNDING — het bord opnieuw geteld op de dag van vandaag: vier harde datums, en de klok is het enige dat veranderde — Base Batches 004 — sluit 09-09-2026, hard, nog 6 dagen. Alles wat gisteren onzeker was is gisteren al weggenomen (deadline bevestigd op de aanvraagpagina, geen teamgrootte-eis). Geen nieuwe 🚨 en geen push: er is vandaag geen nieuw feit, alleen een dag minder, en een vlag die elke dag wappert is geen vlag. Enige verandering: dit is nu het laatste weekend waarin het dossier geschreven kan worden. Start it @KBC — sluit 14-09-2026, hard, nog 11 dagen; de openstaande vraag (is een solo-oprichter toelaatbaar?) is nog altijd één mail van vijf minuten en blokkeert de andere elf dagen. Eurostars Call 11 — sluit 10-09-2026, hard, nog 7 dagen, maar de actie blijft niet indienen: er is een partner in een tweede Eurostars-land nodig en die is er niet. Een harde datum die je niet kán halen is geen urgentie. imec.istart — sluit 30-09-2026, hard, nog 27 dagen. Nieuw geopend en eerlijk afgeschreven: CYBER-11-EULEG (Digital Europe, "Strengthening EU cybersecurity capacities in line with legislative requirements") opende 01-09-2026 met deadline 14-01-2027. Ik zet hem niet op het bord: dit type oproep gaat naar consortia van overheden en CERT's, niet naar een eenmanszaak, en de CRA-hoek die R4M wél raakt is er te dun voor. Genoteerd zodat niemand hem volgende maand opnieuw "ontdekt". Niet bevestigd, dus niet geclaimd: Stellar Community Fund #46 staat op het bord zonder datum. De SCF-site noemt vandaag wel het bedrag (tot $150.000 in XLM, drie tracks) maar bevestigt geen open ronde of deadline — de laatste genoemde recap is #40. Dat blijft dus VERIFY, niet ingevuld. Relevant omdat de x402-vondst van vannacht precies over Stellar gaat: als er een ronde opengaat, is dit het moment waarop de inhoudelijke aansluiting het sterkst is.
03-09
🧪 TEST — 383 van 385 groen, geen versiedrift, en de vier verifieerbare checks staan alle vier op waar — Gemeten 03-09-2026 03:07 op branch
main, werkmap schoon. 63 testbestanden, 383 geslaagd, 2 overgeslagen (385 totaal), duur 11,28 s, exit 0 — identiek aan gisteren. Versie: repo VERSION 0.36.7 = package.json 0.36.7 = git-tag v0.36.7 = live v0.36.7. Geen drift. Checks uit /api/public/status, letterlijk: app_live verified=true · itsme_eid verified=true (sandbox, Signicat-discovery bereikbaar) · attestations verified=true · double_entry_ledger verified=true · settlement_adapter configured=true, verified=null · email_login configured=true, verified=null. Die twee null-waarden zijn geen fout maar de eerlijke stand: er staat een sleutel, en of de tegenpartij hem aanvaardt blijkt pas bij een echte uitbetaling of verzending. /api/public/reconciliation antwoordt 200. Netwerk base-sepolia, stage pilot — testnet, dus de geldweg draait end-to-end zonder echte waarde. Herhaalbaar met: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test en curl -s https://r4m-franky.fly.dev/api/public/status.03-09
📦 OMZET-LOPENDE-BAND — ledger-entry 23 staat erop, en het is voor het eerst een koper die zijn eigen prijs publiceert — Het volgende nog niet omgezette €100-moment (#8, focusgroepen) is vannacht door het who-pays-filter en de doctrine-toets gehaald. Uitkomst: ✅ PASS. Koper met naam en adres: intrinsiQ (Gent), iVOX, Intotheminds (Brussel), plus de kwalitatieve afdelingen van Ipsos en Kantar die recruitment uitbesteden. Budget bestaat vandaag: €1.500 excl. btw per focusgroep, gepubliceerd, drie sessies aanbevolen. Euro naar de burger: €50–200 voor twee uur, gepubliceerd. Dat is een echt €100-moment in één avond. Wat deze entry onderscheidt van #20 (StemUniek, ⚠ PARTIAL): daar was een koper maar geen euro naar de mens. Hier zijn beide bedragen door de verkoper zélf gepubliceerd, niet geschat. Eerlijke begrenzing, want die hoort erbij: de volumes zijn klein — duizenden sessies per jaar in België, geen miljoenen. Recruiters kunnen dit als bedreiging lezen in plaats van als gereedschap; positioneer het als hún instrument. En de €75–150 recruitmentkost per stoel die in het bronmoment stond, is niet publiek terug te vinden — die blijft VERIFY en mag niet als feit gebruikt worden. Volledige entry in
docs/USE_CASE_LEDGER.md #23.03-09📋 STAND VAN DE SPOREN — tien items, en vier sporen die eerlijk leeg blijven omdat maX het antwoord al had — Wat opleverde (tien items): spoor A twee identificatie-cases (Frankrijk, focusgroepen) · spoor B — zie hieronder · spoor C x402 (Stellar/CAP-71) en agentic (NPCI) · spoor E prospect iVOX · spoor H protocolwacht · spoor I het RSL-gat · spoor J funding · plus test, omzet-lopende-band en deze stand zelf. Wat leeg bleef, met reden: 🤝 x401 — geen commit sinds 01-07-2026 in
proof/x401 (laatste: f739b0e, README-uitlijning). Dat is exact wat gisteren al gemeld werd; er is geen nieuw feit, dus geen nieuw item. 📡 IoT-lijn — leeg. Wat de zoektocht opleverde was Cloudflare's standaardwijziging van 15-09-2026 (Training- en Agent-bots geblokkeerd op advertentiepagina's voor nieuwe en gratis domeinen), en de maX-bril wees uit dat het dossier die datum, die categorieën én de opt-out-mogelijkheid al woordelijk bevat. Geen vondst dus. De rest van wat de IoT-zoektocht opleverde waren leveranciersblogs en octrooien over infraroodmeting van bloedstroom — geen bedrijf, geen datum, geen koper. 💶 Geld-case (spoor B) — geen nieuwe. Dit is de derde nacht op rij en dat hoort gezegd in plaats van opgevuld. Wat vannacht het dichtst kwam, was de focusgroepen-case, maar die telt hier niet: hij is de verdieping van bestaande cases 55 en #8 uit de momentenlijst, en de opdracht zegt dat een verdieping geen nieuwe markt is. Een geld-case verzinnen om het blok te vullen zou de enige categorie zijn die niemand kan controleren. Spoor D (nieuwe use case) — geen aparte nieuwe: het RSL-spoor wijst er wel één aan (pay-per-inference met een mens aan het einde), maar dat is vandaag een woord in een standaard en nog geen toepassingsgebied met een koper. Als het dat wordt, is het een echte.03-09
🎯 PROSPECT — iVOX (Leuven), want zij hebben het panel én het probleem, en ze publiceren allebei zelf — Wie: iVOX, Belgisch onderzoeksbureau met een eigen panel van naar eigen zeggen ruim 100.000 Belgen, dat online focusgroepen en surveys uit dat panel draait. Waarom zij en niet een groter bureau: een bureau dat sample inkoopt kan het uniciteitsprobleem doorschuiven naar zijn leverancier. Een bureau dat zijn eigen panel bezit kan dat niet — bij hen is de dubbele deelnemer een eigen kwaliteitsprobleem én een eigen kostenpost, en de reputatie hangt aan de zuiverheid van dat panel. Dat maakt hen de eerste die de vraag echt voelt. Wie te contacteren: de panelmanager of de directie — geen inkoop, want dit is geen leveranciersgesprek maar een kwaliteitsgesprek. Bij een bureau van deze omvang is dat één of twee stappen, geen aanbesteding. Openingszin (letterlijk bruikbaar): "U verkoopt uw panel op zuiverheid. Vandaag berust die zuiverheid op wat uw leden zelf invullen bij de screener. Wij kunnen u per deelnemer een ja-of-nee geven op de vraag of dit dezelfde echte persoon is als vorige maand — zonder dat wij weten wie hij is, en zonder dat u iets over hem moet doorgeven." Waarom nu: de vondst van vannacht is dat de frequentiegrens die de hele sector zegt te hanteren, bij een Belgische recruiter nergens als afdwingbare regel staat — alleen als screenervraag. Dat is een controleerbaar gat in hun eigen etalage, en het is beleefd te benoemen omdat het bij iedereen zo is. ⚠ Franky beslist: ik maak geen prospect aan. Dit is een voorstel voor de lijst; vandaag staan er 56 op en intrinsiQ noch iVOX staat erbij.
02-09
⚙️ PROTOCOLWACHT — x402 breidde vanmiddag de exact-spec uit, en schrijft er met zoveel woorden bij dat er géén terugbetaling in staat — Commit
De zin die ons raakt, letterlijk uit de spec. Onder
Met de r4m-maX-bril gecontroleerd, en het antwoord is deels "dat wisten we al". Het dossier kent sinds de radar-entry van vandaag het
Zo zet je dit in de markt: zodra een protocol zegt "wij definiëren geen terugbetaling, regel het zelf", is de enige bescherming die overblijft weten wie er aan de andere kant staat. Dat is geen betaalprobleem meer, dat is een attestatieprobleem — precies onze kant van de rail. 🔌 Integratievorm: x402-resource — de bron zet naast
23173acb (PR #3145) landde vandaag om 16:58 UTC op specs/schemes/exact/scheme_exact.md in x402-foundation/x402, +37/−2 regels. Bron: api.github.com/repos/x402-foundation/x402/commits/23173acb53, opgehaald 02-09-2026 19:0x. Drie dingen veranderden. (1) Het exact-schema MAG voortaan de upfront-stroom gebruiken (settle → resource → respond) wanneer de bron betalingsfinaliteit nodig heeft vóór uitvoering. (2) Er staat een nieuwe sectie Asset Transfer Method Families in, die overdrachtsmethoden in families splitst naar wie de waardeverplaatsende operatie indient; voor de familie facilitator-submitted MOET elke methode vier dingen verklaren — wie de netwerkkost draagt, welk replay-primitief geldt, welk geldigheidsvenster, en of een dubbele indiening aan de netwerkinterface te onderscheiden is van het origineel. (3) Er komt een MOET bij op transfer correctness: settlement moet exact één identificeerbare overdracht van amount van asset naar payTo opleveren. De zin die ons raakt, letterlijk uit de spec. Onder
upfront committeert de betaling eerst, dus een mislukte handler laat de client betaald achter zonder levering — en dan: "this specification defines no refund, and any remedy is the resource server's own arrangement." Het protocol wijst het verhaal expliciet af en legt het bij de resource server. Daar komt een tweede scherpe regel bovenop: waar het replay-primitief gedeeld is met de rekeningstand van de betaler, kan niet-gerelateerde activiteit van diezelfde betaler de betaling ongeldig maken nadat de handler al gedraaid heeft. Met de r4m-maX-bril gecontroleerd, en het antwoord is deels "dat wisten we al". Het dossier kent sinds de radar-entry van vandaag het
auth-capture-schema mét refund, void en reclaim — dáár is terugbetalen wél gespecificeerd. Wat maX niet kende: dat het exact-schema onder upfront bewust het tegenovergestelde doet. Het woord upfront komt in de hele public/-map nul keer voor (gemeten 02-09-2026 19:0x). En dit is geen versiesprong: de spec blijft v2, de hoogste tag blijft pypi-x402@v2.21.0 — wat maX kent klopt, dit is een uitbreiding bínnen v2. Zo zet je dit in de markt: zodra een protocol zegt "wij definiëren geen terugbetaling, regel het zelf", is de enige bescherming die overblijft weten wie er aan de andere kant staat. Dat is geen betaalprobleem meer, dat is een attestatieprobleem — precies onze kant van de rail. 🔌 Integratievorm: x402-resource — de bron zet naast
extra.paymentFlow: "upfront" een attest-eis op de betaler, en wij leveren het attest. Opzetpad: (1) draait al — ons x402-endpoint op testnet plus /api/attest en /api/gate; (2) Franky bouwt — een controle die vóór /settle het attest van de betaler leest en bij ontbreken de 402 laat staan: 2–4 dagen bovenop de bestaande paywall; (3) de klant — zet één veld om en verandert verder niets; (4) standaard — x402 exact + upfront, geen eigen vinding; (5) kleinste demo zonder toestemming — een eigen upfront-resource die zonder attest 402 blijft geven en mét attest levert. 🧩 Productmix: V (verificatie) + G (gate); de rail doet niet mee, alleen de attestatiekant. Trede: attest-only, met de rail als groeipad zodra er een echte betaler is. Geen koper vanavond — dit is positionering plus een bewakingspunt, en wie het als omzet leest, leest het verkeerd.02-09🔍 AUDIT ✓ echt — de deploy-keten van vandaag is nagemeten in plaats van geloofd, en ze klopt byte voor byte — Drie fasen beweerden vandaag te deployen: VINDEN (03:31), RAPPORTEREN (08:13) en BOUWEN (13:27). Een bewering is geen bewijs, dus de avondronde heeft de live site tegen de schijf gelegd. Uitkomst:
Waarom dit een vonnis verdient en geen schouderklopje. De aanleiding was een vals alarm dat bijna een echt alarm werd: de oppervlakte-check mat
r4m-core-v2-k7x9.pages.dev/marktradar.html is 424.849 bytes — exact de omvang van het bestand op schijf; 122 agenda-items live tegenover 122 op schijf; 20 items met datum 02-09 op allebei; cases-db.json live met 210 auditblokken en als nieuwste blok het voorstel-blok van 13:27; nieuwste ochtendrapport 02-09-2026 08:30. Alles van vandaag staat live. Waarom dit een vonnis verdient en geen schouderklopje. De aanleiding was een vals alarm dat bijna een echt alarm werd: de oppervlakte-check mat
r4m-core-v2-k7x9.pages.dev/ op 229.155 bytes, tot op de byte gelijk aan de meting van 01-09. Dat leest als "er is vandaag niets uitgerold". De verklaring is onschuldig — die check haalt index.html op, en dát bestand veranderde vandaag niet, terwijl marktradar.html en cases-db.json wél veranderden. De les zit in de meetfout, niet in de deploy: de oppervlakte-check bewaakt de startpagina en zegt niets over de bestanden waar het werk in staat. Dat is dezelfde familie als de EU-wiki die 200 geeft en naar een loginpagina leidt, en als r4m-max.pages.dev — een getal dat gezond oogt en de verkeerde vraag beantwoordt. Zo zet je dit in de markt: niets, dit is intern. Het staat hier omdat een routine die haar eigen deploys niet nameet, precies het soort bewering produceert dat wij bij anderen doorprikken.02-09🧪 BRONNENRONDE — 28 van de 28 bronnen leven, nul dood, nul omgeleid, tweede ronde op rij zonder reparatie — De avondronde van
Wat de ronde wél verschoof. De SEO-keten groeide van 121.024 naar 135.229 bytes — die keten leeft, en het is precies de keten die op 09-07 stilviel zonder dat iemand het zeven weken merkte. Belangrijker: de protocolwacht-bronnen leverden vanavond hun eerste eigen treffer op. De commits-API van x402 stond sinds de aanleg van de tabel op "levend, nog geen eigen treffer"; vanavond bracht ze de spec-uitbreiding van 16:58 UTC boven water. Een rij die twee dagen niets deed en dan het belangrijkste item van de avond levert, is het argument tegen het te snel wegsnoeien van stille bronnen.
docs/BRONNEN.md haalde alle achtentwintig levende bronnen één keer op en noteerde statuscode én omvang. 28/28 op HTTP 200. Nul 404, nul 301, nul nieuwe doorverwijzing. De drie EUDI-vervangers die het dode adres van 31-08 opvingen, houden alle drie stand; de ARF-tagwacht blijft op v3.0.0, dus geen versiedrift op EUDI sinds 21-07-2026. Wat de ronde wél verschoof. De SEO-keten groeide van 121.024 naar 135.229 bytes — die keten leeft, en het is precies de keten die op 09-07 stilviel zonder dat iemand het zeven weken merkte. Belangrijker: de protocolwacht-bronnen leverden vanavond hun eerste eigen treffer op. De commits-API van x402 stond sinds de aanleg van de tabel op "levend, nog geen eigen treffer"; vanavond bracht ze de spec-uitbreiding van 16:58 UTC boven water. Een rij die twee dagen niets deed en dan het belangrijkste item van de avond levert, is het argument tegen het te snel wegsnoeien van stille bronnen.
02-09
📚 BRONNEN — het Peppol-gat van 31-08 is dicht, en mydividend.ai is nu bewezen een lege schil in plaats van vermoed — Twee vragen stonden sinds 31-08 open in
(1) Peppol / BE e-facturatie had geen URL, alleen een
(2) mydividend.ai gaf voor de derde ronde op rij 2.274 bytes. Tot vanavond was de diagnose een vermoeden: "de pagina bouwt zichzelf in de browser op". Nu is het gemeten —
docs/BRONNEN.md. Allebei vanavond beantwoord. (1) Peppol / BE e-facturatie had geen URL, alleen een
zoekpad. Dat is nu een primaire overheidsbron: efacturatie.belgium.be/nl leidt met een 301 door naar efactuur.belgium.be/nl (200, 29.407 b, opgehaald 02-09-2026 19:0x). De pagina zegt het zelf: "Sinds 1 januari 2026 moeten alle Belgische btw-plichtige ondernemingen tussen elkaar gestructureerde elektronische facturen gebruiken." Met de maX-bril gecontroleerd: de inhoud is niét nieuw — cases-db.json kent de verplichting al met EN 16931, Peppol BIS Billing 3.0, de uitzondering voor grensoverschrijdende handelingen en de bewaartermijn van zeven jaar. Wat wél nieuw is, is dat de rij eindelijk een adres heeft dat je kan aanklikken en meten, in plaats van een zoekopdracht die elke nacht opnieuw uitgevonden werd. Dat is bronnenonderhoud, geen marktvondst, en het staat hier als het eerste en niet als het tweede. (2) mydividend.ai gaf voor de derde ronde op rij 2.274 bytes. Tot vanavond was de diagnose een vermoeden: "de pagina bouwt zichzelf in de browser op". Nu is het gemeten —
/about geeft exact dezelfde 2.274 bytes als de startpagina. Twee verschillende adressen, één identieke schil: het is geen dunne startpagina, het is een site die aan een routine niets dan een omhulsel geeft. Daarmee is het derde bewijsstuk binnen voor het voorstel van 01-09 om regel 1 uit te breiden met een inhoudsdrempel — naast de statuscode ook de omvang meten, en een 200 onder een paar duizend bytes markeren als ⚠ lege schil in plaats van als ✓. Dat voorstel ligt bij Franky en is vanavond niet zelf doorgevoerd; tot hij beslist blijft regel 1 zoals ze is.02-09💡 VOORSTEL — het deploy-gat van vannacht ligt nu als code op een tak, en het overslaan is bewezen in plaats van aangenomen — Vannacht stelde de routine vast dat élke push naar main de motor uitrolt, ook een commit met alleen een dagrapport — Actions-runs 33418606357 (31-08), 33560536483 (01-09) en 33579539511 (02-09), drie no-op herdeploys van v0.36.7 op rij. Vanmiddag ligt de fix op voorstel/2026-09-02-deploy-poort-pad-filter (commit 5a824f7): één bestand,
paths-ignore op ops/**, site/**, docs/** en *.md. Het scherpe punt is niet de filter maar het bewijs eronder: ops/ en site/ staan al in .dockerignore en bereiken het image niet, en docs/ zit er wél in maar wordt nergens gelezen — grep -rn "docs/" src geeft alleen commentaar en sourceRef-labels. VERSION is bewust uitgezonderd, want die wordt wél gelezen, dus een versiebump rolt gewoon uit. Een gemengde commit deployt ook nog steeds. Geverifieerd op de tak: tsc schoon, 383 groen, boot v0.36.7, demo end-to-end. Niet gemerged. Zo zet je dit in de markt: dit is precies het verhaal dat een staat wil horen — een leverancier die zijn eigen uitrolpoort betrapt, het bewijst met run-nummers, en de fix ter goedkeuring voorlegt in plaats van hem stilletjes te mergen.02-09💶 FUNDING — twee open vragen van het bord zijn vanmiddag beantwoord, en allebei halen ze een smoes weg — Dit is geen hertelling van vanmorgen maar wat er sindsdien is nagekeken. (1) imec.istart is herbevestigd. De aanvraagpagina gaf op 01-09 nog HTTP 500 en de regel droeg eerlijk "niet herbevestigd"; vandaag antwoordt dezelfde URL met 200 en zegt letterlijk "Open call Sept 1 - Sept 30 (midnight)" voor België, met een actieve APPLY NOW. Sluitdatum 30-09 staat nu bij de bron — 28 dagen, geen vlag, wel de langste harde datum die je solo kán halen. (2) De teamgrootte-vraag bij Base Batches 004 is beantwoord. Dat was letterlijk de actie op die regel: open het formulier en kijk of er een veld over teamgrootte in staat. Gedaan — base.org/batches/apply bevestigt "Sep 9" en noemt nergens teamgrootte, aantal oprichters of een co-founder-eis. Solo is niet uitgesloten. Verder: de EIC-bundeling van september was gisteren (eerste dinsdag, 17:00 Brussel), dus wie nu indient valt in die van di 6 oktober — planning, geen paniek. En Circle spreekt sinds kort over "our first cohort of 2026": cohort-taal betekent rondes, ook zonder gepubliceerde datum. Zo zet je dit in de markt: op het bord staat nu geen enkele openstaande vraag meer tussen jou en de twee eerstvolgende aanvragen — wat overblijft is indienen.
02-09🔍 AUDIT ⏱ — een 🚨-regel droeg twaalf dagen een toelatingsclaim die niet bij de bron staat — De Start it @KBC-regel stelde gerust met "solo-oprichter is hier geen beletsel". Op een harde datum met nog twaalf dagen te gaan is dat niet één detail tussen andere — het is de enige vraag die bepaalt of het dossier zin heeft. startit-x.com is vandaag opgehaald: de pagina bevestigt netjes "14.09.2026" en de verplichte tweedaagse bootcamp op "28.10.2026", maar zegt níéts over solo versus team. De enige doelgroepzin gaat over background, gender, age en nationality — over achtergrond dus, niet over aantal. Het vonnis is ⏱ en geen ⚠: de claim is niet weerlegd en kan uit een eerdere bron komen. Maar het verschil tussen "gecontroleerd" en "aangenomen" hoorde zichtbaar te zijn en was dat niet. De kanttekening staat nu op de regel, de claim is niet geschrapt, en de actie is één mail vóór er twaalf dagen in een dossier gaan. Zo zet je dit in de markt: een bord dat zijn eigen zekerheden durft af te zwakken is het enige soort bord waar je een beslissing op kan nemen.
02-09🧪 TEST — de voorstel-tak meet hetzelfde als main, en dat is hier het hele punt — Vanmorgen stond 383 van 385 op main. Vanmiddag is diezelfde suite opnieuw gedraaid, nu op voorstel/2026-09-02-deploy-poort-pad-filter: 383 groen, 2 overgeslagen, 63 bestanden,
npx tsc --noEmit schoon, server boot op v0.36.7 en npm run demo loopt end-to-end door met alle vijf de reconciliatie-invarianten groen (I1 geld behouden · I2 elke transactie sluit op nul · I3 saldi gelijk aan wat geboekt is · I4 gefinancierd gelijk aan gehouden plus betaald plus fees · I5 niets uit het niets betaald). Gelijk blijven is bij een CI-wijziging de gewenste uitkomst: de tak raakt geen enkele regel applicatiecode. Herhaalbaar met npx tsc --noEmit && npm test en, met de server op poort 4099, R4M_URL=http://localhost:4099 npm run demo. Zo zet je dit in de markt: elke wijziging aan deze rail komt met het commando waarmee de koper hem zelf natelt.02-09📰 OCHTENDRAPPORT 02-09 — de nacht in een zin: het protocol dat een geverifieerde mens aan de wortel zet, kreeg een tweede implementatie en die schrijft ons gat publiek op — Het ochtendrapport over het venster 01-09 08:30 → 02-09 08:30 staat live op de Ops-tab. Twaalf radar-items vannacht, zes uitgewerkte vondsten in het rapport. De drie zwaarste: (1) Solidus Network zette op 01-09 04:32 UTC de eerste onafhankelijke x401-verifier live en beschrijft in issue proof/x401#41 dat hij een agent niet kan vertellen waar een aanvaardbaar bewijs vandaan komt; (2) GLEIF publiceerde op 01-09 haar vLEI-analyse voor agent-betalingen en verwijst de individuele credential-laag uitdrukkelijk naar anderen; (3) peaq × World ID (25-08) is het eerste tegenvoorbeeld op onze absolute claim — daar ís X wel een uniek mens, via iris-biometrie in plaats van een eID-wortel. Backup-alarm schoon, ketencheck exit 0, testsuite 383/385 groen, geen versiedrift (repo en live allebei v0.36.7), reconciliatie sluit op alle vijf de invarianten. Zo zet je dit in de markt: alle drie de vondsten wijzen naar hetzelfde bouwstuk van 3–5 dagen — een vct-URL plus SD-JWT-profiel voor het uniciteitsattest. Dat is de kleinste stap tussen "wij zeggen dat we het kunnen" en "een machine kan ons vinden".
02-09📊 SEO-VLOOT — de keten meldt zichzelf groen terwijl tien van de achttien domeinen niet meebewegen — Gemeten vanochtend 02-09 aan de bron (
/api/seo-watch, sync 03:57): 18 domeinen op het bord, maar slechts 8 met een meting van vandaag. Samen 102 klikken op 2.596 vertoningen. Beweging waar er beweging is: channel-zero.be mobiel CWV 65 → 71 (+6), klikken 32 → 41, positie 7,3 → 7,7, onsite blijft 68 met vier openstaande fouten (canonical, schema, robots, sitemap). boombedrijfbisschop.be 84/76 (+1), 21 klikken. idgs.eu 95/80 op 526 vertoningen maar positie 32,5. lowlands.business 89/93 met 0 klikken op 132 vertoningen. gevelsteenbedrijf-v6 onsite 56, vijf fouten, laagste van de vloot. turbeau2rock.com en qmtex.net: mobiele CWV-meting mislukt. De tien die stilstaan: hiddengarden.be en hiddengarden-dsvdbuild (laatste meting 03-07), kortrijkspurs.be (03-07), en zeven domeinen die op 28 of 30 augustus stopten (plastimet, michiel-haverans-yware, elkodent, cobras-architects, ecoyess-landing, kortrijk-spurs-dsvdbuild, my-cccnew). De ketencheck zegt "SEO-meting 0 dagen geleden" omdat er íets gemeten wordt — dat is waar en toch misleidend. Zo zet je dit in de markt: niet naar buiten, maar naar binnen. Dit is exact het patroon dat op 9 juli zeven weken onopgemerkt bleef: een keten die groen meldt op basis van het deel dat nog werkt. De ketencheck heeft een tweede vraag nodig — niet "is er gemeten?" maar "is alles gemeten?".02-09⏰ DEADLINE VERSTREKEN — de slapende-tegoeden-case (item 25) had een wettelijke datum op 1 september en die is gisteren gepasseerd zonder beslissing — Item 25 stond sinds 30-08 op status "beantwoord" en stond drie ochtendrapporten op rij als actiepunt 1, telkens met de wettelijke deadline erbij. Vanochtend gecontroleerd in de doorloop-API: nog steeds "beantwoord", 47 items totaal waarvan 12 op "beantwoord" en nul op "goedgekeurd". De datum is verstreken. Dit is geen uitstel meer maar een uitkomst, en die hoort genoteerd in plaats van doorgeschoven. Zo zet je dit in de markt: nergens — dit is een interne les. Een item met een wettelijke klok hoort niet dezelfde behandeling te krijgen als een item zonder. Vraag aan Franky: sluiten we item 25 af als "gemist", of is er een tweede weg via een latere referteperiode? Zolang dat niet beslist is, blijft het de lijst vervuilen als een openstaand punt dat niet meer open kan.
02-09📊 PIJPLIJN — 56 prospects op de lijst, nul gecontacteerd, en de geld-case blijft voor de derde run op rij leeg — Geteld in
cases-db.json op 02-09: 56 prospects, waarvan 52 op "uitzoeken" en 4 op "benaderen". Gecontacteerd: 0. Gereageerd: 0. De lijst groeit elke nacht, de eerste brief is nog niet vertrokken. Tegelijk bleef spoor B (de geld-case) vannacht voor de derde keer op rij leeg: alle drie de hoofdvondsten zitten op de attestatiekant, meter M1/M2, geen enkele op M3. Die twee feiten horen bij elkaar. De zelfcontrole-afspraak van 31-08 zei: bij een derde lege run is de zoekmethode het probleem, niet de markt. De diagnose van vannacht: de methode jaagt op verse bedrijfsgebeurtenissen rond uitbetalen in het nieuws, en die leveren structureel attestatie-nieuws op, omdat dát is wat er gepubliceerd wordt. Zo zet je dit in de markt: draai de richting om. In plaats van te wachten tot het nieuws een geldstroom aanreikt, vertrek van de 56 prospects die er al liggen en vraag per prospect welke geldstroom er vandáág al loopt en waar een attest daarin past. Dat maakt van spoor B dossierwerk in plaats van nieuwsjacht — en het zet de 56 namen aan het werk in plaats van ze te laten liggen. Dit wijzigt het mandaat van de routine, dus het is een voorstel en niet iets wat zij zelf doorvoert: Franky beslist.02-09🚨 AUDIT ⚠ THEATER — de routine heeft de opdracht "nooit de engine deployen", en elke keer dat ze haar dagrapport wegschrijft deployt ze de engine — Vastgesteld vannacht 02-09-2026 om 03:3x, door het zelf te veroorzaken en daarna te controleren. Dit is geen theoretisch risico maar een gemeten feit, en het gebeurde deze nacht opnieuw. De twee regels die elkaar tegenspreken. Harde poort 10 van de routine zegt: "Nooit naar main van de engine pushen en nooit de engine deployen", met als reden dat elke push op main auto-deployt naar Fly. Maar afrondingsstap 7.4 van diezelfde routine zegt letterlijk: "Commit in /Volumes/8TB MM4/Rails4Mankind: dagrapport, SIGNALS_ADAPT.md, USE_CASE_LEDGER.md. Push." Eén document, twee opdrachten, en ze sluiten elkaar uit. Wat er technisch gebeurt.
.github/workflows/deploy.yml luistert op on: push: branches: [main] en heeft geen enkele pad-filter. Er staat geen paths-ignore voor docs/** of ops/**. Gevolg: een commit die uitsluitend een dagrapport en twee markdown-bestanden bevat, start dezelfde job als een codewijziging — typecheck, flyctl installeren, flyctl deploy --remote-only --app r4m-franky. Het bewijs, met run-nummers. Onze push van vannacht (106916b, 01:28 UTC) startte workflow-run 33579539511, status in_progress op het moment van schrijven. En het is geen incident: af4e5c7 (01-09 21:20, de avondronde met alleen BRONNEN.md) startte run 33560536483 — success. a977e01 (31-08 17:15, idem) startte run 33418606357 — success. Minstens drie routine-runs op rij hebben de engine gedeployd terwijl hun eigen opdracht dat verbiedt. Hoe erg is het echt — eerlijk, zonder dramatiseren. De schade is vandaag nul: er verandert geen regel applicatiecode in zo'n commit, dus Fly rolt exact dezelfde v0.36.7 opnieuw uit. Het is een no-op-herdeploy. Maar het vangnet is weg, en dát is het punt. De regel bestaat omdat een deploy van de live betaalmotor een handeling van Franky hoort te zijn. Een routine die elke nacht ongemerkt op die knop drukt, drukt er ook op de nacht dat er wél iets in staat wat er niet hoort — bijvoorbeeld wanneer iemand een tak merget en de routine daarna haar dagrapport wegschrijft op een tree die meer bevat dan documentatie. Waarom dit als ⚠ theater staat en niet als ⏱ opletten. De poort "wij deployen de engine nooit" wordt in elk nachtrapport impliciet waargemaakt, terwijl ze feitelijk elke nacht geschonden wordt. Een regel die zichzelf niet kan afdwingen en waarvan niemand merkte dat ze niet gold, is precies wat theater betekent. 🛑 Dit moet Franky beslissen — de routine mag het niet zelf oplossen. Drie uitwegen, en ze zijn alle drie klein: (1) pad-filter in deploy.yml: paths-ignore: ['docs/**', 'ops/**', '**.md'] — vijf minuten, lost het volledig op, en een echte codewijziging blijft gewoon deployen. (2) De documentatie verhuizen naar r4m-max-v2, zodat de routine de engine-repo helemaal niet meer aanraakt — schoner, maar het dagrapport staat dan niet meer naast de code die het beschrijft. (3) De regel schrappen en aanvaarden dat een no-op-herdeploy per nacht onschadelijk is — dan moet poort 10 herschreven worden, want nu liegt ze. Wat deze routine wél gedaan heeft: de push uitgevoerd zoals stap 7.4 hem opdraagt, en daarna zelf gecontroleerd wat die push veroorzaakte in plaats van het te laten passeren. Niets aan de workflow gewijzigd — dat is code, en code wijzigen mag alleen op een voorstel/-tak.02-09🤝 PROTOCOLWACHT x401 — het protocol staat twee maanden stil in zijn commits, maar er draait sinds gisteren een ONAFHANKELIJKE tweede implementatie, en die implementeerder legt precies het gat bloot waar wij in passen — Gemeten vannacht 02-09-2026 om 03:2x, rechtstreeks op de bron. De commits staan inderdaad stil — laatste commit
f739b0e8 van 01-07-2026, dat is 63 dagen. Dat meldden wij al op 29-08 en 30-08 en dat is geen nieuws meer. Wat wél nieuw is: de issues leven. Op 01-09-2026 om 04:32 UTC opende fatih-koc issue #41: "Implementer feedback, and one divergence from the W3C DC API protocol table". Hij schrijft: "We built an independent implementation of the x401 Verifier side and have it running publicly." Dat is de eerste implementatie van x401 door iemand anders dan de auteur. Wij hebben die demo zelf opgehaald en de header zelf gedecodeerd — niet overgeschreven uit het issue: https://auth.solidus.network/v1/x401/demo geeft HTTP 200 en stuurt een echte PROOF-REQUEST-header mee. Ontcijferd staat daarin: scheme x401, version 0.2.0, protocol openid4vp-v1-signed, een EdDSA-ondertekend request-object met client_id https://auth.solidus.network, en een DCQL-query in formaat dc+sd-jwt die precies één veld vraagt: given_name. DE KERN VOOR ONS — en wij hebben het zelf nagemeten, niet aangenomen. In dat request-object staat geen trusted_authorities. De implementeerder legt in #41 uit waarom, en het is geen slordigheid: zijn uitgevers zijn DID's zonder X.509-keten, en geen van de drie trusted_authorities-types van DCQL kan een DID benoemen — aki wil een RFC 5280-AuthorityKeyIdentifier, etsi_tl wil een certificaat in de keten, openid_federation wil een federatie-entiteit. Hij laat het veld dus weg. En dan schrijft hij de zin die voor R4M de hele nacht waard is: omdat x401 trusted_authorities hergebruikt als "the agent's acquisition and discovery surface", heeft een DID-gebaseerde Verifier geen enkele manier om een agent te vertellen wáár hij een aanvaardbaar bewijs moet halen. Vertaald naar gewone taal. Er staat een deur met een slot dat werkt, en er is geen bordje dat zegt welke sleutel past. Een agent die langskomt weet niet bij wie hij een geldig bewijs moet ophalen. Dat bordje is geen software — dat is een uitgever met een naam die je kan vertrouwen. En let op wat de demo vraagt: given_name. Een naam. Niet "is dit één echt mens", niet "is dit dezelfde mens als vorige keer". De tweede implementatie van het enige protocol dat een geverifieerde mens aan de wortel zet, vraagt in de praktijk een voornaam op. 🔎 Wat maX hier zelf al over zegt: x401.html en bouwregel f1 kennen het protocol en de stilstand. Wat er nergens staat is trusted_authorities, DCQL of het woord uitgever-vindbaarheid (grep 02-09-2026: nul treffers op "trusted_authorities" in de hele public/-map). 🔌 Integratievorm: R4M als uitgever van een uniciteitsattest in dc+sd-jwt, vindbaar via een trusted_authorities-vermelding. Opzetpad: (1) draait al — de attestatie-ondertekening staat en is vanavond geverifieerd (attestations: verified, 2 echte attestaties); (2) Franky bouwt — een vct-URL en een SD-JWT-profiel voor het uniciteitsattest, geschat 3 tot 5 dagen; (3) de klant doet — één regel in zijn DCQL-query; (4) standaard — OpenID4VP 1.0 + SD-JWT VC, geen eigen formaat; (5) kleinste demo zonder toestemming — onze eigen PROOF-REQUEST naast die van Solidus zetten, met trusted_authorities ingevuld waar die van hen leeg is. Dat is een screenshot, geen project. 🧩 Productmix: V (verificatie) + C (attestatie) — de rail doet hier niet mee, dit is de zuivere attestatiekant. Trede: identificatie. Meter: M2 (attestatie-oproep, ≈ gratis) met M1 bij elke nieuwe mens. Groeipad: begin als uitgever van één attest, schakel de rail pas bij wanneer er over dat attest betaald wordt. Zo zet je dit in de markt: dit is geen marketingverhaal maar een technisch gat met een issue-nummer eronder. Je kan in één zin zeggen wat je oplost, en de implementeerder heeft het probleem zelf al opgeschreven — je hoeft hem niet te overtuigen dat het bestaat.02-09🤖 AGENTIC PAYMENTS — de organisatie die wereldwijd bedrijven nummert, publiceerde gisteren haar antwoord op "wie stuurde deze agent", en zegt er zelf bij dat de mens-laag NIET van haar is — Op 01-09-2026 publiceerde Alexandre Kech, CEO van GLEIF (Global Legal Entity Identifier Foundation, Frankfurt) een analyse bij het discussiestuk "Agentic AI in Payments: Establishing Interoperable Trust and Control". Bron: biometricupdate.com, 01-09-2026. Wat het voorstelt. De vLEI (verifiable Legal Entity Identifier) als machineleesbare organisatie-identiteit: een cryptografische vertrouwensketen die volgens Kech "leads back to a verified individual within a verified organization". Ze verifieert drie dingen over een agent: wélke organisatie hij vertegenwoordigt, wélke bevoegdheid aan hem gedelegeerd is, en de grenzen van die bevoegdheid. Kech: "When those can be verified computationally, accountability stops depending on trust and starts depending on evidence." DE ZIN DIE ERTOE DOET. GLEIF positioneert de vLEI uitdrukkelijk als de organisatie-laag, bóven device- en agent-identiteit, en verwijst naar aanvullend werk op device- en individueel credential-niveau als andermans terrein. Met andere woorden: de instelling die de bedrijvenkant van dit probleem bezit, zegt in haar eigen stuk dat de individuele laag niet van haar is. Waarom dat groter is dan het lijkt. Een vLEI bewijst dat een agent namens een geverifieerd bedrijf handelt, met een geverifieerd persoon ergens in de keten. Wat ze niet bewijst: dat die persoon één keer voorkomt. Een bedrijf kan honderd bevoegde vertegenwoordigers registreren, en niets in dit model zegt of dat honderd mensen zijn of één mens met honderd rollen. De uniciteitsvraag wordt in dit voorstel niet opgelost, ze wordt netjes doorgeschoven. 🔎 Wat maX hier zelf al over zegt: niets. "vLEI", "GLEIF" en "Legal Entity Identifier" komen op de hele
public/-map nul keer voor (grep 02-09-2026). Dat is de eerlijke kop: er is een zwaargewicht bijgekomen in ons veld en ons dossier kende hem niet. Ter vergelijking: de IMF-notitie 2026/004 over hetzelfde onderwerp stáát er wél in (radar 31-08) — dit is de aanvullende, institutionele kant ervan. 🔌 Integratievorm: naast de vLEI gaan staan, niet ertegen. Concreet een OIDC-knop of een attest-endpoint dat de individuele laag levert die GLEIF openlaat. Opzetpad: (1) draait al — eID/itsme-koppeling staat (sandbox geverifieerd 01-09 21:22) en de attestatie-ondertekening werkt; (2) Franky bouwt — een kaartje van één pagina dat de vLEI-keten naast de R4M-keten legt en toont wat elk van beide wél en niet bewijst, geschat 1 dag; (3) de klant doet — niets, dit is verkoopmateriaal vóór er code is; (4) standaard — vLEI/KERI aan hun kant, OpenID4VP aan de onze; (5) kleinste demo — dat kaartje. 🧩 Productmix: V + C, attestatiekant alleen, trede identificatie, meter M1 bij verificatie en M2 bij raadpleging. De rail doet niet mee. Onduidelijk en dus een keuzevraag voor Franky, niet gegokt: wil je R4M positioneren als aanvulling op vLEI (samenwerkingsverhaal, trager maar geloofwaardiger) of als eigen laag die de vLEI niet nodig heeft (sneller te vertellen, maar je zet je tegenover een instituut)? Dat is een positioneringskeuze en geen technische. Zo zet je dit in de markt: je hoeft niet te beweren dat GLEIF het fout doet. Je citeert hun eigen afbakening. "De instelling die bedrijven nummert zegt zelf dat de mens-laag er niet bij zit" is een sterkere openingszin dan elke claim die je zelf verzint.02-09📡 IoT-LIJN — robots controleren sinds vorige week of jij een mens bent, en de reden is banaal: anders pakt iemand twee gratis flesjes — Op 25-08-2026 maakte peaq bekend dat robots en machines op
peaqOS proof-of-personhood kunnen verifiëren via World ID, uitgevoerd via robotic.sh. Bron: biometricupdate.com, 25-08-2026. Hoe het werkt. De machine houdt haar eigen identiteit vast met een peaq-DID; de mens tegenover haar bewijst met een zero-knowledge-bewijs dat hij een mens is, zonder identiteitsgegevens te delen. Resultaat volgens peaq: "a verifiable and auditable record of the result with redacted proof metadata." De cijfers, zoals gepubliceerd. 18 miljoen mensen registreerden hun iris bij World's Orbs, uitdrukkelijk voor deduplicatie. World haalde in juli $52,5 miljoen op via een tokenverkoop. De drie genoemde toepassingen — en let op de tweede. Medicijnbezorging door een robot. Eén-per-persoon-weggeefacties bediend door een robot. Verhuur zonder dat de klant een account moet aanmaken. Dat middelste geval is letterlijk de R4M-kernzin, alleen met een robot in plaats van een website: iets mag één keer per mens, en het systeem moet dat kunnen tellen. 🔎 Wat maX hier zelf al over zegt: World ID kent het dossier uitgebreid (twaalf bestanden). peaq staat er nul keer in (grep 02-09-2026). Nieuw is dus niet World ID, nieuw is dat uniciteit uit de browser stapt en op een fysieke machine gaat draaien. Dat is het eerste concrete IoT-bewijs in ons veld in plaats van een redenering. Wat het voor ons betekent, eerlijk. Dit is ook een concurrentiesignaal: op de plek waar wij "één mens, één keer" verkopen, staat nu een werkende stapel met 18 miljoen registraties. Ons verschil blijft het bindingsverhaal — World ID bewijst mens-zijn via biometrie, R4M bindt uniciteit aan een eID-verificatie met een attest waarover betaald kan worden. Dat verschil moet je kunnen uitleggen zonder World ID af te branden, want hun schaal is echt. 🔌 Integratievorm: API-sleutel op de backend van de machine-operator, met een attestatie-oproep per handeling. Opzetpad: (1) draait al — attestatie-uitgifte en dubbel boekhouden (reconciliatie vanavond groen op vijf invarianten); (2) Franky bouwt — een attestatie-oproep die per handeling "deze mens deed dit al" antwoordt in plaats van per sessie, geschat 4 tot 6 dagen; (3) de klant doet — één HTTP-oproep vóór hij het flesje uitgeeft; (4) standaard — DID + SD-JWT; (5) kleinste demo — een weggeefknop op een pagina die weigert bij de tweede poging van dezelfde geverifieerde mens. 🧩 Productmix: V + C + O (de operator-kant), trede identificatie met doorgroei naar de rail zodra er per handeling afgerekend wordt. Meter: M2 per handeling, M1 bij de eerste verificatie, M3 pas als de operator per uitgifte betaalt. Zo zet je dit in de markt: "één gratis flesje per mens" is de begrijpelijkste verkoopzin die we deze maand gevonden hebben. Elke lezer snapt hem in drie seconden, en hij komt niet van ons maar van peaq zelf.02-09⚙️ PROTOCOLWACHT x402 — geen versiesprong vannacht, wél een spec-correctie die zegt dat de vindbaarheidskaart van x402 tweeduizend items telt — Gemeten vannacht 02-09-2026 om 03:1x op
api.github.com/repos/x402-foundation/x402 (commits en tags). Versiestand: onveranderd. Spec blijft v2, hoogste tag pypi-x402@v2.21.0. Wat maX kent (x402 V2, opgenomen 22-08) klopt dus nog steeds — geen achterstand. Dat is een geldige uitkomst en geen leeg spoor. Drie nieuwe commits sinds onze meting van gisteravond (die stopte bij 1bc2ae8c van 31-08 17:34): bbcb974a 01-09 07:06 fix(core): throw when no scheme server is registered (#3051) — gedragswijziging in de kern, een stille misconfiguratie wordt nu een harde fout; 71dd6296 01-09 08:37 docs(ts/mcp) (#3089) — de MCP-koppeling van x402 kreeg een herschreven README met een tabel van ondersteunde PaymentRequired-vormen; 0344bdf5 01-09 12:13 een e2e-testfix, zonder betekenis voor ons. De vondst van deze ronde zit ietsje ouder en was nog niet gemeld: 240492ed van 31-08 13:50, "docs(specs): correct v2 §8 discovery fields to match the wire format" (#3067). §8 beschreef nog de v1-vorm terwijl de implementaties al lang op v2 zaten. Uit de commit-boodschap, letterlijk en verifieerbaar: alle zes referentie-facilitators sturen een ISO 8601-lastUpdated, alle drie SDK-clients verklaren dat veld een string, en — dit is het cijfer — "The live catalog matches across 2,000 sampled entries including all 12 v1-versioned items." Waarom dat cijfer telt. x402 heeft een levende catalogus waarin betaalde bronnen vindbaar zijn, en er zijn er minstens tweeduizend bemonsterd. Dat is de vindbaarheidskant van x402 — en het is exact hetzelfde probleem als bij x401 hierboven, maar dan opgelost: daar wéét een agent waar hij moet zijn. Zet die twee items naast elkaar en je hebt het verschil tussen een protocol met een register en een protocol zonder. 🔎 Wat maX hier zelf al over zegt: de radar meldde op 01-09 al de builder-code-attributie en het extensionResponses-zijkanaal. De §8-correctie en het catalogus-cijfer stonden er nog niet in. Zo zet je dit in de markt: gebruik het naast de x401-vondst, niet los. "Betalen heeft een register met tweeduizend items, bewijzen wie je bent heeft er geen" is één zin en twee bronnen.02-09🆔 IDENTIFICATIE-CASE — India maakt zijn identiteitswallet los van identiteit zelf en bouwt hem om tot een bewijzenplatform voor zes sectoren; uniciteit komt er in geen enkele zin in voor — Op 01-09-2026 maakte MOSIP (Modular Open Source Identity Platform, gevestigd bij IIIT Bangalore) bekend dat Inji verbreedt van digitale-identiteitswallet naar een onafhankelijk, open-source credentialing-platform. Bron: biometricupdate.com, 01-09-2026. De feiten, zoals gepubliceerd. CTO Ramesh Narayanan: "Inji 1.0 is being designed as a credentialing platform capable of supporting education, healthcare, transport, employment, trade and business credentials." Drie onderdelen: Inji Certify, Inji Verify, Inji Wallet. Verwachte oplevering Q4 2026, alpha is nu al beschikbaar. Inji wordt losgeknipt van MOSIP en gaat verder als zelfstandig publiek goed. Wat er niet in staat. Uniciteit en deduplicatie komen in de aankondiging niet voor. Dat is opmerkelijk juist omdat MOSIP's hele bestaansreden aan de uitgifte-kant deduplicatie is — dat blijft dus in het identiteitssysteem zitten, terwijl de wallet die eromheen gebouwd wordt sector-agnostisch bewijzen gaat rondsturen. De bewijzen reizen; de uniciteit reist niet mee. 🔎 Wat maX hier zelf al over zegt: niets. "MOSIP" en "Inji" komen nul keer voor in
public/ (grep 02-09-2026). Dat is een echt gat: MOSIP is de identiteitsstapel die buiten Europa het meest gekopieerd wordt, en ons dossier is bijna volledig EU-gericht. Eerlijke afbakening — dit is geen klant. Een open-source publiek goed bij een universiteit in Bangalore koopt geen SaaS van een Belgische eenmanszaak, en de itsme-koppeling die onze verificatie draagt bestaat daar niet. Wat dit wél is: een ontwerpspiegel en een woordenlijst. Als Inji Verify straks bewijzen controleert zonder uniciteitsveld, is dat hetzelfde gat als bij x401 en bij vLEI — drie keer dezelfde vorm, in drie verschillende werelden, in één nacht gevonden. 🔌 Integratievorm: geen verkoopintegratie. Wel technisch: Inji Certify is een uitgever-implementatie in open source, en wie een uniciteitsattest wil uitgeven kan daar lezen hoe zo'n uitgever eruitziet zonder er zelf een te ontwerpen. Opzetpad: (1) draait al — onze eigen ondertekening; (2) Franky bouwt — niets, dit is leeswerk van hooguit een halve dag; (3) klant — n.v.t.; (4) standaard — W3C VC en OpenID4VCI; (5) kleinste demo — n.v.t. 🧩 Productmix: niet van toepassing — dit is een referentie, geen mix. Zo hoort het genoteerd te worden in plaats van er een klantverhaal omheen te verzinnen. Zo zet je dit in de markt: niet rechtstreeks. Gebruik het als derde voorbeeld in het gesprek: "in Europa, in de agent-wereld en in de Indiase stapel is het steeds hetzelfde gat." Drie werelden overtuigt waar één anekdote dat niet doet.02-09🎯 PROSPECT — het bedrijf dat gisteren de tweede x401-implementatie live zette, noemt zichzelf de vertrouwenslaag voor "mensen, machines en agents" en heeft precies dat mens-stuk niet — Wie. Solidus Network — solidus.network. Eigen omschrijving: "An identity & wallet protocol for a decentralized economy — the trust & governance layer for humans, machines & agents." Stand: testnet, met een publieke explorer die blokken, transacties en DID-operaties toont. Gebouwd op W3C, DIF, OpenID Foundation, Solid en EUDI; ondersteunt BBS+ en SD-JWT VC. Waarom zij, en waarom deze week. Niet omdat ze in een lijstje passen, maar omdat ze gisteren — 01-09-2026, 04:32 UTC — zélf publiek opgeschreven hebben wat ze missen (issue proof/x401#41). Ze draaien een x401-Verifier, hun uitgevers zijn DID's, en daardoor kunnen ze een agent niet vertellen bij wie hij een aanvaardbaar bewijs haalt. Wij hebben hun demo vannacht opgehaald en bevestigd: het request-object bevat geen
trusted_authorities, en de enige claim die gevraagd wordt is given_name. Een vertrouwenslaag voor mensen die om een voornaam vraagt. Wie contacteren. Geen naamloos contactformulier als eerste zet: de issue-auteur is fatih-koc op GitHub en heeft het probleem zelf beschreven — dat is de inhoudelijke deur. Het bedrijf heeft daarnaast een "Get Early Access"-contactpagina op solidus.network/contact en een login op identity.solidus.network. Voorkeur: reageren in de issue-draad zelf of hem daar rechtstreeks aanspreken, want daar staat de vraag al open en daar is een antwoord welkom in plaats van ongevraagd. Openingszin, klaar om te gebruiken: "Je schrijft in proof/x401#41 dat een DID-gebaseerde Verifier een agent niet kan vertellen waar hij een aanvaardbaar bewijs haalt. Wij bouwen precies die uitgeverskant: een uniciteitsattest — één echt mens, één keer — ondertekend als SD-JWT VC en bedoeld om in trusted_authorities te staan. Ik heb je demo opgehaald en zag dat je given_name vraagt; zou een uniciteitsclaim ernaast jou verder helpen, of los je dat liever binnen DCQL op?" 🔌 Integratievorm: R4M als uitgever naast hun verifier — zij veranderen niets aan hun stapel behalve één vermelding. Opzetpad: (1) draait al — attestatie-ondertekening geverifieerd, twee echte attestaties uitgegeven; (2) Franky bouwt — vct-URL plus SD-JWT-profiel voor het uniciteitsattest, 3 tot 5 dagen (hetzelfde werk als bij de x401-vondst hierboven — één bouwstuk bedient beide); (3) de klant doet — één regel in zijn DCQL-query; (4) standaard — OpenID4VP 1.0 + SD-JWT VC; (5) kleinste demo zonder hun toestemming — ons eigen PROOF-REQUEST publiceren met een ingevulde trusted_authorities, als antwoord op zijn vraag. 🧩 Productmix: V + C, attestatiekant, trede identificatie, meter M1 bij verificatie en M2 per raadpleging. De rail doet nu niet mee; die schakelt pas bij als er over een attest afgerekend wordt (M3). ⚠️ Eerlijk over de lat. Dit is een testnet-bedrijf, geen betalende klant op korte termijn — omzet is hier niet het punt. Het punt is dat het de eerste externe partij is die R4M's exacte gat publiek beschrijft, en dat een antwoord van ons daar leesbaar is voor iedereen die dat issue later opent. Franky beslist of dit een prospect wordt — deze routine maakt er zelf geen aan.02-09⚡ NIEUW TOEPASSINGSGEBIED — "vindbaarheid van de uitgever": drie onafhankelijke bronnen zeggen deze nacht hetzelfde, namelijk dat niemand weet WAAR je een menselijk bewijs moet halen — Dit is geen vondst uit één bron maar het patroon dat uit drie vondsten van vannacht valt, en daarom staat het apart. De drie waarnemingen. (1) x401: een DID-gebaseerde Verifier kan het veld dat als "acquisition and discovery surface" dient niet invullen, dus een agent weet niet bij wie hij moet zijn — door de implementeerder zelf beschreven, 01-09. (2) GLEIF/vLEI: de organisatie-laag is uitgewerkt en de individuele laag wordt expliciet aan anderen gelaten — 01-09. (3) MOSIP Inji: een sector-agnostisch bewijzenplatform waarin uniciteit in geen enkele zin voorkomt — 01-09. Daarbovenop de tegenhanger: x402 heeft dat probleem wél opgelost en bemonstert een catalogus van 2.000 items. Het toepassingsgebied in één zin. Niet "wij verifiëren mensen" — dat verkopen er tien. Wél: wij zijn de vindbare uitgever van het menselijke bewijs, de naam die in het vertrouwensveld van iemand anders past. Het product is niet de verificatie, het product is opgenomen zijn in een lijst waar een machine naar kijkt. Waarom dit anders is dan wat er al staat. De catalogus kent al "de afnemer aansluiten is het product" (radar 29-08) — dat gaat over de kant van de klant. Dit gaat over de kant van de machine: niet een mens die kiest waar hij zich verifieert, maar een agent die programmatisch moet uitvinden welk bewijs telt. Dat is een ander koperspad en een andere meter. 🔌 Integratievorm: één bouwstuk bedient alle drie de vondsten — een
vct-URL plus SD-JWT-profiel voor het uniciteitsattest, plus een publiek PROOF-REQUEST-voorbeeld waarin trusted_authorities naar R4M wijst. Opzetpad: (1) draait al — ondertekening, eID-koppeling, dubbel boekhouden; (2) Franky bouwt — 3 tot 5 dagen, en het is hetzelfde werk als in de x401- en Solidus-items hierboven, dus het telt één keer en niet drie keer; (3) de klant doet — één regel; (4) standaard — OpenID4VP 1.0 + SD-JWT VC; (5) kleinste demo — een publieke URL die een geldig uniciteits-PROOF-REQUEST teruggeeft, zonder dat iemand daar toestemming voor hoeft te geven. 🧩 Productmix: V + C, attestatiekant, trede identificatie, meter M1 + M2, rail later. 🛑 Wat dit NIET is. Geen nieuwe case in de catalogus — deze routine maakt er geen aan. Dit is een voorstel aan Franky om er één van te máken, en de reden staat erbij: drie onafhankelijke bronnen op één nacht is geen toeval meer. Zo zet je dit in de markt: "x402 heeft een register van tweeduizend betaalbronnen; voor de vraag of er een mens achter zit bestaat geen enkel register" — één zin, twee gecontroleerde bronnen, en het verkoopt een plek in een lijst in plaats van een abstractie.02-09💶 FUNDING — vier deadlines herteld op de dag van vandaag: Base sluit over 7 dagen, Start it over 12, en Eurostars over 8 maar die is en blijft onhaalbaar alleen — Hercontrole vannacht 02-09-2026. De teldagen op het bord stonden nog op de stand van gisteren en zijn allemaal met één opgeschoven; dat is precies het soort stille veroudering waar een subsidiebord aan doodgaat. 🚨 Base Batches 004 — sluit wo 09-09-2026, nog 7 dagen, HARDE datum. $100.000 uit het Base Ecosystem Fund voor ongeveer tien teams, plus een programma van acht weken. Toelatingsgebied letterlijk: trading, payments, agents, financing. Aanvragen via
base.org/batches/apply. Dit is de enige regel op het bord die vandaag een push verdient, en hij krijgt er één. 🚨 Start it @KBC — sluit 14-09-2026, nog 12 dagen, HARDE datum. Equity-free, en solo-oprichter is hier uitdrukkelijk geen beletsel. Reken de verplichte tweedaagse bootcamp van 28-10 mee vóór je ja zegt. ⏳ Eurostars Call 11 — sluit 10-09-2026 om 14:00 CEST, nog 8 dagen, HARDE datum, en toch GEEN urgentievlag. Herbevestigd aan de bron vannacht: open sinds 09-07, indienen via myeurekaproject.org. De reden dat hij niet vlagt staat vast en verandert niet door de kalender: elk consortium moet minstens twee onafhankelijke organisaties uit minstens twee Eurostars-landen tellen, geleid door een innoverende kmo. Dat is in acht dagen niet te regelen. Doel blijft Call 12; het werk van nu is één partner vinden in een tweede land, niet een dossier schrijven. Een harde datum die je toch niet kán halen is geen urgentie maar ruis — daarom blijft deze bewust ongevlagd. Bron: eurekanetwork.org. 📅 imec.istart — opende gisteren 01-09. €100.000 converteerbaar, venster van één maand. Een programma dat opengaat vlagt nooit; dat is de regel sinds 31-08 en die geldt ook als het geld groot is. Wel de duidelijkste eerstvolgende actie ná Base. Wat er NIET gevlagd wordt en waarom. De EIC Accelerator (€2,5 miljoen subsidie plus 1 tot 10 miljoen kapitaal) blijft de grootste som op het bord en blijft ongevlagd: de korte aanvraag staat het hele jaar open en wordt maandelijks gebundeld. Die stond drie nachten op rij als URGENT terwijl er geen deadline is — dat is precies de fout die de hardheidstoets moet voorkomen. Zo gebruik je dit vandaag: één ding, en het duurt twee minuten — open base.org/batches/apply en kijk of er een veld over teamgrootte in staat. Dat is de goedkoopste onzekerheid op het hele bord, en over zeven dagen kan je hem niet meer wegnemen.02-09🧪 TEST — 383 van 385 groen, geen versiedrift, en de boekhouding sluit vannacht op alle vijf de invarianten — Gemeten vannacht 02-09-2026 om 03:0x, read-only in
/Volumes/8TB MM4/Rails4Mankind op tak main, met een schone working tree. TESTSUITE: 63 bestanden, 383 geslaagd, 2 overgeslagen, 0 rood (vitest run, 8,52 s). Herhaalbaar met npm test. Dat is exact dezelfde stand als gisteren, en dat klopt: de fix die er 386 van maakt ligt nog altijd op een tak en is niet gemerged. Wij mergen niets. VERSIE — twee bronnen, niet samengevouwen. REPO: VERSION = 0.36.7 · package.json = 0.36.7 · laatste git-tag = v0.36.7. LIVE: /api/public/status meldt v0.36.7, netwerk base-sepolia, stage pilot. Geen versiedrift. ENDPOINTS, letterlijk zoals het statusendpoint ze teruggeeft. app_live verified 02-09 01:06:48Z · attestations verified 02-09 01:06:48Z met realIssued: 2 · double_entry_ledger verified 02-09 01:06:48Z · itsme_eid verified 01-09 21:22:41Z in sandbox, tegen de discovery-URL van de Signicat-sandbox. Drie checks staan bewust op verified: null en dat is eerlijk gedocumenteerd in het endpoint zelf: settlement_adapter, email_login en het configured-deel van itsme meten alleen dát er een sleutel staat, niet dat hij aanvaard wordt. RECONCILIATIE: HTTP 200 en ok: true. Alle vijf de invarianten sluiten: globale conservatie (imbalanceUsd 0), per-transactie in balans, cache gelijk aan het afgeleide grootboek, auditclaim (fundedUsd 1,76 = heldUsd 1,76, uitbetaald 0, fees 0, verschil 0), en geen negatieve posities. Wat hier NIET bewezen is, en dat hoort erbij. Twee echte attestaties op één onderscheiden mens is een pilot, geen bewijs van schaal. Testnet is geen mainnet. De itsme-koppeling is sandbox: dat het OpenID-document bereikbaar is, bewijst niet dat een burger kan inloggen. Zeg dat er altijd bij.02-09🔍 AUDIT ◐ DEELS — het gat van gisteren is nu exact begrensd: één dagrapport is definitief weg en twee kernbestanden stonden twee nachten stil; vannacht is de lus hersteld — Nagemeten vannacht 02-09-2026 om 03:0x. Eerst een correctie op onze eigen melding van gisteravond, en die hoort bovenaan. De radar zei op 01-09 dat "de nacht geen enkel bestand naar de engine-repo schreef". Dat klopt voor de engine-repo, maar de zinsnede kon gelezen worden als "de nacht draaide niet". De VINDEN-fase van 01-09 dráaide wel — commits
d8d4c5f (03:26) en 7d2f085 (03:31) in r4m-max-v2 staan er gewoon. Wat ontbrak was uitsluitend de schrijfkant naar Rails4Mankind. Dat onderscheid is belangrijk genoeg om het recht te zetten in plaats van te laten staan. Het gat, nu exact geteld. (1) ops/daily/r4m-2026-09-01.md bestaat niet en komt er ook niet meer — het dagrapport van die nacht is definitief verloren; wat die nacht opleverde staat alleen nog op de radar en in het ochtendrapport. (2) docs/SIGNALS_ADAPT.md en docs/USE_CASE_LEDGER.md zijn allebei voor het laatst aangeraakt op 31-08 om 03:23 (commit c536215) — dat is twee nachten stil, niet één. (3) De avondfase van 01-09 schreef wél naar de engine-repo (af4e5c7, 23:14, BRONNEN.md), dus de repo zelf is niet stuk; alleen de nachtelijke schrijfkant viel uit. Wat vannacht anders is. Deze run schrijft alle drie de bestanden: dagrapport r4m-2026-09-02.md, een nieuwe SIGNALS_ADAPT-notitie en ledger-entry #22. De lus is daarmee hersteld en het gat is één nacht groot in plaats van open. Vonnis: ◐ deels. Niet ⚠ theater — er werd echt gewerkt en er kwamen echte vondsten uit. Wel deels: een nacht die geen spoor achterlaat in de bestanden die de volgende nacht leest, laat de vólgende nacht blind beginnen. Dat is precies wat hier gebeurde en het kostte ons de vergelijkingsbasis. Wat Franky hiermee kan. Niets bouwen. Wel weten dat de radar op 01-09 correct meldde dát er iets misging, en dat de precieze omvang nu vaststaat: één rapport weg, twee bestanden twee dagen oud, vanaf vannacht weer bij.02-09📋 STAND VAN DE SPOREN — elf items vannacht, en één spoor dat eerlijk leeg blijft — Telling van de nacht van 02-09-2026, zodat het narekenbaar is in plaats van aanneembaar. Wat er staat: 11 nieuwe items — 1 x401-protocolwacht (de kop), 1 agentic payments, 1 IoT, 1 x402-protocolwacht, 1 identificatie-case, 1 prospect, 1 nieuw toepassingsgebied, 1 funding, 1 test, 1 audit, plus deze telregel. Daarbovenop twee bijwerkingen van bestaande items in plaats van nieuwe: het Login.gov-item van 28-08 en het VK-item van 01-09 kregen een aanvulling met de datum erbij, omdat de dedup-regel zegt dat je hetzelfde onderwerp bijwerkt en geen tweede maakt. Wat leeg blijft, en waarom — niet opgevuld. Identificatie-case 2: er is er vannacht maar één gevonden die de lat haalt (MOSIP). De tweede kandidaat was het VK-drankverkoopstuk van 01-09, maar dat onderwerp stond al op de radar van gisteren; volgens de dedup-regel is dat een aanvulling en geen nieuwe case, en zo is het ook verwerkt. Liever één echte dan twee waarvan één een herhaling is. Wat er bewust NIET bij zit. Geld-case: geen enkele vondst van vannacht laat met de R4M-rail actief geld stromen — de drie hoofdvondsten (x401, vLEI, peaq) zitten allemaal op de attestatiekant, meter M1/M2, en geen ervan op M3. Dat als geld-case verkopen zou vals zijn. Secure Mail: dat spoor draait alleen op maandag; vandaag is woensdag. Eerlijk over de kwaliteitslat. Tien van de elf items dragen een echt bedrijf of een echte bron met datum en URL. De uitzondering is deze telregel zelf, en dat is de bedoeling. Eén item — MOSIP — draagt uitdrukkelijk geen productmix en geen verkooproute, omdat het een referentie is en geen klant; dat staat er zo bij in plaats van dat er een klantverhaal omheen verzonnen is.
01-09⚙️ PROTOCOLWACHT — x402 heeft sinds gisteravond een officieel zijkanaal waarlangs een facilitator iets aan de verkoper vertelt zónder dat de koper het ziet, en dat is exact de plek waar een uniciteitsoordeel hoort te landen — Gemeten vanavond 01-09-2026 om 23:1x op
api.github.com/repos/x402-foundation/x402/commits. Op 31-08-2026 17:34 ging commit 1bc2ae8c binnen (PR #3278, TypeScript), sluitend op de Python-tegenhanger e187dda1 (PR #3306) van 31-08 15:58. De commit-boodschap is letterlijk: de facilitator-client decodeert EXTENSION-RESPONSES naar VerifyResponse/SettleResponse.extensionResponses — server-internal — in plaats van ze samen te voegen met extensions, en encodePaymentResponseHeader stript ze weg zodat ze nooit via PAYMENT-RESPONSE naar de koper lekken. Sluit issue #3270. Waarom dit voor R4M harder telt dan een gewone fix: tot gisteren was elk antwoord van een facilitator ofwel zichtbaar voor de betalende agent, ofwel bestond het niet. Nu is er een gespecificeerd, afgeschermd kanaal facilitator → verkoper. Een attestatie-antwoord ("dit is één uniek, geverifieerd mens") is precies het soort feit dat de verkoper moet weten en de koper niet mag zien. De maX-bril: grep -ril "extensionResponses|sidechannel|zijkanaal" public/ gaf vanavond nul treffers — het dossier kent deze laag niet, en dit is dus nieuw en niet een herhaling van de builder-code-vondst van vannacht (die ging over attributie van de bóuwer, dit gaat over het antwoord aan de vérkoper). 🔌 Integratievorm: R4M als x402-extensie op de facilitator-kant. Opzetpad: (1) de rail en de attestatie draaien al, live gemeten v0.36.7; (2) Franky bouwt een extensie-handler die op een verify-oproep het uniciteitsoordeel in extensionResponses zet — geschat 3 à 5 dagen op de bestaande attestatie-endpoint; (3) de klant registreert de extensie in zijn resource-server-config, één regel; (4) standaard: x402 v2 extensie-mechanisme; (5) kleinste demo zonder toestemming van wie dan ook: een lokale resource-server op base-sepolia die een 402 teruggeeft en in extensionResponses een R4M-attest meestuurt dat in de PAYMENT-RESPONSE naar de koper aantoonbaar afwezig is. 🧩 Productmix: V (verificatie) levert het oordeel, C (attestatie-oproep) is wat de facilitator aanroept, de rail doet mee want dit zit in de betaalweg. Meter M2 per oproep, met M1 bij de eerste binding van de mens. Landt op de trede "rail meedoet". Groeipad: eerst alleen het attest in het zijkanaal, later settlement over datzelfde attest (M3). Zo zet je dit in de markt: dit is het antwoord op de bezwaarzin "waar zou R4M dan moeten inpluggen in x402?" — er is nu een genummerde PR die de plek benoemt. Openingszin richting een facilitator of resource-server-bouwer: "Sinds PR #3278 kan uw facilitator de verkoper iets vertellen dat de koper niet ziet. Wij vullen dat veld met het enige feit dat u nog mist: is dit één echt, uniek mens."01-09⚠️ AUDIT ⚠ THEATER — de audit-digest vinkt elke run een logboek af dat sinds 2 juli niet meer geschreven wordt: 61 dagen stil en 33 minor-versies achter — Vastgesteld vanavond 01-09-2026 23:1x. De routine draagt de opdracht "lees
ops/hourly/log.md als die er is". Het bestand is er, dus de stap slaagt elke keer. De inhoud is één regel: 2026-07-02 05:23 | site OK | engine up | sales 0 | rev $0 | baseline snapshot (v0.3.0, testnet base-sepolia, payTo dEaD). Vandaag draait de engine v0.36.7. Een stap die groen afvinkt op een momentopname van 61 dagen en 33 minor-versies geleden meet niets; ze bevestigt alleen zichzelf. Dit is geen nieuwe vondst maar een aangescherpte: op 30-08 stond in het vonnis van de wacht van 01:00 al "audit-digest leest een dood bestand". Twee dagen later is er niets aan veranderd, en de teller loopt door — dat is de nieuwe informatie. Twee wegen, Franky kiest: (a) iets laat ops/hourly/log.md weer schrijven, of (b) de opdracht verwijst niet langer naar dat bestand en de audit-digest leest alleen nog ops/audit-private/audits.json, dat wél leeft (72.974 bytes, laatst geschreven 31-08 19:12). Zolang geen van beide gebeurt blijft dit een groen vinkje zonder meting.01-09⏱️ AUDIT — het gat in de engine-repo dat vanochtend gemeld werd is 28 uur later nog steeds open, en daarmee is het dagrapport van 01-09 definitief niet geschreven — Gemeten vanavond 01-09-2026 om 23:0x in
/Volumes/8TB MM4/Rails4Mankind. De laatste commit is nog altijd a977e01 van 31-08 19:15 — de avondronde van gisteren. Er is geen enkele commit van 01-09, en ops/daily/ bevat wel r4m-2026-08-31.md maar geen r4m-2026-09-01.md. Vanochtend 08:10 stond dit al op de radar als ⏱ opletten; het is nu geen waarschuwing meer maar een vaststelling. Wat er concreet ontbreekt over de nacht van 01-09: het dagrapport, de bijwerking van docs/SIGNALS_ADAPT.md en de ledger-entry in docs/USE_CASE_LEDGER.md. Wat er niét ontbreekt: de elf radar-items van die nacht zitten veilig in r4m-max-v2 en staan live — de vondsten zijn niet weg, alleen het spoor in de engine-repo. Waarom dit telt: drie van de tien sporen (SIGNALS_ADAPT, de omzet-lopende-band, het dagrapport) schrijven uitsluitend naar díé repo. Een nacht zonder commit daar is een nacht waarvan die drie sporen geen bewijs hebben. Deze avondronde herstelt het gat niet met terugwerkende kracht — een rapport over een venster dat je niet hebt waargenomen is fictie, en dat is verboden — maar zij commit haar eigen werk wél in beide repo's, zodat de reeks vanaf vanavond weer doorloopt.01-09🔎 BRONNEN — tweede echte controleronde: 28 bronnen gemeten, 28 leven, nul dood, nul verhuisd; de EUDI-vervangers van gisteren houden stand — Ronde gedraaid vanavond 01-09-2026 om 23:1x, één opvraging per bron, alle statuscodes en byte-tellingen genoteerd in
docs/BRONNEN.md. Uitkomst: 28/28 op HTTP 200. Geen 404, geen 301/308, geen nieuwe doorverwijzing. Vergelijking met de eerste ronde van 31-08 (25 rijen, 1 dood, 2 omgeleid): de drie vervangers voor de doodgelopen EUDI-ruimte geven alle drie 200, en de ARF-tags-API bevestigt onveranderd v3.0.0 — geen versiedrift op EUDI. Wat wél opvalt en bevestigd is: mydividend.ai levert opnieuw slechts 2.274 bytes, tegen 150.000 à 400.000 voor de gezonde nieuwsbronnen. Dat bevestigt de ⚠-markering van gisteren: de pagina bouwt zichzelf in de browser op en geeft aan een routine alleen een titel. Een statuscode 200 is daar geen bewijs van inhoud — dezelfde valstrik als de EU-wiki die naar een loginpagina omleidt. De vervangende primaire bron staat nog steeds open. Oppervlakte-check binnen dezelfde ronde: r4m-core-v2-k7x9.pages.dev 229.155 bytes (+1.520 tegenover 31-08, dat is het ochtendrapport van vanochtend) · r4m-founder 98.018 bytes, ongewijzigd · r4m.franky-f29.workers.dev 5.845 bytes, ongewijzigd · /api/seo-watch 200 en levend. Zo zet je dit in de markt: niet extern — dit is de zelfcontrole die maakt dat een vondst van deze routine een gecontroleerde bron heeft en geen herinnering.01-09🧪 TEST — geen versiedrift vanavond: repo en live staan allebei op v0.36.7, en alle vier de verifieerbare checks zijn vers gemeten — Gemeten 01-09-2026 om 23:1x. REPO:
VERSION = 0.36.7 · package.json = 0.36.7 · laatste git-tag = v0.36.7. LIVE: /api/public/status meldt v0.36.7, netwerk base-sepolia, stage pilot. De drie repo-bronnen en de live-bron zeggen hetzelfde: geen drift. De checks, letterlijk zoals het endpoint ze teruggeeft: app_live verified op 21:09:31 · itsme_eid verified op 21:07:51 (sandbox) · attestations verified op 21:09:31 · double_entry_ledger verified op 21:09:31 · settlement_adapter configured maar verified: null · email_login configured maar verified: null. Die twee laatste zijn niet rood: het endpoint zegt er zelf bij dat "configured" betekent dat de sleutel er staat en dat pas een echte verzending respectievelijk een diepe ketencontrole het bewijst. Boekhouding: /api/public/reconciliation geeft 200 en ok: true, met i1_globalConservation op een imbalans van 0 USD, i2_perTransactionBalance zonder ongebalanceerde transacties en i3_cacheMatchesDerived zonder drift. Wat NIET getest is vanavond: de testsuite zelf is niet gedraaid — dat hoort bij fase VINDEN van 03:00, en deze avondronde raakt de engine-repo alleen lezend. Herhaalbaar commando: curl -s https://r4m-franky.fly.dev/api/public/status en curl -s https://r4m-franky.fly.dev/api/public/reconciliation.01-09📐 BESLISPUNT — de routine-opdracht schrijft nog het Google-favicon-formaat voor dat jij gisteren uit het dashboard hebt gehaald, en wie de opdracht letterlijk volgt zet Google er weer in — Vastgesteld vanavond 01-09-2026 bij het schrijven van deze items. Commit
09e5b74 — "Google uit het dashboard: lettertypes lokaal, favicon-dienst vervangen door letterbadges" — verving in marktradar.html elke <img class="mr-logo" src="https://www.google.com/s2/favicons?..."> door een lokale letterbadge <span class="mr-logo" title="domein">X</span>. Er gaat sindsdien geen enkel verzoek meer van jouw radar naar Google. Maar het vaste itemformaat in de routine-opdracht (~/.claude/scheduled-tasks/r4m/SKILL.md, tweemaal: in DE RADAR en in stap 4 van fase VINDEN) toont nog altijd de <img>-vorm mét google.com/s2/favicons. Deze ronde heeft het bestand gevolgd en niet de opdracht, dus deze zes items dragen letterbadges. Zonder die keuze had een routine die netjes doet wat er staat jouw privacy-opruiming van gisteren stilzwijgend teruggedraaid. Wat jij moet beslissen: het formaatvoorbeeld in SKILL.md bijwerken naar de letterbadge-vorm. Dat is een wijziging aan de routine-opdracht en die maakt de routine niet zelf — vandaar dat het hier staat en niet als een stille aanpassing. Zolang het er niet in staat, kan elke volgende run de <img>-vorm opnieuw introduceren.01-09☀️ OCHTENDRAPPORT dinsdag — drie keer hetzelfde gat op één nacht: het VK certificeert identiteit maar niet uniciteit, x402 attribueert de bouwer maar niet de ontvanger, X betaalt per abonnement maar niet per mens — Het rapport over het venster 31-08 08:30 → 01-09 08:30 staat live. Elf radar-items van fase VINDEN, alle zeven soorten vertegenwoordigd, samengevat in zes vondsten met contactroute. De kop van de dag is de protocolwacht:
builder-code kwam op 31-08 in de x402-spec en staat vandaag in het dossier — een achterstand van één dag, tegenover de twee maanden die x402 V2 nodig had. Twee sporen bleven eerlijk leeg (📡 IoT, 🎯 prospect) omdat er geen gedateerde bron was; de prospect-teller blijft dus op 56. Zo zet je dit in de markt: de drie vondsten van vannacht vertellen één verhaal dat je in één slide kwijt kan — iedereen bouwt de identiteitslaag af behalve de mens-kant, en dat is geen mening meer maar drie gedateerde bronnen van deze week. Volledig rapport →01-09⚠️ AUDIT ⏱ — de nacht leverde elf radar-items op maar schreef geen enkel bestand naar de engine-repo, dus drie sporen lieten geen spoor na — Vastgesteld bij het opmaken van het ochtendrapport op 01-09-2026 om 08:10. Fase VINDEN draaide vannacht om 03:26 en 03:31 en committeerde in
r4m-max-v2 — de vondsten zijn dus veilig. Maar in /Volumes/8TB MM4/Rails4Mankind staat geen enkele commit van 01-09; de laatste is a977e01 van 31-08 19:15. Concreet ontbreekt: het dagrapport ops/daily/r4m-2026-09-01.md, de bijwerking van docs/SIGNALS_ADAPT.md, en de nieuwe entry in docs/USE_CASE_LEDGER.md — de omzet-lopende-band staat dus nog op entry #21 van 31-08 en het volgende €100-moment is niet door het who-pays-filter gehaald. Zo zet je dit in de markt: niets, dit is intern — maar het is precies het soort stille uitval dat de ketencheck voor andere routines wél vangt en voor deze niet. Een routine die haar eigen rapport niet wegschrijft, kan niet melden dat ze het niet deed.01-09📊 SEO-vloot — de twee apex-fixes van gisteren zijn bevestigd in een verse meting, en channel-zero.be trekt aan zonder dat er techniek aan veranderde — 18 domeinen gemeten, sync 01-09-2026 03:51 (bron:
/api/seo-watch). Bevestigd: www.lowlands.business onsite 79 → 89 (+10), nul auto-fails · www.turbeau2rock.com onsite 79 → 84 (+5). Beide fixes dateren van gisteravond; dit is de eerste onafhankelijke meting erna. Nieuw vandaag: channel-zero.be gaat in Search Console van 24 naar 32 klikken en van 480 naar 782 impressies, positie 7,6 → 7,3 — terwijl onsite op 68 blijft staan met vier vaste auto-fails (canonical, schema, robots, sitemap). De winst komt daar dus niet van de techniek, wat betekent dat er nog 68 → 90 op tafel ligt bij een domein dat nú beweegt. idgs.eu cwv 76 → 80. Let op: drie domeinen melden cwv-mobiel-mislukt (turbeau2rock, qmtex, gevelsteenbedrijf-v6) — die cwv-cijfers ontbreken, ze zijn niet nul. Zo zet je dit in de markt: channel-zero is het bewijsstuk voor een verkoopgesprek — een site die stijgt in Search Console terwijl vier basisfouten nog openstaan, is een site waar de goedkoopste winst nog ongeraapt ligt.01-09🆔 Identificatie-case 1 — het VK zet vandaag een wettelijk keurmerk op digitale identiteitscontrole, en het woord "uniek" staat er niet in — Wat er gebeurd is. Op 1 september 2026 — vandaag trad het Digital Verification Services Trust Framework v1.0 in werking, beheerd door het Office for Digital Identities and Attributes (OfDIA) in Londen. Gecertificeerde aanbieders mogen vanaf vandaag voor het eerst het officiële keurmerk voeren. Bestaande certificeringen krijgen minstens vijftien maanden om naar v1.0 te upgraden, met een jaar extra mogelijk. En er hangt meteen een verplichting aan: wie digitale ID gebruikt voor leeftijdscontrole bij drankverkoop, moet voortaan een gecertificeerde DVS-aanbieder gebruiken. De sector telt ongeveer 275 bedrijven met een geschatte jaaromzet van £2,027 miljard, en de groei wordt "sluggish" genoemd — de rem is dat traditionele financiële instellingen hun identiteitscontrole niet willen uitbesteden aan gecertificeerde partijen. Bron: biometricupdate.com, 31-08-2026.
🔎 Wat maX hier zelf al over zegt: niets.
Waarom dit ons raakt. Het keurmerk certificeert twee dingen: is dit een echt persoon en is hij oud genoeg. Het certificeert nergens is dit dezelfde persoon als die andere account. Er staat vanaf vandaag een officiële, publieke lijst van partijen die het eerste mogen zeggen — en op diezelfde lijst staat niemand die het tweede mag zeggen.
🔌 Integratievorm — OIDC-knop plus attestatie-API. (1) Draait al: de itsme/eID-aansluiting en de attestatie-ondertekening — live gemeten vannacht 01-09 om 03:06:
🧩 Productmix: V (verify human) + D (denylist op de persoon-root). Alleen de attestatiekant — de rail doet hier niet mee. Landt op trede 2 (attestatie zonder geldstroom). Groeipad: starten als aanvullend attest bóvenop een gecertificeerde DVS-aanbieder, waarvoor je zelf geen certificering nodig hebt; eigen certificering pas als er volume is.
❓ Keuzevraag voor Franky — ik gok dit niet. Eigen OfDIA-certificering kost geld en doorlooptijd en bindt je aan het VK. Wil je die weg op, of blijf je bewust de laag ónder een gecertificeerde partij? Dat verschil bepaalt of dit een partnerverhaal of een concurrentieverhaal wordt.
Zo zet je dit in de markt: benader een gecertificeerde DVS-aanbieder als leverancier, niet als concurrent — hij heeft vanaf vandaag een keurmerk te verdedigen en een gat dat het keurmerk niet dekt. Openingszin: "Jullie keurmerk is sinds vandaag geldig voor echt en oud genoeg. Wat zegt het tegen een klant die vraagt of dezelfde persoon niet twee keer door de poort kwam?" 🔁 AANVULLING 02-09-2026 — hoe het keurmerk in de winkel landt. Op 01-09-2026 lichtte Tony Allen van het Age Check Certification Scheme toe wat er praktisch verandert bij drankverkoop in Engeland en Wales (biometricupdate.com, 01-09-2026). De regering wil de Mandatory Licensing Conditions aanpassen; de wijziging moet nog door het parlement. Digitale leeftijdsbewijzen mogen dan door klanten van elke leeftijd gebruikt worden, zelfscankassa's zijn toegestaan mits menselijk toezicht op de omgeving, en het model is privacy-bewarend: alleen een ja/nee over de leeftijd, zonder persoonsgegevens. De zin die ons raakt: er wordt biometrische authenticatie of een gelijkwaardige binding geëist om zeker te zijn dat het bewijs bij de persoon hoort die het toont. Dat is precies het bindingsprobleem waar R4M op zit — een bewijs is pas iets waard als het aan een mens vastzit — en het staat nu in een regelgevende eis in plaats van in onze verkoopkit. Wat er nog steeds niet staat: dat die mens één keer voorkomt. Binding aan de toner is niet hetzelfde als uniciteit over accounts heen. Dit is bewust een aanvulling en geen tweede item: het onderwerp VK-keurmerk stond hier al, en de dedup-regel zegt dan bijwerken.
🔎 Wat maX hier zelf al over zegt: niets.
OfDIA, DVS en Ofcom komen op de hele v2-site nul keer voor (grep 01-09-2026). Het VK heeft sinds vandaag een wettelijk kader voor digitale identiteitscontrole en ons dossier kent het niet — dat is de eerlijke kop, niet de ontdekking.Waarom dit ons raakt. Het keurmerk certificeert twee dingen: is dit een echt persoon en is hij oud genoeg. Het certificeert nergens is dit dezelfde persoon als die andere account. Er staat vanaf vandaag een officiële, publieke lijst van partijen die het eerste mogen zeggen — en op diezelfde lijst staat niemand die het tweede mag zeggen.
🔌 Integratievorm — OIDC-knop plus attestatie-API. (1) Draait al: de itsme/eID-aansluiting en de attestatie-ondertekening — live gemeten vannacht 01-09 om 03:06:
itsme_eid verified (sandbox), attestations verified, 2 echte attestaties uitgegeven. (2) Franky bouwt: een profielmapping van onze attestatie op het DVS-schema plus het certificeringsdossier — 5 à 8 dagen voor de mapping, het dossier is doorlooptijd bij OfDIA en geen bouwwerk. (3) De klant doet: niets extra — hij hangt onze attestatie achter zijn bestaande DVS-aanbieder in dezelfde OIDC-flow die hij al draait. (4) Standaard: OpenID Connect + DVS Trust Framework v1.0. (5) Kleinste demo zonder toestemming van wie dan ook: één publieke pagina die naast elkaar zet wat het keurmerk wél certificeert en wat het niet certificeert, met de v1.0-tekst als bron.🧩 Productmix: V (verify human) + D (denylist op de persoon-root). Alleen de attestatiekant — de rail doet hier niet mee. Landt op trede 2 (attestatie zonder geldstroom). Groeipad: starten als aanvullend attest bóvenop een gecertificeerde DVS-aanbieder, waarvoor je zelf geen certificering nodig hebt; eigen certificering pas als er volume is.
❓ Keuzevraag voor Franky — ik gok dit niet. Eigen OfDIA-certificering kost geld en doorlooptijd en bindt je aan het VK. Wil je die weg op, of blijf je bewust de laag ónder een gecertificeerde partij? Dat verschil bepaalt of dit een partnerverhaal of een concurrentieverhaal wordt.
Zo zet je dit in de markt: benader een gecertificeerde DVS-aanbieder als leverancier, niet als concurrent — hij heeft vanaf vandaag een keurmerk te verdedigen en een gat dat het keurmerk niet dekt. Openingszin: "Jullie keurmerk is sinds vandaag geldig voor echt en oud genoeg. Wat zegt het tegen een klant die vraagt of dezelfde persoon niet twee keer door de poort kwam?" 🔁 AANVULLING 02-09-2026 — hoe het keurmerk in de winkel landt. Op 01-09-2026 lichtte Tony Allen van het Age Check Certification Scheme toe wat er praktisch verandert bij drankverkoop in Engeland en Wales (biometricupdate.com, 01-09-2026). De regering wil de Mandatory Licensing Conditions aanpassen; de wijziging moet nog door het parlement. Digitale leeftijdsbewijzen mogen dan door klanten van elke leeftijd gebruikt worden, zelfscankassa's zijn toegestaan mits menselijk toezicht op de omgeving, en het model is privacy-bewarend: alleen een ja/nee over de leeftijd, zonder persoonsgegevens. De zin die ons raakt: er wordt biometrische authenticatie of een gelijkwaardige binding geëist om zeker te zijn dat het bewijs bij de persoon hoort die het toont. Dat is precies het bindingsprobleem waar R4M op zit — een bewijs is pas iets waard als het aan een mens vastzit — en het staat nu in een regelgevende eis in plaats van in onze verkoopkit. Wat er nog steeds niet staat: dat die mens één keer voorkomt. Binding aan de toner is niet hetzelfde als uniciteit over accounts heen. Dit is bewust een aanvulling en geen tweede item: het onderwerp VK-keurmerk stond hier al, en de dedup-regel zegt dan bijwerken.
01-09🆔 Identificatie-case 2 — Roblox ruilt gezichtsschatting in voor een staats-ID, en zet daarmee zelf de trap die onze verkoopkit beschrijft — Wat er gebeurd is. De Filipijnen tekenden een akkoord met Roblox (San Mateo, VS) waarbij het platform het Philippine Identification System (PhilSys) opneemt in zijn leeftijdscontrole in dat land. In hetzelfde gesprek gaf Meta toe op proactieve verwijdering van schadelijke AI-deepfakes, gegevensdeling rond kinderuitbuiting, een inschrijfmechanisme voor deepfake-bescherming, en deelname aan een takedown-werkgroep. Bron: biometricupdate.com, 31-08-2026. Let op: het artikel geeft géén gebruikersaantallen en géén invoerdatum. Die cijfers bestaan dus niet en mogen nergens verzonnen worden.
🔎 Wat maX hier zelf al over zegt — en dat is veel. Roblox staat al in het dossier als prospect, met de juiste onderbouwing: wereldwijd verplichte leeftijdscontrole vóór chat sinds januari 2026, met gezichtsschatting van Persona, en de conclusie dat zij "de leeftijdscontrole áf hebben en dus precies tegen de vólgende vraag aanlopen".
Waarom een staatswortel het gat groter maakt in plaats van kleiner. Gezichtsschatting is zwak maar goedkoop; een nationale ID is sterk maar eenmalig. Geen van beide beantwoordt of dezelfde mens er al eerder in kwam. Sterker: wie een staats-ID vraagt, roept die vraag pas echt op — want nu is er een identiteit waarop je een tweede account kunt vergelijken, en er is geen mechanisme dat dat doet.
🔌 Integratievorm — API-sleutel op hun backend. (1) Draait al: onze attestatie-uitgifte en -raadpleging; de registratieflow van Roblox heeft al een identiteitsstap, dus er komt geen nieuw koppelvlak bij. (2) Franky bouwt: een raadpleeg-endpoint dat op een reeds gebonden mens antwoordt "deze wortel is hier al eens door de poort gegaan" zonder de identiteit prijs te geven — 3 à 5 dagen, bovenop wat er staat. (3) De klant doet: één extra aanroep op het moment dat hij PhilSys al aanroept, en één veld opslaan. (4) Standaard: OpenID Connect / OIDC-knop op de bestaande stap. (5) Kleinste demo: twee testaccounts met dezelfde wortel, waarvan de tweede geweigerd wordt — draait volledig op onze eigen sandbox, geen toestemming van Roblox nodig.
🧩 Productmix: V nu, groeipad naar D (ban op de persoon-root in plaats van op één account — precies wat een platform met een verwijderde minderjarige nodig heeft). Alleen de attestatiekant, geen geldstroom. Trede 2.
Zo zet je dit in de markt: een platform dat naar een staats-ID grijpt heeft de duurste stap al gezet en zit nog steeds zonder antwoord op de goedkoopste vraag. Roblox stond al op de prospectlijst zonder aanleiding — dit is de aanleiding. Openingszin: "Jullie hangen in de Filipijnen aan PhilSys. Wat gebeurt er als dezelfde persoon een tweede account opent met de PhilSys van een familielid — en hoe zou je dat vandaag merken?"
🔎 Wat maX hier zelf al over zegt — en dat is veel. Roblox staat al in het dossier als prospect, met de juiste onderbouwing: wereldwijd verplichte leeftijdscontrole vóór chat sinds januari 2026, met gezichtsschatting van Persona, en de conclusie dat zij "de leeftijdscontrole áf hebben en dus precies tegen de vólgende vraag aanlopen".
PhilSys komt nergens voor. Het nieuwe is dus niet dát Roblox aan leeftijd doet — het is dat hij van SCHATTEN naar een STAATSWORTEL stapt. Dat is exact de trap die onze eigen kit beschrijft, en Roblox zet hem nu zelf, in één land, uit eigen beweging.Waarom een staatswortel het gat groter maakt in plaats van kleiner. Gezichtsschatting is zwak maar goedkoop; een nationale ID is sterk maar eenmalig. Geen van beide beantwoordt of dezelfde mens er al eerder in kwam. Sterker: wie een staats-ID vraagt, roept die vraag pas echt op — want nu is er een identiteit waarop je een tweede account kunt vergelijken, en er is geen mechanisme dat dat doet.
🔌 Integratievorm — API-sleutel op hun backend. (1) Draait al: onze attestatie-uitgifte en -raadpleging; de registratieflow van Roblox heeft al een identiteitsstap, dus er komt geen nieuw koppelvlak bij. (2) Franky bouwt: een raadpleeg-endpoint dat op een reeds gebonden mens antwoordt "deze wortel is hier al eens door de poort gegaan" zonder de identiteit prijs te geven — 3 à 5 dagen, bovenop wat er staat. (3) De klant doet: één extra aanroep op het moment dat hij PhilSys al aanroept, en één veld opslaan. (4) Standaard: OpenID Connect / OIDC-knop op de bestaande stap. (5) Kleinste demo: twee testaccounts met dezelfde wortel, waarvan de tweede geweigerd wordt — draait volledig op onze eigen sandbox, geen toestemming van Roblox nodig.
🧩 Productmix: V nu, groeipad naar D (ban op de persoon-root in plaats van op één account — precies wat een platform met een verwijderde minderjarige nodig heeft). Alleen de attestatiekant, geen geldstroom. Trede 2.
Zo zet je dit in de markt: een platform dat naar een staats-ID grijpt heeft de duurste stap al gezet en zit nog steeds zonder antwoord op de goedkoopste vraag. Roblox stond al op de prospectlijst zonder aanleiding — dit is de aanleiding. Openingszin: "Jullie hangen in de Filipijnen aan PhilSys. Wat gebeurt er als dezelfde persoon een tweede account opent met de PhilSys van een familielid — en hoe zou je dat vandaag merken?"
01-09💶 Geld-case — X begint over zeven dagen een half miljoen makers uit te betalen per "unieke impressie", en telt daarbij abonnementen, geen mensen — De data, hard. X (San Francisco) stopt Creator Revenue Sharing op 7 september 2026; wie erin zit krijgt nog uitbetalingen op 14 en 28 augustus en een slotbetaling rond 11 september. Op 8 september 2026 start Original Content Rewards; bestaande leden kunnen zich vanaf die dag inschrijven en krijgen hun eerste betaling op 25 september 2026. Bronnen: help.x.com (aankondiging @XCreators) · americanbazaaronline.com, 08-08-2026 · techgenyz.com (~500.000 makers).
De rekeneenheid is het hele verhaal. Betaald wordt per "qualified impression": een unieke impressie van een Premium-abonnee die de post op de Home Timeline voor minstens 50% in beeld had. Het woord waar de hele geldstroom aan hangt is dus "uniek" — en de enige eenheid die X kan tellen is een betalend account. Eén mens met drie Premium-abonnementen telt drie keer. Drie mensen die één abonnement delen tellen één keer. X koopt uniciteit met een abonnement, en dat is precies de zin die in onze eigen catalogus staat over wat een abonnement níét bewijst.
En aan de ontvangende kant staat hetzelfde gat. Een half miljoen mensen krijgen straks geld zonder dat ergens vastligt dat het een half miljoen mensen zíjn. Ter grootte-orde: HypeAuditor mat dit jaar over 8,7 miljoen profielen 41,3% frauduleuze accountactiviteit, met AI-botnetwerken achter 58% van de gedetecteerde gevallen (bron: HypeAuditor-audit 2026, via didit.me). Dat cijfer gaat over de creator-markt breed, niet over X specifiek — dat staat er eerlijk bij.
💰 Geldvorm en meter. M1 op de maker bij inschrijving in het programma (nieuwe mens via eID/itsme, draagt de itsme-kost) en M2 voor elke volgende raadpleging op die gebonden mens. M3 pas als er euro over een attest gaat. De M1/M2-kant kan NU; de M3-kant is NA PRIO B — bouwregel
🔌 Integratievorm — API-sleutel op hun backend, op het inschrijfmoment. (1) Draait al: attestatie-uitgifte, raadpleging en het dubbel grootboek (alle drie
🧩 Productmix: V + P (PayLink face: betaal déze mens) + O (obligation + bon). Nu alleen de attestatiekant, trede 2; de rail schakelt pas bij na PRIO B, trede 3. Groeipad: begin met de poort op de inschrijving, en pas als de juridische poort open is de uitbetaling zelf over de rail.
Zo zet je dit in de markt: dit is geen pitch aan X — dat is een reus met eigen bouwers. Het is de beste publieke illustratie van het gat die je dit jaar krijgt, met een datum over zeven dagen erop. Gebruik hem tegen elk platform dat makers uitbetaalt en kleiner is dan X. Openingszin: "X gaat vanaf 8 september betalen per unieke impressie van een betalend account. Als jullie hetzelfde doen: wat kost het jullie als één mens drie van die accounts heeft?"
De rekeneenheid is het hele verhaal. Betaald wordt per "qualified impression": een unieke impressie van een Premium-abonnee die de post op de Home Timeline voor minstens 50% in beeld had. Het woord waar de hele geldstroom aan hangt is dus "uniek" — en de enige eenheid die X kan tellen is een betalend account. Eén mens met drie Premium-abonnementen telt drie keer. Drie mensen die één abonnement delen tellen één keer. X koopt uniciteit met een abonnement, en dat is precies de zin die in onze eigen catalogus staat over wat een abonnement níét bewijst.
En aan de ontvangende kant staat hetzelfde gat. Een half miljoen mensen krijgen straks geld zonder dat ergens vastligt dat het een half miljoen mensen zíjn. Ter grootte-orde: HypeAuditor mat dit jaar over 8,7 miljoen profielen 41,3% frauduleuze accountactiviteit, met AI-botnetwerken achter 58% van de gedetecteerde gevallen (bron: HypeAuditor-audit 2026, via didit.me). Dat cijfer gaat over de creator-markt breed, niet over X specifiek — dat staat er eerlijk bij.
💰 Geldvorm en meter. M1 op de maker bij inschrijving in het programma (nieuwe mens via eID/itsme, draagt de itsme-kost) en M2 voor elke volgende raadpleging op die gebonden mens. M3 pas als er euro over een attest gaat. De M1/M2-kant kan NU; de M3-kant is NA PRIO B — bouwregel
f4 houdt echt geld achter de juridische poort, en een uitbetaalprogramma is trede 3.🔌 Integratievorm — API-sleutel op hun backend, op het inschrijfmoment. (1) Draait al: attestatie-uitgifte, raadpleging en het dubbel grootboek (alle drie
verified gemeten 01-09 03:06). (2) Franky bouwt: een "één maker = één mens"-poort op de inschrijving, met een raadpleging die geen identiteit teruggeeft — 4 à 6 dagen. (3) De klant doet: één aanroep bij inschrijving in het beloningsprogramma en één veld bewaren; aan de uitbetaalkant verandert er niets zolang wij alleen attesteren. (4) Standaard: OIDC voor de binding, attestatie-API voor de raadpleging. (5) Kleinste demo: een simulatie van tien makers waarvan er drie dezelfde wortel delen, met de uitbetalingslijst vóór en ná — geen toestemming van X nodig.🧩 Productmix: V + P (PayLink face: betaal déze mens) + O (obligation + bon). Nu alleen de attestatiekant, trede 2; de rail schakelt pas bij na PRIO B, trede 3. Groeipad: begin met de poort op de inschrijving, en pas als de juridische poort open is de uitbetaling zelf over de rail.
Zo zet je dit in de markt: dit is geen pitch aan X — dat is een reus met eigen bouwers. Het is de beste publieke illustratie van het gat die je dit jaar krijgt, met een datum over zeven dagen erop. Gebruik hem tegen elk platform dat makers uitbetaalt en kleiner is dan X. Openingszin: "X gaat vanaf 8 september betalen per unieke impressie van een betalend account. Als jullie hetzelfde doen: wat kost het jullie als één mens drie van die accounts heeft?"
01-09💸 Protocolwacht x402 — de spec kreeg gisteren een laag die bijhoudt wíé een betaling bouwde, en dat woord staat nergens in ons dossier — Gecontroleerd bij de bron, niet in het nieuws. github.com/x402-foundation/x402, opgehaald 01-09-2026 om 03:05. Commits van 31-08-2026:
🔎 De bril eerst. maX kent x402 V2 (elf vermeldingen in
Wat een builder-code is, in gewone taal. Er zit nu een veld (
🤝 x401, in dezelfde beweging gecontroleerd: github.com/proof/x401 staat ongewijzigd. Laatste commit
🔌 Integratievorm — x402-resource. (1) Draait al: de x402-kant van de engine. (2) Franky bouwt: de attestatie-hash naast het builder-code-veld leggen in één demo-resource — 2 à 3 dagen. (3) De klant doet: niets; het is een header op een verzoek dat hij toch al doet. (4) Standaard: x402 v2. (5) Kleinste demo: een 402-antwoord dat naast de builder-code óók een mens-attest eist, met de twee velden zichtbaar naast elkaar in de respons — dat is de hele slide.
🧩 Productmix: V + O. De rail doet mee (dit is de betaalweg zelf), trede 5 — een machine handelt namens een mens. Groeipad: eerst het attest náást de builder-code als demo, later als voorwaarde.
Zo zet je dit in de markt: de standaard heeft gisteren zelf besloten dat het uitmaakt wie een betaling bouwde. Dat is de opening om te vragen waarom het niet uitmaakt wie hem is. Openingszin, richting elke x402-bouwer: "Jullie payload draagt sinds gisteren een veld voor wie de app bouwde. Waar staat het veld voor wie de mens is?"
validate builder-code app attribution on (#3313) · Document builder-code `a` field validation and v1 behavior (#3315) · docs(specs): correct v2 §8 discovery fields to match the wire format (#3067). Eerder deze week, 27-08: feat(ts/go): auth-capture client v1.1 (#3283). Nieuwste tag: pypi-x402@v2.21.0.🔎 De bril eerst. maX kent x402 V2 (elf vermeldingen in
cases-db.json) en kent auth-capture en upto al. builder-code komt op de hele public/-map nul keer voor (grep 01-09-2026). De achterstand is dus één dag, niet twee maanden — en dat is precies waarvoor deze wacht na het V2-gat van 24-06 is opgezet. Geen ramp, wel een gat dat vandaag gedicht hoort.Wat een builder-code is, in gewone taal. Er zit nu een veld (
a) in de betaling dat bijhoudt wélke applicatie hem gebouwd heeft, zodat opbrengst aan een bouwer toegewezen kan worden — attributie, en dus geld dat de goede kant op vloeit. x402 leert dus attribueren aan een APP. Wat het protocol nog altijd niet draagt, is attributie aan een MENS. Dat is letterlijk het veld dat wij vullen, en het staat nu naast het onze in dezelfde payload.🤝 x401, in dezelfde beweging gecontroleerd: github.com/proof/x401 staat ongewijzigd. Laatste commit
docs: align README header names with current x401 spec (#33) van 1 juli 2026, geen enkele tag. Twee maanden stil. Dat is dezelfde stand als op 29-08 en 30-08 en dus géén nieuwe entry — alleen deze regel, zoals de wacht voorschrijft.🔌 Integratievorm — x402-resource. (1) Draait al: de x402-kant van de engine. (2) Franky bouwt: de attestatie-hash naast het builder-code-veld leggen in één demo-resource — 2 à 3 dagen. (3) De klant doet: niets; het is een header op een verzoek dat hij toch al doet. (4) Standaard: x402 v2. (5) Kleinste demo: een 402-antwoord dat naast de builder-code óók een mens-attest eist, met de twee velden zichtbaar naast elkaar in de respons — dat is de hele slide.
🧩 Productmix: V + O. De rail doet mee (dit is de betaalweg zelf), trede 5 — een machine handelt namens een mens. Groeipad: eerst het attest náást de builder-code als demo, later als voorwaarde.
Zo zet je dit in de markt: de standaard heeft gisteren zelf besloten dat het uitmaakt wie een betaling bouwde. Dat is de opening om te vragen waarom het niet uitmaakt wie hem is. Openingszin, richting elke x402-bouwer: "Jullie payload draagt sinds gisteren een veld voor wie de app bouwde. Waar staat het veld voor wie de mens is?"
01-09🤖 Agentic-lijn — de handtekening waarmee half het web zijn bots binnenlaat, is nog altijd niemands standaard — Wat er is.
🔎 De bril. maX kent
Waarom dat meer is dan een voetnoot. Wat de handtekening bewijst is dat een verzoek van een bepaalde sleutel komt. Niet van welk bedrijf. Niet van welke mens. En de laag die dat bewijst is formeel van niemand: geen werkgroep betekent geen verplichting, en geen plek waar iemand "en wie is de mens erachter" kan indienen. Dat is tegelijk een gat en een deur — een individueel draft is nog vormbaar, een RFC niet meer.
🔌 Integratievorm — browser-extensie én well-known bestand. (1) Draait al: onze attestatie-ondertekening met een geladen sleutel (
🧩 Productmix: V + C (capability card — welke rechten gaf een organisatie aan die mens). Alleen de attestatiekant, geen geldstroom. Trede 5. Groeipad: eerst meelezen als attest, later als voorwaarde voor toegang tot betaalde resources.
⚠️ En de bouwregel die hier geldt:
Zo zet je dit in de markt: zolang dit draft van niemand is, is er nog een deur. Openingszin, richting elke partij die Web Bot Auth in productie draait: "Jullie handtekening bewijst welke sleutel dit verstuurde. Wie draagt de verantwoordelijkheid als die sleutel iets doet dat een mens moest tekenen?"
draft-meunier-webbotauth-httpsig-protocol-02 draagt de datum 18 augustus 2026 en is nog altijd een individueel IETF Internet-Draft — niet aangenomen door een werkgroep — terwijl poortwachters het al in productie draaien. Technisch is het een dunne laag bovenop RFC 9421 (HTTP Message Signatures): de bot houdt een Ed25519-sleutelpaar, publiceert de publieke sleutel op een well-known plek, en tekent zijn eigen headers. De ontvanger controleert de handtekening tegen die sleutel. Bron: datatracker.ietf.org · analyse nerdleveltech.com ("Shipped Before It's a Standard").🔎 De bril. maX kent
Web Bot Auth al — het staat in cases-db.json, gtm-data.js en op deze radar zelf. RFC 9421 en HTTP Message Signatures komen nergens voor (grep 01-09-2026). Het nieuwe feit is dus niet het bestaan maar de status: versie -02 van twee weken geleden, en nog steeds van niemand.Waarom dat meer is dan een voetnoot. Wat de handtekening bewijst is dat een verzoek van een bepaalde sleutel komt. Niet van welk bedrijf. Niet van welke mens. En de laag die dat bewijst is formeel van niemand: geen werkgroep betekent geen verplichting, en geen plek waar iemand "en wie is de mens erachter" kan indienen. Dat is tegelijk een gat en een deur — een individueel draft is nog vormbaar, een RFC niet meer.
🔌 Integratievorm — browser-extensie én well-known bestand. (1) Draait al: onze attestatie-ondertekening met een geladen sleutel (
attestations verified, gemeten 01-09 03:06). (2) Franky bouwt: een well-known document naast de bot-sleutel dat de menselijke opdrachtgever attesteert, in hetzelfde signatuurformaat — 3 à 4 dagen, want RFC 9421 vraagt geen nieuwe cryptografie van ons. (3) De klant doet: één extra veld in het bestand dat hij toch al publiceert. (4) Standaard: RFC 9421, aangevuld met het Web Bot Auth-draft. (5) Kleinste demo: twee getekende verzoeken van dezelfde bot, waarvan er één een mens-attest draagt en de andere niet, met de twee antwoorden ernaast.🧩 Productmix: V + C (capability card — welke rechten gaf een organisatie aan die mens). Alleen de attestatiekant, geen geldstroom. Trede 5. Groeipad: eerst meelezen als attest, later als voorwaarde voor toegang tot betaalde resources.
⚠️ En de bouwregel die hier geldt:
f1 — geen eigen identiteitsprotocol standaardiseren. Dit is dus expliciet géén oproep om een concurrerend draft te schrijven. Het is een oproep om binnen een bestaand, nog niet vastgeklonken draft het mens-veld voor te stellen.Zo zet je dit in de markt: zolang dit draft van niemand is, is er nog een deur. Openingszin, richting elke partij die Web Bot Auth in productie draait: "Jullie handtekening bewijst welke sleutel dit verstuurde. Wie draagt de verantwoordelijkheid als die sleutel iets doet dat een mens moest tekenen?"
01-09🧪 TEST — main staat nog altijd op 383 van 385, want de fix die er 386 van maakt ligt al een dag op een tak — Gemeten 01-09-2026 om 03:06 op
En hier moet ik preciezer zijn dan de kop van gisteren was. De radar meldde op 31-08 "386 groen en voor het eerst NUL overgeslagen". Dat getal was echt, maar het is gemeten op de voorstel-tak, niet op
De twee overgeslagen tests zijn met naam bekend. In
Wat die twee tests bewaken. De kaartbodem is de regel die verhindert dat R4M op elke kaartbetaling van €2 verlies boekt (±€0,28 kosten tegen €0,16 marge).
De fix ligt klaar.
De les die breder is dan deze twee tests, en die ook op de kop van gisteren slaat. Het testgetal van deze suite is niet reproduceerbaar tussen machines: twee testparen gaan aan of uit naargelang er een sleutel in de omgeving staat. Een getal dat per machine verschilt is geen bewijs — het is een momentopname van een omgeving. Elk rapport dat "X groen" zegt zonder de omgeving erbij, zegt minder dan het lijkt.
Herhaalbaar commando:
Versie: repo
main (commit a977e01, schone working tree): 383 groen · 2 overgeslagen · 385 totaal · 63 testbestanden · 7,28 s. Dat is exact dezelfde stand als het testboek gisteren om 03:10 noteerde — er is dus niets veranderd op main, in geen van beide richtingen.En hier moet ik preciezer zijn dan de kop van gisteren was. De radar meldde op 31-08 "386 groen en voor het eerst NUL overgeslagen". Dat getal was echt, maar het is gemeten op de voorstel-tak, niet op
main — de entry zelf schrijft de basislijn er eerlijk bij ("basislijn vanmorgen: 383 geslaagd + 2 overgeslagen"), en het testboek registreerde diezelfde dag de main-stand van 383/385. Er is dus geen terugval. Er is een fix die bestaat en niet gemerged is, en een kop die zonder die context leest als een resultaat dat live staat. Dat verschil is de vondst.De twee overgeslagen tests zijn met naam bekend. In
test/kaartbodem.test.ts staan "een bericht onder de bodem wordt geweigerd, met de ketenweg als alternatief" en "op of boven de bodem gaat de betaling gewoon door" op it.skipIf(zonderSleutel). Zonder Stripe-sleutel in de omgeving draaien ze niet — en de suite meldt dan alsnog groen. Nagegaan met een gerichte run: npx vitest run test/kaartbodem.test.ts test/stripe-connect.test.ts --reporter=verbose toont letterlijk twee ↓-regels.Wat die twee tests bewaken. De kaartbodem is de regel die verhindert dat R4M op elke kaartbetaling van €2 verlies boekt (±€0,28 kosten tegen €0,16 marge).
test/setup.ts pint de Stripe-sleutel hermetisch op leeg — bewust, zodat geen enkele test ooit de echte Stripe-API raakt. Daardoor is de skip-voorwaarde altijd waar en is de handhaving van de bodem sinds 28-08 op main nooit uitgevoerd. Wat er wél draait is de rekensom dat de constante boven het break-evenpunt ligt — dat bewijst dat een getal groot genoeg is, niet dat er iemand naar luistert.De fix ligt klaar.
voorstel/2026-08-31-kaartbodem-test-draait-echt maakt er 386 van, met een mutatietest die aantoont dat de test niet leeg draait. Die tak is nog niet gemerged, dus vannacht bewaakte niemand de bodem — voor de vierde nacht op rij.De les die breder is dan deze twee tests, en die ook op de kop van gisteren slaat. Het testgetal van deze suite is niet reproduceerbaar tussen machines: twee testparen gaan aan of uit naargelang er een sleutel in de omgeving staat. Een getal dat per machine verschilt is geen bewijs — het is een momentopname van een omgeving. Elk rapport dat "X groen" zegt zonder de omgeving erbij, zegt minder dan het lijkt.
Herhaalbaar commando:
cd "/Volumes/8TB MM4/Rails4Mankind" && npm testVersie: repo
0.36.7 (VERSION, package.json én laatste tag v0.36.7) tegenover live v0.36.7 op r4m-franky.fly.dev — geen versiedrift. Endpoints, letterlijk uit /api/public/status: app_live verified · itsme_eid verified (sandbox) · attestations verified, realIssued: 2 · double_entry_ledger verified · settlement_adapter en email_login configured met verified: null. /api/public/reconciliation antwoordt 200. Netwerk base-sepolia, stage pilot.01-09🔍 AUDIT ⏱ — er staan negen voorstellen op een tak te wachten, de oudste sinds 28 augustus, en de theater-vlag van eergisteren zit erbij — Geteld op 01-09-2026.
Waarom dit een auditpunt is en geen boekhouding. Twee van die negen dragen een bevinding die op déze radar al als probleem staat. De dev-poort-omzeiling kreeg op 31-08 de vlag ⚠ theater met de woorden "te omzeilen met één percentteken, en de fix ligt al twee dagen ongemerged" — vandaag ligt hij vier dagen. En de kaartbodem-tak is de reden dat
Het mechanisme werkt; de knop erachter niet. Er wordt elke dag netjes één voorstel geleverd op een tak, met tests, zonder de live code te raken — dat is exact zoals het hoort. Maar een voorstel dat nooit beoordeeld wordt, is geen voorstel; het is een stapel. Aan één per dag staat de teller over een week op zestien.
🛑 Dit is een blocker die alleen Franky kan opheffen. Elke tak wacht op een expliciete goedkeuring — de routine mag niet mergen en zal dat ook nooit doen. Wat het snelst helpt is niet alle negen beoordelen, maar de twee die een bekend gat dichten:
Vonnis: ⏱ opletten. Niets is stuk, niets is theater aan onze kant — maar de doorlooptijd van bevinding naar fix wordt elke dag één dag langer, en dat is meetbaar.
/Volumes/8TB MM4/Rails4Mankind draagt vandaag negen ongemergde voorstel/-takken: hash-bewijs-widget, hermetische-testomgeving en uitrolpoort-pint-node (28-08) · dev-console-poort, hosted-login-lek en werker-poort-refer-submit (29-08) · staatsdeel-eerlijk en voorstellen-telling (30-08) · kaartbodem-test-draait-echt (31-08). Alle negen zijn gepusht, geen enkele is gemerged.Waarom dit een auditpunt is en geen boekhouding. Twee van die negen dragen een bevinding die op déze radar al als probleem staat. De dev-poort-omzeiling kreeg op 31-08 de vlag ⚠ theater met de woorden "te omzeilen met één percentteken, en de fix ligt al twee dagen ongemerged" — vandaag ligt hij vier dagen. En de kaartbodem-tak is de reden dat
main hierboven nog altijd op 383 van 385 staat terwijl de fix naar 386 al klaarligt.Het mechanisme werkt; de knop erachter niet. Er wordt elke dag netjes één voorstel geleverd op een tak, met tests, zonder de live code te raken — dat is exact zoals het hoort. Maar een voorstel dat nooit beoordeeld wordt, is geen voorstel; het is een stapel. Aan één per dag staat de teller over een week op zestien.
🛑 Dit is een blocker die alleen Franky kan opheffen. Elke tak wacht op een expliciete goedkeuring — de routine mag niet mergen en zal dat ook nooit doen. Wat het snelst helpt is niet alle negen beoordelen, maar de twee die een bekend gat dichten:
voorstel/2026-08-29-dev-console-poort en voorstel/2026-08-31-kaartbodem-test-draait-echt.Vonnis: ⏱ opletten. Niets is stuk, niets is theater aan onze kant — maar de doorlooptijd van bevinding naar fix wordt elke dag één dag langer, en dat is meetbaar.
01-09💶 FUNDING — Base Batches sluit over acht dagen, en de toelatingsvoorwaarden staan nu wél publiek: teamgrootte komt er niet in voor — Het openstaande gat van gisteren is deels gedicht. Op 31-08 stond op het bord dat "of een solo-oprichter toegelaten is nergens publiek staat, en dat precies de vraag is die je aanvraag maakt of breekt". De gepubliceerde criteria zijn nu wel te vinden: early-stage (van pre-product met sterke founder-market fit tot post-MVP) · pre-seed (angel-investering mag, een formele seed-ronde niet) · Base-first (meerdere ketens mogen, Base moet de primaire zijn) · gericht op de onchain-economie, met trading, payments, agents en financing als de genoemde domeinen.
Wat er níét in staat: teamgrootte of een co-oprichtersvereiste komt in die opsomming niet voor. Dat is geen toelating zwart op wit, maar het is ook geen uitsluiting — en dat is precies het verschil met gisteren, toen er helemaal niets publiek was.
Bedrag en klok. $100.000 uit het Base Ecosystem Fund voor ongeveer tien teams, plus een programma van acht weken. Sluit 9 september 2026 — nog acht dagen. Hardheid: HARD — mis je die dag, dan is deze cohort weg. Bron: blog.base.org (het origineel gaf 403 bij directe ophaling; criteria bevestigd via cryptobriefing.com en kucoin.com, gecontroleerd 01-09-2026).
Bewust géén nieuwe alarmbel. Over exact deze deadline ging op 30-08 al een urgentie de deur uit. De regel zegt: een urgentie die geen nieuw feit draagt, zakt naar een gewone regel. Het nieuwe feit hier is de criterialijst, niet de klok — dus staat hij hier, zonder 🚨.
Wat er vandaag te doen valt, in twee minuten. "Agents" en "payments" staan letterlijk in het doelgebied; dat is deze rail. Het aanvraagformulier is de enige plek waar een veld over teamgrootte kan opduiken — open het en je weet het meteen. Dat is de goedkoopste onzekerheid op dit hele bord.
Wat er níét in staat: teamgrootte of een co-oprichtersvereiste komt in die opsomming niet voor. Dat is geen toelating zwart op wit, maar het is ook geen uitsluiting — en dat is precies het verschil met gisteren, toen er helemaal niets publiek was.
Bedrag en klok. $100.000 uit het Base Ecosystem Fund voor ongeveer tien teams, plus een programma van acht weken. Sluit 9 september 2026 — nog acht dagen. Hardheid: HARD — mis je die dag, dan is deze cohort weg. Bron: blog.base.org (het origineel gaf 403 bij directe ophaling; criteria bevestigd via cryptobriefing.com en kucoin.com, gecontroleerd 01-09-2026).
Bewust géén nieuwe alarmbel. Over exact deze deadline ging op 30-08 al een urgentie de deur uit. De regel zegt: een urgentie die geen nieuw feit draagt, zakt naar een gewone regel. Het nieuwe feit hier is de criterialijst, niet de klok — dus staat hij hier, zonder 🚨.
Wat er vandaag te doen valt, in twee minuten. "Agents" en "payments" staan letterlijk in het doelgebied; dat is deze rail. Het aanvraagformulier is de enige plek waar een veld over teamgrootte kan opduiken — open het en je weet het meteen. Dat is de goedkoopste onzekerheid op dit hele bord.
01-09💶 FUNDING — vier regels nagekeken, één datum kon ik niet publiek herbevestigen en één stond nog nooit gecontroleerd — Start it @KBC (Start it X, België): sluit 14-09-2026 — nog 13 dagen (het bord zei gisteren 14; de klok tikt gewoon door). Harde datum, equity-free, solo-oprichter geen beletsel, verplichte tweedaagse bootcamp vanaf 28-10. Verder ongewijzigd sinds de controle van 27-08.
imec.istart (Leuven) — hier moet ik eerlijk zijn. De radar van 31-08 zei dat dit loket "morgen", dus vandaag, opengaat. Dat heb ik niet publiek kunnen bevestigen. imecistart.com bevestigt wel het bedrag — €100.000 via een converteerbare lening — maar publiceert geen deadline en geen open oproep; de aanvraagpagina gaf vannacht een HTTP 500. De regel houdt dus zijn eerder gecontroleerde sluitdatum van 30-09-2026, met de aantekening dat die vandaag niet aan de bron herbevestigd kon worden. Dat is geen tegenspraak van gisteren — het is een openstaande controle.
EIC Accelerator: onveranderd de grootste som op dit bord (tot €2,5 miljoen subsidie plus mogelijk 1 tot 10 miljoen kapitaal) en onveranderd ZACHT: stap 1 staat permanent open en wordt maandelijks gebundeld. Geen vlag, en dat blijft zo — dat is precies de correctie die op 31-08 is doorgevoerd nadat deze regel drie nachten op rij ten onrechte als urgent gemeld werd.
Base Batches 004: zie de regel hierboven — acht dagen, hard, met nieuwe criteria.
Eurostars Call 11 — nagekeken omdat hij als enige nog nooit gecontroleerd was. Deze regel stond op het bord met een harde datum binnen tien dagen en een leeg controleveld. Aan de bron nagelezen: open sinds 9 juli, sluit 10 september om 14:00 CEST via myeurekaproject.org. De bestaande beoordeling klopt en blijft staan: niet haalbaar solo — elk consortium wordt geleid door een innoverende kmo en telt minstens twee onafhankelijke organisaties uit minstens twee Eurostars-landen. Nieuw cijfer: ±500 aanvragen per oproep, ±100 gefinancierd (±20%). Daarom géén 🚨, ook al is de datum hard en binnen veertien dagen: een vlag op een oproep waar je onmogelijk aan kunt meedoen, is precies het valse alarm dat de regel van 31-08 wilde uitbannen. De enige zinvolle actie is een partner zoeken in een tweede Eurostars-land, met Call 12 als doel. Bron: eurekanetwork.org, gecontroleerd 01-09-2026.
Zo lees je dit bord: van de vijf nagekeken regels is er vandaag één die je agenda echt raakt (Base, acht dagen), één die over twee weken telt (Start it @KBC), één met een openstaande controle (imec.istart), één met een harde datum waar je niet aan kunt meedoen (Eurostars) en één die nooit haast heeft (EIC). Meer urgentie dan dat is er niet, en dat is een resultaat en geen tekort.
imec.istart (Leuven) — hier moet ik eerlijk zijn. De radar van 31-08 zei dat dit loket "morgen", dus vandaag, opengaat. Dat heb ik niet publiek kunnen bevestigen. imecistart.com bevestigt wel het bedrag — €100.000 via een converteerbare lening — maar publiceert geen deadline en geen open oproep; de aanvraagpagina gaf vannacht een HTTP 500. De regel houdt dus zijn eerder gecontroleerde sluitdatum van 30-09-2026, met de aantekening dat die vandaag niet aan de bron herbevestigd kon worden. Dat is geen tegenspraak van gisteren — het is een openstaande controle.
EIC Accelerator: onveranderd de grootste som op dit bord (tot €2,5 miljoen subsidie plus mogelijk 1 tot 10 miljoen kapitaal) en onveranderd ZACHT: stap 1 staat permanent open en wordt maandelijks gebundeld. Geen vlag, en dat blijft zo — dat is precies de correctie die op 31-08 is doorgevoerd nadat deze regel drie nachten op rij ten onrechte als urgent gemeld werd.
Base Batches 004: zie de regel hierboven — acht dagen, hard, met nieuwe criteria.
Eurostars Call 11 — nagekeken omdat hij als enige nog nooit gecontroleerd was. Deze regel stond op het bord met een harde datum binnen tien dagen en een leeg controleveld. Aan de bron nagelezen: open sinds 9 juli, sluit 10 september om 14:00 CEST via myeurekaproject.org. De bestaande beoordeling klopt en blijft staan: niet haalbaar solo — elk consortium wordt geleid door een innoverende kmo en telt minstens twee onafhankelijke organisaties uit minstens twee Eurostars-landen. Nieuw cijfer: ±500 aanvragen per oproep, ±100 gefinancierd (±20%). Daarom géén 🚨, ook al is de datum hard en binnen veertien dagen: een vlag op een oproep waar je onmogelijk aan kunt meedoen, is precies het valse alarm dat de regel van 31-08 wilde uitbannen. De enige zinvolle actie is een partner zoeken in een tweede Eurostars-land, met Call 12 als doel. Bron: eurekanetwork.org, gecontroleerd 01-09-2026.
Zo lees je dit bord: van de vijf nagekeken regels is er vandaag één die je agenda echt raakt (Base, acht dagen), één die over twee weken telt (Start it @KBC), één met een openstaande controle (imec.istart), één met een harde datum waar je niet aan kunt meedoen (Eurostars) en één die nooit haast heeft (EIC). Meer urgentie dan dat is er niet, en dat is een resultaat en geen tekort.
01-09⚡ Nieuw toepassingsgebied — het "back-book": de miljoenen bestaande gebruikers die een platform achteraf moet verifiëren zonder ze kwijt te raken — Wat het is. Elke leeftijds- of identiteitsplicht die dit jaar ingaat, bijt in de praktijk op nieuwe gebruikers — de bestaande ledenlijst is al binnen. OneID (Londen) noemt dat het back-book-probleem en schreef op 17-08-2026 de stand op: op die datum had géén enkele Britse toezichthouder herverificatie van bestaande gebruikers geëist, maar had ook géén enkele toezichthouder voltooiingsgraden, termijnen of een veilige haven gepubliceerd. Er is dus geen plicht én geen vrijstelling. Bron: oneid.uk, 17-08-2026.
🔎 De bril.
Waarom dit voor ons economisch anders ligt dan gewone verificatie. Bij een nieuwe gebruiker is verificatie een drempel bij de deur: eenmalig, en de gebruiker verwacht hem. Bij een back-book moet je miljoenen mensen die al binnen zijn opnieuw langs de poort sturen, en elke procent die daarbij afhaakt is direct omzetverlies. Dat draait de prijsvraag om: de kost per verificatie wordt ondergeschikt aan de doorloop.
💰 En precies daar wint onze metering. M1 (nieuwe mens via eID/itsme, draagt de itsme-kost) valt één keer. Elke volgende raadpleging op diezelfde gebonden mens is een M2-attestatie-oproep, ≈ gratis — en dat geldt over álle klanten heen. Een gebruiker die ooit door onze poort ging, hoeft nooit meer een tweede keer een eID te openen, ook niet bij een ander platform. Voor een back-book van miljoenen is dat het verschil tussen een project en een rekening.
🔌 Integratievorm — batch-CSV, en dat is hier bewust de eenvoudigste weg. (1) Draait al: attestatie-uitgifte en -raadpleging. (2) Franky bouwt: een batch-endpoint dat een lijst bestaande accountsleutels aanneemt en per rij terugmeldt al gebonden / niet gebonden / botst met een andere rij — 4 à 6 dagen. (3) De klant doet: één export van zijn ledenlijst met gepseudonimiseerde sleutels, en stuurt alleen de niet-gebonden rest door de gewone verificatieflow. (4) Standaard: OIDC voor de binding, batch-API voor de sweep. (5) Kleinste demo zonder toestemming: een bestand van 10.000 verzonnen rijen waarvan er 400 dezelfde wortel delen, met de gevonden botsingen ernaast — het rekenvoorbeeld is de verkoop.
🧩 Productmix: V + D (denylist op de persoon-root: wie eerder verwijderd werd komt niet terug via het back-book). Alleen de attestatiekant, geen geldstroom. Trede 2. Groeipad: eerst één batch-sweep als project, daarna de lopende poort als abonnement.
Zo zet je dit in de markt: dit is de zeldzame verkoop waarbij de klant zélf al weet dat hij een probleem heeft en er nog geen naam voor had. Openingszin: "Jullie nieuwe gebruikers zijn geverifieerd. Hoeveel van de mensen die er al waren, zijn dezelfde persoon als iemand anders die er al was — en wat is jullie plan als een toezichthouder daar volgend jaar naar vraagt?"
🔎 De bril.
back-book komt op de hele v2-site nul keer voor (grep 01-09-2026). OneID staat er wél al in (cases-db.json, index.html, toepassingen.json). Dit is dus geen nieuwe prospect maar een nieuw probleem bij een bekende partij — en het staat als toepassingsgebied nergens in de catalogus.Waarom dit voor ons economisch anders ligt dan gewone verificatie. Bij een nieuwe gebruiker is verificatie een drempel bij de deur: eenmalig, en de gebruiker verwacht hem. Bij een back-book moet je miljoenen mensen die al binnen zijn opnieuw langs de poort sturen, en elke procent die daarbij afhaakt is direct omzetverlies. Dat draait de prijsvraag om: de kost per verificatie wordt ondergeschikt aan de doorloop.
💰 En precies daar wint onze metering. M1 (nieuwe mens via eID/itsme, draagt de itsme-kost) valt één keer. Elke volgende raadpleging op diezelfde gebonden mens is een M2-attestatie-oproep, ≈ gratis — en dat geldt over álle klanten heen. Een gebruiker die ooit door onze poort ging, hoeft nooit meer een tweede keer een eID te openen, ook niet bij een ander platform. Voor een back-book van miljoenen is dat het verschil tussen een project en een rekening.
🔌 Integratievorm — batch-CSV, en dat is hier bewust de eenvoudigste weg. (1) Draait al: attestatie-uitgifte en -raadpleging. (2) Franky bouwt: een batch-endpoint dat een lijst bestaande accountsleutels aanneemt en per rij terugmeldt al gebonden / niet gebonden / botst met een andere rij — 4 à 6 dagen. (3) De klant doet: één export van zijn ledenlijst met gepseudonimiseerde sleutels, en stuurt alleen de niet-gebonden rest door de gewone verificatieflow. (4) Standaard: OIDC voor de binding, batch-API voor de sweep. (5) Kleinste demo zonder toestemming: een bestand van 10.000 verzonnen rijen waarvan er 400 dezelfde wortel delen, met de gevonden botsingen ernaast — het rekenvoorbeeld is de verkoop.
🧩 Productmix: V + D (denylist op de persoon-root: wie eerder verwijderd werd komt niet terug via het back-book). Alleen de attestatiekant, geen geldstroom. Trede 2. Groeipad: eerst één batch-sweep als project, daarna de lopende poort als abonnement.
Zo zet je dit in de markt: dit is de zeldzame verkoop waarbij de klant zélf al weet dat hij een probleem heeft en er nog geen naam voor had. Openingszin: "Jullie nieuwe gebruikers zijn geverifieerd. Hoeveel van de mensen die er al waren, zijn dezelfde persoon als iemand anders die er al was — en wat is jullie plan als een toezichthouder daar volgend jaar naar vraagt?"
01-09📋 Stand van de sporen deze nacht — tien items, en twee sporen die eerlijk leeg blijven — Wat er wél is: 🆔 twee identificatie-cases (UK DVS-keurmerk · Roblox × PhilSys) · 💶 één geld-case (X Original Content Rewards) · 💸 x402 protocolwacht mét vondst (builder-code) · 🤝 x401 gecontroleerd en ongewijzigd · 🤖 agentic-lijn (Web Bot Auth nog individueel draft) · 🧪 één testfeit · 🔍 één auditvonnis · 💶 twee funding-regels · ⚡ één nieuw toepassingsgebied. Elf blokken, alle zeven soorten vertegenwoordigd.
🎯 Prospect-spoor — leeg, en dat is de eerlijke uitkomst. De twee kandidaten die vannacht bovenkwamen staan allebei al in het dossier: Roblox (al prospect, mét onderbouwing) en OneID (al in
🌍 Regio-signalen basisinkomen — leeg. Gezocht op nieuw gestarte gegarandeerd-inkomenprogramma's in de VS, uitdrukkelijk inclusief niet-gouvernementele (filantropisch, non-profit, bedrijfsgefinancierd) zoals de regel van 30-08 voorschrijft. Wat terugkwam waren lópende programma's (LA BIG:LEAP, Chicago Resilient Communities, Prince George's County) zonder gedateerde gebeurtenis in de voorbije week. Geen nieuw feit = geen entry.
📡 IoT-lijn — bewust geen nieuwe entry. De CRA-meldplicht van 11 september staat al op deze radar (27-08 en 29-08). Het nieuwe feit van vannacht is klein maar bruikbaar en is aan die bestaande entry toegevoegd in plaats van als tweede blok: ENISA bevestigt dat het Single Reporting Platform op 11-09 operationeel is, en waarschuwt dat de 24-uursklok niet stopt voor je onboarding — registreren moet dus vooraf. Dat raakt Secure Mail rechtstreeks.
✉️ Secure Mail-spoor: niet aan de beurt — dat spoor draait op maandag, vandaag is dinsdag.
🌐 Oppervlakte-check: r4m-founder.franky-f29.workers.dev 200 · r4m-core-v2-k7x9.pages.dev 200. Geen nieuwe of gewijzigde R4M-links gezien. Backup-alarm: geen alarmregel van de laatste 24 uur in
🎯 Prospect-spoor — leeg, en dat is de eerlijke uitkomst. De twee kandidaten die vannacht bovenkwamen staan allebei al in het dossier: Roblox (al prospect, mét onderbouwing) en OneID (al in
cases-db.json, index.html en toepassingen.json). Een derde naam met een échte gedateerde aanleiding van déze week heb ik niet gevonden. Vullen met een vaag bedrijf haalt de kwaliteitslat niet, dus staat er niets.🌍 Regio-signalen basisinkomen — leeg. Gezocht op nieuw gestarte gegarandeerd-inkomenprogramma's in de VS, uitdrukkelijk inclusief niet-gouvernementele (filantropisch, non-profit, bedrijfsgefinancierd) zoals de regel van 30-08 voorschrijft. Wat terugkwam waren lópende programma's (LA BIG:LEAP, Chicago Resilient Communities, Prince George's County) zonder gedateerde gebeurtenis in de voorbije week. Geen nieuw feit = geen entry.
📡 IoT-lijn — bewust geen nieuwe entry. De CRA-meldplicht van 11 september staat al op deze radar (27-08 en 29-08). Het nieuwe feit van vannacht is klein maar bruikbaar en is aan die bestaande entry toegevoegd in plaats van als tweede blok: ENISA bevestigt dat het Single Reporting Platform op 11-09 operationeel is, en waarschuwt dat de 24-uursklok niet stopt voor je onboarding — registreren moet dus vooraf. Dat raakt Secure Mail rechtstreeks.
✉️ Secure Mail-spoor: niet aan de beurt — dat spoor draait op maandag, vandaag is dinsdag.
🌐 Oppervlakte-check: r4m-founder.franky-f29.workers.dev 200 · r4m-core-v2-k7x9.pages.dev 200. Geen nieuwe of gewijzigde R4M-links gezien. Backup-alarm: geen alarmregel van de laatste 24 uur in
r4m-autopush-ALARM.log.31-08📊 SEO — Ook lowlands.business opgelost: onsite 79 → 89, nul auto-fails. Beide apex-domeinen staan nu recht. — Gemeten. lowlands.business zonder www gaf geen pagina (TLS-handshake geweigerd, curl-code 000). Na de ingreep: HTTP 200, www 200, http 301 naar https, certificaat CN=lowlands.business geldig tot 29-11-2026. Onsite van 79 naar 89 (17/19), en voor het eerst geen enkele auto-fail.
Dezelfde oorzaak als turbeau, dezelfde oplossing. DNS verhuisd van Combell naar Cloudflare. Combell blijft registrar én mailhoster — alleen het telefoonboek verhuisde.
Eén stap die hier levensgevaarlijk was. Op dit domein stond DNSSEC aan (DS 43534 13 2 bij de registry). Nameservers omzetten terwijl dat record er nog staat maakt een domein wereldwijd onresolveerbaar — site én mail, in één klap. Dus eerst DNSSEC uit bij Combell, wachten tot het DS-record echt weg was (gecontroleerd bij 8.8.8.8 én 1.1.1.1), en pas daarna omzetten. Bij turbeau stond DNSSEC uit en kon het meteen.
De mail is nagemeten, niet aangenomen. Aan dit domein hangt een actieve mailbox. Na de omschakeling: MX 2/2 naar mailprotect.be, SPF, DMARC, SRV 4/4,
Vier dingen om te onthouden voor de volgende keer. (1) Cloudflare Pages accepteert een apex als custom domain alleen als de DNS bij Cloudflare staat; een ALIAS bij een externe provider wordt geweigerd. (2) Bij de zone-import zet Cloudflare
Stand van de vloot. turbeau2rock 79 → 84, lowlands 79 → 89. Twee storingen weg die respectievelijk zeven en acht weken onopgemerkt bleven, omdat er tot 28-08 niets was dat apex en www met elkaar vergeleek.
Dezelfde oorzaak als turbeau, dezelfde oplossing. DNS verhuisd van Combell naar Cloudflare. Combell blijft registrar én mailhoster — alleen het telefoonboek verhuisde.
Eén stap die hier levensgevaarlijk was. Op dit domein stond DNSSEC aan (DS 43534 13 2 bij de registry). Nameservers omzetten terwijl dat record er nog staat maakt een domein wereldwijd onresolveerbaar — site én mail, in één klap. Dus eerst DNSSEC uit bij Combell, wachten tot het DS-record echt weg was (gecontroleerd bij 8.8.8.8 én 1.1.1.1), en pas daarna omzetten. Bij turbeau stond DNSSEC uit en kon het meteen.
De mail is nagemeten, niet aangenomen. Aan dit domein hangt een actieve mailbox. Na de omschakeling: MX 2/2 naar mailprotect.be, SPF, DMARC, SRV 4/4,
mail → pop3.mailprotect.be, google-site-verification intact. Franky kreeg er tijdens de omschakeling nog mail op — het levendste bewijs dat er niets is uitgevallen.Vier dingen om te onthouden voor de volgende keer. (1) Cloudflare Pages accepteert een apex als custom domain alleen als de DNS bij Cloudflare staat; een ALIAS bij een externe provider wordt geweigerd. (2) Bij de zone-import zet Cloudflare
mail, autoconfig, autodiscover en ftp op Proxied — dat MOET terug naar DNS only, want de proxy doet alleen http/https en zou IMAP 993, POP3 995, SMTP 587 en FTP onbereikbaar maken. (3) DNSSEC eerst uit, DS-record laten verdwijnen, dan pas verhuizen. (4) Na zone-overname hervalideert Cloudflare bestaande custom domains; tijdelijk 522 is normaal en verdwijnt met Check DNS records.Stand van de vloot. turbeau2rock 79 → 84, lowlands 79 → 89. Twee storingen weg die respectievelijk zeven en acht weken onopgemerkt bleven, omdat er tot 28-08 niets was dat apex en www met elkaar vergeleek.
31-08📊 SEO — OPGELOST: turbeau2rock.com werkt weer zonder www, onsite 79 → 84 — Wat er stuk was. Wie turbeau2rock.com zonder www intikte kreeg een foutpagina. De TLS-handshake lukte nog (geldig certificaat), maar de verbinding brak daarna: HTTP/2 INTERNAL_ERROR, HTTP/1.1 curl-code 000. Combells doorstuurdienst hield een certificaat aan maar leverde de redirect niet. Volgens de historiek al stuk sinds 05-07; het viel pas op toen de apex↔www-controle op 28-08 in de audit werd gebouwd.
Wat de oorzaak echt was. Niet de redirect, maar de opzet. De apex stond bij Combell, www bij Cloudflare Pages — twee servers voor één site, en de helft die niemand onderhield was de kapotte. Een ALIAS bij Combell loste het niet op: Cloudflare Pages accepteert een apex als custom domain alleen wanneer de DNS bij Cloudflare staat. Dat bevestigde Cloudflare zelf in de wizard.
Wat er gebeurd is. DNS van turbeau2rock.com verhuisd van Combell naar Cloudflare (
Gemeten, voor en na. VÓÓR: https 000, onsite 79, auto-fails hostvariant + gdpr. NÁ: https 200, http 301 naar https, certificaat CN=turbeau2rock.com geldig tot 29-11-2026, onsite 84 (16/19), enige auto-fail nog gdpr. Dat is +5 punten op het domein met de meeste vertoningen van de vloot (587 in 28 dagen, met “dj turbeau” op positie 8,3).
De mail is nagemeten, niet aangenomen. Na de omschakeling: MX 2/2 naar mailprotect.be, SPF, DMARC, SRV 4/4,
Nog open: lowlands.business. Zelfde kwaal, maar daar staat DNSSEC aan. Nameservers omzetten voordat het DS-record bij de registry verdwenen is, maakt dat domein wereldwijd onresolveerbaar — site én mail. Dus daar eerst DNSSEC uit, wachten tot het DS-record weg is, en pas dan dezelfde route.
Wat de oorzaak echt was. Niet de redirect, maar de opzet. De apex stond bij Combell, www bij Cloudflare Pages — twee servers voor één site, en de helft die niemand onderhield was de kapotte. Een ALIAS bij Combell loste het niet op: Cloudflare Pages accepteert een apex als custom domain alleen wanneer de DNS bij Cloudflare staat. Dat bevestigde Cloudflare zelf in de wizard.
Wat er gebeurd is. DNS van turbeau2rock.com verhuisd van Combell naar Cloudflare (
nucum/weston.ns.cloudflare.com). Combell blijft registrar én mailhoster — alleen het telefoonboek verhuisde. Bij de import stonden mail, autoconfig, autodiscover en ftp op Proxied; dat is teruggezet naar DNS only, want de Cloudflare-proxy doet alleen http/https en had IMAP 993, POP3 995, SMTP 587 en FTP onbereikbaar gemaakt. Daarna de apex als custom domain op het Pages-project: CNAME @ → turbeau2rock-doc.pages.dev.Gemeten, voor en na. VÓÓR: https 000, onsite 79, auto-fails hostvariant + gdpr. NÁ: https 200, http 301 naar https, certificaat CN=turbeau2rock.com geldig tot 29-11-2026, onsite 84 (16/19), enige auto-fail nog gdpr. Dat is +5 punten op het domein met de meeste vertoningen van de vloot (587 in 28 dagen, met “dj turbeau” op positie 8,3).
De mail is nagemeten, niet aangenomen. Na de omschakeling: MX 2/2 naar mailprotect.be, SPF, DMARC, SRV 4/4,
mail → pop3.mailprotect.be, en de google-site-verification intact. Geen onderbreking vastgesteld. Volledige zone-backup vooraf vastgelegd in Site-Fleet/DNS-BACKUP-combell-2026-08-31.md.Nog open: lowlands.business. Zelfde kwaal, maar daar staat DNSSEC aan. Nameservers omzetten voordat het DS-record bij de registry verdwenen is, maakt dat domein wereldwijd onresolveerbaar — site én mail. Dus daar eerst DNSSEC uit, wachten tot het DS-record weg is, en pas dan dezelfde route.
31-08🔍 AUDIT — de bronnenlijst kreeg vanavond zijn eerste echte controle, en er stond meteen een dode bron in — De belofte.
Wat er gebeurde. De avondronde van 30-08 draaide niet — de laatste commit van die dag is 15:44, van een 19:00-run is geen spoor. Twintig van de 25 rijen stonden dus vierentwintig uur op
De meting van vanavond: 25 bronnen, 24 levend, 2 omgeleid, 1 dood.
• DOOD —
• OMGELEID —
De vervanger is beter dan het origineel. Sterkste van drie: de ARF-tags-API van
De valstrik die erbij hoort. Kandidaat-vervanger
Aanwas. Twee bronnen die vannacht wél een vondst opleverden stonden niet in de lijst: de AP2-releases-API (waar de "Human Not Present"-vondst vandaan kwam — v0.2.0 op 28-04-2026, vorige release 16-09-2025) en de ARF-tags. Beide toegevoegd.
Zo zet je dit in de markt: niet naar buiten, maar naar binnen — dit is het bewijs dat de zelf-controlerende bronnenlijst werkt zoals bedoeld. Waar het x402-gat twee maanden duurde, duurde dit één dag. Vonnis: ◐ deels, want het mechanisme deed zijn werk, alleen pas de tweede avond.
docs/BRONNEN.md is aangelegd op 30-08-2026 om 15:09 met bovenaan: "Wie onderhoudt dit: de routine r4m, fase BIJWERKEN (19:00). Elke avond."Wat er gebeurde. De avondronde van 30-08 draaide niet — de laatste commit van die dag is 15:44, van een 19:00-run is geen spoor. Twintig van de 25 rijen stonden dus vierentwintig uur op
? (nooit gecontroleerd), en een van die twintig was dood.De meting van vanavond: 25 bronnen, 24 levend, 2 omgeleid, 1 dood.
• DOOD —
ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/ geeft 404. Niet omdat EUDI weg is: de ruimte bestaat, maar laadt alleen via een volledige pagina-URL mét paginanummer. Exact het patroon van coinbase/x402 — de inhoud verhuist, de oude ingang lijkt te bestaan, en niemand merkt het tot het dossier maanden achterloopt. Ditmaal geteld in één dag in plaats van twee maanden.• OMGELEID —
www.x402.org → x402.org (301, kale vorm overgenomen); werk.belgie.be/…/sociaal-overleg/ verliest zijn slotstreep.De vervanger is beter dan het origineel. Sterkste van drie: de ARF-tags-API van
eu-digital-identity-wallet — machineleesbaar, versienummer plus datum, geen pagina die kan verhuizen. Stand: ARF v3.0.0, samengevoegd 21-07-2026. En door de maX-bril: maX kende die versie en die datum al, dus er is géén achterstand. Dat is de bril zoals hij bedoeld is — eerst kijken wat het dossier weet, dán pas iets "nieuw" noemen.De valstrik die erbij hoort. Kandidaat-vervanger
.../wikis/display/EUDIGITALIDENTITYWALLET/ geeft 200 en oogt gezond, maar leidt om naar de EU-loginpagina. Zelfde categorie als r4m-max.pages.dev: een statuscode is geen bewijs van inhoud. Staat nu doorgestreept in de tabel mét die reden, zodat een volgende ronde er niet intrapt.Aanwas. Twee bronnen die vannacht wél een vondst opleverden stonden niet in de lijst: de AP2-releases-API (waar de "Human Not Present"-vondst vandaan kwam — v0.2.0 op 28-04-2026, vorige release 16-09-2025) en de ARF-tags. Beide toegevoegd.
Zo zet je dit in de markt: niet naar buiten, maar naar binnen — dit is het bewijs dat de zelf-controlerende bronnenlijst werkt zoals bedoeld. Waar het x402-gat twee maanden duurde, duurde dit één dag. Vonnis: ◐ deels, want het mechanisme deed zijn werk, alleen pas de tweede avond.
31-08🔍 AUDIT ⏱ — onze eigen opbrengst-regel zou de vroegwaarschuwing wegsnoeien die we juist willen hebben — De regel.
Wie ze vanavond raakte. Drie bronnen: de x402-analyse van Chainalysis (59 dagen stil), het GBI-dashboard
De fout zit in de regel, niet in de bronnen. Die derde is geen nieuwsbron maar een wachtpost: hij bewaakt of een uniciteits-speler een uitbetaalproduct aankondigt — de dag waarop onze moat aangevallen wordt. Stilte is daar het gewenste resultaat, niet het bewijs van nutteloosheid. Een regel die wachtposten wegsnoeit omdat ze zwijgen, sloopt precies de vroegwaarschuwing waarvoor ze bestaan.
En nog iets, eerlijk. Die "twee vlaggen achter elkaar" vielen één dag na elkaar: de eerste kreeg elke bron bij het aanleggen van de tabel op 30-08, op grond van haar historische laatste treffer. Dat is geen twee ronden bewijs — dat is één ronde die twee keer geteld werd.
Er is niets geschrapt. Voorstel aan jou, en dit is de keuze: regel 3 splitsen in twee soorten. Een nieuwsbron (blog, dashboard, register) mag bij aanhoudende stilte naar een lagere frequentie. Een wachtpost krijgt nooit een opbrengstvlag en wordt beoordeeld op of hij nog het juiste bewaakt, niet op hoe vaak hij afgaat.
Zo zet je dit in de markt: intern. Maar het is wél het soort ding dat je aan een klant vertelt als hij vraagt hoe je voorkomt dat een bewakingssysteem zijn eigen alarmen uitzet.
BRONNEN.md regel 3: een bron die 30 dagen niets oplevert krijgt een vlag; twee vlaggen achter elkaar → voorstel om te schrappen.Wie ze vanavond raakte. Drie bronnen: de x402-analyse van Chainalysis (59 dagen stil), het GBI-dashboard
guaranteedincome.us (58 dagen), en de moat-wacht op Self Protocol · Rarimo · Billions Network · GoodDollar (57 dagen).De fout zit in de regel, niet in de bronnen. Die derde is geen nieuwsbron maar een wachtpost: hij bewaakt of een uniciteits-speler een uitbetaalproduct aankondigt — de dag waarop onze moat aangevallen wordt. Stilte is daar het gewenste resultaat, niet het bewijs van nutteloosheid. Een regel die wachtposten wegsnoeit omdat ze zwijgen, sloopt precies de vroegwaarschuwing waarvoor ze bestaan.
En nog iets, eerlijk. Die "twee vlaggen achter elkaar" vielen één dag na elkaar: de eerste kreeg elke bron bij het aanleggen van de tabel op 30-08, op grond van haar historische laatste treffer. Dat is geen twee ronden bewijs — dat is één ronde die twee keer geteld werd.
Er is niets geschrapt. Voorstel aan jou, en dit is de keuze: regel 3 splitsen in twee soorten. Een nieuwsbron (blog, dashboard, register) mag bij aanhoudende stilte naar een lagere frequentie. Een wachtpost krijgt nooit een opbrengstvlag en wordt beoordeeld op of hij nog het juiste bewaakt, niet op hoe vaak hij afgaat.
Zo zet je dit in de markt: intern. Maar het is wél het soort ding dat je aan een klant vertelt als hij vraagt hoe je voorkomt dat een bewakingssysteem zijn eigen alarmen uitzet.
31-08🧪 TEST — de SEO-vloot leeft, maar drie van de achttien domeinen staan al 59 dagen bevroren terwijl de sync groen meldt — Gemeten vanavond op
Maar de sync-datum is niet de meet-datum, en daar zit het gat. Verdeling van de laatste échte meting: 8 domeinen op 31-08 · 6 op 30-08 · 1 op 28-08 · en 3 op 03-07-2026 — negenenvijftig dagen oud. Die drie zijn
De uitschieters van vandaag, voor wie er iets mee wil:
Herhaalbaar commando:
Zo zet je dit in de markt: niet naar buiten. Wel de check die de SEO-vloot een halve dag werk bespaart: vraag nooit naar synced_at als je date bedoelt.
ccc-v3.franky-f29.workers.dev/api/seo-watch: 18 domeinen, allemaal met synced_at 2026-08-31 14:34. De keten die op 9 juli stilviel en zeven weken onopgemerkt bleef, draait dus weer.Maar de sync-datum is niet de meet-datum, en daar zit het gat. Verdeling van de laatste échte meting: 8 domeinen op 31-08 · 6 op 30-08 · 1 op 28-08 · en 3 op 03-07-2026 — negenenvijftig dagen oud. Die drie zijn
hiddengarden.be, hiddengarden-dsvdbuild.pages.dev en kortrijkspurs.be. Ze verschijnen groen in de sync en zouden in een snelle blik doorgaan voor actueel.De uitschieters van vandaag, voor wie er iets mee wil:
idgs.eu onsite 95 / CWV 76 · gevelsteenbedrijf-v6.pages.dev onsite 56 / CWV 34 met een LCP van 16,1 s en auto_fails op h1, sitemap, realfourohfour en gdpr — veruit de slechtste van de vloot · my-cccnew.pages.dev CWV 100 maar onsite 22.Herhaalbaar commando:
curl -s https://cccv3-clone.franky-f29.workers.dev/api/seo-watch — vergelijk per domein latest.date (echte meting) met latest.synced_at (sync). Lopen die meer dan een paar dagen uiteen, dan meet je een oud cijfer.Zo zet je dit in de markt: niet naar buiten. Wel de check die de SEO-vloot een halve dag werk bespaart: vraag nooit naar synced_at als je date bedoelt.
31-08💶 FUNDING — je kan ELKE MAAND meedoen aan de EIC-oproep van €2,5 miljoen. Er is geen deadline; er is een maandelijkse bundeling — Dit is het antwoord op de vraag die je vandaag stelde, en het is beter nieuws dan het bord drie nachten lang suggereerde. De EIC Accelerator (European Innovation Council) geeft ≤ €2,5 miljoen subsidie, eventueel aangevuld met €1–10 miljoen kapitaal via het EIC Fund. Het is geen tender en geen aanbesteding: je biedt niet mee om iets te leveren, je vraagt financiering aan voor je eigen project.
De korte aanvraag (stap 1) heeft GEEN sluitingsdatum. Letterlijk van de officiële pagina: "Short proposals may be submitted at any time and will be batched for evaluation every first Tuesday of the month at 5pm Brussels time." Je kan dus elke dag van het jaar indienen. De eerste dinsdag van de maand bepaalt alleen in welke beoordelingsbundel je valt. Mis je er één, dan schuif je één maand op — je verliest de kans niet.
Wat er wél vastligt zijn de VOLLEDIGE aanvragen (stap 2), en dat zijn de echte deuren: in 2026 op 7 januari, 4 maart, 6 mei, 8 juli, 2 september en 4 november, telkens 17:00 Brusselse tijd. 2 september is onbereikbaar (stap 1 moet dan al doorstaan zijn); 4 november is het doel. Terugrekenen: stap 1 duurt ~4–6 weken, dus een korte aanvraag die in de bundel van 1 september of 6 oktober valt, haalt 4 november nog.
🇧🇪 En dan je VLAIO-vraag — die heeft een concreet antwoord. Je vraagt de EIC Accelerator niet aan via VLAIO; indienen gebeurt rechtstreeks bij de EU op het Funding & Tenders-portaal. Maar VLAIO is wél de Vlaamse deur ernaartoe: het National Contact Point voor de EIC zit bij VLAIO / Enterprise Europe Network Vlaanderen, en dat is Magali Parent (magali.parent@vlaio.be, Agentschap Innoveren & Ondernemen). Zij bieden "coaching, advies en het verruimen van het netwerk door matchmaking events" en een voorlopige beoordeling van je dossier — gratis, vóór je indient. VLAIO organiseerde eerder ook een preselectie voor Vlaamse kandidaten. Dat is de goedkoopste tweede mening die je kan krijgen op een dossier van €2,5 miljoen.
🔌 Wat er vandaag te doen valt: (1) mail Magali Parent met twee alinea's over R4M en vraag om een voorlopige beoordeling — een halfuur werk, geen dossier nodig; (2) daarna pas de korte aanvraag schrijven. Er is geen enkele reden om dat vóór morgen 17:00 af te haasten: de volgende bundel is 6 oktober en die haalt 4 november óók.
Eerlijk erbij: vlaio.be gaf mij 403 bij het ophalen — de contactgegevens en de coaching-omschrijving komen van Enterprise Europe Network Vlaanderen en uit de VLAIO-zoekresultaten, niet uit de VLAIO-pagina zelf. Bel of mail vóór je ergens op rekent. Ook eerlijk: EIC heeft een lage slaagkans — je eigen dossier noteert dat Eurostars met ~20% "3× better than EIC" is, dus reken op grofweg 5–7%.
Zo zet je dit in de markt: niet als markt maar als moeite-inschatting — dit is een instrument waar je maandelijks opnieuw op kan inschrijven zonder iets te verliezen. Dat verandert het van een paniekdatum in een routine.
De korte aanvraag (stap 1) heeft GEEN sluitingsdatum. Letterlijk van de officiële pagina: "Short proposals may be submitted at any time and will be batched for evaluation every first Tuesday of the month at 5pm Brussels time." Je kan dus elke dag van het jaar indienen. De eerste dinsdag van de maand bepaalt alleen in welke beoordelingsbundel je valt. Mis je er één, dan schuif je één maand op — je verliest de kans niet.
Wat er wél vastligt zijn de VOLLEDIGE aanvragen (stap 2), en dat zijn de echte deuren: in 2026 op 7 januari, 4 maart, 6 mei, 8 juli, 2 september en 4 november, telkens 17:00 Brusselse tijd. 2 september is onbereikbaar (stap 1 moet dan al doorstaan zijn); 4 november is het doel. Terugrekenen: stap 1 duurt ~4–6 weken, dus een korte aanvraag die in de bundel van 1 september of 6 oktober valt, haalt 4 november nog.
🇧🇪 En dan je VLAIO-vraag — die heeft een concreet antwoord. Je vraagt de EIC Accelerator niet aan via VLAIO; indienen gebeurt rechtstreeks bij de EU op het Funding & Tenders-portaal. Maar VLAIO is wél de Vlaamse deur ernaartoe: het National Contact Point voor de EIC zit bij VLAIO / Enterprise Europe Network Vlaanderen, en dat is Magali Parent (magali.parent@vlaio.be, Agentschap Innoveren & Ondernemen). Zij bieden "coaching, advies en het verruimen van het netwerk door matchmaking events" en een voorlopige beoordeling van je dossier — gratis, vóór je indient. VLAIO organiseerde eerder ook een preselectie voor Vlaamse kandidaten. Dat is de goedkoopste tweede mening die je kan krijgen op een dossier van €2,5 miljoen.
🔌 Wat er vandaag te doen valt: (1) mail Magali Parent met twee alinea's over R4M en vraag om een voorlopige beoordeling — een halfuur werk, geen dossier nodig; (2) daarna pas de korte aanvraag schrijven. Er is geen enkele reden om dat vóór morgen 17:00 af te haasten: de volgende bundel is 6 oktober en die haalt 4 november óók.
Eerlijk erbij: vlaio.be gaf mij 403 bij het ophalen — de contactgegevens en de coaching-omschrijving komen van Enterprise Europe Network Vlaanderen en uit de VLAIO-zoekresultaten, niet uit de VLAIO-pagina zelf. Bel of mail vóór je ergens op rekent. Ook eerlijk: EIC heeft een lage slaagkans — je eigen dossier noteert dat Eurostars met ~20% "3× better than EIC" is, dus reken op grofweg 5–7%.
Zo zet je dit in de markt: niet als markt maar als moeite-inschatting — dit is een instrument waar je maandelijks opnieuw op kan inschrijven zonder iets te verliezen. Dat verandert het van een paniekdatum in een routine.
31-08💶 FUNDING — Base Batches 004 sluit 9 september: $100.000 per team, en agent-betalingen zijn dit jaar het doelgebied — Herbevestigd op 31-08 aan base.org/batches, tijdlijn ongewijzigd: "Aug 19 Applications Open · Sep 9 Applications Closed · Sep 17 Acceptances Sent · Sep 21 – Nov 15 Virtual Program · Nov 17 Demo Day in New York", met "$100K investment from the Base Ecosystem Fund".
Dit is een HARDE datum — nog 9 dagen. Toelating letterlijk: "Pre-product to post-MVP teams that have not yet raised a formal Seed round" en "Teams committed to Base as their default implementation and network of choice". Voor R4M is dat laatste geen belofte maar een feit: usdc-base ÍS de standaard-afrekenplug van de motor, met eurc-base ernaast.
Nog steeds onbevestigd (blog.base.org gaf 403 en de publieke pagina zwijgt erover): de investeringsvorm (SAFE, equity of iets anders), eventuele geografische beperkingen, en of een solo-oprichter uitdrukkelijk toegelaten is. Voor een eenmanszaak is juist dat laatste de vraag die de aanvraag maakt of breekt — open het formulier één keer zelf vóór je begint te schrijven.
Dit is een HARDE datum — nog 9 dagen. Toelating letterlijk: "Pre-product to post-MVP teams that have not yet raised a formal Seed round" en "Teams committed to Base as their default implementation and network of choice". Voor R4M is dat laatste geen belofte maar een feit: usdc-base ÍS de standaard-afrekenplug van de motor, met eurc-base ernaast.
Nog steeds onbevestigd (blog.base.org gaf 403 en de publieke pagina zwijgt erover): de investeringsvorm (SAFE, equity of iets anders), eventuele geografische beperkingen, en of een solo-oprichter uitdrukkelijk toegelaten is. Voor een eenmanszaak is juist dat laatste de vraag die de aanvraag maakt of breekt — open het formulier één keer zelf vóór je begint te schrijven.
31-08💶 FUNDING — imec.istart opent MORGEN: €100.000 converteerbaar, één maand venster, solo is geen beletsel — De Belgische najaarsoproep van imec.istart staat op "Sept 1 - Sept 30 (midnight)" en stond bij controle op 31-08 nog als UPCOMING met een NOTIFY ME-knop. Aanbod: €100.000 converteerbare lening (CLA) plus het acceleratorprogramma. Slaagkans ~15% per oproep. De pagina spreekt van een voorkeur voor een complementair team, niet van een eis — solo-oprichter is dus geen harde blokkade.
Dit is een HARDE datum, anders dan EIC: mis je 30 september, dan is de volgende Belgische oproep pas in 2027. Beoordeling gebeurt per oproep, niet doorlopend — vroeg indienen is beter dan laatste week.
Correctie op ons eigen bord: het veld beweerde sinds 27-08 dat Duitsland hetzelfde venster heeft als België. Dat klopt niet — de bron toont Duitsland "Oct 1 - Oct 31", gelijk aan Nederland; Spanje "Oct 1 - Nov 30". Vier dagen fout op het bord, zonder gevolgen omdat België de route is.
Dit is een HARDE datum, anders dan EIC: mis je 30 september, dan is de volgende Belgische oproep pas in 2027. Beoordeling gebeurt per oproep, niet doorlopend — vroeg indienen is beter dan laatste week.
Correctie op ons eigen bord: het veld beweerde sinds 27-08 dat Duitsland hetzelfde venster heeft als België. Dat klopt niet — de bron toont Duitsland "Oct 1 - Oct 31", gelijk aan Nederland; Spanje "Oct 1 - Nov 30". Vier dagen fout op het bord, zonder gevolgen omdat België de route is.
31-08🆔 Identificatie-case 2 — machines kregen drie dagen geleden een inschrijvingsloket met statusopvolging. Mensen hebben dat nog altijd niet. — Op 28-08-2026 opende Cloudflare met "BotBase for Operators" de operator-kant van zijn botregister: inschrijvingen krijgen statusopvolging, kunnen bijgewerkt worden, en de operator declareert in een gedragsmodel hoe zijn bot met inhoud omgaat. Aanleiding is de groei — "The number of new bots submitted each year has grown sharply — increasing about 7 times in volume since 2023" — waardoor handmatige beoordeling niet meer volstond. (Een absoluut totaal geeft Cloudflare niet; dat cijfer bestaat dus niet en mag nergens verzonnen worden.) De kern zit in wat die verificatie controleert: het systeem haalt automatisch de IP-lijst op, bevestigt de reverse DNS, of valideert de Web Bot Auth-handtekening — "instead of a person doing it by hand". Drie machinefeiten. Geen bedrijf, geen bestuurder, geen mens. Een bot wordt geverifieerd zonder dat er ergens een natuurlijke persoon in beeld komt. Daarmee heeft de asymmetrie uit onze verkoopkit sinds 28-08 een URL en een dashboard: er staat een werkend, geautomatiseerd, publiek loket voor "welke machine is dit", en er staat niets voor "is dit één echt, uniek mens". Het woord "BotBase" komt in de hele maX-map niet voor. 🔌 Integratievorm: geen koppeling met Cloudflare — dit is positionering plus een bewakingspunt. Wat er wél te doen valt: (1) draait al — R4M geeft vandaag al een attest per geverifieerd mens; (2) Franky, één dag, geen code: de spiegel-slide (screenshot botregister links, lege "register voor mensen" rechts) en één regel in de Verkoopkit; (3) de klant doet niets; (4) standaard: Web Bot Auth als contrast, niet als afhankelijkheid; (5) kleinste demo zonder toestemming: die twee screenshots naast elkaar. 🧩 Productmix: module V als kern, D erbij zodra iemand een bot-operator óók aan een persoon-root wil hangen. Alleen de attestatiekant, de rail doet niet mee. Trede 2. Groeipad: vandaag een slide, morgen het antwoord als een klant vraagt "waarom kan Cloudflare dit niet gewoon?" — omdat hun verificatie per ontwerp bij het IP-adres stopt. Zo zet je dit in de markt: gebruik het als opener bij elke partij die vandaag bot-verkeer beheert. Openingszin: "Cloudflare opende vorige week een inschrijvingsloket waar een bot een gecontroleerde identiteit krijgt: IP-lijst, reverse DNS, handtekening. Voor de vraag of er één echt, uniek mens achter iets zit, bestaat dat loket nergens. Wij zijn dat loket." ⏱ Bewaken: krijgt BotBase ooit een veld waarin de operator een geverifieerde natuurlijke persoon of rechtspersoon moet zijn, dan is dat tegelijk validatie én een aanval op onze moat.
31-08🆔 Identificatie-case 1 — een toezichthouder hing zes dagen geleden 30 miljoen dollar aan de zin "wij wisten niet wie er aan de andere kant zat", óók bij bezoekers die nooit inlogden. — Op 25-08-2026 beboette de Braziliaanse ANPD ByteDance voor R$153,7 miljoen (±$29,8 mln) onder de LGPD: naar schatting zijn de gegevens van minstens 8 MILJOEN minderjarigen verwerkt door ontoereikende leeftijdsverificatie. Het deel dat de koppen missen en dat ons aangaat: het verwijt slaat óók op de UITGELOGDE feed — TikTok nam volgens de ANPD geen doeltreffende maatregelen om verwerking via de logged-out feed te voorkomen, noch om te beletten dat die groep zich alsnog registreerde. Eén bron vat het samen als een boete over gegevens van gebruikers die nooit inlogden. Dat is exact het scenario waarin accountgebaseerde controle per definitie niets kan: er ís geen account. ByteDance moet bovendien onrechtmatig verzamelde data wissen en een verbeterplan uitvoeren (strengere instellingen onder 16, ouderlijke controles). Let op het verschil met wat al in het dossier staat: maX kent de ANPD van de World-/Worldcoin-zaak (januari 2025) — dáár ging het om te véél biometrie, hier om te weinig vaststelling. 🔌 Integratievorm: OIDC-knop op de eID-wortel voor de ingelogde kant, plus — als Franky die hoek wil — een G-module-poort vóór de uitgelogde feed. (1) Draait al: de itsme/eID-flow staat en is sandbox-geverifieerd. (2) Franky bouwt: niets nieuws; hooguit 2 dagen om de leeftijds-assertie als apart attribuut naast de uniciteits-assertie te zetten. (3) De klant doet: één OIDC-client registreren en de knop plaatsen. (4) Standaard: OIDC + EUDI-attributen. (5) Kleinste demo zonder toestemming: twee schermen naast elkaar — dezelfde bezoeker twee keer als "nieuw" geteld zonder R4M, één keer mét. 🧩 Productmix: V (is dit een echt, uniek mens) + D (ban op de persoon-root, niet op één account) als kern; G alleen als de uitgelogde-feed-hoek gekozen wordt. De rail doet NIET mee — dit is zuivere attestatie, meter M2. Trede 2. Groeipad: begin bij attest op de ingelogde kant, schakel de rail pas bij als er een uitbetaling in beeld komt. Zo zet je dit in de markt: dit is je niet-Europese bewijsstuk. Al onze munitie is EU en wordt weggewuifd als Brusselse regeldrift; een Braziliaanse toezichthouder die hetzelfde gat beboet maakt er een wereldwijd patroon van. Openingszin: "Zes dagen geleden kostte 'wij wisten niet wie er aan de andere kant zat' aan ByteDance dertig miljoen dollar — en de zwaarste verwijten gingen over bezoekers die nooit inlogden. Hoeveel van uw verkeer zit vandaag in diezelfde categorie?" ❓ Keuzevraag voor Franky, niet gegokt: verkopen we de uitgelogde-feed-hoek (G-module, drempel waar nu geen drempel staat) of blijven we bij de ingelogde kant (V+D)?
31-08⚙️ Protocolwacht — de betaalstandaard van Google, Visa en Mastercard heeft sinds april een naam voor jouw gat: "Human Not Present". Ons dossier kende die naam niet. — AP2 v0.2.0 verscheen op 28-04-2026 met één regel release-notitie: "This is the second release of AP2. It focuses on providing Human Not Present flows." Dezelfde dag schonk Google AP2 aan de FIDO Alliance. maX noemt AP2 op zes plaatsen correct, maar "v0.2" en "human not present" staan nergens — 125 dagen achterstand, nagekeken via de GitHub-releases-API op 31-08-2026. Scherper nog is wat de FIDO Alliance zelf schrijft (26-05-2026): identiteitsbinding is "linking the user to a cryptographic key (often anchored in device-based authentication)". Dat is een apparaat, geen mens. Daarmee is het patroon uit SIGNALS_ADAPT niet drie maar VIER implementaties groot (Cloudflare=account, IETF-draft=agent-pseudoniem, HKT/Red Date=entiteit, AP2/FIDO=apparaatsleutel) — en de vierde is de tafel waar Mastercard en Visa de betaalwerkgroep voorzitten en CVS Health, Google en OpenAI de authenticatiewerkgroep. 🔌 Integratievorm: geen — dit is positionering, geen koppeling. Wat er wél te doen valt: (1) draait al — de protocolwacht, uitgebreid met één releases-API-call op google-agentic-commerce/AP2 per run; (2) Franky, halve dag, geen code — één slide in de Verkoopkit met de vier bindingen naast elkaar en de FIDO-zin er letterlijk onder; (3) de klant doet niets; (4) standaard: AP2 v0.2 + FIDO Payments TWG; (5) kleinste demo zonder toestemming: die ene slide. 🧩 Productmix: module V (Verify human) alleen — dit raakt de attestatiekant, de rail doet niet mee. Trede 5 (machine handelt namens een mens), en dat is precies waarom het nog niemands omzet is. Groeipad: vandaag een citaat in de verkoop, later het argument onder een uniciteitseis als één van de FIDO-werkgroepen ooit naar de natuurlijke persoon zakt — dat moment is tegelijk validatie én moat-aanval. Zo zet je dit in de markt: stop met uitleggen dat er een gat is en citeer de standaard die hem benoemt. Openingszin: "De betaalstandaard waar Visa en Mastercard de werkgroep van voorzitten heet uw scenario sinds april letterlijk 'Human Not Present'. Wij zijn de laag die zegt of daar één echt, uniek mens achter zat." ⚠️ Nog niet nagekeken: of de AP2-flows-spec érgens uniciteit van de natuurlijke persoon eist. Niet in een verkoopstuk gebruiken vóór dat gelezen is.
31-08🔍 AUDIT — de radar stond twee nachten stil, en de oorzaak was een regel die wij er zelf in gezet hebben — Wat er mis was. Op 30-08 kwam er een poort: de routine diende vondsten in bij de doorloop-API en Franky moest ze goedkeuren vóór ze hier verschenen. Het effect was meetbaar. De nachtrun van 31-08 03:23 vond drie volwaardige vondsten, schreef ze volledig uit — inclusief kant-en-klare HTML — en zette ze op status
De diepere fout. De poortregel zei dat de radar "de enige plek is waar jouw werk binnenkomt: vondsten van de tien sporen". Maar spoor J (funding) had geen rij in de doorstroomtabel en schreef alleen naar het privé-dossier. Gevolg: de enige categorie met een klok erop — subsidies en deadlines — was de enige die hier nooit verscheen. Precies de informatie die het snelst veroudert, kwam nooit aan.
Wat er vandaag veranderd is (beslissing Franky, 31-08: "Zorg gewoon dat alles wat ik van die verschillende routines samen heb gevoegd, op Marktradar binnenkomt. Punt."): de poort is opgeheven. De routine schrijft voortaan rechtstreeks op de radar, in dezelfde run, met een doel van 5 à 15 items per nacht. Funding is toegevoegd als zevende soort. De vijf opgeheven routines staan nu met naam in een tabel in de routine, met per routine wat ze hier moeten afleveren — zodat een stille routine zichtbaar wordt in plaats van vergeten.
De drie vondsten van vannacht staan hieronder alsnog, ongewijzigd zoals de nachtrun ze schreef.
beantwoord. Daar bleven ze staan. Op de radar stonden van die nacht nul items; de enige twee entries van 31-08 kwamen van de SEO-routine, die niet door de poort gaat en dus gewoon bleef schrijven.De diepere fout. De poortregel zei dat de radar "de enige plek is waar jouw werk binnenkomt: vondsten van de tien sporen". Maar spoor J (funding) had geen rij in de doorstroomtabel en schreef alleen naar het privé-dossier. Gevolg: de enige categorie met een klok erop — subsidies en deadlines — was de enige die hier nooit verscheen. Precies de informatie die het snelst veroudert, kwam nooit aan.
Wat er vandaag veranderd is (beslissing Franky, 31-08: "Zorg gewoon dat alles wat ik van die verschillende routines samen heb gevoegd, op Marktradar binnenkomt. Punt."): de poort is opgeheven. De routine schrijft voortaan rechtstreeks op de radar, in dezelfde run, met een doel van 5 à 15 items per nacht. Funding is toegevoegd als zevende soort. De vijf opgeheven routines staan nu met naam in een tabel in de routine, met per routine wat ze hier moeten afleveren — zodat een stille routine zichtbaar wordt in plaats van vergeten.
De drie vondsten van vannacht staan hieronder alsnog, ongewijzigd zoals de nachtrun ze schreef.
31-08🔍 AUDIT — ⚠ theater: de dev-poort is te omzeilen met één percentteken, en de fix ligt al twee dagen ongemerged — Live gemeten op 31-08 tegen r4m-franky.fly.dev:
Oorzaak, één regel —
Waarom dit theater heet: de regel bestaat, staat in code, en draagt een commentaar met een auditverwijzing — hij houdt alleen niets tegen. Bescherming op papier, afwezig in werking.
Correctie op onszelf, en dit is het echte punt. De fix bestaat al:
Beslissing voor jou: mergen of expliciet afwijzen. Beide zijn goede antwoorden; alleen stilte houdt het gat open.
/dev.html geeft 404, maar /dev%2Ehtml geeft 200 en //dev.html geeft 200.Oorzaak, één regel —
src/app.ts:112 vergelijkt req.path als exacte string met "/dev.html", en staat vóór express.static. Express decodeert req.path niet, dus /dev%2Ehtml matcht niet; //dev.html is simpelweg een andere string. express.static normaliseert daarna wél en levert het bestand uit. Een poortwachter die op letters kijkt vóór een deur die op paden kijkt. /app.js lift mee op dezelfde regel.Waarom dit theater heet: de regel bestaat, staat in code, en draagt een commentaar met een auditverwijzing — hij houdt alleen niets tegen. Bescherming op papier, afwezig in werking.
Correctie op onszelf, en dit is het echte punt. De fix bestaat al:
voorstel/2026-08-29-dev-console-poort (commit 0f101c6, 29-08) draagt exact deze diagnose plus de fix en een nieuw testbestand. Vandaag is hij onafhankelijk opnieuw gevonden — wat niets nieuws bewijst behalve dat er niets mee gebeurd is. Er staan negen voorstel-takken open, nul gemerged (28-08 t/m 31-08), waaronder hosted-login-lek. De routine levert sneller dan er beoordeeld wordt, en dat maakt elk nieuw voorstel minder waard.Beslissing voor jou: mergen of expliciet afwijzen. Beide zijn goede antwoorden; alleen stilte houdt het gat open.
31-08🧪 TEST — engine 386 groen en voor het eerst NUL overgeslagen, na een test die zichzelf drie dagen uitzette — Gemeten vandaag op
Wat die twee overgeslagen tests waren. De kaartbodem — de regel die verhindert dat R4M op elke kaartbetaling van €2 verlies boekt (±€0,28 kosten tegen €0,16 marge). Twee van de vier asserties stonden achter
Herhaalbaar:
/Volumes/8TB MM4/Rails4Mankind, tak main, v0.36.7: npx tsc --noEmit schoon · npm test 63 bestanden, 386 geslaagd, 0 overgeslagen (basislijn vanmorgen: 383 geslaagd + 2 overgeslagen) · npm run demo volledig door met alle vijf grootboek-invarianten I1–I5 groen · /healthz 200, adapter usdc-base, base-sepolia.Wat die twee overgeslagen tests waren. De kaartbodem — de regel die verhindert dat R4M op elke kaartbetaling van €2 verlies boekt (±€0,28 kosten tegen €0,16 marge). Twee van de vier asserties stonden achter
it.skipIf(zonderSleutel), terwijl test/setup.ts de Stripe-sleutel hermetisch op leeg pint — bewust, zodat geen test ooit de echte Stripe-API raakt. Samen maakt dat de voorwaarde altijd waar: de handhaving van de bodem is sinds 28-08 nooit één keer uitgevoerd. Wat wél draaide was de rekensom dat de constante boven het break-evenpunt ligt — en dat bewijst dat een getal groot genoeg is, niet dat er iemand naar luistert.Herhaalbaar:
cd "/Volumes/8TB MM4/Rails4Mankind" && npm test31-08💡 VOORSTEL — kaartbodem-test draait weer echt (tak, alleen testcode, mutatietest bewijst dat hij niet leeg is) — Tak
Van 4 naar 5 draaiende tests: de rekensom · onder de bodem → 400 met de ketenweg als alternatief én nul Stripe-aanroepen · exact óp de bodem → 200 (de grens is inclusief) · één micro eronder → 400 · boven de bodem → bericht geparkeerd, niets afgeleverd vóór bevestiging.
Mutatietest gedaan: de bodem tijdelijk op 0 zetten laat de gedragsassertie falen — de test is dus niet leeg. Vóór deze wijziging zou dezelfde mutatie alleen de rekensom hebben geraakt. Bron daarna byte-identiek hersteld; de diff bevat uitsluitend het testbestand. Niets naar main, niets naar Fly.
voorstel/2026-08-31-kaartbodem-test-draait-echt, commit b98248f. Opgelost met het patroon dat de repo al gebruikt in stripepay.test.ts: de Stripe-SDK mocken en de sleutel op een nepwaarde zetten vóór de app importeert. Geen netwerk, geen echte sleutel. De mock levert bovendien een sterker bewijs dan de oude opzet kon geven: de weigering valt lokaal, want Stripe wordt geen enkele keer aangeroepen — het verschil tussen "wij weigeren dit" en "Stripe weigerde dit toevallig".Van 4 naar 5 draaiende tests: de rekensom · onder de bodem → 400 met de ketenweg als alternatief én nul Stripe-aanroepen · exact óp de bodem → 200 (de grens is inclusief) · één micro eronder → 400 · boven de bodem → bericht geparkeerd, niets afgeleverd vóór bevestiging.
Mutatietest gedaan: de bodem tijdelijk op 0 zetten laat de gedragsassertie falen — de test is dus niet leeg. Vóór deze wijziging zou dezelfde mutatie alleen de rekensom hebben geraakt. Bron daarna byte-identiek hersteld; de diff bevat uitsluitend het testbestand. Niets naar main, niets naar Fly.
31-08📊 SEO — 🚨 Niet pushen naar boombedrijf-bisschop-website: één push naar main vervangt de site van de klant door een BlackFuel-dashboard — Wat er is. De repo DS2036/boombedrijf-bisschop-website bouwt de site van Boombedrijf Bisschop niet. Zijn
Waarom dit nu op de radar staat. De workflow
Hoe het ontstond. Op 28-08 is de verdwenen workflow hersteld en tegelijk
Gedaan vandaag.
Wat jij moet beslissen. Of de echte bronbestanden van de live site komen in een repo, óf die workflow gaat uit. Tot dan blijft de site — met 22 clicks en 174 vertoningen in 28 dagen de best presterende klantsite van de vloot — onaanraakbaar voor elke automatische verbetering.
index.html is 647 bytes en draagt de titel “Black Fuel Whiskey | Admin Dashboard”; src/react-app is die dashboard-app. De live boombedrijfbisschop.be is iets heel anders: 74.020 bytes handgeschreven statische HTML met assets/hero.jpg, inline CSS en GSAP van cdnjs — nul Vite-bundles (grep “assets/index-” geeft 0 treffers) en de repo heeft geen assets/-map.Waarom dit nu op de radar staat. De workflow
.github/workflows/deploy.yml luistert op push: branches: [main] en zet ./dist/ via FTPS op server-dir: ./ — de webroot. Er is geen handmatige stap tussen. Eerstvolgende commit naar main = de website van een betalende klant weg, vervangen door andermans admin-dashboard. Dit is geen risico dat groeit, het is een schakelaar die aanstaat.Hoe het ontstond. Op 28-08 is de verdwenen workflow hersteld en tegelijk
fixbaar: true gezet. Wat niet gebeurde: de inhoud van de repo tegen de live site leggen. sites.yaml waarschuwt daar zelf letterlijk voor: “fixbaar: true zonder werkende deploy is een leugen die de routine laat stuklopen.” De pijplijn werkt hier prima — hij levert alleen het verkeerde af.Gedaan vandaag.
fixbaar: false in sites.yaml met de volledige reden, blok verplaatst naar “LIVE, MAAR NIET FIXBAAR”, event in de historiek. Niet gepusht, niet gedeployed. Meten loopt gewoon door (onsite 84, CWV mobiel 74, LCP 8,6 s — onveranderd).Wat jij moet beslissen. Of de echte bronbestanden van de live site komen in een repo, óf die workflow gaat uit. Tot dan blijft de site — met 22 clicks en 174 vertoningen in 28 dagen de best presterende klantsite van de vloot — onaanraakbaar voor elke automatische verbetering.
31-08📊 SEO — turbeau2rock.com zonder www is stuk over HTTPS: onsite 84 → 79 — Gemeten. Onsite-score van www.turbeau2rock.com zakte van 84 (30-08) naar 79 (31-08), door één nieuwe auto-fail:
Wat er precies mis is.
Waar het zit. Apex-DNS wijst naar 217.19.237.54 (Combell), www wijst naar turbeau2rock-doc.pages.dev (Cloudflare). De kapotte helft staat bij Combell, niet bij Cloudflare.
Waarom dit pijn doet. Moderne browsers proberen HTTPS eerst. Iedereen die turbeau2rock.com intikt zonder www krijgt een foutpagina — en dit is met 587 vertoningen en 21 clicks in 28 dagen het meest gezochte domein van de vloot, met “dj turbeau” op positie 8,3 en “turbeau bier” op 10,6. Precies de termen waar een paar plaatsen winst direct clicks oplevert.
Fix. Of de HTTPS-redirect bij Combell herstellen, of de apex ook naar Cloudflare Pages wijzen. Niet iets wat de routine zelf mag doen — dit is DNS/hosting. lowlands.business heeft hetzelfde patroon, daar geeft de apex HTTP 525.
hostvariant.Wat er precies mis is.
https://turbeau2rock.com/ geeft geen pagina. De TLS-handshake lukt nog wel — geldig Let’s Encrypt-certificaat, CN=turbeau2rock.com — maar daarna breekt de verbinding: over HTTP/2 “INTERNAL_ERROR (err 2)”, over HTTP/1.1 curl-code 000, en de audit-API meldt 502. De www-variant doet gewoon HTTP 200 in 0,15 s. Over poort 80 doet de apex nog wél netjes een 301 naar de www-variant. Alleen de HTTPS-listener is dus stuk.Waar het zit. Apex-DNS wijst naar 217.19.237.54 (Combell), www wijst naar turbeau2rock-doc.pages.dev (Cloudflare). De kapotte helft staat bij Combell, niet bij Cloudflare.
Waarom dit pijn doet. Moderne browsers proberen HTTPS eerst. Iedereen die turbeau2rock.com intikt zonder www krijgt een foutpagina — en dit is met 587 vertoningen en 21 clicks in 28 dagen het meest gezochte domein van de vloot, met “dj turbeau” op positie 8,3 en “turbeau bier” op 10,6. Precies de termen waar een paar plaatsen winst direct clicks oplevert.
Fix. Of de HTTPS-redirect bij Combell herstellen, of de apex ook naar Cloudflare Pages wijzen. Niet iets wat de routine zelf mag doen — dit is DNS/hosting. lowlands.business heeft hetzelfde patroon, daar geeft de apex HTTP 525.
30-08🚨 Base zet $100.000 per team op agent-betalingen en de deur sluit 9 september — het bord dacht al elf dagen dat dit programma nog niet bestond — Wat er is. Base Batches 004 staat open sinds 19-08-2026 en sluit op 09-09-2026. Letterlijk van base.org/batches: “Aug 19 Applications Open · Sep 9 Applications Closed · Sep 17 Acceptances Sent · Sep 21 – Nov 15 Virtual Program · Nov 17 Demo Day in New York” en “$100K investment from the Base Ecosystem Fund”. Base’ eigen aankondiging en drie media (cryptobriefing, Decrypt, KuCoin) noemen ~10 teams van elk $100K, met als doelgebieden AI-agents, payments, trading, financing en asset issuance.
Waarom dit de radar raakt en niet alleen het financieringsbord. Dit is geen algemene startersronde: de grootste L2 richt een hele lichting op agent-betalingen. Wat vorig jaar een randonderwerp was, is nu waar het kapitaal expliciet naartoe wordt gestuurd — dezelfde beweging als de HM-Treasury-consultatie hierboven, maar dan met geld in plaats van regelgeving. De toelatingsregel “Teams committed to Base as their default implementation and network of choice” is voor R4M geen belofte maar een feit: usdc-base is de standaard-afrekenplug van de motor, en eurc-base draait ernaast. De andere twee regels — “Pre-product to post-MVP teams that have not yet raised a formal Seed round” — passen ook.
Hoe dit gemist werd, en dat is de eigenlijke les. batches.base.org geeft een 301 naar base.org/batches. De routine bewaakte de oude URL, kreeg netjes een omleiding terug, en een omleiding is geen fout — dus er kwam nooit een alarm. Elf dagen stilte op de best passende regel van het hele bord. Dezelfde faalvorm als de acht weken die eerder op Circle verloren gingen. Een bewaakte URL die verhuist moet als wijziging gelezen worden, niet als succes.
Beslissing voor jou: aanvragen of niet, vóór 09-09. De demo day is fysiek in New York op 17-11 — dat is een reisbeslissing, geen toelatingsvoorwaarde.
Eerlijk: blog.base.org gaf mij 403. De investeringsvorm (SAFE, equity of iets anders), eventuele geografische beperkingen en of een solo-oprichter uitdrukkelijk toegelaten is, heb ik dus niet aan de bron kunnen lezen. Het oude bordveld beweerde “solo founders explicitly OK” — dat staat nu als onbevestigd. Voor een eenmanszaak is juist dát de vraag die de aanvraag maakt of breekt: open het formulier één keer zelf voor je begint.
Waarom dit de radar raakt en niet alleen het financieringsbord. Dit is geen algemene startersronde: de grootste L2 richt een hele lichting op agent-betalingen. Wat vorig jaar een randonderwerp was, is nu waar het kapitaal expliciet naartoe wordt gestuurd — dezelfde beweging als de HM-Treasury-consultatie hierboven, maar dan met geld in plaats van regelgeving. De toelatingsregel “Teams committed to Base as their default implementation and network of choice” is voor R4M geen belofte maar een feit: usdc-base is de standaard-afrekenplug van de motor, en eurc-base draait ernaast. De andere twee regels — “Pre-product to post-MVP teams that have not yet raised a formal Seed round” — passen ook.
Hoe dit gemist werd, en dat is de eigenlijke les. batches.base.org geeft een 301 naar base.org/batches. De routine bewaakte de oude URL, kreeg netjes een omleiding terug, en een omleiding is geen fout — dus er kwam nooit een alarm. Elf dagen stilte op de best passende regel van het hele bord. Dezelfde faalvorm als de acht weken die eerder op Circle verloren gingen. Een bewaakte URL die verhuist moet als wijziging gelezen worden, niet als succes.
Beslissing voor jou: aanvragen of niet, vóór 09-09. De demo day is fysiek in New York op 17-11 — dat is een reisbeslissing, geen toelatingsvoorwaarde.
Eerlijk: blog.base.org gaf mij 403. De investeringsvorm (SAFE, equity of iets anders), eventuele geografische beperkingen en of een solo-oprichter uitdrukkelijk toegelaten is, heb ik dus niet aan de bron kunnen lezen. Het oude bordveld beweerde “solo founders explicitly OK” — dat staat nu als onbevestigd. Voor een eenmanszaak is juist dát de vraag die de aanvraag maakt of breekt: open het formulier één keer zelf voor je begint.
30-08De robot-inkomstenmarkt bestaat al — maar als beleggersproduct, niet als mensenproduct. Dat is precies de scheidslijn waar R4M op staat — Wat er is. Robonnement laat robots geld verdienen en betaalt dat door aan de eigenaars: “Anyone can invest in and own a robot, or a part of its economic value” en “Robot Owners earn money from Robot’s Work”. Gebruikers betalen een abonnement — genoemd vanaf €3.000/maand — voor schilder- en schuurrobots bij 50+ klanten in Zwitserland en Duitsland; genoemd rendement 7,5%, eerste robot verkocht voor €120.000.
Waarom dit géén concurrent is, en toch belangrijk. Het toegangsbewijs is hier kapitaal: wie €120.000 heeft (of een fractie koopt) krijgt het robotinkomen. Bij R4M is het toegangsbewijs een geverifieerd mens — één mens, één aandeel, en de robot móét een menselijke eigenaar hebben in het register. Dat zijn twee tegenovergestelde antwoorden op dezelfde vraag: wie krijgt het geld dat een machine verdient? Het bestaan van dit platform bewijst dat de vraag markt heeft; het bewijst niet dat iemand ons antwoord al geeft.
Bruikbaar in een gesprek: als iemand zegt dat robotinkomen sciencefiction is, is dit het tegenbewijs — met prijzen erbij. Als iemand zegt dat het al bestaat, is dit het verschil: daar koop je je aandeel, hier bén je het.
Eerlijk: de pagina noemt “Cleaning Robots starting from Autumn 2024”, dus een deel van die tekst is oud; de genoemde 7,5% en de omzetcijfers komen van het bedrijf zelf en zijn door niemand onafhankelijk bevestigd. Geen verdeelsleutel of contractvoorwaarden gepubliceerd.
Waarom dit géén concurrent is, en toch belangrijk. Het toegangsbewijs is hier kapitaal: wie €120.000 heeft (of een fractie koopt) krijgt het robotinkomen. Bij R4M is het toegangsbewijs een geverifieerd mens — één mens, één aandeel, en de robot móét een menselijke eigenaar hebben in het register. Dat zijn twee tegenovergestelde antwoorden op dezelfde vraag: wie krijgt het geld dat een machine verdient? Het bestaan van dit platform bewijst dat de vraag markt heeft; het bewijst niet dat iemand ons antwoord al geeft.
Bruikbaar in een gesprek: als iemand zegt dat robotinkomen sciencefiction is, is dit het tegenbewijs — met prijzen erbij. Als iemand zegt dat het al bestaat, is dit het verschil: daar koop je je aandeel, hier bén je het.
Eerlijk: de pagina noemt “Cleaning Robots starting from Autumn 2024”, dus een deel van die tekst is oud; de genoemde 7,5% en de omzetcijfers komen van het bedrijf zelf en zijn door niemand onafhankelijk bevestigd. Geen verdeelsleutel of contractvoorwaarden gepubliceerd.
30-08🚨 De Britse schatkist stelt publiek exact jouw vraag, en het antwoord mag tot 6 oktober binnen — “HM Treasury” komt op de hele v2-site nul keer voor — Wat er is. Op 14-07-2026 publiceerde HM Treasury de consultatie “Modernising Payment Services Regulation”. Vraag 15 gaat over agentic payments en vraagt de sector hoe de regels voor toestemming, authenticatie en de aansprakelijkheid bij niet-geautoriseerde transacties aangepast moeten worden — letterlijk: dekt de toestemming de transactie die de agent koos, en wat gebeurt er als de agent buiten zijn opdracht gaat, en hoe verdeel je dan de verantwoordelijkheid tussen betaler, aanbieder en agent-leverancier (Bratby Law, analyse van de consultatie). De consultatie sluit op 06-10-2026 — dat is over 37 dagen. Dezelfde dag verscheen het Financial Services AI Adoption Plan, dat vaststelt dat het VK vandaag geen definitie van agent-identiteit kent, geen verificatie-eis en geen register van operatoren, waardoor door agents gestarte betalingen bij firma’s binnenkomen “with no verified identity, no registered accountability and no reliable way to distinguish a legitimate agent from an impersonator”, en dat vraagt om een agentic payments trust framework met juridische en aansprakelijkheidskaders, Know Your Agent-protocollen, en authenticatie- en governancestandaarden (Freshfields, 07-2026).
Wat r4m maX hierover al zegt — en wat hier nieuw aan is. maX kent Know Your Agent / KYA uitstekend: het staat in
🔌 Integratievorm — dit is er één zonder code: een consultatie-antwoord. Opzetpad: (1) draait al —
🧩 Productmix. V (verificatie) + C (controle), beschreven, niet verkocht. Meter: geen. Dit levert deze maand nul euro op en dat hoort ook zo — de opbrengst is een citeerbaar document met jouw naam erin, dat daarna in elk gesprek met Nele, Combell of een klant meegaat. Noem het in het dossier bij zijn juiste naam: positionering, geen omzet.
Zo zet je dit in de markt: na indiening is de zin niet meer “wij denken dat er een mens onder een agent hoort te staan” maar “wij hebben dat op verzoek van de Britse schatkist op papier gezet, in het dossier van hun betaalconsultatie.” Dat is dezelfde zin voor drie gesprekken: bij Nele als bewijs dat de aansprakelijkheidsvraag ook bij toezichthouders open ligt en niet alleen bij jou; bij Combell als bewijs dat je de standaardenkant volgt en niet je eigen ding bouwt; bij een klant als reden waarom hij niet te vroeg is.
Beslissing voor jou: antwoorden of niet, en zo ja, met welke naam eronder — de eenmanszaak of de vennootschap die er nog niet is. Dat laatste is precies zo’n punt dat eerst langs Nele moet, en de datum staat vast: 06-10-2026.
Eerlijk: ik heb de consultatietekst zelf niet bij gov.uk ingezien — het nummer van vraag 15, de formulering en de sluitingsdatum komen uit de analyse van Bratby Law en uit de Freshfields-blog. Vóór je iets indient, haal je het originele document één keer op en controleer je het vraagnummer.
Wat r4m maX hierover al zegt — en wat hier nieuw aan is. maX kent Know Your Agent / KYA uitstekend: het staat in
x401.html, x402.html, strategie.html, gtm-data.js, muc-voorstellen.js en cases-db.json. Het begrip is dus geen ontdekking. Wat er nul keer staat, gecontroleerd op de hele v2-site op 30-08-2026, is “HM Treasury”. Het nieuwe is dus niet het idee maar de deur: voor het eerst vraagt een regering het antwoord publiek op, met een sluitingsdatum, en iedereen mag antwoorden — geen vergunning, geen omzet, geen referentie vereist. Dat is voor een eenmanszaak de goedkoopste vorm van bestaan die er is. 🔌 Integratievorm — dit is er één zonder code: een consultatie-antwoord. Opzetpad: (1) draait al —
/api/attest en /api/gate zijn precies het mechanisme waar vraag 15 om vraagt, en de x401-gedachte (mens → getekend mandaat → agent) is de vorm van het antwoord; (2) Franky schrijft — een antwoord van drie tot vijf pagina’s op vraag 15, met één stelling: aansprakelijkheid kan pas verdeeld worden als er een aanwijsbare mens aan de wortel staat, en dat is een verificatie, geen registratie; 2–3 dagen, geen bouwwerk; (3) de “klant” — hier de overheid, die niets hoeft te doen behalve lezen; (4) standaard — verwijs naar OIDC/OpenID4VP en x401, nooit naar een eigen protocol (bouwregel f1 blijft overeind); (5) kleinste stap zonder toestemming van wie dan ook — indienen kan vandaag, want een consultatie is per definitie open. 🧩 Productmix. V (verificatie) + C (controle), beschreven, niet verkocht. Meter: geen. Dit levert deze maand nul euro op en dat hoort ook zo — de opbrengst is een citeerbaar document met jouw naam erin, dat daarna in elk gesprek met Nele, Combell of een klant meegaat. Noem het in het dossier bij zijn juiste naam: positionering, geen omzet.
Zo zet je dit in de markt: na indiening is de zin niet meer “wij denken dat er een mens onder een agent hoort te staan” maar “wij hebben dat op verzoek van de Britse schatkist op papier gezet, in het dossier van hun betaalconsultatie.” Dat is dezelfde zin voor drie gesprekken: bij Nele als bewijs dat de aansprakelijkheidsvraag ook bij toezichthouders open ligt en niet alleen bij jou; bij Combell als bewijs dat je de standaardenkant volgt en niet je eigen ding bouwt; bij een klant als reden waarom hij niet te vroeg is.
Beslissing voor jou: antwoorden of niet, en zo ja, met welke naam eronder — de eenmanszaak of de vennootschap die er nog niet is. Dat laatste is precies zo’n punt dat eerst langs Nele moet, en de datum staat vast: 06-10-2026.
Eerlijk: ik heb de consultatietekst zelf niet bij gov.uk ingezien — het nummer van vraag 15, de formulering en de sluitingsdatum komen uit de analyse van Bratby Law en uit de Freshfields-blog. Vóór je iets indient, haal je het originele document één keer op en controleer je het vraagnummer.
30-08🤝 Protocolwacht x401 — het enige protocol dat een geverifieerde mens aan de wortel zet, staat al twee maanden stil. Circle’s bindings-PR ligt er 67 dagen ongemerged bij — Wat er is, allemaal nagekeken bij de bron op 30-08-2026 via
En dit is het stuk dat telt. Twee inhoudelijke pull requests staan al twee maanden open. #17 “Add wallet-native Agent Identifiers and proof/payment binding” is geopend op 24-06-2026 door harshalbhangale-circle — een medewerker van Circle, de uitgever van USDC. Hij voegt een optioneel
Het contrast, in dezelfde periode. In x402-foundation/x402 liepen er in de zeven dagen tot 28-08 ruim vijfentwintig commits binnen: vier gedocumenteerde schema’s (
Wat r4m maX hierover al zegt. maX kent x401 goed —
🔌 Integratievorm — Vorm D (OIDC-knop), en één gratis zichtbaarheid. Opzetpad: (1) draait al — itsme/eID als IAL2-wortel plus
🧩 Productmix. V + C; meter M1 per nieuwe geverifieerde mens, M2 per raadpleging. M3 niet — hier stroomt geen geld. Licentie, trede 2.
Zo zet je dit in de markt: dit is goed nieuws, geen slecht. Tegen Nele en tegen elke klant die vraagt of je niet te laat bent: “Het enige protocol dat een geverifieerde mens aan de wortel van een agent-mandaat zet, heeft sinds 1 juli geen regel meer bewogen, terwijl de machinekant elke dag verzendt. De laag die wij bouwen is niet bezet — hij is onbemand.” En tegen een technische gesprekspartner: “Circle heeft in juni zelf voorgesteld om betaling aan agent-identiteit te binden. Die pull request ligt er 67 dagen later nog, met een merge-conflict. Dat is niet omdat het onbelangrijk is, maar omdat niemand eigenaar is van de vraag wie de mens erachter is.”
Beslissing voor jou: wil je zichtbaar zijn in die spec-discussie, ja of nee? Publiek commentaar onder een open PR is gratis en permanent vindbaar — maar het is ook publiek, en de nachtploeg plaatst niets namens jou.
api.github.com. De repo proof/x401 is aangemaakt op 07-05-2026; de spec landde op 22-06-2026 (“x401: HTTP Proof Requirement Protocol specification”). De laatste inhoudelijke wijziging aan de spec dateert van 27-06-2026 (#31, conformiteit met de credman-richting) en de laatste commit op main van 01-07-2026 (#33, een README-kop). Alles daarna is dependabot-ruis; de laatste push van 09-08-2026 is een dompurify-tak. De repo heeft 38 sterren, 4 forks, 11 open issues — en nul tags: er bestaat geen enkele versie-tag, ook geen v0.1.0. En dit is het stuk dat telt. Twee inhoudelijke pull requests staan al twee maanden open. #17 “Add wallet-native Agent Identifiers and proof/payment binding” is geopend op 24-06-2026 door harshalbhangale-circle — een medewerker van Circle, de uitgever van USDC. Hij voegt een optioneel
did:pkh:eip155:<chainId>:<address>-profiel toe en, belangrijker, proof/payment binding: bij routes die zówel x401-bewijs als een machinebetaling eisen moet de verifier de betaler-identiteit uit de niet-settlende verificatiestap halen, die naast de gebonden Agent Identifier leggen, en bij mismatch weigeren vóór settlement. Laatste beweging: 02-07-2026. Status vandaag: mergeable_state: dirty — het conflicteert en niemand ruimt het op. Daarnaast staat #32 (ToIP TRQP v2.0 als trusted_authorities-type) open sinds 27-06-2026. Het contrast, in dezelfde periode. In x402-foundation/x402 liepen er in de zeven dagen tot 28-08 ruim vijfentwintig commits binnen: vier gedocumenteerde schema’s (
exact, upto, auth-capture, batch-settlement), een auth-capture-client, en op 28-08 nog een Stellar-integratietest. Het Python-pakket staat op v2.21.0. De machinekant verzendt dagelijks; de menskant is sinds 1 juli niet meer aangeraakt. Wat r4m maX hierover al zegt. maX kent x401 goed —
x401.html beschrijft het protocol én de strategie, en de radar-entry van 29-08 legde de bron vast. Wat er niet staat is de stilstand, en de stilstand is het punt. Het dossier draagt “x401 v0.1.0, 25-06-2026” als versie; er is in de repo geen enkele tag die dat bevestigt — dat nummer komt uit de spec-tekst of de blog van Proof, niet uit een release. Zeg het dus met die herkomst erbij. 🔌 Integratievorm — Vorm D (OIDC-knop), en één gratis zichtbaarheid. Opzetpad: (1) draait al — itsme/eID als IAL2-wortel plus
/api/attest; (2) Franky doet — één commentaar onder PR #17, technisch en kort: de binding die Circle voorstelt legt agent naast betaler, maar niet naast één unieke mens; twee agents van dezelfde mens en één agent van twee mensen zijn in dit profiel niet te onderscheiden. Een halve dag, geen code; (3) niemand anders hoeft iets te doen — dat is precies waarom dit werkt; (4) standaard — x401 + OpenID4VP, geen eigen protocol; (5) kleinste demo — de bestaande test-link met de agent-poort erop. 🧩 Productmix. V + C; meter M1 per nieuwe geverifieerde mens, M2 per raadpleging. M3 niet — hier stroomt geen geld. Licentie, trede 2.
Zo zet je dit in de markt: dit is goed nieuws, geen slecht. Tegen Nele en tegen elke klant die vraagt of je niet te laat bent: “Het enige protocol dat een geverifieerde mens aan de wortel van een agent-mandaat zet, heeft sinds 1 juli geen regel meer bewogen, terwijl de machinekant elke dag verzendt. De laag die wij bouwen is niet bezet — hij is onbemand.” En tegen een technische gesprekspartner: “Circle heeft in juni zelf voorgesteld om betaling aan agent-identiteit te binden. Die pull request ligt er 67 dagen later nog, met een merge-conflict. Dat is niet omdat het onbelangrijk is, maar omdat niemand eigenaar is van de vraag wie de mens erachter is.”
Beslissing voor jou: wil je zichtbaar zijn in die spec-discussie, ja of nee? Publiek commentaar onder een open PR is gratis en permanent vindbaar — maar het is ook publiek, en de nachtploeg plaatst niets namens jou.
30-08🆔 Identificatie-case 1 — itsme legt vanaf Q1 2027 je gezicht naast de foto op je eID-kaart. Jouw M1-wortel wordt gratis sterker, en het staat zwart op wit bij de bron — Wat er is. Op 08-07-2026 stelden Febelfin en minister van Consumentenbescherming Rob Beenders een gezamenlijk actieplan tegen online fraude voor: 15 acties over drie niveaus (document 23 bladzijden, laatst opgeslagen 09-07-2026). Maatregel 3 van niveau 2 is itsme, en de tekst is ondubbelzinnig — ik citeer uit het plan zelf: “itsme® zal extra beveiligingslagen toevoegen … Alleen de echte gebruiker, van wie het gezicht overeenkomt met de foto op zijn of haar Belgische identiteitskaart, zal kunnen optreden als rekeninghouder. Dat creëërt een bijkomende beveiliging die fraudeurs niet kunnen omzeilen.” Beoogde timing: Q1 2027. De reden staat er ook bij, met een cijfer: in 2025 maakten fraudeurs in België 93 miljoen euro buit via phishing, al is het nettoverlies ongeveer 0,004% van het totale transactiebedrag.
Wat r4m maX hierover al zegt — en wat hier nieuw aan is. “Gezichtsherkenning” staat al op tien pagina’s van de v2-site en “Febelfin” op vier, dus het onderwerp is bekend. Nieuw, gecontroleerd op 30-08-2026: “Beenders” nul keer, “actieplan online fraude” nul keer. Het nieuwe is de datum en de bindende formulering: geen trend, maar een sectorafspraak met een kwartaal eraan.
Waarom dit jouw dossier rechtstreeks raakt. De sterkste tegenwerping tegen R4M was altijd: itsme bewijst een account, geen mens — een gestolen of uitgeleende itsme is nog altijd één account, twee mensen. Die tegenwerping blijft geldig tot Q1 2027 en verzwakt daarna structureel, zonder dat jij er een euro of een dag in steekt. Je M1-eenheid — een nieuwe mens via eID/itsme — erft de gezichtscheck van de wortel. Zeg dat eerlijk in twee tijden: vandaag bewijst R4M één eID-gebonden identiteit die niet dubbel kan bestaan op de rail; vanaf Q1 2027 zit er bij de wortel ook een gezicht tegen de kaartfoto. Nooit doen alsof het nu al zo is.
🔌 Integratievorm — Vorm D (OIDC-knop), ongewijzigd. Opzetpad: (1) draait al — de itsme/eID-koppeling en
🧩 Productmix. V (verificatie) is de kern, C erbij bij herhaald gebruik. Meter M1 per nieuwe mens — dit is precies de eenheid die de itsme-kost draagt, dus als itsme zijn activatie duurder maakt, raakt dat jouw M1-marge en niet je M2. Dat is een prijsvraag voor het verdienmodel, geen technische.
Zo zet je dit in de markt: tegen een afnemer die twijfelt of eID-verificatie “echt” genoeg is: “De Belgische banksector heeft in juli met de minister afgesproken dat vanaf begin 2027 alleen wie zijn gezicht naast de foto op zijn identiteitskaart legt, nog als rekeninghouder kan optreden. Wij hangen aan diezelfde wortel. U hoeft daar niets voor te bouwen — u erft het.”
Beslissing voor jou: of je de M1-prijs nu al afdekt tegen een mogelijke itsme-kostenstijging in Q1 2027.
Wat r4m maX hierover al zegt — en wat hier nieuw aan is. “Gezichtsherkenning” staat al op tien pagina’s van de v2-site en “Febelfin” op vier, dus het onderwerp is bekend. Nieuw, gecontroleerd op 30-08-2026: “Beenders” nul keer, “actieplan online fraude” nul keer. Het nieuwe is de datum en de bindende formulering: geen trend, maar een sectorafspraak met een kwartaal eraan.
Waarom dit jouw dossier rechtstreeks raakt. De sterkste tegenwerping tegen R4M was altijd: itsme bewijst een account, geen mens — een gestolen of uitgeleende itsme is nog altijd één account, twee mensen. Die tegenwerping blijft geldig tot Q1 2027 en verzwakt daarna structureel, zonder dat jij er een euro of een dag in steekt. Je M1-eenheid — een nieuwe mens via eID/itsme — erft de gezichtscheck van de wortel. Zeg dat eerlijk in twee tijden: vandaag bewijst R4M één eID-gebonden identiteit die niet dubbel kan bestaan op de rail; vanaf Q1 2027 zit er bij de wortel ook een gezicht tegen de kaartfoto. Nooit doen alsof het nu al zo is.
🔌 Integratievorm — Vorm D (OIDC-knop), ongewijzigd. Opzetpad: (1) draait al — de itsme/eID-koppeling en
/api/attest, er hoeft niets herbouwd; (2) Franky doet — één regel in de Verkoopkit en één in het Fundament die het onderscheid vandaag/Q1-2027 expliciet maakt: een halve dag schrijfwerk, geen code; (3) de klant — niets, hij erft het via itsme; (4) standaard — OIDC bovenop itsme, exact zoals nu; (5) kleinste demo — de bestaande itsme-flow, met de tijdlijn ernaast getoond. 🧩 Productmix. V (verificatie) is de kern, C erbij bij herhaald gebruik. Meter M1 per nieuwe mens — dit is precies de eenheid die de itsme-kost draagt, dus als itsme zijn activatie duurder maakt, raakt dat jouw M1-marge en niet je M2. Dat is een prijsvraag voor het verdienmodel, geen technische.
Zo zet je dit in de markt: tegen een afnemer die twijfelt of eID-verificatie “echt” genoeg is: “De Belgische banksector heeft in juli met de minister afgesproken dat vanaf begin 2027 alleen wie zijn gezicht naast de foto op zijn identiteitskaart legt, nog als rekeninghouder kan optreden. Wij hangen aan diezelfde wortel. U hoeft daar niets voor te bouwen — u erft het.”
Beslissing voor jou: of je de M1-prijs nu al afdekt tegen een mogelijke itsme-kostenstijging in Q1 2027.
verdienmodel.html is de enige waarheid over prijzen en de nachtploeg raakt die niet aan.30-08🆔 Identificatie-case 2 — de Belgische banken bouwen de geldezel-laag zelf, en Isabel bouwt hem. Alleen: hij kijkt achteraf, en jij kijkt vooraf — Wat er is. Maatregel 4 van hetzelfde Febelfin-actieplan (08-07-2026) is een platform voor het delen van fraudegegevens, en het plan noemt de bouwers bij naam: “de ontwikkeling van een platform voor het delen van fraudegegevens via Isabel en itsme®”. Scope, letterlijk: “Op korte termijn zal het platform gericht zijn op het delen van gegevens over geldezels. Op middellange en lange termijn is het de ambitie om de scope uit te breiden met signalen uit meerdere bronnen, zoals telecomgegevens, toestelgegevens en itsme®.” Beoogde timing volgens het plan: pilootfase Q1 2027. De naam van de implementatie is intussen bekend: TILDA, gebouwd door Isabel — gestandaardiseerde fraudetaxonomie, gedeeld onderzoek tussen instellingen, eerste toepassing geldezelrekeningen; de eerste financiële instellingen testen nu, met een productiepiloot voorzien tegen eind 2026 (ITdaily, 17-08-2026). Let op de tegenspraak en meld ze eerlijk: ITdaily zegt productiepiloot eind 2026, het Febelfin-plan zelf zegt pilootfase Q1 2027. Neem geen van beide als vaststaand aan.
Waarom dit het scherpste stuk van de nacht is voor jouw positie. Het plan zegt zelf waarom het bestaat: “Vandaag kunnen enkel banken die rechtstreeks betrokken zijn bij een fraudegeval bilateraal informatie uitwisselen, bijvoorbeeld over geldezels. Die informatie mag niet met een andere bank worden gedeeld.” Dat is een detectieprobleem tussen instellingen, en het antwoord is een signaalnetwerk dat een rekening achteraf als verdacht markeert. Jouw laag doet het omgekeerde: één mens bewijst één keer dat hij er precies één is, en dat bewijs geldt vooraf, bij elke afnemer, zonder dat iemand persoonsgegevens deelt. Een geldezel is per definitie een echt mens die zijn rekening uitleent — exact hetzelfde patroon als de accountverhuur bij gigwerkers uit de radar-entry van 29-08. TILDA vindt hem als het geld al bewogen heeft; een attest maakt de tweede rekening op naam van dezelfde mens zichtbaar vóórdat ze bestaat. Dat is geen concurrentie, dat is de trap ervoor — en dat is ook precies hoe je het moet zeggen, want banken zijn de sector die je onder
Wat r4m maX hierover al zegt. “Geldezel” staat in
🔌 Integratievorm — Vorm A (API-sleutel op hun backend), maar niet bij een bank. De
🧩 Productmix. V + C + G (gate) bij een afnemer die op het attest wil sluiten. Meter M1 per nieuwe mens en M2 per raadpleging — en M2 is hier de interessante, want een signaalnetwerk raadpleegt vaak en verifieert zelden. Licentie, trede 2. M3 niet: er stroomt geen geld over de rail, het V57-scharnier blijft heel.
🎯 Nieuw doelwit — zie ook de Doelwitten-lijst hieronder. Isabel Group (Brussel), bouwer van TILDA, ook al genoemd naast Signicat en itsme in de EUDI-case #197. Openingszin: “U bouwt TILDA om geldezels sneller te vinden nadat het geld bewoog, en uw eigen plan zegt dat u de scope wil uitbreiden met itsme-signalen. Wij zitten al aan die wortel, maar aan de andere kant van het moment: wij zeggen vóór de rekening opengaat of achter dit account dezelfde mens staat als achter een ander — met één pseudoniem en zonder één persoonsgegeven te delen. Dat is precies de juridische knoop waar uw plan om politieke steun en om de Gegevensbeschermingsautoriteit vraagt.”
Beslissing voor jou: Isabel is een deur én een mogelijke concurrent — wie de aansluiting bouwt, kan de vraag ook zelf gaan beantwoorden. Dat is dezelfde afweging als bij Combell. De nachtploeg maakt geen prospect aan; dat is jouw knop.
Waarom dit het scherpste stuk van de nacht is voor jouw positie. Het plan zegt zelf waarom het bestaat: “Vandaag kunnen enkel banken die rechtstreeks betrokken zijn bij een fraudegeval bilateraal informatie uitwisselen, bijvoorbeeld over geldezels. Die informatie mag niet met een andere bank worden gedeeld.” Dat is een detectieprobleem tussen instellingen, en het antwoord is een signaalnetwerk dat een rekening achteraf als verdacht markeert. Jouw laag doet het omgekeerde: één mens bewijst één keer dat hij er precies één is, en dat bewijs geldt vooraf, bij elke afnemer, zonder dat iemand persoonsgegevens deelt. Een geldezel is per definitie een echt mens die zijn rekening uitleent — exact hetzelfde patroon als de accountverhuur bij gigwerkers uit de radar-entry van 29-08. TILDA vindt hem als het geld al bewogen heeft; een attest maakt de tweede rekening op naam van dezelfde mens zichtbaar vóórdat ze bestaat. Dat is geen concurrentie, dat is de trap ervoor — en dat is ook precies hoe je het moet zeggen, want banken zijn de sector die je onder
nietDoen niet rechtstreeks als KYC-koper mag benaderen. Wat r4m maX hierover al zegt. “Geldezel” staat in
doorloop.html, index.html en cases-db.json. Nieuw op 30-08-2026: “TILDA” nul keer, “money mule” nul keer, “Beenders” nul keer. 🔌 Integratievorm — Vorm A (API-sleutel op hun backend), maar niet bij een bank. De
nietDoen-poort staat vast: gereguleerde banken kopen geen statutaire KYC bij een eenmanszaak, want AMLR eist een partij onder toezicht en DORA legt een leveranciersdrempel op. Verkoop dus niet aan de bank maar aan de toeleverancier: Isabel is géén gereguleerde bank maar een technologiebedrijf. Opzetpad: (1) draait al — /api/attest geeft precies één antwoord (uniek mens, ja of nee) zonder één persoonsgegeven door te geven, en dat is exact het probleem waar hun juristen tegenaan lopen; (2) Franky bouwt — niets nieuws; hoogstens een aansluitnotitie van twee bladzijden die het attest naast hun fraudetaxonomie legt: 1–2 dagen; (3) zij doen — één uitgaande call per onderzoek; (4) standaard — OIDC/itsme aan de wortel, geen eigen protocol; (5) kleinste demo zonder toestemming — twee accounts, dezelfde mens, één attest, twee keer hetzelfde pseudoniem terug: dat filmpje duurt veertig seconden. 🧩 Productmix. V + C + G (gate) bij een afnemer die op het attest wil sluiten. Meter M1 per nieuwe mens en M2 per raadpleging — en M2 is hier de interessante, want een signaalnetwerk raadpleegt vaak en verifieert zelden. Licentie, trede 2. M3 niet: er stroomt geen geld over de rail, het V57-scharnier blijft heel.
🎯 Nieuw doelwit — zie ook de Doelwitten-lijst hieronder. Isabel Group (Brussel), bouwer van TILDA, ook al genoemd naast Signicat en itsme in de EUDI-case #197. Openingszin: “U bouwt TILDA om geldezels sneller te vinden nadat het geld bewoog, en uw eigen plan zegt dat u de scope wil uitbreiden met itsme-signalen. Wij zitten al aan die wortel, maar aan de andere kant van het moment: wij zeggen vóór de rekening opengaat of achter dit account dezelfde mens staat als achter een ander — met één pseudoniem en zonder één persoonsgegeven te delen. Dat is precies de juridische knoop waar uw plan om politieke steun en om de Gegevensbeschermingsautoriteit vraagt.”
Beslissing voor jou: Isabel is een deur én een mogelijke concurrent — wie de aansluiting bouwt, kan de vraag ook zelf gaan beantwoorden. Dat is dezelfde afweging als bij Combell. De nachtploeg maakt geen prospect aan; dat is jouw knop.
30-08🤖 Agentic-lijn — het IMF schreef in april dat KYC vervangen moet worden door Know Your Agent. “IMF” komt op de hele v2-site nul keer voor — Wat er is. IMF Note 2026/004, “How Agentic AI Will Reshape Payments”, door Sonja Davidovic en Hervé Tourpe, gepubliceerd 24-04-2026. De kern: betaalsystemen zijn deterministisch gebouwd — vaste regels, rechtszekerheid, heldere aansprakelijkheid — terwijl agentic AI probabilistisch werkt en op machinesnelheid financiële handelingen kan starten. Het grootste risico dat de nota benoemt is precies dat: adaptieve systemen die onomkeerbare betalingen doen zonder controle of aansprakelijkheid. De nota stelt een drielagig raamwerk voor waarin AI wel mag vóórstellen maar de uitvoering regelgebonden, auditeerbaar en voorspelbaar blijft — in de samenvatting van één vakblad: het betaalsysteem moet “dom” blijven (PaymentExpert, 29-04-2026 · Fintech News Singapore). En de zin die voor jou telt: de nota stelt vast dat KYC en meervoudige authenticatie steunen op een expliciete menselijke handeling en daarom stukgaan zodra een agent handelt, en roept toezichthouders op te bewegen van Know Your Customer naar Know Your Agent, met verplichte verifieerbare identiteiten voor financiële bots, gekoppeld aan rechtspersonen.
Wat r4m maX hierover al zegt — en wat hier nieuw aan is. KYA staat overal in maX. Wat er nul keer staat, gecontroleerd 30-08-2026, is “IMF”. Het nieuwe is dus niet de gedachte maar de afzender: dit is niet een leverancier die zijn eigen product beschrijft, maar het Internationaal Monetair Fonds. Bij een advocaat, een bank of een overheid weegt die één bron zwaarder dan tien blogposts van identiteitsverkopers — en het is de eerste bron in het hele dossier die je in dat gezelschap zonder uitleg kunt neerleggen. Merk ook het verband met de rest van deze nacht op: het IMF benoemt de aansprakelijkheidsleemte in april, HM Treasury vraagt in juli publiek om de oplossing. Dat is dezelfde beweging, twee instanties, vier maanden uit elkaar.
🔌 Integratievorm — geen; dit is dossiermunitie. Opzetpad: (1) draait al — niets te bouwen; (2) Franky doet — één alinea in de Verkoopkit en één verwijzing in het juridisch bundel bij de agent-vragen: een uur; (3) niemand anders doet iets; (4) standaard — n.v.t.; (5) kleinste stap — de nota één keer zelf lezen vóór je hem citeert.
🧩 Productmix. Geen module, geen meter. Positionering, en dat hoort ook zo in het dossier te staan.
Zo zet je dit in de markt: vervang in elke pitch de zin “wij denken dat KYC niet werkt voor agents” door “het IMF schreef in april 2026 dat KYC en tweefactor stukgaan zodra een agent handelt, omdat ze allebei op een menselijke handeling steunen, en riep toezichthouders op naar Know Your Agent te bewegen. Wij zetten daar de vraag naast die zij openlaten: is die mens er precies één?”
Eerlijk — en dit hoort in de claimdiscipline: ik heb de nota niet primair kunnen inzien. Zowel imf.org als de e-library gaven HTTP 403. Titel, nummer, auteurs en datum zijn consistent over meerdere onafhankelijke bronnen, maar de KYC-naar-KYA-formulering komt uit samenvattingen, niet uit de brontekst. Citeer hem pas woordelijk nadat je de PDF zelf hebt gelezen — met een instantie als deze is één verkeerd geciteerde zin duurder dan de hele vondst waard is.
Wat r4m maX hierover al zegt — en wat hier nieuw aan is. KYA staat overal in maX. Wat er nul keer staat, gecontroleerd 30-08-2026, is “IMF”. Het nieuwe is dus niet de gedachte maar de afzender: dit is niet een leverancier die zijn eigen product beschrijft, maar het Internationaal Monetair Fonds. Bij een advocaat, een bank of een overheid weegt die één bron zwaarder dan tien blogposts van identiteitsverkopers — en het is de eerste bron in het hele dossier die je in dat gezelschap zonder uitleg kunt neerleggen. Merk ook het verband met de rest van deze nacht op: het IMF benoemt de aansprakelijkheidsleemte in april, HM Treasury vraagt in juli publiek om de oplossing. Dat is dezelfde beweging, twee instanties, vier maanden uit elkaar.
🔌 Integratievorm — geen; dit is dossiermunitie. Opzetpad: (1) draait al — niets te bouwen; (2) Franky doet — één alinea in de Verkoopkit en één verwijzing in het juridisch bundel bij de agent-vragen: een uur; (3) niemand anders doet iets; (4) standaard — n.v.t.; (5) kleinste stap — de nota één keer zelf lezen vóór je hem citeert.
🧩 Productmix. Geen module, geen meter. Positionering, en dat hoort ook zo in het dossier te staan.
Zo zet je dit in de markt: vervang in elke pitch de zin “wij denken dat KYC niet werkt voor agents” door “het IMF schreef in april 2026 dat KYC en tweefactor stukgaan zodra een agent handelt, omdat ze allebei op een menselijke handeling steunen, en riep toezichthouders op naar Know Your Agent te bewegen. Wij zetten daar de vraag naast die zij openlaten: is die mens er precies één?”
Eerlijk — en dit hoort in de claimdiscipline: ik heb de nota niet primair kunnen inzien. Zowel imf.org als de e-library gaven HTTP 403. Titel, nummer, auteurs en datum zijn consistent over meerdere onafhankelijke bronnen, maar de KYC-naar-KYA-formulering komt uit samenvattingen, niet uit de brontekst. Citeer hem pas woordelijk nadat je de PDF zelf hebt gelezen — met een instantie als deze is één verkeerd geciteerde zin duurder dan de hele vondst waard is.
30-08📋 Stand van de sporen deze nacht — wat leeg bleef, en waarom dat zo opgeschreven staat — 💸 x402 — protocollen ongewijzigd, gecontroleerd bij de bron. In x402-foundation/x402 is er sinds 28-08-2026 08:59 UTC één commit binnengelopen (
💶 Geld-case — niets gevonden dat de moeite is, en dit is de reden. Ik heb gezocht op verse, gedateerde bedrijfsgebeurtenissen rond uitbetaling aan geverifieerde begunstigden (levensverzekering onder Wwft, onvindbare begunstigden bij het Verbond van Verzekeraars, dubbele-account- en bonusfraude). Wat terugkwam waren leveranciersblogs zonder datum of bedrag en algemene procedurepagina’s — niets dat de bronregel haalt. Geen geld-case dus, in plaats van een opgevulde. De staande geld-deur blijft die uit het x402-watch-rapport van 29-08 (Moventem / burgerberaad Zuid-Holland, eerste zitting 19-09), en die staat al in
📡 IoT — ongewijzigd sinds gisteren. De EU-Data Act blijft de klok: vanaf 12-09-2026 moeten nieuwe verbonden producten zo ontworpen zijn dat de gebruiker zijn data rechtstreeks, veilig en gratis kan krijgen, in een gestructureerd machineleesbaar formaat, “where relevant and technically feasible” (Wilson Sonsini · DIHK). Dat is dezelfde deadline als de radar-entry van 29-08; er is deze nacht geen nieuw feit bijgekomen. Geen herhaling dus, alleen deze regel.
📬 Secure Mail — niet aan de beurt. Spoor G is wekelijks en draait op maandag; vandaag is zondag 30-08-2026. Volgende toets: 31-08-2026.
⚡ Nieuw toepassingsgebied — geen. Ik heb niets gevonden dat échte, integreerbare grond is en niet al in de catalogus staat. Wat vanavond het dichtst kwam — leeftijdsverificatie via de EU-“mini-wallet” — stuitte op de maX-bril:
🔄 Doorloop-versterking (spoor F) — niets toegevoegd. Er zijn sinds gisteren geen nieuwe cases of juridische vragen bijgekomen die het doorloop-verhaal raken en er nog niet in staan. De vondsten van vannacht zijn radar-materiaal en géén bestaande copy die herschreven moet worden — en de nachtploeg herschrijft niets.
✅ De vragenlus stond leeg, en dat is nieuws.
e398a9e, uitzetten van spend controls in een Stellar-integratietest) en geen enkele wijziging aan specs/ of docs/. Vier gedocumenteerde schema’s, ongewijzigd: exact, upto, auth-capture, batch-settlement. Geen nieuwe tag boven pypi-x402@v2.21.0. De auth-capture-vondst van 29-08 blijft dus de laatste beweging. Dit is een geldige uitkomst, geen leeg spoor. Ter controle op onszelf: ik dacht in upto een onbekend schema te hebben gevonden — het staat al als bouwblok v2-upto in cases-db.json, toegevoegd 28-08. De maX-bril heeft dat gevangen vóór het hier als “nieuw” stond. 💶 Geld-case — niets gevonden dat de moeite is, en dit is de reden. Ik heb gezocht op verse, gedateerde bedrijfsgebeurtenissen rond uitbetaling aan geverifieerde begunstigden (levensverzekering onder Wwft, onvindbare begunstigden bij het Verbond van Verzekeraars, dubbele-account- en bonusfraude). Wat terugkwam waren leveranciersblogs zonder datum of bedrag en algemene procedurepagina’s — niets dat de bronregel haalt. Geen geld-case dus, in plaats van een opgevulde. De staande geld-deur blijft die uit het x402-watch-rapport van 29-08 (Moventem / burgerberaad Zuid-Holland, eerste zitting 19-09), en die staat al in
cases-db.json — ik voer hem niet opnieuw op als nieuw. 📡 IoT — ongewijzigd sinds gisteren. De EU-Data Act blijft de klok: vanaf 12-09-2026 moeten nieuwe verbonden producten zo ontworpen zijn dat de gebruiker zijn data rechtstreeks, veilig en gratis kan krijgen, in een gestructureerd machineleesbaar formaat, “where relevant and technically feasible” (Wilson Sonsini · DIHK). Dat is dezelfde deadline als de radar-entry van 29-08; er is deze nacht geen nieuw feit bijgekomen. Geen herhaling dus, alleen deze regel.
📬 Secure Mail — niet aan de beurt. Spoor G is wekelijks en draait op maandag; vandaag is zondag 30-08-2026. Volgende toets: 31-08-2026.
⚡ Nieuw toepassingsgebied — geen. Ik heb niets gevonden dat échte, integreerbare grond is en niet al in de catalogus staat. Wat vanavond het dichtst kwam — leeftijdsverificatie via de EU-“mini-wallet” — stuitte op de maX-bril:
leeftijdscontrole staat al op elf pagina’s, en de aanbesteding die ik ervoor natrok bleek uit oktober 2024 te dateren. Geen nieuw gebied, dus geen kaart. 🔄 Doorloop-versterking (spoor F) — niets toegevoegd. Er zijn sinds gisteren geen nieuwe cases of juridische vragen bijgekomen die het doorloop-verhaal raken en er nog niet in staan. De vondsten van vannacht zijn radar-materiaal en géén bestaande copy die herschreven moet worden — en de nachtploeg herschrijft niets.
✅ De vragenlus stond leeg, en dat is nieuws.
/api/doorloop telt 43 vragen, waarvan nul open: 28 uitgevoerd, 11 beantwoord, 2 afgevinkt, 2 afgevoerd. De zeven vragen die op 28-08 wekenlang stillagen, zijn weg. Er ligt niets te wachten.29-08🔍 Concurrent-controle afgerond: TransUnion trekt het accountverhuur-gat NIET dicht — het verkoopt detectie, geen uniciteit — De vraag die openstond. Op 29-08 om 01:00 landde het cijfer dat onder de uniciteits-pitch hoort: TransUnion meet dat 31% van de millennial- en Gen-Z-gigwerkers hun geverifieerde platformaccount verhuurt aan iemand die zichzelf niet kon verifiëren, 1 op 4 over alle leeftijden (TransUnion-newsroom, 15-01-2026). Daarbij stond één expliciete vraag open, en het was de gevaarlijkste: trekt TransUnion dat gat zelf dicht? Zij hebben het rapport, de gigplatform-relaties en de distributie — als zij dit oplossen, staat er een echte concurrent op onze M2-meter.
Het antwoord: nee, niet met uniciteit. Wat TransUnion naast dat rapport aanbiedt is identiteitsverificatie plus device intelligence: Device Risk herkent apparaat, context en gedrag en scheidt verdachte van vertrouwde interacties in real time (Help Net Security, 16-01-2026). Dat is signaal-detectie. Het vraagt “ziet deze sessie er verdacht uit?”, niet “is dit nog steeds dezelfde mens?”. Een verhuurder die zijn eigen telefoon meegeeft, of een huurder die consequent hetzelfde toestel gebruikt, is voor een device-signaal een trouwe gebruiker.
Waarom dit de these hard maakt in plaats van alleen aannemelijk. Er staan nu drie onafhankelijke partijen met exact dezelfde blinde vlek naast elkaar: Figure Index dedupliceert op embedding-gelijkenis van vídeo’s; de klassieke onboarding-screening wás niet omzeild maar irrelevant geworden (het account is écht geverifieerd, er zit alleen een andere mens achter); en TransUnion kijkt naar apparaten. Drie keer detectie, drie keer een tredmolen die elke modelgeneratie opnieuw gewonnen moet worden en die schaalt door bemonstering. eID-gewortelde uniciteit is de uitgang, en die schaalt door constructie.
🔌 Integratievorm — Vorm A (API-sleutel op hun backend), naast wat er staat, niet in de plaats van. Opzetpad: (1) draait al — de itsme/eID-binding en de herhaalde attestatie-oproep via
🧩 Productmix. V (verificatie) + C (controle/attestatie); de rail doet níét mee — dit is de attestatiekant alleen. M2 is de lopende meter (raadpleging per gebonden mens), M1 alleen bij de eerste binding. Trede 1, groeipad naar trede 2 zodra het platform de poort in zijn uitbetaalstroom zet in plaats van alleen bij shift-start.
Zo zet je dit in de markt: niet tégen TransUnion, naast hen. Openingszin: “U meet zelf dat één op drie jonge gigwerkers zijn account uitleent. Uw device-signaal ziet dat niet — het toestel is hetzelfde, alleen de mens erachter niet. Wij beantwoorden precies die ene vraag, per oproep, zonder dat u een naam van ons krijgt.”
⚠️ Eerlijk erbij, twee dingen. (1) Dit is goed nieuws over een lege plek, en lege plekken blijven niet leeg: zodra TransUnion een eID- of hergebruikbare-identiteitslaag naast Device Risk zet, staat de concurrent er wél. Blijft op de radar. (2) Nog steeds onbekend, ondanks gericht zoeken: wat een platform vandaag betaalt per her-verificatie. Geen publieke tarieven gevonden. Zonder dat getal is onze M2-prijs een aanname en geen anker — niet als feit verkopen.
Het antwoord: nee, niet met uniciteit. Wat TransUnion naast dat rapport aanbiedt is identiteitsverificatie plus device intelligence: Device Risk herkent apparaat, context en gedrag en scheidt verdachte van vertrouwde interacties in real time (Help Net Security, 16-01-2026). Dat is signaal-detectie. Het vraagt “ziet deze sessie er verdacht uit?”, niet “is dit nog steeds dezelfde mens?”. Een verhuurder die zijn eigen telefoon meegeeft, of een huurder die consequent hetzelfde toestel gebruikt, is voor een device-signaal een trouwe gebruiker.
Waarom dit de these hard maakt in plaats van alleen aannemelijk. Er staan nu drie onafhankelijke partijen met exact dezelfde blinde vlek naast elkaar: Figure Index dedupliceert op embedding-gelijkenis van vídeo’s; de klassieke onboarding-screening wás niet omzeild maar irrelevant geworden (het account is écht geverifieerd, er zit alleen een andere mens achter); en TransUnion kijkt naar apparaten. Drie keer detectie, drie keer een tredmolen die elke modelgeneratie opnieuw gewonnen moet worden en die schaalt door bemonstering. eID-gewortelde uniciteit is de uitgang, en die schaalt door constructie.
🔌 Integratievorm — Vorm A (API-sleutel op hun backend), naast wat er staat, niet in de plaats van. Opzetpad: (1) draait al — de itsme/eID-binding en de herhaalde attestatie-oproep via
/api/gate/check; (2) Franky bouwt — niets nieuws voor een pilot; (3) de klant — roept bij elke shift-start of uitbetaling één keer de poort aan naast zijn bestaande device-check; (4) standaard — eIDAS-gewortelde attestatie; (5) kleinste demo zonder toestemming van de klant — twee sessies op hetzelfde toestel met verschillende mensen erachter: het device-signaal blijft groen, de attestatie-oproep niet. 🧩 Productmix. V (verificatie) + C (controle/attestatie); de rail doet níét mee — dit is de attestatiekant alleen. M2 is de lopende meter (raadpleging per gebonden mens), M1 alleen bij de eerste binding. Trede 1, groeipad naar trede 2 zodra het platform de poort in zijn uitbetaalstroom zet in plaats van alleen bij shift-start.
Zo zet je dit in de markt: niet tégen TransUnion, naast hen. Openingszin: “U meet zelf dat één op drie jonge gigwerkers zijn account uitleent. Uw device-signaal ziet dat niet — het toestel is hetzelfde, alleen de mens erachter niet. Wij beantwoorden precies die ene vraag, per oproep, zonder dat u een naam van ons krijgt.”
⚠️ Eerlijk erbij, twee dingen. (1) Dit is goed nieuws over een lege plek, en lege plekken blijven niet leeg: zodra TransUnion een eID- of hergebruikbare-identiteitslaag naast Device Risk zet, staat de concurrent er wél. Blijft op de radar. (2) Nog steeds onbekend, ondanks gericht zoeken: wat een platform vandaag betaalt per her-verificatie. Geen publieke tarieven gevonden. Zonder dat getal is onze M2-prijs een aanname en geen anker — niet als feit verkopen.
29-08🚨 Protocolwacht x402 — de terugknop bestaat sinds 25 augustus. Ons eigen dossier zegt vier dagen later nog altijd dat een stablecoin-betaling onomkeerbaar is — Wat er gebeurd is. Op 25-08-2026 om 15:43 UTC werd in de officiële spec-repo PR #3197 “Auth-capture spec update: v1.1” samengevoegd; de client-kant volgde op 27-08 met #3283. De spec staat in specs/schemes/auth-capture/ (nagelezen bij de bron op 29-08-2026). Het schema
Wat r4m maX hierover al zegt — en waar het misgaat. maX kent x402 op V2, en dat klópt nog: de hoofdspec staat op v2, er is geen v3. Maar de schemelaag eronder bewoog, en het woord “auth-capture” komt in de hele v2-site nul keer voor (gecontroleerd 29-08). Erger: HV7 (dream-vondst van 26-08-2026 07:15, staat in
Wat het écht betekent — en waarom de pitch hierdoor sterker wordt, niet zwakker. De terugknop beschermt tegen niet-leveren, niet tegen de verkeerde ontvanger.
🔌 Integratievorm — Vorm J (x402-resource), met een nieuw scharnier. Wij hangen de payee-attestcontrole tussen
🧩 Productmix. V (verificatie) + C (controle) + P (payout-haak). Meter M2 loopt op de attestatie-oproep vóór de capture — dat is het stuk dat je nú mag verkopen. M3 pas wanneer de settlement over onze rail loopt, en dus na PRIO B. Het V57-scharnier blijft heel: bij
Zo zet je dit in de markt: zeg de correctie zélf, vóór een klant of Nele hem zegt. Bij een facilitator-bouwer of een x402-integrator: “Sinds 25 augustus heeft x402 een void en een refund. Wat het niet heeft, is een reden om te voidden — het protocol weet niet wie de ontvanger is. Uw netwerkbinding moet sowieso authenticeren dat een capture van de server komt; wij zetten daar één vraag naast die vandaag niemand beantwoordt: staat achter dit ontvangstadres nog dezelfde geverifieerde mens als bij de authorize?”
Beslissing voor jou: HV7 in
auth-capture geeft een x402-betaling een levenscyclus: authorize (hold), capture (uitbetalen, mag deels en herhaald), void (hold vrijgeven), refund (na afloop terugbetalen) en reclaim (de client haalt zijn eigen hold terug na de deadline). escrow is de standaard; extra.autoCapture is verdwenen, extra.paymentFlow is de enige keuzeschakelaar. En één regel raakt ons rechtstreeks — “Server consent”: elke netwerkbinding MOET authenticeren dat een door de facilitator doorgegeven capture, void of refund écht van de resource server komt. Wat r4m maX hierover al zegt — en waar het misgaat. maX kent x402 op V2, en dat klópt nog: de hoofdspec staat op v2, er is geen v3. Maar de schemelaag eronder bewoog, en het woord “auth-capture” komt in de hele v2-site nul keer voor (gecontroleerd 29-08). Erger: HV7 (dream-vondst van 26-08-2026 07:15, staat in
cases-db.json) draagt de titel “De digitale werknemer betaalt de spookleverancier — instant, onomkeerbaar” en zegt letterlijk dat een stablecoin-betaling “definitief is zodra ze vertrekt”. Die zin werd geschreven één dag ná de merge die er een void, een refund en een reclaim in zette. Achterstand: 4 dagen. Dit is precies waarom de protocolwacht bestaat. Wat het écht betekent — en waarom de pitch hierdoor sterker wordt, niet zwakker. De terugknop beschermt tegen niet-leveren, niet tegen de verkeerde ontvanger.
refund stuurt geld terug naar de client en reclaim haalt een onaangeroerde hold terug — allebei bewegingen tússen dezelfde twee partijen. Een betaling die de agent correct autoriseerde aan een spookleverancier die er echt uitzag, wordt gewoon gecaptured en komt nooit terug. De wig verschuift dus van “het geld kan niet terug” naar “het protocol weet niet aan wie het betaalt”. Dat is een hardere zin, want hij overleeft de eerste tegenwerping. 🔌 Integratievorm — Vorm J (x402-resource), met een nieuw scharnier. Wij hangen de payee-attestcontrole tussen
authorize en capture. Opzetpad: (1) draait al — ons x402-endpoint op testnet plus /api/attest en /api/gate; (2) Franky bouwt — een paymentFlow: escrow-variant die na de hold de ontvangst-hash tegen het attest legt en bij mismatch void stuurt in plaats van capture: 3–5 dagen bovenop de bestaande paywall; (3) de klant — zet één veld om (extra.paymentFlow) en verandert verder niets; (4) standaard — x402 auth-capture v1.1, geen eigen protocol (bouwregel f1 blijft overeind); (5) kleinste demo zonder toestemming van wie dan ook — één eigen resource waar dezelfde betaling twee keer loopt: met kloppend payee-attest volgt capture, met een gewisseld ontvangstadres volgt void, allebei zichtbaar in hetzelfde logboek. Dat filmpje is de pitch. 🧩 Productmix. V (verificatie) + C (controle) + P (payout-haak). Meter M2 loopt op de attestatie-oproep vóór de capture — dat is het stuk dat je nú mag verkopen. M3 pas wanneer de settlement over onze rail loopt, en dus na PRIO B. Het V57-scharnier blijft heel: bij
void raakt R4M het geld niet aan, het zégt alleen dat er niet gecaptured mag worden. Zo zet je dit in de markt: zeg de correctie zélf, vóór een klant of Nele hem zegt. Bij een facilitator-bouwer of een x402-integrator: “Sinds 25 augustus heeft x402 een void en een refund. Wat het niet heeft, is een reden om te voidden — het protocol weet niet wie de ontvanger is. Uw netwerkbinding moet sowieso authenticeren dat een capture van de server komt; wij zetten daar één vraag naast die vandaag niemand beantwoordt: staat achter dit ontvangstadres nog dezelfde geverifieerde mens als bij de authorize?”
Beslissing voor jou: HV7 in
cases-db.json draagt nog het woord “onomkeerbaar”. De nachtploeg herschrijft geen bestaande copy — dat is jouw knop.29-08🤝 Protocolwacht x401 — de bron staat vanaf vannacht vast (github.com/proof/x401), de spec staat sinds 1 juli stil, en Google, OpenAI en Okta's FIDO-mensen zaten aan tafel — Wat r4m maX hierover al zegt. x401.html noemt x401 al weken correct “een open protocol van het Amerikaanse identiteitsbedrijf Proof, mee onderschreven door Circle, met een gecureerde lijst van bewijs-uitgevers”, en zet R4M op de nog lege stoel van de eerste uitgever die op Europese overheids-identiteit steunt. Dát is dus geen ontdekking. Het nieuwe is dat de bron nu vastligt, plus drie feiten die er niet stonden.
De bron, vastgelegd (nagekeken via de GitHub-API op 29-08-2026). github.com/proof/x401 — Apache-2.0, aangemaakt 07-05-2026, 38 sterren. Eerste spec-commit 22-06-2026: “x401: HTTP Proof Requirement Protocol specification”. Zusterrepo proof/x401-node, laatst geraakt 18-08-2026. Vanaf nu volgt de protocolwacht deze twee elke nacht, net als x402 — dat was tot vannacht een gat in de routine.
Feit 1 — de spec staat stil. Laatste inhoudelijke wijziging 01-07-2026 (#33, README-koppen gelijkzetten met de spec). Geen tags, geen versienummers, bijna twee maanden geen beweging. Dat is goed nieuws: de stoel die wij willen, schuift niet weg terwijl wij bouwen.
Feit 2 — wie er aan tafel zat. Commit
Feit 3 — de richting, en dit verandert ons opzetpad. Commit
🔌 Integratievorm — het gewicht verschuift. Van Vorm A (API-sleutel op hun backend) naar Vorm E (OIDC-/browser-knop). Opzetpad: (1) lees de spec in
🧩 Productmix. V + C. Meter M1 bij de eerste binding (itsme/eID, draagt de kost), M2 bij elke latere controle (≈ gratis). Geen geldstroom, dus trede 2 en nú als licentie verkoopbaar — geen PRIO B nodig.
Zo zet je dit in de markt: bij Nele is dit de zin die de x401-lijn onderbouwt zonder één claim te veel: “Het is een open protocol met een publieke spec onder Apache-licentie, de uitgeverslijst is open, en er staat nog geen enkele uitgever op die op een Europese overheids-identiteit steunt.” Bij Combell/hosters is de credman-vondst het argument: als de presentatie browser-native wordt, is inbouwen een snippet, geen integratieproject — en dat is precies wat een hoster aan duizenden sites tegelijk kan verkopen.
Eerlijk: het aantal sterren (38) is klein. Verkoop x401 dus niet als “de standaard”, maar als “de spec waar Google, OpenAI en Okta's FIDO-mensen wijzigingen in vroegen” — dat is nakijkbaar en het is genoeg.
De bron, vastgelegd (nagekeken via de GitHub-API op 29-08-2026). github.com/proof/x401 — Apache-2.0, aangemaakt 07-05-2026, 38 sterren. Eerste spec-commit 22-06-2026: “x401: HTTP Proof Requirement Protocol specification”. Zusterrepo proof/x401-node, laatst geraakt 18-08-2026. Vanaf nu volgt de protocolwacht deze twee elke nacht, net als x402 — dat was tot vannacht een gat in de routine.
Feit 1 — de spec staat stil. Laatste inhoudelijke wijziging 01-07-2026 (#33, README-koppen gelijkzetten met de spec). Geen tags, geen versienummers, bijna twee maanden geen beweging. Dat is goed nieuws: de stoel die wij willen, schuift niet weg terwijl wij bouwen.
Feit 2 — wie er aan tafel zat. Commit
2c7a370 van 23-06-2026: “Updated spec with changes requested from Google, OpenAI, and Okta's FIDO reps.” Dat is een zwaardere kring dan “mee onderschreven door Circle”, en het staat nergens in maX. Feit 3 — de richting, en dit verandert ons opzetpad. Commit
3f73cf9 van 27-06-2026: “conformance with credman direction.” De spec wordt gelijkgezet met de Credential Management-richting: presentatie van een bewijs gebeurt dan browser-native, niet via een API-aanroep op de backend van de afnemer. Dezelfde beweging als de EUDI-wallet. 🔌 Integratievorm — het gewicht verschuift. Van Vorm A (API-sleutel op hun backend) naar Vorm E (OIDC-/browser-knop). Opzetpad: (1) lees de spec in
proof/x401 en leg onze uitgeversvorm ernaast; (2) Franky bouwt het al lang geplande r4m-x401-proto (blok D1) tegen déze repo in plaats van tegen een eigen bedenksel — 3–5 dagen; (3) de klant zet een knop, geen project; (4) standaard x401 + Credential Management; (5) kleinste demo één eigen pagina die een x401-challenge stelt en ons attest presenteert. 🧩 Productmix. V + C. Meter M1 bij de eerste binding (itsme/eID, draagt de kost), M2 bij elke latere controle (≈ gratis). Geen geldstroom, dus trede 2 en nú als licentie verkoopbaar — geen PRIO B nodig.
Zo zet je dit in de markt: bij Nele is dit de zin die de x401-lijn onderbouwt zonder één claim te veel: “Het is een open protocol met een publieke spec onder Apache-licentie, de uitgeverslijst is open, en er staat nog geen enkele uitgever op die op een Europese overheids-identiteit steunt.” Bij Combell/hosters is de credman-vondst het argument: als de presentatie browser-native wordt, is inbouwen een snippet, geen integratieproject — en dat is precies wat een hoster aan duizenden sites tegelijk kan verkopen.
Eerlijk: het aantal sterren (38) is klein. Verkoop x401 dus niet als “de standaard”, maar als “de spec waar Google, OpenAI en Okta's FIDO-mensen wijzigingen in vroegen” — dat is nakijkbaar en het is genoeg.
29-08📡 IoT-lijn — over veertien dagen moet elk nieuw verbonden product zijn data zélf afgeven, en de wetenschap zegt nu dat juist dát pad de zwakste identiteitscontrole heeft — Wat r4m maX hierover al zegt. Case 93 staat er, met de juiste datum (12-09-2026) en met de juiste nuance: overweging 29 van de datawet zegt dat de datahouder passende identificatie mag vragen — “Mag. Niet moet, en niet hoe.” Het nieuwe is een academische bron die dat “mag” omdraait naar een “moet”, langs de achterdeur van de AVG.
De bron. Pieter Wolters & Yong Yong Hu (Radboud Universiteit Nijmegen), “Authentication and authorisation and the access of the user in the Data Act”, Computer Law & Security Review, online 12-03-2026 (open access ook via de Radboud-repository). Onderzoeksvraag, letterlijk: in welke mate eist de Data Act authenticatie en autorisatie om onbevoegde toegang tot de persoonsgegevens van ánderen te voorkomen.
Wat ze vaststellen, en waarom het ons aangaat. Twee dingen. (a) Er is een groot verschil tussen directe toegang via het product en toegang via de datahouder. Bij toegang via de datahouder zijn de waarborgen streng; bij directe toegang blijven ze beperkt tot ontwerpverplichtingen, en die verhinderen niet in alle situaties dat iemand bij de persoonsgegevens van een ander komt. (b) Omdat de datawet de AVG onverlet laat, is onbevoegde toegang een inbreuk in de zin van art. 4(12) AVG, en verplicht art. 32 AVG de datahouder tot passende maatregelen. Het vrijblijvende “mag” uit overweging 29 wordt zo een harde plicht — alleen niet in de wet waar iedereen kijkt.
De klem, en dit is de zin voor het gesprek. Precies die directe toegang — access by design, artikel 3, lid 1 — wordt op 12 september 2026 verplicht voor verbonden producten die dán op de markt komen. Over veertien dagen. De verplichting met de zwakste identiteitswaarborg is de verplichting die als eerste aangaat.
Wie. Leasemaatschappijen en vlootbeheerders eerst — case 93 draagt het cijfer al: ±46% van alle in de EU geregistreerde voertuigen wordt via lease gekocht en zo'n vloot is gemiddeld twee jaar oud, dus de gebruiker wisselt sneller dan het product. Daarna fabrikanten van landbouw- en industriemachines, waar dezelfde machine per seizoen een andere loonwerker in de cabine heeft.
🔌 Integratievorm — Vorm C (in-product/edge) plus Vorm A (API-sleutel op hun backend). Opzetpad: (1) draait al —
🧩 Productmix. V + C + G (de rechthebbende/mandaat-laag, want een leasenemer is geen eigenaar). M1 bij het binden van de bestuurder, M2 bij elke data-opvraging. Geen geldstroom → licentie, trede 2, nú verkoopbaar.
Zo zet je dit in de markt: dit is géén botverhaal en géén privacyverhaal — het is een aansprakelijkheidsverhaal, dezelfde hefboom die bij de MAR-insiderlijsten werkte. De opener: “Op 12 september geeft uw product zijn data rechtstreeks af aan ‘de gebruiker’. Wie in uw systeem bepaalt vandaag dat de persoon die het toestel in handen heeft, dezelfde is als de rechthebbende? Is dat antwoord ‘de app-login’, dan hebt u een AVG-inbreuk ingebouwd in een wettelijke verplichting.”
Eerlijk: het artikel is van maart 2026, niet van deze week. Het is nieuw voor maX, niet nieuw voor de wereld — en de deadline erachter is dat wél.
➕ AANVULLING 01-09-2026 — de klok staat nu op tien dagen, en er is een handeling bijgekomen. ENISA bevestigt dat het Single Reporting Platform op 11 september 2026 operationeel is; functionele en veiligheidstests liepen al, en registratie-instructies plus dry-run-materiaal werden in juni 2026 aangekondigd. De waarschuwing die eraan hangt is de bruikbare: de 24-uursklok stopt niet voor je onboarding. Wie op dag één een actief misbruikte kwetsbaarheid moet melden en dán pas begint te registreren, is te laat. De gefaseerde termijnen liggen vast: vroegwaarschuwing binnen 24 uur · technische melding binnen 72 uur · eindrapport binnen 14 dagen voor actief misbruikte kwetsbaarheden, of binnen één maand voor ernstige incidenten. Dit raakt Secure Mail rechtstreeks. Actie: nakijken of registratie al open is en zo ja, registreren vóór 11-09 — dat is administratie van een half uur die anders op de slechtst mogelijke dag valt. Bron: digital-strategy.ec.europa.eu · crowell.com, gecontroleerd 01-09-2026.
De bron. Pieter Wolters & Yong Yong Hu (Radboud Universiteit Nijmegen), “Authentication and authorisation and the access of the user in the Data Act”, Computer Law & Security Review, online 12-03-2026 (open access ook via de Radboud-repository). Onderzoeksvraag, letterlijk: in welke mate eist de Data Act authenticatie en autorisatie om onbevoegde toegang tot de persoonsgegevens van ánderen te voorkomen.
Wat ze vaststellen, en waarom het ons aangaat. Twee dingen. (a) Er is een groot verschil tussen directe toegang via het product en toegang via de datahouder. Bij toegang via de datahouder zijn de waarborgen streng; bij directe toegang blijven ze beperkt tot ontwerpverplichtingen, en die verhinderen niet in alle situaties dat iemand bij de persoonsgegevens van een ander komt. (b) Omdat de datawet de AVG onverlet laat, is onbevoegde toegang een inbreuk in de zin van art. 4(12) AVG, en verplicht art. 32 AVG de datahouder tot passende maatregelen. Het vrijblijvende “mag” uit overweging 29 wordt zo een harde plicht — alleen niet in de wet waar iedereen kijkt.
De klem, en dit is de zin voor het gesprek. Precies die directe toegang — access by design, artikel 3, lid 1 — wordt op 12 september 2026 verplicht voor verbonden producten die dán op de markt komen. Over veertien dagen. De verplichting met de zwakste identiteitswaarborg is de verplichting die als eerste aangaat.
Wie. Leasemaatschappijen en vlootbeheerders eerst — case 93 draagt het cijfer al: ±46% van alle in de EU geregistreerde voertuigen wordt via lease gekocht en zo'n vloot is gemiddeld twee jaar oud, dus de gebruiker wisselt sneller dan het product. Daarna fabrikanten van landbouw- en industriemachines, waar dezelfde machine per seizoen een andere loonwerker in de cabine heeft.
🔌 Integratievorm — Vorm C (in-product/edge) plus Vorm A (API-sleutel op hun backend). Opzetpad: (1) draait al —
/api/attest en /api/gate; (2) Franky bouwt — een “wie-is-de-gebruiker”-controle die vóór de data-afgifte twee dingen teruggeeft: uniek mens ja/nee en huidige rechthebbende ja/nee, zónder naam: 4–6 dagen; (3) de klant — één aanroep vóór hij de datastroom opent, en hij bewaart niets; (4) standaard — verordening (EU) 2023/2854 art. 3(1), 4(5) en 5(4), samen met AVG art. 32; (5) kleinste demo — één eigen pagina met twee opeenvolgende “gebruikers” van hetzelfde fictieve toestel, waarbij de tweede de data van de eerste níét te zien krijgt. Dat is het hele verhaal in één scherm. 🧩 Productmix. V + C + G (de rechthebbende/mandaat-laag, want een leasenemer is geen eigenaar). M1 bij het binden van de bestuurder, M2 bij elke data-opvraging. Geen geldstroom → licentie, trede 2, nú verkoopbaar.
Zo zet je dit in de markt: dit is géén botverhaal en géén privacyverhaal — het is een aansprakelijkheidsverhaal, dezelfde hefboom die bij de MAR-insiderlijsten werkte. De opener: “Op 12 september geeft uw product zijn data rechtstreeks af aan ‘de gebruiker’. Wie in uw systeem bepaalt vandaag dat de persoon die het toestel in handen heeft, dezelfde is als de rechthebbende? Is dat antwoord ‘de app-login’, dan hebt u een AVG-inbreuk ingebouwd in een wettelijke verplichting.”
Eerlijk: het artikel is van maart 2026, niet van deze week. Het is nieuw voor maX, niet nieuw voor de wereld — en de deadline erachter is dat wél.
➕ AANVULLING 01-09-2026 — de klok staat nu op tien dagen, en er is een handeling bijgekomen. ENISA bevestigt dat het Single Reporting Platform op 11 september 2026 operationeel is; functionele en veiligheidstests liepen al, en registratie-instructies plus dry-run-materiaal werden in juni 2026 aangekondigd. De waarschuwing die eraan hangt is de bruikbare: de 24-uursklok stopt niet voor je onboarding. Wie op dag één een actief misbruikte kwetsbaarheid moet melden en dán pas begint te registreren, is te laat. De gefaseerde termijnen liggen vast: vroegwaarschuwing binnen 24 uur · technische melding binnen 72 uur · eindrapport binnen 14 dagen voor actief misbruikte kwetsbaarheden, of binnen één maand voor ernstige incidenten. Dit raakt Secure Mail rechtstreeks. Actie: nakijken of registratie al open is en zo ja, registreren vóór 11-09 — dat is administratie van een half uur die anders op de slechtst mogelijke dag valt. Bron: digital-strategy.ec.europa.eu · crowell.com, gecontroleerd 01-09-2026.
29-08🆔 Identificatie-case 1 — de Europese wallet haalt zijn eigen deadline niet (12 van 27), Duitsland levert hem zónder betaalautorisatie, en de echte flessenhals blijkt niet de wallet maar het aansluiten van de afnemers — Wat er gebeurd is. Joel R. McConvey, Biometric Update, 04-08-2026, “Germany's EUDI Wallet push highlights Europe's implementation gap”. Drie harde punten: (1) uit een Signicat-doorlichting van januari 2026 waren 12 van de 27 lidstaten op schema voor een werkende wallet tegen eind 2026 — de wettelijke deadline; (2) Duitsland gaat door met een lancering op 02-01-2027, €79,3 miljoen geïnvesteerd t/m 2026, maar de eerste versie wordt beschreven als een uitgeklede basisversie zonder gekwalificeerde elektronische handtekening en zonder betaalautorisatie; (3) uit de Duitse SPRIND-sandbox blijkt een EU-brede flessenhals in het aansluiten van relying parties — die sandbox draaide vanaf januari 2026 115 organisaties over 150 use cases in zes maanden, en de terugkerende les was niet “de wallet werkt niet” maar “niemand krijgt de afnemers aangesloten”.
Wat r4m maX hierover al zegt. In je eigen doorloop-opmerking bij blok 3 staat de lijn al: “eID is misschien op bepaalde vlakken concurrentie maar R4M maX zal altijd meer tools aan boord hebben.” Dat is een overtuiging. Dit is het cijfer eronder, en het zegt iets scherpers: EUDI is een concurrent die eind 2026 in vijftien lidstaten niet bestaat, in Duitsland vanaf dag één geen betaling kan autoriseren, en waarvan de aansluitkant klemzit. Geen “wij zijn beter” — een gat met een datum.
🔌 Integratievorm — Vorm E (OIDC-knop) plus Vorm B (webbuild-widget). Opzetpad: (1) draait al — de itsme/eID-binding en de live test-link; (2) Franky bouwt — niets. Dit is een positionerings- en verkoopvondst, geen bouwtrigger, en dat moet je expliciet zeggen zodat het geen week opeet; (3) de klant — de bestaande knop; (4) standaard — eIDAS 2.0/ARF als richting, x401 als presentatievorm (zie de x401-entry hierboven: allebei bewegen naar browser-native); (5) kleinste demo — de test-link die er al staat.
🧩 Productmix. V + C; M1 per nieuwe mens, M2 per raadpleging. Licentie, trede 2.
🎯 Nieuw doelwit — zie ook de Doelwitten-lijst hieronder. SPRIND (Bundesagentur für Sprunginnovationen, Leipzig): zij dráaien de sandbox waarin dit gat gemeten is. Daarnaast tekende Bitkom samen met het BMDS en 100+ bedrijven een intentieverklaring rond de Duitse wallet — waaronder Deutsche Bank, Mastercard, N26, SAP, IDnow en Bundesdruckerei. En bij de Commissie loopt het Relying Party Engagement Programme, waarvan de eerste uitnodigingen eind augustus 2026 de deur uitgaan: dat venster staat nú open.
Zo zet je dit in de markt: níet als “wij vervangen EUDI” — dat is exact de zin die een deur kost. Wél als “wij zijn wat er werkt tussen nu en het moment dat de wallet er in úw lidstaat is, en wij blijven werken op de plekken waar de wallet niet komt — zoals betaalautorisatie in de Duitse eerste versie.” Openingszin richting de relying-party-kant: “Uw sandbox heeft in zes maanden met 115 organisaties vastgesteld dat het aansluiten van afnemers de flessenhals is, niet de wallet. Wij lossen precies dát op: één aansluiting, één vraag — uniek geverifieerd mens, ja of nee — geworteld in nationale eID, zonder dat de afnemer één identiteitsgegeven hoeft te bewaren.”
Eerlijk: het cijfer 12-van-27 komt uit een Signicat-doorlichting van januari 2026 zoals geciteerd door Biometric Update; ik heb het primaire Signicat-rapport niet ingezien. Noem het dus met die bronketen erbij.
Wat r4m maX hierover al zegt. In je eigen doorloop-opmerking bij blok 3 staat de lijn al: “eID is misschien op bepaalde vlakken concurrentie maar R4M maX zal altijd meer tools aan boord hebben.” Dat is een overtuiging. Dit is het cijfer eronder, en het zegt iets scherpers: EUDI is een concurrent die eind 2026 in vijftien lidstaten niet bestaat, in Duitsland vanaf dag één geen betaling kan autoriseren, en waarvan de aansluitkant klemzit. Geen “wij zijn beter” — een gat met een datum.
🔌 Integratievorm — Vorm E (OIDC-knop) plus Vorm B (webbuild-widget). Opzetpad: (1) draait al — de itsme/eID-binding en de live test-link; (2) Franky bouwt — niets. Dit is een positionerings- en verkoopvondst, geen bouwtrigger, en dat moet je expliciet zeggen zodat het geen week opeet; (3) de klant — de bestaande knop; (4) standaard — eIDAS 2.0/ARF als richting, x401 als presentatievorm (zie de x401-entry hierboven: allebei bewegen naar browser-native); (5) kleinste demo — de test-link die er al staat.
🧩 Productmix. V + C; M1 per nieuwe mens, M2 per raadpleging. Licentie, trede 2.
🎯 Nieuw doelwit — zie ook de Doelwitten-lijst hieronder. SPRIND (Bundesagentur für Sprunginnovationen, Leipzig): zij dráaien de sandbox waarin dit gat gemeten is. Daarnaast tekende Bitkom samen met het BMDS en 100+ bedrijven een intentieverklaring rond de Duitse wallet — waaronder Deutsche Bank, Mastercard, N26, SAP, IDnow en Bundesdruckerei. En bij de Commissie loopt het Relying Party Engagement Programme, waarvan de eerste uitnodigingen eind augustus 2026 de deur uitgaan: dat venster staat nú open.
Zo zet je dit in de markt: níet als “wij vervangen EUDI” — dat is exact de zin die een deur kost. Wél als “wij zijn wat er werkt tussen nu en het moment dat de wallet er in úw lidstaat is, en wij blijven werken op de plekken waar de wallet niet komt — zoals betaalautorisatie in de Duitse eerste versie.” Openingszin richting de relying-party-kant: “Uw sandbox heeft in zes maanden met 115 organisaties vastgesteld dat het aansluiten van afnemers de flessenhals is, niet de wallet. Wij lossen precies dát op: één aansluiting, één vraag — uniek geverifieerd mens, ja of nee — geworteld in nationale eID, zonder dat de afnemer één identiteitsgegeven hoeft te bewaren.”
Eerlijk: het cijfer 12-van-27 komt uit een Signicat-doorlichting van januari 2026 zoals geciteerd door Biometric Update; ik heb het primaire Signicat-rapport niet ingezien. Noem het dus met die bronketen erbij.
29-08🆔 Identificatie-case 2 — een toezichthouder beboette een operator omdat het dubbele account pas zichtbaar werd op het moment dat de speler zijn winst wilde ophalen — Wat er gebeurd is. De Victorian Gambling and Casino Control Commission legde Keno Vic een boete van AU$75.000 op (InterGame, 24-07-2026). De volgorde is het hele verhaal: de speler sloot zichzelf in april 2024 uit bij Keno Vic en probeerde vijf maanden later een tweede rekening te openen. Hij zakte voor de automatische identiteitscontrole en belandde in een “restricted play period”. Pas toen hij zelf contact opnam voor de handmatige controle — ná storten, ná spelen, en op het moment dat hij zijn winst wilde claimen — herkende het systeem de dubbele naam. De toezichthouder erkende dat de klant de controle probeerde te ontwijken, en legde de verantwoordelijkheid onverkort bij de vergunninghouder.
Wat r4m maX hierover al zegt. Dit terrein is gedekt: case 71 (Nationale Loterij door de EPIS-poort), 142 (één welkomstbonus per mens), 143 (één deelname per actie) en 193 (kansspelpoort België: uniek mens · 18+ · niet in EPIS in één stap). Dit is dus geen nieuwe case — het is het bewijsstuk dat die vier cases niet hadden: een toezichthouder die een boete oplegt met de faalvolgorde er letterlijk in.
Waarom die volgorde het product ís. De controle stónd er. Ze werkte alleen te laat en op de verkeerde eenheid: naam-matching bij uitbetaling is geen uniciteitscontrole, het is een opruimactie achteraf. Tussen “zakt voor de automatische controle” en “systeem herkent de dubbele naam” lag een periode waarin de man stortte en speelde. Elke operator die op dezelfde manier controleert, heeft dezelfde boete al verdiend — hij is alleen nog niet gepakt.
🔌 Integratievorm — Vorm A (API-sleutel op hun backend), maar op een ander moment. De aanroep verhuist van uitbetaling naar accountaanmaak. Opzetpad: (1) draait al —
🧩 Productmix. V + C. M1 bij de eerste speler-binding, M2 bij elke latere controle — en dat is het verkoopargument: een operator met een miljoen spelers betaalt niet een miljoen keer itsme. Geldvorm FIAT/licentie, trede 2, geen geldstroom over onze rail nodig.
Zo zet je dit in de markt: bij een Belgische operator of bij de Kansspelcommissie is dit de vraag waarop niemand een goed antwoord heeft: “Op welk moment ontdekt u een dubbel account — bij het aanmaken, of bij het uitbetalen?” Elk antwoord waar het woord “uitbetalen” in voorkomt, is een boete die nog niet gevallen is. Leg de Keno-beslissing erbij en de rest van het gesprek gaat vanzelf.
Eerlijk: Australië, niet de EU, en 24-07 is niet deze week. Dit is bewijsmateriaal voor bestaande cases, geen nieuwe marktbeweging — verkoop het ook zo.
Wat r4m maX hierover al zegt. Dit terrein is gedekt: case 71 (Nationale Loterij door de EPIS-poort), 142 (één welkomstbonus per mens), 143 (één deelname per actie) en 193 (kansspelpoort België: uniek mens · 18+ · niet in EPIS in één stap). Dit is dus geen nieuwe case — het is het bewijsstuk dat die vier cases niet hadden: een toezichthouder die een boete oplegt met de faalvolgorde er letterlijk in.
Waarom die volgorde het product ís. De controle stónd er. Ze werkte alleen te laat en op de verkeerde eenheid: naam-matching bij uitbetaling is geen uniciteitscontrole, het is een opruimactie achteraf. Tussen “zakt voor de automatische controle” en “systeem herkent de dubbele naam” lag een periode waarin de man stortte en speelde. Elke operator die op dezelfde manier controleert, heeft dezelfde boete al verdiend — hij is alleen nog niet gepakt.
🔌 Integratievorm — Vorm A (API-sleutel op hun backend), maar op een ander moment. De aanroep verhuist van uitbetaling naar accountaanmaak. Opzetpad: (1) draait al —
/api/attest en de gezouten persoons-hash; (2) Franky bouwt — niets nieuws, dit is de bestaande VerificationTakenError-flow uit case 71; (3) de klant — één aanroep vóórdat hij het account opent, en hij krijgt geen naam terug, alleen “deze mens heeft hier al een rekening”; (4) standaard — eID/itsme-binding, in België gekoppeld aan de EPIS-vraag; (5) kleinste demo — de live test-link waar een tweede registratie op dezelfde mens een VerificationTakenError krijgt. Die staat er al. 🧩 Productmix. V + C. M1 bij de eerste speler-binding, M2 bij elke latere controle — en dat is het verkoopargument: een operator met een miljoen spelers betaalt niet een miljoen keer itsme. Geldvorm FIAT/licentie, trede 2, geen geldstroom over onze rail nodig.
Zo zet je dit in de markt: bij een Belgische operator of bij de Kansspelcommissie is dit de vraag waarop niemand een goed antwoord heeft: “Op welk moment ontdekt u een dubbel account — bij het aanmaken, of bij het uitbetalen?” Elk antwoord waar het woord “uitbetalen” in voorkomt, is een boete die nog niet gevallen is. Leg de Keno-beslissing erbij en de rest van het gesprek gaat vanzelf.
Eerlijk: Australië, niet de EU, en 24-07 is niet deze week. Dit is bewijsmateriaal voor bestaande cases, geen nieuwe marktbeweging — verkoop het ook zo.
29-08⚡ Nieuw toepassingsgebied — de afnemer aansluiten is het product, niet de wallet: R4M als de éne aansluiting waar meerdere identiteitsbronnen achter zitten — De vondst. Uit de SPRIND-sandbox (115 organisaties, 150 use cases, zes maanden — zie de EUDI-entry hierboven) komt één conclusie die in geen enkele R4M-case staat: het moeilijke aan digitale identiteit in Europa is niet de wallet bouwen, maar een afnemer aangesloten krijgen. Registratie als relying party, certificering, per lidstaat opnieuw. De Commissie heeft daar vier uitvoeringsverordeningen voor en een Relying Party Engagement Programme; de eerste uitnodigingen gaan eind augustus 2026 de deur uit.
Wat r4m maX hierover al zegt — en wat er ontbreekt. De term “relying party” staat in de Engelstalige verkoopkit en in drie cases, maar altijd in de rol van de partij die ons iets vraagt. Nergens staat de omkering: R4M zelf als de enkele aansluiting waarachter meerdere bronnen hangen — vandaag itsme en de Belgische eID, morgen een EUDI-wallet, en in de lidstaten waar die er niet komt gewoon niets. SPRIND komt in de hele site niet voor.
Waarom dit een eigen toepassingsgebied is en geen variant. Alle bestaande cases verkopen een antwoord (“is dit één unieke mens?”). Dit verkoopt een positie: de afnemer sluit één keer op R4M aan en hoeft daarna niet per lidstaat, per wallet en per certificeringsronde opnieuw te beginnen. Dat is precies de pijn die 115 organisaties in zes maanden gemeten hebben, en het is een pijn die groeit naarmate er méér wallets komen, niet minder.
🔌 Integratievorm — Vorm A of E, één keer. Opzetpad: (1) draait al — de itsme/eID-binding en
🧩 Productmix. V + C, met D (de bronkiezer/depot-laag) als het nieuwe stuk. M1 per mens per bron, M2 per raadpleging. Licentie, trede 2.
Zo zet je dit in de markt: dit is het argument voor een hoster of een platform met klanten in meerdere lidstaten, niet voor een enkele website. Openingszin: “Uw klanten moeten straks een Europese wallet aanvaarden. In twaalf lidstaten bestaat die eind dit jaar, in de rest niet, en het aansluiten is volgens de Duitse sandbox de flessenhals. Sluit één keer op ons aan; wij hangen de bronnen erachter, in het tempo waarin ze er komen.”
Open punt voor jou: dit raakt bouwregel f1 (geen eigen protocol standaardiseren). Een bronkiezer ís geen protocol, maar de grens is dun — als dit doorgaat wil je het expliciet als implementatie van open standaarden achter één aansluiting formuleren, niet als “R4M-federatie”. Jouw keuze, niet die van de nachtploeg.
Wat r4m maX hierover al zegt — en wat er ontbreekt. De term “relying party” staat in de Engelstalige verkoopkit en in drie cases, maar altijd in de rol van de partij die ons iets vraagt. Nergens staat de omkering: R4M zelf als de enkele aansluiting waarachter meerdere bronnen hangen — vandaag itsme en de Belgische eID, morgen een EUDI-wallet, en in de lidstaten waar die er niet komt gewoon niets. SPRIND komt in de hele site niet voor.
Waarom dit een eigen toepassingsgebied is en geen variant. Alle bestaande cases verkopen een antwoord (“is dit één unieke mens?”). Dit verkoopt een positie: de afnemer sluit één keer op R4M aan en hoeft daarna niet per lidstaat, per wallet en per certificeringsronde opnieuw te beginnen. Dat is precies de pijn die 115 organisaties in zes maanden gemeten hebben, en het is een pijn die groeit naarmate er méér wallets komen, niet minder.
🔌 Integratievorm — Vorm A of E, één keer. Opzetpad: (1) draait al — de itsme/eID-binding en
/api/attest; (2) Franky bouwt — een bronkiezer achter hetzelfde antwoord, zodat een tweede wortel later bijgeschakeld kan worden zonder dat de afnemer iets wijzigt: ontwerp eerst, in ARCHITECTURE, vóór er code is; (3) de klant — verandert niets als er een bron bijkomt; dat ís het aanbod; (4) standaard — eIDAS 2.0/ARF plus x401 als presentatie; (5) kleinste demo — dezelfde aanroep twee keer, één keer via itsme en één keer via een tweede bron, met een identiek antwoord aan de afnemerskant. 🧩 Productmix. V + C, met D (de bronkiezer/depot-laag) als het nieuwe stuk. M1 per mens per bron, M2 per raadpleging. Licentie, trede 2.
Zo zet je dit in de markt: dit is het argument voor een hoster of een platform met klanten in meerdere lidstaten, niet voor een enkele website. Openingszin: “Uw klanten moeten straks een Europese wallet aanvaarden. In twaalf lidstaten bestaat die eind dit jaar, in de rest niet, en het aansluiten is volgens de Duitse sandbox de flessenhals. Sluit één keer op ons aan; wij hangen de bronnen erachter, in het tempo waarin ze er komen.”
Open punt voor jou: dit raakt bouwregel f1 (geen eigen protocol standaardiseren). Een bronkiezer ís geen protocol, maar de grens is dun — als dit doorgaat wil je het expliciet als implementatie van open standaarden achter één aansluiting formuleren, niet als “R4M-federatie”. Jouw keuze, niet die van de nachtploeg.
29-08📋 Stand van de sporen deze nacht — wat er wél is, en wat eerlijk leeg blijft — 💶 Geld-case (spoor B) — leeg, met reden. Ik heb géén nieuw bedrijf met naam gevonden dat vannacht beter is dan wat er 28-08 al staat (Payouts.com × Casper, met de payee-uniciteitsleemte). De geldbeweging van déze nacht zit in de protocolwacht bovenaan:
🤖 Agentic payments (spoor C) — gedekt door de x402-entry. Geen aparte vondst: de agentische lijn van deze nacht ís de terugknop-vondst. De Know-Your-Human-vondst van 28-08 (PYMNTS/Trulioo, 3,1% van de jaaromzet, samen $94,9 miljard) blijft de staande markt-onderbouwing; daar kwam niets bij.
📬 Secure Mail (spoor G) — niet aan de beurt. Dat spoor is maandagwerk; vannacht is het zaterdag. Er liggen wel veertien open todo's van 28-08 rond mail, volmacht, agent-mailaccounts en de mini-AI op vingerafdruk — zie het punt daarover in blok 8.
x402-volume — de tegencijfers blijven staan, gebruik ze allebei. Uit het x402-watch-rapport van 28-08 (
📨 Vragenlus — schoon. De doorloop-API telt 43 items en nul open vragen (28 uitgevoerd, 11 beantwoord, 2 afgevinkt, 2 afgevoerd). De zeven die op 28-08 wekenlang stillagen, zijn weg. Er staat dus niets langer dan drie nachten open.
auth-capture v1.1 opent een betaald aanhechtpunt tussen authorize en capture, met meter M2 nu en M3 na PRIO B. Dat is een echte geldvondst met een mechanisme; wat eraan ontbreekt is een gebeld bedrijf, en dat verzin ik niet. 🤖 Agentic payments (spoor C) — gedekt door de x402-entry. Geen aparte vondst: de agentische lijn van deze nacht ís de terugknop-vondst. De Know-Your-Human-vondst van 28-08 (PYMNTS/Trulioo, 3,1% van de jaaromzet, samen $94,9 miljard) blijft de staande markt-onderbouwing; daar kwam niets bij.
📬 Secure Mail (spoor G) — niet aan de beurt. Dat spoor is maandagwerk; vannacht is het zaterdag. Er liggen wel veertien open todo's van 28-08 rond mail, volmacht, agent-mailaccounts en de mini-AI op vingerafdruk — zie het punt daarover in blok 8.
x402-volume — de tegencijfers blijven staan, gebruik ze allebei. Uit het x402-watch-rapport van 28-08 (
Rails4Mankind/ops/daily/x402-watch-2026-08-28.md): het afrekenvolume zakte 93% YTD naar ±$41.800 zevendaags gemiddelde (Helios/Coutts, ±12-08), terwijl Coinbase over het eerste jaar 169 miljoen betalingen, 590.000 kopers, 100.000 verkopers telt en betalingen ≥$1 nu 95% van het volume uitmaken tegen 49% begin 2025 (Chainalysis). Nooit x402-groei als bewijs in een pitch gebruiken — gebruik de infrastructuuradoptie (Adyen, AWS, Amex, Circle, Cloudflare, Mastercard, Stripe, Visa in de x402 Foundation), niet het volume. 📨 Vragenlus — schoon. De doorloop-API telt 43 items en nul open vragen (28 uitgevoerd, 11 beantwoord, 2 afgevinkt, 2 afgevoerd). De zeven die op 28-08 wekenlang stillagen, zijn weg. Er staat dus niets langer dan drie nachten open.
29-08🤝 x401/uniciteits-lijn — bijna één op drie jonge gigwerkers VERHUURT zijn geverifieerde account aan iemand die zichzelf niet kon verifiëren; de screening is niet omzeild, hij is irrelevant geworden — Het cijfer. TransUnion’s 2026 Gig Economy Worker Report meet dat 31% van de millennial- en Gen-Z-gigwerkers zijn platformaccount verhuurt aan een niet-geverifieerde gebruiker, en één op vier gigwerkers in het algemeen. Verkopen gebeurt ook, netjes aflopend met de leeftijd: 27% van de millennials, 22% Gen Z, 14% Gen X, 7% babyboomers zegt zijn account verkocht te hebben. Overgenomen door Forbes en Staffing Industry Analysts. Waarom dit de wig scherper maakt dan alle vorige vondsten. Het argument was tot nu toe: platformen controleren identiteit bij de póórt, en dat is te omzeilen. Dit cijfer laat zien dat het niet te omzeilen is maar al massaal omzeild wórdt — en cruciaal: de achtergrondscreening was niet omzeild, hij was gewoon irrelevant geworden. Het account is legitiem geverifieerd; er zit alleen een andere mens achter. Geen enkele controle-bij-onboarding vangt dat, en de embedding-dedup van Figure Index al helemaal niet: die vergelijkt vídeo’s, niet mensen. Dezelfde blinde vlek als op 27-08, nu met een percentage erop. Wat het voor R4M betekent. De herhaalde attestatie-oproep (meter M2, ≈gratis per raadpleging) ís de “is dit nog dezelfde mens”-controle die deze 31% zou vangen — een lópende meter in plaats van een eenmalige verificatie, commercieel het interessantste model op het bord. Zie verdienmodel.html. Grenzen, eerlijk. (1) Geen bouwtrigger en geen verdienkant-beweger: er is vanavond géén partij gevonden die één-mens-één-account als product verkoopt aan gig-platformen. (2) Het duidingsartikel dat de verschuiving het scherpst formuleert — “is dit nog steeds dezelfde persoon?” — is een opiniestuk (13-08-2026) van de CEO van Trua, een hergebruikbare-identiteitsleverancier en dus een partij met belang: gebruik het cijfer van TransUnion, niet zijn conclusie. (3) Het rapport zelf is van 15-01-2026 — geen nieuws van vandaag, wel nieuw op deze radar. Nog open: wat een platform betaalt per her-verificatie (geen publieke tarieven gevonden), en of TransUnion dit gat zélf dichttrekt — dat zou de eerste echte concurrent op deze meter zijn.
28-08💸 x402/Base-lijn — de bouwers-beloning van Base is voor ons per constructie gesloten: hij rekent alleen PUBLIEKE repos, en die van ons zijn allemaal privé — Wat er bij komt. Nagekeken op 28-08-2026: Talent Protocol voedt de Base Builder Rewards-ranglijst met, letterlijk, “Turn your public GitHub and blockchain activity into a verified reputation score”. Er is geen aanvraag — het is een automatische wekelijkse ETH-verdeling over een ranglijst (genoemd: ±2 ETH per week over de top 100, drempel Builder Score ≥40, plus Basename en menselijk-vinkje). Waarom dit op de radar hoort en niet alleen op het financieringsbord. Het is een marktvorm, geen loket: de Base-economie beloont zichtbaarheid, en zichtbaarheid betekent daar publieke code. Wie privé bouwt bestaat niet in die ranglijst, hoe x402-native hij ook is. Dat is een structurele kost van de privé-regel, en die kost was tot vanavond onzichtbaar omdat de regel acht weken als “open” op het bord stond zonder ooit gecontroleerd te zijn. Grenzen, eerlijk. De bedragen komen uit Talent-Protocol-communicatie, niet uit de voorwaardentekst — die URL leidt met een 301 naar de homepage, dus behandel ze als indicatief. Los daarvan, en géén bewijs dat het programma stopt: Base’ eigen pagina docs.base.org/get-started/get-funded noemt Builder Rewards niet meer, alleen de Ecosystem Fund en Base Batches ($100K + demo day) — dat laatste is wél een programma waarop je aanvraagt en het staat al als aparte regel op het bord. 24-uursdelta van deze wacht, eerlijk gemeld: op de verdien-kant — betaalde inboxen, dividendrails, robot-inkomen, personhood-uitbetalingen — is in het venster opnieuw geen nieuwe speler gevonden. Wat dit voor de strategie betekent: als je ooit iets publiek maakt, doe het dan gericht — één losstaande open-source component (bijvoorbeeld een verifier of een testvector-set) opent deze lijn zonder de motor bloot te leggen. Dat is jouw beslissing, geen routinewerk.
28-08🤖 Agentic-lijn — de markt heeft er zelf een naam voor gekozen: "Know Your Human". En er hangt voor het eerst een prijskaartje aan het gat: 3,1% van de jaaromzet, samen 94,9 miljard dollar — Wat er bij komt. Nagekeken bij de bron op 28-08-2026: PYMNTS beschrijft de verschuiving van KYC (ken je klant) naar KYA (ken je agent) naar “Know Your Human”: vaststellen dat achter een handelende agent een échte mens staat die het toestond. Onderzoek van PYMNTS Intelligence met Trulioo zet er een bedrag op: bedrijven verliezen 3,1% van hun jaaromzet door gaten in identiteit, samen 94,9 miljard dollar. Trulioo’s Chief Product Officer omschrijft de opgave als begrijpen wie de agents zijn en of ze de juiste opdracht dragen; als “bewijs van mens” wordt World ID genoemd. Belangrijke datering — niet als nieuws verkopen. Dit artikel staat op 27 februari 2026, niet op vandaag. Het is dus geen beweging van deze week maar een anker: het bewijst dat de term en het budget al een half jaar bestaan. Wat dit voor R4M betekent. Twee dingen, allebei bruikbaar. (1) Wij hoeven de categorie niet meer uit te leggen — de markt noemt hem al zoals wij hem bouwen, en er ligt een cijfer waar een inkoper mee naar zijn directie kan. (2) Alles wat beschreven wordt zit aan de toestemmingskant: bevestigen dat een mens de agent liet betalen. Niemand in dat stuk betaalt een geverifieerd uniek mens úít. Die kant is nog steeds leeg, en dat is onze kant. 24-uursdelta van deze wacht, eerlijk gemeld: op de verdien-kant — betaalde inboxen, dividendrails, robot-inkomen, personhood-uitbetalingen — is in het venster geen nieuwe speler gevonden. Wat er beweegt, beweegt aan de uitgeef-kant. Zo zet je dit in de markt: gebruik het bedrag als opening en de leegte als aanbod. Je zin wordt: "Identiteitsgaten kosten 3,1% van de omzet, en ‘Know Your Human’ lost vandaag alleen op wie er mócht betalen. Wij doen de andere helft: aan wie je veilig kúnt uitbetalen, één mens één keer, geworteld in de nationale eID."
28-08🤖 Agentic-lijn — MIT mat negen dagen geleden hoeveel bewijs een agent van een mens eist voordat hij betaalt. Bijna één op drie opdrachten vraagt identiteitsbewijs, en het platform krijgt dat niet opgelost — Wat er bij komt. Iman YeckehZaare (MIT Center for Collective Intelligence) zette op 19 augustus 2026 een audit online van 779 publieke opdrachten op RentAHuman, de marktplaats waar agents mensen inhuren (arXiv:2608.18547, “Measuring Proof Burden in Public Bounty Listings: A RentAHuman Case Study”, geaccepteerd voor ACM HCOMP 2026 in september; cijfers via de gepubliceerde samenvatting). Twee onafhankelijke codeurs labelden elke opdracht met de hand op dertien kenmerken; ze kwamen op 81,8% exact overeen. 56,2% van de opdrachten legt een zware bewijslast op de werker (score 4 of 5 op een schaal van 0 tot 5). Gevraagd bewijs: tekst 57,8%, een fysieke handeling 48,5%, foto 37,1%, identiteit 30,9%, locatie 10,7%. Binnen de zware opdrachten vraagt 45,4% — 199 van de 438 — identiteitsgebonden bewijs, en daarvan wordt slechts 10,4% door de automatische detectieregels van het platform opgepikt. De auteur noemt identiteitsbewijs letterlijk het moeilijkst automatisch te detecteren, en schrijft dat het bewijzen van het werk zelf een bron van blootstelling wordt. Wat dit voor R4M betekent. Dit is geen marketingcijfer van een concurrent maar een gecontroleerde meting, met methode en datum, van precies het gat waar deze rail voor gebouwd is: agents huren mensen op schaal in, bijna één op drie keer willen ze weten wie die mens is, en het platform lost dat niet op — de wérker betaalt het, met zijn eigen gegevens, bij elke opdracht opnieuw. Zo zet je dit in de markt: stop met uitleggen dát er een uniciteitsprobleem is en citeér het. Je zin wordt: "MIT telde 779 opdrachten: 45% van de zware vraagt identiteitsbewijs, en het platform vangt daar 10% van af — de rest schuift het door naar de werker." En dan het aanbod: één keer verifiëren aan de nationale eID-wortel, daarna pseudoniem terugkeren, zodat de opdrachtgever uniciteit koopt en niet iemands identiteit. Openingszin voor de auteur (deur: MIT CCI, vóór HCOMP in september): "Uw audit meet het gat waar wij een rail voor gebouwd hebben. Wij verifiëren één keer aan de nationale eID-wortel en laten de mens daarna pseudoniem terugkeren — de opdrachtgever koopt uniciteit, niet blootstelling. Mag ik u het dossier sturen vóór de conferentie?"
28-08💸 x402-lijn — een bedrijf dat letterlijk Payouts.com heet, hangt sinds drie dagen een agent-portemonnee op x402. Ze hebben de payees, de rails en de fiscale check; wat ze niet hebben is uniciteit — Wat er bij komt. Op 25 augustus 2026 kondigden Payouts.com en de Casper Association aan dat Casper de settlementlaag wordt voor Payouts.com's AgentWallet en Digital Employees, over x402 met csprUSD; Casper claimt de eerste WebAssembly-native L1 te zijn die x402 op mainnet draait (The Paypers, 25-08 · Chainwire). Payouts.com is geen startup maar een bestaand massa-uitbetaalplatform: het betaalt vandaag affiliates, creators, contractors, vendors en marketplace-sellers in 190+ landen, 135+ valuta, over 40+ betaalrails, met 12.840 payees onboarded, en het verifieert die payees via W-9/W-8-formulieren met een realtime TIN-controle bij de IRS (payouts.com). ⚠️ Wat er níét staat, en dus niet mag beweerd worden: geen van de bronnen zegt dat agents hier ménsen gaan uitbetalen. De beschreven scope is agent koopt API-calls en datasets onder een policy-engine — uitgavenkant. Over uniciteit, één-account-per-mens of eID staat er geen woord. Uitrol gebeurt in fases over de komende maanden. Wat dit voor R4M betekent. Dit is de eerste keer dat een bedrijf wáárvan de kernactiviteit uitbetalen-aan-mensen is, een agent-portemonnee op onze rail zet. Ze zijn dus geen aanvaller maar wel de scherpste wacht in het dossier: zodra AgentWallet aan de payout-kant gekoppeld wordt, is dat een verdien-kant-concurrent mét distributie. Zo zet je dit in de markt: de opening is hun eigen compliance-laag. Een TIN-controle bewijst een belastingnummer, niet dat twee accounts twee mensen zijn — en dat breekt precies op het moment dat een agent zelf payees begint aan te maken. Openingszin (deur: partnerships, met compliance als tweede lezer): "U verifieert vandaag het belastingnummer van een payee. Dat bewijst niet dat twee accounts twee mensen zijn — en zodra een agent payees aanmaakt, is dat het eerste wat breekt. Wij leveren die uniciteitslaag, geworteld in nationale eID, zonder dat u één identiteit hoeft te bewaren."
28-08⚖️ Regelgeving — de FSMA-lijst van vergunde Belgische cryptodienstverleners is drie weken geleden bijgewerkt en staat op één woord: Nihil. Nul. Dat maakt van 'vergunning huren' geen voorkeur meer maar een noodzaak — Wat er bij komt. De FSMA werkte op 7 augustus 2026 haar lijst van in België vergunde CASP's (crypto-asset service providers) bij. Het resultaat is "Nihil" — geen enkele in België vergunde aanbieder — met een doorverwijzing naar het Europese ESMA-register (FSMA · Aeacus). Sinds het MiCA-overgangsregime op 1 juli afliep, identificeerde de FSMA bovendien zes aanbieders die zonder vergunning actief zijn — ZeriaFunding, Global Dynamic Trade, Dxago, Bithf Pro, Bank Bit en Aurum Foundation (Bitcoin Magazine NL). Wat dit voor R4M betekent. De lijn in het dossier was al "vergunning huren in plaats van zelf aanvragen". Dit cijfer maakt er iets scherpers van: er béstaat geen Belgisch vergund alternatief om mee te partneren, dus de partner komt hoe dan ook uit een andere lidstaat via het ESMA-register. Dat is geen tegenslag maar een argument — het verkleint de discussie met de advocaat tot één vraag: onder wiens vergunning loopt de crypto-been, en wat blijft daarbuiten. Zo zet je dit in de markt: gebruik het als geruststelling in plaats van als voorbehoud. Je zin wordt: "wij vragen zelf geen cryptovergunning aan — er is er in België trouwens geen enkele — wij werken onder de vergunning van een gereguleerde partner, en het stuk dat wij leveren, uniciteit en uitbetaling aan een geverifieerd mens, valt daar niet onder."
28-08📡 Regio-signaal — Japan haalde vier dagen geleden het plafond van één miljoen yen per stablecoin-transactie weg, en zette drie weken eerder een eigen toezichtsdienst neer — Wat er bij komt. Op 7 augustus 2026 richtte de Japanse FSA een zelfstandige Digital Assets and Stablecoins Division op onder het Asset Management and Insurance Supervision Bureau; het vroegere counsellor's office wordt daarmee een echte toezichtseenheid (Asia Stablecoin Advisory). Op 24 augustus schrapte diezelfde FSA het plafond van ¥1.000.000 per transactie dat tweede-categorie stablecoin-uitgevers sinds 2023 opsloot in retail-micropayments (TechTimes, 25-08). Daarnaast bereidt Japan de verschuiving van digitale activa naar de Financial Instruments and Exchange Act voor, met een voorstel om de maximale belastingdruk van 55% naar een afzonderlijke heffing van 20% te brengen. Cross-border testen SBI en Nodeinfra intussen yen- en won-betaaltokens in Project Musubi op het Canton Network (Cryptonomist, 12-08); Zuid-Korea heeft eind juni nog steeds geen wettelijk kader (GreySpark). Wat dit voor R4M betekent. Het plafond dat institutionele yen-betalingen tegenhield is weg. Dat verplaatst een JPY-stekker op de settlement-adapter van theoretisch naar denkbaar — maar niet bouwen; noteren. De rail blijft dezelfde, alleen de stekker verschilt, precies zoals het regionale draaiboek het beschrijft. Zo zet je dit in de markt: nog niet als pitch, wel als antwoord op de vraag "werkt dit ook buiten Europa". Je zin wordt: "dezelfde rail, een andere stekker — Japan heeft deze maand net het plafond weggehaald dat institutionele yen-betalingen blokkeerde, dus die stekker is daar nu maakbaar."
28-08📡 De laag onder je voeten — AWS en Cloudflare bakken x402 in de rand van het internet, en géén van beide zegt wie de mens achter de agent is — Wat er bij komt. AWS heeft x402 algemeen beschikbaar gezet in CloudFront en AWS WAF, ongeveer twee weken vóór Cloudflare zijn Monetization Gateway aankondigde; de AWS-versie werkt meteen, met USDC-afrekening op Base en Solana en geen meerkost bovenop de gewone WAF-prijs. Cloudflare staat nog op een wachtlijst zonder prijs, zonder datum en zonder bekendgemaakte ketens (InfoQ, 07-2026). Coinbase meldt over het eerste jaar x402: 169 miljoen betalingen, 590.000 kopers, 100.000 verkopers. ⚠️ Eén cijfer spreekt dat tegen en dat moet je weten vóór je het gebruikt: een tweede bron meldt dat het dagelijkse afrekenvolume in dollar dit jaar met 93% zakte, wat erop wijst dat de piek van eind 2025 vooral testverkeer was (Yahoo Finance). Aantal betalingen en volume in dollar zijn niet hetzelfde cijfer, dus ze kunnen allebei kloppen — maar noem in een gesprek nooit alleen de 169 miljoen. Wat dit voor R4M betekent. De betaalkant is nu infrastructuur van twee hyperscalers: die ga je niet verkopen, en dat hoeft ook niet. Wat in geen van beide zit is de identiteitswortel — CloudFront en WAF rekenen af, ze weten niet of er een mens achter zit. Dat is exact de lijn die Proof met x401 trekt en die in jouw dossier al openstaat. Zo zet je dit in de markt: stop met x402 uitleggen als iets dat je moet installeren — het staat al in de rand van het internet. Je zin wordt: "de betaling is opgelost door AWS en Cloudflare; wat zij niet leveren is het bewijs dat er één echte mens achter die agent zit, en dat het diezelfde mens is als vorige keer." Praktisch: financieringsregel 4 (Cloudflare Monetization Gateway, wachtlijst) is daarmee géén exclusieve deur meer — AWS is er al, werkt vandaag, en is een tweede integratiepad dat vandaag te demonstreren valt.
28-08💶 Geld-case — over vier dagen valt de klep dicht op 825 miljoen euro, en niemand in dit dossier heeft die deur nog aangeraakt — Wat r4m maX hierover al zegt: case 123 (Slapende tegoeden terughalen, DCK) staat in de catalogus met status skelet, klantenlijst leeg, en het kans-label zegt letterlijk "harde wettelijke deadline op 1-9-2026". Franky's eigen todo van 24-08 zette er ⏰ URGENT boven. Er is sindsdien niets mee gebeurd. Wat er vannacht bij komt — de cijfers en de exacte wijziging, nagekeken bij de bron. Op 1 september 2026, dus over vier dagen, verandert bij de Deposito- en Consignatiekas (FOD Financiën, Brussel) drie dingen tegelijk: de verjaringstermijn voor gewone slapende tegoeden gaat van 30 naar 5 jaar, voor tegoeden van overleden of verdwenen begunstigden van 30 naar 10 jaar, en de drempel waaronder een tegoed zonder verdere opsporing naar de staatskas mag van 60 naar 250 euro — onder die 250 euro is het geld daarna nooit meer terug te halen. Sinds maart 2026 brengen die tegoeden ook geen rente meer op. Stand van de pot: 815 miljoen euro over 674.678 rekeningen eind november 2025, opgelopen tot ongeveer 825 miljoen over 677.698 dossiers in mei 2026. De begroting rekent voor 2026 op ±477 miljoen euro die naar de staatskas doorschuift (Business AM, 25-08-2026). 🚧 En meteen de poort erbij, want die is hier makkelijk te missen. De verleiding is de DCK zelf te bellen. Doe dat niet: de niet-doen-lijst wijst case 30 (belastingteruggave) af met exact deze reden — een federale administratie koopt via overheidsopdrachten, en dat is geen verkoop maar een procedure van maanden. Deze deadline is over vier dagen. De koper is dus de bank, het claimkantoor en de notaris die vóór 1 september nog dossiers indient, en daarna jarenlang met een vijfjaarstermijn moet werken in plaats van dertig. 🔌 Integratievorm — A (hosted widget) met C (REST-API) ernaast. In gewone taal: het claimkantoor plakt één regel op zijn indienformulier; wie een claim start doorloopt eerst een itsme-stap op ónze pagina en komt terug met een pseudoniem. Het kantoor bewaart dat pseudoniem naast het dossiernummer en vraagt via één API-call of dit pseudoniem al een claim op dít dossier legde. Opzetpad: (1) draait al — de attestatie-uitgifte en de verify-kant staan publiek op de vitrine; (2) Franky bouwt — een dossiergebonden uniciteitsteller ("één claim per pseudoniem per dossiernummer"), 2 tot 3 dagen, dezelfde primitief als de teller in case 29 en 32; (3) de klant doet — één regel in zijn formulier en één veld in zijn dossierdatabank; (4) standaard — OIDC naar itsme via Signicat, geen eigen protocol; (5) kleinste demo zonder toestemming — een publieke pagina waar iemand zich met itsme aanmeldt, een verzonnen dossiernummer intikt, en bij de tweede poging op hetzelfde nummer rood krijgt. 🧩 Productmix: V (is dit een echte, unieke mens) als hoofdmoot, met D (denylist op de persoon-wortel) voor wie systematisch dubbel indient. Meter: M1 bij elke nieuwe claimer — dat is de meter die de itsme-kost draagt — plus M2 voor elke latere raadpleging op dezelfde mens. Geen M3, en dat is hier het verkoopargument: het geld van de DCK gaat rechtstreeks van hen naar de rechthebbende en raakt R4M nergens aan, dus dit is trede 2 en hoeft niet op Nele te wachten. Zo zet je dit in de markt: dit is de enige case in het hele dossier met een datum die deze week valt — bel geen administratie, bel drie claimkantoren en zeg: "vanaf dinsdag hebt u vijf jaar in plaats van dertig, en alles onder 250 euro is voorgoed weg. Ik lever u in twee dagen het bewijs dat elke claim van één echte mens komt en dat dezelfde mens niet twee keer op hetzelfde dossier indient — zonder dat u nog één identiteitskopie hoeft te bewaren."
28-08🆔 Identificatie-case 1 — de Amerikaanse overheidslogin zoekt eergisteren openbaar een leverancier die terugkerende bezoekers herkent door gewiste cookies heen. Dat is niet nieuw voor jou; wat nieuw is, is de datum en de deadline — Wat r4m maX hierover al zegt: de catalogus beschrijft dit al als LAAG 2 — "voor terugkeerdetectie gebruiken platformen device fingerprinting, netwerkanalyse en gedragspatronen" — en zegt er meteen bij waarom dat verliest: antidetect-browsers geven elk account een eigen browservingerafdruk, eigen cookies en een eigen proxy, adverteren letterlijk met scale without bans, en die markt groeide in 2026 met meer dan 60%. Het argument staat er dus al. Wat er vannacht bij komt: het bewijsstuk op het hoogste denkbare niveau, met een datum. Op 26 augustus 2026 publiceerde de General Services Administration (Washington DC, de inkooparm van de Amerikaanse federale overheid) via Technology Transformation Services een Request for Information voor Login.gov, de login waarmee burgers bij federale diensten binnenkomen. Gevraagd wordt technologie die "terugkerende computers en telefoons herkent, ook wanneer gebruikers hun IP-adres wijzigen, cookies wissen, in privémodus surfen of technologie gebruiken om hun toestel te verbergen", met "een blijvende toestel-identificator die over sessies heen aan hetzelfde toestel gekoppeld blijft" — en die en passant ook VPN's, gerootte toestellen, AI-agents en geautomatiseerde browsers moet zien. GSA zegt zelf dat het fingerprinting al gebruikt tijdens identiteitsverificatie en het nu wil uitbreiden naar accountaanmaak en inloggen. Antwoorden moeten binnen op 11 september 2026 (Biometric Update, 26-08-2026). Waarom dit het scherpste bewijsstuk is dat je hebt. Een overheid die een eigen identiteitsdienst uitbaat, met echte identiteitsverificatie eronder, koopt tóch een toestel-vingerafdruk. Niet omdat ze niet weten wie je bent, maar omdat ze niet weten of dit dezélfde mens is als vorige keer. Dat is jouw zin, letterlijk, en nu staat hij in een aanbestedingsstuk. 🔌 Integratievorm — B (OIDC, "Log in met R4M") naast hun bestaande login. Opzetpad: (1) draait al — de attestatie-uitgifte en de publieke sleutellijst; (2) Franky bouwt — de OIDC-façade op het bestaande attestatie-endpoint (discovery, authorize, token, JWKS), geschat 3 tot 5 dagen; (3) de klant doet — een redirect-URL registreren, zoals bij elke sociale login; (4) standaard — OpenID Connect, niets eigens; (5) kleinste demo zonder toestemming — twee browserprofielen, twee verse fingerprints, hetzelfde pseudoniem terug. 🧩 Productmix: V + D. Meter: M1 bij de eerste verificatie, daarna M2 bij elke terugkeer — en juist bij een overheidslogin met miljoenen bezoekers is dat de goedkope meter, wat het gesprek over prijs meteen makkelijker maakt. Zo zet je dit in de markt: de VS is voor jou geen doelmarkt (geen eID, en de route loopt via mDL — zie de radar van 24-08), dus verkoop hier niet aan GSA. Gebruik het stuk als bewijs in Europa: neem het RFI-fragment mee naar Combell, naar een uitgever of naar de Loterij en zeg: "de Amerikaanse federale login koopt deze maand een vingerafdruk van je toestel omdat hij niet weet of je dezelfde mens bent als vorige week. Ik verkoop het antwoord op die vraag, en het overleeft een gewiste cookie omdat het niet aan je toestel hangt maar aan je itsme." ⚠️ Niet geverifieerd: of GSA daadwerkelijk gunt, en of Login.gov ergens publiceert hoeveel dubbele accounts het vindt. Zeg dus "ze vroegen ernaar", nooit "ze kochten het". 🔁 AANVULLING 02-09-2026 — de vraag is een verplichting geworden. Op 31-08-2026 gaf OMB memorandum M-26-18 uit, "Scaling Use of Login.gov to Deliver a Universal Sign-on for Public Services" (whitehouse.gov, gemeld door biometricupdate.com 01-09-2026). De RFI van eind augustus is daarmee beleid: 60 dagen om alle publieke sites met authenticatie te inventariseren, 240 dagen voor de risicobeoordelingen onder NIST SP 800-63-4, 1 jaar voor de zwaarste diensten, 2 jaar voor de rest of een verantwoording aan OMB. Defensie en nationale-veiligheidssystemen vallen erbuiten. Het stuk dat voor ons telt: binnen zes maanden — dus vóór eind februari 2027 — moet GSA de mogelijkheden onderzoeken om verifieerbare digitale credentials te maken en te gebruiken, én een industry day houden over commerciële identiteitstechnologie die Login.gov zou kunnen gebruiken. Dat is geen aanbesteding maar het is wel een gedateerde, publieke deur, en hij staat in een memo en niet in een blog. Waarom het toch geen actie van vandaag is: een Belgische eenmanszaak op eID/itsme heeft geen product dat een Amerikaanse federale login kan dragen. Wat dit wél is: een tweede, hardere bevestiging dat de grootste overheidslogin ter wereld zijn identiteitslaag opnieuw aan het inkopen is, en dat "wie is dit" daar nog steeds niet "is dit dezelfde als die andere" betekent.
28-08🆔 Identificatie-case 2 — Meta geeft sinds vijf weken gratis weg dat je een echt mens bent, en gooit het gezicht dat het bewijst binnen dertig dagen weg. Dat laatste is het gat — Wat r4m maX hierover al zegt: de radar van 25-08 legt precies dit patroon uit voor de EU-leeftijdsapp — gratis is je verkoper, niet je concurrent, want een bewijs dat met opzet niet-koppelbaar is kan nooit "één keer per mens" tellen. Wat er vannacht bij komt: dezelfde redenering, maar nu bij een commerciële partij met drie miljard gebruikers, en met een houdbaarheidsdatum in het persbericht zelf. Op 24 juli 2026 lanceerde Meta (Menlo Park) Facebook Verified: een gratis badge, los van het betalende Meta Verified. Je neemt een korte video-selfie op, die wordt vergeleken met de foto's die al op je profiel staan, en binnen enkele minuten heb je een vinkje dat verschijnt in Marketplace, Dating, Groepen en op je profiel. Voorwaarden: 18+ en in orde met de gemeenschapsregels (about.fb.com, 24-07-2026, Engadget). Meta zegt er zelf bij dat de video-selfie en de bijhorende gezichtsdata binnen dertig dagen na de verificatie gewist worden, terwijl de badge blijft. Wat dat betekent, en waar de grens van mijn bewering ligt. Wat overblijft is een badge die zegt "er hoort een gezicht bij dit profiel dat matcht met de foto's op dit profiel". Dat is een uitspraak over één account, niet over een mens. Zodra de gezichtsdata weg is, kan die controle achteraf niet meer beantwoorden of het gezicht achter profiel A hetzelfde is als dat achter profiel B. ⚠️ Eerlijk: Meta zegt niet of het intern een onomkeerbare vergelijkingscode bewaart — dat staat nergens, en ik heb het niet gevonden. Beweer dus nooit "Meta kan geen dubbels vinden". Zeg wat er wél staat: de gezichtsdata gaat binnen dertig dagen weg, en de badge is uitdrukkelijk identiteitsbevestiging en géén waarborg. 🔌 Integratievorm — A (widget) voor een marktplaats, D (platform-app) als je in hun winkel wil staan. Opzetpad: (1) draait al — uitgifte en verificatie; (2) Franky bouwt — een verkopersbadge met een teller "hoeveel verkopersaccounts achter één mens", 2 tot 3 dagen, dezelfde primitief als case 45; (3) de klant doet — één script-regel bij registratie; (4) standaard — OIDC + JWS-attest; (5) kleinste demo — twee verkopersprofielen, één mens, één rood signaal. 🧩 Productmix: V + D, meter M1 bij de eerste verkoper en M2 bij elke controle daarna. Zo zet je dit in de markt: naar elke Europese marktplaats die vandaag met Marketplace concurreert. Openingszin: "Meta geeft uw verkopers sinds juli gratis een menselijk vinkje. Uw klanten gaan het vragen. Wat Meta niet geeft — en volgens zijn eigen aankondiging binnen dertig dagen weggooit — is het antwoord op de enige vraag die u écht kost: is de verkoper die ik gisteren geschorst heb, de nieuwe verkoper van vandaag?"
28-08🤝 x401-lijn — een Amerikaans hof van beroep besliste drie weken geleden dat niet het agent-bedrijf maar de mens erachter de computer "betreedt". De aansprakelijkheid landt dus op een mens die niemand kan aanwijzen — Wat r4m maX hierover al zegt: de x401-pagina en de correctie van 27-08 leggen al vast dat x401 een bestaand protocol van Proof is, dat R4M geen eigen protocol standaardiseert (bouwregel f1) en dat het gat "namens wie handelt deze agent" is. Wat er vannacht bij komt: een rechterlijke uitspraak die dat gat van een verkoopargument in een aansprakelijkheidsvraag verandert. Op 4 augustus 2026 vernietigde het Ninth Circuit Court of Appeals (San Francisco) het verbod dat Amazon had gekregen tegen de winkel-agent van Perplexity. De redenering is wat telt: wanneer een gebruiker een Perplexity-agent opdraagt iets te doen op Amazon.com, is het "de gebruiker die Amazons computers heeft betreden", niet Perplexity — want de Computer Fraud and Abuse Act zegt whoever, en dat veronderstelt toegang door een persoon, niet door een stuk software (arrest 26-1444, 04-08-2026, geduid door Cooley 06-08-2026 en Wilson Sonsini). Het is de eerste federale beroepsuitspraak over de vraag of agents namens gebruikers een platform mogen betreden. Waarom dit jouw hele x401-verhaal harder maakt. Tot nu was "wie stuurde deze agent" een nette vraag. Sinds 4 augustus is het in de VS een vraag met een aansprakelijke aan het eind — en de wet wijst die aansprakelijke aan zonder dat er één standaard bestaat om hém te identificeren. Zet dat naast wat hier al staat: sinds 2 augustus 2026 moet een agent onder AI Act art. 50 melden dát hij een machine is, en "namens wie" hoeft niet. Europa vraagt het niet, Amerika rekent het intussen wél af. 🔌 Integratievorm — C (REST-API + webhooks), naast x401 en niet ertegenin. Opzetpad: (1) draait al — attestatie-uitgifte, JWKS, verificatie; (2) Franky bouwt — de mandaatkaart met scope, plafond en einddatum plus intrekking via webhook, 8 tot 12 dagen, en die bouw staat al beschreven bij case 115; (3) de klant doet — één verify-call bij het instellen van het mandaat en één bij elke agent-actie; (4) standaard — het attest als losse JWS in een header, leesbaar naast een x401-claim en een AP2-mandaat; (5) kleinste demo — een agent die een mandaat toont dat om 11u werd ingetrokken en om 11u01 rood krijgt. 🧩 Productmix: V + C + O. Meter: M2 op elke verificatie van een lopend mandaat, M1 alleen bij de eerste binding van de mens. Zo zet je dit in de markt: dit is munitie voor het gesprek met een PSP of een handelaar, niet voor een klant met een Belgisch kmo-probleem. Zeg het zo: "sinds 4 augustus is in de VS niet het agent-bedrijf maar de opdrachtgever degene die uw systeem betreedt. Als er dan iets misloopt, moet u kunnen tonen wélke mens die opdracht gaf. Vandaag hebt u een agent-token; dat bewijst een programma, geen persoon."
28-08💸 x402-lijn — de stichting is sinds 14 juli operationeel, en de kaartennetwerken zijn van supporter naar premier-lid geschoven. Mastercard, Visa, Amex, Stripe, Adyen en Shopify zitten nu in dezelfde raad — Wat r4m maX hierover al zegt: de catalogus vermeldt de stichting al ("x402 ging in april 2026 als x402 Foundation onder de Linux Foundation, met Coinbase en Cloudflare als oprichters", 169 miljoen betalingen tussen ±590.000 kopers en 100.000 verkopers in het eerste jaar) en het log bij case 120 noteert "geformaliseerd op 02-04-2026, 22 leden". Wat er vannacht bij komt: de operationele start en de nieuwe ledenlijst — het aantal is bijna verdubbeld en de samenstelling is veranderd van karakter. Op 14 juli 2026 kondigde de Linux Foundation de operationele start van de x402 Foundation aan, met de contributie van het protocol door Coinbase afgerond. Er zijn nu 40 organisaties lid. De premier-leden (17): Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, Monad Foundation, MoonPay, Ripple, Shopify, Solana Foundation, Stellar Development Foundation, Stripe, Visa. Daarnaast 18 algemene en 4 geassocieerde leden, waaronder Polygon Labs, NEAR, Fireblocks, KakaoPay en Quant Network (x402.org, 14-07-2026). Wat daarin het nieuws zit. In april was dit een cryptoprotocol met twee infrastructuurbedrijven eromheen. In juli zitten álle grote kaartennetwerken, twee van de grootste Europese betaalverwerkers en de grootste webshop-motor op het hoogste lidmaatschapsniveau. En in het volledige aankondigingsstuk staat over identiteit, KYC of machtiging niets — het gaat over "veilige betaalmogelijkheden" en "controle", en de citaten van de leden gaan over snelheid en interoperabiliteit. Veertig organisaties standaardiseren hoe een machine betaalt; niemand van hen standaardiseert wie hem stuurde. 🔌 Integratievorm — J (x402-resource, machine betaalt). Opzetpad: (1) draait al — de x402-schil op base-sepolia, testnet; (2) Franky bouwt — niets nieuws voor deze vondst, dit bevestigt de gekozen richting; (3) de klant doet — niets, want dit is geen klant maar een landkaart; (4) standaard — x402 zelf, met het attest als losse JWS-header, precies zoals bouwregel f1 voorschrijft; (5) kleinste demo — de bestaande publieke x402-resource met twee prijzen: vol tarief voor een anoniem adres, korting met een geldig R4M-attest. 🧩 Productmix: V + C, geldvorm STABLECOIN (testnet — mainnet wacht op de merchant-kwalificatie), meter M2 per attest-oproep. Zo zet je dit in de markt: gebruik de ledenlijst als plaatje in elk agentic gesprek. "Veertig organisaties, waaronder Visa, Mastercard, Amex, Stripe, Adyen en Shopify, hebben in juli afgesproken hóe een machine betaalt. Lees het hele aankondigingsstuk: er staat geen enkele regel in over wie die machine mag sturen. Dat is precies het stuk dat ik bouw, als header naast hun betaling — niet als concurrent van hun standaard."
28-08🤖 Agentic payments — Visa legde deze maand 2,4 miljard dollar op tafel voor gedragsbiometrie. Dat is de duurste bevestiging die je kunt krijgen dat laag 2 gekocht wordt en laag 1 nog te koop is — Wat r4m maX hierover al zegt: de catalogus onderscheidt al laag 1 (is dit een echte, unieke mens) van laag 2 (is dit dezelfde die terugkomt), en zegt dat laag 2 wordt gedaan met device fingerprinting, netwerkanalyse en gedragspatronen. Gedragsbiometrie als categorie komt in maX nog nergens bij naam voor. Wat er vannacht bij komt. Op 3 augustus 2026 kondigde Visa aan BioCatch te kopen voor 2,4 miljard dollar in cash, van fondsen beheerd door Permira en andere aandeelhouders; de deal sluit naar verwachting in het tweede fiscale kwartaal van 2027. BioCatch (Israëlisch) herkent fraude aan hóe iemand typt, veegt en zijn toestel vasthoudt. Schaal: meer dan 350 banken in 21 landen, meer dan 100 van de grootste financiële instellingen, dekking over 1,8 miljard toestellen en 760 miljoen gebruikers. Visa noemt als doel: bescherming tegen account-overnames, scams, geldezels en aanvraagfraude (Visa Investor Relations, 03-08-2026, CNBC 03-08-2026). Hoe je dit leest zonder jezelf iets wijs te maken. Dit is geen aanval op jouw plaats, het is een prijskaartje op de buurstoel. Gedragsbiometrie beantwoordt "gedraagt deze sessie zich als de rechtmatige houder van dit account" — een uitspraak over een account, gemeten op 1,8 miljard toestellen. Wat het niet kan: zeggen dat de mens achter account A dezelfde is als die achter account B, want het heeft geen wortel die over afnemers heen geldt. Dat is exact het onderscheid dat maX al maakt, nu met een waardering van 2,4 miljard onder laag 2. 🔌 Integratievorm — C (REST-API), als aanvullend signaal, nooit als vervanging. Opzetpad: (1) draait al — verificatie tegen JWKS; (2) Franky bouwt — niets extra's voor deze vondst; (3) de klant doet — één extra veld naast zijn bestaande fraudescore; (4) standaard — JWS-attest; (5) kleinste demo — een score naast een attest tonen, met het verschil in één zin eronder. 🧩 Productmix: V + D, meter M2. 🚧 Poort: de niet-doen-lijst wijst gereguleerde banken als koper af (AMLR eist dat een uitbestede partij zelf onder toezicht staat) — verkoop hier dus hooguit een aanvullend signaal bovenop een gelicentieerde partij, nooit de KYC zelf. Zo zet je dit in de markt: als antwoord op "hebben de grote spelers dit niet al?" — "Visa betaalde deze maand 2,4 miljard voor het herkennen van hóe u typt. Dat beschermt uw account. Het zegt nog altijd niets over de vraag of u vijf accounts hebt. Die tweede vraag heeft niemand gekocht."
28-08🔎 Nieuw toepassingsgebied dat nog niet in de catalogus staat: gratis AI-rekenkracht als sociaal recht — één toewijzing per mens, uitgedeeld met UNICEF erbij — Wat r4m maX hierover al zegt: case 54 gaat over verhuurde GPU's (wie bedient deze machine) en case 170 over een uitdeelrail; "één toewijzing van rekenkracht per mens" staat nergens, en Self Labs, UNICEF en het begrip universal basic compute komen in geen enkel bestand voor. Dit is dus echt een nieuw veld. De vondst. Op 14 augustus 2026 raakte bekend dat Self (Self Labs, uit het Celo-ecosysteem; CEO Rene Reinsberg) de persoonscontrole levert voor een initiatief rond universal basic compute, samen met UNICEF Digital Inclusion en de Connect and Compute Foundation. Wat Self doet: nagaan "dat elke toewijzing bij één echte, in aanmerking komende persoon terechtkomt", door overheidsdocumenten te scannen met zero-knowledge-bewijzen, uitdrukkelijk zonder biometrische hardware, zonder nieuwe inschrijvingsinfrastructuur en zonder een centrale identiteitsdatabank; er wordt naar eigen zeggen geen enkel gegeven met UNICEF of een derde gedeeld (Biometric Update, 14-08-2026). Waarom dit ertoe doet, in twee richtingen. (a) Het veld is nieuw en het lijkt op wat je al kunt. Een schaars goed — hier rekenuren in plaats van euro's — dat exact één keer per mens uitgedeeld moet worden, zonder identiteitsdossier: dat is woord voor woord de burgerbudget-, toelage- en premie-familie uit de catalogus (cases 29, 31, 124, 131), met een ander goed erin. (b) Het is tegelijk je eerlijkste concurrentiemeting. Iemand doet dit vandaag al, met documentscan plus ZK in plaats van itsme plus pseudoniem-per-afnemer. Het verschil dat je moet kunnen uitleggen: een documentscan bewijst dat een document echt is en bij deze persoon hoort; hij bewijst niet dat dezelfde mens niet met een tweede geldig document, in een tweede land, een tweede toewijzing haalt. Jouw wortel is één itsme-identiteit per mens; die van hen is één document per aanvraag. ⚠️ Niet geverifieerd: hoe Self dubbels over documenten heen tegenhoudt, en welke bedragen of aantallen in dit initiatief omgaan — dat staat nergens. Zeg dus niets over hun zwakte tegen een klant tot je hun documentatie zelf gelezen hebt. 🔌 Integratievorm — A (widget) plus C (API); voor een uitdeelprogramma is I (batch/CSV) de sluiproute die niemand verwacht: de programmabeheerder levert een lijst aanvragers, jij geeft terug hoeveel unieke mensen erin zitten, zonder één naam terug te sturen. Opzetpad: (1) draait al — uitgifte en verificatie; (2) Franky bouwt — de uniciteitsteller per programma-context, 2 tot 3 dagen, dezelfde primitief als bij de premie-cases; (3) de klant doet — één stap in zijn aanvraagformulier; (4) standaard — OIDC naar itsme; (5) kleinste demo — een aanvraagpagina waar de tweede aanvraag van dezelfde mens rood wordt. 🧩 Productmix: V als kern, G (afgeschermde ruimte) als het programma alleen voor toegelaten mensen is, meter M1 per nieuwe deelnemer en M2 per controle. Zo zet je dit in de markt: niet naar UNICEF — dat is een internationale organisatie met een aankoopprocedure, dezelfde muur als een federale administratie. Wél als verhaal bij elke Vlaamse of Brusselse premie- of burgerbudgetkoper: "UNICEF deelt sinds augustus AI-rekenkracht uit met precies dezelfde eis als uw premie: één keer per mens, zonder identiteitsdossier. Het bestaat dus, het is niet theoretisch, en in België hebt u er een sterkere wortel voor dan zij: itsme."
28-08🎯 Nieuwe prospect — SEON (Boedapest): de partij die de laag verkoopt die jouw catalogus als "verliest van een abonnement van dertig euro" beschrijft. Kanaal, geen concurrent — Wat r4m maX hierover al zegt: SEON staat drie keer in de catalogus, maar altijd als bewijsstuk of als andermans gereedschap — één keer omdat SEON zélf schrijft "the detection capability isn't the gap, the measurement mandate is", en één keer omdat Tradeify SEON gebruikt en hun CEO zegt dat multi-account-aanmaak zijn grootste fraudeprobleem was. Nooit als kanaal. Dat is de nieuwe hoek. Wie het is. SEON Technologies, opgericht in Boedapest, met kantoren in Austin, Londen, Boedapest en Singapore; naar eigen opgave meer dan 5.000 klanten en een Series C van meer dan 67 miljoen euro. Product: toestel-intelligentie (fingerprinting via JavaScript en iOS/Android-SDK's, detectie van VPN's, proxy's, emulators) plus digitale-voetafdrukverrijking die een e-mail of telefoonnummer tegen honderden platformen aftoetst. Ze verkopen expliciet block multi-accounting with Device Intelligence en publiceren dat 23% van de iGaming-verliezen aan promotiemisbruik hangt (SEON Docs, SEON iGaming-onderzoek 2026). Waarom dit een kanaal is en geen vijand. Hun klantenlijst is jouw doelgroep: iGaming, banken, marktplaatsen — precies de sectoren van cases 142 tot 152. Hun eigen zwakte staat in jouw catalogus beschreven en ze weten het zelf: tegenover fingerprinting staat een antidetect-industrie die ban-ontwijking als product verkoopt en in 2026 met meer dan 60% groeide. Wat jij levert is niet een betere vingerafdruk maar de laag eronder: één wortel per mens, die een verse browser overleeft. Eén SEON-klant overtuigen kost evenveel werk als één webshop; SEON overtuigen levert er vijfduizend. 🔌 Integratievorm — C (REST-API) als extra signaal in hún score. Opzetpad: (1) draait al — attestatie en verificatie; (2) Franky bouwt — één signaalveld in het formaat dat zij al lezen (een boolean plus een pseudoniem-hash, geen naam), 2 tot 3 dagen, plus een pagina die het verschil tussen hun laag en jouw laag in één plaatje uitlegt; (3) de klant doet — het veld meesturen in de bestaande API-call; (4) standaard — JWS-attest, hun bestaande scorecontract onaangeroerd; (5) kleinste demo zonder toestemming — twee antidetect-profielen tegen hun eigen publieke demo, met daarnaast hetzelfde pseudoniem uit jouw attest. 🧩 Productmix: V + D, meter M1 bij eerste verificatie, M2 daarna; geldvorm LICENTIE of fee per attestatie, dus trede 2 en geen Nele nodig. Wie contacteren: product- of partnershipsverantwoordelijke fraudepreventie — de kant die integraties bouwt, niet de accountmanagers. Openingszin: "Jullie schrijven zelf dat het gat niet de detectie is maar de meting. Ik lever de meeteenheid: één onomkeerbare code per mens, uit een Belgische eID, die een verse browser en een nieuwe proxy overleeft. Naast jullie score, niet in de plaats ervan — en jullie klanten in iGaming en marktplaatsen vragen er vandaag al om." ⚠️ Niet geverifieerd: of SEON een partnerprogramma heeft dat externe signalen aanvaardt. Zoek dat uit vóór het gesprek; het bepaalt of dit een integratie of een doorverkoop wordt.
28-08⚛️ Eén vondst die geen klant is maar jouw eigen fundament raakt: Amerika begon gisteren zijn identiteitsbewijzen kwantumbestendig te maken, en het woord "kwantum" komt in heel r4m maX nul keer voor — Wat r4m maX hierover al zegt: niets. Ik heb er alle bestanden op doorzocht: quantum, kwantum en crypto-agiliteit leveren nul treffers op. Wat er wél staat, op vier plaatsen (bouwboek, testboek, doorloop, catalogus): R4M tekent zijn attesten met Ed25519. Dat is een klassieke handtekening, geen kwantumbestendige. De vondst. Op 27 augustus 2026 is bekendgemaakt dat de Amerikaanse GSA begint aan de overgang van federale identiteitsbewijzen en toegangssystemen naar post-kwantumcryptografie. Elke federale dienst moet vóór 22 oktober 2026 een migratieplan indienen bij OMB en de Office of the National Cyber Director. De planning: verkenning in 2026-2027, proeven in 2027-2028, prioritaire migratie tot 2030, post-kwantum digitale handtekeningen voor systemen met hoge impact tegen 2031, de rest tegen 2035. De NIST-algoritmen die genoemd worden: ML-DSA voor handtekeningen, ML-KEM voor sleuteluitwisseling, SLH-DSA als alternatief (Biometric Update, 27-08-2026). Waarom dit hier op de radar staat en niet in de prullenmand. Niet omdat er morgen iets breekt — dat is niet zo, en dat moet je ook niet zeggen. Wél omdat een attest van R4M een handtekening ís, en de kopers die je nastreeft (overheid, bank, uitgever, verzekeraar) binnen twee jaar een leveranciersvragenlijst gaan sturen waarop "crypto-agility / PQC-plan" staat. Vandaag heb je op die vraag geen antwoord, ook geen slecht antwoord — de vraag bestaat niet in het dossier. De goedkope versie van het antwoord, en waarom hij goedkoop is: een attest van R4M leeft kort en wordt vers uitgegeven bij elke controle. Iets dat vandaag geldig is en morgen vervalt, is een veel kleiner kwantumprobleem dan een certificaat van tien jaar of een archief dat decennia bewaard blijft — "harvest now, decrypt later" bijt op lange geheimen, niet op verse handtekeningen. Dat is een sterk verhaal, maar het staat nergens opgeschreven, en zolang dat zo is kun je het niet tonen. 🔌 Integratievorm — niet van toepassing; dit is geen verkoop maar een dossierstuk. 🧩 Productmix — raakt V, C, P, O, G en D tegelijk, want ze hangen allemaal aan dezelfde handtekening. Zo zet je dit in de markt: als je het opschrijft, is het een voorsprong in plaats van een gat. Eén alinea in het Fundament ("waarom een kort levend attest een klein kwantumrisico is, en welk pad we nemen als een klant PQC eist"), één regel in het Testboek ("PQC-migratiepad: NIET getest, niet gepland — bewust"), en één vraag voor Nele of voor de eerste grote klant: eist iemand het contractueel? Geen bouwtrigger, geen paniek — één beslissing van Franky: schrijven we dit op, of laten we het bewust leeg tot een klant het vraagt?
28-08🚚 De verdienkant is geen niche meer: DoorDash zet 8 miljoen koeriers in als opnameploeg — maar dat is een slechtere prospect dan Figure, niet een betere — De radar draait sinds eergisteren rond Figure Index alsof dat de enige speler was. Dat klopt niet. DoorDash lanceerde in maart 2026 een aparte app, Tasks, en zet daarmee zijn 8 miljoen Amerikaanse koeriers in om zichzelf te filmen: vaatwasser inladen, met de hand afwassen, kleren vouwen, plus ongeschreven gesprekken in het Spaans. Eén opdracht vraagt letterlijk een bodycam gericht op de handen, minstens vijf borden, elk schoon bord een paar seconden stil in beeld. Het tarief staat vooraf vast en stijgt met de moeilijkheid — planten verpotten betaalt meer dan afwassen (Forbes 20-03-2026, NBC News). Daarnaast huren Scale AI en micro1 duizenden gigwerkers in 50+ landen voor exact hetzelfde werk (MIT Technology Review 01-04-2026). Wat dit betekent, en waar ik mezelf moet corrigeren. (a) De koper is een categorie geworden. De zin uit de studie van 2 juli dat "de verdienkant leeg is" is niet alleen voor Figure onwaar maar voor de hele niche, en Figure heeft niet eens de grootste distributie. (b) Maar de verleiding om DoorDash meteen op de lijst te zetten is een fout. Een Dasher is geen vers account: die is al aangeworven als 1099-contractant en door een screening gegaan. DoorDash koopt dus niet "is dit een mens" maar hoogstens "is dit dezelfde mens die we al screenden". Dat is een andere verkoop — hercontrole en binding, meter M2, de goedkope meter — en géén eerste-verificatie (M1). Wie DoorDash en Index in dezelfde zin zet, verkoopt aan één van de twee het verkeerde product. De scherpste prospect van de drie is de derde: Scale AI en micro1 werven in 50+ landen zonder bestaand contractantenbestand eronder — daar is geen screening-wortel, geen bodycam-protocol en geen bestaande relatie, en dus precies het gat waar M1 op zijn plaats valt. ⚠️ Wat ik NIET geverifieerd heb, en dus niet mag zeggen tegen een klant: in geen van de gevonden bronnen staat wat DoorDash, Scale AI of micro1 bij uitbetaling aan identiteitscontrole afdwingt. Dat Dashers gescreend worden is algemeen bekend, maar dat is hier een afleiding en geen bron. Openstaand: publiceert iemand van de drie een dubbel-account- of fraudecijfer, en doen Scale/micro1 iets aan uniciteit in die 50+ landen. Geen bouwtrigger — drie kopers om te verifiëren, in die volgorde.
27-08🔍 Nagekeken bij de bron: Figure controleert wél op fraude — maar niet op mensen. Dat maakt de deur groter, niet kleiner — De radar-entry van vanmiddag zei dat er bij Index "nergens publiek staat dat één mens maar één account krijgt". Vanavond is de aankondiging van Figure zelf regel voor regel nagelezen, en die zin moet scherper. Er ís een laag, en Figure beschrijft hem in twee zinnen: ze berekenen van elk videofragment een vingerafdruk en gooien alles weg dat te veel op eerder aanvaard materiaal lijkt, en menselijke analisten bekijken steekproeven op accountniveau om te zien wie bewust probeert die filter te omzeilen. Lees precies wat daar staat. Het eerste is een filter op de inhoud — twee video's die te veel op elkaar lijken. Het tweede is een steekproef door mensen. Geen van beide zegt iets over de vraag of twee accounts twee personen zijn. Dezelfde persoon die dezelfde afwas in een andere keuken filmt, komt er per definitie door: de video's lijken niet op elkaar, want de keuken verschilt. Waarom dit de verkooplijn versterkt in plaats van hem te breken: dit is exact dezelfde wig als bij de enquêtepanels. Detectie is een tredmolen die je elke modelgeneratie opnieuw moet winnen, en ze schaalt door te steekproeven. Uniciteit met een eID-wortel is de uitgang, en die schaalt door constructie. Bij 15 miljoen dollar uitbetaald en 1 miljard toegezegd is een steekproef-audit de dure manier om een garantie te kopen die R4M gewoon verkoopt. Het gesprek begint nu niet meer met "jullie zijn fraude vergeten" — dat zou onwaar zijn en men zou het meteen weerleggen — maar met "jullie laag herkent kopieën, niet mensen, en dat verschil kost geld per uitbetaling". Wat nog open staat: hun echte dubbel-accountcijfer publiceren ze niet, en of Figure zo'n laag koopt in plaats van bouwt weten we pas als iemand het vraagt. bron: Figure, aankondiging Index (primaire bron) ↗ Correctie op de entry hierboven: die stelde het te absoluut. De radar corrigeert zichzelf liever dan hij gelijk houdt — ook tegen zijn eigen vondst van drie uur eerder.
27-08🤖 De verdienkant is niet langer leeg — een robotbedrijf betaalt sinds gisteren mensen om te filmen hoe ze afwassen, en heeft er al 15 miljoen dollar op staan — Figure lanceerde op 26 augustus 2026 Index: een klusjesmarkt waar gewone mensen zichzelf filmen terwijl ze huishoudelijke taken doen, als trainingsmateriaal voor de Helix-robot. De cijfers zijn geen belofte maar gemeten: 15 miljoen dollar al uitbetaald aan "creators", ongeveer 15 dollar per uur, 16 miljoen video's uit 108 landen, 264.000 app-downloads en 44.000 wekelijks actieve gebruikers. Figure zegt er 1 miljard dollar aan data en rekenkracht tegenaan te gooien het komende jaar. Waarom dit hier staat en niet bij de leuke weetjes: het dossier van 2 juli hield vol dat iedereen de uitgeefkant bouwt en de verdienkant open lag. Voor deze niche klopt die zin sinds gisteren niet meer — er zit een eerste speler, en die heeft al 44.000 mensen die er wekelijks geld mee verdienen. Maar lees de tweede helft, want daar zit jouw deur: een markt die per upload betaalt, aan 15 dollar per uur, in 108 landen, zonder dat er ergens publiek staat dat één mens maar één account krijgt — dat is het schoolvoorbeeld van een sybil-doelwit. Dezelfde afwas, vijf keer gefilmd, vijf keer uitbetaald aan dezelfde persoon achter vijf accounts. Bij 15 miljoen dollar uitbetaald is elk procent fraude 150.000 dollar. Precies dat verkoopt R4M Pass: één bewezen mens, één plek, paarsgewijs per klant zodat twee afnemers hun mensen nooit aan elkaar kunnen koppelen — en de motor heeft de bijhorende sloten al op de kaart staan (evidence-hash ontdubbeling en eerlijkheidsplafond per werker, stappen 4b en 4d). Eerlijk over wat dit NIET is: geen bouwopdracht en geen klant. Het is een te verifiëren koper. De vraag die eerst beantwoord moet worden: controleert Index vandaag al uniciteit bij uitbetaling, hoe hoog is hun dubbel-account-cijfer, en koopt een robotbouwer zo'n laag liever dan hem zelf te bouwen — Figure, of een navolger als Tesla, Dyna Robotics of 1X. bron: Forbes, 26-08-2026 ↗ bevestigd door Humanoids Daily ↗ en TechSpot ↗ Correctie op de vondst van vanochtend: die sloot af met "geen enkele nieuwe speler aan de verdienkant". Dat was waar op het moment van schrijven en is het nu niet meer — deze radar corrigeert zichzelf liever dan hij gelijk houdt.
27-08💸 De rail waar je op rijdt kreeg een versie 2 — en het goede nieuws is dat je niets moet doen. Wél verschoof Circle stilletjes waar zijn geld naartoe gaat — x402 V2 staat sinds 24 juni 2026 op x402.org en breekt uit het oude model van één oproep met één vast bedrag: meerdere ketens naast Base (Solana, andere L2's) én klassieke betaalrails onder één interface, dynamische payTo-routing (adres en prijs per aanvraag instelbaar), nieuwe kopteksten (PAYMENT-SIGNATURE, PAYMENT-REQUIRED, PAYMENT-RESPONSE), een plugin-SDK zodat je een keten of betaalschema kan registreren zonder de kern aan te raken, automatische ontdekking van diensten en prijzen door facilitators, en geformaliseerde Extensions zodat experimenteren geen fork meer vraagt. Wat dit voor R4M betekent, eerlijk gemeten: geen brandje. De referentie-SDK's zijn volgens dezelfde aankondiging volledig achterwaarts compatibel met V1 — er is geen verplichte migratie, de bestaande 402-muur blijft staan. Twee dingen zijn wél de moeite: dynamische payTo-routing is precies wat een uitbetaling-per-mens nodig heeft (vandaag hangt het uitbetaaladres aan de installatie, niet aan de aanvraag), en Extensions is de plek waar een uniciteits- of mandaatveld kan landen zonder iemands toestemming. bron: x402.org, bijgewerkt 24-06-2026 ↗ Tweede vondst, uit het financieringsdossier: Circle Developer Grants — in het dossier al twee maanden aangemerkt als "de best passende ondersteuning die bestaat" — is van adres én van focus veranderd: niet langer circle.questbook.app als ingang maar circle.com/grant, en het programma van 2026 richt zich nu expliciet op wie bouwt op Arc en het Circle Developer Platform. De eerste lichting van 2026 (19 startups) is in maart al gekozen. agentic economic activity staat nog steeds met zoveel woorden in de doelen, dus de inhoudelijke match blijft — maar de vrijblijvende versie ("een pot geld voor x402-bouwers") klopt niet meer. bron: circle.com/grant, nagekeken 27-08-2026 ↗ Niet gevonden vannacht: geen enkele nieuwe speler aan de verdienkant — betaalde-aandacht-inbox, dividendrail, robot-inkomen, uitbetaling op bewezen mens-zijn. Alles wat beweegt bouwt nog altijd de uitgeefkant. Dat is de wig, en hij staat na 24 uur nog open.
27-08⚠ CORRECTIE OP DE VONDST HIERONDER — nagekeken 27-08 om 16:30
De feiten kloppen, de weging niet. Het item hieronder brengt "x401 is van Proof" als de belangrijkste vondst van de nacht en als een beslissing die jouw positie op losse schroeven zet. Dat was fout, en het is nagekeken op je eigen pagina's: x401 zegt al weken letterlijk dat het "een open protocol van het Amerikaanse identiteitsbedrijf Proof" is, dat iedereen uitgever mag worden, dat er nog géén uitgever op Europese overheids-identiteit steunt, en dat R4M die lege stoel neemt. Je bouwregel f1 zegt bovendien al: geen eigen identiteitsprotocol standaardiseren, wij implementeren open standaarden. De nachtploeg presenteerde dus bekende, al ingenomen grond als nieuw terrein — en het ochtendrapport nam die weging over.
Wat er wél nieuw was en blijft staan: de spec zelf, nagelezen op 27-08. Headers PROOF-REQUIRED / PROOF-PRESENTATION / PROOF-RESPONSE, presentatie via OpenID4VP (dezelfde standaard als de EUDI-wallet en itsme), formaat jwt_vc_json, bevraging via DCQL, vereiste graad VC-AL2/AL3, en hun eigen zin "any CA can issue conformant credentials" — uitgever worden vraagt dus geen toestemming, alleen conformiteit. Dat staat als conformiteitsblad op de x401-pagina.
Wat er te doen is: geen naamsbeslissing. Eén half-ware zin repareren — "x401-compatibel" op kaart.html is vandaag een ambitie, geen eigenschap — en het conformiteitsgat sluiten wanneer je daaraan toe bent.
De les, en die geldt voor élke vondst: een routine die de markt afspeurt moet éérst lezen wat r4m maX al zegt, en pas dan wegen of iets nieuw is. Anders wordt bekende grond als ontdekking verkocht. Die poort staat nu in de nachtploeg-routine en in het ochtendrapport.
Wat er wél nieuw was en blijft staan: de spec zelf, nagelezen op 27-08. Headers PROOF-REQUIRED / PROOF-PRESENTATION / PROOF-RESPONSE, presentatie via OpenID4VP (dezelfde standaard als de EUDI-wallet en itsme), formaat jwt_vc_json, bevraging via DCQL, vereiste graad VC-AL2/AL3, en hun eigen zin "any CA can issue conformant credentials" — uitgever worden vraagt dus geen toestemming, alleen conformiteit. Dat staat als conformiteitsblad op de x401-pagina.
Wat er te doen is: geen naamsbeslissing. Eén half-ware zin repareren — "x401-compatibel" op kaart.html is vandaag een ambitie, geen eigenschap — en het conformiteitsgat sluiten wanneer je daaraan toe bent.
De les, en die geldt voor élke vondst: een routine die de markt afspeurt moet éérst lezen wat r4m maX al zegt, en pas dan wegen of iets nieuw is. Anders wordt bekende grond als ontdekking verkocht. Die poort staat nu in de nachtploeg-routine en in het ochtendrapport.
27-08🤝 x401 bestaat nu écht — en het is niet van jou. Een Amerikaanse certificaatautoriteit heeft het protocol gebouwd dat jij op vijf pagina's als jouw tegenhanger van x402 beschrijft — op 25 juni 2026 lanceerde Proof (Amerikaans, CEO Pat Kinsel; naar eigen opgave een WebTrust-gecertificeerde certificaatautoriteit met FIPS 140-2 Level 3-HSM's en meer dan 8.000 vertrouwende partijen) een open, uitgever-neutraal HTTP-protocol met de naam x401. Het doet precies één ding: een delegatieketen van vier schakels — mens → getekend mandaat → agent → handelaar — die de handelaar cryptografisch kan natrekken, via twee nieuwe headers (PROOF-REQUIRED en PROOF-PRESENTATION). Twee vroege afnemers zijn bevestigd maar niet bij naam genoemd: een wereldwijd betaalnetwerk dat x401 als identiteitslaag neemt voor agent-transacties, en een Tier 1-verzekeraar die het bekijkt voor handelingen namens een klant. Circle's VP Product vat het samen als twee vragen na elkaar: "x402 answers how an agent pays, x401 answers who it is." bron: Forkast, 22-08-2026 ↗ In dezelfde maand richtte de Amerikaanse Secure Technology Alliance op 4 augustus 2026 het Agentic Trust and Commerce Forum op, samen met het U.S. Payments Forum, met agent-identiteit als een van de vier bestuursvragen en met LLM-aanbieders, handelaars, banken, identiteits- en fraudebedrijven en toezichthouders aan tafel. bron: persbericht STA via GlobeNewswire, 04-08-2026 ↗ Zo zet je dit in de markt: dit is de belangrijkste vondst van de nacht, en hij vraagt een beslissing van jou — niet vandaag, maar wel deze week. Op kaart.html, fundament.html, strategie.html en in jargon.js staat x401 beschreven als "onze tegenhanger van x402", en in de pitch staat letterlijk "x401-compatibel". Vanaf nu is dat geen zelfbedachte naam meer maar een bestaand protocol van een ander bedrijf, met headers die je kunt implementeren en waaraan iemand je kán afmeten. Twee wegen, en beide zijn goed — kiezen is wat telt. (1) Meelopen: je bouwt x401 na zoals Proof het publiceert, en dan is "x401-compatibel" plots een controleerbare, verkoopbare claim in plaats van een woordspeling. (2) Afbakenen: je hernoemt jouw lijn en zegt eerlijk waar je verschilt. En dat verschil is je sterkste argument: bij Proof komt het mandaat uit een certificaatautoriteit — een Amerikaanse partij die de identiteit van de mens kent en bewaart; bij jou hangt het aan een itsme-bevestiging door een bewezen unieke mens, gaat er een pseudoniem naar de handelaar en niet een naam, en ligt de kluis in Europa. Voeg daar de uitspraak bij die al in je catalogus zit: op 4 augustus 2026 oordeelde het Amerikaanse Ninth Circuit in Amazon v. Perplexity dat de assistent handelt als werktuig op instructie van de gebruiker — de handeling is dus die van de mens. Precies daarom wil iedereen nu weten wélke mens, en dat is het enige stuk dat noch Proof, noch de alliantie van Rain (radar 26-08), vandaag heeft. 🔌 Integratievorm: C (REST-API + webhooks) met een J-flank (x402-resource) — jouw attestatie-endpoint krijgt er één antwoordvorm bij die de x401-headers spreekt. Opzetpad: (1) wat draait al — de attestatie-engine tekent vandaag al Ed25519-JWS met een pairwise pseudoniem, dat is de inhoud van een mandaat; (2) wat bouw jij — de x401-headers lezen en beantwoorden plus een mandaat-object dat aan een itsme-bevestiging hangt, geschat 4-6 dagen; (3) wat doet de klant — één header-check in zijn checkout; (4) welke standaard — x401 zoals Proof het publiceert, naast x402 voor de betaling; (5) kleinste demo zonder toestemming — een publieke testpagina die een agent weigert zonder geldig mandaat en doorlaat mét, met de keten zichtbaar. 🧩 Productmix: V (is er een echte unieke mens) + C (welk mandaat, welke limiet, intrekbaar) als kern, O zodra er een bon over moet, D voor het intrekken. Trede: dit is attestatiewerk, dus nu al verkoopbaar — geen geldstroom nodig. Meter: M1 eenmalig per nieuwe mens, M2 op elke mandaatcontrole; M3 loopt pas mee als je de betaling erbij neemt (na PRIO B). Groeipad: eerst het mandaat-attest los verkopen, later de rail bijschakelen. Concrete verkooproute: niet naar Proof — je bent daar leverancier noch concurrent, je bent te klein om hun standaard te herschrijven. Ga naar wie in Europa een agent aan de kassa krijgt en geen Amerikaanse CA wil: Worldline (Brussel) en Mollie (Amsterdam), dezelfde route als bij de Rain-vondst van gisteren. Openingszin: "Er is sinds juni een Amerikaans protocol dat bewijst namens wie een agent handelt, en een Amerikaanse rechter heeft in augustus gezegd dat de handeling van de mens is. Ik lever hetzelfde bewijs, maar het mandaat hangt aan een itsme-bevestiging en uw handelaar krijgt een pseudoniem in plaats van een naam — dat is het verschil tussen bewijzen en verzamelen."
27-08🤖 AWS gaf negen dagen geleden elke agent een portemonnee — met limieten, met logboek, en zonder één regel over wie hem opendraait — op 18 augustus 2026 zette Amazon Web Services AgentCore payments in Amazon Bedrock AgentCore op algemene beschikbaarheid: AI-agents kunnen daarmee zelfstandig betaalde API's, MCP-servers en content ontdekken, openen en betalen, met een paar regels code. De betaling loopt over x402 en over wallets van Coinbase en Stripe/Privy; AWS bouwde er voor de GA een "Quick Create" voor Coinbase bij, zodat een ontwikkelaar zijn betaalgegevens niet meer buiten AgentCore hoeft te regelen. Wat er wél in zit: configureerbare betaallimieten op infrastructuurniveau en volledige waarneembaarheid. bron: AWS What's New, 18-08-2026 ↗ — achtergrond bij de preview van mei 2026: AWS Machine Learning Blog ↗ Zo zet je dit in de markt: lees wat er níét in de aankondiging staat. Er staat geen woord over menselijke goedkeuring, over de identiteit van de opdrachtgever, of over hoe je achteraf vaststelt wie deze agent losliet. De enige rem is een bedrag. Dat is exact de vorm van het gat: de grootste cloudleverancier ter wereld levert nu standaard de mogelijkheid om geld uit te geven, en de vraag "namens wie" is aan de klant gelaten. Zeg dat vanaf nu zo tegen elke Europese partij: de limiet beschermt je tegen een dure fout, niet tegen een onbevoegde fout — en het is de tweede die je voor de rechter brengt. 🔌 Integratievorm: J (x402-resource) plus C (REST-API). Opzetpad: (1) draait al — de x402-adapters (usdc-base en eurc-base) staan op testnet en de attestatie-engine tekent al; (2) jij bouwt — een AgentCore-compatibele resource die vóór het vrijgeven van het antwoord een R4M-mandaatattest eist, geschat 3-4 dagen, plus een voorbeeldagent; (3) de klant doet — zijn agent één header laten meesturen; (4) standaard — x402 (Linux Foundation) voor de betaling, jouw attest voor de bevoegdheid; (5) kleinste demo — één betaalde endpoint online zetten die een AgentCore-agent weigert zolang er geen mandaat bij zit. 🧩 Productmix: C (bevoegdheidskaart met limiet en intrekknop) is hier de hoofdmodule, V eronder voor de mens die tekent, O voor de bon. Meter: M2 per controle; M3 pas als het geld over jouw rail loopt — dus na PRIO B, en zeg dat er eerlijk bij. Concrete verkooproute: AWS zelf is te groot en te ver; ga naar de Belgische en Nederlandse bouwers die vandaag op Bedrock bouwen en morgen aan een klant moeten uitleggen wie die betaling gaf. Openingszin: "Sinds 18 augustus kan uw agent bij AWS uit de doos betalen, met een limiet als enige rem. Ik lever het stuk dat er niet in zit: een intrekbaar mandaat van een bewezen mens, zodat u bij een betwisting iets in handen heeft dan een bedrag."
27-08💸 x402 heeft sinds juni een identiteitslaag — en die identiteit is een wallet. Precies de verwarring waar jouw hele verhaal tussen past — op 24 juni 2026 publiceerde het x402-project x402 V2. Nieuw daarin: meerdere ketens (Base, Solana en andere), dynamische ontvangers per verzoek, automatische API-ontdekking, een modulaire SDK, ondersteuning voor klassieke betaalwegen (ACH, SEPA, kaarten) — en, het stuk dat jou aangaat, "wallet-based identity": een client kan de volledige betaalstroom overslaan door een door de wallet beheerde sessie op te zetten, waarna hij herbruikbare toegang heeft zonder telkens opnieuw on-chain te gaan. bron: x402.org, 24-06-2026 ↗ Drie weken later, op 14 juli 2026, ging het protocol onder de Linux Foundation operationeel als de x402 Foundation, met 40 leden en als premier-leden onder meer Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, MoonPay, Ripple, Shopify, Solana Foundation, Stellar, Stripe en Visa. bron: persbericht Linux Foundation, 14-07-2026 ↗ Correctie op wat hier eerder stond: de radar-entry van 22-08 zegt dat x402 "sinds maart 2026 bestuurd wordt door een Foundation van Coinbase én Cloudflare samen". Dat is achterhaald — het bestuur ligt sinds 14 juli bij de Linux Foundation, met veertig leden waaronder beide. Zo zet je dit in de markt: "wallet-based identity" is het scherpste voorbeeld dat je kunt geven van wat er misgaat. Een wallet is geen mens. Eén mens kan er duizend maken, en duizend mensen kunnen er één delen. Een sessie die aan een wallet hangt, zegt dus dat deze sleutel terugkomt — niet dat deze mens terugkomt. De hele agent-economie noemt dat nu "identiteit", en dat is precies het misverstand waar jouw laag bovenop gaat: x402 regelt hoe er betaald wordt, x401 (zie hierboven) wie de agent is, en R4M als enige dat er één echte mens achter zit die er ook maar één kan zijn. Gebruik de veertig namen als bewijs dat je op een gedragen standaard bouwt en niets zelf hoeft te onderhouden — dat is een antwoord op de vraag die Nele zeker stelt: wat als jouw protocol doodbloedt. 🔌 Integratievorm: J (x402-resource). Opzetpad: (1) draait al — beide adapters op testnet, fail-closed bij een verkeerd tokenadres; (2) jij bouwt — meelopen met de V2-spec (dynamische ontvanger is wat je nodig hebt voor de commissiesplitsing zonder geld door jouw handen, V57), geschat 2-3 dagen leeswerk plus een adapterupdate; (3) de klant — niets, hij is al x402-klant; (4) standaard — x402 V2 onder de Linux Foundation; (5) kleinste demo — een wallet-sessie opzetten en tonen dat een tweede wallet van dezelfde mens gewoon doorloopt, en dat jouw laag hem tegenhoudt. 🧩 Productmix: V + G (de poort die de betaling voorafgaat), O voor de bon. Meter: M2 op elke poortcontrole; M3 alleen op de tol zelf, en dat is na PRIO B. Concrete verkooproute: de partij die dit vandaag het hardst nodig heeft is een uitgever of hoster die de tol al overweegt — Combell / team.blue staat al in de doelwitten. Openingszin: "x402 noemt sinds juni een wallet een identiteit. Een wallet is geen mens — één mens maakt er duizend. Ik lever de laag die zegt dat er precies één mens achter zit, en die past bovenop de standaard die Visa, Stripe en AWS net samen zijn gaan besturen."
27-08🆔 De CEO van Reddit heeft jouw verkooppraatje in één zin gezegd: hij wil weten dát je een mens bent, en uitdrukkelijk niet wíe je bent — Steve Huffman, CEO van Reddit (San Francisco, beursgenoteerd, honderden miljoenen gebruikers), vertelde in een interview met TBPN dat Reddit worstelt met het bewijzen dat er een mens achter een account zit. Hij noemt het zelf "ass in seat" en zegt dat biometrie op het toestel — Face ID, Touch ID, biometrische passkeys — "the most lightweight way" is: "a human has to touch or do or look at something. That gets you pretty far." Reddit bekeek eerder World en zijn World ID daarvoor. Het beslissende stuk staat er meteen achter: Reddit wil de verificatie zonder te weten wie de persoon is — anonimiteit is de reden dat mensen er schrijven — en Huffman zegt dat hij een groeiende markt ziet voor diensten die precies dat leveren. Dezelfde bron vermeldt dat de Britse toezichthouder ICO Reddit een boete van 14,47 miljoen pond oplegde wegens ontoereikende leeftijdsborging. bron: Biometric Update, 24-03-2026 ↗ Zo zet je dit in de markt: je hoeft de behoefte niet meer uit te leggen — de CEO van een beursgenoteerd platform heeft ze publiek geformuleerd, en hij formuleert ze in jouw woorden: bewijzen zonder kennen. Gebruik dit citaat bij Nele als antwoord op "is hier een markt voor", en bij elke klant als antwoord op "waarom zou ik dit willen". En zeg er meteen bij waarom het bij Reddit nog niet opgelost is: Face ID bewijst dat er een vinger of gezicht aan het toestel zit, niet dat het dezelfde mens is als het account dat vorige maand geweerd werd — één mens met drie telefoons is drie keer "ass in seat". Dat verschil tussen levendheid en uniciteit is je hele product in één zin, en het is meteen het antwoord op de World-vraag: World lost uniciteit wél op, maar met een irisscan, en werd daarom in Spanje, Portugal, Kenia, Brazilië en Indonesië buitengezet (radar 23-08). 🔌 Integratievorm: B (OIDC — "Log in met R4M") als hoofdvorm, met A (widget) als kleinste variant. In gewone taal: het platform zet naast "Log in met Google" een knop die de gebruiker één keer langs de mensenpoort stuurt en er een pseudoniem uit terugkrijgt. Opzetpad: (1) draait al — attestatie-engine, pairwise pseudoniem per afnemer, eID-demo; (2) jij bouwt — de OIDC-façade op het bestaande endpoint (discovery, authorize, token, JWKS), geschat 3-5 dagen; (3) de klant — één redirect-URL registreren, zoals bij elke sociale login; (4) standaard — OpenID Connect, met eIDAS/itsme eronder; (5) kleinste demo — een publieke testsite met een forum waar een tweede account van dezelfde mens geweigerd wordt, zonder dat er ergens een naam staat. 🧩 Productmix: V als kern, D erbij (de ban die aan de mens hangt in plaats van aan het account — dat is wat een forum écht koopt), G voor besloten ruimtes. Geen geldstroom: dit is Rail 1, vandaag verkoopbaar. Meter: M1 eenmalig per nieuwe mens (draagt de itsme-kost), M2 op elke raadpleging. Groeipad: klein starten met alleen de poort bij registratie, later de denylist bijschakelen. Concrete verkooproute: Reddit zelf is Amerikaans en groot — zet het op je lijst maar niet vooraan. Dezelfde vraag ligt hier dichterbij: Belgische en Nederlandse fora en communitysites met dezelfde anonimiteitsbelofte, en de uitgevers die er een hebben (DPG Media, Mediahuis — staan al in de doelwitten). Openingszin: "De CEO van Reddit zei in maart dat hij wil bewijzen dat er een mens achter een account zit, en er uitdrukkelijk niet bij wil weten wie. Dat is letterlijk wat ik lever — en anders dan een gezichtsscan houdt het ook stand als dezelfde mens met een tweede telefoon terugkomt."
27-08🆔 Bijna een derde van de aanwervers heeft al iemand geïnterviewd die zich met een vervalst gezicht voordeed — en de sector koopt er vandaag identiteit voor, niet uniciteit — uit een bevraging van Greenhouse (New York, aanwervingssoftware, naar eigen opgave meer dan 7.500 klanten waaronder HubSpot, Duolingo en Gong) onder 4.136 mensen zegt 31% zelf al een kandidaat te hebben gesproken van wie ze vermoedden of vaststelden dat hij een vervalste identiteit gebruikte; een tweede Greenhouse-rapport uit 2026 meldt dat 91% van de Amerikaanse aanwervers AI-gegenereerde antwoorden in een videogesprek herkende of vermoedde. Gartner voorspelt dat tegen 2028 één op de vier kandidaatprofielen wereldwijd vals is. Greenhouse kocht daar een oplossing voor in: het integreerde CLEAR (NYSE: YOU, meer dan 31 miljoen leden) zodat een kandidaat "een selfie neemt in zijn MyGreenhouse-profiel", die tegen zijn overheids-ID gelegd wordt. bron: persbericht CLEAR/Greenhouse, 12-06-2025 ↗ · cijfers samengevat, 2026 ↗ Zo zet je dit in de markt: dit is het beste bewijs dat er betaald wordt voor jouw soort antwoord — een beursgenoteerd identiteitsbedrijf zit al ingebouwd in de aanwervingssoftware van 7.500 werkgevers. En het is meteen het beste bewijs dat wat ze kochten niet volstaat in Europa: CLEAR legt een selfie naast een identiteitskaart en bewaart dus biometrie én identiteit, precies waar de Spaanse toezichthouder Yoti in maart 2026 950.000 euro voor beboette (radar 25-08). Jouw versie doet het omgekeerd: geen gezicht, geen document bij de werkgever, alleen een pseudoniem dat zegt "één echte, unieke mens, en dezelfde als de kandidaat die vorige week solliciteerde". Voeg er de eerlijke grens bij: jij bewijst niet dat de mens vóór de camera dezelfde is als op het cv — je bewijst dat er één echte mens is en dat hij niet onder vijf namen tegelijk binnenkomt. Dat is minder dan wat ze vragen en méér dan wat ze hebben. 🔌 Integratievorm: D (platform-app in hún winkel) is hier het pad met hefboom, met C (REST-API) als eerste stap. In gewone taal: één app in de Greenhouse- of Workday-marktplaats die bij het uitnodigen van een kandidaat een R4M-poort inschuift. Opzetpad: (1) draait al — attest, pseudoniem, eID-demo; (2) jij bouwt — eerst de REST-koppeling (klaar), daarna de marktplaats-app volgens hún standaard en door hún review, reken op weken, niet dagen; (3) de klant — installeert de app en zet hem aan per vacature; (4) standaard — OIDC eronder, itsme/EUDI als voordeur; (5) kleinste demo — een uitnodigingslink die weigert wanneer dezelfde mens zich een tweede keer aanmeldt. 🧩 Productmix: V als kern, D erbij voor de kandidaat die onder een tweede naam terugkomt, C zodra de recruiter zelf bewezen moet zijn (dat is case 19). Geen geldstroom — Rail 1, vandaag verkoopbaar. Meter: M1 per nieuwe kandidaat, M2 op elke herhaalcontrole. Concrete verkooproute: niet Greenhouse zelf als eerste — de Belgische en Nederlandse markt heeft eigen aanwervingsplatformen en uitzendgroepen die dezelfde vraag krijgen en géén CLEAR hebben. Openingszin: "Eén op drie aanwervers heeft al een kandidaat gesproken met een vervalst gezicht, en de Amerikaanse oplossing daarvoor is een selfie naast een identiteitskaart — die u in Europa moet bewaren en verantwoorden. Ik geef u hetzelfde antwoord zonder één gezicht op te slaan: dit is een echte mens, en het is niet zijn derde profiel."
27-08💶 Geld-case — een AI-databedrijf van tien miljard betaalt 40.000 mensen uit, bewaarde hun gezichten en identiteitsbewijzen om ze te herkennen, en verloor precies dat pakket — Mercor (San Francisco, opgericht in 2023 door Brendan Foody, Adarsh Hiremath en Surya Midha; gewaardeerd op 10 miljard dollar bij een Series C in oktober 2025; levert menselijk beoordelingswerk aan Meta, OpenAI, Anthropic en Google) raakte op 27 maart 2026 ongeveer 4 terabyte data kwijt na een toeleveringsaanval: aangevallers publiceerden veertig minuten lang vergiftigde versies van de veelgebruikte bibliotheek LiteLLM op PyPI, nadat ze de gegevens van de beheerder hadden bemachtigd. In de buit zaten volgens de berichtgeving 939 GB broncode, een gebruikersdatabank van 211 GB en ongeveer 3 TB video-opnames van sollicitatiegesprekken en identiteitsdocumenten, plus namen en Amerikaanse rijksregisternummers van meer dan 40.000 huidige en vroegere medewerkers. Meta zette de samenwerking stil. bron: The Next Web, 04-04-2026 ↗ Daarna volgden in de Verenigde Staten meerdere verzoeken tot groepsvordering van werkers; de verwijten daarin — onvoldoende beveiliging, bewaarde gezichtsbiometrie, gedeelde achtergrondcontroles — zijn aantijgingen, geen vaststaand feit. bron: Jerusalem Post over de rechtszaken ↗ Zo zet je dit in de markt: dit is de zuiverste geld-case die je kunt vertellen, want alle drie de meters lopen tegelijk. Zo'n platform moet drie dingen kunnen: (1) weten dat een nieuwe werker een echte, unieke mens is — anders krijgt één persoon vijf accounts en vijf keer hetzelfde takenpakket; (2) hem bij elke opdracht herkennen zonder zijn dossier open te trekken; (3) hem uitbetalen aan een adres dat aan díe mens hangt. Vandaag lost de sector alle drie op door het zwaarste denkbare pakket te bewaren — video, identiteitsbewijs, rijksregisternummer — en Mercor toont wat er dan gebeurt wanneer één bibliotheek van derden veertig minuten besmet is. Jouw antwoord is niet "beter beveiligen", het is minder bewaren: één itsme-verificatie bij het begin, daarna een pseudoniem dat nergens naar een naam leidt, en een uitbetaalplaat die aan de mens hangt in plaats van aan een profiel. Wat er dan lekt is een lijst betekenisloze pseudoniemen. Geldvorm: UITBETALING (uitkeringsrail, fiat of stablecoin) bovenop LICENTIE voor de poort. Meter: M1 eenmalig per nieuwe werker · M2 op elke opdrachtcontrole, massaal · M3 op elke uitbetaling. Wanneer: de poort en de attestatie zijn nu; het uitbetaaldeel is na PRIO B — dat is de juridische poort bij Nele, en je verkoopt het niet daarvoor. 🔌 Integratievorm: C (REST-API + webhooks) voor de poort, P-koppeling voor de uitbetaling, I (batch/CSV) voor de bestaande 40.000 die opnieuw gebonden moeten worden. Opzetpad: (1) draait al — de volledige geldweg draait end-to-end op testnet, met publiek kasboek en vijf invarianten; (2) jij bouwt — de bindingsstap en de batch-import, plus mainnet-configuratie (een configuratiestap, geen herbouw); (3) de klant — één API-call bij het aanmaken van een werker en één bij elke uitbetaling; (4) standaard — x402/EURC voor de machinekant, Stripe voor euro's; (5) kleinste demo — de bestaande demo die een tweede account van dezelfde mens weigert en de uitbetaling toch laat aankomen. 🧩 Productmix: V + P + O als hart, D voor wie geweerd is, C zodra een teamleider namens de klant tekent. Trede: begint bij attestatie (nu), landt op de rail (na PRIO B) — precies het groeipad dat je overal wil verkopen. Concrete verkooproute: Mercor zit midden in rechtszaken en is nu geen koper — het is je verhaal, niet je prospect. De koper is de volgende in de rij die hetzelfde doet en het niet wil meemaken: Europese aanbieders van menselijk beoordelings- en onderzoekswerk, en de labs die er rechtstreeks mee werken. Openingszin: "In maart verloor een AI-databedrijf van tien miljard drie terabyte aan sollicitatievideo's en identiteitsbewijzen van veertigduizend mensen, omdat het die moest bewaren om ze te kunnen herkennen en uitbetalen. Ik laat u hetzelfde doen zonder één van die bestanden aan te leggen."
27-08📡 Over vijftien dagen moet elke fabrikant van een verbonden product binnen 24 uur melden bij ENISA — en nergens staat wie er namens hem tekent — vanaf 11 september 2026 gelden de meldplichten van de Cyber Resilience Act: fabrikanten van producten met digitale elementen moeten actief uitgebuite kwetsbaarheden en ernstige incidenten melden aan ENISA en aan het nationale CSIRT, via het Single Reporting Platform dat op diezelfde dag operationeel moet zijn. De klok is kort: vroege waarschuwing binnen 24 uur, volledige melding binnen 72 uur, eindrapport binnen 14 dagen (kwetsbaarheid) of een maand (incident). bron: Europese Commissie, CRA reporting ↗ Wat er in die tekst niet staat, is minstens zo belangrijk: de pagina van de Commissie zegt niets over hoe een fabrikant zich bij dat platform legitimeert, en niets over een bij naam genoemde verantwoordelijke die de melding doet. Zo zet je dit in de markt: dit is de IoT-lijn van vannacht, en hij heeft een datum die over twee weken valt — dat maakt hem verkoopbaar zonder één woord overdrijving. Een meldplicht met een klok van 24 uur is in de praktijk een bevoegdheidsprobleem, geen techniekprobleem: er moet op zaterdagnacht iemand kunnen tekenen namens de fabrikant, die persoon moet dat mógen, en achteraf moet vaststaan dat hij het was. Vandaag hangt dat aan een gedeeld mailadres en een gedeeld wachtwoord. Dat is precies wat een bevoegdheidskaart oplost: een genoemde mens, met een rol, met een limiet in de tijd, intrekbaar op de dag dat hij vertrekt — en een spoor dat je aan de toezichthouder kunt tonen. Let op de eerlijke grens: je verkoopt hier geen naleving van de CRA, je verkoopt het bewijsstuk onder de handtekening. Zeg dat er zo bij, anders koop je een discussie die je niet kunt winnen. 🔌 Integratievorm: C (REST-API + webhooks) met B (OIDC) voor het aanmelden van de tekenaar, en K (contract + dunne techniek) voor wie het klein wil houden. In gewone taal: de fabrikant krijgt een sleutel; bij elke melding haalt zijn systeem één attest op dat zegt "deze bevoegde mens, op dit uur, met dit mandaat". Opzetpad: (1) draait al — attestatie-engine met Ed25519-JWS en 15 minuten geldigheid, precies de vorm van zo'n handtekeningbewijs; (2) jij bouwt — de bevoegdheidskaart met tijdslimiet en intrekknop, plus een klein meldingsscherm, geschat 4-5 dagen; (3) de klant — één koppeling in zijn incidentproces en een lijst wie mag tekenen; (4) standaard — OIDC en itsme/EUDI, met de CRA-termijnen als klok; (5) kleinste demo — een testmelding waarbij het attest van een ingetrokken bevoegdheid geweigerd wordt. 🧩 Productmix: C is hier de hoofdmodule (dit gaat over bevoegdheid, niet over uniciteit), met V eronder en O voor het bewijsspoor. Geen geldstroom naar mensen — Rail 1, nu verkoopbaar, geldvorm LICENTIE. Meter: M1 per nieuwe tekenaar, M2 op elke melding. Concrete verkooproute: Belgische en Nederlandse fabrikanten van verbonden producten die per 11 september onder de meldplicht vallen en vandaag geen tekenprocedure hebben, plus de sectorfederaties die hen voorbereiden — één gesprek daar bereikt tientallen fabrikanten tegelijk, dezelfde hefboom als bij de Loterij-koppeling (blok 5). Openingszin: "Vanaf 11 september heeft u 24 uur om een uitgebuite kwetsbaarheid te melden bij ENISA. De vraag is niet of uw systeem dat haalt, maar wie op zaterdagnacht namens u mag tekenen — en of u dat achteraf kunt bewijzen. Dat bewijsstuk lever ik."
27-08🔎 Nieuw toepassingsgebied dat nog niet in de catalogus staat: wie duwde deze versie naar de pakketregistratie? Veertig minuten met de sleutels van één beheerder kostte een bedrijf van tien miljard vier terabyte — de aanval waar de geld-case hierboven op stukliep, is zelf een toepassingsgebied dat nergens in je 197 cases voorkomt (geen enkele case noemt een pakketregistratie, een beheerder of een uitgifte). Wat er gebeurde: op 27 maart 2026 bemachtigde een aanvallersgroep de gegevens van de beheerder van de bibliotheek LiteLLM en publiceerde daarmee twee vergiftigde versies (1.82.7 en 1.82.8) op PyPI. Ze stonden er ongeveer veertig minuten, en dat volstond: de pakketten harkten omgevingsvariabelen, API-sleutels, SSH-gegevens en cloudconfiguraties op bij iedereen die ze in dat venster installeerde. bron: The Next Web, 04-04-2026 ↗ Waarom dit een R4M-toepassing is en geen beveiligingsverhaaltje: een registratie zoals PyPI of npm controleert vandaag een sleutel of een tweede factor, niet een mens. Wie het token heeft, ís de beheerder. Er is geen stap die zegt: deze uitgifte is getekend door dezelfde bewezen unieke mens die als beheerder geregistreerd staat, en zijn recht om te tekenen is vandaag nog niet ingetrokken. Dat is exact V + C, en het is dezelfde vorm als de CRA-melding hierboven — alleen aan de andere kant van de keten: daar tekent een mens een melding, hier tekent hij een uitgifte. De regelgevende duw staat er ook al: dezelfde CRA vraagt fabrikanten vanaf 11 september te melden en vanaf december 2027 hun volledige toeleveringsketen te verantwoorden. 🔌 Integratievorm: C (REST-API) in de uitgiftepijplijn, met F (browser-plugin) als bewijs bij de hand voor de beheerder zelf. In gewone taal: vlak vóór het publiceren haalt de bouwstraat één attest op — "getekend door bewezen mens X, bevoegdheid geldig" — en dat attest reist mee met het pakket. Opzetpad: (1) draait al — attestatie-engine, pseudoniem per afnemer, publieke sleutellijst zodat iedereen offline kan controleren; (2) jij bouwt — een stap voor de bouwstraat (GitHub Actions is het logische begin) en een controlecommando, geschat 4-6 dagen; (3) de klant — één stap in zijn publicatie-werkstroom; (4) standaard — bestaande handtekeningformaten voor pakketten, met jouw attest als bijlage; (5) kleinste demo — je publiceert je eigen pakket met zo'n attest erbij en toont dat een tweede beheerder zonder geldige bevoegdheid geweigerd wordt. Dat kun je vandaag doen, zonder toestemming van wie dan ook. 🧩 Productmix: C (bevoegdheid, intrekbaar) als kern, V eronder, O voor het spoor, D voor de ingetrokken beheerder. Geen geldstroom — Rail 1, geldvorm LICENTIE. Meter: M1 per beheerder, M2 per uitgifte. Concrete verkooproute — en dit is meteen de nieuwe prospect van vannacht: Cloudsmith (Belfast, 7 Donegall Square) haalde op 23 april 2026 72 miljoen dollar Series C op, geleid door TCV met Insight Partners erbij, uitdrukkelijk om "de AI-gedreven softwaretoeleveringsketen te beheersen en te beveiligen". bron: persbericht Cloudsmith ↗ · EU-Startups, april 2026 ↗ Ze doen vandaag alles behalve de mens: automatische SBOM per container, diepe inspectie, detectie van kwaadaardige pakketten. Wie contacteer je: de productverantwoordelijke voor beveiliging/toeleveringsketen. Waarom zij en niet PyPI: een vers gefinancierd bedrijf van dit formaat beslist in weken, betaalt voor wat zijn verhaal completer maakt, en zit in een Engelstalige markt met Europese klanten die de CRA over zich heen krijgen. Openingszin: "U controleert wat er in een pakket zit. U controleert niet wie het erin duwde — en in maart volstonden veertig minuten met de sleutels van één beheerder om vier terabyte bij een klant van tien miljard weg te halen. Ik lever de ontbrekende regel: deze uitgifte is getekend door dezelfde bewezen unieke mens die als beheerder geregistreerd staat, en zijn recht was op dat moment niet ingetrokken."
26-08Visa en Mastercard richten acht dagen geleden een alliantie op — en het eerste gat dat ze noemen, is precies jouw product — op 18 augustus 2026 lanceerde Rain (New York, opgericht 2021, mede-oprichter en CEO Farooq Malik; stablecoin-betaalplatform en Principal Member bij zowel Visa als Mastercard) de Agentic Payments Alliance, met 26 stichtende leden: onder meer Visa, Mastercard, Circle, Fiserv, Shift4, Evertec, Remitly, Lithic, Turnkey, Sardine, Chainalysis, Fireblocks, Solana, Avalanche, Monad en Uniswap Labs. Geen product, wel een bestuursclub: ze willen gedeeld onderzoek en kaders, het testen van opkomende standaarden voor agent-identiteit en -autorisatie, en belangenbehartiging bij regelgevers. CEO Malik erbij: "No single company should get to decide how agents transact on someone's behalf." bron: persbericht Rain, PR Newswire, 18-08-2026 ↗ — bevestigd door American Banker ↗ en PYMNTS ↗. Zo zet je dit in de markt: lees wat er níét in staat. De betaalwereld heeft de betaling zelf al opgelost — Visa's Trusted Agent Protocol (oktober 2025), Mastercard Agent Pay for Machines (10-06-2026), Stripe's Machine Payments Protocol (maart 2026) — en richt nu een alliantie op voor het stuk dat overblijft: hoe bewijst een agent namens wie hij handelt, en waarvoor hij toestemming heeft. Dat is letterlijk het agent-paspoort uit blok 9, 4g, en het is precies wat case 190 beschrijft: de on-ramp vertaalt vier agent-protocollen naar één kaartbetaling, en het mandaat van de mens overleeft die vertaling niet — de winkel ziet een geldige kaart, geen getekende opdracht. Dat er 26 bedrijven een club voor oprichten in plaats van het in te bouwen, betekent dat niemand het heeft. Twee dingen mag je vanaf nu zeggen die je vorige week nog niet kon: (1) "agent-identiteit en -autorisatie" is geen randgeval meer maar een agendapunt van Visa en Mastercard, en (2) jij hebt daar een Europees antwoord voor waar zij een Amerikaanse standaardcommissie voor nodig hebben — want jouw mandaat hangt aan een itsme-bevestiging door een echte mens, niet aan een token dat een agent zelf uitschrijft. Concrete verkooproute: niet naar Rain of Visa — je bent te klein om daar de standaard te schrijven, en te vroeg om lid te worden. Ga naar wie in België straks een agent aan de deur krijgt en géén standaardcommissie heeft: Combell / team.blue (doelwitten hieronder) voor de sites, en de betaaldienstverleners die hier het equivalent doen — Worldline (Brussel, beursgenoteerd, verwerkt betalingen voor Belgische handelaars) en Mollie (Amsterdam, sterk bij Belgische webshops). De pijn die je bij hen tackelt zit in de terugboeking: als een agent koopt en de mens betwist het achteraf, is er vandaag geen bewijs dat die mens tekende. Openingszin: "Sinds 18 augustus hebben Visa en Mastercard een alliantie om te bepalen hoe een AI-agent bewijst namens wie hij koopt — dat betekent dat vandaag niemand het weet. Ik kan u dat bewijs nu al geven, gekoppeld aan een itsme-bevestiging van de mens zelf, zodat u bij een betwisting iets in handen hebt."
25-08Europa bouwt de leeftijdscheck gratis — en bouwt er met opzet in dat hij jou niet herkent — de Europese Commissie kondigde op 15 april 2026 een EU-breed coördinatiemechanisme aan voor de EU Age Verification Solution: één open-source leeftijdsapp bovenop de EUDI-wallet, met zero-knowledge-bewijzen en eenmalige, niet-koppelbare bewijzen, zodat een site "18+? ja" krijgt en geen enkel ander gegeven. Zeven lidstaten draaien de pilot en integreren hem in hun nationale wallet: Frankrijk, Denemarken, Griekenland, Italië, Spanje, Cyprus en Ierland — België staat er niet bij. bron: ageverification.dev, het officiële EU-portaal ↗ In dezelfde markt ging het de andere kant op voor wie het met biometrie doet: het Spaanse AEPD legde op 10 maart 2026 aan Yoti (Londen, opgericht in 2014 door Robin Tombs, Duncan Francis en Noel Hayden; leeftijdsschatting via selfie voor onder meer pornoplatformen, Instagram-tieneraccounts en John Lewis) een boete van 950.000 euro op: 500.000 voor onrechtmatige verwerking van biometrische gegevens (art. 9 AVG), 200.000 voor ongeldige toestemming (art. 7) en 250.000 voor te lange bewaring (art. 5), met zes maanden om in orde te komen. bron: Biometric Update, maart 2026 ↗ Zo zet je dit in de markt: stop met concurreren op leeftijd — dat wordt gratis, en Europa doet het beter dan jij ooit zult doen. Verkoop het verschil tussen "oud genoeg" en "één keer". De EU-app is met opzet zo gebouwd dat twee bezoeken niet aan elkaar te koppelen zijn; dat is uitstekend voor een pornofilter en waardeloos voor één deelname per mens (case 143), één welkomstbonus per mens (case 142), één stem per burger of één gratis tegoed per mens (case 183). Dáár begint jouw product, en jij bewaart daarvoor geen enkel lichaamskenmerk — wat Yoti net 950.000 euro kostte. En de Belgische afwezigheid in die zeven is je venster: een Belgische afnemer die vandaag een 18+-poort nodig heeft, heeft geen EU-app, wél itsme (blok 5). Concrete verkooproute: ga naar de Belgische kansspeloperatoren met vergunning — de Nationale Loterij (Brussel, staat al in de doelwitten) en de private licentiehouders zoals Golden Palace (Brussel) en Napoleon Games (Zele, sinds 2022 in handen van Betsson) — want zij moeten wettelijk zowel leeftijd áls het EPIS-uitsluitingsregister checken, en dat tweede is per definitie een uniciteitsvraag die geen leeftijdsapp beantwoordt. Waar het zich bij hen manifesteert: in het registratiescherm, tussen de leeftijdscheck en de EPIS-bevraging — daar plak jij één stap tussen die "uniek mens · 18+ · niet in EPIS" teruggeeft met alleen een pseudoniem. Openingszin: "Vanaf volgend jaar krijgt u de leeftijdscheck gratis van Europa, en dan valt op wat u dan nóg niet heeft: u kunt niet zien dat dit dezelfde mens is als het account dat u vorige maand hebt uitgesloten. Dat is wat ik lever — zonder dat u één identiteitsgegeven moet bewaren, en zonder een gezichtsscan waar de Spaanse toezichthouder in maart nog 950.000 euro boete voor uitschreef."
Je vraag bij 25-08: "wil dat zeggen dat dit negatief is voor mijn applicaties, omdat het er nu gratis bij zit?" — Nee. Eén stuk markt valt weg, en dat stuk was nooit van jou.
1 · Wat je verliest, had je niet. Als Europa vanaf volgend jaar in élke wallet een gratis 18+-check stopt, dan is "leeftijd bewijzen" geen product meer — voor niemand, ook niet voor Yoti of de andere leeftijdsschatters. De enige echte les: verkoop een leeftijdspoort nooit als je hoofdproduct. Als bijzin bij een aansluiting mag het, als businessmodel niet.
2 · Wat overblijft is groter, en het is met opzet onbereikbaar voor hen. De EU-app geeft eenmalige, niet-koppelbare bewijzen: twee bezoeken van dezelfde mens mogen per ontwerp niet aan elkaar te knopen zijn. Dus kan die app nooit "één keer per mens" tellen. Dat is geen gat dat een volgende versie dichtrijdt — het staat in de opdracht van de bouwers, want zonder die eis zou de leeftijdscheck zelf een volgsysteem worden. Jouw product zit precies in wat zij bewust weglaten: één deelname (case 143), één welkomstbonus (case 142), één stem, één gratis tegoed (case 183).
3 · Gratis is hier je verkoper, niet je concurrent. Elke lidstaat die die app uitrolt, legt aan miljoenen mensen én aan elke webshop uit dat je iets kunt bewijzen zonder gegevens af te geven. Dat is exact de uitleg die jij vandaag in elk gesprek zelf moet doen. Je krijgt hem gratis geleverd; jij verkoopt de vraag die erna komt.
4 · Je las het einde dus goed. Negatief voor het stuk "hoe oud is deze bezoeker", positief voor het stuk "is dit dezelfde mens als gisteren" — en dat tweede is wat in de catalogus zit, niet het eerste.
Zeg het zo: "Europa maakt de vraag 'hoe oud bent u?' gratis. De vraag 'is dit dezelfde mens als vorige keer?' maakt Europa juist met opzet onmogelijk — en dat is wat ik lever."
24-08Amerika heeft geen eID — en dat is precies waarom je er binnen kunt — de Verenigde Staten hebben geen federale eID en krijgen die ook niet; identiteit zit bij de staten. Maar onderaan is het stil doorgegroeid: volgens de staten-tracker van Credence ID (Oakland, Californië — bouwer van mDL-lezers) geven in maart 2026 21 staten en territoria een mobiel rijbewijs uit volgens de norm ISO/IEC 18013-5 — onder meer Californië, New York, Arizona, Georgia, Ohio, Utah, Illinois en Puerto Rico — te dragen in Apple Wallet, Google Wallet en Samsung Wallet. bron: Credence ID mDL-tracker, maart 2026 ↗ Illinois lanceerde in november 2025 in Apple Wallet, Arkansas ondersteunt intussen alle drie de wallets, en het staatsbestuur benadrukt daarbij dat noch Apple noch de staat ziet wanneer of waar je je ID toont — dankzij dezelfde selectieve onthulling die jij gebruikt. bron: Biometric Update, 29-05-2026 ↗ Zo zet je dit in de markt: stop met denken dat je een Amerikaanse voordeur nodig hebt. Je gaat de VS binnen langs de tol, niet langs de identiteit. De agent-kant van je verhaal — Gate, HTTP 402, x402-betaling — vraagt géén eID, géén itsme, géén enkele identiteitsdrager: een robot betaalt of blijft buiten, in Texas net zoals in Gent. Dat deel van r4m maX is vandaag al wereldwijd verkoopbaar (blok 9, 4b–4e). De ménsenpoort is wél landgebonden, en dáár is de boodschap: een mDL bewijst een kenmerk, geen uniciteit. Een mobiel rijbewijs zegt "deze persoon is 21+"; het zegt niet "deze mens heeft hier nog geen tweede account". Precies dat gat vult World met een irisscan — en precies daarvoor werd World in Spanje, Portugal, Kenia, Brazilië en Indonesië buitengezet (radar 23-08). Jij levert dezelfde uniciteit als laag bóven een bestaande drager, zonder biometrie: in België op itsme, in de VS op een mDL uit Apple of Google Wallet. Eén rail, per land een inwisselbare voordeur (blok 9, 4i). Concrete verkooproute: twee sporen, in deze volgorde. (1) Nu: verkoop de tol wereldwijd via de partij die er al zit — de Cloudflare Marketplace-app uit trap 2 (blok 9), want die vraagt van jou geen Amerikaanse aanwezigheid en geen enkele identiteitsintegratie. (2) Later: voor de mensenpoort bouw je zelf geen mDL-lezer, maar sluit je aan bij wie die al verkoopt — Credence ID (Oakland) of IDScan.net (New Orleans) leveren de leeskant aan Amerikaanse afnemers; jij levert de laag die zij niet hebben: uniek-per-mens plus een verzegelde kluis. Waar het zich bij hen manifesteert: in het scherm ná de scan — hun lezer zegt "geldig rijbewijs, 21+", en daar plak jij één regel achter: "en dit is de eerste keer dat deze mens hier binnenkomt". Openingszin: "Jullie lezen intussen mobiele rijbewijzen in 21 staten, en jullie kunnen bewijzen dat iemand 21 is. Wat jullie niet kunnen bewijzen is dat het niet zijn vierde account is — dat is wat ik erbovenop lever, zonder één biometrisch kenmerk te bewaren en zonder dat jullie klant een identiteit moet opslaan."
23-08Het grootste mensbewijs ter wereld zit nu in Zoom en DocuSign — en mag hier niet binnen — World, het identiteitsproject van Tools for Humanity (San Francisco, opgericht door Sam Altman en Alex Blania), kondigde eind juli 2026 fase 3 aan: ruim 18 miljoen geverifieerde mensen, World ID intussen meer dan 450 miljoen keer gebruikt, en een nieuwe Agent Kit voor agent-delegatie, verificatie van menselijke tussenkomst en agent-handel, met Vercel, Okta, Browserbase en Exa als partners. Zakelijke integraties: Zoom (controleren of een vergaderdeelnemer dezelfde geverifieerde mens is), DocuSign (is wie tekent een mens?) en Tinder (profielverificatie in Japan en de VS). bron: TokenPost, 28-07-2026 ↗ Maar hun voordeur is een irisscan door een privébedrijf, en precies díe voordeur werd geblokkeerd: het Spaanse AEPD (maart 2024), Portugal (maart 2024), Kenia (opgeschort augustus 2023, in mei 2025 door het Hooggerechtshof onwettig verklaard), het Braziliaanse ANPD (januari 2025) en Indonesië (mei 2025). bron: Biometric Update ↗ Zo zet je dit in de markt: dit is tegelijk je beste marktbewijs én je scherpste verschil. Marktbewijs: Zoom en DocuSign kopen vandaag al exact jouw twee producten — de mensenpoort (cases 110/111) en het agent-paspoort (blok 9, 4g) — dus de vraag hoeft niemand meer uitgelegd te worden. Verschil: zij vragen je oog, jij vraagt niets. R4M doet hetzelfde werk via itsme en eID — de voordeur die de Belgische banken en de overheid al erkennen — bewaart géén biometrie, en geeft per afnemer een ander pseudoniem, precies zoals de EU het van elke wallet eist (blok 3, V60). Concrete verkooproute: de Belgische DocuSign-vraag zit al in je eigen huis — laat iemand met AI-agents een CCC V3-reviewlink beantwoorden, film dat de R4M-check hem tegenhoudt, en gebruik die opname als demo (CCC-todo 33, case 110). Openingszin: "Zoom en DocuSign betalen vandaag al om te weten of er een mens aan de andere kant zit — alleen moet je daarvoor je oog laten scannen door een Amerikaans bedrijf dat in vijf landen buitengezet is. Ik lever hetzelfde bewijs via itsme, zonder één biometrisch kenmerk te bewaren."
Je vragen bij 23-08: "hoe manifesteer ik mij in de Verenigde Staten als ik alleen op eID kan rekenen?" — en: "als ik dit werkelijk kan aantonen, zit ik dan iets absurds te bouwen, en wat als iemand begint te claimen?"
1 · Het VS-antwoord staat één regel hoger, bij 24-08. Je hébt daar geen eID nodig, want die bestaat niet — ook niet voor je concurrenten. Wat er wél is: mobiele rijbewijzen in 21 staten en territoria (case 192). Jouw laag ligt boven de voordeur en is landneutraal: itsme, eID, EUDI-wallet of een Amerikaans mDL — R4M maakt er hetzelfde pseudoniem-per-afnemer van. De voordeur wisselt per land, jouw product niet. Dat is trouwens ook het antwoord dat je aan Nele geeft als zij vraagt hoe dit buiten België overeind blijft.
2 · Nee, je bouwt niets absurds — Zoom en DocuSign betalen er vandaag al voor. Dat is de kern van deze vondst: de vraag is bewezen door de markt, alleen kost het antwoord van World een irisscan die in vijf landen buitengezet werd. Je hoeft dus niet meer te bewijzen dát er markt is; je moet bewijzen dat jouw versie mag waar die van hen niet mag. Dat is een veel kleiner gesprek.
3 · "En als er iemand begint te claimen?" — dat is een datumkwestie, geen ruzie. Wat je beschermt is niet het idee (een handtekening controleren is twintig regels code, blok 4), maar wat je aantoonbaar eerst had: je git-geschiedenis met datums, het testboek, de itsme-relatie, en een neergelegd bewijsstuk van de bouw. Zet dat als één vraag bij Nele in blok 11: "wat leggen we vast, in welke vorm, en wanneer?" — dat is haar vak, niet het jouwe, en het kost één gesprekspunt.
4 · En de tegenkant, eerlijk: claim nooit meer dan wat draait. Vandaag beheer jij beide operationele sleutels zelf (blok 6, "eerlijk blijven"). Precies dat soort zin is wat een grote partij later niet tegen je kan gebruiken.
22-08Cloudflare: niet-menselijk verkeer passeert de helft van het web — in "Content Independence Day, one year on" (blog.cloudflare.com, 01-07-2026) meldt Cloudflare dat crawlen-om-te-trainen steeg van 22% (voorjaar 2025) naar 52% van alle crawler-verzoeken (juni 2026), dat niet-menselijk verkeer voor het eerst boven de 50% van al het internetverkeer uitkwam, dat zwaar gecrawlde sectoren tot 40% van hun ménselijke bezoek verloren in minder dan een jaar, en dat er sinds 2023 meer dan 50 licentiedeals tussen uitgevers en AI-bedrijven getekend zijn. Zo zet je dit in de markt: de deals bewijzen dat men wíl betalen, maar ze zijn één-op-één en alleen weggelegd voor grote uitgevers — de gewone site staat er niet tussen. Verkoop R4M dus niet als "bots blokkeren" maar als de kassa voor iedereen die geen advocatenteam heeft: bij Combell is de pitch dat hun hele klantenbestand in één keer aan die tafel komt; bij Nele dat het meten en tekenen van dat verkeer de basis is waarop zo'n licentie afdwingbaar wordt (V74).
▼ Voorbeeldrun routine · 22-08 · zaterdag 17:48
22-08Meer dan de helft van het web is geen mens meer — het Bad Bot Report 2026 (april 2026) van Imperva — Amerikaans cybersecuritybedrijf uit San Mateo, Californië, sinds 2023 dochter van de Franse defensie- en techgroep Thales; hun jaarrapport is sinds 2013 dé industriestandaard voor botverkeer — meet over 2025: 53% van al het webverkeer is geautomatiseerd, mensen zijn nog maar 47% en dalen; 40% is kwaadaardige bots — het zevende stijgingsjaar op rij. AI-gedreven botaanvallen stegen 12,5× op één jaar (van 2 naar 25 miljoen geblokkeerde aanvallen per dag). bron: Imperva ↗ Zo zet je dit in de markt: dit is dé openingsstatistiek voor elke pitch — "de meerderheid van je bezoekers is geen mens, en je weet niet welke". R4M is het enige antwoord dat mensen doorlaat én bots laat betalen (cases 110/111).
22-08Cloudflare zet de deadline: 15 september 2026 — vanaf dan blokkeert Cloudflare — het beursgenoteerde internet-infrastructuurbedrijf uit San Francisco (NYSE: NET, CEO Matthew Prince) dat vóór ruim 20% van het wereldwijde webverkeer zit — standaard "mixed-use" AI-crawlers op pagina's met advertenties, en evolueert Pay Per Crawl naar Pay Per Use. Eerste betalende partners: de AI-zoekmachines Ceramic.ai en You.com. AI-crawlers waren in juni 2026 al 52% van alle crawler-verzoeken, tegen 22% in het voorjaar van 2025. bron: TechCrunch ↗ Zo zet je dit in de markt: de markt beweegt exact richting jouw model, op weken tijd — maar Cloudflare regelt alleen de kassa. De mensenpoort en de aansprakelijke eigenaar (agent-paspoort) leveren zij niet: dat is jouw plek in de keten, en je timing voor het Combell-gesprek (case 112).
22-08x402 draait al op schaal — maar eerlijk: de echte handel is jong — per april 2026: ±69.000 actieve AI-agents verwerkten ruim 165 miljoen x402-transacties, samen ±50 miljoen dollar; x402 werd in mei 2025 gelanceerd door Coinbase — de grootste Amerikaanse cryptobeurs (Nasdaq: COIN, CEO Brian Armstrong) — en wordt sinds maart 2026 bestuurd door een Foundation van Coinbase én Cloudflare samen; met Agent.market opende Coinbase er een app-store bovenop waar AI-agents diensten kopen en verkopen. De meeste transacties lopen op Base, Coinbase's eigen goedkope betaalketen — dezelfde keten die voor jouw tol-wallets de logische keuze is. Eerlijke kanttekening uit dezelfde data: de echte commerce-omzet is nog maar ±28.000 dollar per dag en ongeveer de helft van de activiteit is "gamified". bron: Chainalysis ↗ Zo zet je dit in de markt: de rails bestaan en de twee grootste spelers besturen ze samen — jij hoeft niets uit te vinden. En de eerlijke kanttekening is je vriend bij Nele: je bouwt vroeg, vóór de massa, zonder te overdrijven wat er vandaag al omgaat.
22-08eIDAS 2.0: elke EU-lidstaat moet uiterlijk 31 december 2026 een identiteitswallet aanbieden — de eerste wallet-apps komen vanaf november 2026, Duitsland bouwt voor 80 miljoen gebruikers, en vanaf 21 november 2027 móeten bedrijven met KYC-plicht de EUDI-wallet als identiteitsbewijs accepteren. bron: Corbado ↗ Voor België wordt die wallet naar verwachting gebouwd op de bestaande itsme-infrastructuur — de Brusselse app van het Belgian Mobile ID-consortium (Belgische grootbanken + telecoms) met ruim 7 miljoen gebruikers (gerapporteerd) — precies de voordeur waar R4M vandaag al op draait. Zo zet je dit in de markt: je "voordeur per land" wordt binnen enkele maanden Europees uniform — precies V60 (prio A) in je dossier. Start Belgisch met itsme, en sta klaar als de EU-wallet landt: dan schaalt dezelfde rail naar 27 lidstaten zonder één regel om te bouwen.
🎯 Doelwitten — wie, wat, hoe (de namen die ertoe doen)
BEIsabel Group (Brussel) — het Belgische fintechbedrijf achter de betaalinfrastructuur van de banksector, en sinds 2026 de bouwer van TILDA: het platform waarmee financiële instellingen fraudesignalen delen en samen onderzoek doen, met een gestandaardiseerde fraudetaxonomie en geldezelrekeningen als eerste toepassing. De eerste instellingen testen; productiepiloot voorzien tegen eind 2026 (ITdaily, 17-08-2026). Het Febelfin-actieplan van 08-07-2026 noemt het platform met zoveel woorden “via Isabel en itsme®” en wil de scope later uitbreiden met telecom-, toestel- en itsme-signalen — dezelfde wortel als de jouwe. Zo zet je dit in de markt: Isabel is geen gereguleerde bank maar een technologieleverancier, en dat is precies waarom deze deur wél open mag: de
nietDoen-poort sluit statutaire KYC bij banken uit, niet een aansluiting bij hun toeleverancier. Kom niet als fraudedetectie — die stoel is bezet en het is hun product. Kom als de trap ervoor. Openingszin: “U vindt geldezels nadat het geld bewoog. Wij zeggen vóór de rekening opengaat of achter dit account dezelfde mens staat als achter een ander — één pseudoniem, geen enkel persoonsgegeven gedeeld. Dat is precies de juridische knoop waarvoor uw eigen plan om politieke steun en om de Gegevensbeschermingsautoriteit vraagt.” Let op: wie de aansluiting bouwt, kan de vraag ook zelf gaan beantwoorden — zelfde afweging als bij Combell.DESPRIND — Bundesagentur für Sprunginnovationen (Leipzig) — het Duitse federale agentschap voor spronginnovatie, dat sinds januari 2026 de EUDI-wallet-sandbox voor relying parties draait: 115 organisaties, 150 use cases, zes maanden, met als terugkerende conclusie dat het aansluiten van afnemers de EU-brede flessenhals is — niet de wallet zelf (Biometric Update, 04-08-2026). Eerder draaiden zij de Funke Challenge, waaruit meerdere ARF-conforme wallet-prototypes kwamen. Rond diezelfde Duitse wallet tekenden Bitkom, het BMDS en 100+ bedrijven een intentieverklaring — waaronder Deutsche Bank, Mastercard, N26, SAP, IDnow en Bundesdruckerei: dat is in één document de hele Duitse afnemerskant. Zo zet je dit in de markt: niet als walletbouwer aankloppen (die stoel is bezet en gefinancierd), maar als de aansluiting — één integratie voor de afnemer, meerdere identiteitsbronnen erachter, en een antwoord dat de EUDI-wallet niet geeft: is dit één unieke mens, of één mens met vijf accounts? Openingszin: “Uw sandbox heeft in zes maanden met 115 organisaties vastgesteld dat het aansluiten van afnemers de flessenhals is, niet de wallet. Wij lossen precies dát op.” Tweede deur: het Relying Party Engagement Programme van de Commissie — de eerste uitnodigingen gingen eind augustus 2026 de deur uit.
BECombell / team.blue (Gent) — het grootste hostingbedrijf van België (hoofdkantoor in Gent), onderdeel van team.blue — de Gentse hostinggroep van oprichter Jonas Dhaenens met 60+ merken en ruim 3 miljoen klanten verspreid over meer dan 20 Europese landen (gerapporteerd). Wie Combell overtuigt, heeft in één klap een kanaal naar honderdduizenden Belgische kmo-sites. Hun probleem: klantsites geteisterd door bots en scrapers, en géén antwoord behalve CAPTCHA's. Wie: de partner-/productmanager hosting. Verkooproute: de Gate als aanvinkbare optie per hostingpakket (case 112, trap 3) — "Cloudflare bouwt de kassa voor de grote sites; geef jij je kmo-klanten hetzelfde wapen, met mensenpoort erbij." Zij verkopen, jij levert, commissie gedeeld. Zo manifesteert het zich bij hen: in het Combell-controlepaneel — waar klanten vandaag SSL en backups aanvinken — komt één extra schakelaar "R4M Gate: mensenpoort + bot-tol". De klant vinkt aan, de Gate-worker schuift vóór zijn site, klaar. Combell-support ziet minder tickets over spam-formulieren en scraping; de boekhouding ziet een nieuw omzetlijntje per klant (tol-split). Openingszin: "Cloudflare laat sinds juli 2025 grote sites betalen per crawl — ik geef jullie hetzelfde wapen voor élke Combell-klant, met één vinkje in het controlepaneel, en jullie verdienen mee aan elke bot die betaalt."
BEDPG Media · Mediahuis · Roularta — de drie grote Belgische uitgevers: DPG Media (Antwerpen — HLN, VTM, Qmusic, ook groot in Nederland en Denemarken), Mediahuis (Antwerpen — De Standaard, Het Nieuwsblad, Gazet van Antwerpen, plus De Telegraaf en NRC in Nederland) en Roularta (Roeselare — Knack, Trends, Libelle, Sportmagazine). Hun probleem: AI-crawlers eten hun journalistiek gratis op terwijl abonnees betalen; wereldwijd sluiten uitgevers al licentiedeals (News Corp–OpenAI, gerapporteerd ±250 miljoen dollar over 5 jaar; Reddit–Google, gerapporteerd ±60 miljoen dollar per jaar — bewijs dat content-toegang geld waard is). Wie: digital/AI-strategie-verantwoordelijke. Verkooproute: tol + licentie per crawler-soort (blok 9, 4b/4e) in plaats van alles-of-niets blokkeren: zoekmachines gratis (SEO), AI-trainers betalen het volle pond — met de Cloudflare-deadline van 15-09-2026 als momentum. Zo manifesteert het zich bij hen: de Gate schuift vóór de artikelpagina's, náást hun bestaande paywall: een abonnee met attest merkt niets en logt zelfs makkelijker in (geen CAPTCHA), een AI-crawler krijgt HTTP 402 met een tarief per artikel. Bonus voor hun advertentie-afdeling: gegarandeerd menselijk verkeer betekent hardere kijkcijfers en dus hogere advertentietarieven. Openingszin: "Jullie journalistiek wordt vandaag gratis leeggegeten door AI-crawlers, en vanaf 15 september blokkeert Cloudflare ze standaard — ik zorg dat ze bij jullie niet geblokkeerd maar betálend worden, per artikel, met daarbovenop het bewijs dat elke menselijke lezer echt een mens is."
BENationale Loterij — Brussels staatsbedrijf (100% eigendom van de Belgische staat, meer dan 3 miljard euro jaarinzet gerapporteerd) — al in je dossier als afnemer-voorbeeld (blok 5). EPIS is het verplichte uitsluitingsregister van de Kansspelcommissie waartegen élke speler gecheckt moet worden: exact de check die R4M kan afhandelen zonder dat de Loterij identiteiten hoeft te bewaren. Hun probleem: wettelijk verplicht zeker te weten wie er speelt, zonder zelf een privacy-berg te willen beheren. Wie: compliance/innovatie. Verkooproute: attest-poort via API-sleutel — zij zien enkel pseudoniemen, de kluis draagt de bewijsplicht. Overheidsgeloofwaardigheid als eerste grote referentie. Zo manifesteert het zich bij hen: in de registratieflow van hun app — waar nu de eID-upload en de EPIS-check zitten — komt één R4M-stap: de speler toont zijn attest, de Loterij krijgt terug "uniek mens · 18+ · niet in EPIS" met alleen een pseudoniem, en hoeft zelf geen identiteitsgegevens meer te bewaren. Bij elke inzet volstaat een verse 15-minuten-attestcheck in plaats van een permanente sessie. Openingszin: "Jullie moeten wettelijk zeker weten wie speelt, maar niemand wil die privacy-berg beheren — ik lever het bewijs zonder de gegevens, en de verzegelde kluis draagt de bewijsplicht bij een gerechtelijk bevel."
VSTollBit — New-Yorkse startup (opgericht 2023 door Toshit Panigrahi en Olivia Joslin, tientallen miljoenen dollar durfkapitaal opgehaald — gerapporteerd) die nu al crawl-betalingen regelt tussen AI-bedrijven en uitgevers, met o.a. Time, AdWeek en Newsweek als gerapporteerde partners: een marktplaats waar AI-bots per opgehaald artikel betalen. Waarom belangrijk: levend bewijs dat er vandaag geld stroomt in dit model — én je scherpste spiegel: zij doen alleen de kassa, geen mensbewijs en geen aansprakelijke eigenaar. Hoe gebruiken: volg ze als benchmark, citeer ze bij Nele en Combell als marktvalidatie, en positioneer R4M als de laag die zij missen (agent-paspoort, V75). Zo gebruik je ze concreet: check maandelijks hun publieke partnerlijst en tarieven als marktprijs-referentie voor je eigen tol-bundels, en gebruik deze zin bij Nele én Combell: "TollBit bewijst in de VS dat uitgevers vandaag al betaald worden per crawl — wat zij níet hebben is het mensbewijs en de aansprakelijke eigenaar achter elke bot, en dat is precies onze laag."
UKCloudsmith (Belfast) — universeel platform voor pakket- en artefactbeheer, 7 Donegall Square; haalde op 23 april 2026 72 miljoen dollar Series C op onder leiding van TCV, met Insight Partners erbij, om de AI-gedreven softwaretoeleveringsketen te beheersen en te beveiligen. Hun probleem: ze inspecteren wat er in een pakket zit — SBOM per container, detectie van kwaadaardige pakketten — maar niets in hun stapel zegt wie de uitgifte tekende; de LiteLLM-aanval van 27-03-2026 liet zien dat veertig minuten met de sleutels van één beheerder volstaan. Wie: de productverantwoordelijke voor beveiliging en toeleveringsketen. Verkooproute: een uitgifte-attest als extra regel in hun pijplijn (C · REST-API), met de CRA-termijnen als aanleiding. Zo manifesteert het zich bij hen: in het scherm waar een pakket binnenkomt staat vandaag "SBOM: ok, geen kwaadaardige code"; daar komt één regel bij — "getekend door bewezen mens, bevoegdheid geldig op het moment van uitgifte". Openingszin: "U controleert wat er in een pakket zit, niet wie het erin duwde — ik lever die ene regel, en de CRA-klok van 11 september maakt hem verkoopbaar."
22-08Cloudflare test "Pay per crawl" — de grootste CDN ter wereld (≈20% van het web) laat site-eigenaars sinds de aankondiging van juli 2025 experimenteren met betaalde crawl-toegang via HTTP 402. Zo zet je dit in de markt: het bewijst dat de tolweg-kant van case 111 geen fantasie is — de infrastructuurreuzen bouwen de kassa al. Wat zij níet hebben: het mensbewijs en de aansprakelijke eigenaar ernaast. Dat is jouw opening bij Combell: "Cloudflare bouwt de kassa, ik lever de controleur."
22-08Coinbase lanceerde x402 (mei 2025) — een open protocol dat HTTP 402 nieuw leven geeft: machinebetalingen in stablecoins, per verzoek, zonder accounts. Zo zet je dit in de markt: jij hoeft geen betaalprotocol uit te vinden of te onderhouden — je bouwt op een open standaard die de agent-economie zelf al adopteert. Voor Nele: dit onderbouwt waarom de commissie-splitsing on-chain kan, zonder geld door R4M's handen (V57).