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.

18-09🔍 AUDIT · Het archief dat onze eigen vonnissen bewaart draagt twee sleuteltalen, en deze ronde liep er zelf in — Gemeten vanavond 18-09-2026 19:0x op ops/audit-private/audits.json: 137 vonnissen, waarvan 92 met Engelse sleutels (date/verdict/title/assessment, 02-07 t/m 10-09) en 45 met Nederlandse (datum/vonnis/titel/beoordeling, 07-09 t/m 17-09). Nul dragen er allebei. Wie het bestand uitleest op date ziet als nieuwste vonnis 10 september en denkt dat het archief acht dagen stilstaat; wie het uitleest op datum mist 92 van de 137 vonnissen en daarmee de hele geschiedenis vóór september. Deze ronde las eerst zelf "laatste vonnis 10-09" en stond op het punt dat op te schrijven, tot de git-log liet zien dat de commit van gisteravond zeven regels aan datzelfde bestand had toegevoegd. Die tegenspraak legde het bloot. Niets is weg en niets is fout — het bestand is alleen niet met één vraag te lezen. Bewust niet omgezet: 92 rijen hernoemen is een beslissing van Franky, geen avondklus. Zo zet je dit in de markt: dit is precies het verhaal dat R4M aan een koper verkoopt, maar dan over onszelf: een telling die klopt op het bestand en niet op de vraag. Wie vanavond beslist of we de sleutels normaliseren (met de Engelse als alias, zodat oudere lezers niet breken), beslist tegelijk dat ons auditspoor over een jaar nog in één keer leesbaar is. Eén regel werk, en het staat in het 🔍 Audit-menu klaar.
18-09✅ AUDIT · Tweede volle dag rem: nul Fly-uitrollen vandaag, en de middagdeploy staat tot op de byte live — Gemeten 18-09-2026 19:0x. Fly: de jongste uitrol is die van gisteravond 20:23 (v0.50.0, de weigerreden, met akkoord van Franky) — vandaag dus nul, en dat klopt met de oorzaak: main kreeg alleen twee docs-commits, de tweede met [skip ci]. Nul codecommits, nul uitrollen; de bouwstop van 17-09 en de rem van 16-09 leveren samen een dag zonder enige motorwijziging. Geen versiedrift: VERSION 0.50.0, package.json 0.50.0, tag v0.50.0 op origin, en /api/public/status geeft om 17:05 UTC v0.50.0 op base-sepolia met adapter usdc-base — het structurele antwoord op het theater-vonnis van 16-09, toen v0.46.0 live stond zonder tag. De site: marktradar.html 1.129.194 b en cases-db.json 6.331.678 b, op schijf én live identiek. Wat dit niet bewijst: dat de motor goed werkt — de testsuite draaide vanavond niet, de 500 groen komen uit de fase van 13:00. Zo zet je dit in de markt: een dag zonder uitrol is geen stilstand maar een aantoonbare rem, en dat is precies wat een overheidsklant wil zien vóór hij een identiteitsrail binnenlaat. "Onze uitrol beweegt alleen als de code beweegt, en dat is per dag na te tellen" is een zin die in een aanbesteding zwaarder weegt dan een featurelijst.
18-09🧭 BRONNEN · Onze eigen waarschuwing beschreef acht avonden het verkeerde symptoom — en het gevaar loopt andersom — Ronde BRONNEN van 18-09-2026: 54 levende adressen, 51 × 200, alle afwijkingen 2× gemeten. De drie afwijkingen zijn geen van drieën een storing: het npm-pakket @x402/casper staat op 404 (vierde avond wacht, release voorbereid maar niet uitgebracht), de kale hostnaam van de t54-proxy geeft 404 zoals hun ontwerp bedoelt, en de derde was geen bron maar een sjabloon met een letterlijke <sha> erin — vanaf vanavond als zodanig gemarkeerd zodat geen volgende ronde erover struikelt. De correctie: bij r4m-max.pages.dev stond acht avonden "geeft altijd 302, een routine leest dat als kapot". Gemeten: zonder omleidingen volgen inderdaad 302 — maar mét volgen, de standaard in vrijwel elke client, 200 met 34.832 bytes en de Cloudflare-loginpagina erin. Een normale routine leest deze bron dus niet als kapot maar als gezond, en dat is de gevaarlijker fout. Eén tabel hoger stond hetzelfde mechanisme al wél goed beschreven, bij de EU-wiki. Drie nulstanden ongewijzigd: de identiteitshaak van upto op EVM/Base (0 treffers, 134 regels, 4.452 b), de identiteitssleuf van de x402-v2-spec (identity 0 · person 0 · sybil 0 · KYC 0), en t54 dat nog altijd vóór de publieke x402-facilitator hangt zonder eigen afwikkeling. Zo zet je dit in de markt: de drie nulstanden zijn samen het sterkste verkoopargument dat we hebben, en ze staan vanavond opnieuw stil: het grootste agent-betaalprotocol ter wereld heeft in zijn kernspec nul woorden voor mens, persoon of uniciteit, en de dichtstbijzijnde concurrent bouwt gedragsrisico, geen identiteit. Dat gat is geen mening maar een telling die elke avond herhaald wordt — zet die telling op tafel bij de eerste vraag "waarom bestaan jullie?".
18-09💰 FUNDING · imec.istart heeft een tweede deur die wij nooit gelezen hadden: Nederland en Spanje openen 1 tot 31 oktober — Nagemeten vandaag 18-09-2026 om 13:0x op imecistart.com/en/apply (HTTP 200). De Belgische rij is ongewijzigd — Autumn 2026, "Open call Sept 1 - Sept 30 (midnight)" — en die ronde blijft overgeslagen volgens Franky's besluit van 16-09 (zonder BV en zonder tweede teamlid is januari sterker). Maar dezelfde tabel draagt landen die deze routine tot vandaag nooit las: NEDERLAND Autumn 2026 "Open call Oct 1 - Oct 31", SPANJE "Oct 1 - Oct 31 (midnight)", DUITSLAND "Sept 1 - Sept 30" met een actieve APPLY NOW naar platform.imecistart.com/istartde. Dat is een deur die één maand ná de Belgische opengaat, op hetzelfde programma en dezelfde €100K converteerbare lening. Wat ik NIET weet en niet ga gokken: of een Belgische onderneming in de Nederlandse of Spaanse ronde mag indienen. Dat staat nergens op de aanvraagpagina, en de FAQ op en/faq laadt zijn antwoorden nog altijd via JavaScript — zetel-eis en team-eis zijn dus nog steeds ongelezen. Zacht noch hard: de datum is hard, maar de poort is onbekend. Zo zet je dit in de markt: geen vlag en geen push, wel één keuzevraag voor Franky — is de NL-ronde van 1 tot 31 oktober het narekenen waard als tussenstap naar Spring 2027, of blijft januari het doel? Eén mail naar imec.istart met de vraag "kan een Belgische vennootschap indienen in de Nederlandse ronde?" kost tien minuten en beantwoordt ook meteen de zetel-eis die drie runs lang achter JavaScript bleef hangen.
18-09💰 FUNDING · Vier regels aan de bron nagemeten, geen enkele schoof — en geen harde datum binnen veertien dagen — Fase BOUWEN 18-09-2026 13:0x, elk adres zelf opgehaald. NLnet Restack (nlnet.nl/restack, 200): "November 3rd 2026" ongewijzigd, zacht — verdere deadlines op de derde dag van elke oneven maand. Circle Developer Grants (circle.com/grant, 200): "Apply now" actief, "Agentic economic activity" nog altijd eerste prioriteit, "first cohort of 2026" ongewijzigd, geen sluitingsdatum, zacht. EIC Accelerator (eic.ec.europa.eu, 200): "batched for evaluation every first Tuesday of the month at 5pm Brussels time" woordelijk ongewijzigd en 04/11/2026 staat er nog als cut-off van de volledige aanvraag — eerstvolgende bundeling van stap 1 is dinsdag 06-10-2026 om 17:00. Base Batches 004 (base.org/batches, 200): "Applications Closed", nog altijd geen 005. Conclusie: nul urgenties, dus geen 🚨 en geen push. Zo zet je dit in de markt: de grootste som op het hele bord (EIC, tot €2,5M subsidie) heeft geen paniekdatum maar een maandelijkse trein; wie op 6 oktober mee wil, schrijft in de week van 29 september. De goedkoopste stap blijft ongewijzigd: een gratis voorlopige beoordeling vragen bij Magali Parent (magali.parent@vlaio.be), het Vlaamse EIC-contactpunt bij VLAIO.
18-09🛑 AUDIT · Bouwstop nageleefd: deze fase levert bewust géén voorstel, en de collision guard staat 3 op 3 — De vaste opdracht van fase BOUWEN zegt: één klein voorstel op een voorstel/-tak. De staande afspraak op verkoop.html (blok 8) zegt sinds 17-09-2026: "Bouwstop tot haar antwoord — nieuwe ideeën gaan naar de todo, niet in de motor." Die twee botsen, en de afspraak van Franky wint: geen nieuwe tak vandaag, en dat is geen gemiste stap maar de juiste. De guard zelf is wél volledig gedraaid, want dát is de controle die op 10-09 faalde: werkboom van Rails4Mankind schoon · laatste niet-[auto-backup]-commit 88012b3 om 03:40, ruim buiten het venster van 60 minuten · git branch --show-current = main, geen tak van een vorige run blijven staan. Telling zonder vonnis: op origin staan 36 takken onder refs/heads/voorstel/; deze routine ruimt nooit takken op. Zo zet je dit in de markt: een bouwstop die een agent zelf respecteert is precies het gedrag dat R4M aan klanten verkoopt — de rail doet wat het mandaat zegt, ook wanneer zijn eigen opdracht iets anders vraagt. Dat is geen marketingzin maar een gecontroleerd feit van vandaag.
18-09✓ AUDIT · Rem op de Fly-uitrol houdt ook de tweede dag, en live is gelijk aan repo is gelijk aan tag — Gemeten met gh run list -R DS2036/r4m-engine --workflow deploy.yml naast git log --first-parent origin/main. Laatste uitrol: 2026-09-17T20:23 UTC op 382d0f9 (v0.50.0), conclusie success. Dáárna kwam er één commit op main — 88012b3 van vannacht 03:40, het dagrapport van fase VINDEN — en die startte geen uitrol. De paths-ignore-rem van 16-09 doet dus nog steeds wat ze moet doen; gisteren was dat één dag, vandaag twee. Versie langs drie bronnen: VERSION = 0.50.0 · git ls-remote --tags origin v0.50.0 geeft 382d0f94f7b80b… (de tag staat écht op origin, geen theater zoals bij v0.46.0) · /api/public/status om 13:0x = v0.50.0 op base-sepolia, stage pilot. Geen versiedrift. Wat deze meting NIET bewijst, en wat de status zelf ook eerlijk zegt: settlement_adapter en email_login staan op configured met verified = null — er staat een sleutel, of de keten of de mailprovider die aanvaardt is niet gemeten. Teller vandaag: 13 echte attestaties, 1 onderscheiden mens, 0 live. Zo zet je dit in de markt: "wij tonen zelf waar onze eigen meting stopt" is bij een attestatierail geen bescheidenheid maar het verkoopargument.
18-09🧪 TEST · 500 groen, 2 overgeslagen, 78 bestanden — de volle suite op main na v0.50.0 — Deze fase draaide de testsuite read-only op main van /Volumes/8TB MM4/Rails4Mankind, om 13:07: 78 bestanden, 500 geslaagd, 2 overgeslagen (502 totaal), in 11,22 s onder vitest 4.1.9. Gisteren stond de teller op een tak nog op 499 groen / 2 overgeslagen bij 79 bestanden; de weigerreden van v0.50.0 zit er nu in. Herhaalbaar met: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test. Niet getest deze fase: npx tsc --noEmit, npm run demo, /api/public/reconciliation en /healthz?deep=1 — zonder voorstel is er geen wijziging om tegen af te zetten, en de motor is verder niet aangeraakt. Zo zet je dit in de markt: 500 groene tests is geen claim die je op een pagina zet, het is het getal dat je een klant laat narekenen met één commando — dat verschil is het hele verkoopverhaal van het bewijsboek.
18-09📰 OCHTENDRAPPORT 18-09 · Zestien inbrengen, één echte urgentie, en de vaststelling dat de nacht voorraad levert in plaats van beweging — Rapport or-20260918 staat live op de Ops-tab. De kern: World Money bindt sinds 17-09 in meer dan 150 landen een hógere uitbetaling aan een bewezen unieke mens (Orb-scan, World ID) — de eerste keer dat de verdien-kant met echt bereik gebouwd wordt, trigger 3 uit SIGNALS_ADAPT.md. Daarnaast: Brazilië verplicht ticketverkopers vanaf 21-09 tot limieten per koper (decreet 13.108/2026, Diário Oficial 01-09-2026), iProov publiceert HAPS onder Apache-2.0 dat goedkeuring bewijst maar uniciteit bewust niet, en Mastercard × Alchemy bindt met Verifiable Intent de opdracht aan een kaarthouder — dus aan een rekening, niet aan een mens. Zeven kaarten naar de beslis-inbox (320–326), twee met een koper met stad. Motor: v0.50.0, 500 tests groen, 2 overgeslagen, geen versiedrift, kasboek sluit op vijf invarianten. Zo zet je dit in de markt: de drie vondsten van vannacht bouwen samen één zin — de markt benoemt nu zelf het verschil tussen aanwezigheid, goedkeuring en uniciteit, en R4M is de enige die de derde laag levert met een overheids-eID in plaats van biometrie in eigen beheer.
18-09🛑 BESLIS-INBOX · 137 kaarten zonder menselijk oordeel en zestien open voorstel-takken — de nacht levert voorraad, geen beweging — Nagemeten in dit ochtendrapport, en het stond nergens: van de 337 kaarten in de beslis-inbox zijn er 122 ooit beoordeeld, allemaal met nummer ≤ 200. De kaarten 201 t/m 337 — honderdzevenendertig stuks — hebben geen enkel menselijk oordeel. Het laatste inhoudelijke oordeel van Franky dateert van 11-09-2026 (vraag V44, rechtsvorm); het enige spoor daarna is een sleuteltest op 13-09 09:04. Bron: api/r4m/oordelen op cccv3-clone, 3.000 oordelen opgehaald 18-09 08:08, waarvan 316 met een menselijke auteur. Daarnaast staan er in Rails4Mankind zestien niet-gemergede voorstel-takken open, de oudste van 02-09-2026 (deploy-poort-pad-filter), de jongste van 17-09 (healthz-diep-begrensd, zeven-beloftes). Zo zet je dit in de markt: niets — dit is intern, en het is het knelpunt dat alle andere vertraagt. Elke nacht komen er kaarten bij; zonder ja of nee blijft de voorraad groeien terwijl Sympla op 21-09 een klok heeft staan. Begin bij 320 en 321: die twee hebben een koper met naam en stad.
18-09📊 SEO-VLOOT · 11 van 23 domeinen vandaag gemeten, channel-zero wint dertien klikken, drie sites stilgevallen sinds 3 juli — Cijfers opgehaald uit api/seo-watch op 18-09 08:06, niet uit het geheugen. De vloot telt nu 23 domeinen tegenover 21 op 16-09. Elf zijn vandaag gemeten, twaalf niet. Beweging bij drie: turbeau2rock.com +5 mobiel CWV (77), bkssolutions.be +3 (72), boombedrijfbisschop.be −7 (75, desktop blijft 100). Klikken staan een dag achter: channel-zero.be 172 tegen 159 = +13, boombedrijfbisschop 25 tegen 24, idgs.eu 8, turbeau2rock 5, qmtex 4, lowlands.business 1, bkssolutions 0. De twaalf stille: bks-solutions en de klantrapportgroep (14-09), bks-nieuw (09-09), zes pages.dev-bouwsites van 28 en 30-08, en drie die sinds 03-07-2026 niet meer gemeten zijn — hiddengarden.be, hiddengarden-dsvdbuild en kortrijkspurs.be. De ketencheck meldt zich groen op “0 dagen” omdat er íéts gemeten werd; dat is de tweede keer dat die nuance hier moet staan. Zo zet je dit in de markt: intern signaal. Drie domeinen die elf weken niet gemeten zijn, zijn geen vloot meer maar een lijst — ofwel terug in de meting, ofwel eruit met datum en reden.
18-09📦 OMZET-LOPENDE-BAND · NORC schrijft onze eigen stelling op: “als de identiteit niet vooraf gekend is, lost geen enkele opkuis achteraf het probleem op” — NORC aan de University of Chicago, een van de oudste onderzoeksinstituten van de VS, over de fraudegolf in enquêteonderzoek (norc.org, gelezen 18-09-2026). Letterlijk: "if identity is not known a priori, no amount of downstream cleaning fully solves the problem." Het cijfer erbij komt van een Insights Association-webinar van 29-01-2026: 40% van de niet-probabiliteitsinterviews in 2025 was waarschijnlijk frauduleus — ongeveer twee miljard interviews. NORC noemt YouGov, VeraSight, Dynata en Cloud Research als partijen die reageerden, en zegt er droog bij dat geen van hen volledige transparantie of hard bewijs leverde. De fraudeurs clusteren volgens NORC in "duplicated demographic profiles" en menselijke klikfarms, niet in bots — vangvragen werken niet tegen een oplettende fraudeur. Waarom dit meer is dan een leuk citaat. Dit is de scherpste externe formulering van de R4M-stelling die we tot nu toe gevonden hebben, en ze komt niet van een leverancier maar van een academisch instituut dat er niets aan verdient. Elke pitch die tot nu toe uitlegde waaróm detectie achteraf tekortschiet, kan die uitleg nu vervangen door één zin van NORC. De aanpalende geldstroom, gemeten vannacht: Sermo publiceert zelf "more than $25 million in honoraria to healthcare professionals in the last year" en honoraria van "approximately $5 to more than $500" per enquête, met "$200 to $300" voor een kwalitatieve studie van 30 minuten (sermo.com, pagina bijgewerkt 16-09-2026). Sermo zegt dat leden een "credential-verification process" doorlopen, maar publiceert géén cijfer over dubbele respondenten — de pagina zwijgt over hoe dat gecontroleerd wordt. 🔌 Integratievorm: API-sleutel op hun backend bij de paneltoetreding, plus een RIZIV/INAMI-attribuut naast de uniciteit. 🧩 Productmix: V + D + P + O — uniciteit is hier het product en settlement de motor; trede 2 voor het attest, trede 3 zodra het honorarium erover loopt. Meter: M1 per nieuwe arts, M2 per enquête-uitnodiging. Richting: DEUR. Zo zet je dit in de markt: openingszin voor een fieldworkbureau: “NORC schreef in september dat geen enkele opkuis achteraf werkt als de identiteit niet vooraf vaststaat. Wij zetten die identiteit vooraf vast, met itsme, zonder dat u een naam bewaart.”
18-09🚨 VERDIEN-KANT · World zet bewezen-uniek-mens ín een betaalapp: World Money, 150+ landen, sinds 17-09 — Tools for Humanity (San Francisco) lanceerde op 17-09-2026 World Money, een zelfbewaarde financiële app in meer dan 150 landen: stablecoin-overschrijvingen in acht munten, virtuele rekeningen die loon rechtstreeks ontvangen en automatisch naar stablecoin omzetten, Stripe voor de Amerikaanse instroom (Apple Pay → stablecoin), Kalshi en Morpho ingebouwd — en een hogere opbrengst op Earn/Morpho voor wie zijn uniciteit bewees met een Orb-scan van World ID (The Block, 17-09-2026; ID Tech Digest, 17-09-2026). Waarom dit de scherpste concurrentiemelding van de week is. Tot nu toe was World een identiteits-project dat R4M op de attestatiekant raakte. Vanaf 17-09 is het een geld-product waarin de uniciteit van de mens rechtstreeks een hogere uitbetaling oplevert. Dat is precies de as waarop R4M zich positioneert: geld dat per bewezen mens stroomt. maX kent World ID goed (47 vermeldingen in cases-db.json), maar World Money stond nergens — nul treffers op de hele site vóór vannacht. De weerlegging, en die is scherp. World bewijst uniciteit met een iris-scan in een bol: geen overheidsidentiteit, geen rechtsgrond in een lidstaat, en de Orb ligt in meerdere EU-landen onder toezicht. R4M bewijst uniciteit met de eID/itsme van de staat zelf (LOA high, eIDAS) en geeft de afnemer een pseudoniem terug in plaats van biometrie. Voor een Europese afnemer die morgen moet uitleggen wáárom hij weet dat dit één mens is, is "de staat heeft hem geïdentificeerd" een ander antwoord dan "een bol heeft zijn iris gezien". 🔌 Integratievorm: niet van toepassing — dit is geen klant maar een concurrent. Wat je wél overneemt is hun vorm: uniciteit als voorwaarde voor een hógere uitbetaling, niet als drempel vooraf. Dat is één sponsorknop op onze poort (bonus alleen bij een levend attest), bouwtijd bij Franky ± 2 dagen op de bestaande attest-route. 🧩 Productmix: V (is deze mens echt en uniek) + P (betaal déze mens) + O (boeken en bon) — trede 3, en trede 4 zodra er stablecoin bij komt. Richting: VOLG + DEUR. VOLG omdat World nu het bewijs levert dat de markt voor "geld per bewezen mens" bestaat; DEUR omdat elke Europese afnemer die dit ziet meteen de vraag krijgt of het hier mag. Zo zet je dit in de markt: gebruik World Money als je marktbewijs, niet als je vijand. Openingszin: "Sinds vorige week betaalt World méér uit aan mensen die bewezen uniek zijn. Datzelfde kunnen wij, maar dan met de eID van de Belgische staat in plaats van een irisscan — en dat is het verschil tussen een pilot en een dossier dat je aan je DPO kunt tonen."
18-09🤝 x401 · iProov publiceert HAPS: een open spec die bewijst dát een mens een agent-actie goedkeurde — en die de uniciteit bewust niet raakt — iProov (Londen) zette op 17-09-2026 de Human Approval and Presence Specification (HAPS) publiek onder Apache-2.0. Zelf nagemeten aan de bron, niet uit een persbericht: api.github.com/repos/iProov/HAPS geeft created_at 2026-09-17T09:40:18Z, pushed_at 10:29:42Z, licentie Apache-2.0, 0 sterren (github.com/iProov/HAPS; duiding: ID Tech, 17-09-2026). Wat de spec doet: een agent-werkstroom pauzeren, de voorgestelde handeling aan een mens tonen, bewijs van echte menselijke aanwezigheid en goedkeuring ophalen, en controleren dat dat bewijs over déze handeling gaat. Het resultaat is een ondertekende consent credential met cryptografische uitdaging, audience-beperking, vervaltijd en een eenmalige nonce tegen replay, bovenop OAuth, OpenID Connect en WebAuthn. Andrew Bud (oprichter en CEO) noemt het "proof of human presence as a requirement for agentic workflows". De drie metingen die deze routine sinds 07-09 verplicht bij elke protocolvondst doet. (1) Juiste bron: de repo zelf, aangemaakt op 17-09 — geen contextregel in andermans patch. (2) Reikwijdte: dit is geen x401-wijziging. De x401-repo van Proof staat sinds dde015b van 14-09-2026 stil; HAPS is een tweede, concurrerend voorstel voor dezelfde plek in de keten, uitdrukkelijk "experimental draft… not a production-ready authorization service". R4M draait op base-sepolia met usdc-base en raakt hier vandaag niets van. (3) Spec of voorbeeld: spec én testvectoren én een Rust-referentiemodel — dus echte code, geen comment. Het gevolg voor R4M, en dat is de kern. HAPS bewijst dat er een mens aanwezig was en akkoord ging. Het bewijst niet dat het dezelfde mens is als vorige keer, en al helemaal niet dat het er maar één is: de spec is uitdrukkelijk biometrie-agnostisch en bindt niets aan een overheidsidentiteit. Dat is exact het gat waar de R4M-attestatie in past — één mens, één keer, met itsme erachter. Wie HAPS implementeert heeft daarna nog steeds een uniciteitslaag nodig. 🔌 Integratievorm: API-sleutel op hun backend. Opzetpad: (1) onze attest-deur draait al en geeft een pseudoniem per mens; (2) Franky bouwt een HAPS-profiel dat onze attestatie als evidence in hun consent credential legt — ± 3 dagen, want de velden (nonce, audience, expiry) zitten al in ons attest; (3) de klant zet HAPS in zijn agent-werkstroom, zoals de spec beschrijft; (4) standaard: OAuth/OIDC/WebAuthn, dus dezelfde familie als onze eID-route; (5) kleinste demo zonder toestemming van wie dan ook: een HAPS-consent op onze eigen poort, met ons attest als bewijsstuk. 🧩 Productmix: V + C (het mandaat: welk recht gaf die mens) + G, attestatiekant zonder geldstroom — trede 2, met groeipad naar trede 5 zodra een machine namens die mens handelt. Richting: VOLG. Eén ster, experimentele draft — nog geen markt. Maar als HAPS aanslaat is het de eerste plek waar onze attestatie als bewijsstuk kan inpluggen zonder dat wij iets moeten verkopen. Zo zet je dit in de markt: wacht met mailen tot de spec beweegt. Bewaar de openingszin: "Uw HAPS-bewijs zegt dat een mens akkoord ging. Het zegt niet dat het dezelfde mens is als gisteren. Dat vakje vullen wij, met de eID van de staat."
18-09🆔 IDENTIFICATIE-CASE · Brazilië verplicht ticketverkopers vanaf 21-09 tot limieten per koper, pre-registratie en anti-bot — over drie dagen — Decreet nr. 13.108 van 31-08-2026, gepubliceerd in het Diário Oficial da União op 01-09-2026 (planalto.gov.br; duiding Mattos Filho en TicketNews, 09-2026). Het merendeel gold meteen, maar de verplichtingen over primaire en secundaire verkoop, wachtrijen en beveiligingsmechanismen treden twintig dagen na publicatie in werking: 21-09-2026, over drie dagen. Letterlijk: de oorspronkelijke verkoper moet mechanismen inzetten om massale, abusieve of speculatieve aankoop te voorkomen, "inclusief via robots, software en scripts"; bij evenementen met hoge vraag mogen virtuele wachtrijen, pré-cadastro (voorafgaande registratie) en limieten per koper worden opgelegd; en platformen moeten mechanismen aannemen om patronen van habitueel, professioneel of georganiseerd handelen te herkennen. Sportevenementen vallen erbuiten. De klant, met naam en stad: Sympla (Sympla Internet Soluções, Belo Horizonte, Minas Gerais, opgericht 2012 door Rodrigo Cartacho, Marcelo Cartacho en David Tomasella) — het grootste online evenementenplatform van Brazilië, met bijna 90.000 evenementen en 20.000 actieve organisatoren. Sympla is een primaire verkoper, en het is precies de primaire verkoper die het decreet aanspreekt. Waarom de bestaande aanpak tekortschiet. "Limiet per koper" wordt vandaag gemeten op e-mail, kaart of CPF-veld. Een CPF is een nummer dat je intikt, geen bewijs dat jij het bent; e-mails en kaarten zijn oneindig. Het decreet vraagt niet om minder bots maar om een koper die telt als één koper. Dat is een uniciteitsprobleem, niet een botprobleem. 🔌 Integratievorm: API-sleutel op hun backend, plus een webbuild-widget op het pré-cadastro-scherm. Opzetpad: (1) onze attest-deur en de poort draaien al; (2) Franky bouwt een gov.br-koppeling naast itsme — ± 5 dagen, en dit is de echte kost, want gov.br is een ander OIDC-eindpunt dan Signicat en de Braziliaanse LGPD stelt andere eisen dan de AVG; (3) de klant zet één knop in zijn wachtrij: één bewezen mens = één plaats in de rij, en een tweede poging op dezelfde mens krijgt geen tweede plaats; (4) standaard: OIDC, zoals bij itsme; (5) kleinste demo zonder toestemming van Sympla: onze eigen poort op turbeau2rock met een limiet van één kaartje per bewezen mens, in het Portugees. 🧩 Productmix: V + G (de wachtrij is de afgeschermde ruimte) + D (herhaalde speculant op de persoon-root, niet op het account) — trede 2, attestatie zonder geldstroom, groeipad naar trede 3 zodra Sympla ook de terugbetaling per mens wil boeken. Meter: M1 per nieuwe bewezen koper, daarna M2 voor elke raadpleging in de wachtrij. ⚠ De open vraag, en die gok ik niet: R4M draait op de Belgische eID en itsme. Brazilië heeft gov.br, geen eIDAS. Bouwt Franky een tweede identiteitsbron, of gaat deze case naar de plank tot er een Europese ticketverkoper met dezelfde plicht opstaat? Dat is een keuze voor Franky, geen technische afweging. Zo zet je dit in de markt: alleen als het antwoord op die vraag ja is. Openingszin dan: "Vanaf 21 september moet u limieten per koper afdwingen. Uw systeem telt vandaag e-mailadressen. Wij tellen mensen — en we tonen u het bewijs zonder dat u één identiteitsgegeven hoeft te bewaren."
18-09🆔 IDENTIFICATIE-CASE · Voor het eerst veroordeeld omdat de mens achter de vennootschap niet geverifieerd was — en 18-11 is de harde datum voor alle anderen — De Britse Insolvency Service haalde op 16-09-2026 bij de City of London Magistrates' Court de eerste veroordelingen ooit binnen voor het niet naleven van de identiteitsverificatie bij Companies House, onder de Economic Crime and Corporate Transparency Act 2023 (GOV.UK; detail ID Tech, 17-09-2026). Drie bestuurders beboet: Jill White (White (Reading Properties) Limited) £166 + £85 kosten + £66 toeslag omdat ze als niet-geverifieerde bestuurder aan besluiten deelnam en jaarrekeningen tekende; Marc Dillon £307 + £85 + £123 omdat hij niet verhinderde dat zij dat deed terwijl hij de plicht kende; Modinat Banjo (J Isogony Apparel Limited) £80 + £85 + £32. De klok die eronder hangt: alle bestaande bestuurders en PSC's moeten hun identiteit geverifieerd hebben tegen 18-11-2026 — over 61 dagen. Wat hier nieuw aan is voor het dossier. "Companies House", "UBO" en "ondernemingsregister" komen nul keer voor in cases-db.json (197 cases). Dit is dus een toepassingsgebied dat we niet hadden: niet "is deze klant echt" maar "is de mens achter deze rechtspersoon een echte, geverifieerde mens" — en voor het eerst met een strafrechtelijke uitkomst in plaats van een boete van de toezichthouder. Eerlijk over de koper: die is er hier niet. De Britse markt zit achter het DVS Trust Framework; alleen gecertificeerde aanbieders mogen dit doen en er staan er al 46 op het register. R4M is niet gecertificeerd en dat wordt geen weekwerk. Bovendien botst dit op de eigen nietDoen-regel over gereguleerde KYC. Deze vondst is dus geen verkoopdossier maar een bewijsstuk. Richting: VOLG, en gebruik het als argument. België kent voor het UBO-register geen verificatieplicht met een strafrechtelijke staart. Het Verenigd Koninkrijk zet nu de norm dat een niet-geverifieerde mens achter een vennootschap een misdrijf is. Dat is het soort precedent waarmee je in Brussel een gesprek begint. 🔌 Integratievorm: n.v.t. vandaag — als België of de EU dezelfde stap zet, is het een OIDC-knop op het inschrijvingsscherm van de onderneming (itsme, LOA high), niet een documentcontrole. 🧩 Productmix: V + C (welke rol gaf de vennootschap aan die mens), attestatiekant, trede 2. Zo zet je dit in de markt: niet als mail naar een Britse partij. Wél als zin in elk Belgisch gesprek: "Sinds 16 september zijn in Londen de eerste bestuurders veroordeeld omdat ze hun identiteit niet lieten verifiëren. Dat komt hierheen. De vraag is of u dan een documentscan doet of een eID-bewijs."
18-09💶 GELD-CASE · Eén man haalde 27.052 uitbetalingen uit 107 schikkingsfondsen — en de fraudedetectie die daarvoor gebouwd is, vraagt nog steeds niet of het dezelfde mens is — Het Amerikaanse openbaar ministerie (Western District of New York) klaagde Philip DiGennaro (38, Greece, NY) aan voor samenzwering, wire fraud, verzwaarde identiteitsdiefstal en witwassen. Tussen januari 2022 en december 2025 ontving hij ongeveer 27.052 betalingen voor in totaal $1.303.060,59 uit ongeveer 107 verschillende class-action-schikkingen, via ruim 480 bankrekeningen bij acht instellingen (Synchrony, Alliant, Chase, Key, M&T, PNC, Discover, Barclays) en PayPal; op 21-05-2026 werd $1.224.497,27 in beslag genomen (justice.gov, 07-2026; Claims Journal, 15-07-2026). De klant, met naam en stad: Angeion Group (Philadelphia, Pennsylvania, opgericht 2014) — schikkingsbeheerder; het managementteam voerde naar eigen zeggen meer dan 2.000 class-action-administraties uit en verdeelde meer dan $10 miljard onder gedupeerden. Angeion bouwde hier zelf een product voor: AngeionAffirm (10-2023) en AngeionAffirm 2.0 (07-2024), dat volgens het eigen persbericht tijdens het indienen in real time bepaalt of de indiener "a real person or an electronic fraud" is (PRNewswire, 07-2024). De weerlegging in één zin: DiGennaro wás een echte mens. Een botfilter dat "echte mens ja/nee" antwoordt, laat 27.052 claims van dezelfde echte mens gewoon door. De vraag die geld bespaart is niet "is dit een mens" maar "is dit alweer dezelfde mens" — en dat is exact wat een R4M-attestatie beantwoordt, zonder dat de beheerder één identiteitsgegeven hoeft te bewaren. De geldstroom en de meter. Hier stroomt écht geld: het schikkingsfonds betaalt de gedupeerden. Elke valse claim verdunt de pot van de echte gedupeerden — bij een fonds van $5 miljoen zakt $50 per persoon naar $10 zodra er vier keer zoveel valse claims bijkomen. Meter: M1 per nieuwe claimant (draagt de eID-kost, één keer per fonds), M2 voor elke herhaalcontrole binnen hetzelfde fonds (≈ gratis), M3 zodra de uitbetaling zelf over het attest loopt. Dat laatste is de trede waar dit pas écht R4M-werk wordt. 🔌 Integratievorm: API-sleutel op hun backend, op het claimformulier. Opzetpad: (1) attest-deur, poort en kasboek draaien al, en het kasboek sluit vanochtend op vijf invarianten; (2) Franky bouwt één claim-eindpunt dat per fonds-ID een pseudoniem terugkoppelt en een tweede claim weigert — ± 2 dagen, want de poort doet dit al per audience; (3) de klant zet één veld in zijn formulier en krijgt ja/nee terug, geen naam; (4) standaard: OIDC via de eID van het land van de gedupeerde; (5) kleinste demo zonder toestemming: een nagebouwd claimformulier op onze eigen poort waar een tweede claim op dezelfde mens zichtbaar geweigerd wordt. 🧩 Productmix: V + D (één claim per persoon-root, niet per bankrekening) + O (boeken vóór settelen, met bewijsbare bon) + P zodra de uitbetaling erover loopt — start op trede 2 met alleen het attest, groeipad naar trede 3 zodra de uitbetaling erdoor gaat. ⚠ Eerlijk: Angeion is Amerikaans en werkt met Amerikaanse gedupeerden zonder eID. Het Europese spoor is de richtlijn vertegenwoordigende vorderingen (EU) 2020/1828: elke lidstaat heeft sinds 2023 een collectieve schadeprocedure, en in België voert de FOD Economie dat register. Dáár zit de eID wél. Zo zet je dit in de markt: Europees beginnen, niet in Philadelphia. Openingszin: "Uw fraudefilter vraagt of de indiener een mens is. De man die vorig jaar 27.052 uitbetalingen uit 107 fondsen haalde, wás een mens. Wij beantwoorden de andere vraag: is dit dezelfde mens als claim nummer 11?"
18-09⚡ NIEUW TOEPASSINGSGEBIED · Compensatie- en schikkingsfondsen — 197 cases in de catalogus, en geen enkele gaat hierover — Nagemeten op public/cases-db.json vannacht: "class action", "claimfonds", "compensatie" en "ondernemingsregister" geven nul treffers over 197 cases; "schikking" één, en die gaat over de Meta-zaak, niet over het uitbetalen. ⚠ Correctie op mezelf, met de R4M-bril: in de engine-documenten staat het wél. docs/100_EURO_MOMENTS.md heeft als moment #30 "Class-action- en schikkingsuitbetaling: één claimant, één uitkering", met erbij geschreven "dit is letterlijk de rail". Het is dus geen ontdekking maar een gat tussen twee lijsten: de momentenlijst kent het, de cases-catalogus die Franky op de site ziet niet. Dat gat dichten is de echte actie. Het patroon zelf is groot: een pot geld die per persoon verdeeld moet worden onder mensen die de betaler niet kent. Dat is niet hetzelfde als een klantrekening (daar heb je al een relatie) en niet hetzelfde als een subsidie (daar is er een dossier). Onder hetzelfde patroon vallen: class-action- en groepsvorderingsfondsen, terugbetalingen na een datalek, compensatie bij vluchtvertraging, schadefondsen na een ramp, en cashback-acties van een merk. De aanleiding is de zaak-DiGennaro hiernaast (27.052 uitbetalingen, 107 fondsen, 480 rekeningen), maar het toepassingsgebied is breder dan die ene case. Wat het onderscheidt van wat we al hebben: de betaler heeft geen bestaande relatie met de ontvanger, kan geen account-geschiedenis gebruiken, moet binnen een deadline uitbetalen, en elke valse claim kost de échte gedupeerden geld — het is dus geen verliespost voor de betaler maar een verdelingsprobleem. 🧩 Productmix: V + D + O, trede 2 → trede 3. Meter: M1 per claimant, M2 per herhaalcontrole, M3 bij uitbetaling over het attest. Richting: DEUR. Dit is een Europese markt met een Europese rechtsgrond — richtlijn (EU) 2020/1828, in België uitgevoerd via boek XVII WER, met de rechtbank van eerste aanleg in Brussel als bevoegde rechter. Zo zet je dit in de markt: dit is een keuzevraag voor Franky, geen case die ik zelf aanmaak. Wil je dit als nieuw toepassingsgebied in de catalogus, dan hoort er eerst één Belgische of Nederlandse claimstichting bij met naam en vestigingsplaats — die heb ik vannacht niet nagemeten, en ik verzin er geen.
18-09🤖 AGENTIC · Mastercard bindt sinds 17-09 de opdracht van een mens aan de betaling van zijn agent — met Verifiable Intent, en zonder te vragen of die mens uniek is — Mastercard en Alchemy kondigden op 17-09-2026 een agentische betaaloptie aan op basis van Alchemy's AgentCard: een AI-agent kan overal waar Mastercard online aanvaard wordt kopen namens een consument, met "identity, wallet and one-time-use Mastercard credentials" voor de ontwikkelaar (PYMNTS, 17-09-2026). De kern voor ons is het Verifiable Intent-kader: het koppelt de identiteit van de consument, zijn concrete opdracht en de uitkomst van de transactie aan elkaar in één manipulatiebestendig spoor; de gewone kaart van de gebruiker blijft afgeschermd en de transactie draagt alleen de goedgekeurde handelaar en het bedrag. Citaten: Jorn Lambert (CPO Mastercard) "We believe it's not about if, it's about when and how quickly"; Nikil Viswanathan (medeoprichter/CEO Alchemy) over "agentic commerce into the mainstream"; Chiro Aikat (co-president VS) noemt ongeveer 132 miljoen consumenten die AI gebruiken. maX-bril eerst. Alchemy en AgentCard stonden op nul in marktradar.html en cases-db.json; Know Your Agent daarentegen kent het dossier uitstekend en die term staat al in x401.html, x402.html, strategie.html en cases-db.json. Dit item is dus de nieuwe helft, niet de herhaling. De weerlegging. Verifiable Intent bindt de agent aan een kaarthouder. Een kaarthouder is een rekening, geen mens: één persoon kan er vijf hebben en vijf personen kunnen er één delen. Voor "heeft déze mens dit gevraagd" is dat genoeg; voor "hoeveel verschillende mensen zitten hierachter" — de vraag bij elke uitbetaling, elke quotum en elk stemrecht — niet. Onze mandaatlaag (v0.42.0, mandaat-tabel en herkomstcontrole) hangt aan een persoon-root, niet aan een kaart. 🔌 Integratievorm: API-sleutel op hun backend. Opzetpad: (1) de mandaatroutes draaien sinds v0.42.0 en de poort kent al de soorten agent en mandaat; (2) Franky bouwt een vertaling van ons mandaat naar een Verifiable-Intent-bewijsstuk — ± 3 dagen, maar pas zinvol als Mastercard het kader publiek documenteert, en dat is vandaag niet zo; (3) de klant hangt het aan zijn checkout; (4) standaard: Mastercard Agent Pay; (5) kleinste demo: de bestaande poort van turbeau2rock die een agent zonder mandaat weigert en met mandaat doorlaat. 🧩 Productmix: C + V + G, trede 5 (machine handelt namens een mens) — juridisch niemandsland, en dat staat zo in de eigen tredenkaart. Richting: VOLG. Niet bouwen tot het kader gedocumenteerd is. Zo zet je dit in de markt: als argument in het x401-gesprek, niet als eigen bouwwerk. Openingszin: "Verifiable Intent bewijst dat een kaarthouder het vroeg. Het bewijst niet hoeveel verschillende mensen achter uw agenten zitten. Dat tweede getal is wat uw toezichthouder straks vraagt."
18-09⚙️ PROTOCOLWACHT · x402 stil op een Stellar-fix, x401 vier dagen stil, upto-EVM nog altijd nul — en de concurrentie voor x401 komt van buiten — Alle drie de bronnen vannacht om 03:0x zelf bevraagd, niet uit het nieuws. x402: jongste commit c8c71f2 van 17-09-2026 09:57, "fix(stellar): make the exact facilitator inclusion fee configurable (#3503)" — een Stellar-fee-instelling, geen spec-, scheme- of breaking-wijziging; de jongste tag blijft pypi-x402@v2.23.0 op 9b37f37 (15-09). Geen enkele commit in specs/ sinds de vorige ronde. x401: github.com/proof/x401 staat nog op dde015b van 14-09-2026 16:29 ("Update required to optional for oauth member") — vier dagen stil, en dat is geen feit, dus geen apart item. upto op EVM/Base — nulstand opnieuw bevestigd: typescript/packages/mechanisms/evm/src/upto/facilitator/scheme.ts geeft 0 treffers op resolveCallerIdentity|authorizerSigner|delegatedAuthStore|receiverAuthorizer over 134 regels, identiek aan de nulstand van 07-09. De identiteitshaak blijft dus op SVM/Solana; R4M draait base-sepolia met adapter usdc-base (nagemeten op /api/public/status) en raakt dit niet. Wat wél beweegt, en het komt niet uit de repo's: iProov publiceerde 17-09 met HAPS een concurrerend voorstel voor dezelfde plek als x401 (zie het x401-item van vannacht). De x401-repo stilte betekent dus niet dat de lijn stilstaat — ze betekent dat de beweging elders zit. Herhaalbaar: curl -s "https://raw.githubusercontent.com/x402-foundation/x402/main/typescript/packages/mechanisms/evm/src/upto/facilitator/scheme.ts" | grep -ci "resolveCallerIdentity\|authorizerSigner\|delegatedAuthStore\|receiverAuthorizer". Zo zet je dit in de markt: intern. De enige verkoopbare zin is dat onze motor op geen enkel punt achterloopt op de spec die vandaag geldt.
18-09⚖️ Kids Act · De officiële tekst is nu gelezen — de leeftijdsgrenzen schoven en de EU zegt zelf dat de EUDI-wallet de eindbestemming is — Op 17-09 stond hier dat de Kids Act-lezing uit een uitgelekte tekst kwam en dat de officiële tekst nog gelezen moest worden. Dat is nu gebeurd. De Commissie nam de EU KIDS Act aan op donderdag 17-09-2026 — voluit "EU Keeping Internet Digital Spaces Accountable and Trustworthy" — een dag na de State of the Union (Commissie, digital-strategy.ec.europa.eu; analyse Biometric Update, 17-09-2026). Wat afwijkt van de uitgelekte lezing van 15-09 en 17-09: de trappen liggen anders. Onder 3 geen toegang; 3–13 kindvriendelijke diensten via een ouder- of voogdaccount; 13 jaar is de ondergrens waaronder een platform geen gegevens van een minderjarige mag verwerken; 13 tot 15 krijgen mini-accounts die door de voogd worden opgezet en beheerd, met beperkte functies en schermtijd; vanaf 15 een eigen account. De uitgelekte tekst zei nog "13–14 introductie-accounts". De twee zinnen die voor R4M tellen. Eén: de leeftijdstechnologie moet "highly effective" zijn volgens de criteria van het EU Age Verification Scheme, en de Commissie beveelt haar eigen leeftijdsapp aan omdat die geen biometrie of identiteitsdocumenten bewaart. Twee, en dit is de belangrijkste: "Ultimately, the EU is headed towards a system in which EU Digital Identity Wallets are the first option for online age and attribute claims." Wat dat betekent. De zorg van 17-09 — dat "solutions provided by public authorities" een privé-attest zou buitensluiten — blijft staan voor de leeftijdskant. Maar de Commissie zegt in dezelfde adem "age and attribute claims": de wallet wordt de drager, niet de enige uitgever, en de guardian-band tussen volwassene en kind is geen leeftijdsclaim maar een attribuutclaim. Dat is precies het vakje dat een leeftijdsapp niet vult en dat de motor sinds v0.49.0 wél kent (ouderlijke toestemming, hetzelfde huishouden — niet het ouderschap zelf; dat verschil blijft eerlijk staan). Raakt geen bundel G15/G17/G18 — dit is DSA-terrein. Het voorstel moet nog door Raad en Parlement. Richting: DEUR, met een wachttijd. Zo zet je dit in de markt: de outreach naar FOD BOSA (DG Digitale Transformatie) kan nu wél vertrekken, want de officiële tekst ligt er. Openingszin: "De Kids Act vraagt van elk platform een bewezen band tussen voogd en kind. De EU-leeftijdsapp bewijst leeftijd, niet die band. Wij bouwden die tweede stap al, op itsme."
18-09🧭 BASISINKOMEN · Ierland maakte het eerste permanente basisinkomen ter wereld — 2.000 mensen, €325 per week, en een uniciteitsregel over zes jaar — Niet in het dossier, en het hoort er wel in: Ierland zette het Basic Income for the Arts-proefproject van 2022 om in een permanente regeling — volgens RTÉ de eerste van haar soort ter wereld. 2.000 professionele kunstenaars in de Republiek krijgen €325 per week gedurende drie jaar, uit een budget van €18,27 miljoen uit Begroting 2026, binnengehaald door minister O'Donovan. De aanvraagpoort liep van 15-04-2026 tot 12-05-2026 17:00; de eerste betalingen vertrekken vóór eind 2026 en de ronde loopt 2026–2029 (RTÉ, 01-04-2026; Citizens Information). De regel die dit een R4M-vondst maakt en geen nieuwsbericht: je kunt de BIA maar drie jaar uit elke zes ontvangen. Wie in 2026–2029 geselecteerd is, mag niet meedoen aan 2030–2033, wél aan 2034–2037. Dat is een uniciteitsregel over een venster van zes jaar en over drie afzonderlijke selectierondes heen — precies het soort regel dat vandaag met een naam-en-PPS-nummer in een spreadsheet wordt bewaakt, en dat een attestatie op de persoon-root zonder bewaarde persoonsgegevens kan afdwingen. Waarom dit voor de noordster telt. Het dossier praat over inkomensvloeren als richting; hier is er één die niet meer "pilot" heet. Een permanente inkomensvloer met een selectie-quotum heeft per definitie een teller nodig die mensen telt en geen dossiers. Dat is de rail, niet de pot. 🧩 Productmix: V + D (drie-uit-zes op de persoon-root) + O, trede 2 → trede 3 zodra de betaling erover loopt. Meter: M1 per geselecteerde mens, M2 bij elke volgende ronde. ⚠ Eerlijk: geen koper vannacht. Het Department of Tourism, Culture, Arts, Gaeltacht, Sport and Media voert dit uit, en een Iers departement koopt via overheidsopdrachten — dat is dezelfde deur die in de nietDoen-lijst al op een federale administratie is dichtgedaan. Richting: VOLG, en gebruiken als bewijs. Zo zet je dit in de markt: als zin in het verhaal, niet als mail. "Het eerste permanente basisinkomen ter wereld draait in Ierland en het heeft een regel die zegt: drie jaar uit elke zes, per mens. Zo'n regel valt of staat met de vraag of je mensen kunt tellen."
18-09🌍 REGIO · Nigeria wil 95% digitale ID vóór nieuwjaar, Polen opent zijn EUDI-zandbak — en Nieuw-Zeeland laat een bank een attest in de overheidswallet zetten — Drie regio-signalen uit dezelfde dag, alle drie gedateerd 17-09-2026 (ID Tech Digest, 17-09-2026). Nigeria: president Tinubu droeg de National Identity Management Commission op om vóór het einde van dit jaar 95% digitale-ID-dekking te halen — een schaalsprong in een land van meer dan 200 miljoen inwoners (Biometric Update). Polen: het Ministerie van Digitale Zaken opende de mObywatel Europa-zandbak waarin partijen hun wallet-koppeling kunnen testen vóór eIDAS 2.0; het Poolse identiteitsbedrijf Identt is een van de eerste deelnemers. Dat is de eerste EU-lidstaat waar een derde partij zijn EUDI-koppeling in een officiële zandbak mag proberen — het soort deur dat R4M voor België nog niet heeft. Nieuw-Zeeland: Westpac kreeg accreditatie om een bankrekening-attest uit te geven in de Govt.nz-wallet, zodat een klant geverifieerde rekeninggegevens kan delen zonder een PDF-uittreksel. Dat is een privé-uitgever die een attest in een overheidswallet legt — exact het model waarvan de Kids Act-lezing hiernaast zegt dat de EU er ook naartoe gaat. Richting: Polen is VOLG met een actie: als de mObywatel-zandbak openstaat voor niet-Poolse partijen, is dat de goedkoopste manier om een EUDI-koppeling te bewijzen zonder Belgisch traject. Niet nagemeten of buitenlandse deelname toegelaten is — dat is de eerste vraag, geen aanname. Nigeria en Nieuw-Zeeland zijn achtergrond, geen markt. Zo zet je dit in de markt: intern. Zet de mObywatel-vraag op de lijst voor de week: één mail naar het Poolse ministerie is goedkoper dan een half jaar wachten op een Belgische zandbak.
18-09💶 FUNDING · Nachtronde: drie bronnen woordelijk ongewijzigd, geen harde datum binnen veertien dagen, niets urgent — Alle drie vannacht om 03:1x aan de bron nagelezen, niet uit het geheugen. imec.istart — imecistart.com/en/apply, rij BELGIUM: "Autumn 2026 · Open call Sept 1 - Sept 30 (midnight)", daaronder "Spring 2027 · Jan 1 - Jan 30 (midnight)" en "Summer 2027 · May 1 - May 31 (midnight)". Woordelijk ongewijzigd. Niet urgent, en dat is geen inschatting maar het besluit van Franky van 16-09: de ronde van 30-09 wordt overgeslagen, mikpunt is de ronde van januari. De volgende harde deur is dus 01–30 januari 2027. NLnet Restack — nlnet.nl/restack: "November 3rd 2026 12:00 CET (noon)", ongewijzigd, en zacht (verdere deadlines op de derde dag van elke oneven maand). Geen nieuwe oproepen op de pagina. Base Batches — base.org/batches toont nog altijd "Applications Closed" en beschrijft batch 004 als de vierde lichting; geen Base Batches 005. Hardheidstoets: geen enkele harde datum binnen veertien dagen. De EIC Accelerator blijft de grootste som op het bord en blijft zacht — stap 1 wordt gebundeld op de eerste dinsdag van elke maand, dus 06-10-2026 17:00 Brusselse tijd. Geen 🚨-vlag, geen push: een vlag die elke dag wappert is geen vlag. Zo zet je dit in de markt: intern. De enige funding-actie die vandaag zin heeft is de EIC-stap-1-tekst schrijven vóór 6 oktober — dat is geen paniek, dat is planning.
18-09🧪 TEST · De motor om 03:05: 500 groen, 2 overgeslagen, 78 bestanden op v0.50.0 — geen drift, kasboek sluit op vijf invarianten — Gemeten 18-09-2026 03:05 op main van /Volumes/8TB MM4/Rails4Mankind, schone working tree. npm test: 500 geslaagd, 2 overgeslagen (502), 78 bestanden, 0 rood, 8,52 s. Geen versiedrift: VERSION en package.json staan op 0.50.0, de jongste tag is v0.50.0, en /api/public/status antwoordt "version":"v0.50.0". Kasboek: /api/public/reconciliation geeft ok:true op alle vijf invarianten — gefund 21,76 = vastgehouden 16,76 + uitbetaald 5 + fees 0, verschil 0 (testnet-USD). Publieke checks: netwerk base-sepolia, adapter usdc-base, stage pilot; app_live, attestations, double_entry_ledger en itsme_eid verified=true (itsme sandbox, gemeten 17-09 23:27 UTC), settlement_adapter en email_login alleen configured. 13 echte attestaties, 0 levend, 1 unieke mens — ongewijzigd. Claims-check ongewijzigd tegenover 17-09: acht cases met "alleen onder wettig bevel" (13, 29, 40, 42, 48, 92, 95, 108), negen met "anoniem", drie met "weggegooid" — niet opnieuw als vlag, en niets zelf herschreven. Herhaalbaar: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test. Zo zet je dit in de markt: 500 groen en één mens in de databank. De keten werkt; het volume is nog nul, en dat verzwijgen we niet.
18-09⚠ AUDIT ◐ deels · De doorloop belooft nog steeds dat de motor nooit een leeftijd opslaat — sinds v0.48.0 doet hij dat wel, met opzet — Tweede dag, en nu met de code ernaast in plaats van met een vermoeden. public/doorloop.html zegt letterlijk: "omdat je nooit een leeftijd opslaat, alleen doorgeeft wat itsme op dat moment antwoordt", en verkoopt dat als argument ("de klassieke fout is een opgeslagen geboortedatum of een geverifieerd 18+-vinkje dat blijft staan — jij hebt geen van beide"). Wat de motor vandaag doet, nagelezen in src/identity/leeftijdGeheugen.ts op main, v0.50.0: er bestaat een tabel leeftijd_geheugen die per subject_hash bewaart dat "deze mens minstens N jaar is, bewezen op datum D", over alle afnemers heen. Het bestand legt zelf uit waaróm — één itsme-scan per mens in plaats van per app, anders is een app met een miljoen gebruikers onbetaalbaar — en het is net zo eerlijk over de tweede helft: "voor N mag deze mens opnieuw proberen vanaf datum X" is versleuteld, en "X is zijn N-de verjaardag in vermomming. Dat is Nele-vraag V94." Het oordeel is ◐ deels, niet ⚠ theater. De bouwkeuze is verdedigd, gedocumenteerd en de scherpste kant staat al bij Nele. Wat niet klopt is de verkooptekst: die belooft iets absoluuts dat de motor met opzet niet meer waarmaakt. Precies het soort zin waar een auditeur een dossier mee opent. Deze routine herschrijft geen copy — dat is de staande regel, en ze geldt ook als de fout duidelijk is. Dus: gemeld, niets aangeraakt. Wat Franky moet beslissen: ofwel de zin in de doorloop nuanceren ("we slaan geen geboortedatum op; we onthouden wél dat u minstens N bent"), ofwel het leeftijdsgeheugen achter een knop van de afnemer zetten die standaard uit staat. Dat is een keuze tussen prijs en belofte, en die is niet van mij. Zo zet je dit in de markt: nog even niet. Een klant die dit zelf vindt, vindt het op de verkeerde dag.
18-09📋 STAND VAN DE SPOREN · Veertien inbrengen vannacht, en twee lijnen die eerlijk leeg blijven — 📡 IoT — leeg, en de reden is dat het dossier vóórloopt. De ontwerpplichten van de Data Act (verordening (EU) 2023/2854) gelden sinds 12-09 voor nieuwe verbonden producten; die datum staat al in case 93 en drie keer op deze radar. Nagezocht op nieuwe machine-to-machine-bewegingen: Mastercard Agent Pay for Machines dateert van 06-2026 en het Machine Payments Protocol van 03-2026 — beide ouder dan onze laatste IoT-regel en geen nieuw feit. Vullen zou hier liegen zijn. 💸 x402-lijn — geen eigen vondst, alleen de protocolwacht. De jongste beweging is een Stellar-fee-instelling van 17-09 09:57; de Arc-facilitator van Circle en het X Pay-mainnet staan er al sinds 16-09 en 14-09. Eén item, geen twee. ✉️ Secure Mail — niet aan de beurt: dat spoor loopt op maandag, en vandaag is het vrijdag. 🎯 Prospect: Sympla (Belo Horizonte) is de enige kandidaat die de lat haalt — echt bedrijf, vestigingsplaats nagemeten, bron met datum, wettelijke aanleiding met een klok van drie dagen. Hij hangt aan de open vraag of Franky een tweede identiteitsbron (gov.br) wil; tot dat antwoord maak ik er geen prospect van, want prospects aanmaken is niet aan deze routine. Angeion Group (Philadelphia) is de tweede kandidaat, met dezelfde rem: Amerikaanse gedupeerden hebben geen eID. 🔁 Doorloop-versterking: geen toevoeging vannacht. De enige doorloop-bevinding is de leeftijdsbelofte hiernaast, en dat is een correctie op bestaande copy — die mag deze routine niet schrijven. Zo zet je dit in de markt: niet. Dit is de dagboekregel die de nacht aan elkaar knoopt. Eerste actie van de dag: beslissen over de leeftijdsbelofte in de doorloop.
17-09🔍 AUDIT ✓ echt · de rem op de Fly-uitrol houdt een volle dag — Gemeten 17-09-2026 19:0x (fase BIJWERKEN) met gh run list --workflow deploy.yml naast git log. Sinds de merge van paths-ignore in deploy.yml (16-09 18:57): zeven codecommits (v0.47.0 t/m v0.49.0) gaven zeven Fly-uitrollen, alle geslaagd; zes docs/ops-commits (audits, ARCHITECTURE.md, ledger) gaven nul. Gisteren om 13:0x telde de audit nog achttien lege uitrollen. Live = VERSION = tag = v0.49.0 (/api/public/status, 17:05 UTC). Niet bewezen: of een wijziging in site/ die live moet nog meegaat — die rolt deze workflow bewust niet meer uit. Zo zet je dit in de markt: elke uitrol van de motor is nu één codewijziging met een eigen versietag — dat is de tijdlijn die je een auditor of partner toont als ze vragen wat er wanneer live ging.
17-09🧪 TEST · bronnenronde 17-09: 47 van 51 bronnen 200, nulstanden ongewijzigd, twee bronnen erbij — Avondronde van docs/BRONNEN.md: 55 metingen op 51 adressen, elke afwijking twee keer. De vier afwijkingen zijn dezelfde als gisteren en allemaal bekend (www-omleiding x402secure, ontwerp-404 t54, Cloudflare Access op r4m-max, @x402/casper nog niet op npm — derde avond). upto-EVM: 0 treffers, 134 regels. x402-kernspec: tellers identiek (identity 0, person 0, sybil 0, KYC 0). x401: geen commit na 14-09. Eén x402-commit sinds gisteravond: c8c71f2 (#3503), alleen Stellar — raakt onze motor op base-sepolia niet. Aanwas: het Bitquery-onderzoek naar x402-volume (06-09-2026, bitquery.io) en het CREG-kwartaaltarief voor thuisladen (creg.be) — allebei vannacht door spoor I gebruikt, nu bewaakt. Zo zet je dit in de markt: geen beweging in de spec betekent dat het mens-veld in x402 nog altijd leeg is — het argument van deze week blijft staan zonder bijschrift.
17-09💡 VOORSTEL · /healthz?deep=1 vraagt de keten nog maar één keer per 30 seconden — Tak voorstel/2026-09-17-healthz-diep-begrensd, commit 4cd1def (fase BOUWEN 13:0x). /healthz is publiek, en elke ?deep=1 deed een verse balansvraag bij de base-sepolia-RPC: een lus gewone GETs kon de limiet van de RPC-provider opmaken, en dan faalt ook de echte uitbetaling. Nu: één probe per 30 s die gelijktijdige vragen delen, met measuredAt erbij, de hangende timer opgeruimd, en Cache-Control: no-store. Nieuwe test 3/3 rood op de oude code, 3/3 groen op de tak. Niet op main, niet live. Zo zet je dit in de markt: een publieke motor die zijn eigen ketentoegang niet laat uitputten is een gewone hygiëne-eis van elke bank- of overheidsklant; beoordelen kost 5 minuten, details in het Audit-menu.
17-09🧪 TEST · 499 groen, 2 overgeslagen op de voorsteltak (79 bestanden) — Gemeten 17-09-2026 13:07 op voorstel/2026-09-17-healthz-diep-begrensd: npx tsc --noEmit groen · npm test 499 groen / 2 overgeslagen (501) · lokale server op poort 4035 met tijdelijke databank gaf twee keer hetzelfde measuredAt en de header no-store · npm run demo volledig door, invarianten I1–I5 groen. Main zelf (v0.49.0) telde vannacht 496 groen; het verschil is de nieuwe testfile. Commando: cd Rails4Mankind && npx tsc --noEmit && npm test. Zo zet je dit in de markt: geen verkoopzin — dit is het bewijs dat het voorstel niets anders breekt.
17-09💶 FUNDING · middaghercontrole: vier bronnen ongewijzigd, niets urgent — Nagemeten 17-09-2026 13:0x aan de bron: base.org/batches nog "Applications Closed", acceptaties 004 "Sep 17", geen 005 · nlnet.nl/restack deadline "November 3rd 2026 12:00 CET" (zacht) · circle.com/grant "Apply now", geen deadline (zacht) · imecistart.com België "Open call Sept 1 - Sept 30" — op het bord de verouderde actie "morgen urgent" vervangen door Franky's besluit van 16-09 (niet indienen, volgende deur januari 2027, hard). Geen harde datum binnen 14 dagen, dus geen vlag en geen push. Zo zet je dit in de markt: de eerstvolgende deur met geld is EIC stap 1 (bundeling di 06-10, zacht) — de gratis voorbeoordeling bij VLAIO blijft de goedkoopste eerste stap.
17-09🕘 OCHTENDRAPPORT 17-09 · Proof zet x401 in een bankproduct, Lancr bouwt op itsme — en de doorloop verkoopt nog dat R4M geen leeftijd bewaart — Fase RAPPORTEREN vatte het venster 16-09 08:30 → 17-09 08:30 samen: zeventien radar-inbrengen van fase VINDEN, acht kaarten naar de beslis-inbox (304–311, drie met een koper met stad), 496 tests groen op v0.49.0 zonder drift, acht releases in 24 uur en alle acht getagd. Ketencheck vijf keer OK, backup-alarm stil sinds 10-09, doorloop-API nul op goedgekeurd. Van gisterens drie acties zijn er twee gedaan (deploy.yml dicht, imec.istart beslist); de acht wettig-bevel-cases staan er nog. Zo zet je dit in de markt: het rapport staat op r4m-core-v2-k7x9.pages.dev#ops onder or-20260917; Lancr (kaart 304) is de enige vondst die vandaag een ja of nee vraagt.
17-09⚠ ONDER DE LAT · vier vondsten van vannacht halen de kwaliteitslat niet — ze staan in het rapport, niet als case — Spoor A: de tweede identificatievondst (EBU/Eurovisie online stemmen) steunt op een bron van 13-08 en een uitgelekt voorstel, dus niet op de radar. Spoor B: de Deezer-geldcase (kaart 306) gebruikt het 85%-cijfer van 21-07; alleen de koppeling met het IFPI-initiatief van 14-09 is nieuw. Agentic: Nevermined × Baselayer (kaart 309) zonder nagemeten vestigingsplaats. Regelgeving: de Kids Act-lezing komt uit een uitgelekte tekst, de officiële tekst is niet gelezen — dus de FOD BOSA-outreach wacht daarop. Zo zet je dit in de markt: niet. Beoordeel kaart 306 en 309 in de inbox als achtergrond, en gebruik het Kids Act-argument pas na de officiële tekst.
17-09🤝 x401 · Het eerste commerciële product op x401 is een bankidentiteit: Proof (Boston) mag sinds 08-09 van vijf VS-toezichthouders een herbruikbaar digitaal bewijs gebruiken — Op 08-09-2026 voegden FinCEN, Federal Reserve, FDIC, NCUA en OCC verifiable digital credentials toe aan de federale klantidentificatieregels (CIP). Op 15-09 lanceerde Proof zijn Verifiable Digital Credential: IAL2-identiteitscontrole, X.509-certificaat uit een eigen WebTrust-geaudite CA, SD-JWT en OID4VCI/OID4VP; volgens het persbericht is Proofs x401-protocol ontworpen om die identiteit mee te nemen in agenttransacties (GlobeNewswire, 15-09-2026: globenewswire.com/news-release/2026/09/15/3362157). R4M-bril: x401.html en bouwregel f1 kennen x401 al — nieuw is dat de maker er nu een betalend bankproduct met regelgever-dekking op zet. Wie: Proof, 8.000+ bedrijven. Waarom het ons niet nekt: VS, bank-KYC, en Proof belooft prove once — geen uniciteit, geen eID-wortel. Waar het ons raakt: dezelfde standaard, dus de EU-variant (eIDAS2/EUDI) wordt het speelveld. Richting: VOLG. Zo zet je dit in de markt: "In Amerika mogen banken nu een herbruikbaar identiteitsbewijs aanvaarden. R4M doet dat voor Belgen met itsme — en bewijst er ook bij dat het één mens is."
17-09🆔 Achttien muziekverdelers beloven sinds 14-09 elke uploader te identificeren en herhaalde fraudeurs te weren — DistroKid, tot 40% van de nieuwe muziek, tekende niet — IFPI lanceerde op 14-09-2026 het Streaming Integrity Initiative (Music Ally: musically.com/2026/09/14/ifpi-launches-an-anti-fraud-streaming-integrity-initiative; IMPALA, Brussel, zelfde dag). De 18 ondertekenaars — o.a. FUGA (Amsterdam), The Orchard, CD Baby, AWAL, Symphonic, Ditto — beloven "verify rights ownership and uploader identities … take action against fraudsters including repeat offenders; share intelligence with their peers". Niet getekend: DistroKid, Believe/TuneCore, SoundOn, UnitedMasters (Music Business Worldwide, 14-09). Geen invoerdatum. Het gat: een herhaalde fraudeur weren over verdelers heen vraagt de mens te herkennen, niet het account — en KYC-dossiers mag je niet zomaar delen. 🔌 Integratievorm: API-sleutel op de onboarding-backend van de verdeler + attest-oproep over verdelers heen. Opzetpad: 1) draait al: itsme + attest met pseudoniem per afnemer; 2) Franky bouwt een ‘geweerd door een deelnemer’-ja/nee zonder dossier (~5 dagen); 3) verdeler doet één oproep bij aanmelding en één bij een ban; 4) OIDC; 5) demo: twee nep-verdelers, mens X geweerd bij A, geweigerd bij B zonder naam. 🧩 Productmix: V + C, alleen attestatie; groeipad naar royalty-uitbetaling (M3). Keuzevraag voor Franky: valt het delen van een ban-signaal onder C of wordt het een eigen module — en mag dat juridisch (Nele)? Meter M1 bij aanmelding, M2 per check. Zo zet je dit in de markt: via IMPALA als neutrale plek voor de indies; openingszin aan FUGA: "U tekende maandag om herhaalde fraudeurs te weren en informatie te delen. Wij laten een tweede verdeler weten dat het dezelfde mens is, zonder dat u één paspoort deelt."
17-09💶 GELD-CASE · Deezer haalt tot 85% van de AI-streams achteraf uit de royaltypot — de pot wordt nog altijd per stream verdeeld, niet per mens — Deezer (Parijs) meldde op 21-07-2026 dat er dagelijks 90.000 AI-tracks binnenkwamen, meer dan de helft van de uploads, goed voor 1–3% van het luisteren, en dat tot 85% van hun streams vals is (newsroom-deezer.com/2026/07/ai-music-exceeds-50-percent-daily-uploads-deezer). Het initiatief van 14-09 pakt uploaders aan, niet valse luisteraccounts. R4M-bril: Deezer staat al in case 16 en case 76 — nieuw is de koppeling met de verplichting van 14-09, geen nieuw cijfer. ⚠ cijfers van juli, niet van deze week. Geldvorm: royaltypot per stream; wie meer luisteraccounts draait, int meer. 🔌 Integratievorm: API-sleutel op de royaltyberekening + batch-CSV van artiest-uitbetalingen. Opzetpad: 1) draait al: attest, pot, testnet-uitbetaling (Franky liep die keten op 12-09 zelf door); 2) Franky bouwt ‘uniek mens ja/nee’ per luisteraccount + CSV-import (~7 dagen); 3) Deezer weegt geattesteerde streams zwaarder; 4) OIDC, SEPA-weg zonder crypto; 5) demo: pot van €100, 10 echte en 90 bot-accounts, verdeling voor en na. 🧩 Productmix: V + C + P; eerst luisterattest, later uitbetaling. Keuzevraag voor Franky: attest verplicht of als bonus in het gewicht? Meters: M2 per account, M3 per uitbetaling — na PRIO B. Zo zet je dit in de markt: "U haalt fraude achteraf uit de pot; wij laten een stream pas meetellen als er vooraf een bewezen mens achter het account zit."
17-09💸 x402 · Circle zet Arc mainnet én een eigen x402-facilitator live (Arc, Base, Polygon) — ‘USDC is 98,8% van het agentvolume’, maar niemand weet wie er koopt — Live sinds 16-09-2026. Arc mainnet opende met 11 stichtende validators, onder wie BlackRock, DTCC, ICE, Mastercard en Visa, gas in USDC (circle.com/pressroom, 16-09-2026). Tegelijk de facilitator: Circle controleert de EIP-3009-toestemming en wikkelt af op de exact-scheme, de verkoper hoeft geen gas-wallet te draaien; API-sleutel nodig, proefversie zonder sleutel. Circle: 98,8% van het volume in agent-to-agent x402-betalingen gebruikte USDC (Crypto Briefing, 16-09-2026: cryptobriefing.com/circle-x402-facilitator-service-arc-launch). Reikwijdte: één facilitator, drie ketens waaronder Base. Raakt R4M onrechtstreeks: een tweede grote afwikkelaar naast Coinbase voor de keten van onze adapter usdc-base — of hij Base Sepolia draagt is niet nagemeten. Circle screent sancties, geen mensbewijs: onze laag blijft ernaast staan. Zo zet je dit in de markt: "Circle controleert of het geld mag bewegen, R4M bewijst dat er één echte mens achter de agent zit."
17-09🤖 Agentic · Baselayer en Nevermined binden bedrijfsidentiteit aan agentbetalingen — en schrijven zelf dat de mens achter de agent pas ‘later’ komt — Finovate (16-09-2026): Baselayer verifieert de verkopers op Nevermineds marktplaats; Nevermineds kaartdelegatie komt in Baselayers Trusted Registry zodat de agent vastzit aan zijn bestedingsbevoegdheid. Aan de bron: nevermined-io/docs PR #400, gemerged 15-09 15:05 UTC, +243 regels integrations/baselayer.mdx — voorbeeldplan $10 = 100 credits, 10 credits per oproep, x402-token op elke oproep. Het is KYB (bedrijven); mensbewijs staat uitdrukkelijk in de toekomst. Richting: DEUR. 🔌 Integratievorm: x402-resource + attest-header per oproep, volgens hun eigen integratiesjabloon. Opzetpad: 1) draait al: poort met x402 + attest (v0.49.0); 2) Franky schrijft een integratiepagina in hun sjabloon (1–2 dagen); 3) Nevermined merget de docs-PR; 4) standaard x402 V2 + x401; 5) kleinste demo zonder toestemming: een eigen Nevermined-plan dat een R4M-attest eist. 🧩 Productmix: alleen attestatiekant (V + O), rail niet; trede 1; groeipad naar M3 als hun kopers mensen uitbetalen. Zo zet je dit in de markt: "Baselayer weet welk bedrijf verkoopt. R4M weet welke mens koopt." Openingszin: "Jullie docs zeggen dat de mens achter de agent later komt — wij hebben die laag vandaag, op eID."
17-09🎯 PROSPECT · Lancr (Antwerpen) bindt sinds 15-09 elk freelancerprofiel aan itsme en de KBO — met de CRO van itsme in het persbericht, maar zonder bewijs dat een ander platform of een agent kan oproepen — Made in Antwerpen (15-09-2026: made-in.be/antwerpen/lancr-lanceert-platform-voor-geverifieerde-profielen…): Lancr lanceert gedeelde, geverifieerde freelancerprofielen; eerste laag is itsme gekoppeld aan KBO-gegevens. Partners: UNIZO, Connecting-Expertise, Freelancers in Belgium, FreelanceMatch, PIA Group. 234.466 actieve freelancers in Vlaanderen en Brussel (+7% op jaarbasis). Ramses Bossuyt, Chief Revenue Officer itsme: "met itsme als digitaal fundament … frictionless en waterdicht". Competitie én klant — wie: een Belgische reputatiewallet op dezelfde eID-leverancier; waarom het ons niet nekt: het bewijs blijft een profiel in hun app, geen oproepbaar attest, geen uniciteit over platformen, geen uitbetaling; waar het raakt: case 77 (Malt) en case 11. 🔌 Integratievorm: API-sleutel op hun backend. Opzetpad: 1) draait al: attest + x401-poort; 2) Franky bouwt attesttype ‘unieke mens + actief KBO-nummer’ (~3 dagen); 3) Lancr zet een knop ‘deel bewijs’; 4) OIDC + x401; 5) kleinste demo zonder toestemming: een agent huurt via x402 een freelancer in en ziet alleen ‘unieke mens + actief ondernemingsnummer’. 🧩 Productmix: V + C + G, rail optioneel bij uitbetaling (case 11); trede 1. Meter M2 per partnercheck. Contact: medeoprichter Khalid Neffari. Zo zet je dit in de markt: openingszin "U bewijst sinds deze week wie de freelancer is; wij maken dat bewijs meeneembaar naar elk platform en elke AI-agent die hem wil inhuren."
Ouder — 454 eerdere inbrengen (laatst bijgewerkt 18-09-2026, niets verwijderd)
17-09⚡ NIEUW TOEPASSINGSGEBIED · Revolut gaf paspoorten en selfies vrij aan een oplichter die mailde vanaf een écht overheidsdomein — niemand controleerde de mens achter de vordering — TechCrunch (12-09-2026: techcrunch.com/2026/09/12/revolut-confirms-customer-data-breach-through-fake-government-requests): Revolut bevestigt dat het klantgegevens — identiteitsbewijzen, verificatieselfies, transactiehistoriek — vrijgaf na valse vorderingen vanaf een echt e-maildomein van een overheidsinstantie; Revolut noemt het aantal ‘limited’ (Irish Times, 14-09). Security.NL (15-09) spreekt van ongeveer 700 klanten, onder wie 36 Nederlanders — ⚠ niet door Revolut bevestigd. Welke instantie: onbekend. Niet in de catalogus: SecureMail (case 88) bewijst de afzender, maar hier klopte het domein en was de mailbox misbruikt. Wat ontbreekt: per vordering een attest dat een bevoegde ambtenaar ze vandaag zelf indiende (mens + organisatie, cf. case 44). 🔌 Integratievorm: OIDC-knop in een vorderingsportaal + validatie per vordering met API-sleutel bij de bank. Opzetpad: 1) draait al: mens-attest; 2) Franky bouwt een vorderingsattest gebonden aan het dossiernummer, 72 u geldig (~6 dagen); 3) de bank zet vorderingen zonder attest in de wachtrij; 4) itsme/EUDI + rolattest van de werkgever; 5) demo: dezelfde vordering uit een gekaapte mailbox (geweigerd) en met attest (vrijgegeven). 🧩 Productmix: V + C + O, geen rail. Keuzevraag voor Franky: begint dit bij de banken (Febelfin) of bij de uitgever (FOD Justitie)? Meter M2 per vordering. Zo zet je dit in de markt: "Het adres klopte en toch was het geen ambtenaar. Wij laten elke vordering dragen wie ze vandaag zelf indiende."
17-09⚖️ Kids Act · De uitgelekte tekst noemt de ‘EU age verification tool’ én een ‘dedicated guardian app’ voor 13–15 jaar — de band ouder–kind wordt een wettelijk vakje — Aanvulling op de radar van 15-09. Nieuw uit de draft (ppc.land, gelezen 17-09: ppc.land/eu-kids-act-draft-sets-15-as-age-for-unsupervised-social-media-accounts; Euronews 15-09): autonoom account pas vanaf 15; leeftijdscontrole bij elk nieuw account via "the EU age verification tool or on other solutions provided by public authorities offering an equivalent level of accuracy"; voor 13–15 introductory accounts met een dedicated guardian app; AI-chatbots binnen scope; nog geen boeteregime. De officiële tekst komt vandaag, do 17-09 — niet nagelezen, lezen na 12:00 op de press corner. R4M-bril: case 92, en sinds vannacht v0.49.0 (ouderlijke toestemming, hetzelfde huishouden — niet het ouderschap). Let op: ‘solutions provided by public authorities’ kan een privé-attest buitensluiten — dat is de juridische vraag. Outreach-kandidaat: FOD BOSA, DG Digitale Transformatie — de Commissie-aanbeveling van 29-04-2026 vraagt tegen 31-12-2026 minstens één oplossing per lidstaat; niet nagemeten of België al koos. Zo zet je dit in de markt: "De guardian-app veronderstelt een bewezen band tussen volwassene en kind. Een leeftijdsbewijs alleen dekt dat niet — wij bouwden die tweede stap al."
17-09🌍 VS · ID.me en Plaid koppelen ‘wie is de ontvanger’ aan ‘van wie is de rekening’ voor overheidsuitkeringen — ‘dat gat kost miljarden’ — Aangekondigd 16-09-2026 (Biometric Update: biometricupdate.com/202609/id-me-partners-with-plaid-to-link-verification-for-users-bank-accounts). Blake Hall (ID.me): "that gap is where benefits go missing, and it's costing our government and everyday Americans billions"; Plaid-COO Eric Sager: "What's been missing is confidence about where money actually lands." Bouwt voort op het ID.me-Treasury-contract en de TreasuryDirect-verplichting (radar 15-09). Wie: ID.me (McLean, VA) + Plaid (San Francisco). Waarom het ons niet nekt: VS, selfie-KYC bij één private partij, geen uniciteitsgarantie over diensten heen. Waar het ons raakt: exact de noordster — uitbetalen aan één geverifieerde mens op een rekening die van hem is. Richting: VOLG (argument, geen markt). Zo zet je dit in de markt: "Zelfs de VS noemen het gat tussen persoon en rekening nu een miljardenlek; R4M sluit het met één attest, zonder centrale gezichtsdatabank."
17-09💸 x402 · $2,6 miljard x402-volume in augustus, maar negen tiende is één bridge — agents op Base en Polygon verplaatsten samen zo’n $57.000 — Bitquery-onderzoek (06-09-2026, bitquery.io/investigations/x402-ai-agent-payments-audit — buiten het 48u-venster, nog niet op de radar): $2,6 miljard over vijf EVM-ketens, waarvan $2,33 miljard op Arbitrum, "almost nine tenths of it is a single bridging contract". "Seven tenths of the payments are agents on Base and Polygon, and those moved about $57,000 between them." Op Base stuurde één wallet 13,2 miljoen betalingen naar één adres. Tweede onafhankelijke meting na TRM Labs (radar 15-09: 0,6–7,5% agentverkeer): het getelde volume is geen mensen- en nauwelijks agentvolume. Zo zet je dit in de markt: "Iedereen telt transacties. Niemand kan zeggen hoeveel mensen er achter zitten — dat getal leveren wij."
17-09🧭 COMPETITIE · Jumio rolt selfie.DONE uit in APAC: herbruikbare identiteit op een gezichtsgrafiek van 75 miljoen, 85.000 erbij per dag — 16-09-2026 (Biometric Update: biometricupdate.com/202609/jumio-launches-selfie-based-reusable-identity-tool-across-apac-region): tot 60% van de gebruikers geverifieerd zonder document, doelgroepen financiële diensten, crypto, gaming, deeleconomie. Wie: Jumio (Sunnyvale, VS). Waarom het ons niet nekt: APAC, en herbruikbaarheid via een centrale biometrische databank — in de EU onder GDPR art. 9 een zware last. Waar het ons raakt: dezelfde belofte ‘één keer bewijzen, overal hergebruiken’ bij dezelfde kopers (gaming, deeleconomie). Richting: VERMIJD de vergelijking op gemak, DEUR op privacy. Zo zet je dit in de markt: "Jumio onthoudt je gezicht. R4M onthoudt alleen dat je één mens bent — met je eID, zonder gezichtsdatabank."
17-09🌍 VS · Login.gov wordt de verplichte federale login — en zet stil een browser-ID van ongeveer twintig jaar — OMB-memo van 31-08-2026 maakt Login.gov de universal sign-on; een cookie _nds_experiment_uuid_ met een levensduur van circa twintig jaar werd op 14-09 goedgekeurd; een GitHub-issue daarover stond op 16-09 onbeantwoord (Biometric Update, 16-09-2026: biometricupdate.com/202609/login-gov-adds-persistent-browser-id-as-government-pushes-universal-federal-sign-on). Login.gov stond al op de radar op 28-08; nieuw is de verplichting plus het volgspoor. Richting: VOLG — tegenvoorbeeld. Zo zet je dit in de markt: bij GBA en BOSA: "een centrale login die het toestel twintig jaar volgt is wat je niet wil; R4M bewijst één mens zonder volgspoor."
17-09💰 FUNDING · Circle Grants kantelt naar ‘van testnet naar mainnet’ nu Arc live is — R4M zit op Base; nieuw: Digital Science Catalyst (£25K, hard 05-10) — Hercontrole 17-09 03:4x. Circle Developer Grants ($5K–100K, zacht, geen deadline): Arc mainnet live 16-09; Circles grantblog (18-03) zegt dat de volgende fase "will prioritize builders progressing from testnet to mainnet" — zonder Arc-poort daalt de fit. Keuzevraag voor Franky: eerst een Arc-testnetpoort, dan aanvragen? NLnet Restack 03-11 12:00 CET, zacht, ongewijzigd. EIC stap 1 bundeling di 06-10, stap 2 04-11, zacht. Alliance ALL19 early 23-09 — zacht, dus geen vlag. Base Batches 004: acceptaties vandaag, geen 005. Nieuw: Digital Science Catalyst Grant, tot £25K equity-free, thema ‘Agentic Workflows You Can Trust’, sluit ma 05-10-2026 17:00 BST — hard, lage fit (newsfilecorp.com/release/312372). VLAIO niet nagemeten (HTTP 403). Geen urgent. Zo zet je dit in de markt: geen nieuwe identiteitsoproep in EU/BE/NL deze week — de EIC-bundeling blijft de grootste routine.
17-09⚙️ PROTOCOLWACHT · x402 Go-SDK breekt de schema-interface (cf07e96) en MCP-herstel in Python — niets raakt onze stack; upto-EVM blijft op nul — Vijf commits na 16-09 03:00, geen spec-wijziging, geen nieuwe tag (jongste pypi-x402@v2.23.0, 15-09). cf07e96 (PR #3410, 16-09 03:37 UTC, +1128/−264, 36 bestanden): +CreatePaymentPayload(ctx, requirements, payloadCtx PaymentPayloadContext), de aparte ExtensionAwareClient verdwijnt (--regels) — een breuk voor wie in Go een eigen schema schreef; plus extra.minDeposit-hint voor EVM batch-settlement, EnforceMinDeposit standaard uit. Echte code, geen commentaar; alleen Go. c608a71 (#3495, +205/−6) en 165ff37 (#3494, +212/−7): MCP-herstel in Python; 1944976 (#3499) README-fix. Raakt R4M niet: motor is TypeScript, HTTP-poort, live base-sepolia / usdc-base (gemeten 17-09 01:06 UTC). Nulstand upto-EVM: scheme.ts 0 treffers, 134 regels — ongewijzigd sinds 07-09. x401 stil sinds dde015b (14-09); AP2, Visa TAP geen commits; Mastercard Agent Pay geen publieke repo. Te volgen: issue #3504 (16-09) — betaling zonder facilitator op ketens waar USDC het gas is. Zo zet je dit in de markt: niet — dit is onderhoud; de les voor onze eigen code: log ‘betaald’ pas als er een echte paymentResponse is.
17-09🧪 TEST · De motor om 03:06: 496 groen, 2 overgeslagen, 78 bestanden op v0.49.0 — geen drift, en elke release van het etmaal heeft zijn tag — npm test op main 956c5e6: Test Files 78 passed · Tests 496 passed | 2 skipped (498), 8,31 s, vitest 4.1.9 — 36 tests en 5 bestanden meer dan 16-09 (460/462). Versie: repo VERSION 0.49.0, package.json 0.49.0, git describe v0.49.0, live /api/public/status v0.49.0. Kasboek /api/public/reconciliation: ok, vijf invarianten groen, funded 21,76 = held 16,76 + paid 5,00 + fees 0. attestationsIssued: issued 13 (was 8), live 0, distinctHumans 1; itsme sandbox, verified 17-09 01:00 UTC. Claims-check ongewijzigd tegenover 16-09 (acht cases ‘alleen onder wettig bevel’, negen ‘anoniem’, drie ‘weggegooid’) — niet opnieuw als vlag. Commando: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test. Zo zet je dit in de markt: 13 echte attesten, één mens: de keten werkt, het volume is nog nul.
17-09⏱ AUDIT · Sinds v0.48.0 onthoudt de motor ‘minstens N jaar, bewezen op D’ — maar de doorloop verkoopt nog ‘Wij bewaren geen leeftijd, elke keer opnieuw’ — Doorloop stap 5 (Loterij-voorbeeld) zegt letterlijk: "Wij bewaren geen leeftijd. Wij stellen ze opnieuw vast, elke keer". Commit 96abd53 (v0.48.0, live sinds 17-09 01:52): tabel leeftijd_geheugen per subject_hash met "minstens N, bewezen op D" (monotoon, eeuwig) en een pas-cookie van één jaar — nooit de geboortedatum, maar wél een opgeslagen leeftijdsbewering. De zin staat ook in de kloon (r4m-max-clone/public/doorloop.html). Niet herschreven — melden is de regel; wel een NIEUW-deelpunt onder het blok met de stand van v0.47–v0.49. Twee opletpunten erbij: (1) 96abd53 schreef "Live pas na Nele V94" en af205bd "V94 loopt nog" — live ging op Franky’s eigen vrijgave, dus geen theater, maar de juridische toets loopt ná de uitrol; (2) v0.49.0 (ouderlijke toestemming) is volgens zijn eigen commit niet getest op de echte Signicat-sandbox (twee testpersonen met hetzelfde adres nodig) en staat live. Vonnis: ⏱ opletten. Zo zet je dit in de markt: zeg voortaan "wij bewaren nooit een geboortedatum, alleen ‘minstens N, bewezen op datum D’ op een pseudoniem" — dat is eerlijk én nog altijd sterker dan een opgeslagen 18+-vinkje.
17-09✓ AUDIT · Acht motorreleases in 24 uur (v0.46.1 → v0.49.0), alle acht getagd en alle acht door Franky vrijgegeven — de les van de ongetagde v0.46.0 houdt — git tag toont v0.46.1, v0.47.0, v0.47.1, v0.48.0, v0.48.1, v0.48.2, v0.48.3, v0.49.0; elke merge op main draagt Franky’s vrijgave in de boodschap (bv. 956c5e6: "zet v0.49.0 ook in main live"). Live = repo = v0.49.0. Het voorstel voorstel/2026-09-17-zeven-beloftes (v0.50.0, 03:06) staat al op origin — geen tak zonder upstream. Vonnis: ✓ echt. Zo zet je dit in de markt: elke versie is terugrolbaar naar een benoemd punt — dat is wat een auditeur vraagt.
16-09⏱ AUDIT · De kaartje-duur-merge staat live — meegenomen door de docs-push van deze fase, niet bewust uitgerold — Een andere sessie mergede om ±19:05 voorstel/2026-09-16-kaartje-duur-een-bron (goedgekeurd door Franky) op main zonder te pushen. De BRONNEN-push c9e31b8 om 19:08 droeg 1e8ff68 mee, met src/routes/poort.ts. Uitrol naar Fly: success om 19:11. Nagemeten: npm test op main 462 groen / 2 overgeslagen (74 bestanden) · live v0.46.0, base-sepolia · reconciliation 200. Dit bewijst ook het ongeteste geval van de rem: docs én src → wél uitrollen. Open: geen versiebump, dus live ≠ tag v0.46.0. Niet getest: een echte x402-betaling tegen de nieuwe 402. Fix: vóór elke push git log origin/main..main lezen. Zo zet je dit in de markt: niet — huishouden; wel een reden om v0.46.1 te taggen.
16-09✓ AUDIT · De uitrolrem werkt: een push met alleen ops/ start geen Fly-uitrol meer · v0.46.0 heeft zijn tag — Gemeten om 19:0x met gh run list -R DS2036/r4m-engine. Om 18:57 werd voorstel/2026-09-07-uitrol-negeert-docs-en-ops gemerged: deploy.yml slaat een push nu over als hij alleen docs/, ops/, site/ of *.md raakt. De merge zelf rolde nog één keer uit (terecht, hij raakte .github/). Proef: de ops-only push da5b8a1 om 19:01 startte géén run. En git ls-remote --tags origin v0.46.0 geeft 0dca12a — live v0.46.0 is weer terug te rollen naar een benoemd punt. Beide vonnissen van 13:0x (⏱ achttien lege uitrollen, ⚠ geen tag) zijn daarmee gesloten. Niet getest: een push die docs én src raakt (hoort wél uit te rollen). Zo zet je dit in de markt: niet — huishouden; maar een motor die alleen uitrolt als er code verandert is een bewijsbare uitrol, en dat verkoopt R4M.
16-09🔎 BRONNEN · Avondronde: 51 bronnen, 47×200, alle nulstanden ongewijzigd — Casper staat nog niet op npm — Vier afwijkingen, alle bekend en twee keer gemeten (x402secure 307, t54-hostnaam 404, r4m-max Access 302, npm-wacht 404). upto-EVM: 0 treffers, 134 regels. Kernspec x402 v2: 38.469 b, tellers identiek. x401: stil sinds dde015b. Op x402-foundation/x402 tien commits sinds gisteravond, geen spec-bestand: MCP-fixes (#3482/#3492/#3494/#3495) en extra.minDeposit voor de EVM-batch-settlement-scheme in Go (#3410) — reikwijdte die scheme, onze motor draait exact op base-sepolia, raakt ons niet. Nieuwe tag pypi-x402@v2.23.0; de repo zet @x402/casper sinds 15-09 18:18 UTC op 2.26.0 (9b37f37), maar registry.npmjs.org/@x402%2Fcasper geeft vanavond nog 404. Volledige ronde in docs/BRONNEN.md. Zo zet je dit in de markt: niets nieuws te verkopen vanavond; de Casper/Payouts.com-haak van 15-09 wordt pas concreet zodra het pakket op npm staat.
16-09⚖ BESLIST · imec.istart: de ronde van 30-09 wordt overgeslagen — mikpunt is januari 2027 — Franky besliste op 16-09-2026: niet indienen voor Autumn 2026. Reden: de aanvraag vraagt "a complementary team" en de BV is er nog niet; beide kunnen tegen de Spring 2027-ronde (open call 1-30 januari 2027, hard) wel rond zijn. Wat al klopt: "a working proof of concept" — de motor draait live op testnet met itsme-attesten, kasboek en poort. De 🚨 gaat van het subsidiebord. Nagekeken: FAQ en aanvraagpagina noemen geen vennootschaps- of zetel-eis; het aanvraagsjabloon zit achter een formulier en is niet gelezen. Zo zet je dit in de markt: gebruik oktober-december om de twee gaten te dichten (BV, tweede persoon) en toon in januari een eerste echte afnemer in plaats van een eigen test.
16-09⚠ AUDIT · Achttien Fly-uitrollen zonder code — en de jongste kwam van deze routine zelf, die [skip ci] vergat · v0.46.0 om 13:00 nog altijd zonder tag — Gemeten om 13:0x met gh run list --workflow deploy.yml naast git log --name-only. Sinds gisteren 13:00 acht nieuwe uitrollen, alle acht 'success'. Zeven raakten geen regel code: 7bb5593, 5bc118f, 7e6493c, f57ecef, 2a1e848 (docs/ en ARCHITECTURE.md), 7c36e35 (ARCHITECTURE.md, VERSIONS.md) en 1b007ef — de commit van fase VINDEN om 03:26. De achtste, dd63e80, was zelf ook docs, maar nam de nog niet gepushte v0.46.0-code mee naar Fly. Totaal nu achttien. Nieuw feit: de vier routine-commits mét [skip ci] (f6b291c, 2596beb, 897aa50, 4afa1f5) startten géén uitrol — de rem werkt per commit, hij ontbreekt alleen in deploy.yml. En git describe --tags origin/main geeft om 13:0x nog v0.45.2-19-g1b007ef: live v0.46.0 is nog altijd niet terug te rollen naar een benoemd punt. Zo zet je dit in de markt: niet — dit is huishouden. Maar R4M verkoopt bewijsbaarheid; tien minuten (tag v0.46.0 + merge voorstel/2026-09-07-uitrol-negeert-docs-en-ops) sluiten dit.
16-09◐ CORRECTIE · Een agent verliest zijn toegang niet halverwege — ons kaartje leeft tien keer langer dan het betaalvenster dat de poort aankondigt — Correctie op het AGENTIC-item van vannacht (x402 PR #3481, tienminutenplafond voor betaalde MCP-aanroepen), dat schreef dat een agent 'betaalt en halverwege zijn toegang verliest' als het kaartje te kort leeft. Nagemeten in src/routes/poort.ts: het kaartje leeft 600 s, wordt pas ná de aanvaarde betaling gemaakt en alleen bij binnenkomst gelezen. Het betaalvenster in onze 402 is 60 s — niet door ons gekozen, maar de stille standaard van x402-express (maxTimeoutSeconds ?? 60). Reikwijdte: #3481 zit in de MCP-clients van Go en Python; onze poort is een HTTP-poort, geen MCP-server. Er breekt niets. Wat wél klopte: het getal stond nergens expliciet in onze code — daarvoor ligt nu een voorstel klaar (item hieronder). Zo zet je dit in de markt: 'wij hebben x402 gelezen' betekent ook: het gevolg nameten vóór je het verkoopt.
16-09💡 VOORSTEL · Kaartje-duur en x402-betaalvenster uit één bron — tak voorstel/2026-09-16-kaartje-duur-een-bron — Commit d25334b, +9/−3 in src/routes/poort.ts plus één testbestand. KAARTJE_SEC wordt geëxporteerd en de reden 'kaartje N minuten geldig' leest hem, in plaats van een losse '10'. maxTimeoutSeconds staat nu expliciet op BETAALVENSTER_SEC = 60 in de 402 — dezelfde waarde als vandaag, dus geen gedragswijziging. De test legt vast dat elk betaalvenster korter is dan het kaartje. Tests: de nieuwe test op de oude code 2 van 2 rood · op de tak tsc groen · npm test 462 groen / 2 overgeslagen / 464 (74 bestanden) · server op poort 4034 met tijdelijke databank · npm run demo I1–I5 groen. Repo daarna terug op main, werkboom leeg. Niet getest: een echte x402-betaling tegen de tak. Niet gemerged, niet uitgerold — Franky beslist. Zo zet je dit in de markt: intern; het maakt de poort-uitleg aan een klant exact ('kaartje tien minuten, betaalvenster één minuut').
16-09🧪 TEST · Op de voorstel-tak: 462 groen, 2 overgeslagen, 74 bestanden — twee tests meer dan main vannacht — Gedraaid om 13:06 op voorstel/2026-09-16-kaartje-duur-een-bron in /Volumes/8TB MM4/Rails4Mankind: Test Files 74 passed (74) · Tests 462 passed | 2 skipped (464), 13,70 s. Main mat vannacht 460/462 op 73 bestanden; het verschil is precies het nieuwe testbestand. Live /api/public/status om 13:0x: v0.46.0, base-sepolia, usdc-base — geen drift met VERSION. Herhaalbaar: cd "/Volumes/8TB MM4/Rails4Mankind" && git checkout voorstel/2026-09-16-kaartje-duur-een-bron && npm test. Zo zet je dit in de markt: niet — dit is de bodem onder de poortdemo.
16-09💶 FUNDING · Middagronde: imec.istart ongewijzigd (30-09, hard, 14 dagen) — NLnet, Circle en Base Batches ook ongewijzigd — Om 13:0x aan de bron gelezen. imec.istart (imecistart.com/en/apply): 'Autumn 2026 Open call Sept 1 - Sept 30 (midnight)', daarna Spring 2027 (1-30 jan) en Summer 2027 (1-31 mei). Urgent sinds 03:00 en toen gepusht — geen nieuw feit, dus geen tweede push. De FAQ laadt zijn antwoorden nog steeds via JavaScript: of 'a complementary team' een tweede oprichter eist, blijft ongelezen. NLnet Restack: 'deadline of November 3rd 2026 12:00 CET (noon)', zacht; nieuw in de agenda een office hour 'Ask us Anything' op 30-09. Circle Developer Grants: geen deadline, 'Agentic economic activity' eerste prioriteit. Base Batches 004: dicht, acceptances 17-09 (morgen), geen 005. EIC niet zelf nagemeten (pagina via JavaScript). Zo zet je dit in de markt: de beslissing over imec (indienen of schrappen) kost twintig minuten en moet deze week vallen; na 30-09 is de volgende Belgische deur 1 januari.
16-09🕔 OCHTENDRAPPORT 16-09 · veertien dagen voor imec.istart, twee x402-bewegingen aan de bron, en een zevende uitrol die niemand besliste — Fase RAPPORTEREN vatte het venster 15-09 08:30 → 16-09 08:30 samen: twaalf radar-inbrengen van fase VINDEN, 460 tests groen op 73 bestanden, kasboek sluit op nul, de claims-vlag “alleen onder wettig bevel” zakte van twaalf naar acht cases, en vier kaarten (273–276) gingen naar de beslis-inbox. Ketencheck vijf keer OK, backup-alarm stil sinds 10-09, doorloop-API 47 items met nul op goedgekeurd — derde dag op rij. Zo zet je dit in de markt: het rapport staat op r4m-core-v2-k7x9.pages.dev#ops onder or-20260916; de geld-case (Liander/Enexis/Stedin) en imec.istart zijn de twee dingen die vandaag een beslissing van Franky vragen.
16-09📈 SEO-VLOOT · de keten meldt zich groen op “0 dagen”, maar meet vandaag 9 van de 21 domeinen — en drie staan al tien weken stil — Opgehaald uit ccc-v3.franky-f29.workers.dev/api/seo-watch op 16-09-2026 08:0x. Gemeten vandaag: 9 van 21. Beweging uitsluitend op Core Web Vitals, geen enkele op onsite: channel-zero.be +2, www.turbeau2rock.com −9, idgs.eu −10. Twaalf domeinen zijn niet vandaag gemeten: hiddengarden.be, hiddengarden-dsvdbuild.pages.dev en kortrijkspurs.be staan alle drie nog op 03-07-2026 (tien weken); ecoyess-landing, cobras-architects, elkodent, kortrijk-spurs-dsvdbuild, michiel-haverans-yware, my-cccnew en plastimet-webbuild-1 op 28/30-08; bks-nieuw op 09-09; bks-solutions op 14-09. De ketencheck zegt “SEO-meting 0 dagen geleden” omdat er élke dag gemeten wordt — alleen niet élke dag alles. Dat verschil stond nergens vast en staat nu hier. Zo zet je dit in de markt: twee keer dubbelcijferig omlaag op één dag is een eigen-huis-signaal, niet een klantsignaal — turbeau2rock is de site waar de x402-poort op draait, dus een CWV-val van 9 punten daar raakt de demo die Franky laat zien. Beslissing voor vandaag: de twaalf stille domeinen terug in de dagmeting, of uit de vloot.
16-09⚠ AUDIT · de oorzaak van zeven onbedoelde uitrollen staat nog woordelijk in deploy.yml — tweede dag dat dit als actie op de lijst staat — Fase VINDEN meldde vannacht de zevende onbedoelde uitrol (v0.46.0 live om 01:04, ongetagd). Deze fase mat om 08:0x de oorzaak zelf na, en die is niet weggenomen: .github/workflows/deploy.yml staat nog altijd op on: push / branches: [main] zonder paths-ignore. Gevolg: elke commit op main rolt de motor uit — ook een docs- of ops-commit van een routine die alleen een dagrapport wegschrijft. git describe --tags geeft v0.45.2-19-g1b007ef: de live versie is ongetagd en niet terug te rollen naar een benoemd punt. Dit stond gisteren als actie 2 in het ochtendrapport en is niet uitgevoerd. Zo zet je dit in de markt: niets — dit is huishouden, geen verkoop. Maar het raakt wel de verkoop: R4M verkoopt bewijsbaarheid, en een motor die live gaat zonder dat iemand dat besliste is precies het tegendeel. Tien minuten werk: paths-ignore op docs/** en ops/**, of [skip ci] in de backupcommit.
16-09⚙️ PROTOCOLWACHT · x402 zet Tether’s VS-gereguleerde dollar in zijn EVM-standaardlijst — en dat haalt het woord “crypto” uit je verkoopgesprek — Aan de bron gemeten vannacht: commit 4fb5d07 (PR #3457, 15-09-2026 03:56 UTC) voegt twee activa toe aan de standaardlijst van de EVM-mechanismen van x402 — USDT (0x48065fbBE25f71C9282ddf5e1cD6D6A887483D5e) en USAT, “Tether America USD” (0xD2ab3C9A02DBBAB236BfEC45D1d755DF4267F771), beide 6 decimalen, op Celo mainnet. Ik heb de patch zelf gelezen: het zijn echte +-regels in alle drie de SDK’s (go/mechanisms/evm/default_assets.go, python/x402/mechanisms/evm/default_assets.py, typescript/packages/mechanisms/evm/src/defaultAssets.ts), met de commentaarregel “Celo mainnet USDC, USDT, USAT (EIP-3009 supported)”. Reikwijdte, eerlijk: dit is de standaard-activalijst van de EVM-familie op één keten (Celo). De motor draait base-sepolia met adapter usdc-base (gemeten op /api/public/status, 16-09 01:05 UTC) — er verandert vandaag niets aan onze werking en er is niets te bouwen. Zo zet je dit in de markt: USAT is de dollar die Tether onder Amerikaans toezicht uitgeeft. Vanaf nu staat een gereguleerde stablecoin gewoon in de standaardlijst van het betaalprotocol waarop R4M rust. Dat is het antwoord op het bezwaar dat je bij elke klant krijgt — “wij doen niets met crypto” — want je kan nu zeggen: de rail draagt evengoed een gereguleerde dollar, en welke munt eronder ligt is bij ons een configuratieregel, geen herbouw.
16-09🤖 AGENTIC · x402 kapt betaalde MCP-aanroepen af op tien minuten — en daarmee krijgt de levensduur van ons poortkaartje voor het eerst een bovengrens van buiten — Gemeten aan de bron: commit 78ef8f0 (PR #3481, 15-09-2026 16:41 UTC) zet een plafond op de wachttijd van een betaalde gereedschapsaanroep via MCP — standaard tien minuten, met +60/−10 regels in go/mcp/client.go, een nieuw python/x402/mcp/utils.py en 95 regels test. In dezelfde ronde: #3442 en #3443 leiden die wachttijd af uit accept maxTimeoutSeconds van de server, #3482 laat de Go-client HandlePaymentResponse uitvoeren ná een betaalde aanroep, #3486 documenteert de instelling. Reikwijdte: de MCP-clients in Go en Python; R4M levert zelf geen MCP-client, dus er breekt niets. Het gevolg dat je wél moet anticiperen: de betalende kant krijgt nu een harde bovengrens die de verkopende kant kan meegeven. Voor onze poort betekent dat één meetbare eis: het kaartje dat een agent na betaling krijgt moet lánger leven dan de gereedschapstimeout die wij in ons eigen 402-antwoord aankondigen, anders betaalt een agent en verliest hij halverwege zijn toegang. Dat is geen theorie meer maar een getal dat aan de andere kant van de lijn ingebouwd staat. Zo zet je dit in de markt: dit is precies het soort detail waarmee je bij een klant het verschil maakt tussen “wij ondersteunen x402” en “wij hebben x402 gelezen”. Zet de vergelijking kaartje-TTL vs. maxTimeoutSeconds in het bouwboek en noem hem in het gesprek.
16-09🆔 IRCTC schrapt 30,4 miljoen gebruikers-ID’s en schorst er 63,3 miljoen — en geen enkele parameter is een mensbewijs — De Indian Railway Catering and Tourism Corporation (IRCTC, New Delhi) heeft 3,04 crore gebruikers-ID’s gedeactiveerd en nog 6,33 crore geschorst om kaartjeshandel en misbruik van het reserveringssysteem te stoppen (channeliam.com, 12-09-2026). Lees waarop ze gevlagd zijn: onrealistische mobiele nummers, wegwerp-maildomeinen, verdachte IP-adressen, en gebruikersnamen die opeenvolgend of wartaal zijn. Dat zijn vier patroonsignalen en nul mensbewijzen. Zo zet je dit in de markt: gebruik het cijfer, niet de klant. Dit is het grootste opgeruimde multi-account-veld dat ooit publiek geteld is, en het bewijst in één regel wat je bij elke prospect moet zeggen: patroonherkenning vindt de rommel pas achteraf en in bulk — 93 miljoen accounts diep — terwijl één mensbewijs vóór de inschrijving het probleem niet laat ontstaan. Richting: VERMIJD als markt, DEUR als argument. India blijft afgeraden en dat besluit staat al in de beslissingenlijst (het identiteitsgat is daar bezet door Aadhaar); dit wordt dus geen case en geen prospect, wel je sterkste cijfer in een Europees gesprek.
16-09🆔 38,5% van 19.368 sollicitatiegesprekken gevlagd voor AI-bedrog — en 61% van die gevlagde kandidaten haalde de slaagdrempel alsnog — Fabric (fabrichq.ai — vestigingsplaats vannacht niet nagemeten, dus dit is geen case) analyseerde 19.368 door AI gevoerde sollicitatiegesprekken tussen juli 2025 en januari 2026: 38,5% van de kandidaten werd gevlagd voor AI-bedrog, technische rollen 48% tegen 12% voor sales, en de vlaggingsgraad ging in drie maanden eind 2025 van 9% naar 45%. Het cijfer dat het interessantst is: meer dan 61% van de gevlagde kandidaten haalde alsnog de eigen slaagdrempel van 7 op 10. Gartner verwacht dat in 2028 één op de vier kandidaatprofielen wereldwijd nep is; mensen herkennen een deepfake met 55,54% nauwkeurigheid, nauwelijks beter dan een muntworp. Let op de weerlegging die je gratis krijgt: Fabric verkóópt die detectie, en SocialTalent schreef er meteen bij dat hun eigen cijfers het gesprek dat ze verkopen ondermijnen. Zo zet je dit in de markt: dit is de scherpste illustratie van je kernonderscheid. Detectie levert een kans op (“waarschijnlijk niet echt”) en dus een discussie met de kandidaat; een attestatie levert een feit op (“deze mens is één keer gebonden aan een eID”) en dus geen discussie. Zeg tegen een HR-koper: u koopt vandaag een waarschijnlijkheid die uw eigen leverancier zelf weerlegt.
16-09📡 IoT · Vanaf 01-01-2027 moet ook je laadpunt thuis het volledige laadprotocol spreken — en dan stroomt er geld terug naar een certificaat dat niemand aan een mens bindt — Twee data, aan de gids van laadplatform AMPECO nagelezen op 16-09-2026 (leveranciersgids, niet de verordening zelf — dat is de bron die ik gemeten heb): “January 8, 2026: All newly installed or substantially renovated publicly accessible AC charging points must implement EN ISO 15118-2:2016” en “January 1, 2027: All newly installed or renovated publicly accessible and private Mode 3 (AC) charging points must implement EN ISO 15118-20:2022” — die tweede versie draagt V2G, en de eis loopt vanaf dan ook je oprit binnen. Wie is wie in die keten? De gids zegt dat een contractcertificaat “is provisioned to the vehicle” via de sub-CA van de mobiliteitsoperator, en dat de eMAID “acts as the vehicle’s digital identity”, gekoppeld aan het laadcontract. De gids laat uitdrukkelijk open of dat certificaat aan het voertuig, aan de rijder of aan de contracthouder hangt — en precies dat openlaten is het gat. Bij V2G verkoopt de auto stroom térug, dus er stroomt geld naar dat certificaat; bij een leasewagen, een deelauto of een gezin met twee rijders weet niemand in de keten aan welke mens die opbrengst toekomt. 🔌 Integratievorm: API-sleutel bij de mobiliteitsoperator (eMSP), niet bij de laadpuntbezitter — de eMSP koppelt bij het aanmaken van een laadcontract één attestatie aan één eMAID. Wat al draait: attestatie-uitgifte en -raadpleging op de motor (v0.46.0). Wat Franky bouwt: een eMAID-veld in het attest, 2 dagen. Wat de klant doet: die attest-id meesturen bij contractaanmaak. Standaard: OIDC voor de mens, ISO 15118 blijft ongemoeid voor de auto. Kleinste demo zonder toestemming: een attest met eMAID-veld tonen naast een publiek voorbeeld-laadcontract. 🧩 Productmix: V (verificatie) + C (attestatie-oproep) — de rail doet hier niet mee, want de eMSP rekent zelf af; trede 2, met groeipad naar de rail als V2G-opbrengst per sessie uitbetaald gaat worden in plaats van via de energiefactuur. Zo zet je dit in de markt: dit is dezelfde vorm als de Alipay-robothond (13-09) en de irisbril van Alibaba (14-09), maar met een wettelijke datum eronder: “Vanaf 1 januari 2027 moet uw laadpunt V2G-klaar zijn. De norm bindt uw auto. Wie bindt de mens die het geld krijgt?” Sluit aan bij ledger-entry 33 (We Drive Solar).
16-09💴 GELD-CASE · Voor het eerst is de betaler een netbeheerder en niet de energiefactuur — maar het bedrag staat nergens, en de dubbele-deelname-vraag laat het persbericht zelf open — Omzet-lopende-band, €100-moment #20 (demand response voor gezinnen zónder EV of batterij). Aan de bron gelezen vannacht: Netbeheer Nederland, 26-06-2026 — Enexis, Liander en Stedin schalen samen met Eneco, Essent, Vattenfall, Frank Energie en Zonneplan (later ook Budget Thuis, Innova Energie, Quatt en Tibber) het slim aansturen op, voor huishoudens in Gelderland, Utrecht en delen van de Flevopolder en Noord-Brabant, op laadpalen, thuisbatterijen en hybride warmtepompen; de marktuitvraag “KV Flex Slimme apparaten” ging 1 juli de deur uit. Drie eerlijke bevindingen. (1) De betaler is hier een géreguleerde netbeheerder met een “financiële vergoeding”, niet een leverancier die korting geeft op de factuur — dat is nieuw tegenover ledger-entries 31 tot 34, waar het voordeel elke keer via de energierekening liep en de rail dus niet meedeed. (2) Het persbericht noemt geen enkel bedrag: geen euro per jaar, geen tarief per kW, geen vergoeding per activatie. De “tot €120 per kW flexvermogen” die je online vindt komt van een thuisbatterij-blog, niet van een netbeheerder. (3) Het persbericht zegt niet hoe een huishouden geïdentificeerd of ingeschreven wordt, en niet of één huishouden aan meer dan één programma kan meedoen. Dat tweede is exact onze wig — en het is vannacht een open vraag, geen claim. Uitkomst who-pays-filter: ⚠️ PARTIAL (koper met naam ✓, budget bestaat ✓, bedrag per eenheid door de koper zelf gepubliceerd ✗, euro bij de burger ◐). Meters: M1 bij inschrijving van een nieuw huishouden, M2 bij de controle “dit huishouden zit nog niet in een ander flexprogramma”; M3 niet aangetoond. Zo zet je dit in de markt: bel niet de leverancier maar de netbeheerder, en stel één vraag: “Uw uitvraag zegt niet of hetzelfde huishouden bij twee leveranciers flex kan verkopen. Weet u dat vandaag?” Als het antwoord nee is, is dat een gemeten gat bij een partij met gereguleerd budget.
16-09🚨 FUNDING · imec.istart is vandaag urgent: 30-09 middernacht, veertien dagen — en er staat sinds vannacht ook een Summer 2027-ronde op de pagina — Hercontrole aan de bron op 16-09-2026 03:3x, imecistart.com/en/apply: BELGIUM — “Open call Sept 1 - Sept 30 (midnight)”, ongewijzigd, en de drie eisen staan er nog letterlijk: “developing a tech product”, “a complementary team”, “a working proof of concept”. Nieuw feit vannacht: naast Spring 2027 (“Jan 1 - Jan 30 (midnight)”) staat er nu ook een Summer 2027-ronde (“May 1 - May 31 (midnight)”) — die stond er gisteren niet. Dat verandert de inzet: mis je 30-09, dan is de volgende deur 1 januari en de deur daarna 1 mei. Hard, en veertien dagen. Daarmee gaat de vlag vandaag aan volgens de eigen regel van het bord (harde datum binnen veertien dagen — veertien en niet zeven, omdat een dossier schrijftijd kost). De tijdzone staat nog steeds niet op de pagina; reken op Belgische tijd en lever niet op de laatste avond. Zo zet je dit in de markt: dit is de enige harde datum op het hele subsidiebord en het enige Belgische programma met een werkende proof of concept als toegangseis — en die heb je: de motor draait v0.46.0 met een sluitend kasboek en 460 groene tests.
16-09🧪 TEST · De motor om 03:0x: 460 groen, 2 overgeslagen, 73 bestanden op v0.46.0 — en het kasboek sluit op nul — Zelf gedraaid vannacht op main in /Volumes/8TB MM4/Rails4Mankind: Test Files 73 passed (73) · Tests 460 passed | 2 skipped (462), duur 11,79 s (vitest 4.1.9). Dat is 28 tests en 3 bestanden meer dan de 432/434 op 70 bestanden van 15-09. Geen versiedrift: VERSION en package.json staan op 0.46.0 en /api/public/status meldt v0.46.0. Kasboek: /api/public/reconciliation geeft ok:true met alle vijf de invarianten groen — i1 globale conservatie imbalanceUsd 0, i4 auditclaim funded 21,76 / held 16,76 / paid 5,00 / fees 0 / diff 0, geen negatieve saldi, geen cache-drift. Attestaties: 8 echt uitgegeven, 0 levend, 1 onderscheiden mens; itsme staat op sandbox en werd laatst waargenomen 15-09 23:25 UTC. Herhaalbaar met: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test en curl -s https://r4m-franky.fly.dev/api/public/reconciliation.
16-09⚠ AUDIT · v0.46.0 staat live zonder git-tag, en de commit van 01:10 zegt zelf dat hij onbedoeld uitgerold is — tien minuten na de commit die hem “GESTAGED, niet uitgerold” noemde — Vastgesteld vannacht in /Volumes/8TB MM4/Rails4Mankind. Om 01:00 legt commit 9340f91 vast: “v0.46.0 GESTAGED — leeftijdsvlaggen over_13/16/18 + minimumleeftijd per poort (Key Box); niet uitgerold, geen tag”. Om 01:10 legt commit 7c36e35 het tegendeel vast: “v0.46.0 is onbedoeld live (push van andere sessie 01:04)”. Nagemeten: /api/public/status geeft v0.46.0 (01:05 UTC), dus de uitrol is echt gebeurd; git describe --tags geeft v0.45.2, dus de live versie heeft géén tag en is niet terugrolbaar naar een benoemd punt. Vonnis: ⚠ theater op de uitrolrem. Dit is geen nieuw mechanisme maar de zevende keer dat een push op main de motor uitrolt zonder dat iemand dat als uitrol bedoelde — en de rem daarvoor ligt sinds 07-09 klaar op een tak die niet gemerged is. Wat Franky moet weten: de leeftijdsvlaggen staan live terwijl het werk van 01:01 (0dca12a) zelf zegt dat de AgeAttestationProvider een stub is die fail-closed staat. Dat is verdedigbaar — fail-closed betekent dat hij niets ten onrechte toestaat — maar het is wel live gegaan zonder dat iemand dat besliste. Twee dingen te doen: tag v0.46.0 alsnog, en merge de uitrolrem.
16-09⚠ AUDIT · Claims-check: “alleen onder wettig bevel” zakte van twaalf naar acht cases — maar geen van de acht draagt de stand-van-vandaag — Gemeten op public/cases-db.json vannacht. De zin “alleen onder wettig bevel” staat nog in acht cases, in het r4m- of vandaag-veld: 13, 29, 40, 42, 48, 92, 95, 108. Op 14-09 waren het twaalf, op 13-09 ook twaalf — er zijn er dus vier weggewerkt, en dat is de eerste beweging in deze vlag sinds ze bestaat. De vlag blijft toch staan, want de resterende acht dragen de vereiste nuance niet; case 29 luidt bijvoorbeeld letterlijk “een verzegeld bewijs dat alleen onder wettig bevel opengaat”, zonder één woord over de stand van vandaag. Daarnaast: “anoniem” in negen cases (54, 58, 82, 86, 103, 105, 111, 188, 189) en “weggegooid” in drie (86, 121, 197). Schoon gemeten: nul treffers op “structureel onmogelijk”, “kan niet gelinkt worden” en “1 integratie = 27 landen”, en géén “–” in db.strategie.matrix. Conform de opdracht heb ik geen enkele van die teksten herschreven — melden mag, herformuleren niet. Herhaalbaar met een grep op de drie velden per case.
16-09⏱ VERMIJD · De eerste boete ooit onder een anti-doorverkoopwet gaat over príjs, niet over identiteit — en het zoekresultaat dat het tegendeel beweerde heb ik voor publicatie weggegooid — Ontario beboette SeatGeek Canada voor $25.000 onder de anti-doorverkoopwet van april 2026 (BNN Bloomberg, 03-09-2026; de boete zelf viel eind augustus). Ik ben de opsplitsing zelf gaan nalezen, en die is: $10.000 voor het verkopen van een kaartje boven nominale waarde, $5.000 voor het niet bekendmaken van de oorspronkelijke aankoopprijs, en nog $10.000 voor een transactie zónder bewijs van de oorspronkelijke prijs. Er zit geen identiteitscomponent in. De zoekmachine-samenvatting die mij hierop bracht schreef dat derde bedrag toe aan “failure to conduct identity checks” — dat staat niet in het artikel, en de enige verificatie-uitspraak die er wél in staat gaat over príjzen: SeatGeeks Joe Freeman zegt dat “many sellers, including season ticket holders, don’t have access to the original face value of their tickets”. Zo zet je dit in de markt: niet. Dit is een VERMIJD-signaal en het is de moeite waard omdat het een aantrekkelijk verhaal kapotmaakt: de eerste handhaving ter wereld op kaartjesdoorverkoop keert op prijstransparantie, niet op wie de verkoper is. Verkoop mensbewijs dus níét aan doorverkoopplatformen op het argument “de handhaving komt” — ze komt, maar op een ander veld. Dit staat hier als les over bronnen, niet als kans.
16-09⚙️ PROTOCOLSTAND · upto-op-EVM blijft op nul, x401 stil sinds 14-09, en de MiCA-dubbelcontrole is vannacht wél gelukt — Vier vaste wachten, alle vier vannacht gemeten. (1) upto op EVM: typescript/packages/mechanisms/evm/src/upto/facilitator/scheme.ts telt 134 regels en 0 treffers op resolveCallerIdentity|authorizerSigner|delegatedAuthStore|receiverAuthorizer — de nulstand van 07-09 staat. De identiteitshaak blijft dus uitsluitend op SVM/Solana bestaan, en de bevestiging daarvan is commit 3c2ddfb (09-09): die splitst fóûten in de delegated-auth-store van upto-op-SVM, wat betekent dat ze daar aan het afwerken zijn en niet aan het overzetten. Onze motor draait base-sepolia, dus dit raakt ons niet — maar de wacht blijft staan. (2) x401: laatste commit in proof/x401 is dde015b van 14-09 (“Update required to optional for oauth member”) en die staat al op de radar van 14-09; sindsdien niets. (3) De buren: geen versie- of spec-wijziging gevonden bij AP2 (sinds mei 2026 bij de FIDO Alliance, met de werkgroepen Agentic Authentication en Payments), Visa TAP of Mastercard Agent Pay — alleen marketing en overzichtsartikelen, dus geen entry. (4) MiCA-dubbelcontrole: vannacht écht aan beide registers uitgevoerd, en de stand is onveranderd. FSMA art. 63 (fsma.be/en/list/authorised-belgian-crypto-asset-service-providers): HTTP 200, 155.517 bytes, “Nihil”, “Last verified date 11/09/2026” — FSMA voert dus nul Belgische CASP’s onder eigen bevoegdheid, en verwijst zelf door naar ESMA. De ESMA-kant via de leesbare spiegel casptracker.eu: HTTP 200, 3.136.668 bytes, “Data last changed: 11 September 2026 · Data last synced: 11 September 2026”, en voor België exact twee records, allebei onder de NBB: BNY SA/NV en KBC Bank NV. Dat is dezelfde stand als op 15-09, alleen met een nieuwere verificatiedatum. Twee meetlessen die in de bronnen thuishoren: het ESMA-CSV-pad met de maandmap (/sites/default/files/2026-09/CASPS.csv) geeft nu 404 — dat pad roteert en is dus geen bewaakbare bron; en fsma.be/en/list-crypto-asset-service-providers-article-63-mica bestaat niet (404), de werkende URL is die met /en/list/. Geen nieuw inhoudelijk feit, dus geen aparte entry.
15-09💸 x402 · Casper krijgt een officieel x402-pakket: de keten waarop Payouts.com uitbetaalt zit sinds vanmiddag in de SDK — R4M draait er niet op — Aan de bron gelezen: commit f4c3f61 (PR #2877, samengevoegd 15-09-2026 13:58 UTC) voegt @x402/casper toe aan de TypeScript-SDK van de x402 Foundation — exact-betalingen via CEP-3009 met csprUSD, handleiding in docs/schemes/exact.mdx (#3484), release voorbereid om 16:40 UTC, op npm om 19:1x nog niet gepubliceerd (404). In de Casper-spec zelf verdween één regel (+0/−1: de ondergrens validBefore ≥ now + maxTimeoutSeconds); de rest van de patch is context. Reikwijdte: alleen exact op Casper. Geen woord over identiteit of ontvanger. Raakt de motor niet: die draait base-sepolia met usdc-base. Met de maX-bril: Payouts.com × Casper staat sinds 25-08 op de radar en in de klantenlijst — nieuw is dat de partnerbelofte nu officiële code is. Anticiperen: een Casper-ontvanger is een ED25519- of secp256k1-sleutel, geen EVM-adres; wie bij Payouts.com een ontvangstadres aan één mens bindt, moet dat formaat aankunnen (niet getest). Zo zet je dit in de markt: openingszin voor Payouts.com: “Sinds vandaag kan elke x402-agent met het standaardpakket naar een Casper-adres betalen. Niets in dat pakket zegt wie achter dat adres staat — dat is het stuk dat R4M levert.”
15-09✓ Avondronde 15-09: de middagdeploy staat tot op de byte live, de motor zonder drift en zonder nieuwe uitrol, 46 van 50 bronnen 200 — Radar live 994.026 b en cases-db.json 6.122.946 b, gelijk aan de schijf. Motor v0.45.2 = VERSION; sinds 13:15 geen commit op main, laatste Fly-uitrol blijft de backup van 03:20. Doorloop: 47 items, 0 goedgekeurd. Voorstel-takken: 23 open (29 op origin, 6 in main). Vier afwijkingen, elk 2× gemeten, alle vier bekend (x402secure 307, kale t54-hostnaam 404, r4m-max.pages.dev 302 naar Access, www.startit-x.com 301). Nulstanden ongewijzigd: upto-EVM 0 op 134 regels, kernspec v2 38.469 b, t54 stil sinds 30-08, x401 niets na dde015b, Legwork alleen een opgeruimde afhankelijkheid. Start it @KBC: 'Fall 2026 closed', volgende periode 'Spring 2027' zonder datum. Upto-EVM ongewijzigd, nulstand bevestigd. Zo zet je dit in de markt: niets naar buiten — intern huishouden. De byte-gelijkheid tussen schijf en live is het bewijs dat wat Franky leest ook echt gepubliceerd is.
15-09💶 imec.istart om 13:1x zelf hermeten: 30-09 blijft hard, morgen wordt het urgent — de aanvraagpagina noemt drie eisen, en een ervan is een team — Fase BOUWEN las imecistart.com/en/apply rechtstreeks: BELGIUM 'Autumn 2026 Open call Sept 1 - Sept 30 (midnight)', ongewijzigd sinds 03:2x. De pagina zoekt startups die 'developing a tech product' zijn, 'a complementary team' hebben en 'a working proof of concept' bezitten. De FAQ laadt via JavaScript en is niet gelezen: of er twee medeoprichters en een Belgische zetel nodig zijn, blijft onbevestigd. Ook nagekeken: NLnet Restack 03-11 12:00 CET (zacht), Circle Developer Grants zonder deadline met 'Agentic economic activity' als eerste prioriteit. EIC en Start it laden nu via JavaScript en zijn deze fase niet zelf hermeten (fase VINDEN deed dat om 03:2x). Geen push: de datum valt vandaag op 15 dagen, de veertiendagengrens is morgen. Zo zet je dit in de markt: het werkende proof of concept bestaat: de live motor op r4m-franky.fly.dev en de weblock die op 13-09 een agent 0,05 USDC liet betalen. De open vraag is 'complementary team' — dat beslist Franky, niet de routine.
15-09⏱ Elf keer rolde Fly de motor uit zonder één regel code — de rem ligt sinds 07-09 klaar op een tak — Gemeten met gh run list naast git show --name-only: na 07-09 11:25 startten elf pushes naar main een Fly-uitrol waarin elk bestand onder docs/, ops/, site/ of *.md valt, de laatste vannacht om 03:20 door de automatische backup (4848e3f). Alle elf 'success'; live bleef v0.45.2, geen schade. Tak voorstel/2026-09-07-uitrol-negeert-docs-en-ops (457da59, +22 regels in deploy.yml) is op main 2596beb nog altijd schoon te mergen, en opnieuw nagekeken op v0.45.2: de app leest geen .md, serveert alleen app/, .dockerignore sluit site en ops al uit. Beslissing: tak mergen (5 minuten) of de backup [skip ci] laten meegeven. Zo zet je dit in de markt: niets naar buiten — intern huishouden. Een uitrolhistoriek die alleen code-uitrollen toont, is later wel het bewijsstuk dat je aan een auditor laat zien.
15-09💡 Voorstel voorstel/2026-09-15-versie-uit-een-bron: /api/public/status gaf vanuit een andere map stil v0.0.0 — publicApi.ts las VERSION relatief aan de werkmap; /healthz leest relatief aan het bestand. Gestart vanuit een andere map gaf /status, /config en /compliance "v0.0.0" terwijl /healthz 0.45.2 zei — en de dagcheck leest de live versie uit /status. Live is niet geraakt (Fly start in /app). Commit d620d38 (+57/−3): één bron, src/version.ts. Nieuwe test test/versie-een-bron.test.ts: op de oude code 3 van 3 rood ("expected 'v0.0.0' to be 'v0.45.2'"), op de tak groen. Server vanuit de scratchmap: beide endpoints v0.45.2; npm run demo volledig door, I1–I5 groen. Repo daarna terug op main, werkboom leeg. Niet getest: een Fly-uitrol van de tak. Zo zet je dit in de markt: een versienummer in publieke JSON is een bewijsstuk; het mag nooit verzonnen zijn, ook niet als terugvaloptie.
15-09🧪 De motor op de voorsteltak: 435 groen, 2 overgeslagen, 71 bestanden — main staat op 432 van 434 — Gemeten om 13:09 op voorstel/2026-09-15-versie-uit-een-bron (d620d38): 435 groen, 2 overgeslagen, 437 tests, 71 bestanden, 8,0 s; npx tsc --noEmit groen. De drie extra tests zijn de nieuwe versietest. Main (2596beb, v0.45.2) is deze fase niet opnieuw volledig gedraaid: 432 van 434 komt van fase VINDEN om 03:04. Commando: cd "/Volumes/8TB MM4/Rails4Mankind" && npx tsc --noEmit && npm test Zo zet je dit in de markt: niets naar buiten; het getal staat hier zodat een testaantal in een pitch altijd naar een meting met datum terugwijst.
15-09📄 Het ochtendrapport van dinsdag 15-09: een massadonor van 199 kinderen geeft case 75 en 95 hun bewijsstuk, drie kopers met naam, en een backup die de motor uitrolde — Het rapport over het venster 14-09 08:30 tot 15-09 08:30 staat op de Ochtendrapport-tab (or-20260915). Veertien radar-inbrengen van fase VINDEN plus één SEO-inbreng, negen kaarten in de beslis-inbox (257–265, drie met koper: UMCG, Nationale Loterij, RIZIV), vijf blokken op de CN-radar en drie op de India-radar. Testsuite om 08:07 hermeten: 432 van 434 groen, live v0.45.2 zonder drift, 8 attesten / 1 mens. Pijplijn onveranderd: 56 prospects, 0 gecontacteerd, 0 gereageerd. Claims-check vierde dag rood op twaalf "wettig bevel"-cases. Start it @KBC is dicht; imec.istart (hard 30-09) wordt morgen urgent. ⚠ Onder de lat: IoT leeg, Azerion zonder nagemeten vestiging. Zo zet je dit in de markt: niets naar buiten — de dagboekregel die de nacht aan elkaar knoopt. Eerste actie van de dag: imec.istart indienen of schrappen.
15-09🤖 Vandaag, 15-09, gaat de Cloudflare-standaard om: Agent-verkeer geblokkeerd op advertentiepagina’s van nieuwe domeinen, en “Verified” is geen toegangsbewijs meer — Cloudflare (San Francisco) schreef op 01-07-2026: "On September 15, 2026 … the categories of Training and Agent will be blocked by default on the pages that display ads, while Search will remain allowed by default" — voor alle nieuwe domeinen. In dezelfde tekst: Verified is niet langer "default allowed", maar maakt een bot "allowable with its relevant category"; voor tussenpersonen stelt Cloudflare de Forwarded-kop (RFC 7239) voor. Een Forwarded-kop toont wie het verkeer doorgaf, niet namens wie het besteld werd. Bron: https://blog.cloudflare.com/content-independence-day-ai-options/ (01-07-2026, nagelezen 15-09-2026 08:1x). Gevonden door de CN-radar; op deze radar stond op 22-08 alleen de datum. Bestaande klanten: de brontekst zegt "new domains", Remote Work Europe News (11-09) zegt dat ook gratis bestaande klanten meegaan — onopgelost. Raakt case 112 en de weblock van turbeau2rock-2026. 🔌 Integratievorm: x402-resource plus mandaatattest aan de poort (bestaat al in de motor sinds v0.42.0); kleinste demo zonder toestemming: een agent met mandaat die op de eigen proefsite wel binnenkomt waar een kale Verified-bot 403 krijgt. 🧩 Productmix: C + O, M2 per raadpleging, rail optioneel via x402. Zo zet je dit in de markt: dit is de zin voor de weblock-pitch — "sinds 15 september is geverifieerd niet meer genoeg; de site-eigenaar wil weten namens welke mens de agent komt." Geen contact met Cloudflare zelf: nog niet publiek zichtbaar.
15-09📊 SEO — vier sites 5 tot 12 punten lager, maar geen enkele site veranderde: de meetlat telt sinds vannacht 22 checks in plaats van 19 — Meting 15-09 05:40. De drie nieuwe foto-checks (alt, bestandsnaam, afbeeldingen in sitemap) staan sinds 15-09 in de audit. Het aantal geslaagde checks bleef gelijk of steeg, de noemer ging van 19 naar 22: blackfuelwhiskey.com 89 → 77 (17 geslaagd, vóór en ná), boombedrijfbisschop.be 84 → 73 (16 → 16), www.turbeau2rock.com 84 → 73 (16 → 16), qmtex.net 89 → 82 (17 → 18). lowlands 89 → 86 (17 → 19), idgs 100 blijft 100. Eén echte daling: channel-zero.be Core Web Vitals mobiel 70 → 60, LCP 11,2 s, desktop-CLS 0,511 — niet fixbaar zonder repo. Fout in de nieuwe meetlat: turbeau2rock staat op ‘fail, 3 van 3 zonder alt’ terwijl die beelden bewust een lege alt hebben (decoratief). Patch klaar in Site-Fleet/patches. BKS Solutions staat live op bkssolutions.be: nulmeting onsite 82, CWV 69, vannacht door Google gecrawld en geïndexeerd. Bron: https://ccc-v3.franky-f29.workers.dev/seo · https://bkssolutions.be. Zo zet je dit in de markt: niets voor R4M — dit staat hier zodat een dalend cijfer op de /seo-tab niet als een kapotte site gelezen wordt.
15-09⚠ AUDIT · Zesde keer: een docs-wijziging rolde de motor uit — dit keer nam de auto-backup de half afgewerkte ledger-regel van fase VINDEN mee — 15-09-2026 03:4x · ⏱ opletten. Fase VINDEN schreef om ~03:17 ledger-entry 34 in docs/USE_CASE_LEDGER.md en commitde die pas om 03:4x. Daartussen, om 03:20:13, maakte de automatische backup commit 4848e3f "[auto-backup] 2026-09-15 03:20:13" (alleen dat bestand, +14 regels) en pushte naar main — zonder [skip ci]. GitHub Actions "Deploy naar Fly.io" draaide daarop (run 34916853671, 01:20 UTC, success, 1m58s). Gevolg nagemeten om 03:4x: live nog altijd v0.45.2, app_live opnieuw waargenomen 01:39 UTC, 8 attesten / 1 mens — geen schade, wel een onnodige herstart van de live motor om 03:20. Dezelfde oorzaak als de vijf eerdere keren (12-09, 13-09): de deploy-workflow filtert niet op pad, en de backup zet geen [skip ci]. Nieuw is dat de routine het nu zelf niet kan voorkomen door haar eigen commitboodschap. Wat de routine vanaf nu doet: engine-docs pas op schijf zetten vlak vóór de eigen commit. Wat Franky kan beslissen (buiten deze routine): paths-ignore: [docs/**, ops/**] in deploy.yml, of [skip ci] in de backupcommit. Zo zet je dit in de markt: intern — geen actie naar buiten.
15-09🆔 Case 75 en 95 krijgen hun Nederlands bewijsstuk: één donor, minstens 199 kinderen, en het UMCG zegt dat het ‘ook nooit’ te controleren valt — Wat maX al zegt: case 75 ("Donor-limiet over centra heen") en case 95 ("Dezelfde donor, veertien landen, en elke teller begint opnieuw") beschrijven dit gat al. Nieuw is het gedateerde Nederlandse geval. RTV Noord (03-09-2026): massadonor Simon liet ouders weten dat hij "zeker 199" kinderen verwekte (eerder 121 bekend via Nieuwsuur); het UMCG (Groningen) weigerde hem al in 2021 omdat hij toen de limieten overtrad. Donoren moeten verklaren dat ze nergens anders doneren; de landelijke registratie sinds april 2025 "biedt geen waterdichte garantie". UMCG: ‘Wat er in de privésfeer gebeurt, is niet door de kliniek te controleren en zal dat ook nooit worden’. NOS (14-09-2026): ruim 30 ouders, verenigd in Stichting Donorkind, stellen hem aansprakelijk en eisen een juridisch bindend doneerverbod, dwangsom en schadevergoeding; de wettelijke grens is 12 gezinnen per donor (nos.nl/l/2630956). Het gat: de limiet geldt per mens, elke kliniek telt haar eigen dossiers. 🔌 Integratievorm: OIDC-knop bij de donorintake + QR "donor onder de limiet: ja/nee" voor wensouders. (1) Draait al: verificatie, attest, pseudoniem per context. (2) Franky bouwt een teller-attest "aantal gezinnen onder de limiet" zonder naam, 6–8 dagen (schatting). (3) Kliniek of register koppelt de intake aan het pseudoniem. (4) OIDC / OpenID4VP, SD-JWT. (5) Demo: QR-check op de testmotor met een fictieve donor. 🧩 Productmix: V + D + C; M1 per donor, M2 per check; rail doet niet mee; trede 2. Grens: privédonaties via internet blijven buiten bereik tenzij wensouders zelf checken; medische gegevens vragen een wettelijke grondslag (VWS); itsme in Nederland niet nagegaan. Keuzevraag voor Franky: het landelijke register (overheid, traag) of Stichting Donorkind als vrijwillige QR-check? Openingszin: "U zegt zelf dat de registratie nooit waterdicht wordt. Mogen we tonen hoe je per donor telt over alle klinieken heen, zonder zijn naam te delen?" Zo zet je dit in de markt: geen nieuw verhaal maar het bewijsstuk onder een bestaand: "het UMCG zei in 2021 nee, en hij doneerde gewoon verder".
15-09🆔 Case 143 staat vandaag live: de Nationale Loterij laat tot 15-11 stemmen op erfgoed — ‘Stap 1: identificeer jezelf’ — Wat maX al zegt: case 143 ("Nationale Loterij: één deelname per actie") en de Loterij staat al in 🎯 Doelwitten. Nieuw: de Erfgoedtombola. RTV (Lier): "Van 15 september tot en met 15 november kan iedereen gratis stemmen op zijn of haar favoriete erfgoedproject via de website van de Nationale Loterij. Op 24 november worden de drie winnaars bekendgemaakt"; twaalf finalisten, hoofdprijs 150.000 euro. De deelnamepagina (nationale-loterij.be/erfgoedtombola/hoe-deelnemen, gelezen 15-09-2026) opent met "Stap 1 - Identificeer jezelf". Volgens een onderzoeker van deze run eist het reglement een Nationale Loterij-account (18+, één stem per deelnemer, registratie via itsme) — het reglement zelf laadt alleen met JavaScript; die details niet zelf hermeten. Het gat: wie op erfgoed wil stemmen, moet een account openen bij een kansspelaanbieder. 🔌 Integratievorm: tweede OIDC-knop op de stempagina. (1) Draait al: V. (2) Franky bouwt een attest "18+, uniek per actie", 3–5 dagen. (3) De Loterij voegt een inlogroute toe. (4) OIDC. (5) Demo: nagebouwde stempagina met één stem per pseudoniem. 🧩 Productmix: V + C + D; M1 bij nieuwe mensen, M2 per stem; rail doet niet mee (prijzen in natura). Grens: geen incident — de Loterij lost uniciteit al op met eigen account + itsme; voor wie al speler is voegt R4M niets toe. Deur én concurrent. Openingszin: "U lost één mens, één stem op met een speleraccount. Mogen we tonen hoe dat werkt voor wie geen speler wil worden?" Zo zet je dit in de markt: een levend, gedateerd voorbeeld voor elke gemeente of vzw die een publieksprijs organiseert zonder loterijaccount.
15-09💶 Geld-case: een thuisverpleegkundige factureert 70.000 euro per maand terwijl het plafond 19.000 is — de controle telt nummers, geen mensen — VRT NWS (11-09-2026): het IMA, de koepel van de ziekenfondsen, vond met een nieuw controlesysteem dat "23 thuisverpleegkundigen dit jaar nu al tienduizenden euro's te veel hebben aangerekend"; volgens HLN.be gaat het in het zwaarste geval om 70.000 euro per maand, "terwijl het plafond neerkomt op zo'n 19.000 euro per maand". RIZIV (Erik Rossignol): het systeem moet ook naar tandartsen en kinesisten (vrt.be/vrtnws/nl/2026/09/11/nog-eens-23-thuisverpleegkundigen-gevonden-die-te-veel-factureer/). Geldvorm: terugbetaling door de ziekteverzekering aan zorgverleners. Meter: M1 per zorgverlener, M2 per prestatie-check; M3 niet (geld loopt via de ziekenfondsen); NU als attestkant, rail pas na PRIO B en waarschijnlijk nooit. Eerlijke grens: de bron zegt niet dat meerdere mensen onder één nummer werken — dat is onze lezing. Is de zorg nooit gegeven, dan helpt R4M niet; eHealth authenticeert zorgverleners al met eID/itsme. 🔌 Integratievorm: API-sleutel op de backend + batch-CSV van prestaties. (1) Draait al: V, C, attest. (2) Franky bouwt een prestatie-attest met teller per mens, 8–12 dagen (schatting). (3) IMA levert een CSV per pseudoniem. (4) eHealth/MyCareNet blijft hun kanaal. (5) Demo: fictieve CSV waarin drie nummers bij één mens horen die over het plafond gaat. 🧩 Productmix: V + C + D (+ O voor groepspraktijken). Keuzevraag voor Franky: een overheidsinstelling koopt via overheidsopdracht — dezelfde reden waarom case 30 onder nietDoen staat. IMA of één ziekenfonds, of niet? Openingszin: "Het plafond geldt per verpleegkundige, maar de controle ziet een nummer. Mogen we tonen hoe je per mens telt, zonder extra persoonsgegevens?" Zo zet je dit in de markt: als voorbeeld van een plafond per mens dat op een nummer hangt — niet als belofte dat R4M zorgfraude oplost.
15-09💸 x402 · TRM Labs meet het echte agentverkeer: tussen 0,6% en 7,5% van de gescreende x402-betalingen komt van agents — en ‘wie is verantwoordelijk’ kan het protocol niet beantwoorden — TRM Labs tech blog (Noah Hodge, 09-09-2026; Decrypt bracht het op 13-09): "roughly USD 52.7 million across 198.9 million settlement transactions" via bekende x402-facilitators op Base, Solana en Polygon sinds mei 2025; 99,6% in USDC. Na filteren lijkt 0,6% tot 7,5% echt door agents gedreven; het maandvolume van agents ligt rond $5.000–11.000. Letterlijk: "The x402 protocol wasn't built to answer, 'Who is responsible for this payment?'" — eigenaarsclaims zijn "unverified" en die verklaring is "voluntary and currently not utilized by the majority of participants" (trmlabs.com/trm-tech-blog/whos-actually-paying-measuring-ai-agent-payments-onchain). Wat maX al zegt: dit is exact de reden voor x401 en de poort; nieuw is een onafhankelijk cijfer. Richting: DEUR (argument) + VOLG (volume is klein — verkoop niet op volume). 🔌 Integratievorm: x402-resource: de poort vraagt naast de betaling een attest (M2), de bon verwijst naar het pseudoniem, de facilitator aggregeert per mens in plaats van per wallet. 🧩 Productmix: V + O; M2, M3 als de settlement over de rail loopt. Zo zet je dit in de markt: "Een analysebureau telt $5.000 tot $11.000 per maand aan echte agentbetalingen en kan niet zeggen wie erachter zit. Dat tweede is wat wij leveren."
15-09🤖 Agentic · Case 120 krijgt zijn Europese kassier: Worldline zet een betaalhandler voor Google's UCP live — zonder woord over wie de agent stuurt — Wat maX al zegt: case 120 — "UCP regelt het karretje, niet de mens" — en Worldline stond al als Europese deur op de radar. Nieuw: persbericht Worldline, 14-09-2026: Worldline "becomes one of the first in Europe to launch a payment handler for the Universal Commerce Protocol (UCP)", een "open standard for agentic commerce co-developed by Google and industry partners", dat handelaars "AI-initiated purchases across multiple platforms with a unified setup" laat aanvaarden. Geen handelaar of AI-platform bij naam; identiteit, SCA, mandaat of fraude komen in de tekst niet voor (worldline.com/.../pr-2026_09_14_01). Of het in België al actief is: niet gevonden. 🔌 Integratievorm: REST + webhook aan handelaarskant: UCP-bestelling binnen → backend vraagt een attest van de mens achter de agent (M2) → groen naar Worldline, rood extra controle → misbruik terug naar D. 🧩 Productmix: V + D (+ C voor zakelijke kopers); rail doet niet mee, de betaling blijft bij Worldline. Richting: VOLG + DEUR. Zo zet je dit in de markt: "Uw handler neemt vanaf nu agent-aankopen aan. Wij zeggen welke mens die agent stuurt, zonder dat uw handelaar een identiteit bewaart."
15-09💸 Verdien-kant · De markt die mensen betaalt voor robotdata krijgt een waardering van $500 miljoen: Mecka AI — en nog altijd geen woord over wie er filmt — Wat maX al zegt: de radar volgt deze verdien-kant sinds eind augustus (Figure Index, DoorDash Tasks op 28-08). Nieuw: TechCrunch (Marina Temkin, 11-09-2026): Mecka AI "is nearing a new round led by Sequoia Capital at a valuation of about $500 million"; "The startup pays people to record themselves performing everyday tasks — like making coffee or fixing cars — using body sensors and smartphones." Series A $60 miljoen (Framework Ventures); begin juni mikte Mecka op $100 miljoen jaaromzet tegen eind 2026. Het artikel noemt geen aantallen bijdragers, tarieven, landen of identiteitscontrole; vestigingsplaats niet vermeld. URGENT: nee — Mecka bouwt geen uniciteitslaag. Waarom het ertoe doet: trainingsdata is maar zoveel waard als het aantal echte, verschillende mensen erachter; dubbele of nep-bijdragers vervuilen de set. 🔌 Integratievorm: OIDC bij aanmelden of batch-CSV van bestaande bijdragers: (1) bijdrager bewijst één keer uniek mens (M1); (2) elke opname draagt het pseudoniem; (3) uniciteitscheck vóór uitbetaling (M2); (4) later uitbetaling via P over de rail (M3). 🧩 Productmix: V + D, later P + O. Richting: DEUR (koper) + VOLG. Zo zet je dit in de markt: "Sequoia waardeert menselijke beweging op een half miljard. Wij garanderen dat het ook verschillende mensen zijn."
15-09⚡ Nieuw toepassingsgebied: één betaald AI-abonnement, een heel team dat het model leegtrekt — NSA, CISA en FBI noemen gedeelde zitjes bij naam — Niet in de catalogus (dichtst bij: 53 betaalde MCP-server, 54 verhuurde GPU). The Hacker News (09-09-2026) over een gezamenlijk bulletin van NSA, CISA en FBI: DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun en Z.AI voerden sinds eind 2024 distillatiecampagnes op Claude, GPT, Gemini en Grok, en besparen via "bulk procurement of the U.S. AI companies' premium subscriptions shared across teams". Google Threat Intelligence zag campagnes van meer dan 100 miljoen prompts met duizenden gestolen inloggegevens en frauduleuze accounts. Advies: verdachte extractie subtiel slechter beantwoorden en activiteit over aanbieders heen correleren. Het bulletin zelf niet gelezen, alleen via The Hacker News. Het gat: een zitje is bedoeld voor één mens, de aanbieder ziet een account. 🔌 Integratievorm: OIDC-knop bij het aanmaken van een zitje + API-sleutel gebonden aan een pseudoniem; x401-mandaat voor agentsleutels. Kleinste demo: de testmotor weigert een tweede sleutel op hetzelfde pseudoniem. 🧩 Productmix: V + C + D + O; M1 per zitje, M2 per sleuteluitgifte. Grens: staatsgesteunde spelers kopen echte identiteiten; itsme dekt alleen BE/NL; correleren over aanbieders heen kan alleen met toestemming. Geen koper met naam en stad — Europese kandidaat (bv. Mistral) niet nagekeken. Zo zet je dit in de markt: "uw limiet per zitje telt accounts; wij laten haar mensen tellen" — hetzelfde patroon als GitHub op 13-09.
15-09⚖️ Case 92 wordt wet-in-wording: Brussel stelt donderdag 17-09 een ‘Kids Act’ voor — ouderaccounts tot 12 jaar, online games inbegrepen — Wat maX al zegt: case 92 — "De leeftijdsapp bewijst dat je achttien bent, niet dat dit kind van jou is". RTÉ/AFP (14-09-2026) over het uitgelekte voorstel: onder 3 geen toegang; 3–12 enkel door ouders beheerde accounts op kindvriendelijke diensten; 13–14 door ouders goedgekeurde introductie-accounts met beperkte contacten en strikte tijdslimieten; vanaf 15 een eigen account. Gedekt: sociale media, videoplatformen, AI-chatbots en online games; platformen moeten leeftijd controleren bij het openen van een account, gamingplatformen vóór een download. Voorstelling donderdag, na de State of the Union van woensdag 16-09 (rte.ie/news/2026/0914/1591453-social-media-ban-eu/). Details kunnen nog wijzigen; hoe de leeftijd gecontroleerd wordt (EU-app, wallet of erkende derde) staat niet in het bericht. Raakt geen bundel G15/G17/G18 (DSA-kant). Richting: VOLG tot donderdag, dan mogelijk DEUR: de ouder-kind-binding is precies wat een leeftijdsapp niet doet. ⚠ Prospect onder de lat: Azerion (Nederland) — eigenaar van Habbo via Sulake volgens Wikipedia (stand januari 2026); vestigingsplaats, minimumleeftijd van Habbo en eigendom niet zelf nagemeten, dus geen dealkaart. Zo zet je dit in de markt: donderdag de tekst lezen; valt de controle bij "erkende derden", dan is het verhaal: "wij bewijzen dat de ouder de ouder is, met itsme, zonder dat het platform een identiteitskaart ziet".
15-09⚖️ CRA · ENISA werkt de FAQ van het meldloket bij: registreer pas als je iets moet melden, geen API, alleen Engels — ENISA-FAQ Single Reporting Platform, "Updated: 12 September 2026": fabrikanten moeten "register and initiate the validation process only when they need to submit a notification"; per fabrikant tot 20 secundaire gemachtigden; een nog niet gevalideerde gemachtigde mag "up to 20 notifications" indienen; "No Application Programming Interface (API) will be provided at the initial release"; "At launch, the platform will be available in English only." Een actief uitgebuit lek dat al vóór 11-09-2026 gekend was, hoeft niet achteraf gemeld (enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions; Help Net Security 14-09). Bundel G17: status ongewijzigd — dit is procedure, geen nieuwe datum of plicht; niet in het statusveld gezet. Wat Franky kan doen (5 minuten, niet urgent): een EU Login-account met tweestapsverificatie klaarzetten, maar zich níet vooraf op het loket registreren. Zo zet je dit in de markt: intern en voor Secure Mail: "melden gebeurt manueel, in het Engels, zonder koppeling" — hou de meldprocedure op één blad.
15-09🧭 Basisinkomen · ‘The Trump dividend’: $5.000 voor elke volwassen Amerikaanse burger beloofd — en niemand zegt hoe je die 245 miljoen mensen telt — PBS NewsHour (10-09-2026): op de Republikeinse Midterm Convention in Dallas zei Trump: "If the Republicans win, you get $5,000. It will be called the Trump dividend." Bedoeld voor "every adult citizen in the United States of America"; kostprijs ongeveer $1,2 biljoen op basis van 245 miljoen volwassen burgers; het Congres moet het goedkeuren, senator Bernie Moreno wil een wetsvoorstel indienen "immediately after the November 3rd election". Hoe ontvangers geïdentificeerd of betaald worden, of hoe fraude voorkomen wordt, staat niet in het artikel (pbs.org/newshour/politics/trump-promised-5000-checks-if-republicans-win-the-midterms-how-would-that-work). Wat maX al zegt: dit is de noordstervraag zelf — een burgerdividend is een telling van mensen voor het een betaling is. Richting: VOLG. Politiek geladen: niets naar buiten, alleen als intern voorbeeld. Zo zet je dit in de markt: niet; wel als zin in een gesprek met een beleidsmaker: "het grootste burgerdividend dat ooit beloofd werd, heeft nog geen antwoord op de eerste vraag: wie telt als één mens?"
15-09🌍 VS · TreasuryDirect laat na 28-10-2026 alleen nog aanmelden via ID.me — de overheid legt de burgeridentiteit bij één private selfie-KYC — TreasuryDirect-FAQ (gelezen 15-09-2026, geen paginadatum): "After October 28, 2026, ID.me will be the only method to log in to your TreasuryDirect account." ID.me verifieert met een identiteitsdocument, een selfie, of een live videogesprek met een "Trusted Referee" (treasurydirect.gov/savings-bonds/help-center/faqs/idme-faq/; ID Tech 14-09). Soort competitie — wie: ID.me, Amerikaanse identiteitsaanbieder voor overheidsdiensten. Waarom het R4M niet nekt: geen EU-eID-wortel, één account per dienst en geen pseudoniem uniciteitsattest; in België en Nederland doet itsme/DigiD dit werk al. Waar het raakt: het model "overheid besteedt de mens-controle uit aan één private partij" is precies waar een verzegeld attest per context het privacyalternatief is. Richting: VOLG. Zo zet je dit in de markt: als contrast: "in de VS moet je voor je staatsobligaties een selfie bij een bedrijf afgeven; wij laten een dienst weten dat je uniek bent zonder dat ze je gezicht zien."
15-09💰 Subsidiebord 15-09: Start it @KBC is dicht, imec.istart wordt morgen urgent (hard, 30-09), en nergens een nieuwe identiteitsoproep — Hermeting 03:2x, aan de bron: Start it @KBC — startit-x.com toont "Applications for Fall 2026 are closed" en "Next application period: Spring 2027" (datum niet gepubliceerd); 🚨 van het bord. Of er ingediend is weet de routine niet. imec.istart — "Autumn 2026 Open call Sept 1 - Sept 30 (midnight)" ongewijzigd; hard; nog 15 dagen, dus urgent vanaf morgen 16-09; tijdzone niet vermeld — reken op 30-09 overdag. Volgens een onderzoeker (niet op de bronpagina gelezen) eist imec minstens twee medeoprichters en een Belgische zetel — Franky nakijken. Via onderzoeker, niet zelf hermeten: NLnet Restack 03-11 12:00 CET (zacht) · EIC stap 1 gebundeld elke eerste dinsdag 17:00 (volgende 06-10, zacht), stap 2 04-11 · Alliance ALL19 early 23-09 (zacht) / 18-11 · YC W2027 02-11 20:00 PT · Base Batches 005 niet aangekondigd · Circle Developer Grants doorlopend · FIT Starterspakket volgende oproep "eind september 2026", wie eerst komt, vereist een bestaande kmo (opent, dus nooit urgent) · Innoviris geen nieuwe oproepen in 2026. Geen nieuwe oproep over identiteit, wallets of agentbetalingen in het EU-portaal of bij VLAIO (VLAIO gaf opnieuw 403). Zo zet je dit in de markt: intern — de enige klok met gevolg is imec op 30-09: beslis deze week.
15-09🩺 De motor om 03:07: 432 groen, 2 overgeslagen, 70 bestanden op v0.45.2 — geen drift, kasboek sluit, nog altijd één mens — npm test op main 0f6aab3, working tree schoon: 70 bestanden, 432 van 434 groen, 2 overgeslagen, 0 rood (10,48 s). VERSION 0.45.2 = package.json = tag v0.45.2 = live /api/public/status v0.45.2. Checks letterlijk: app_live, itsme_eid (sandbox, laatst gemeten 14-09 17:05 UTC), attestations en double_entry_ledger verified; settlement_adapter usdc-base en email_login configured met verified null. attestationsIssued 8 / live 0 / distinctHumans 1. /api/public/reconciliation: vijf invarianten groen, gefund 21,76 = vastgehouden 16,76 + uitbetaald 5 + fees 0. Protocolwacht: x402 ongewijzigd sinds 04c750e (11-09), x401 jongste dde015b (14-09, al gemeld), upto-EVM nulstand 0 treffers op 134 regels. Claims-check: de twaalf "wettig bevel"-zinnen staan er nog, zonder nieuw feit — geen nieuw auditblok. Niet getest: echte itsme-aanmelding, mailprovider, /healthz?deep=1. Zo zet je dit in de markt: intern.
14-09⚙️ PROTOCOLWACHT · x401 maakt de OAuth-stap optioneel — een site kan mensbewijs vragen zonder eigen token-server — Commit dde015b in proof/x401 (PR #43 van Daniel Buchner, Proof), samengevoegd 14-09-2026 16:29 UTC. Aan de bron nagelezen, alleen de +regels: in spec.md staat het payload-veld oauth niet langer als REQUIRED maar als OPTIONAL. Nieuwe regel in de spec zelf: een Verifier die token-uitwisseling aanbiedt MOET oauth meegeven; een Verifier die alleen het bewijs zelf aanvaardt bij de herhaalde aanvraag laat het weg. De enige verplichte kern is nu credential_requirements. REIKWIJDTE: de hele x401-payload, geen voorbeeld of commentaar — het is de ledendefinitie in de spec (spec.md +23/−16, CHANGELOG.md +1/−1). Het versienummer blijft 0.2.0: een 0.2.0-payload kan vanaf nu met én zonder oauth bestaan. De publieke demo van Solidus (auth.solidus.network/v1/x401/demo) stuurt vanavond nog oauth mee. Eerste spec-commit sinds 01-07-2026, gevonden door de avondronde; spoor H keek om 03:00 en zag hem dus niet. RAAKT R4M VANDAAG: nee. src/ in de motor bevat geen x401-code (4 treffers, alle vier commentaar of de itsme-OIDC-route; poort.ts: 'wordt geïmplementeerd zodra het er is'). WAT FRANKY MOET ANTICIPEREN: (1) wie x401 op de poort bouwt, hoeft geen OAuth-token-endpoint te draaien — het bestaande kaartje met sessiecookie kan de hergebruiklaag blijven; (2) een agent die een x401-site aanroept moet een payload zonder oauth aankunnen, dus de demo-agent mag er niet op rekenen. Richting: VOLG (spec beweegt weer) + DEUR (kleinere bouw). Zo zet je dit in de markt: De drempel om een site mensbewijs te laten vragen zakt: x401 zonder eigen token-server past bij een webwinkel of blog zonder IAM-afdeling — precies de Weblock-klant.
14-09✓ AUDIT · Avondronde: de middagdeploy landde tot op de byte, motor zonder versiedrift, 49 bronnen gemeten — 14-09-2026 19:0x · ✓ echt. SITE: marktradar live 956.218 b en cases-db.json 6.062.324 b, allebei tot op de byte gelijk aan public/ op schijf — de deploy van fase BOUWEN (355b11f, 13:15) landde volledig. MOTOR: /api/public/status v0.45.2 = VERSION 0.45.2; sinds 13:16 geen commit op main en geen Fly-deploy (laatste 13-09 12:12 UTC, success); motor-backup 08:54 UTC success. DOORLOOP: 47 items, 0 op goedgekeurd, niets te verwerken. VOORSTEL-TAKKEN: 28 op origin, 6 in main opgenomen, 22 open (gisteren 21 + de tak van vanmiddag). BRONNEN: 49 adressen, 45 keer 200, vier afwijkingen allemaal hermeten en verklaard (x402secure.com 307 naar www · kale t54-hostnaam 404 by design · r4m-max.pages.dev 302 naar Access · startit-x.com 301 van www naar kale vorm). NULSTANDEN: upto-EVM 0 treffers op 134 regels; kernspec x402 v2 38.469 b, tellers gelijk; t54 'Risk layer for the x402 protocol.', laatste push 30-08, 28 sterren, upstream nog x402.org. Enige beweging: x401 (zie het ⏱-blok van vanavond). Zo zet je dit in de markt: intern — geen actie; dit bevestigt dat wat vanmiddag gemeld werd ook live staat.
14-09🚨 Start it @KBC: het sluitingsuur is nu zelf nagemeten — vanavond 23:59, nog ongeveer tien uur — Fase VINDEN las het uur via een onderzoeker en kon het niet zelf hermeten. Om 13:08 vroeg fase BOUWEN de publieke API achter het formulier rechtstreeks (startit.api.acceleratorapp.co/graphql): deadlineAt: 2026-09-14T21:59:00.000Z voor "1-Year program - Start it Fall 2026" = 23:59 Belgische tijd. De programmapagina (startit-x.com) draagt nog "Application deadline: 14.09.2026", "Capacity: 65 selected participants" en "FREE (no strings attached)". Hard: missen = geen najaarsronde. Drie andere regels aan de bron herbevestigd, geen wijziging: imec.istart BELGIUM "Open call Sept 1 - Sept 30 (midnight)" (hard, 16 dagen, urgent vanaf 16-09) · NLnet Restack "November 3rd 2026 12:00 CET" (zacht) · Circle Developer Grants zonder deadline, "Agentic economic activity" nog eerste prioriteit. Zo zet je dit in de markt: gratis, 0% aandelen, twaalf maanden coaching in negen Belgische hubs — vandaag indienen of bewust laten vallen.
14-09◐ AUDIT · v0.45.2 belooft 'een vreemde site krijgt altijd 403' — de proef-claim geeft live nog 200 met een hint — Gemeten 13:1x op r4m-franky.fly.dev: POST /api/proef/claim met Origin https://kwaad.example en een onbestaand attest geeft 200 met "attest niet geldig: onbekende attestatie". Dezelfde aanroep op /api/public/attest/inwissel geeft 403. v0.45.2 zette de Origin-controle eerst op inwissel en mandaat, niet op de claim. Ernst laag: een browser op een vreemde site kan het antwoord niet lezen, en een server zonder Origin krijgt het toch. Het gaat om een belofte die voor twee van de drie routes klopt. Zo zet je dit in de markt: intern — de fix staat klaar op een tak (zie voorstel hieronder).
14-09💡 VOORSTEL · voorstel/2026-09-14-origin-eerst-op-claim — Origin vóór de attestcontrole, op alle drie de routes — Commit a8186c6, 2 bestanden (+14/−1): de Origin-regel in src/routes/proef.ts staat nu vóór de attestcontrole, en een nieuwe test pint het gedrag voor claim, inwissel en mandaat. Test eerst op de oude code: rood ("expected 200 to be 403"). Daarna: typecheck groen · npm test 433 groen / 2 overgeslagen · server op een tijdelijke databank (v0.45.2, healthz ok) · npm run demo volledig door, I1–I5 groen · probe: vreemde Origin 403, zonder Origin ongewijzigd. Repo terug op main, werkboom leeg. Niet getest: live na merge. Zo zet je dit in de markt: intern — mergen en releasen doe jij; het is de kleinste tak van de stapel.
14-09🧪 TEST · Motor op main om 13:08: 432 van 434 groen, geen drift — 70 testbestanden, 0 rood, 2 overgeslagen; typecheck groen. VERSION = tag = live = v0.45.2. Ongewijzigd sinds de meting van 03:00. Commando: cd Rails4Mankind && npx tsc --noEmit && npm test. Zo zet je dit in de markt: intern — de basis onder het voorstel van vandaag.
14-09📄 Het ochtendrapport van maandag 14-09: Legwork laat agents unieke mensen betalen, twee kopers met naam en stad, en Start it sluit vanavond 23:59 — Het rapport over het venster 13-09 08:30 tot 14-09 08:30 staat op de Ochtendrapport-tab (or-20260914). Dertien radar-inbrengen van fase VINDEN plus één doelwit (Stichting FAD), zes kaarten in de beslis-inbox (241–246, waarvan twee met koper: Manchester United en Stichting FAD), vijf blokken op de CN-radar en vijf op de India-radar. Franky bracht de motor tussen 11:04 en 14:12 van v0.42.1 naar v0.45.2 (houderbinding, astra ronde 8, canoniek pad); testsuite om 08:05 hermeten: 432 van 434 groen, geen drift. Pijplijn onveranderd: 56 prospects, 0 gecontacteerd, 0 gereageerd. Claims-check blijft rood op twaalf "wettig bevel"-cases. Zo zet je dit in de markt: niets naar buiten — de dagboekregel die de nacht aan elkaar knoopt. Eerste actie van de dag: Start it @KBC vóór 23:59.
14-09✅ AUDIT · De GDPR-bronketen draait weer na dertien dagen stilstand — maar de URGENT-push komt nog altijd niet op je telefoon — Ketencheck 14-09 08:04 (python3 Site-Fleet/ketencheck.py): vijf keer OK, exit 0. Het GDPR-bronrapport stond gisteren nog op twaalf dagen (laatste meting 01-09) en mat vannacht met de maandagrun opnieuw: 0 dagen. De vraag "wie zet gdpr-monitor.sh weer aan" is daarmee vervallen. Open blijft: de PushNotification van fase VINDEN over Start it @KBC bereikte de telefoon niet (Remote Control inactief), net als gisteren. Een URGENT-vlag die niet aankomt, telt niet. Zo zet je dit in de markt: intern — de machine bewaakt zichzelf van buitenaf; het meldkanaal naar Franky is de enige schakel die nog stuk is.
14-09🚨 Start it @KBC sluit vandaag, maandag 14-09 — niet gisteren: het formulier staat open tot 23:59 Belgische tijd — Negende bronmeting, 14-09 03:10 en 03:5x: startit-x.com/en/accelerate/start-it-kbc draagt onveranderd "Applications for Fall 2026 are open!" en "Application deadline: 14.09.2026". Nieuw feit: het uur. De publieke aanvraag-API achter het formulier gaf deadlineAt: 2026-09-14T21:59:00Z en active: true — dat is 23:59 CEST vandaag. ⚠ Die API-waarde las een onderzoeker van deze run; de routine kon hem niet zelf hermeten, want het formulier laadt alleen met JavaScript. Correctie op gisteren: de radar zei "reken op zondag vóór 23:59". Wie gisteren niet indiende, heeft nog vandaag. Hard: daarna is het de lenteronde van 2027. Zo zet je dit in de markt: gratis, geen aandelen, 65 plaatsen, pitchdagen 14–15 oktober, start 28 oktober — de pitch is live en duurt drie minuten. Formulier: startit.acceleratorapp.co/apply/program/1-year-program-start-it-fall-2026.
14-09Subsidiebord 14-09: imec.istart nog 16 dagen (hard), NGI Zero Commons definitief dicht, nergens een nieuwe identiteitsoproep — Aan de bron nagelezen om 03:1x. imec.istart BELGIUM "Autumn 2026 Open call Sept 1 - Sept 30 (midnight)" — hard, urgent vanaf 16-09; volgende Belgische ronde "Spring 2027 Open call Jan 1 - Jan 30" · NLnet Restack "Next deadline: November 3rd 2026 12:00 CET (noon)", €5.000–50.000, zacht; AI-projecten alleen boven 1 miljoen gebruikers · NGI Zero Commons Fund: "The thirteenth and final call ... closed on June 1st 2026" · EIC Accelerator stap 1 doorlopend, gebundeld "every first Tuesday of the month" (zacht), stap 2 volgende bundeling 04-11-2026 · YC W2027 02-11 20:00 PT, "we will still consider the application" na de datum (zacht) · Alliance ALL19 early 23-09 (zacht), regular 18-11 · Base Batches: geen opvolger op base.org/batches · Celo Prezenti: de pagina spreekt zichzelf tegen ("Applications open from 12th Aug - 29th Dec 2026" én "We are currently closed for applications"); de Frontier Pool eist Celo-mainnet — past niet. Nieuw geopend in het EU Funding & Tenders-portaal (1.405 oproepen doorzocht): alleen twee ECCC-cyberoproepen van €15–20 miljoen voor consortia, sluiten 14-01-2027 — geen fit. Niet gemeten: VLAIO (403), het Base-blog en de CDP-pagina. Zo zet je dit in de markt: na vanavond is imec.istart de enige harde deur met geld; de eis "a working proof of concept" haal je met de live motor.
14-09⚠ Verdien-kant mét uniciteitslaag, in hackathonvorm: Legwork laat AI-agents World ID-geverifieerde mensen betalen via x402 — github.com/RubenSousaDinis/legwork, repo aangemaakt 04-09-2026, laatste push 13-09, gebouwd voor ETHOnline 2026. Een agent zet een klus ("confirm a shop is open, photograph a poster") in USDC-escrow, een mens met World ID claimt hem, levert bewijs, en de escrow betaalt uit. Uniciteit: Orb-credential van World plus een selfie-check bij het aanmelden én bij het aannemen van een klus. Stand volgens de eigen README: vier contracten op Base Sepolia, de x402-referentiefacilitator, ERC-8004-registers; "a World ID-verified person has been paid 3.00 USDC for a real errand on the street"; 23 werkersprofielen zijn gezaaide testrijen en zo gelabeld; werkers in Leiria (Portugal). Hun eigen vergelijkingstabel noemt CYBERDYNE als "live, Base mainnet" met x402-escrow en 2,5% commissie — niet nagekeken. Soort competitie: exact het R4M-patroon (agent betaalt mens, één mens één werker), op dezelfde keten als onze adapter, met de Orb in plaats van itsme. Waarom het ons niet nekt: geen bedrijf, geen adres, testnet, één echte werker. Waar het raakt: trigger 3 van SIGNALS_ADAPT ("een expliciete verified-unique-human-laag") gaat hiermee voor het eerst af — als prototype, niet als markt; daarom geen push. 🔌 Integratievorm: geen koper; kleinste demo zonder toestemming = dezelfde klus-lus op onze motor, met itsme in plaats van World ID (x402-resource + attest). 🧩 Productmix: V + O + P, de rail doet mee (M1, M3 na PRIO B). Richting: VOLG, en DEUR voor een eigen demo. Zo zet je dit in de markt: "Een hackathonteam bouwde in negen dagen ‘agents betalen unieke mensen’. De vraag is dus niet óf, maar op welke wortel — de onze is de eID die de burger al op zak heeft, geen irisscan."
14-09X Pay live op Base mainnet: een Nederlandse x402-poort die weet hoeveel een agent mag uitgeven, maar niet wie erachter zit — GlobeNewswire 11-09-2026: X-Pay Technologies (Nederland, KVK 42149086) zet "Settlement in USDC on Base mainnet, chain id 8453" live, tegen 1% van het afgerekende volume. Identiteit is een sessiesleutel: "An operator mints a session key, which is the only credential an agent process ever needs to hold", met een plafond per oproep, een rollend budget, een lijst toegelaten bestemmingen en "a threshold above which a human has to approve". Het persbericht citeert x402-volume van "over 169 million payments ... about $600 million annualised as of March 2026" — hun cijfer, niet nagerekend. Vestigingsplaats niet nagemeten. Soort competitie: naastligger — zij doen de betaalpoort, niet de mens. 🔌 Integratievorm: x402-resource met attest-header. Hun goedkeurdrempel is precies de plek voor een R4M-attest "deze goedkeurder is één geverifieerde mens, pseudoniem per operator". Kleinste demo: onze eigen x402-poort op testnet met een goedkeurstap die zo'n attest eist. 🧩 Productmix: C (wie mag boven de drempel tekenen) + V; M2 per goedkeuring; de rail doet niet mee, zij settelen. Richting: VOLG, mogelijke DEUR. Zo zet je dit in de markt: "Uw drempel zegt dat een mens moet goedkeuren. Wij bewijzen dat het een mens is — en telkens dezelfde."
14-09Alibaba's Qianwen N1-bril krijgt irisherkenning om te betalen: het toestel kent zijn drager, niet de mens per dienst — PANews 10-09-2026, via Sina Tech: op de Bund Conference in Shanghai stond de "N1" afgedekt in de zone voor AI-betalingen; hij "will introduce iris recognition". Geen prijs, geen datum. Tweede toestel van dezelfde beurs na robothond Tutu (radar 13-09). Soort competitie: naastligger, gesloten Alipay-ecosysteem met biometrie op het toestel. Waar het raakt: het bewijst "de eigenaar draagt de bril", niet "één unieke mens per dienst", en er is geen EU-route. 🔌/🧩 Geen EU-koper; context voor IoT-gesprekken (V + C, M2). Richting: VOLG. Zo zet je dit in de markt: "In China betaalt je bril omdat hij je oog kent. Wij binden het toestel aan de eID die je al hebt, zonder biometrie te bewaren."
14-09Manchester United trok 685 seizoenskaarten in op accountgedrag — en gaf toe dat gedeelde logins gewone fans raakten — GOAL via Yahoo Sports, 11-09-2026: 685 accounts geband, 464 supporters kregen een sanctie of waarschuwing, 468 dossiers zonder gevolg na uitleg, 499 bans bleven overeind na beroep. De club "underestimated how many fans share account details" en viseerde "organised ticketing networks, which were controlling, selling and distributing tickets from hundreds of accounts". Fans protesteerden bij de derby van 13-09 (PA). Bedrijf: Manchester United, Old Trafford, Manchester (VK). Pijn: een account is geen mens — de controle trof netwerken én gezinnen. 🔌 Integratievorm (OIDC-knop bij login en bij het doorgeven van een ticket): (1) draait al — itsme-binding en attestatie-endpoint; (2) Franky bouwt de doorgeefkaart "dit account mag mijn stoel gebruiken" op C, enkele dagen; (3) de club zet één knop in haar ticketflow; (4) OIDC + SD-JWT; (5) kleinste demo: een testticketshop die per mens telt in plaats van per account. 🧩 Productmix: V + D (weigerlijst per mens) + C; M1 bij binding, M2 per doorgifte; de rail doet niet mee; trede 2. ⚠ Grens: Britse fans hebben geen itsme — voor R4M vandaag een verhaal, geen verkoop. Welke Belgische of Nederlandse club hetzelfde probleem publiek maakte, is niet nagekeken. Zo zet je dit in de markt: "Manchester United telde accounts en raakte gezinnen. Tel mensen: het netwerk met honderd accounts valt op, en de broer die jouw stoel gebruikt mag gewoon binnen."
14-09🎯 Stichting FAD (Leidschendam): de zwarte lijst van winkelfraudeurs herkent iemand aan vijf letters en een geboortedatum — Distrifood 05-09-2026: het Waarschuwingsregister "voorkomt jaarlijks in honderden gevallen dat werknemers bij een andere retailer weer aan de slag gaan"; bestuurslid Ben Swagerman: "Het is jammer dat Albert Heijn, Lidl en Plus niet meedoen." Hoe het werkt, letterlijk op stichtingfad.nl/waarschuwingsregister: men "voert een code in die gelijk is aan de eerste vijf letters van de achternaam en de geboortedatum"; bij een treffer "moet worden geverifieerd of de sollicitant inderdaad de geregistreerde fraudeur" is. Vergunning van de Autoriteit Persoonsgegevens. Pijn (afleiding uit die werkwijze): naamgenoten met dezelfde geboortedatum geven een valse treffer, en het winkelbedrijf moet zelf nagaan wie er voor hem zit. 🔌 Integratievorm (REST-API bij aanwerving + batch-CSV voor bestaande registraties): (1) draait al — gezouten hash per context en het attestatie-endpoint; (2) Franky bouwt de weigerlijst-bevraging op de persoonsroot, enkele dagen; (3) FAD vervangt de code-invoer door één API-oproep met toestemming van de sollicitant; (4) REST + SD-JWT; (5) kleinste demo: twee testsollicitanten met dezelfde code die het register verwart en R4M uit elkaar houdt. 🧩 Productmix: D + V; M1 per nieuwe sollicitant, M2 per controle; de rail doet niet mee; trede 2. ⚠ Open: Nederlanders gebruiken DigiD — of itsme volstaat is niet nagegaan, en het AP-protocol bepaalt wat mag. Wie: het bestuur via info@stichtingfad.nl. Openingszin: "Uw register herkent een ex-medewerker aan vijf letters van zijn achternaam en een geboortedatum. Wij geven een verzegeld bewijs dat het om dezelfde mens gaat — zonder dat er een naam in het register hoeft." Toegevoegd aan 🎯 Doelwitten; Franky beslist of dit een prospect wordt. Zo zet je dit in de markt: een register dat door de privacytoezichthouder vergund is en toch op een naamcode draait, is het schoolvoorbeeld van D.
14-09Nieuw toepassingsgebied: gratis overheidsafspraken worden door bots opgekocht en doorverkocht — Spanje, identiteitskaart — AdslZone 10-09-2026 (Iván Dávila): Facebookgroepen verkopen afspraken om de DNI, het paspoort of verblijfspapieren te vernieuwen; sommige groepen tellen meer dan 14.000 leden. De Policía Nacional rolde in november 2024 een netwerk op met 21 aanhoudingen dat met bots afspraken blokkeerde en voor €15–30 doorverkocht. Staat niet in de catalogus (dichtst: case 180 bot-vrije wachtrij, case 64 examenstoel). Pijn: de afspraak hangt aan een formulier, niet aan de mens die aan het loket staat. 🔌 Integratievorm: OIDC-knop bij het boeken + QR aan het loket. 🧩 Productmix: V + G (+ D voor doorverkopers); M1 per burger, M2 per boeking; de rail doet niet mee. ⚠ Geen koper: Spanje heeft een eigen eID en de overheid moet zelf klant zijn. Of Belgische gemeenten of het rijexamen hetzelfde probleem hebben, is niet nagekeken — dat is de volgende vraag. Zo zet je dit in de markt: "Een afspraak op naam is geen afspraak op de mens. Bind hem aan wie echt aan het loket komt, en doorverkopen heeft geen zin meer."
14-09Australië verdubbelt de boete op de sociale-mediaminimumleeftijd naar A$99 miljoen — ruim de helft van de kinderen moest nooit hun leeftijd bewijzen — Biometric Update 11-09-2026: de Online Safety Amendment (Strengthening Enforcement for the Social Media Minimum Age) Bill 2026 is aangenomen; maximale civiele boete A$99 miljoen, ruimere onderzoeksbevoegdheden voor de eSafety Commissioner. In het artikel: "More than half of children say their account remained active because they were not asked to prove their age." maX kende de Australische regel al; nieuw zijn de boete en het cijfer. Geen EU-koper, geen itsme in Australië. Richting: VOLG — naast Coimisiún na Meán (radar 13-09): toezichthouders gaan van regel naar handhaving. ⚠ Leeftijd alleen verkoopt itsme Qualify zelf al (radar 13-09); ons stuk blijft uniciteit per platform en de weigerlijst per mens. Zo zet je dit in de markt: "Waar leeftijd een vraag bleef, bleef de helft van de kinderen binnen. Een geband account komt terug; een gebande mens niet."
14-09122 basisinkomen-proeven in de VS, $481 miljoen aan 40.921 mensen — en het grootste overzicht zegt geen woord over wie er uitbetaald werd — AEI, 11-09-2026 (Kevin Corinth en Hannah Mayhew): pilots 2017–2025 in 33 staten plus DC. In de 30 gerandomiseerde studies steeg de werkgelegenheid gemiddeld met 0,8 procentpunt; in de vier grootste daalde ze met 3,2 procentpunt. "Among the 26 pilots for which we can determine attrition rates, the mean is 37 percent." Fraude, dubbele inschrijving of identiteitscontrole van ontvangers komen in het rapport niet voor. Noordster, geen koper. Nieuwe filantropische of bedrijfsgefinancierde programma's in het venster: niets gevonden. Richting: VOLG (trigger 6). Zo zet je dit in de markt: "Iedereen meet wat het geld doet. Niemand meet of het bij de juiste mens landde — en dat is precies wat een rail die mensen telt publiek natelbaar maakt."
14-09Secure Mail · BigBear 2.0 schakelt FIDO2 uit in de browser en kaapte Microsoft 365-logins bij 258 organisaties — BleepingComputer 07-09-2026, onderzoek CloudSEK: 5.137 buitgemaakte records, waaronder 4.148 sessiecookies en 474 volledige MFA-omzeilingen, slachtoffers in 40+ landen. Werkwijze: een Evilginx2-achtige man-in-the-middle met "custom JavaScript that interferes with FIDO2/WebAuthn authentication", zodat het slachtoffer terugvalt op een zwakkere methode. Toets aan de positionering (attestatie-gebaseerde afzender-verificatie op de rail, x401-compatibel): de aanval zit op de login, niet op de afzender — Secure Mail lost dit niet op, en dat hoort zo gezegd. Wat het wel zegt: met een gestolen sessie mailt de aanvaller vandaag gewoon namens het slachtoffer; een afzenderattest dat per bericht de mens zelf vraagt, zou dat niet toelaten. Verder leeg deze week: geen nieuwe regels van Gmail, Microsoft of Yahoo, geen BIMI/VMC-, eDelivery- of EUDI-mailnieuws. Zo zet je dit in de markt: "Phishing steelt vandaag de sessie, niet het wachtwoord. Wie een sessie steelt, is daarmee nog geen verzegelde afzender."
14-09🩺 De motor om 03:07: 432 groen, 2 overgeslagen, 70 bestanden op v0.45.2 — geen drift, 8 attesten, nog altijd één mens — Gemeten op main (fd39dc4), werkboom schoon. VERSION 0.45.2 = package.json 0.45.2 = tag v0.45.2 = live v0.45.2. Checks: app_live ✓, itsme_eid ✓ (sandbox), attestations ✓ realIssued 8, double_entry_ledger ✓; settlement_adapter usdc-base en email_login configured met verified null. attestationsIssued: 8 uitgegeven, 0 live, 1 onderscheiden mens (7 op 13-09 03:00). Kasboek: vijf invarianten groen, gefund 21,76 = vastgehouden 16,76 + uitbetaald 5 + fees 0. Protocollen stil: x402 04c750e (11-09), x401 f739b0e (01-07, 75 dagen), upto-EVM 134 regels en 0 treffers. Niet gemeten: echte itsme-aanmelding, mailprovider, /healthz?deep=1. Commando: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test
14-09⚠ AUDIT · Claims-check: "alleen onder wettig bevel" staat in twaalf cases zonder stand-van-vandaag — gisteren werden er acht gemeld — Case 29, 13, 48, 40, 42, 55, 62, 95, 107 (r4m) · 70 (pitch) · 92, 108 (vandaag), plus de tekst van or-20260912 en or-20260913. De vier extra (55, 62, 70, 107) zijn geen nieuwe tekst: de telling van gisteren was onvolledig. Volgens de correctie van 12-09 is de sleutelbewaring niet gebouwd; zonder die nuance belooft de zin meer dan de bouw draagt. Niet zelf herschreven — dat is jouw beslissing. "anoniem" en "weggegooid": alle treffers beschrijven derden. Engine-broncode: nul treffers. Geen streepje in strategie.matrix, geen AI Act-claim. Wat je ermee doet: één ronde zoek-en-vervang met de stand-van-vandaag-regel, twaalf plekken, een kwartier.
13-09✅ AUDIT · Het padgat van 13:1x is in main al dicht — het voorstel van vanmiddag is ingehaald door v0.45.0 — Om 13:1x viel /blog/../admin binnen een bon voor /blog (vonnis ◐ deels). Om 13:59 kwam v0.45.0 (4bdd57e) met canoniekPad: één keer decoderen, . en .. oplossen, en elke gecodeerde slash, overgebleven % of backslash weigeren. De site-middleware draagt dezelfde functie.

Gemeten om 19:0x. De acht ontsnappingspaden uit de test van het voorstel door de functie van main gehaald: 8 van 8 geweigerd, ook %252e%252e. De twee gewone paden uit dezelfde test komen door. Volledige suite op v0.45.2: 432 groen, 2 overgeslagen.

Verschil. Het voorstel weigert elk punt-segment; main lost het op (/blog/../blog/x wordt /blog/x en mag door). Geen lek, wel een andere keuze.

Wat je ermee doet: de tak voorstel/2026-09-13-padgrenzen-punt-segmenten afwijzen — hij is overbodig. Niet gemeten: de HTTP-antwoorden van de draaiende motor op deze paden, en of turbeau2rock-2026 al de middleware van v0.45.0 draait.
13-09✅ AUDIT · Vijf motorreleases in 44 minuten, vijf keer groen uitgerold — en de docs-commit van de routine rolde niets uit — v0.44.0 (13:28) tot v0.45.2 (14:12): vijf runs Deploy naar Fly.io, vijf keer success. VERSION, package.json, de laatste tag en /api/public/status staan alle vier op v0.45.2: geen versiedrift.

De waarschuwing van gisteren (⏳ een commit met alleen documentatie rolt de motor uit): de routinecommit van 13:14 (e9fcf5c) droeg [skip ci], en geen van de laatste twintig runs staat op die sha. Voor vandaag is het gat dicht.

De site tot op de byte gelijk aan de schijf: index 229.155, marktradar 925.257, cases-db.json 5.986.760.

Opletten: v0.45.1 herstelt volgens zijn eigen commitboodschap een 401 die sites kregen na v0.45.0. Hoe lang een live site dat antwoord echt kreeg, is niet gemeten.
13-09🩺 De motor om 19:06: 432 groen, 2 overgeslagen, 70 bestanden op v0.45.2 — Gemeten op main (f2b9b73), werkboom schoon vóór en na. Om 13:0x waren het er 426 op v0.43.0: zes tests kwamen erbij met v0.44 en v0.45. Commando: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test
13-09🔍 Bronronde 13-09: 47 bronnen, 43 levend, geen nieuwe afwijking — de protocollen staan stil — Vier afwijkingen, alle vier bekend of bedoeld: x402secure.com 307 naar www., kale t54-hostnaam 404 (/health 200), r4m-max.pages.dev 302 naar Access, en een invulpatroon commits/<sha> dat geen bron is. Nulstanden ongewijzigd: upto-EVM 4.452 b en 0 treffers, spec v2 38.469 b, t54 laatste push 30-08 en 28 sterren. Op x402 kwam sinds 11-09 geen commit binnen. SEO-keten leeft (+3.297 b).

Wat je ermee doet: twee besluiten liggen bij jou. De AI Dividend staat voor de dertiende ronde op exact 2.274 b (vervangende bron of schrappen), en 21 voorstel-takken staan buiten main. Volledige ronde in docs/BRONNEN.md.
13-09🚨 Start it @KBC: om 13:1x nog open — vanavond 23:59 is de veilige grens, daarna is het de lenteronde van 2027 — Achtste bronmeting, fase BOUWEN: startit-x.com/en/accelerate/start-it-kbc draagt onveranderd "Application deadline: 14.09.2026", "Capacity: 65 selected participants" en "FREE (no strings attached)". Het formulier zei vannacht "Please apply before Sep 14"; een uur staat nergens. Het nieuwe feit tegenover 03:00 is alleen de klok: nog ongeveer tien uur. De andere vier nagemeten regels zijn woordelijk ongewijzigd: imec.istart BELGIUM "Open call Sept 1 - Sept 30 (midnight)" (hard, urgent vanaf 16-09) · NLnet Restack "Next deadline: November 3rd 2026 12:00 CET" (zacht) · Circle Developer Grants geen deadline, "Agentic economic activity" nog altijd eerste prioriteit, "first cohort of 2026" · Base Batches 004 gesloten. Zo zet je dit in de markt: gratis, geen aandelen, en de pitch is live — de goedkoopste deur op het bord. Formulier: startit.acceleratorapp.co/apply/program/1-year-program-start-it-fall-2026.
13-09💡 VOORSTEL · Padgrenzen van het mandaat: /blog/../admin telde als /blog — gedicht op een tak — Tak voorstel/2026-09-13-padgrenzen-punt-segmenten, commit 9cd6c47. v0.43.0 (11:04) maakte de padgrenzen afdwingbaar, maar binnenPaden vergelijkt het ruwe pad met startsWith. Eerst een test op de ongewijzigde code: 200 in plaats van 422 — het lek is gemeten. Het voorstel decodeert het pad (tot drie keer), voegt dubbele strepen samen en weigert punt-segmenten, backslash en onleesbare codering; mandaten zonder paden blijven ongewijzigd. Acht ontsnappingen geven nu 422, met en zonder kaartje. tsc groen, 427 groen / 2 overgeslagen, server boot, npm run demo I1–I5 groen. Niet getest: of Cloudflare Pages ..%2F echt als /admin serveert. Zo zet je dit in de markt: niets naar buiten tot het gemerged is — een klant die "alleen /blog" aan zijn agent geeft, moet dat ook krijgen.
13-09◐ AUDIT · De padgrenzen van v0.43.0 heten "afgedwongen", maar de motor vergelijkt het ruwe pad — docs/POORT.md zegt sinds vanochtend dat de poort de paden afdwingt, ook met kaartje. In de motor valt /blog/../admin binnen een bon voor /blog (gemeten, zie het voorstel). Geen theater: gewone paden als /winkel worden wél geweigerd, en de middleware stuurt url.pathname, waarin een letterlijke ../ al opgelost is. De ontsnapping via de echte site vraagt een gecodeerde variant, en dat is niet gemeten. Vonnis: ◐ deels. Zo zet je dit in de markt: tot de merge "padgrenzen" niet als harde garantie verkopen.
13-09✅ AUDIT · Geen versiedrift meer: repo en live motor staan allebei op v0.43.0 — Het ochtendrapport zag live v0.42.1 tegen repo v0.42.0. Gemeten om 13:10: VERSION 0.43.0 = package.json 0.43.0 = /api/public/status v0.43.0 op base-sepolia; GitHub-run "Deploy naar Fly.io" voor v0.43.0 geslaagd (5m19s, 09:04 UTC). De collision-guard liep alle drie de controles: vooraf main en lege werkboom, achteraf tak gepusht met upstream en terug op main. Vonnis: ✓ echt. Zo zet je dit in de markt: wat op de site staat, draait ook.
13-09🩺 De motor om 13:0x: 426 groen, 2 overgeslagen, 70 bestanden op v0.43.0 — Gemeten op main, werkboom schoon: 426 van 428 groen, 2 overgeslagen, 0 rood; npx tsc --noEmit groen. Om 08:06 was dat 424/426 op v0.42.1 — twee tests erbij met v0.43.0. Op de voorstel-tak: 427/429. Commando: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test. Zo zet je dit in de markt: 426 groen op v0.43.0, testnet — zeg dat laatste erbij.
13-09📄 Het ochtendrapport van zondag 13-09: itsme verkoopt zelf het leeftijdsattest, vier kopers met naam en stad, en Start it sluit vandaag — Het rapport over het venster 12-09 08:30 tot 13-09 08:30 staat op de Ochtendrapport-tab (or-20260913). Zestien radar-inbrengen van fase VINDEN, twintig nieuwe kaarten in de beslis-inbox (221–240: zeven van VINDEN, vijf van de CN-radar, acht van de India-radar), CRA-bundel G17 aangevuld met art. 64(10). Franky bracht de motor zelf van v0.36.7 naar v0.42.1 tussen 21:17 en 06:19 (weg 2, Key Box-wizard, websitepoort, tempo-regel, mandaat) en liet astra rondes 3 en 4 op de site los. Pijplijn onveranderd: 56 prospects, 0 gecontacteerd, 0 gereageerd. Ketencheck: het GDPR-bronrapport staat op twaalf dagen — morgen is de maandag waarop hij hoort te draaien. Zo zet je dit in de markt: niets naar buiten — de dagboekregel die de rest van de radar aan elkaar knoopt. Eerste actie van de dag blijft Start it @KBC vóór 23:59.
13-09🩺 De motor na de nacht: 424 groen, 2 overgeslagen, 70 bestanden op v0.42.1 — zestien versies later nog altijd geen drift — Hermeten om 08:06 op tak main, werkboom schoon: 424 van 426 groen, 2 overgeslagen, 0 rood, 9,25 s. Om 03:06 was dat 419/421 op v0.41.0. VERSION 0.42.1 = jongste tag v0.42.1 = /api/public/status v0.42.1. Binnen het venster ging de motor van v0.36.7 naar v0.42.1; alle Fly-uitrols van de nacht geslaagd (GitHub Actions, laatste run 04:19 UTC). Checks ongewijzigd: 4 van 6 verified (app_live, itsme_eid sandbox, attestations, double_entry_ledger); realIssued 7, 0 live, 1 onderscheiden mens. Niet getest: een echte itsme-aanmelding, de mailprovider, /healthz?deep=1. Commando: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test. Zo zet je dit in de markt: voor de Start it-aanvraag vandaag is dit het getal: 424 groen op v0.42.1, testnet — zeg dat laatste erbij.
13-09⏱ AUDIT · De "alleen onder wettig bevel"-belofte staat in twaalf cases, niet in acht — Fase VINDEN meldde vannacht acht cases (29, 13, 48, 40, 42, 92, 108, 95) die een verzegeld bewijs beloven dat "alleen onder wettig bevel" opengaat, zonder stand-van-vandaag-regel. Een bredere zoekopdracht om 08:07 vindt er vier meer die hetzelfde in andere woorden zeggen: case 55 en 62 ("gaat alleen open onder wettig bevel", veld r4m), case 107 (Lawful Access Module, veld r4m) en case 70 ("revealbaar onder wettig bevel", veld pitch). Astra ronde 4 (05:55) zette twaalf andere restzinnen recht, deze niet. De routine herschrijft geen copy. Vonnis: ⏱ opletten. Zo zet je dit in de markt: dit is dezelfde belofte als de 2-van-3-sleutelbewaring die je op 12-09 zelf van de site haalde — een klant die case 70 leest, koopt iets wat de motor vandaag niet heeft.
13-09⚠️ AUDIT · Vijfde keer: de docs-commit van fase VINDEN rolde vannacht om 03:43 de motor uit — Gisteravond stond het vonnis op vier keer in zes dagen. Vannacht kwam de vijfde: commit 2999b6b (alleen dagrapport, SIGNALS_ADAPT en ledger) startte GitHub-run 34731263417 "Deploy naar Fly.io", geslaagd in 2m02s. .github/workflows/deploy.yml luistert op elke push naar main en kent geen paths-ignore. De routine-opdracht spreekt zichzelf tegen: poort 10 zegt "nooit naar main van de engine pushen", stap 7.4 zegt het dagrapport in die repo committen en pushen. Er brak niets — de uitrol zette dezelfde code opnieuw live — maar elke nacht rolt de routine de live motor uit zonder dat er code veranderde. Vonnis: ⏱ opletten, niet gerepareerd. Zo zet je dit in de markt: niets naar buiten. Keuze voor Franky: paths-ignore op ops/** en docs/** in deploy.yml, of het dagrapport uit de engine-repo halen.
13-09📈 SEO-vloot: channel-zero.be verspringt op desktop — CLS van 0,003 naar 0,419 — Gemeten vandaag op de vloot-API van CCC V3: negen van twintig domeinen, nul onbereikbaar. De enige echte beweging: channel-zero.be desktop −18 naar 73, met een layout-shift van 0,003 naar 0,419 — ruim boven de Google-grens van 0,25, dus iets op de pagina verspringt bij het laden. Mobiel bleef op 71; GSC-klikken lopen door naar 129. Ruis, geen actie: boombedrijfbisschop.be mobiel −22 naar 75, exact de +22 van gisteren terug. turbeau2rock.com mobiel −9 naar 72. bks-solutions.pages.dev herstelt deels: +4 naar 73, LCP van 8,0 naar 5,6 s. qmtex.net en gevelsteenbedrijf-v6 kregen vandaag geen mobiele waarde. Zo zet je dit in de markt: geen verkooppunt, wel een klantsite die rankt (positie 8) — een verspringende pagina kost daar klikken. Kijk naar wat er na de eerste paint inschuift (lettertype, banner of afbeelding zonder afmetingen).
13-09🚨 URGENT · Start it @KBC: het aanvraagformulier zegt "before Sep 14" — reken op vandaag, niet op maandag — Nieuw feit sinds gisteren, gemeten op 13-09-2026 om 03:09 en 03:12. De programmapagina startit-x.com/en/accelerate/start-it-kbc zegt nog "Application deadline: 14.09.2026", maar het formulier zelf (startit.acceleratorapp.co/apply/program/1-year-program-start-it-fall-2026) zegt letterlijk "Please apply before Sep 14, 2026". Het sluitingsuur staat op geen van beide pagina's. Om 03:12 stond de aanvraag open. Harde datum: missen = lenteronde 2027. Gratis, 0% aandelen, 65 plaatsen, geen slides nodig (live pitch van 3 minuten). De rest van de hermeting, allemaal zonder vlag: imec.istart herbevestigd op 30-09 middernacht (hard, 17 dagen). NLnet heropend op 03-09 als Restack: €5.000–50.000, volgende indiening 03-11-2026 12:00 CET, daarna elke 3de van een oneven maand (zacht) — maar alleen voor open source, en alle R4M-repos zijn privé. VLAIO Innovatieve Starterssteun: volgende pitchdagen 5, 6 en 8 oktober (doorlopend). EIC stap 1 ongewijzigd, bundeling 06-10 (zacht). YC Winter 2027: op tijd vóór 02-11 20:00 PT (zacht). Alliance ALL19: early 23-09, regular 18-11 (zacht). Correctie op het bord: base.org/batches toont nu "Sep 10 Applications Closed", niet meer 09-09. Bronnen: startit-x.com, imecistart.com/en/apply, nlnet.nl/news/2026/20260903-call.html, base.org/batches, ycombinator.com/apply, alliance.xyz/apply. Zo zet je dit in de markt: Start it indienen met wat er al staat: de verkoopkit-pitch en 419 groen op v0.41.0 (testnet, zeg dat erbij). Voor NLnet eerst één beslissing: welk stuk mag open source worden, bijvoorbeeld een open bibliotheek die R4M-attesten verifieert?
13-09🔎 Onze eigen eID-leverancier verkoopt al een privacy-attest: itsme Qualify bewijst leeftijd, woonplaats en "humanity" met zero-knowledge — De R4M-bril gaf nul treffers op "Qualify" in v2, v1 en de kloon — dit stond nergens. Op itsme-id.com/business/platform/qualification (gelezen 13-09-2026) staat letterlijk: "Attribute-based verification: age, residency, humanity", "Built on zero-knowledge proof principles", en "No eligibility results or personal data are stored after verification". Geen lanceerdatum op de pagina. Soort competitie: naastligger met gewicht — itsme is de wortel waarop R4M zelf draait. Waarom het ons niet nekt: wie niets bewaart, kan per definitie niet zeggen of déze mens al eerder bij déze dienst langskwam; "18+" en "echte mens" zijn geen "één keer per mens". Dat is een afleiding uit hun eigen zin, geen uitspraak van itsme. Waar het raakt: elke R4M-pitch die alleen leeftijd of mens-zijn verkoopt (DSA-leeftijd, 18+-poorten) botst hier frontaal op, en itsme wint die. Richting: VERMIJD de leeftijdspitch als hoofdzaak, DEUR op uniciteit per dienst, weigerlijst per mens en settlement. Zo zet je dit in de markt: Zeg het zelf voor een klant het zegt: "itsme Qualify vertelt u dat iemand 18 is. Wij vertellen u dat het dezelfde mens is die u vorige week bande — en bouwen daarvoor op itsme." Vraag itsme/Signicat in het tarievengesprek of Qualify via Signicat beschikbaar is en wat het kost.
13-09🎰 Cruks deed zijn werk, het geleende paspoort niet: PowNed kwam met de ID van collega's drie keer op vijf binnen, ook bij Holland Casino — Een PowNed-verslaggever liet zich uitsluiten in Cruks en probeerde tien casino's en speelhallen. Met zijn eigen ID: 0 op 5 binnen. Met de ID van een collega: 3 op 5 — Casino Be One Rotterdam, Jack's Casino Utrecht en Holland Casino Eindhoven, waar het personeel het verschil met de foto opmerkte en hem toch binnenliet (CasinoNieuws, 02-09-2026, casinonieuws.nl/landgebonden/powned-test-cruks-werkt-maar-controle-identiteitsbewijs-schiet-tekort/). JA21 stelde Kamervragen (2026D40472, 02-09); de Kansspelautoriteit reageerde op 03-09 dat toegangscontrole "mensenwerk" is en kondigde stappen aan (kansspelautoriteit.nl/reactie-kansspelautoriteit-op-pownews). Kopers: Holland Casino (Hoofddorp), JVH gaming & entertainment / Jack's Casino ('s-Hertogenbosch). 🔌 Integratievorm: QR aan de deurkiosk + API-sleutel op het toegangssysteem. (1) Draait al: itsme-verificatie, attest-oproep, itsme in Nederland sinds 01-06-2026. (2) Franky bouwt een deurflow: bezoeker scant QR, bevestigt met eigen itsme, kiosk krijgt "bewezen mens, 18+, pseudoniem per casino" terug — schatting 5–8 dagen, niet gemeten. (3) Klant: Cruks-bevraging blijft verplicht en ongewijzigd; kiosk toont groen of rood. (4) OIDC via itsme, attest als SD-JWT. (5) Kleinste demo: eigen tablet-kiosk met gesimuleerde ID-scan naast een sandbox-attest. 🧩 Productmix: V (M1 één keer per bezoeker) + C (M2 per bezoek); rail doet niet mee. Groeipad: proef Eindhoven → 13 vestigingen → online. Keuzevraag voor Franky: mag de kiosk een controlewaarde op naam en geboortedatum krijgen om naast de ID te leggen? Zonder die match zegt R4M alleen "echte mens", niet "de persoon van dít paspoort". Eerlijke grens: een geleende telefoon met pincode komt er nog door. Zo zet je dit in de markt: Openingszin voor Compliance / Verantwoord Spelen bij Holland Casino: "PowNed kwam met een geleend paspoort drie keer op vijf binnen, en Cruks deed daarbij precies wat het moest doen. Het gat zit tussen het document en de mens — en die mens heeft zijn itsme al op zak."
13-09💶 finperks keert merkgeld uit per rekening, niet per mens — en brengt het via Saldo Bank naar Finland — Op 11-09-2026 kondigden finperks GmbH (Berlijn) en Saldo Bank aan dat door merken betaalde cashback en beloningen in de bankomgeving komen, eerst in Finland; genoemde merken Apple, Wolt, Zalando, Adidas, PlayStation, en toegang tot meer dan 1.000 merken (fintech.global, fintech.global/2026/09/11/saldo-bank-teams-up-with-finperks-on-cashback-push/; co-CEO Sebastian Seifert, Saldo-CPO Tuomas Nenonen). finperks noemt op de eigen site ook "sign-up bonuses and referral rewards" als toepassing. Het gat: een welkomst- of doorverwijsbonus per account betaalt drie keer aan wie drie accounts heeft. Eerlijk: bij een bankklant is identiteit al gecontroleerd, daar voegt R4M weinig toe; de wig zit bij hun niet-bankklanten (apps, HR-platformen). Hoe finperks bonusmisbruik vandaag afremt: niet gevonden. 🔌 Integratievorm: REST-API + webhook. (1) Draait al: attest-endpoint, itsme-sandbox, de cashbackketen die Franky op 12-09 zelf doorliep. (2) Franky bouwt een "bonus-claim-check" met een sleutel per campagne en een webhook bij botsing, 3–5 dagen (schatting). (3) Klant doet één call vóór de bonus vertrekt. (4) Pseudoniem attest per campagne, niet volgbaar over campagnes. (5) Demo zonder toestemming: nagebouwde "€10 tegoed"-flow op de motor waar de tweede claim rood wordt. 🧩 Productmix: V + D (weigerlijst op de mens) + O (bon bij uitgifte); geldvorm cashback/bonus; NU M1 + M2, M3 (uitbetaling over de rail) pas na PRIO B. Keuzevraag voor Franky: finperks zelf (één contract, veel klanten) of één klant van hen als proef? Zo zet je dit in de markt: Openingszin voor Sebastian Seifert: "Jullie klanten keren welkomst- en doorverwijsbonussen per account uit. Wij laten ze dat per bewezen mens doen, met één API-call en zonder dat jullie ooit een naam zien."
13-09🎯 Eclipse Foundation (Brussel): 77 valse extensies kwamen van gewone nieuwe accounts, en hun nieuwe controle kijkt naar namen, niet naar mensen — Op Open VSX, de extensiemarkt die de Eclipse Foundation AISBL (Rond Point Schuman 11, 1040 Brussel) beheert, verschenen van 26-07 tot 01-08-2026 77 "evil twin"-extensies via "unrelated" uitgeversaccounts; verwijderd op 03-08, ontdekt door Manifold Security (The Hacker News, 05-08-2026, thehackernews.com/2026/08/open-vsx-removes-77-malicious-evil-twin.html). Publiceren vraagt een GitHub-account, een eclipse.org-account en een getekende Publisher Agreement. Eclipse bracht op 10-09-2026 een gratis CRA-toolkit voor kmo's uit (GlobeNewswire) en organiseert op 27-10 Code & Compliance in Brussel. Waarom zij: Belgisch adres, verse schade, CRA-meldplicht sinds 11-09, en een eigen verificatiekader dat op naamgelijkenis let. Wie: Executive Director Mike Milinkovich, of het Open VSX-securityteam; beste route persoonlijk op 27-10. 🔌 Integratievorm: OIDC-knop naast "Log in with Eclipse" + API-check vóór publicatie. (1) Draait al: de motor. (2) Franky bouwt koppeling + attest "unieke mens, niet eerder geband", 5–8 dagen (schatting). (3) Klant: extra stap voor nieuwe namespaces, quarantaine bij twijfel. (4) OIDC, SD-JWT, later EUDI. (5) Demo: lokale Open VSX-installatie (open source) met de R4M-knop. 🧩 Productmix: V (M1 per nieuwe uitgever) + C (M2 per publicatie), rail doet niet mee. Grens: uitgevers zitten wereldwijd; itsme dekt alleen BE/NL. Ondernemingsnummer niet in de KBO nagekeken. Zo zet je dit in de markt: Openingszin: "Uw nieuwe controles vangen namen die op andere namen lijken, maar de 77 extensies van eind juli kwamen van gewone nieuwe accounts. Wij tonen u of achter tien nieuwe uitgevers één mens zit, zonder dat u zijn identiteit bewaart." Franky beslist of dit een prospect wordt.
13-09⚡ Nieuw toepassingsgebied: GitHub begrenst pull requests per account — tien accounts is tien keer de limiet — Niet in de catalogus (dichtst bij: case 79 bug bounty, 84 peer review). GitHub laat maintainers sinds 17-06-2026 het aantal open pull requests beperken voor gebruikers zonder schrijfrechten, en sinds 06-08-2026 op organisatieniveau (github.blog/changelog/2026-08-06-set-pull-request-limits-at-the-organization-level/). De druk erachter is AI-gegenereerde bijdragen: Jazzband stopte op 14-03-2026 (jazzband.co/news/2026/03/14/sunsetting-jazzband), Codeberg stemde in juli een verbod op repositories die vooral uit AI-code bestaan. Het gat: de limiet telt accounts, niet mensen. 🔌 Integratievorm: GitHub App + OIDC-koppelpagina. (1) Draait al: motor, itsme, attest-oproep. (2) Franky bouwt een webhook die bij elke nieuwe PR het label "bewezen mens" zet en de limiet over alle accounts van hetzelfde pseudoniem telt, 4–6 dagen (schatting). (3) Klant installeert de App en zet een regel. (4) GitHub Apps API, OIDC, SD-JWT. (5) Demo op een private DS2036-repo met twee testaccounts — géén PR's bij anderen zolang R4M niet publiek zichtbaar wil zijn. 🧩 Productmix: V (M1) + C (M2 per PR); later bounty-uitbetaling via P (M3). Open vraag: wie betaalt M1 — maintainers hebben geen budget, een foundation of bedrijfsorganisatie wel. Grens: bijdragers wereldwijd, itsme alleen BE/NL. Zo zet je dit in de markt: Dit is het verhaal voor een open-source-foundation met budget (Eclipse hierboven is dezelfde koper): "u begrenst accounts; wij laten u mensen begrenzen."
13-09⚖️ CRA-vraag van gisteren beantwoord: kleine bedrijven ontsnappen aan de boete voor de 24-uursmelding — maar pas dankzij een rectificatie — Het open punt van 12-09 ("V-vraag voor Nele, geen vaststelling") is aan de primaire bron nagelezen. Artikel 64, lid 10, punt a) van Verordening (EU) 2024/2847 stelt micro- en kleine ondernemingen vrij van de administratieve geldboete voor het missen van de termijn van art. 14, lid 2, a) en lid 4, a): de vroegtijdige waarschuwing binnen 24 uur. De oorspronkelijke tekst verwees naar "leden 3 tot en met 9" en ving de meldboete (lid 2) dus niet; de rectificatie van 02-07-2025 (PB L 2025/90555, eur-lex.europa.eu CELEX:32024R2847R(02)) maakt er "leden 2 tot en met 9" van. Overweging 120 bevestigt het. Blijft beboetbaar: de meldplicht zelf, de 72-uursmelding, het eindrapport, en alles voor middelgrote ondernemingen. Valkuil: de HTML-tekst op EUR-Lex toont nog "leden 3 tot en met 9". Bundel G17 aangevuld; niet nagekeken: de Belgische strafbepalingen en de kmo-definitie (Aanbeveling 2003/361). Zo zet je dit in de markt: Voor Secure Mail en elk product met digitale elementen: een eenmanszaak of kleine BV riskeert geen boete voor een gemiste 24-uurswaarschuwing, wél voor een gemiste 72-uursmelding. Zo formuleren, en Nele laten bevestigen.
13-09⚖️ Leeftijd: Ierland zegt dat een aangevinkt vakje geen bewijs is, en Nederland en Spanje vragen een Europese minimumleeftijd zonder extra gegevens — Op 08-09-2026 opende Coimisiún na Meán (Dublin) zijn eerste formele onderzoek onder de Online Safety Code, tegen X: "Age assurance based solely on self-declaration is not considered effective"; boete tot 10% van de omzet of €20 miljoen (cnam.ie/investigation-commenced-into-x-under-online-safety-code/). Op 11-09-2026 vroegen Nederland en Spanje samen een EU-brede minimumleeftijd voor sociale media, met leeftijdsverificatie die de drempel bevestigt "without processing any additional personal data" (government.nl/latest/news/2026/09/11/dutch-government-advocates-for-eu-wide-minimum-age-for-social-media; Euronews 11-09). Een Commissievoorstel wordt volgens Euronews in de Staat van de Unie verwacht — datum niet zelf aan een primaire bron bevestigd. Richting: VOLG. Geen koper, wel precedent. Let op het item hierboven: precies dit formaat verkoopt itsme Qualify al. Zo zet je dit in de markt: Gebruik het Ierse citaat bij elk platform met een Ierse vestiging, maar verkoop er uniciteit mee, niet leeftijd: de leeftijdsdrempel zelf levert je eigen leverancier al.
13-09🌍 Wallets worden echt: Duitsland start "d-you" op 02-01-2027, het Parlement opent de trilogen over bedrijfswallets, en Amerikaanse banktoezichthouders aanvaarden het digitale rijbewijs — Duitsland: het BMDS (Berlijn) kondigde op 09-09-2026 aan dat de EUDI-wallet "d-you" op 02-01-2027 start, met leeftijdsbewijs, contracten en rekeningopening, en een veertigtal partners (bmds.bund.de/aktuelles/pressemitteilungen/detail/d-you-deutschland-startet-digitale-identitaet-fuer-alle); netzpolitik.org noteert dat de BSI-norm TR-03189 pas eind 2026 gepland is. EU: de ITRE-commissie keurde op 10-09-2026 de European Business Wallets-verordening goed en besliste te onderhandelen met de Raad, die zijn standpunt op 09-06 vastlegde (OEIL 2025/0358(COD); MLex 10-09). VS: OCC, FinCEN, Fed, FDIC en NCUA verduidelijkten op 08-09-2026 dat een digitaal rijbewijs van een staat mag gelden als "government-issued identification" voor de klantidentificatie van banken — alleen overheidsbewijzen, geen private attesten (occ.gov/news-issuances/bulletins/2026/bulletin-2026-44.html). Richting: VOLG. Overal wordt het cryptografische overheidsbewijs de wortel; R4M blijft een laag erbovenop, niet ernaast. Zo zet je dit in de markt: Wallet-agnostisch blijven is geen keuze meer maar de pitch: "vandaag itsme, vanaf januari d-you, morgen elke EUDI-wallet — dezelfde uniciteitslaag." Volg in de trilogen wie bedrijfsattesten mag uitgeven.
13-09📬 Stad Gent maakt zelf de case: eID of itsme voor kotbazen gaf nul fraude op 5.082 koten — het lek zit nu op sociale media — VRT NWS 11-09-2026 (vrt.be/vrtnws/nl/2026/09/11/koten-fraude-kotenzoeker-identificatie-5-000-koten-oproep/): sinds vorig jaar moeten verhuurders op de Gentse Kotenzoeker zich identificeren met eID of itsme; er werden geen nieuwe fraudegevallen geregistreerd voor koten op het platform, het aanbod steeg met een vijfde, en schepen Filip Watteeuw zegt dat de aanpak werkt. Valse advertenties verspreiden zich vooral via sociale media, waar studenten geld vooruit betalen voor koten die niet bestaan. Deur: kabinet schepen Watteeuw, dienst Wonen / Kotatgent. Pakket: de attestatiekant — een "geverifieerde verhuurder"-attest dat ook buiten de stadssite te controleren is, bijvoorbeeld via een QR in een advertentie. Waarom deze week: de stad maakte het resultaat zelf publiek en noemde zelf het resterende lek. Rail doet niet mee; M1 bij de verhuurder, M2 per controle door een student. Zo zet je dit in de markt: Openingszin: "U bewees dat identificatie kotfraude stopt op uw eigen platform. Wij laten een student hetzelfde bewijs controleren onder een advertentie op Instagram, zonder dat de verhuurder zijn naam moet tonen." Franky beslist en contacteert.
13-09⚙️ Protocolwacht: x402 en x401 ongewijzigd — en OpenID4VP legt vast dat een attest zonder houderbinding onbeschermd reist — x402-foundation/x402: jongste commit nog altijd 04c750e (11-09-2026 10:17 UTC, al op de radar); tag pypi-x402@v2.22.0. upto-EVM-nulstand bevestigd (134 regels, 0 treffers, gemeten 13-09 03:08). proof/x401: f739b0e van 01-07-2026. De enige specbeweging in de buurt: OpenID4VP PR #783, gemerged 10-09-2026 15:33 UTC (+8/−6, github.com/openid/OpenID4VP/pull/783): als require_cryptographic_holder_binding op false staat, gaat een W3C-credential zelf in de VP Token, en gelden de nonce/aud- en challenge/domain-eisen alleen als er wél een presentatie terugkomt. Reikwijdte: een verduidelijking, geen nieuwe versie; alleen de W3C-formaten jwt_vc_json en ldp_vc met die vlag op false; SD-JWT VC en mdoc onaangeroerd. De motor draait vandaag geen OpenID4VP-verifier, dus aan de werking verandert niets. Anticiperen: zonder binding zit er geen nonce in het antwoord en is het bewijs opnieuw af te spelen. Richting: VERMIJD — een R4M-verifier moet houderbinding altijd eisen, en dat hoort zo in de verifier-documentatie zodra die er komt. Zo zet je dit in de markt: Wie vraagt waarom een R4M-attest niet "gewoon doorgestuurd" kan worden: omdat de standaard zelf nu zegt dat een attest zonder binding een kopie is die iedereen kan afspelen.
13-09📡 Alipay laat een robothond betalen "binnen de machtiging van de eigenaar" — en zegt niet hoe het die eigenaar kent — IT之家 11-09-2026 (ithome.com/1/001/145.htm): Alipay kondigde "AI Pay · Embodied Intelligence" aan, met de robothond "Tutu" van Gaode Momentum (Amap/Alibaba) die boodschappen doet en betaalt binnen de machtiging van de eigenaar, op Ant's APASS-vertrouwensinfrastructuur en het KYA-kader (identiteit, bedoeling, machtiging, gedrag van de agent). Geen lanceerdatum, geen cijfers, en geen woord over hoe de eigenaar geïdentificeerd wordt. Richting: VOLG. Het eerste concrete toestel onder het Ant/Visa/Mastercard-KYA-akkoord dat al op de radar stond: de machine is benoemd, de mens erachter niet. Geen EU-koper; wel een voorbeeld voor EN 18031-3 (radioapparatuur die geld verwerkt). Zo zet je dit in de markt: In elk IoT-gesprek: "KYA vertelt wie de agent is en wat hij mag. Het vertelt niet dat er één echte mens achter die machtiging staat — dat is de laag die wij leveren."
13-09🤖 Eerste BLIK-aankoop door een AI-agent in Polen: het mandaat zit in de bankapp, de winkel krijgt geen bewijs — Persbericht 09-09-2026 (clear-communication-group-sp-z-o-o.prowly.com/470677-pierwsza-pilotazowa-transakcja-blikiem-zrealizowana-samodzielnie-przez-agenta-ai): BLIK (Polski Standard Płatności), PayU, Juo en Your KAYA voerden een pilottransactie uit waarin een agent zelfstandig een handcrème van 19,99 zł kocht, nadat de gebruiker vooraf toestemming gaf met een 6-cijferige BLIK-code bevestigd in de bankapp. Niets over de identiteit van agent of gebruiker. Bijvangst, beide nieuw voor maX: Paysera publiceerde een open-source "Payments skill" voor Claude Code die alleen conceptbetalingen maakt, elke overschrijving bevestigt de klant met 2FA (paysera.com); Stripe laat Meta's agent Muse winkelen met Link, alleen in de VS, met goedkeuring per aankoop (stripe.com/newsroom, 08-09). Richting: VOLG. Een Europees schema bewijst dat een bankgebonden mandaat vandaag werkt; R4M is voor de betaling niet nodig, wel voor case 61 (het mandaat als bewijsstuk bij betwisting). Geen koper in deze pilot. Zo zet je dit in de markt: Het contrast om te gebruiken: "BLIK weet dat de bankklant ja zei. De winkel weet het niet, en kan het bij een betwisting niet tonen. Een R4M-attest is dat draagbare bewijs."
13-09💸 Twee platformen laten agents mensen betalen zonder te weten wie ze betalen: HireForHumans ("No KYC") en PayHumans (x402) — Buiten het 48-uursvenster, maar nieuw voor maX (nul treffers). HireForHumans (hireforhumans.com, gelezen 13-09-2026): "AI agents hire human workers" voor foto-verificatie, onderzoek, enquêtes, betaling in USDC op Polygon, meermaals "No KYC" en "Just connect a wallet", lancering aangekondigd op 15-06-2026, "190+ Countries", geen volume, geen vestiging. PayHumans (payhumans.co): agents betalen "domain experts" $50–500 per taak via x402 op Solana, Base en Ethereum; "Verified domain experts" zonder uitleg hoe; geen vestiging, geen volume. Soort competitie: verdien-kant, maar geen vlag — geen volume, geen bedrijf met adres, geen uniciteitslaag. Waarom het ons niet nekt: ze betalen een wallet, geen mens; tien wallets cashen tien keer. Waar het raakt: zij claimen de uitbetaling van agent aan mens, precies de kant van onze rail. Trigger 3 van SIGNALS_ADAPT gaat pas af als een van hen een uniciteitslaag toevoegt. Zo zet je dit in de markt: Dit zijn eerder kopers van V/D dan concurrenten: "uw agents betalen wallets; wij garanderen dat er per wallet één mens staat." Niet contacteren zolang er geen bedrijf met adres achter zit.
13-09🧭 Basisinkomen: in Korea landt het binnen twaalf dagen in lokale winkels, en GoodDollar verliest reserves door een fout in een ander protocol — Korea, Boseong: de eerste uitbetaling van het plattelandsbasisinkomen, 12,44 miljard won aan 31.114 inwoners, was voor 50,6% binnen twaalf dagen uitgegeven, via lokale cadeaubonnen en prepaidkaarten (Seoul Economic Daily, 10-09-2026, en.sedaily.com/society/2026/09/10/boseong-basic-income-puts-63-billion-won-into-local-shops); de begroting 2027 breidt het programma uit van 17 naar 35 gemeenten (sedaily 04-09). GoodDollar: een fout in Superfluid op Celo kostte ruim 100.000 dollar uit de reserves; reserves op Celo en XDC staan stil, claimen en identiteitsverificatie draaien weer; meer dan 963.000 claimers (CryptoSlate, 10-09-2026). Richting: VOLG. Korea: een afgebakende, betaalde rail schaalt en het geld blijft lokaal. GoodDollar: een basisinkomen dat op een eigen token en externe contracten rust, erft hun fouten. Zo zet je dit in de markt: Voor de SOVEREIGN_KIT: "het geld komt uit een fonds met naam, niet uit een token; de rail telt mensen en raakt de pot nooit aan." Boseong is het voorbeeld dat een overheid al gelooft.
13-09🩺 De motor: 419 groen, 2 overgeslagen, 69 bestanden op v0.41.0 — geen drift, en vijf nieuwe attesten op nog altijd één mens — Gemeten op 13-09-2026 03:06, read-only op main, werkboom schoon: 419 / 421 groen, 0 rood, 7,67 s — eenentwintig tests meer dan gisteren (398 / 400). Geen versiedrift: VERSION 0.41.0 = package.json 0.41.0 = tag v0.41.0 = live v0.41.0; de motor sprong binnen één etmaal van v0.36.7 naar v0.41.0 (Weblock-poort, tempo-regel, publieke tellers). Checks letterlijk: app_live ✓, itsme_eid ✓ (sandbox), attestations ✓, double_entry_ledger ✓; settlement_adapter usdc-base en email_login configured met verified null; netwerk base-sepolia, stage pilot. realIssued 7 (gisteren 2), live 0, distinctHumans 1. Reconciliation: vijf invarianten groen, gefund 21,76 = vastgehouden 16,76 + uitbetaald 5 (testnet-USD). Claims-check: de acht cases met "alleen onder wettig bevel" zonder stand-van-vandaag-regel staan er nog (29, 13, 48, 40, 42, 92, 95, 108) — ongewijzigd, niet zelf herschreven. Niet getest: echte itsme-aanmelding, mailprovider, /healthz?deep=1. Commando: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test Zo zet je dit in de markt: Vijf nieuwe attesten zijn geen vijf nieuwe mensen: zeg "7 attesten, 1 mens" tot de teller distinctHumans beweegt.
12-09⚠️ Een commit met alleen documentatie rolt de motor uit — vier keer in zes dagen, door de routine zelf — De routine-opdracht zegt "nooit de engine deployen" én zegt bij fase BIJWERKEN "commit docs/BRONNEN.md en push". Die tweede regel voert de eerste uit het raam: .github/workflows/deploy.yml draait op elke push naar main, zonder padfilter. De commit van deze ronde (2913857, alleen twee tekstbestanden) startte om 17:15 UTC een Fly-uitrol; die liep met succes af en de motor staat daarna gezond op v0.36.7 met app_live verified om 17:18 UTC. Van de twaalf recentste uitrollen zijn er vier gestart door een commit die alleen documentatie raakte, alle vier van deze routine (2913857, 6b92de9, 1e4e9ed, 6d7edd4). Geen theater — er gaat niets stuk zolang main niets draagt dat nog niet naar buiten mag. De fix bestaat al: de tak voorstel/2026-09-07-uitrol-negeert-docs-en-ops legt er een padfilter op en ligt sinds 07-09 onbeoordeeld. Zo zet je dit in de markt: niets te verkopen, wel te beslissen — dit is het tweede vonnis van vanavond dat op dezelfde stapel voorstellen uitkomt.
12-09📋 Twintig voorstel-takken wachten, niet zeven — en er gingen er wél vijf door — Vanavond nagemeten met git branch -r --no-merged origin/main | grep -c voorstel: op origin staan 25 voorstel-takken, waarvan er 5 in main zitten en 20 niet. De briefing van vandaag 13:00 sluit af met "Zeven voorstel-takken wachten nu op een oordeel. Er ging er nog nooit één af." Beide helften zijn onjuist. De vijf die wél doorgingen: hermetische-testomgeving (28-08), claim-check-en-retour (06-09), installatiepakket (06-09), codewoord-k1 (07-09), pas-stap-dicht-en-iban-uit (07-09) — alle vijf met een echte voorstel-commit die nu in main staat. Verzwarend: op 09-09 stond het nog correct in dezelfde reeks briefings ("zestien voorstel-takken buiten main, vijf ooit binnengehaald"), dus dit is het verlies van een meting die er al was. Geen theater: de takken bestaan en de tests eronder draaiden; wat faalde is dat een getal uit het hoofd kwam in plaats van uit git. Oudste openstaande tak: 2026-08-28-hash-bewijs-widget, vijftien dagen. Zo zet je dit in de markt: Dit is geen verkoopverhaal maar een uur werk dat twintig afgeronde voorstellen vrijmaakt. Neem de lijst door in blokken van vijf; elke tak die je aanvaardt of wegstuurt is er één die de volgende fase niet opnieuw hoeft te wegen.
12-09✅ De deploys van vandaag landden volledig — drie bestanden byte-voor-byte gelijk aan de schijf — Live opgehaald en naast het bestand op schijf gelegd: index.html 229.155 b, marktradar.html 879.467 b, cases-db.json 5.883.436 b — alle drie tot op de byte gelijk, zonder marge. De radar groeide +34.633 bytes t.o.v. gisteren, cases-db.json +119.880. Daarmee is de deploy-melding van vandaag gecontroleerd in plaats van geloofd. Niet getest: de inhoud is niet vergeleken, alleen de omvang; gelijke omvang met andere inhoud is theoretisch mogelijk en hier niet uitgesloten. Zo zet je dit in de markt: Een site die aantoonbaar gelijk is aan zijn bron is een verkoopargument op zichzelf: als een klant vraagt hoe je weet dat wat je toont ook staat wat je zegt, is dit het antwoord in één regel.
12-09🔎 Bronronde 12-09: 46 bronnen, 52 metingen, 44 keer 200 — en drie nulstanden die stilstaan — De avondronde over docs/BRONNEN.md, met elke afwijking minstens één keer hermeten. Twee afwijkingen, allebei bekend en allebei zonder nieuw feit: www.nbb.be geeft de achtste avond op rij 520 (in dezelfde minuut gaven fsma.be, registers.esma.europa.eu en casptracker.eu alle drie 200, dus de Belgische registerkant blijft leesbaar), en de kale hostnaam x402-proxy.t54.ai geeft 404 volgens eigen ontwerp terwijl /health 200 geeft. De drie nulstanden die écht toe doen staan stil: het x402-bestand voor EVM/upto is byte-voor-byte gelijk (4.452 b, haak dus nog altijd alleen op SVM), de kernspec v2 staat op 38.469 b, en t54 — de dichtstbijzijnde concurrent — draagt drie ongewijzigde getallen: omschrijving letterlijk "Risk layer for the x402 protocol.", laatste push 30-08-2026, 28 sterren, met een /health dat nog steeds naar x402.org/facilitator wijst en dus geen eigen afwikkeling draait. De SEO-vloot-API bewoog wél: 269.129 b, +4.173. Zo zet je dit in de markt: Zolang t54 een risicolaag blijft en geen rail, is de identiteitskant onbezet. Dat is de zin waarmee je bij een x402-partij binnenkomt: zij meten gedrag van software, R4M meet of er één echt mens achter zit.
12-09📜 83 van de 422 bronnen in de eigen dossiers antwoorden niet meer zoals ze opgeschreven staan — Vandaag om 13:12 voor het eerst gemeten, met een nieuw script over docs/USE_CASE_LEDGER.md, docs/100_EURO_MOMENTS.md en docs/BRONNEN.md: 422 bron-URL's, 339 ongewijzigd, 83 verhuisd, weg of onleesbaar. De scherpste zit onder een prijs: de Prolific-pagina die het anker van £6 / $8 per uur draagt is met een 301 hernoemd van "payment principles" naar "payment model", dus het citaat staat onder een titel die niet meer bestaat. Verder geeft vgnexpert.com 404 op elke pagina — één dag nadat dat bedrijf als koper-met-naam in ledger-entry 30 werd opgeschreven — en leidt de mystery-shopper-pagina van Volt District naar de homepage. De oorzaak is structureel: de bestaande bronwacht bewaakt uitsluitend het financieringsbord, en dat bord staat buiten git. Zo zet je dit in de markt: dit is precies het verschil dat R4M verkoopt — wie zegt "wij controleren onze bronnen" bedoelt meestal "wij hebben ze ooit gecontroleerd". Een bedrijf dat zijn eigen rot kan tellen mag het woord bewijs gebruiken.
12-09💡 Voorstel voorstel/2026-09-12-bronwacht-op-de-dossiers — de bronwacht kijkt eindelijk naar wat in git staat — Commit 360c2a7, gepusht met upstream, repo terug op main. Eén nieuw script dat de bron-URL's uit de drie dossiers meet met dezelfde beoordelingsfunctie als de bestaande bordwacht — hergebruikt, niet nagebouwd, zodat de regel "een verhuisde bron is een wijziging, geen succes" op één plek blijft staan. Het volgt geen omleidingen, slaat codeblokken over omdat een commando geen bron is, en schrijft met opzet nooit terug in de dossiers: het meldt, en Franky beslist. Wat de tests aantonen: veertien nieuwe, allemaal op de pure extractie — een afsluitende punt hoort niet bij de URL, een haakje dát erbij hoort blijft staan, een sjabloonadres met beletselteken is geen bron, dubbels tellen één keer, en een omleiding met een JWT van duizend tekens wordt ingekort in plaats van het rapport te verdrinken. Zo zet je dit in de markt: niets — dit is huishouden. Het telt pas mee zodra Franky het goedkeurt.
12-09🩺 412 groen, 2 overgeslagen, 68 bestanden op de voorsteltak — veertien meer dan main, niets nieuw overgeslagen — Gemeten om 13:15 op voorstel/2026-09-12-bronwacht-op-de-dossiers. Main stond vanochtend om 03:06 op 398 groen / 2 overgeslagen / 67 bestanden; de tak voegt er veertien toe en laat de rest onaangeroerd. Daarnaast gemeten: npx tsc --noEmit groen, de motor boot op poort 4031 als v0.36.7 met usdc-base op base-sepolia en /healthz op status ok, en npm run demo loopt end-to-end door met I1 tot en met I5 groen. Herhaalbaar met: cd "/Volumes/8TB MM4/Rails4Mankind" && git checkout voorstel/2026-09-12-bronwacht-op-de-dossiers && npm test. Zo zet je dit in de markt: het testgetal is het enige cijfer dat een koper zelf kan natikken — daarom staat het commando er altijd bij.
12-09💰 Hermeting 13:07 — de twee harde subsidieklokken zijn woordelijk ongewijzigd sinds vanochtend — Geen nieuw feit, en dat is de melding. Start it @KBC en imec.istart staan sinds vannacht al op deze radar; beide zijn om 13:07 en 13:08 opnieuw aan de bron gelezen en dragen exact dezelfde tekst. Wat de hermeting wél toevoegt: vandaag is zaterdag, dus voor Start it @KBC is dit weekend alles wat er nog is — maandag 14-09 is de deadline zelf en geen werkdag ervoor. imec.istart blijft op 30-09 en wordt pas urgent vanaf 16-09; een vlag zetten die daar veertien dagen wappert maakt hem waardeloos tegen de tijd dat hij nodig is. Zo zet je dit in de markt: niets — dit is de eigen agenda, en de enige actie ligt bij Franky.
12-09📄 Het ochtendrapport van zaterdag 12-09: acht vondsten, één harde klok en twee besluiten die Franky zelf nam — Het rapport over het venster 11-09 08:30 tot 12-09 08:30 staat op de Ochtendrapport-tab (or-20260912). De nacht in één zin: één deur die maandag dichtgaat en gratis is, en daaronder een Brugs bedrijf dat 886.000 euro boete betaalde voor een zorgplicht die het per rekening niet kán zien. Acht radar-inbrengen van fase VINDEN, zeven testboek-rijen ververst, bundel G17 aangevuld met het CRA-meldloket, en twee nieuwe auditblokken. Franky werkte zelf tot 02:40 in de kloon: rechtsvorm en naam vastgelegd (BV met de naam R4M) en drie valse claims van de site gehaald, waaronder de 2-van-3-sleutelbewaring die niet bestaat. Zo zet je dit in de markt: niets naar buiten — dit is de dagboekregel die de rest van de radar aan elkaar knoopt.
12-09📈 SEO-vloot: BKS-Solutions verdubbelt zijn laadtijd op mobiel terwijl desktop op 97 blijft staan — Gemeten vandaag op de vloot-API van CCC V3: negen van twintig domeinen gemeten, zes met beweging, nul onbereikbaar. Omhoog: boombedrijfbisschop.be CWV +22 naar 97, channel-zero.be +17 naar 71, turbeau2rock.com +10 naar 81, idgs.eu +4 naar 78 met onsite 100. Omlaag, en dit is de enige die aandacht vraagt: bks-solutions.pages.dev CWV −7 naar 69 met LCP van 5,0 naar 8,0 seconden op mobiel, terwijl de desktopmeting onveranderd op 97 staat. Dat verschil betekent dat het niet de bouw is maar wat er op een trage verbinding als eerste moet laden. Twee auto_fails staan er al langer open: sitemap en gdpr. Zo zet je dit in de markt: geen verkooppunt, maar wel jouw eigen vloot — een pagina die er acht seconden over doet verkoopt niets, en de vergelijking mobiel-tegen-desktop zegt meteen waar je moet kijken.
12-09⏳ Het GDPR-bronrapport staat elf dagen stil — tweede dag gemeld, nog steeds niemand die gdpr-monitor.sh aanzette — De ketencheck van Site-Fleet meldt vanochtend: GDPR-bronrapport laatste meting 01-09-2026, elf dagen stil op een drempel van negen. Het hoort maandags mee te draaien met seo-fleet-watch. Gisteren stond dezelfde regel op tien dagen; er is sindsdien niets bewogen, dus dit is geen nieuw feit maar hetzelfde feit dat een dag ouder werd. De vier andere ketens staan wel goed: SEO-meting vandaag, Artes GDPR-check vijf dagen, Site-Fleet commit vandaag, klantrapporten vijf dagen. Geen backup-alarm in de laatste 24 uur. Zo zet je dit in de markt: niets naar buiten, maar het is precies het patroon dat twee keer eerder maanden duurde — de SEO-keten viel stil op 09-07 en dat bleef zeven weken onopgemerkt, de Artes-monitor op 01-06 en dat duurde drie maanden. Een keten die stilligt kan niet melden dat ze stilligt.
12-09📁 Zes voorstel-takken wachten op een oordeel, en er gaat er nooit één af — Nageteld op origin vanochtend: voorstel/2026-09-07-uitrol-negeert-docs-en-ops, 08-09-reikwijdte-pin, 09-09-testklok-poort, 10-09-kaartbodem-bewijsbaar, 10-09-kaartbodem-bewijsbaar-v2 en 11-09-bord-ontbreekt-eerlijk. Alle zes gepusht met upstream, dus nergens werk in gevaar; geen enkele gemerged. De repo staat schoon op main en de collision-guard doet zijn werk. Het probleem is niet de guard maar de stapel: elke middag komt er één voorstel bij en er verdwijnt er nooit één. Zo zet je dit in de markt: niets naar buiten. Wel een bouwsignaal: hoe hoger die stapel, hoe groter de kans dat de volgende middag voortbouwt op een aanname die jij nooit goedkeurde.
12-09🌎 Vijftien kaarten op de landenradars vannacht: de Chinese staat schreef in mei al "conforme betaling" op, en India haalde UAP de avond vóór de lancering van tafel — Buiten de markt-radar landden vannacht vijftien kaarten op twee eigen tabs: acht op cn-radar om 06:28 en zeven op india-radar om 06:59. De twee die je moet kennen. Eerst China: het implementatieadvies van CAC, NDRC en MIIT van 08-05-2026 schrijft een agent-registratieplatform voor met digitaal identiteitsbeheer en vermogensverklaring, en noemt "identiteitskenmerk, vertrouwd koppelen en conforme betaling" als basistechnieken — de brontekst zelf gelezen. Dat is onze architectuur, door een staat opgeschreven. De groepsnorm van 27-08-2026 zet daar dubbele machtiging bovenop en verbiedt schermlezen bij financiële apps zonder toestemming van de instelling. Dan India: NPCI haalde het Unified Agentic Protocol op de avond van 10-09 van tafel, terwijl de lancering op 11-09 stond, in afwachting van RBI-goedkeuring; de bezwaren gaan over gebruikersbescherming, aansprakelijkheid en bestuursnormen. Singapore had met MAS SAFR op 03-07-2026 al gepubliceerd wat India nog onderzoekt. Zo zet je dit in de markt: dit is het antwoord op de vraag "waarom zou een overheid dit willen". Drie rechtsgebieden schrijven nu onafhankelijk van elkaar op dat een agent een identiteit en een machtigingsspoor nodig heeft. Gebruik China als bewijs dat het geen Europese fantasie is, en India als bewijs dat een land het tégenhoudt zolang dat spoor er niet is.
12-09🚨 URGENT · Start it @KBC sluit over twee dagen, en de aanvraag staat vanochtend nog open — Aan de bron gemeten op 12-09-2026 om 03:2x op startit-x.com/en/accelerate/start-it-kbc: de Fall 2026-ronde staat op "applications are currently open" met indieningsdatum 14 september 2026. Dat is een harde datum — mis je hem, dan is het de lenteronde van 2027. Nieuwe feiten sinds de controle van 07-09: pitchdagen 14 en 15 oktober, programmastart 28 oktober, en 65 plaatsen op ongeveer 150 die pitchen. Het programma is twaalf maanden, gratis, zonder aandelen en zonder voorwaarden, met negen Belgische hubs. Voor R4M is dat de goedkoopste deur die er vandaag openstaat: geen verwatering, wel toegang tot een net van investeerders en corporates op het moment dat de BV er komt. Zo zet je dit in de markt: dit is de enige regel van vannacht met een klok die echt afloopt. Twee dagen is genoeg voor een aanvraag als je de bestaande stukken hergebruikt — de pitch van verkoopkit, de teststand van de motor (398 groen op v0.36.7) en het verdienmodel staan al klaar. Concurrentie is er: 150 pitchen, 65 halen het. Het onderscheidende punt is dat R4M draaiende code heeft en geen slide.
12-09💰 imec.istart bevestigd op 30-09, en Nederland en Spanje openen daarna nog een tweede deur — Aan de bron gemeten op 12-09-2026 op imecistart.com/apply. België (Autumn 2026) staat open tot 30 september middernacht — harde datum, maar achttien dagen weg, dus geen URGENT-vlag; die komt vanaf 16-09. Duitsland loopt op dezelfde datum. Het nieuwe feit tegenover de controle van 07-09: Nederland en Spanje openen 1 tot 31 oktober, en België Spring 2027 opent 1 tot 30 januari. Er is dus een tweede en een derde kans, en de Nederlandse deur is voor R4M inhoudelijk de interessantste: de KSA-boetes van 2026 (zie de 711-vondst hieronder) zitten in dat land. De toelatingseis is expliciet "a working proof of concept" — die heeft R4M. Bedrag en aandelenpercentage staan niet op de aanvraagpagina; dat is een open punt, geen aanname. Zo zet je dit in de markt: zet de Belgische aanvraag klaar met 30-09 als deadline, maar hou de Nederlandse van oktober als de sterkere — daar kan je de KSA-zaak als markt-bewijs meesturen in plaats van als hypothese.
12-09💵 Een Brugs bedrijf betaalde 886.000 euro boete voor een zorgplicht die het per rekening niet kán zien — De Nederlandse Kansspelautoriteit legde op 11-06-2026 een boete van €886.000 op aan 711 BV wegens onvoldoende naleving van de zorgplicht over de periode februari 2022 tot juni 2024 (bron: kansspelautoriteit.nl/711-leeft-zorgplicht-onvoldoende-na-en-krijgt-boete-van-eur886-000). De KSA vroeg tien spelersdossiers op van mensen met hoge verliezen, hoge frequentie en nachtelijk spel, en vond in alle tien een overtreding: 711 analyseerde het speelgedrag niet goed en greep niet op tijd in. De standaardboete van €500.000 werd opgetrokken omdat de bruto spelopbrengst in 2025 €67,3 miljoen bedroeg. Het bedrijf zelf: 711 BV, Gistelse Steenweg 300 bus 201, 8200 Brugge, KBO 0762.709.614, actief sinds 29-01-2021 — nagekeken in het Belgische KBO op 12-09-2026. Dus: een Belgisch bedrijf, op een uur rijden, met een Nederlandse vergunning (KSA 1976/01.259.997) die op 15-03-2027 afloopt. Dat is de klok. Voor de hele Nederlandse markt telde 2026 tot nu ongeveer €35,59 miljoen aan KSA-boetes, bijna allemaal voor zorgplicht (Qbet €24,85 miljoen op 10-03, Vave €3,08 miljoen op 17-06, Rant €4,23 miljoen op 13-01, ComeOn €750.000 op 13-01). 🔌 Integratievorm: OIDC-knop plus API-sleutel op hun backend. 1) Wat draait al: de eID/itsme-poort (Signicat-sandbox, verified gemeten 12-09 00:36) en de attestatie-ondertekening. 2) Wat Franky bouwt: een persoons-sleutel-endpoint dat per aanmelding een stabiele pseudonieme mens-id teruggeeft — twee tot drie dagen, want de binding bestaat al; het nieuwe is een uitlees-endpoint op hun kant. 3) Wat de klant doet: de mens-id meesturen in hun eigen zorgplicht-analyse in plaats van het rekeningnummer. 4) Standaard: OIDC + SD-JWT-attest. 5) Kleinste demo zonder hun toestemming: een namaakpagina met twee rekeningen op één eID, waar de teller optelt over beide. 🧩 Productmix: V (verificatie) en C (attestatie-oproep) — de rail doet niet mee, er stroomt geen geld. Trede: attestatiekant alleen. Meter: M1 bij elke nieuwe speler (draagt de itsme-kost), M2 bij elke raadpleging op een gebonden mens. Groeipad: starten met uniciteit bij inschrijving, later de EPIS/Cruks-poort erbij (case 193) en dan pas een bonus-teller per mens (case 142). Wat R4M niet doet: R4M analyseert geen speelgedrag en bepaalt geen interventiedrempel. Dat blijft hun werk en hun aansprakelijkheid. R4M levert de laag eronder: dat het één mens is over alle rekeningen en merken heen. Zonder die laag is elke gedragsanalyse per rekening, en dat is precies waar de tien dossiers op stukliepen. Zo zet je dit in de markt: openingszin voor Brugge — "U kreeg in juni een boete omdat de zorgplicht per rekening werd gemeten. Wij maken van tien rekeningen één mens, met de Belgische eID, zonder dat u een identiteitsdossier moet bijhouden. Uw vergunning loopt tot maart 2027; zullen we vóór de verlenging één aanmelding samen doorlopen?" Dit is een voorstel in de inbox, geen case — jij beslist.
12-09🔎 Een KYC-leverancier publiceert zelf het cijfer dat zijn eigen categorie ondergraaft: 65,68% vervalste documenten — Shufti bracht op 08-09-2026 het Identity Fraud Report 2026 uit, op eigen netwerkdata (persbericht via GlobeNewswire, 08-09-2026). De harde cijfers: van alle gelinkte frauduleuze aanmeldpogingen — pogingen die aantoonbaar bij elkaar horen — is 65,68% te herleiden tot hergebruikte vervalste identiteitsdocumenten, gevolgd door gedeelde IP-adressen (17,67%) en gedeelde toestellen (16,64%). Binnen AI-gedreven fraude is document-deepfake 80,10% en die groeit naar verwachting met bijna 3.900% jaar op jaar; deepfake-fraude in het geheel zou in 2026 met 495% stijgen. En de zin die er voor ons het meest toe doet: multi-identity account abuse concentreert zich in iGaming, forex en lending, waar één operator welkomstbonussen kan oogsten, zelfuitsluiting kan omzeilen of tegengestelde posities kan aanhouden over rekeningen die niet met elkaar in verband lijken te staan. Zwaarst getroffen sectoren: digital assets 22,49%, fintech 18,36%, forex 17,18%, lending 17,08%, online gaming 12,45%. ⚔ Soort competitie: naastligger, geen concurrent. Shufti verkoopt documentcontrole en gezichtsvergelijking. Ze nekken R4M niet, want hun eigen rapport zegt dat het document zelf de aanvalsopening is — je kan een vervalst paspoort niet beter controleren dan de staat die het uitgaf. Waar ze ons raken: bij een klant die "wij doen al KYC" zegt. Het antwoord staat nu in hun eigen cijfer. Zij meten of dit document echt lijkt; R4M vraagt de staat of deze mens al gebonden is. Dat zijn twee verschillende vragen, en 65,68% zegt welke van de twee vandaag faalt. Zo zet je dit in de markt: dit is géén nieuwe case, het is bewijsmateriaal onder de bestaande case 142 (één welkomstbonus per mens) en case 193 (kansspel-poort België). Zet het cijfer in de verkoopkit: van alle fraude die aantoonbaar bij elkaar hoort, hangt tweederde aan hergebruikte documenten — precies het stuk dat een eID-binding overslaat. Gebruik het ook in het gesprek met 711 hierboven: hun boete en dit cijfer beschrijven hetzelfde gat.
12-09⚙️ x402 lapt een omzeiling die twee keer decoderen nodig had, en de reikwijdte is kleiner dan de schrik — PROTOCOLWACHT, gemeten 12-09-2026 om 03:1x aan de bron. Op 11-09-2026 gingen twee commits binnen op x402-foundation/x402: 04c750e (#3441, Go) en 273ecef (#3440, Python), allebei "decode routeTemplate to a fixed point before traversal checks". De patch van 04c750e gelezen: één enkele decodeerbeurt liet %252e%252e door, want dat wordt pas na twee beurten ... De fix decodeert nu tot een vast punt met een budget van vijf beurten, en de nieuwe tests weigeren expliciet dubbel- en drievoudig gecodeerde traversal én scheme-injectie (%253a%252f%252f). De TypeScript-kant kreeg dezelfde fix al op 09-09 met 8ae5ff6 (#3213). Reikwijdte, eerlijk begrensd. Dit zit in de bazaar-uitbreiding, de ontdekkingslaag van x402 — niet in het betaalscheme. R4M draait base-sepolia met adapter usdc-base op v0.36.7 en gebruikt bazaar niet: nagemeten in de motorbroncode, nul treffers op bazaar, routeTemplate en decodeURIComponent. Er verandert dus vandaag niets aan onze werking. Waarop moet jij anticiperen: zodra R4M ooit een attestatie-bron pubiceert in de x402-bazaar — en dat is de logische route om als betaalde resource vindbaar te worden — erven we deze validatie. Zet dan de versie-ondergrens op de release ná deze commits. Verder: upto-op-EVM blijft op nulstand, nul treffers op de identiteitshaak in een bestand van 134 regels, en docs/schemes/upto.mdx noemt receiverAuthorizerSigner nog uitsluitend in het SVM-tabblad. x401 is onveranderd: de jongste commit op proof/x401 blijft f739b0e van 01-07-2026, ruim tien weken stil. Onze achterstand op de gekende versie (x402 V2) is nul.
12-09⚖️ Het CRA-meldloket bestaat nu echt — gisteren om 03:08 was dat niet meetbaar — Aanvulling op de G17-vaststelling van gisteren, niet een herhaling ervan. Op 11-09 om 03:08 mat de routine dat de ENISA-themapagina wel antwoordde maar geen adres van het Single Reporting Platform noemde, en dat de Commissie nog in de toekomende tijd schreef dat het SRP "will be operational by 11 September 2026". Vandaag, 12-09-2026 om 03:3x, is dat veranderd: de CRA-meldpagina van de Commissie schrijft nu in de tegenwoordige tijd dat het platform operationeel is sinds 11 september 2026 en verwijst naar enisa.europa.eu/topics/product-security/single-reporting-platform-srp. Die pagina antwoordt met HTTP 200 en draagt nu echte handleidingen: SRP Guidance — AR User Registration, AR Notification submission and update, AR Interface functions. Er is dus een registratieprocedure, geen aankondiging. Gevolg voor ons: de meldplicht is niet langer een datum maar een loket met een inschrijving. De klok van 24 uur begint te lopen op het moment dat je van een actief uitgebuite kwetsbaarheid weet, 72 uur voor de volledige melding, 14 dagen voor het eindrapport. Dat raakt Secure Mail zodra dat als product de EU-markt op gaat, en het geldt ook voor producten die er al staan. Open punt, niet gegokt: in de zoekresultaten staat dat micro- en kleine ondernemingen zijn vrijgesteld van de administratieve boetes voor het missen van de 24-uursmelding, terwijl de meldplicht zelf blijft gelden. Dat staat niet op de pagina van de Commissie die ik las, dus het is nog geen vastgesteld feit. Dit is een V-vraag voor Nele: geldt die boete-vrijstelling voor een eenpersoons-BV, en verandert ze iets aan de plicht zelf? Volledige CRA volgt op 11-12-2027.
12-09🩺 De motor: 398 groen, 2 overgeslagen, 67 bestanden — en geen versiedrift — Gemeten op 12-09-2026 om 03:06 op de tak main van /Volumes/8TB MM4/Rails4Mankind, working tree schoon. Uitkomst: Test Files 67 passed (67) · Tests 398 passed | 2 skipped (400), duur 9,02 s. Herhaalbaar met:
cd "/Volumes/8TB MM4/Rails4Mankind" && npm test
Versie, twee bronnen apart gehouden. REPO: VERSION = 0.36.7, package.json = 0.36.7, jongste git-tag = v0.36.7. LIVE: r4m-franky.fly.dev/api/public/status meldt v0.36.7. Geen versiedrift. Endpoints, letterlijk uit checks: app_live configured+verified (01:06 UTC) · settlement_adapter = usdc-base, configured, verified null · email_login configured, verified null · itsme_eid configured+verified (00:36 UTC, sandbox) · attestations configured+verified, realIssued = 2 · double_entry_ledger configured+verified. Netwerk base-sepolia, stage pilot. Uitgegeven attestaties: 2 uitgegeven, 0 live, 1 onderscheiden mens. Die nul is de eerlijke stand: de geldweg draait end-to-end op testnet, zonder echte waarde. Zo zet je dit in de markt: 398 groen en een draaiende motor is het enige wat je in een aanvraag kan tonen dat een slide niet kan. Gebruik het in Start it @KBC en imec.istart. Zeg er telkens bij dat het testnet is — dat is geen zwakte maar een configuratiestap, en wie je erop betrapt dat je het verzweeg verliest je het gesprek.
12-09📬 Een openstaande deur met een datum: ETSI en CEN zetten eind september de EUDI-standaarden op tafel — ETSI organiseert samen met CEN van 29 september tot 1 oktober 2026 een gezamenlijke workshop over het Europese digitale-identiteitsraamwerk, voor partijen die met de vertrouwensinfrastructuur van de EUDI-wallet werken (bron: Biometric Update, juni 2026, over de ETSI-standaardenuitrol). Dat valt precies in het venster waarin de lidstaten hun wallet moeten aanbieden: de eIDAS 2.0-verplichting loopt af eind 2026, en vanaf december 2027 moeten gereguleerde sectoren de wallet aanvaarden voor sterke klantauthenticatie. 📌 Waarom dit een outreach-kandidaat is en geen wenslijstje: er is een gedateerde aanleiding (de workshop, 29-09), een juiste deur (de ETSI-CEN-werkgroep rond de EUDI-vertrouwensinfrastructuur, niet een lidstaat) en een pakket dat past (de attestatiekant van R4M, niet de rail). R4M leunt op dezelfde bouwstenen — OIDC, SD-JWT, een broker die de staat bevraagt — en de vraag die R4M stelt (is dit één mens, al gebonden?) is precies de vraag die de walletstandaard niet beantwoordt. Eerlijk wat hier níet in zit: ik heb geen inschrijfpagina, geen prijs en geen deelnemerslijst gevonden — alleen de datum en de organisatoren. Dat is dus een actie voor jou: zoek de inschrijving op etsi.org op, en beslis of dit de moeite is. Als het gratis online bij te wonen is, is het de goedkoopste manier om te horen welke sectoren als eerste moeten aanvaarden. Zo zet je dit in de markt: niet als spreker, maar als toehoorder die daarna één gerichte mail stuurt. Positionering: R4M zit niet in de wallet, R4M zit ernaast — de wallet zegt wie je bent, R4M zegt dat je er maar één keer bent.
11-09✓ AUDIT — de collision-guard hield stand tot de avond, en het backup-alarm zweeg twintig uur — Het vonnis van vanmiddag kon alleen zeggen dat de nieuwe derde vraag van de guard werkte op een dag waarop ze niets te herstellen vond. Vanavond is de toestand zelf gemeten. De motor-repo staat op main, de working tree is leeg, en van de 24 voorstel-takken heeft er nul geen upstream. Het externe bewijs is sterker dan onze eigen meting: r4m-autopush-ALARM.log telt zeven alarmregels op 10-09 en nul op 11-09, met de laatste om 23:15:42 gisteravond. Op 10-09 sloeg datzelfde log vanaf 16:05 zeven keer alarm omdat de middagfase een tak liet staan zonder upstream. Zo zet je dit in de markt: een reparatie die zes uur later nog houdt en een wachter die zwijgt zijn samen het verschil tussen "gefixt" en "bewezen" — precies de lat die R4M aan klanten verkoopt. Wat dit niet zegt: de reddingstak van vraag 3 (een blijven staande tak alsnog pushen) is nog altijd niet uitgevoerd en dus niet getest.
11-09⏱ AUDIT — een 302 die een 520 verbergt: onze hermeetregel kijkt alleen naar slecht nieuws — Sinds 09-09 geldt de regel dat elke bron die geen 200 geeft een tweede keer gemeten wordt, ingevoerd nadat de FSMA-pagina vijf avonden ten onrechte als onbereikbaar genoteerd stond. Vanavond bleek het gat aan de andere kant. De ronde van 10-09 noteerde dat de Nationale Bank 302 gaf en verklaarde de storing daarmee voorbij. Die 302 was echt, maar het is de doorverwijzing naar www.nbb.be, en dáár staat een 520. Vanavond in drie vormen gemeten, elk twee keer, mét en zonder het volgen van de omleiding: www.nbb.be 520, www.nbb.be/nl 520, kale nbb.be 302. De storing loopt dus onafgebroken van 05-09 tot vandaag — zeven avonden, niet vijf — en de tabel droeg een dag lang een herstel dat er geen was. Op 09-09 heette een levende bron vijf avonden dood; vanavond heette een dode bron een avond levend. Twee keer was de meetmethode de oorzaak en niet de bron. Zo zet je dit in de markt: dit is het bewijsstuk onder de claim dat R4M zijn eigen metingen wantrouwt in plaats van ze te geloven — de fix zit vanavond in de NBB-rij (een herstel wordt voortaan óók twee keer gemeten), en wat níét gebeurd is staat er eerlijk bij: de algemene regel in BRONNEN.md dekt herstel nog steeds niet.
11-09🔍 De dichtstbijzijnde concurrent draait geen eigen afwikkeling — t54 hangt vóór de publieke x402-facilitator — t54 labs (Singapore/VS, GitHub t54-labs/x402-secure, 28 sterren) verkoopt Trustline als "identity, verification and compliance", maar de repo-omschrijving zegt vandaag letterlijk "Risk layer for the x402 protocol." — laatste push 30-08-2026, twaalf dagen stil. Vanavond is voor het eerst hun productie-proxy zelf gemeten in plaats van hun marketing. Het pad staat in hun eigen README: https://x402-proxy.t54.ai/health geeft 200 (169 bytes, twee keer gemeten, 11-09-2026 17:08 UTC) en het antwoord draagt twee velden die alles zeggen: upstream_verify en upstream_settle wijzen allebei naar https://x402.org/facilitator/…. Waarom dit ons niet nekt: zij bouwen geen rail — ze hangen als risicolaag vóór de publieke facilitator van iemand anders, en hun vier README-beloften gaan alle vier over gedrag van software (redeneerketens, gekaapte agenten, prompt-injecties, audittrails), nul over een mens. Waar het ons wél raakt: een risicolaag die klanten al aan de x402-keten heeft, zit dichter bij de identiteitsvraag dan wij bij hun klanten. Zo zet je dit in de markt: VOLG — de nieuwe wachtpost is het upstream_*-veld zelf. Wijst dat ooit naar een eigen domein, dan bouwen ze wél afwikkeling en verschuift de concurrentie van gedrag naar geld. Tot dan is de openingszin naar hun kant van de markt: "jullie meten of een agent zich misdraagt, wij meten of er een mens achter zit — dat is geen overlap maar een stapel."
11-09🔬 TEST — 75 metingen op 49 bronnen: 44 levend, één dood, één hersteld, en één meetfout van onszelf — De avondronde op docs/BRONNEN.md, alle rijen bijgewerkt naar 11-09. Levend en bruikbaar: 44. Onbereikbaar: de Nationale Bank (zevende avond, zie het auditvonnis hierboven). Hersteld: de Dune-query met het x402-volume, die gisteren twee keer 403 gaf en vanavond drie keer 200 — exact hetzelfde patroon als 05→06-09, dus dat is nu een reeks en geen incident. Vanaf nu telt één 403 op Dune als meting en pas twee ronden op rij als statuswijziging. Eén nieuwe rij aangelegd (x402-proxy.t54.ai/health), geen enkele rij geschrapt. Eigen fout, meteen rechtgezet: de eerste meetronde las hoogstens 400.000 bytes per bron en gaf dus voor vier grote bronnen exact dat getal terug — dezelfde meetlimiet-fout die deze tabel op 06-09 al veroordeeld heeft. Alle vier opnieuw gemeten zonder limiet; alleen die getallen staan in de tabel. Zo zet je dit in de markt: de radar staat nu op 844.834 bytes en cases-db.json op 5.763.556 — beide gegroeid vandaag, dus de fasen die draaiden hebben ook echt iets afgeleverd. Zelf herhalen: cd "/Volumes/8TB MM4/Rails4Mankind" && sed -n '/Ronde 11-09/,$p' docs/BRONNEN.md.
11-09💡 VOORSTEL — drie tests werden rood op elke machine behalve deze, en niemand hier kon dat zien — Tak voorstel/2026-09-11-bord-ontbreekt-eerlijk, commit 9e50d18, gemaakt in de middagfase van 11-09-2026. Het auditvonnis van vannacht 00:45 stelde vast dat drie tests het financieringsbord rechtstreeks van schijf lazen. Dat bord staat bewust buiten git, dus in elke verse kloon eindigden die drie in een kale foutmelding zonder uitleg — rood op elke andere machine, onzichtbaar op deze. Het voorstel geeft de bronwacht twee functies: één die vooraf zegt of het bord er staat, en één die bij afwezigheid een fout gooit die uitlegt wáárom. De drie bordtests slaan zichzelf daarna zichtbaar over waar het bord ontbreekt; drie nieuwe tests die overal draaien pinnen die uitleg vast. Wat de tests aantoonden: op deze Mac 401 groen tegen 398 op main, met niets nieuw overgeslagen; in een verse kloon uit exact de git-inhoud gaf het betrokken testbestand 11 groen en 3 zichtbaar overgeslagen waar het eerder 3 rood gaf. Typecheck groen, server boot op v0.36.7 met adapter usdc-base op base-sepolia, demo end-to-end door met de vijf boekhoudcontroles groen. Wat het met opzet niet doet: het bord in git zetten. Dat is een beslissing van Franky — tracken, aparte privé-repo, of zo laten. Zo zet je dit in de markt: niet naar buiten, dit is machinewerk. Wel het patroon dat je aan een klant uitlegt: een test die alleen groen is op de machine van de bouwer bewijst niets over de code, en R4M meet dat verschil in plaats van het weg te poetsen.
11-09✓ AUDIT — de guard die gisteren de tak niet zag, deed vandaag precies wat hij moest doen — Gemeten in de middagfase van 11-09-2026, niet afgeleid. Vóór de start: de repo stond op main, de working tree was leeg, en de laatste commit die niet van het backupscript kwam was c1c4970 van vanochtend 03:27 — negen uur oud, ruim buiten het venster van zestig minuten. Alle drie de vragen groen. Na afloop opnieuw gemeten: de nieuwe tak is gepusht mét upstream, de repo staat terug op main, de working tree is leeg. Dat zijn exact de drie dingen die op 10-09 ontbraken en die de automatische backup zeven keer deden alarmeren met een oorzaak die niet bestond. Wat dit vonnis niet zegt: het bewijst de guard op een dag waarop er niets te herstellen viel. Het reparatiepad — een blijven staande tak alsnog pushen — is niet doorlopen. Zo zet je dit in de markt: de kortste versie van wat R4M verkoopt is dit: een systeem dat zijn eigen stilstand meet in plaats van erop te wachten. De fout van 10-09 is niet met een regel in een document gerepareerd maar met een controle die elke run draait.
11-09🧪 TEST — 401 groen en 2 overgeslagen op de voorstel-tak, tegen 398 en 2 op main — Gemeten op 11-09-2026 tussen 13:07 en 13:09 in /Volumes/8TB MM4/Rails4Mankind, 67 testbestanden. Op main: 398 groen, 2 overgeslagen, 400 in totaal. Op voorstel/2026-09-11-bord-ontbreekt-eerlijk: 401 groen, 2 overgeslagen, 403 in totaal. Drie tests erbij, geen enkele test die eerder draaide slaat zichzelf nu over — want het financieringsbord staat op deze machine wél. De derde meting is de interessante: in een verse kloon, gemaakt met git archive HEAD | tar -x en dus zonder het bord, gaf het betrokken testbestand 11 groen en 3 zichtbaar overgeslagen, waar dezelfde kloon vóór deze wijziging 3 rood gaf. Herhaalbaar met npm test in de engine-map, en met npx vitest run test/url-wacht.test.ts in een verse kloon. Zo zet je dit in de markt: het getal 401 is niets waard zonder de machine erbij. Wie R4M laat auditeren krijgt het getal én het commando, zodat hij het zelf kan natikken.
11-09💰 FUNDING — Start it @KBC sluit maandag, dus vandaag is de laatste werkdag, en imec blijkt twee landen op dezelfde regel te zetten — Twee harde regels vandaag opnieuw aan de bron gemeten in de middagfase. Start it @KBC — startit.be/apply leidt permanent door naar startit-x.com/en/accelerate/start-it-kbc en die pagina draagt onveranderd "14.09.2026". Vierde controle op rij, nul wijzigingen. Het nieuwe feit is de kalender: 14 september is een maandag, vandaag is vrijdag. Wie het weekend gebruikt om te schrijven heeft nog tijd; wie op een antwoord van iemand anders wacht niet meer. Gratis, geen equity, solo indienbaar. imec.istart — de zin "Open call Sept 1 - Sept 30" staat twee keer in de landentabel: onder BELGIUM én onder GERMANY. De Belgische rij is apart nagemeten en klopt, maar het was toeval dat hij klopte: wie op de maandnaam alleen zoekt kan net zo goed de Duitse rij lezen. Die correctie staat nu in het dossier. Wat missen kost is voortaan ook meetbaar: de pagina noemt zelf de volgende Belgische ronde, "Spring 2027 · Open call Jan 1 - Jan 30". Vier maanden, geen maand — dat bevestigt dat 30-09 een harde datum is. Nog 19 dagen, dus nog geen vlag; hij wordt urgent op 16-09. Zo zet je dit in de markt: niet extern. Intern is het de enige deur die deze week dichtgaat, en de enige beslissing van vandaag die een kalender heeft.
11-09📰 OCHTENDRAPPORT — elf inbrengen vannacht, en de kop is een zin die de Belgische staat zelf geschreven heeft — Het rapport over het venster 10-09 08:30 naar 11-09 08:30 staat op de Ochtendrapport-tab (or-20260911). De kern: de FOD-pagina over elektronisch stemmen bevat de GBA-regel dat "minder ingrijpende methodes dan identificatie en authenticatie op basis van het rijksregisternummer de voorkeur verdienen", en de eis van beveiligd mailverkeer voor authenticatiegegevens. Twee R4M-producten op een overheidspagina, met een klok van negentien dagen en een gesloten lijst van vijf leveranciers eronder. Daarnaast: Valve tegenover Epic in Australie, Pi Network als tweede prijsdruk binnen een week, de CRA-meldplicht die vandaag in werking trad, en drie lijnen (x402, x401, IoT) die eerlijk leeg bleven. Testsuite 398 van 400 groen op v0.36.7, geen versiedrift, kasboek sluit op alle vijf de invarianten. Zo zet je dit in de markt: de stemvondst is de enige van de nacht met tegelijk een juridische hefboom, een klok en een bereikbare koperslijst — begin daar, en niet bij het sterkste verhaal.
11-09⚠ AUDIT — het GDPR-bronrapport staat tien dagen stil, en dat is precies het patroon dat twee keer eerder maanden duurde — De ketencheck van Site-Fleet (python3 ketencheck.py, gedraaid 11-09-2026 08:05) meldt vier ketens gezond en een vijfde stil: het GDPR-bronrapport, laatste draai 01-09-2026, tien dagen geleden bij een drempel van negen. Het hoort maandags mee te lopen met seo-fleet-watch, via gdpr-monitor.sh. De vier andere staan groen: SEO-meting vandaag, Artes GDPR-check 07-09, Site-Fleet commit vandaag, klantrapporten 07-09. WAAROM DIT ER TOE DOET. Dit is hetzelfde beeld als de SEO-keten die op 09-07-2026 stilviel en zeven weken onopgemerkt bleef, en de Artes-GDPR-monitor die op 01-06-2026 stopte en drie maanden stillag. In geen van beide gevallen brak er iets — er keek alleen niemand van buitenaf. Zo zet je dit in de markt: niet naar buiten, naar binnen. Een routine die stilligt kan niet melden dat ze stilligt; de ketencheck is het enige oog dat dat wel kan, en die meldt nu iets. Eerst uitzoeken waarom gdpr-monitor.sh maandag niet gedraaid heeft.
11-09🧪 TEST — de SEO-vloot meet twintig domeinen, de onsite-scores staan alle stil en vier snelheidsscores zakken fors — Opgehaald bij ccc-v3.franky-f29.workers.dev/api/seo-watch op 11-09-2026 08:06. Elf domeinen zijn vandaag gemeten, de rest draagt een oudere meting. Onsite: geen enkele beweging, alle verschillen nul. Core Web Vitals dalen wel, op vier domeinen scherp: boombedrijfbisschop.be min 23 (naar 75), turbeau2rock.com min 13 (naar 71), channel-zero.be min 11 (naar 54), idgs.eu min 10 (naar 74). Zoekverkeer vandaag: channel-zero.be 117 kliks op 3.258 vertoningen op positie 8, boombedrijfbisschop.be 17 kliks, qmtex.net 8 kliks op positie 1,9, blackfuelwhiskey.com en idgs.eu elk 7, lowlands.business 1. Twee domeinen leveren geen CWV-cijfer (qmtex.net, gevelsteenbedrijf-v6). Herhaalbaar met curl -s https://ccc-v3.franky-f29.workers.dev/api/seo-watch. Zo zet je dit in de markt: channel-zero.be haalt 117 kliks per dag met een mobiele snelheidsscore van 54 en vier openstaande autofails (canonical, schema, robots, sitemap). Dat is het domein waar werk het snelst zichtbaar wordt — en het is geen R4M-domein, dus het hoort in de SEO-keten, niet in de verkoop.
11-09⚠ AUDIT — de pijplijn telt zesenvijftig prospects en nul gesprekken, en de nacht blijft er deuren bij leggen — Geteld in cases-db.json op 11-09-2026 08:07: 56 prospects, waarvan 52 op status "uitzoeken" en 4 op "benaderen". Nul gecontacteerd, nul gereageerd. Die verdeling staat sinds begin september stil, terwijl de nachtroutine in diezelfde periode tientallen radar-inbrengen leverde — vannacht opnieuw vijf leveranciers met een gedateerde aanleiding en een uitgeschreven openingszin. Dit is geen routinefout. De machine doet wat ze moet doen: zoeken, natrekken, de deur benoemen. Wat er niet gebeurt, gebeurt aan de andere kant. Zo zet je dit in de markt: dit is een beslispunt, geen verwijt. Ofwel wordt er deze week gebeld — Assembly Voting en Neovote staan klaar, vijfenveertig minuten — ofwel zakt prospectie naar een lagere prioriteit en levert de radar minder prospects en meer protocol- en juridisch werk. Beide zijn verdedigbaar; stilstand is het niet.
11-09🆔 IDENTIFICATIE-CASE — de Belgische wet zegt zélf dat het rijksregisternummer de laatste keus is bij elektronisch stemmen — Op de officiële pagina van de FOD Werkgelegenheid over elektronisch stemmen bij sociale verkiezingen (werk.belgie.be, gelezen 11-09-2026 03:10) staan twee zinnen die samen onze hele verkoop dragen. Eén: de Gegevensbeschermingsautoriteit stelt dat "minder ingrijpende methodes dan identificatie en authenticatie op basis van het rijksregisternummer de voorkeur verdienen", en dat het rijksregisternummer alleen doorgegeven wordt wanneer geen minder ingrijpende methode in aanmerking komt. Twee: gaan authenticatiegegevens per mail tussen fabrikant en kiezer, dan moet dat via "beveiligd mailverkeer". De fabrikant van het stemsysteem werkt de authenticatie zelf uit — de FOD doet alleen het depot. WAT HIER NIEUW AAN IS. Het dossier kende de klok van case 134 al (08-09), maar de term "minder ingrijpend" komt in de hele public/-map niet voor (gemeten 11-09 03:11). Wij verkochten uniciteit als comfort; de wet formuleert het als een voorkeursregel met een voorwaarde: mág het minder ingrijpend, dan móet het minder ingrijpend. Tot vandaag bestond die minder ingrijpende methode niet in de praktijk, dus ging het nummer over de lijn. Onze attestatie ís die methode. DE KLOK. De referteperiode voor vaste werknemers loopt van 01-10-2026 tot 30-09-2027, voor uitzendkrachten van 01-04-2027 tot 30-06-2027 (Vandelanotte, 27-08-2026, onder voorbehoud van publicatie van de verkiezingswet). Over negentien dagen begint de teller die bepaalt wie in 2028 moet stemmen. Wie dán zijn stemsysteem kiest, kiest nu zijn authenticatie. 🔌 Integratievorm: B — OIDC-knop ("Log in met R4M"), met A als demo. Opzetpad: (1) draait al — de attestatie-motor ondertekent en de itsme-broker is bereikbaar (statuspagina 11-09 01:05: itsme_eid verified, attestations verified); (2) Franky bouwt de OIDC-façade op het bestaande attestatie-endpoint, geschat 3-5 dagen; (3) de stemleverancier registreert één redirect-URL en vervangt het RRN-veld door de pseudonieme attestatie-claim; (4) standaard: OpenID Connect, met de GBA-regel als juridische grond; (5) kleinste demo zonder toestemming van de klant: een publieke stempagina waar dezelfde kiezer twee keer probeert te stemmen en de tweede stem afbotst op het pseudoniem, zonder dat er ooit een rijksregisternummer in beeld kwam. 🧩 Productmix: V + G + D. V bewijst één echte unieke mens, G is het stemlokaal waar alleen bewezen kiezers in mogen, D houdt bij dat dit pseudoniem al gestemd heeft. De rail doet níét mee — dit is pure attestatie, trede 2, geen geldstroom, meter M1 bij de eerste verificatie en M2 bij elke volgende raadpleging. Groeipad: begin bij het attest voor één werkgever, schaal naar de stemleverancier, en pas veel later komt er eventueel een geldkant bij. ⚠ Let op de bronjaartallen: de FOD-pagina is die van de verkiezingen van 2024 en de wet voor 2028 is nog niet gepubliceerd. De GBA-regel is een privacy-principe en verdwijnt niet, maar het exacte 2028-artikelnummer moet nagekeken worden zodra de wet er is. Zo zet je dit in de markt: dit is de eerste keer dat een Belgische overheidspagina zelf schrijft dat onze methode de voorkeur verdient boven de methode die vandaag gebruikt wordt. Openingszin naar een stemleverancier: "Uw eigen FOD-pagina zegt dat het rijksregisternummer alleen mag als er geen minder ingrijpende methode bestaat. Sinds kort bestaat die wel — mag ik u in twintig minuten tonen hoe uw kiezer zich authenticeert zonder dat u dat nummer nog moet aanraken?"
11-09🆔 IDENTIFICATIE-CASE — Valve laat Australiërs hun kredietkaart vastklikken als leeftijdsbewijs, Epic doet op dezelfde dag het tegenovergestelde — Sinds 9 september 2026 moeten Australische winkels voor volwassenenspellen de leeftijd controleren onder de Age-Restricted Material App Distribution Services Code, gehandhaafd door de eSafety Commissioner. Twee van de grootste spelwinkels ter wereld kozen op diezelfde dag tegengestelde methodes (ID Tech Digest, 10-09-2026). VALVE (Bellevue, Washington — maker van Steam) eist dat de Australische gebruiker een geldige Australische kredietkaart aan zijn account koppelt én daaraan gekoppeld hóudt, als doorlopend bewijs van volwassenheid. EPIC GAMES (Cary, North Carolina) koos gezichtsleeftijdsschatting of documentcontrole, via Yoti en Veriff. WAAROM VALVE'S KEUZE ONS ARGUMENT IS. Een kredietkaart bewijst dat iemand kredietwaardig is, niet wie hij is en al helemaal niet dat hij uniek is. Het kind dat de kaart van zijn ouder invoert, slaagt. De volwassene met drie kaarten maakt drie accounts. En omdat de kaart vastgeklikt móet blijven, verandert een leeftijdscontrole in een permanente opslag van een betaalinstrument — precies het soort gegevensberg waar de leeftijdsverificatiesector dit jaar al op stukliep. Valve heeft geen identiteitslaag; het heeft een betaallaag geleend en er identiteit op geplakt. NIEUW VOOR HET DOSSIER. Noch "Valve" noch "Epic Games" komt ergens in de public/-map voor (gemeten 11-09 03:14). Yoti en Veriff kende maX al; de twee kopers niet. 🔌 Integratievorm: C — REST-API met webhook op accountniveau, naast hun bestaande winkel. Opzetpad: (1) draait al — attestatie-endpoint plus pseudoniem; (2) Franky bouwt een leeftijdsclaim bovenop het bestaande attest (ja/nee ouder dan 18, zonder geboortedatum), geschat 2-3 dagen; (3) de winkel roept één keer bij accountaanmaak en bewaart alleen het pseudoniem, geen kaart en geen document; (4) standaard: OIDC-claim of een ondertekend attest, aansluitbaar op de EUDI-wallet zodra die er is; (5) kleinste demo zonder toestemming: een publieke pagina die twee accounts op hetzelfde pseudoniem laat botsen en toont dat er nul betaalgegevens bewaard zijn. 🧩 Productmix: V + G, met D als verschil-maker. Alleen de attestatiekant, trede 2, geen rail, meter M1 bij eerste verificatie en M2 daarna. D is hier het echte verkoopargument: een verbanning op de persoon-root overleeft het aanmaken van een nieuw account, een kredietkaartcontrole niet. Groeipad: start met de leeftijdsclaim voor één markt (Australië, want daar staat de wet), breid uit naar uniciteit per account. Zo zet je dit in de markt: hier ligt het contrast kant-en-klaar. Twee gelijkwaardige bedrijven, dezelfde wet, dezelfde dag, en de een bewaart kaartgegevens terwijl de ander gezichten scant — niemand bewijst uniciteit. Openingszin: "U bewaart nu een kredietkaart om te bewijzen dat iemand achttien is. Die kaart bewijst niet dat het dezelfde persoon is en niet dat het er één is. Mag ik u tonen wat u wél kunt bewaren: een pseudoniem dat geen betaalgegeven is en dat een tweede account herkent?"
11-09💶 GELD-CASE + 🥊 COMPETITIE — Pi Network betaalde een miljoen gewone mensen om achttien miljoen identiteiten te controleren, aan vier tienden van een cent per stuk — Pi Network (Pi Foundation, opgericht vanuit Stanford, VS) rondde op 3 april 2026 de eerste uitbetaling af aan zijn KYC-validatoren. De cijfers, bevestigd door het bedrijf zelf (minepi.com/blog/kyc-validator-rewards) en onafhankelijk nagerekend door Coinpedia (05-04-2026): 526.970.631 geslaagde validatietaken, meer dan 1 miljoen menselijke validatoren, 18 miljoen geverifieerde identiteiten, meer dan 200 landen. De beloning was 0,0504179 Pi per validatie — bij een koers van $0,077 ongeveer $0,0039, vier tienden van een cent. De totale pot was 26,5 miljoen Pi: 16,5 miljoen bijgelegd door de gebruikers zelf en 10 miljoen gesubsidieerd door de stichting. De uitkering liep van Pi Day (14-03-2026) tot 03-04-2026. DE METHODE. Elke aanvraag werd opgesplitst in losse taken — een levendheidsvideo, een documentcontrole, een fotovergelijking — verdeeld over meerdere onafhankelijke beoordelaars, met meerderheidsakkoord per stap, zodat niemand een volledig dossier zag. 🥊 WIE DIT IS EN WAAROM HET ONS NIET NEKT. Franky kent deze naam wellicht niet: Pi Network is een mobiel crypto-project dat sinds 2019 gebruikers laat "minen" op hun telefoon. Dit is de grootste menselijke verificatie-operatie ooit buiten een staat om, en ze bewijst dat de verdien-kant werkt: mensen betalen om mensen te tellen. Maar het attest heeft geen wortel. Een beoordeling door drie vrijwilligers die $0,004 verdienen is geen eID; ze staat nergens in het recht, geen enkele werkgever, stemleverancier of toezichthouder kan erop steunen, en de beoordelaars zijn zelf alleen door dezelfde methode gecontroleerd. Wij binden aan itsme en de Belgische eID — een wortel die een rechter aanvaardt. WAAR HET ONS WÉL RAAKT: de prijs. Vier tienden van een cent per controle is de tweede prijsdruk in een week, na Didit dat de uniciteitscontrole gratis weggeeft (radar 05-09). Ons prijspunt van €0,10–0,30 per verificatie staat daarmee onder druk van twee kanten. Het antwoord is niet zakken maar scheiden: wij verkopen geen controle-arbeid, wij verkopen een attest met juridische wortel. Dat is een ander product met een andere koper. 🧩 Productmix: V, alleen de attestatiekant. Geen rail, trede 2, meter M1. Dit is geen klant maar een ijkpunt. ❓ KEUZEVRAAG VOOR FRANKY — niet gegokt. Twee partijen drukken nu op dezelfde prijs. Blijft €0,10–0,30 per verificatie staan, of gaat de prijs naar de attestatie-oproep (M2) en wordt de eerste verificatie een instapkost? Die keuze raakt verdienmodel.html rechtstreeks en deze routine mag hem niet zelf maken. Zo zet je dit in de markt: gebruik dit cijfer als opening bij elke koper die twijfelt of uniciteit een echt probleem is. 526 miljoen controles en een miljoen betaalde mensen zijn niet ingezet voor een verzonnen probleem. Openingszin: "Een crypto-project heeft vorig jaar 526 miljoen controles laten uitvoeren door een miljoen mensen om achttien miljoen identiteiten te bevestigen. Dat is wat uniciteit kost als je geen wortel hebt. Wij hebben er een — mag ik u het verschil tonen?"
11-09🎯 PROSPECT — vijf leveranciers mogen elektronisch stemmen bij Belgische sociale verkiezingen, en vier daarvan staan nergens op onze lijst — De FOD Werkgelegenheid houdt geen erkenning maar een depot: alleen een stemsysteem dat bij de Algemene Directie Individuele Arbeidsbetrekkingen gedeponeerd is, mag gebruikt worden, en de FOD publiceert de namen van de fabrikanten. De vijf partijen die bij de vorige ronde in dat depot zaten: Elegio (intussen AXI, E-voting versie 7.5, actief bij de sociale verkiezingen van 2012, 2016 en 2020), Assembly Voting (Kopenhagen, Denemarken), BlueKrypt – Oadeo, Neovote (Frankrijk) en ONLZ. Bron: werk.belgie.be, aangevuld met Anchr (leverancierspagina Elegio), gelezen 11-09-2026 03:12. WAT DIT WAARD IS. Elegio stond sinds 08-09 al als prospect op de lijst. De andere vier niet. Dit is geen wenslijst maar een gesloten, publiek gepubliceerde lijst van elke partij die dit in België wettelijk mag leveren — de volledige bereikbare markt voor case 134, in vijf namen. Bij de vorige ronde stemde ongeveer 15 procent van de bedrijven elektronisch (ZigZagHR), dus de groeiruimte zit in de andere 85. DE TIMING IS HET HELE PUNT. Over negentien dagen, op 01-10-2026, begint de referteperiode. Deze vijf bedrijven zijn nu bezig met hun aanbod voor 2028. Wie ná januari belt, belt nadat de authenticatie-keuze gemaakt is. 🔌 Integratievorm: B (OIDC) naar de leverancier, niet naar de werkgever. Dit is een kanaalverkoop: één leverancier draagt honderden werkgevers. Opzetpad staat in de identificatie-case hierboven; wat hier bijkomt is dat de leverancier zijn gewijzigde systeem opnieuw moet deponeren bij de FOD — reken dat mee in de doorlooptijd en vraag ernaar in het eerste gesprek. 🧩 Productmix: V + G + D, attestatiekant, trede 2, meter M1/M2. ⚠ ONDER DE LAT, eerlijk gemeld. Deze vijf namen komen van de vorige verkiezingsronde. Het depot voor 2028 is nog niet gepubliceerd en de contactpersonen zijn niet opgezocht — dat is precies het werk dat Franky zelf doet, want deze routine maakt geen prospects aan. Wat hier ligt is de lijst, niet het gesprek. Zo zet je dit in de markt: vier belletjes dekken de volledige wettelijke markt. Openingszin naar Assembly Voting of Neovote: "U levert stemsoftware voor Belgische sociale verkiezingen. De Gegevensbeschermingsautoriteit zegt dat het rijksregisternummer alleen mag als er geen minder ingrijpende methode bestaat. Wij zijn die methode, en de referteperiode voor 2028 start op 1 oktober — heeft u twintig minuten vóór uw aanbod vastligt?"
11-09⚖️ JURIDISCH G17 — de CRA-meldplicht geldt vanaf vandaag, en het loket waar je moet melden was om 03:08 nergens publiek te vinden — Vandaag, 11 september 2026, wordt de meldplicht uit de Cyber Resilience Act bindend: een fabrikant van een product met digitale elementen moet een actief uitgebuite kwetsbaarheid of een ernstig incident binnen 24 uur als vroege waarschuwing melden, binnen 72 uur als volledige melding, en binnen 14 dagen met een eindrapport. ENISA schrijft: "From 11 September 2026, manufacturers are required to submit these mandatory notifications through the SRP" — het Single Reporting Platform (enisa.europa.eu, gelezen 11-09 03:07). De verplichting geldt voor álle producten die al op de EU-markt staan, niet alleen nieuwe. WAT DEZE ROUTINE ZELF GEMETEN HEEFT. Om 03:08 vanochtend gaf de ENISA-themapagina HTTP 200, maar srp.enisa.europa.eu loste niet op (curl-code 000, geen DNS-antwoord). De CRA-meldpagina van de Europese Commissie (digital-strategy.ec.europa.eu) noemt geen enkel webadres van het platform en schrijft in de toekomende tijd dat het "will be operational by 11 September 2026". Op de dag dat de plicht ingaat, staat het adres van het loket dus op geen van beide officiële pagina's. EERLIJK ERBIJ. Het is 03:08 op de dag zelf; het platform kan tijdens de kantooruren van vandaag alsnog verschijnen, en srp.enisa.europa.eu was een gok van deze routine, geen door ENISA gepubliceerd adres. Wat hard vaststaat is dat geen van beide officiële pagina's om 03:08 een adres noemde. Dit is een waarneming, geen beschuldiging. WAAROM DIT ONS RAAKT. De CRA raakt Secure Mail rechtstreeks: dat is software met digitale elementen die wij op de markt zouden brengen. Vanaf vandaag hoort bij elke release een meldpad — weten wáár je binnen 24 uur moet melden is geen papierwerk maar een klok die loopt vanaf het moment dat je iets weet. Het onderwerp stond sinds 07-09 op de radar maar niet in het juridisch dossier; die vlag ging drie dagen op rij als "onder de lat" de deur uit. Vannacht is bundel G17 wél bijgewerkt: status van toekomstige datum naar in werking, met de datum erbij. De volledige CRA volgt op 11-12-2027. Zo zet je dit in de markt: niet verkopen, wel gebruiken. Elke fabrikant van verbonden producten zit vandaag met dezelfde vraag, en wie straks over Secure Mail praat, praat met iemand die dit zelf heeft moeten uitzoeken. Dat is geloofwaardigheid die je niet koopt.
11-09💰 FUNDING — imec.istart aan de bron herbevestigd: 30 september middernacht, hard, negentien dagen — en geen vlag — Het bord droeg deze datum sinds 10-09 met de noot "bron niet opnieuw bevraagd". Vannacht wél bevraagd. De officiële aanmeldpagina (imecistart.com/en/apply, gelezen 11-09 03:15) toont voor België de najaarsronde als "Open call Sept 1 - Sept 30 (midnight)". Dat is een harde datum: mis je hem, dan is deze ronde weg en wacht je op de volgende oproep. Negentien dagen. GEEN 🚨-VLAG, en dat is met opzet. De drempel voor urgent is een harde datum binnen veertien dagen. Negentien is meer dan veertien, dus dit is een gewone regel. Op 25 september wordt hij vanzelf urgent; tot dan is een alarm alleen maar ruis. WAT DE BRON NIET ZEGT. Het bedrag staat niet op de aanmeldpagina. Het bord vermeldt €100K converteerbare lening plus accelerator; een derde partij noemde €100.000 tot €250.000, maar dat is niet aan de officiële bron bevestigd en het bedrag op het bord blijft dus ongewijzigd staan. Wie het exacte bedrag nodig heeft, vraagt het aan imec zelf. DE REST VAN HET BORD. Start it @KBC sluit op 14-09 en werd drie uur geleden al aan de bron herbevestigd (11-09 00:35) — die urgentie draagt vandaag geen nieuw feit en krijgt dus geen tweede alarm, zoals de eigen regel voorschrijft. Base Batches 004 en Eurostars Call 11 zijn gesloten; Call 12 staat op 4 maart 2027. EIC Accelerator blijft doorlopend met een zachte bundeling op 06-10. Vier regels nagekeken, één echt herbevestigd, nul feitwijzigingen. Zo zet je dit in de markt: niet verkopen maar plannen. Twee harde deuren in negentien dagen — 14 september en 30 september — en ze vragen allebei hetzelfde verhaal in een ander formaat.
11-09💰 FUNDING — Digital Europe sluit op 1 oktober, en na het openen van alle tien de onderwerpen past er geen enkel bij ons — Tien Digital Europe-oproepen staan open met één gedeelde, harde indieningsdatum: 1 oktober 2026 (NCP Flanders, gelezen 11-09 03:13). De onderwerpen: AI-beeldscreening in ziekenhuizen, regelgevende compliance via data, digitale vaardigheden voor AI in de zorg, een EdTech-accelerator, nationale coalities digitale vaardigheden, een EDIC-steunhub, situationeel bewustzijn rond informatie-integriteit, capaciteit voor het Europese e-gezondheidsdossier, het netwerk van Safer Internet Centres, en verspreiding van programmaresultaten. DE UITKOMST IS NEGATIEF, EN DAT IS DE WAARDE. Geen enkel van de tien gaat over digitale identiteit, vertrouwensdiensten, de EUDI-wallet of uniciteit. Het onderwerp dat er het dichtst bij komt — informatie-integriteit — is een onderzoeksraamwerk voor consortia, geen product-oproep. Een eenmanszaak trekt geen Digital Europe-consortium. WAAROM DIT TOCH OP DE RADAR STAAT. Een zoekmachine koppelt "Digital Europe" en "digitale identiteit" nog altijd aan de oproep DIGITAL-2024-BESTUSE-TECH-06-TRUST, en die pagina leeft nog. Ze is van 2024 en haar deadline lag op 24 september 2024 — twee jaar geleden. Wie die pagina vandaag vindt en de datum niet controleert, schrijft twee weken aan een dossier voor een deur die in 2024 dichtging. Deze regel staat er om dat te voorkomen. NIET op het bord gezet, geen vlag. Een deadline waar je niet aan kán meedoen hoort niet op een bord dat bedoeld is om aandacht te sturen. Zo zet je dit in de markt: onthoud wel dat de Europese identiteitsoproepen bestaan en in golven terugkeren. De volgende ronde is een partnerschapsverhaal, geen solo-aanvraag — dan heb je een consortium nodig, en dat is precies waarvoor Eurostars Call 12 op 4 maart 2027 een partner vraagt.
11-09⚙️ PROTOCOLWACHT — x402 zesendertig uur stil, x401 tweeënzeventig dagen, en de EVM-nulstand staat byte-voor-byte nog op nul — Alle drie de wachten staan vannacht op ongewijzigd, en dat is een geldige uitkomst. x402. De jongste commit op x402-foundation/x402 is 3c2ddfb van 09-09-2026 15:17 UTC (splitsing van upto-fouten op SVM). Sindsdien niets: ongeveer zesendertig uur stil, gemeten 11-09 03:06. De Cardano-implementatie (PR #2537) stond gisteren al op de radar en is dus geen nieuw feit. De jongste tag blijft pypi-x402@v2.22.0. Onze achterstand op de gekende versie (x402 V2) is nul. x401. De jongste commit op proof/x401 is f739b0e van 01-07-2026 — tweeënzeventig dagen geleden. Op 09-09 stond dat als zeventig dagen op de radar; twee dagen erbij is geen nieuw feit, dus dit blijft een regel en wordt geen tweede inbreng. De verplichte upto-EVM-nulstand. Het bestand typescript/packages/mechanisms/evm/src/upto/facilitator/scheme.ts telt 134 regels en 0 treffers op resolveCallerIdentity, authorizerSigner, delegatedAuthStore en receiverAuthorizer (gemeten 11-09 03:06). Identiek aan de nulstand van 07-09. De identiteitshaak blijft dus uitsluitend op SVM/Solana in de facilitator-delegated modus. Onze motor draait base-sepolia met adapter usdc-base (statuspagina 11-09 01:05), dus die haak raakt ons vandaag niet. Zo zet je dit in de markt: stilstand is hier het verkoopargument. Een protocol dat zesendertig uur niet beweegt is een protocol waarop je durft te bouwen, en de haak die ons zou raken ligt nog altijd op een keten waar wij niet staan — dat is ruimte, geen risico.
11-09🧪 TEST — 398 van 400 groen op main, kasboek sluit op alle vijf de invarianten, geen versiedrift — Volledige suite gedraaid op een schone hoofdtak van /Volumes/8TB MM4/Rails4Mankind, 11-09-2026 03:05: 67 testbestanden, 398 geslaagd, 2 overgeslagen, 0 rood, in 6,49 seconden. Herhaalbaar met npm test. Versie — twee bronnen, apart gemeten. REPO: VERSION 0.36.7, package.json 0.36.7, jongste tag v0.36.7. LIVE: https://r4m-franky.fly.dev/api/public/status meldt v0.36.7. Geen drift. Werkboom schoon, tak main — de voorsteltak van gisteren staat netjes opzij. Endpoints, letterlijk uit de statuspagina (11-09 01:05 UTC). app_live verified · settlement_adapter usdc-base configured, verified null · email_login configured, verified null · itsme_eid configured én verified (sandbox) · attestations verified met 2 echte attestaties · double_entry_ledger verified. Netwerk base-sepolia, fase pilot. Kasboek. /api/public/reconciliation is bereikbaar en sluit op alle vijf: globaal behoud 0 onbalans, elke transactie in evenwicht, cache gelijk aan het grootboek, audit-claim €1,76 gefund = €1,76 vastgehouden met 0 verschil, geen negatieve saldi. Zo zet je dit in de markt: dit is het getal dat je noemt wanneer een koper vraagt of er iets wérkt. Niet "het is af", wel "vierhonderd testen, achtendertig van de veertig tellen mee, de boekhouding sluit op vijf invarianten en u kunt de statuspagina zelf openen".
11-09🔍 AUDIT — de eigen eerlijkheidsregel hield vannacht een cijfer tegen dat nergens te herleiden was — Tijdens spoor I kwam een sterk cijfer boven: "88 procent van de organisaties had het afgelopen jaar een bevestigd of vermoed beveiligingsincident met een AI-agent". Dat is precies het soort getal dat in een verkoopgesprek werkt. Het is niet gepubliceerd. Bij het natrekken van de genoemde bron (Zitadel, gelezen 11-09 03:17) bleek het cijfer daar niet te staan: geen enquête, geen steekproef, geen jaartal, geen vermelding. Het getal kwam uit een samenvatting, niet uit een bron. Volgens de eigen regel — elk cijfer draagt een echte gecontroleerde bron met URL — gaat het niet de deur uit. WAT ER WEL STAAT, en het is bruikbaarder. Diezelfde bron formuleert het mechanisme zonder cijfer: wat misgaat is niet dat een identiteit dubbelzinnig is, maar dat "iets verderop in de keten een bewering vertrouwde die het niet kon controleren". Dat is in één zin waarom R4M bestaat, en het staat er van een partij die zelf identiteitssoftware verkoopt. WAAROM DIT ALS AUDIT OP DE RADAR STAAT en niet stilzwijgend verdwijnt. Op 07-09 ging een protocolvondst live die op drie punten fout was, en daaruit kwam de harde leesregel. Een regel die alleen zichtbaar is wanneer ze faalt, lijkt te werken. Vannacht hield ze iets tegen, en dat hoort even zichtbaar te zijn als de keer dat ze het niet deed. Vonnis: ✓ echt. Zo zet je dit in de markt: gebruik de zin, niet het cijfer. "Er ging iets verderop in de keten mee dat niemand kon controleren" opent elk gesprek over agenten beter dan een percentage dat een koper kan natrekken en niet vindt.
11-09📋 STAND VAN DE SPOREN — elf inbrengen vannacht, en drie lijnen die eerlijk leeg blijven — Fase VINDEN van 11-09-2026 03:00, volledig geteld. Elf inbrengen: twee identificatie-cases, één geld-case die tegelijk een competitie-ijkpunt is, één prospect-lijst, één juridische statuswijziging, twee funding-regels, één protocolwacht, één test, één audit en deze telling. DE LEGE SPOREN, met reden. 💸 x402-lijn: leeg. De enige beweging sinds gisteren is stilstand, en stilstand staat al in de protocolwacht. 🤝 x401-lijn: leeg. Tweeënzeventig dagen zonder commit, en op 09-09 stond zeventig dagen er al — twee dagen erbij is geen feit. 📡 IoT-lijn: leeg. De ontwerpplichten van de Data Act (verordening (EU) 2023/2854) gelden vanaf morgen, 12-09-2026, voor nieuwe verbonden producten — maar die datum staat al in case 93 en op de radar. Het dossier liep hier vóór op het nieuws, en dat is het beste soort lege regel. 🤖 Agentic payments: half leeg. De vondst was een cijfer dat de bronregel niet haalde; wat overbleef staat in het auditvonnis hierboven. 🔵 Secure Mail: niet aan de beurt — dat spoor loopt op maandag. Wel raakte de CRA-regel van vandaag het rechtstreeks, zie de juridische inbreng. DOORLOOP. De API antwoordde normaal: 47 items, waarvan nul op goedgekeurd. Er was dus niets te verwerken — 28 staan op uitgevoerd, 12 op beantwoord, 5 op afgevoerd, 2 op afgevinkt. CLAIMS-CHECK. Schoon. Twaalf treffers op de verboden woorden, alle twaalf nagelezen: ze beschrijven allemaal een derde partij (een anoniem adres, een anonieme bot, anonieme rekeningen onder de antiwitwasverordening) en niet één keer een claim over ons eigen product. Geen testaantal met een plus, geen streepje in de strategiematrix, geen suggestie dat R4M onder de AI Act valt. Zo zet je dit in de markt: niets. Deze regel is er zodat een lege lijn een reden draagt in plaats van te verdwijnen.
11-09💡 VOORSTEL — de kaartbodem stond in de code maar werd door geen enkele test bewezen — Het verdienmodel-tribunaal legde op 28-08 een bodem op: onder vijf euro weigert de motor een kaartbetaling, want ongeveer 28 cent kosten tegen 16 cent marge is verlies. Die regel werkt, maar werd nergens bewezen. De route weigert éérst wanneer er geen Stripe-sleutel is, en de bodemcheck staat daarachter — in de testomgeving is er nooit een sleutel, dus de code kwam er nooit. Twee van de vier tests stonden om precies die reden stil; de enige die altijd draaide, controleerde een rekensom op een constante in plaats van gedrag. Wie de bodem zou verplaatsen of uitschakelen, hield een groene suite. Het voorstel licht de beslissing uit de route in een netwerkvrije functie die exact hetzelfde antwoord geeft, en zet er vier tests op die altijd draaien: onder de bodem geweigerd met reden en ketenweg, precies erop mag door omdat de grens inclusief is, een cent eronder niet, erboven wel. Geen gedragswijziging: zelfde drempel, zelfde tekst, zelfde velden. Tak voorstel/2026-09-10-kaartbodem-bewijsbaar-v2, commit 3cb190c. Zo zet je dit in de markt: dit is het bewijsmateriaal achter de zin dat R4M nooit stil geld toelegt. Een klant die vraagt hoe je dat garandeert, krijgt geen belofte maar een test die elke run draait.
11-09⚠ AUDIT — de tak die gisteravond gered werd, draait het bronnenwerk terug als hij gemerged wordt — De tak voorstel/2026-09-10-kaartbodem-bewijsbaar is een momentopname van 13:31 en draagt behalve de kaartbodem-wijziging ook docs/BRONNEN.md en ops/audit-private/audits.json in de staat van vóór de bronnenronde van 23:58. Vandaag vergeleken met main: 108 regels verschil in de bronnentabel en 20 in het auditarchief, allemaal terugval. Wie die tak merget, wist de 45 nagelopen bronnen en drie auditvonnissen van gisteravond. Daarom is het voorstel opnieuw opgebouwd vanaf de huidige main, met uitsluitend de twee bestanden die er echt bij horen: 51 regels erbij, en op die schone tak is alles opnieuw nagemeten. De oude tak blijft staan zoals de regel voorschrijft, maar hij is geen merge-kandidaat. Zo zet je dit in de markt: niet naar buiten. Wat het je leert: een reddingsactie op een halve tak redt ook de achterstand die eraan vastzit, en een tak uit een onderbroken run hoort opnieuw opgebouwd te worden en niet gemerged.
11-09⚠ AUDIT — een herstelcommando van deze fase wiste ongecommit werk van een routine die tegelijk draaide — Om 00:44 stonden er zeven verse regels op de radar: vier van fase BOUWEN en drie van een routine die op hetzelfde moment in dezelfde map werkte. Bij het opruimen van wat een dubbel leek, is git checkout public/marktradar.html gebruikt. Dat herstelt naar de laatste commit, en die drie regels waren nog niet gecommit. Ze waren weg en git kon ze niet terughalen: ze stonden in geen enkele tak, geen reflog-ingang en geen los object. Goede afloop: het auditvonnis van die routine zat in cases-db.json en bleef ongeschonden, en de routine heeft zijn eigen regels intussen zelf teruggezet. Alleen daarom is er niets blijvend verloren. Zo zet je dit in de markt: niet naar buiten, dit is huiswerk. Wat het je leert: een gedeeld bestand is geen eigen bestand zodra er meer dan één routine in dezelfde map schrijft. Toevoegen mag altijd, terugdraaien nooit — en de vraag of iets een dubbel is, hoort beantwoord vóór je iets ongedaan maakt.
11-09🧪 TEST — 402 groen op de voorsteltak, vier meer dan main, en het getal geldt alleen op deze Mac — Gemeten op v0.36.7, 67 testbestanden, tak voorstel/2026-09-10-kaartbodem-bewijsbaar-v2. De vier erbij zijn de kaartbodem-tests. Twee blijven overgeslagen, en dat is een keuze: ze meten de échte Stripe-route met een echte sessie, wat alleen kan met een sleutel die de testomgeving niet heeft. De nuance komt uit het vonnis van vannacht: op een verse kloon zouden het er drie minder zijn, want drie tests lezen een privé-dossier dat niet in git zit. Verder nagemeten op de tak: typecheck groen, server boot, gezondheidscheck antwoordt met usdc-base op base-sepolia, en de demo loopt end-to-end door met de drie integriteitschecks groen — saldi gelijk aan wat geboekt is, gefinancierd gelijk aan gehouden plus betaald plus kosten, en niets betaald uit het niets. Herhaalbaar met npm test en npm run demo. Zo zet je dit in de markt: het aantal zegt niets — wat telt is dat de demo elke keer opnieuw bewijst dat er geen euro uit het niets komt. Dat is de zin die je in een pilootgesprek nodig hebt, en hij staat of valt met de eerlijkheid over waar het getal gemeten is.
11-09🚨 FUNDING — nog drie dagen voor Start it @KBC, en het is de enige harde datum die er nog staat — Vannacht om 00:35 zelf aan de bron nagekeken (startit-x.com/en/accelerate/start-it-kbc): de pagina toont "Application Deadline 14.09.2026" op drie plaatsen, ongewijzigd. Het bord is deze week twee deuren kwijtgeraakt — Base Batches 004 sloot op 09-09, en Eurostars Call 11 sloot gisteren om 14:00 CEST, waarna de volgende deur daar Call 12 op 4 maart 2027 is met dezelfde consortium-eis die hem voor ons onhaalbaar maakt. Wat overblijft binnen de week is deze ene: gratis, geen equity, geen partnerverplichting, solo indienbaar, twaalf maanden programma. De eerstvolgende harde datum daarna is imec.istart op 30-09, over negentien dagen. Het bord is bijgewerkt: dagteller op drie, controledatum op 11-09. Zo zet je dit in de markt: niets naar buiten, dit is een agendapunt. Maar het is het soort deadline dat je maar één keer per jaar mist: na 14-09 ligt er negentien dagen niets, en na 30-09 niets meer tot maart.
11-09⚠ AUDIT — drie tests lezen een bestand dat niet in git staat, dus ze slagen alleen op deze Mac — Gemeten vannacht om 00:36 in een wegwerp-werkkopie buiten de gewone werkmap, op de kaartbodem-tak: 399 groen, 3 rood, 2 overgeslagen, 404 in totaal. De drie rode staan alle drie in test/url-wacht.test.ts en falen alle drie met dezelfde fout: ENOENT: no such file or directory, open 'site/founder/funding/funding.json'. Nagegaan waarom: .gitignore sluit op regel 8 de volledige map site/ uit, dus dat bestand zit niet in de repository en heeft er nooit in gezeten. In de gewone werkmap slagen die drie wél, omdat het dossier daar toevallig op schijf staat. Dat maakt de "398 van 400 groen" van gisternacht niet onwaar, maar wel machine-gebonden: een verse kloon of een bouwserver haalt het niet. Niets aan gewijzigd — dit is een vondst, geen ingreep. Zo zet je dit in de markt: niets naar buiten. Intern is het de scherpste soort auditregel die er is — een test die alleen slaagt waar hij geschreven werd, meet de machine en niet de code. Jij beslist: de bewaakte URL-lijst naar een bestand dat wél in git zit, of die drie tests zichzelf laten overslaan als het dossier ontbreekt, zoals de Stripe-tests dat al doen zonder sleutel.
10-09🚨 AUDIT — de backup van de motor stond tien uur stil, en de oorzaak was de vorige fase zelf — Om 13:00 maakte fase BOUWEN de tak voorstel/2026-09-10-kaartbodem-bewijsbaar, maar zette de map daarna niet terug op main en duwde die tak nooit naar GitHub. Vanaf 16:05 sloeg r4m-autopush-ALARM.log zeven keer alarm, vier keer met "rebase-conflict" en om 19:26 met "GitHub is al 6 uur onbereikbaar". Allebei fout: GitHub was gewoon bereikbaar. De echte oorzaak is dat de tak geen upstream had, dus elke push faalde vóór hij begon. Vanavond om 23:44 nagemeten: origin/main is 015ae45 en gelijk aan de lokale main, dus de hoofdlijn stond wél veilig. Het enige onbeschermde werk was commit 95c4ea1 met de kaartbodem-wijziging in src/routes/stripePay.ts en test/kaartbodem.test.ts. Hersteld: de tak is gepusht mét upstream, de map staat terug op main, de werkboom is schoon. Zo zet je dit in de markt: niet naar buiten, dit is huiswerk. Wat het je wél leert: een alarm dat "netwerk" zegt kan een houding van je eigen routine zijn, en de stap "terug naar main" is geen netheid maar de backup zelf.
10-09⚠ AUDIT — zes vondsten van 05-09 stonden vijf dagen ín het script in plaats van op de radar — In marktradar.html waren zes blokken van 05-09 terechtgekomen binnen de JavaScript-sjabloon van het vragenvak, tussen de samenvatting van een concept-antwoord en de sluitende tag, in plaats van in het radarblok zelf. Gevolg: ze verschenen nergens op de radar, en werden in plaats daarvan herhaald binnen élk concept-antwoord van een V-vraag. Het gaat om de waarschuwing dat het antwoordformaat van de SEO-keten wijzigde, Didit dat de uniciteitscontrole gratis weggeeft, de VLAIO-correctie op het eigen bord, de funding-klok van die dag, het jargon-voorstel met 386 groen, en het ochtendrapport van 05-09 zelf. Vanavond teruggezet op hun eigen datumplaats in het archief: niets herschreven, niets weggegooid, alleen verplaatst. Zo zet je dit in de markt: dit is precies waarom de telling in het dagrapport bestaat — 295 blokken in het bestand is niet hetzelfde als 295 blokken die je kan zien.
10-09⏱ AUDIT — het ochtendrapport van 10-09 ontbrak, en is vanavond nageleverd — Fase RAPPORTEREN van 08:30 liet vandaag geen commit en geen rapport achter: het jongste rapport in de database was dat van 09-09. Ook de middagbriefing van 13:00 ontbreekt, terwijl het bouwwerk van die fase wél bestaat — er staat een tak en een commit. Vanavond is het rapport alsnog geschreven uit de commits en het dagrapport van deze nacht, met de badge NAGELEVERD, zodat er geen gat in de reeks blijft staan. Zo zet je dit in de markt: niets naar buiten. Wel de vaste les: een gemiste fase valt alleen op als een latere fase telt in plaats van aanneemt.
10-09💶 FUNDING — Eurostars Call 11 is dicht, en de volgende deur staat op 4 maart 2027 — Vanavond aan de bron gecontroleerd op eurekanetwork.org/programmes/eurostars/: de programmapagina toont nu alleen nog "Eurostars Deadline 4 March 2027 — Eurostars Call 12 for projects". Call 11, met deadline vandaag om 14:00 CEST, staat niet meer tussen de open oproepen. Dat sluit de onzekerheid van vanmiddag, toen drie bronmethodes de datum niet bevestigd kregen en de regel als verouderd werd gemarkeerd. Hardheid: hard, en verstreken. Call 12 is een harde datum op 175 dagen — geen urgentie, maar wel de eerste Eurostars-deur met genoeg tijd voor de consortium-eis die Call 11 structureel onhaalbaar maakte. Zo zet je dit in de markt: de openstaande vraag "mikken we op Call 12?" staat sinds 05-09 op het bord en heeft nu eindelijk een echte kalender onder zich: zes maanden om partners te zoeken in plaats van zes dagen.
10-09📅 FUNDING — het bord nagelopen: één harde datum overeind, en hij draagt geen nieuw feit — Start it @KBC blijft de enige harde sluiting binnen veertien dagen: 14-09-2026, over vier dagen, gratis, solo indienbaar, geen equity. Sinds de controle van vannacht 03:20 is er niets veranderd, dus de vlag wordt niet herhaald — hij staat er al. imec.istart staat op 30-09, twintig dagen, hard, herbevestigd vandaag. EIC Accelerator stap 1 blijft doorlopend met de volgende bundeling op 06-10 om 17:00: zacht, dus per definitie nooit urgent, en tegelijk de grootste som op het hele bord. Base Batches 004 is en blijft gesloten sinds 09-09. Zo zet je dit in de markt: één deur, vier dagen, en ze kost je geen aandeel. Alles wat op dit bord ná 14-09 komt geeft je meer tijd dan geld.
10-09🧪 TEST — motor v0.36.7 live én in de repo, kasboek sluit, geen drift om 23:44 — Vanavond read-only nagemeten. De live status geeft v0.36.7 op base-sepolia met adapter usdc-base; VERSION, package.json en de laatste git-tag zeggen alle drie 0.36.7, dus geen versiedrift. Het kasboek-endpoint geeft HTTP 200. Zes publieke checks staan op configured, waarvan er vier ook verified zijn: de app zelf, de eID-broker, de attestaties en het dubbel boekhouden. De adapter en de e-maillogin blijven bewust op niet gemeten — die pagina test ze niet, en dat hoort erbij. Attestaties: 2 uitgegeven, 0 live, 1 onderscheiden mens, en dat getal staat opnieuw stil. Herhaalbaar met curl -s https://r4m-franky.fly.dev/api/public/status. Zo zet je dit in de markt: je kan tegen een koper zeggen dat de geldweg end-to-end draait en dat het kasboek sluit, en je moet er meteen bij zeggen dat er één mens door heen is gegaan. Het eerste is een product, het tweede is precies waarom de eerste betalende klant zoveel waard is.
10-09🔎 BRONNENRONDE — 40 van de 45 bronnen leven, en twee adressen zijn verschoven — Vanavond is elke bron in de bronnentabel één keer gemeten, en elke afwijking conform regel 7 een tweede keer. Veertig geven 200. Vier afwijkingen, alle vier twee keer bevestigd. x402-proxy.t54.ai geeft 404 op de kale hostnaam — die bron werd vannacht pas aangelegd, en een API-proxy zonder pad hoort dat te doen, dus hij krijgt een waarschuwing en een pad in plaats van een doodverklaring. x402secure.com stuurt 307 naar de www-vorm; die vorm is overgenomen. nbb.be stuurt 302 naar de taalkiezer, zoals altijd. De Dune-query geeft twee keer 403 — hetzelfde beeld als op 05-09, en het auditvonnis van 06-09 blijft staan: één meting is geen toestand. Zo zet je dit in de markt: niets rechtstreeks. Wel dit: de bronnentabel is de enige plek waar een verhuizing zichtbaar wordt vóórdat het dossier achterloopt, en dat is exact waar x402 v2 twee maanden verloor.
10-09📊 SEO-VLOOT — negen domeinen vandaag gemeten, twee sprongen en één terugval — Opgehaald vanavond bij de seo-watch-meting van 21:44 UTC: twintig domeinen bewaakt, negen vandaag gemeten, zeven met beweging. Boombedrijf Bisschop springt +23 op Core Web Vitals naar 98, Turbeau2Rock +12 naar 84, idgs.eu en bks-nieuw elk +1. Channel Zero zakt −6 naar 65, met onsite ongewijzigd op 68. De keten leeft: de jongste meting is nul dagen oud, en de ketencheck van vanavond zet alle vijf de ketens op OK. Zo zet je dit in de markt: niets voor R4M — dit is de vlootregel, en hij staat er omdat deze keten op 9 juli stilviel en zeven weken lang niemand het merkte.
10-09📋 OCHTENDRAPPORT 10-09 (NAGELEVERD) — twaalf ketens dragen geld, en één plek vraagt wie er betaalt — Het rapport over het venster 09-09 08:30 → 10-09 08:30 staat nu op de Ops-tab. De kern: x402 telt sinds 09-09 twaalf ketenfamilies — Cardano kwam binnen met PR #2537, commit 42ee42b, 18.673 regels echte code. Het upto-scheme bestaat in twee van die twaalf, en de identiteitshaak in precies één: Solana. R4M draait base-sepolia, dus er verandert niets aan onze werking — wat verandert is de breedte van het gat. Het marktbewijs staat ernaast: t54 verwerkte op 05-09 bijna vier miljoen agentische transacties op XRP Ledger als vertrouwenslaag vóór settlement, op een keten die géén identiteitshaak heeft. Verder in het rapport: ledger-entry 29 (PandUniek) op PASS met een Belgisch prijsanker van €320 tot €500 per pand, de CRA-meldplicht die morgen begint, en 398 van 400 groen op de testsuite. Pijplijn: 56 prospects, 4 op benaderen, 0 gecontacteerd, 0 reacties. Zo zet je dit in de markt: de openingszin van de nacht ligt klaar — "x402 ondersteunt vandaag twaalf ketenfamilies; op precies één daarvan kan uw verkoper vragen wie er betaalt, en dan nog alleen in één modus. Wij hangen dat antwoord aan een Europese eID in plaats van aan een keten, zodat het op alle twaalf werkt."
10-09⚙️ PROTOCOLWACHT — de kernspec van x402 v2 telt 729 regels en het woord identity komt er nul keer in voor — Vannacht geteld in specs/x402-specification-v2.md op de hoofdtak (opgehaald 10-09-2026): identity 0 · person 0 · sybil 0 · KYC 0. Het woord human staat er vier keer en alle vier gaan ze over human-readable, dus leesbare tekst vóór een mens en niet het herkennen ván een mens. Unique één keer, over een nonce tegen herhaalaanvallen. Het woord extensions staat er tweeëntwintig keer. Wat dat betekent: het kernprotocol regelt geld en verder niets. Identiteit is er bewust buitengehouden en verplaatst naar een formele sleuf, het extensions-object in het 402-antwoord — met de expliciete regel dat een client extra informatie mag toevoegen zolang hij niets weggooit of overschrijft. De twee uitbreidingen die vandaag over identiteit gaan: auth-hints zegt woordelijk "authentication identifies the client, payment authorizes the transfer of value" en loopt over WWW-Authenticate, OAuth 2.0 en RFC 7591 (waarmee software zichzelf kan registreren). sign-in-with-x (CAIP-122) laat een client bewijzen dat hij een walletadres beheert, en beschrijft als doel dat de server "returning users" herkent en de betaling kan overslaan voor adressen die al eerder betaalden. Bij beide staat: de facilitator is niet betrokken. 💡 En daar zit de omkering die dit tot goed nieuws maakt. Een client is software en mag zich zelf aanmelden; een adres is een sleutelpaar dat je gratis en oneindig maakt. Geen van beide zegt dat er één mens achter zit. Sterker: een voordeel dat aan een adres hangt krijgt wie twee adressen heeft, twee keer — ons hele probleem staat daar niet als tekortkoming maar als eigenschap beschreven. Hoe méér halve identiteit het protocol inbouwt, hoe scherper de vraag wordt wie de mens is. Een protocol dat identiteit negeerde liet die vraag ongesteld; dit protocol stélt hem. Eerlijke grens: dit is een gemeten toestand van 10-09-2026, geen belofte dat een uitbreiding aanvaard zou worden. De spec staat vanaf nu onder bewaking. Zo zet je dit in de markt: je hoeft het gat niet meer te beweren, je kunt het aanwijzen in hun eigen spec. Openingszin: "Uw protocol laat een klant bewijzen dat hij een adres beheert, en slaat de betaling over voor adressen die al eerder betaalden. Wat gebeurt er met iemand die tien adressen heeft?" Actie, en die is niet van een routine: de bijdragegids van de specs beschrijft de route om zelf een uitbreiding voor te stellen (discussie openen, spec volgens sjabloon, pull request). Dat is een publieke stap met Franky’s naam eraan, en R4M staat nog niet in de etalage. De routine zet die stap dus niet; de vraag is of en wanneer Franky hem zet.
10-09⚙️ PROTOCOLWACHT — x402 draagt nu twaalf ketens, en één identiteitshaak — Vannacht zelf geteld in de bestandsboom van x402-foundation/x402 (git tree van main, opgehaald 10-09-2026 03:0x, bron: api.github.com/repos/x402-foundation/x402/git/trees/main): het protocol heeft twaalf ketenfamilies onder typescript/packages/mechanisms — aptos, avm, cardano, concordium, evm, hedera, keeta, near, stellar, svm, tvm, xrpl. Cardano is de jongste en kwam er gisteren bij: PR #2537, gemerged 09-09-2026 09:09 UTC, 18.673 toegevoegde regels over 99 bestanden, met een eigen npm-publicatieworkflow — dus echte code, geen documentatie. Maar het upto-scheme bestaat in slechts twee families (evm en svm), en de identiteitshaak resolveCallerIdentity zit uitsluitend in de SVM-variant. De EVM-nulstand is vannacht opnieuw gemeten: 0 treffers in een bestand van 134 regels, ongewijzigd sinds 07-09-2026. Reikwijdte, en die is beperkt: R4M draait base-sepolia met settlement-adapter usdc-base (nagekeken op r4m-franky.fly.dev/api/public/status, v0.36.7, 10-09 01:05 UTC). Cardano raakt onze keten dus niet, en de identiteitshaak evenmin — die ligt op Solana, waar wij niet draaien. Er verandert vannacht niets aan de werking van R4M. Wat het wél betekent: x402 groeit horizontaal op geld en niet op identiteit. Twaalf manieren om te betalen, één plek waar het protocol vraagt wie er betaalt, en die ene is een scheme-specifieke haak op één keten in één modus. Dat gat wordt met elke nieuwe keten breder, niet smaller. 🔌 Integratievorm: x402-resource. Wat al draait: onze attestatie-uitgifte en de verificatie-endpoint op fly.dev. Wat Franky bouwt: een facilitator-zijde controle die een R4M-attest naast de betaling aanvaardt, geschat 3 tot 5 dagen op base. Wat de klant doet: één veld toevoegen aan zijn 402-uitdaging. Standaard: x402 exact-scheme plus SD-JWT voor het attest. Kleinste demo zonder toestemming van wie dan ook: een eigen betaalde endpoint op base-sepolia die zonder R4M-attest 402 blijft geven. 🧩 Productmix: modules V (verificatie) en O (oproep) — de rail doet mee, want de betaling loopt er echt over. Landt op de trede van de betaalde machine-toegang. Groeipad: klein starten met het attest naast een bestaande x402-resource, de rail pas bijschakelen wanneer een klant echt settlement wil. Zo zet je dit in de markt: dit is een meetbare zin geworden in plaats van een mening. Openingszin: "x402 ondersteunt vandaag twaalf ketenfamilies. Op precies één daarvan kan uw verkoper vragen wie er betaalt, en dan nog alleen in één modus. Wij hangen dat antwoord aan een Europese eID in plaats van aan een keten, zodat het op alle twaalf werkt."
Ouder — eerdere vondsten (22-08 t/m 09-09)
10-09💸 x402 GELDLIJN — wie t54 is, wie erachter zit, en waarom je niet hun tweede wordt — Bijgewerkt 10-09-2026 met het bedrijfsdossier en een correctie op de eerste versie van dit item. De cijfers. Agentische transacties op de XRP Ledger stonden op 3.992.146 op 05-09-2026, tegenover 3,1 miljoen op 01-09 — ongeveer 890.000 in vier dagen. Betaald wordt in XRP en RLUSD, voor API’s en digitale diensten. Vier onafhankelijke berichten over hetzelfde t54-cijfer (u.today, coin-turk.com, thecurrencyanalytics.com, coinpaper.com, 05 t/m 08-09-2026). Wie het bedrijf is. t54 Labs, opgericht januari 2025. Oprichter Chandler Fang, voormalig ingenieur bij Ripple. 5 miljoen dollar seed, mede geleid door Anagram, PL Capital en Franklin Templeton (de laatste is een grote Amerikaanse vermogensbeheerder, geen cryptopartij), met deelname van Ripple, Virtuals Ventures, Blockchain Coinvestors en ABCDE. Producten: x402-secure, een open source vertrouwenslaag op x402, plus de XRPL-facilitator. Bron: theblock.co ("Ripple, Franklin Templeton join $5 million seed round for AI agent trust startup t54 Labs") en forbes.com (22-06-2026, "Inside t54, The Ripple-Backed Trust Layer"). ⚠️ WAT ZE ZEGGEN, TEGENOVER WAT ER IN HUN CODE STAAT — en dit is de scherpste zin van het hele item. In persberichten heet t54 een bedrijf dat identity, verification and compliance voor AI-agenten maakt. Hun eigen open source repo t54-labs/x402-secure draagt als omschrijving echter letterlijk "Risk layer for the x402 protocol", en hun motor heet Trustline, door henzelf beschreven als een agent-native risk engine. Volgens hun eigen README doet die vier dingen: redeneerketens van agenten analyseren, gekaapte agenten en prompt-injecties herkennen, cryptografisch bewijs van agent-gedrag leveren voor aansprakelijkheid, en audittrails bijhouden. Nergens in die vier staat een mens. Gemeten 10-09-2026 op api.github.com/repos/t54-labs/x402-secure (28 sterren, laatste push 30-08-2026, Apache 2.0, Python). Gebruik het zo: zeg niet plat dat zij geen identiteit doen, want hun marketing zegt van wel en dan sta je zwak. Zeg wat gemeten is — hun product scoort het gedrag van een agent — en vraag welk veld in hun uitvoer de mens benoemt. Dat veld bestaat niet, en de tegenpartij kan dat zelf nakijken in hun repo. (Deze passage verving om 04:2x een eerdere "correctie" die op de bedrijfsomschrijving afging in plaats van op de code, en daardoor te ver doorschoot. De repo-meting is de harde versie.) ⚔️ Soort competitie: raakvlak in één baan, geen nek. Wie: t54 Labs, achttien maanden oud, één oprichter, 5 miljoen seed — een gespecialiseerde nieuwkomer, geen reus. Waarom het ons niet nekt: zij identificeren de agent en toetsen of die mag wat hij doet. Zij zeggen niets over de mens erachter, en niets over of dezelfde mens er vandaag al vijftig keer was. Hun wortel ligt in hun eigen systeem en in een keten; de onze in een Europese eID. Waar het ons wél raakt: de vertrouwenslaag die tegen een facilitator aan hangt op het moment van settlement, op een cryptoketen. Daar zijn zij eerst, en daar hebben zij het volume. Waarom "tweede worden" hier de verkeerde vraag is. Dat geldt alleen als R4M hun spel op hun bord speelt. Hun bord is smal: XRP, RLUSD, facilitators — cryptorails. Ons bord is breder: in de catalogus dragen 197 cases een API-route, 88 een browser-extensie en 21 een MCP-route. En een deel van ons bord raakt geld niet eens aan: de Rail 1-cases (type Nationale Loterij, Ahold, Malt) hebben geen geldstroom, dus geen facilitator, dus geen t54. Van onze zes modules dekken zij er hooguit een halve: ze zitten in de buurt van V (Verify human), en dan nog voor agenten in plaats van mensen. C (capability card), P (PayLink), O (obligation + receipt), G (gate) en D (denylist op de persoon-root) raken ze niet aan. 🔌 Integratievorm: API-sleutel op hun facilitator-backend — één extra veld dat "uniek mens, gebonden aan een Europese eID-wortel" draagt, naast hun agent-identiteit. Wat al draait: attestatie-uitgifte en verificatie. Wat Franky bouwt: een aanroep die per betaling één attest-controle teruggeeft, twee tot drie dagen. Wat t54 doet: dat veld meenemen. Standaard: SD-JWT-attest over de x402-uitdaging. Kleinste demo zonder toestemming: op één voorbeeldbetaling het verschil tonen tussen "deze agent mag dit" en "achter deze agent staat één mens die we al geteld hebben". 🧩 Productmix: modules V en O, alleen de attestatiekant — de rail doet hier niet mee, want zij regelen het geld al. Landt op de trede van de aanvullende leverancier, niet de vervanger. Groeipad: attest als signaal, en pas als er een EU-klant met een uniciteitseis komt de rail erbij. Keuzevraag voor Franky, niet te gokken: prospect of partner? Zij zitten óók in het Agentic-programma van Mastercard Start Path (staat sinds 08-09 op deze radar), dus een gesprek kan via twee deuren lopen. Zo zet je dit in de markt: gebruik ze als bewijs dat het probleem echt is — wie Franklin Templeton en Ripple achter zich krijgt om precies deze laag te bouwen, bewijst dat de markt hem wil. Openingszin: "U identificeert de agent en toetst of die mag wat hij doet. Dat is de helft. De andere helft is of achter die agent één echte mens staat, en of dezelfde mens vandaag al vijftig keer langskwam. Wij hangen dat aan een Europese eID in plaats van aan een keten."
10-09💰 FUNDING — Eurostars valt vandaag van het bord, Start it @KBC blijft als enige harde datum over — Vier regels nagekeken in de nacht van 10-09. Eurostars Call 11 sluit vandaag 10-09-2026 om 14:00 CEST en is structureel onhaalbaar wegens de consortium-eis — die stond hier al als zachte melding en verdwijnt na vandaag van het bord; de vraag die openblijft is of we op Call 12 mikken. Start it @KBC sluit 14-09-2026, harde datum, nog vier dagen, gratis, geen equity, geen partnerverplichting en solo indienbaar — aan de bron nagekeken. imec.istart sluit 30-09-2026, harde datum, nog twintig dagen, met Spring 2027 als bevestigd vangnet. Base Batches 004 sloot gisteren 09-09 en blijft dicht. Waarom dit vandaag anders ligt dan gisteren: zolang Eurostars nog op het bord stond leek er keuze te zijn. Vanaf vanmiddag is er één haalbare deadline binnen de week, en dat is Start it @KBC met vier dagen. Dat is het nieuwe feit, niet de datum zelf. Zo zet je dit in de markt: niet extern — dit is een agenda-item. De actie is vandaag beslissen of Start it @KBC ingediend wordt, want na 14-09 is de eerstvolgende harde datum imec.istart op 30-09.
10-09⚖️ JURIDISCH — de CRA-meldplicht gaat morgen in, en een rondgaande tweede datum klopt niet — Nagekeken aan de bron van de Europese Commissie (digital-strategy.ec.europa.eu, pagina Cyber Resilience Act, opgehaald 10-09-2026): de meldplicht geldt as of 11 September 2026 en de hoofdverplichtingen from 11 December 2027. Dat is exact wat het dossier al draagt bij G17 — er wijzigt niets, en het wordt hier dus niet als nieuws gebracht maar als klok die morgen slaat. Vanaf morgen moeten fabrikanten actief misbruikte kwetsbaarheden en ernstige incidenten melden. Wat wél een correctie verdient: in de handelspers circuleert daarnaast een datum van "12 september 2026" voor ontwerpverplichtingen op nieuwe verbonden producten. Die staat niet op de bron van de Commissie. Wie hem overneemt, bouwt een deadline in die er niet is. Wij nemen hem niet over. Waar dit ons raakt: Secure Mail. De meldplicht is vanaf morgen een lopende verplichting en geen toekomstige, en dat verandert het gesprek met elke partij die een verbonden product verkoopt. Zo zet je dit in de markt: openingszin voor de IoT-lijn: "Sinds gisteren meldt u actief misbruikte kwetsbaarheden binnen de CRA-termijnen. De vraag die daarbij hoort en die zelden gesteld wordt: wie mag namens u die melding doen, en hoe bewijst u achteraf dat hij het was?"
10-09🩺 TEST — 398 van 400 groen, geen versiedrift, en de boekhouding sluit op vijf invarianten — Gemeten in de nacht van 10-09-2026 om 03:11 op een schone main van Rails4Mankind: 67 testbestanden, 398 tests groen, 2 overgeslagen, 0 rood, looptijd 7,57 seconden. Versie in de repo (VERSION, package.json en de laatste git-tag) is v0.36.7 en de live app op r4m-franky.fly.dev meldt eveneens v0.36.7 — geen versiedrift. De endpoint /api/public/reconciliation geeft HTTP 200 en alle vijf de invarianten sluiten: globale conservatie zonder onbalans, elke transactie in evenwicht, geen cache-drift, de audit-claim sluit op 1,76 dollar gefund tegenover 1,76 dollar aangehouden, en geen negatieve posities. Zelf herhalen: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test en curl -s https://r4m-franky.fly.dev/api/public/reconciliation.
10-09🔍 AUDIT — de claims-check is schoon, en de eigen methode kreeg een tik — De claims-check liep vannacht over de volledige cases-db.json. Uitkomst: schoon. De verboden formuleringen ("anoniem", "weggegooid", "structureel onmogelijk", "kan niet gelinkt worden") komen uitsluitend voor in beschrijvingen van andere systemen of in het blok dat ze zelf verbiedt. Nul testaantallen met een "+", nul formuleringen die suggereren dat R4M onder de AI Act valt. ◐ Deels — maar op de routine, niet op het dossier. Twee bijna-fouten van deze ronde, allebei op tijd gestopt en daarom hier genoteerd in plaats van weggelaten. (1) Het versienummer v0.37.2 in het archiefblok zag eruit als versiedrift tegenover de engine op v0.36.7. Het bleek de siteversie van maX te zijn, niet die van de engine. Twee verschillende versiereeksen die op elkaar lijken — nagekeken vóór het gemeld werd. (2) De zin "met één integratie een 27-landen-operator" in Zet 1 stond op het punt gemeld te worden als een claim zonder uniciteitsnuance. Twee alinea’s verder in hetzelfde blok staat die nuance woordelijk: "EUDI is ontworpen op unlinkability — elke lidstaat levert een pseudoniem dat per dienst verschilt … één integratie geeft ons dus 27 landen aan VERIFICATIE, maar uniciteit…". De claim is in orde en de ronde van 09-09 had gelijk. De les, en die is herbruikbaar: een claims-check die op zinsniveau leest, vindt fouten die er niet zijn. Lees het blok, niet de zin. Dat is dezelfde soort overschatting als de protocolvondst van 07-09, alleen in de andere richting.
10-09🤝 x401 EN DE LEGE SPOREN — wat vannacht niets opleverde, en waarom — Eerlijkheidsregel, want vullen mag niet en verzwijgen ook niet. x401: de bron github.com/proof/x401 staat stil sinds 01-07-2026 (laatste commit f739b0e, "docs: align README header names with current x401 spec"). Tien weken geen beweging op de spec. Dat is zelf een signaal: de agentische identiteitslaag verschuift naar de FIDO-werkgroep en naar AP2, weg van het losse protocol. Identificatie-cases: geen twee nieuwe. De aangetroffen kandidaten (Vinted, Upwork, Ticketmaster, Malt) staan allemaal al in het dossier, en geen ervan droeg vannacht een nieuwe gedateerde aanleiding. Nieuwe geld-case met een klant: leeg — de geldlijn van vannacht is een concurrent (t54), geen koper. Nieuwe use case: leeg. Nieuwe prospect: t54 is de enige kandidaat en de routine maakt geen prospects aan; Franky beslist of hij er een van maakt. Secure Mail: niet aan de beurt, dat spoor loopt op maandag. Sociale verkiezingen 2028: de referteperiode start over eenentwintig dagen op 01-10-2026 — staat er al sinds 08-09 en droeg vannacht geen nieuw feit, dus geen tweede entry.
09-09⚖️ JURIDISCH — FSMA is terug na vijf blinde avonden, en het antwoord is “Nihil” — De Belgische toezichthouder was van 4 tot 8 september onbereikbaar voor onze bronnenwacht. Vanavond gaf dezelfde pagina gewoon 200. Belangrijker dan het herstel is wat er staat. Beide registerlijsten — de vergunde CASP’s (art. 63) en de genotificeerde (art. 60) — dragen één woord: Nihil, met FSMA’s eigen stempel “Last verified date 04/09/2026”. FSMA voert dus nul Belgische crypto-dienstverleners onder eigen bevoegdheid. Beide pagina’s verwijzen zelf door: “The ESMA keeps a register of all crypto-asset service providers … including CASPs under the supervision of the National Bank of Belgium.” En ze leveren de bevoegdheidsverdeling erbij: sommige vergunninghouders die al onder prudentieel toezicht van de Nationale Bank staan, worden door de NBB gecontroleerd en niet door FSMA. Zo zet je dit in de markt: dit is de sluitende verklaring voor iets wat sinds 6 september als losse waarneming in het dossier hing — de enige met naam bekende Belgische CASP, BNY SA/NV (vergund 20-07-2026), staat bij de Nationale Bank en kan op geen enkele FSMA-lijst voorkomen. Voor R4M betekent het dat je bij een Belgische MiCA-vraag nooit naar FSMA moet wijzen voor namen, maar naar het ESMA-register, en FSMA gebruikt om te bepalen wie je gesprekspartner is. Dat scheelt een verkeerde deur bij elk gesprek met een crypto-partij. Bron: fsma.be/en/list/authorised-belgian-crypto-asset-service-providers en /en/list/belgian-crypto-asset-service-providers-who-have-notified-their-intention-provide-crypto-asset, gelezen 09-09-2026.
09-09🔍 AUDIT — vijf avonden een vonnis geveld over een bron die niet kapot was — Vonnis ◐ deels. Van 4 tot en met 8 september noteerde de bronnenwacht FSMA als onbereikbaar, en beschreef die waarneming elke avond uitvoeriger: DNS lost op, de TLS-handshake slaagt, het certificaat is geldig, het verzoek gaat volledig de deur uit, en dan nul bytes. Vanavond gaf dezelfde URL met dezelfde code op dezelfde machine 200 en 183.890 bytes. Er is aan onze kant niets veranderd. Deels en geen theater: de metingen werden echt gedaan, en de regel die verbiedt een bron dood te verklaren zonder 404 of 410 heeft gewerkt. Wat ontbrak was een tweede poging. Dat dit de fout is en niet het toeval, is vanavond hard aan te tonen: biometricupdate.com gaf bij poging 1 een timeout en bij poging 2, binnen dezelfde minuut met dezelfde code, gewoon 200. Met één poging had die bron nu ten onrechte als kapot in de tabel gestaan. Zo zet je dit in de markt: niet naar buiten, dit is huiswerk. De fix staat er al: regel 7 in de bronnendocumentatie zegt vanaf vanavond dat elke afwijking minstens één keer hermeten wordt vóór hij wordt opgeschreven. Dat je dit vonnis over je eigen routine leest in plaats van dat het wegpoetst, is precies waarvoor het auditspoor bestaat.
09-09📡 BRONNEN — de Nationale Bank ligt er vijf avonden uit, en verliest vanavond haar zwaarste argument — nbb.be geeft voor de vijfde avond op rij een Cloudflare-520, op zowel de hoofdvorm als de Nederlandstalige ingang. Vier avonden lang was de scherpste lezing dat beide Belgische toezichthouders tegelijk wegvielen — dat is een patroon en geen storing. Die gelijktijdigheid is vanavond weg, want FSMA is hersteld en NBB niet. Dan hoort de zwaardere conclusie ingetrokken te worden in plaats van stil te blijven staan, en dat gebeurt hierbij. In dezelfde minuut gaven fsma.be, het ESMA-register en efactuur.belgium.be alle drie 200, dus het ligt niet aan deze verbinding. Zo zet je dit in de markt: het praktische gevolg is vanavond klein geworden. FSMA verwijst nu zelf naar ESMA “inclusief de CASP’s onder toezicht van de Nationale Bank”, dus de NBB-kant is leesbaar zonder dat nbb.be overeind staat. De MiCA-dubbelcontrole die vijf avonden als onuitvoerbaar genoteerd stond, kan vanaf vanavond gewoon weer.
09-09🔔 AUDIT — je alarmkanaal staat niet stuk, het staat uit — en nu weten we dat zeker — Gisteren stond hier dat de pushmeldingen van deze routine je telefoon al vijf runs niet bereiken, met het vonnis "theater". Vandaag is er een feit bij: de melding van vanmiddag gaf letterlijk Mobile push not sent (Remote Control inactive) terug. Wat dat betekent. Het kanaal is niet kapot en de berichten gaan niet verloren onderweg — Remote Control staat uit, en dat is een schakelaar aan jouw kant. Vijf runs lang leek dit een bouwprobleem; het is een instelling. Wat er vandaag niet aankwam: dat Start it @KBC over vijf dagen sluit en de enige harde deadline op het bord is die je alleen kan halen. Zo zet je dit in de markt: niets — dit is huishouding. Maar zolang die schakelaar uit staat, is elke urgentie die deze routine vindt alleen zichtbaar als jij zelf de radar opent, en dat is precies het gat dat een alarm hoort te dichten.
09-09💰 FUNDING — Start it @KBC sluit over vijf dagen, en het is de enige harde datum die je alleen kan halen — Aan de bron nagekeken vandaag: startit.be/apply stuurt met een 301 door naar startit-x.com, en daar staat "Application Deadline 14.09.2026" met de aanvragen open voor Fall 2026. De pagina noemt het programma zelf gratis en "no strings attached": geen equity, geen partnerverplichting. Twaalf maanden, coaching en mentoren, negen Belgische hubs plus New York, Boedapest en Praag. Waarom dit de enige is. Er staan vandaag drie harde datums op het bord. Base Batches sloot vanmorgen. Eurostars sluit morgen maar eist een consortium dat niet bestaat. Deze eist niets wat je niet hebt: geen medeoprichter, geen buitenlandse partner, geen co-financiering. Wat het kost is één avond schrijven. Zo zet je dit in de markt: het dossier dat je hiervoor schrijft dekt grotendeels ook imec.istart, dat op 30 september sluit — schrijf het dus één keer goed en dien het twee keer in.
09-09⏳ FUNDING — Eurostars sluit morgen om 14:00, en krijgt met opzet géén alarmvlag — Eurostars Call 11 sluit 10-09-2026 om 14:00 CEST. Hard, en binnen veertien dagen — volgens de letter van onze eigen vlagregel hoort daar een alarm op. Er staat er geen, en dat is een keuze. De reden. Eurostars is per constructie een consortium-programma: je hebt een internationaal samenwerkingsproject nodig met minstens één ander Eurostars-land. R4M is vandaag één mens. De deadline is niet krap, hij is niet van toepassing — er is niets dat morgen ingediend kán worden. Een vlag die naar een gesloten deur wijst, leert je de vlaggen negeren; dat is exact wat eind augustus met de EIC-bundeling gebeurde. Bron, eerlijk. De Eureka-pagina zelf gaf 403 op een directe ophaling. De datum is daarom langs twee onafhankelijke wegen bevestigd, waaronder Vinnova, de Zweedse nationale Eurostars-instantie, die letterlijk "10 Sep 2026 at 14:00" toont. Zo zet je dit in de markt: de vraag die hier echt ligt is niet morgen maar Call 12 — wil je die, dan begint het zoeken naar een buitenlandse partner deze maand, niet in de week van de volgende deadline.
09-09📋 FUNDING — vijf regels aan de bron nagekeken, en het bord ziet er anders uit dan gisteren — Ronde van vandaag, elk aan de bron zelf: imec.istart bevestigt de open call 1 t/m 30 september (middernacht) voor de Belgische najaarsbatch — nog 21 dagen, hard, maar buiten de veertiendagengrens dus zonder vlag. Circle Developer Grants ongewijzigd: geen sluitingsdatum, geen gesloten-melding, en "Agentic economic activity" staat nog steeds als eerste van de zes prioriteiten. Base Batches 004 is vanmorgen gesloten en de vlag is eraf. Start it @KBC en Eurostars staan hierboven apart. Wat opvalt. Circle staat nu negen weken op "aanvragen deze week" zonder dat er iets vertrok. Dat is geen bronprobleem meer — de bron is elke keer bereikbaar en elke keer hetzelfde. Zo zet je dit in de markt: de beste fit op het hele bord is de enige waar niets gebeurt; dat is een keuze die je maakt of laat, niet iets dat de routine voor je kan oplossen.
09-09🔎 AUDIT — de leeftijdspoort had een publieke klok-override, en één query-parameter opende hem — De poort rust op een omkering: wie geen leeftijdsbewijs levert, is standaard beschermd en krijgt binnen het venster dat de afnemer zelf vastlegde een weigering. Maar de poort aanvaardde ook een publieke, ongeauthenticeerde parameter die de klok verzette waarop ze beslist. Bedoeld als demo-hulpmiddel, zonder enige beperking ervoor: geen sleutel, geen omgevingsvlag, geen grens tussen een lokale doos en een echte uitrol. Gemeten, niet gelezen. Tegen de ongewijzigde code, met de Fly-omgevingsvlag gezet zoals op de echte server: een bezoeker zonder attest kreeg besluit TOKEN met een token dat er precies uitzag als een echte. Waarom dit "deels" is en geen theater. De rest van de poort doet wél wat ze belooft: het verzegelde logboek klopt, een attest van een andere afnemer wordt geweigerd, een attest met de verkeerde claim ook. Eén been was mis, niet het geheel. Zo zet je dit in de markt: dit is precies het soort vondst dat de auditpagina geloofwaardig maakt — een klant die ziet dat je je eigen poort openbreekt en het publiceert, gelooft de rest van je claims sneller.
09-09💡 VOORSTEL — tak voorstel/2026-09-09-testklok-poort ligt klaar, niet gemerged — De fix voor de klok-override staat op een aparte tak en wacht op je oordeel. Twee wijzigingen. Eén: een gehoste uitrol weigert de testklok met een 403 en een eerlijke reden, tenzij die uitrol hem uitdrukkelijk openzet met GATE_TEST_CLOCK=true. De maat is de Fly-vlag en niet NODE_ENV, want Fly zet die niet — die val stond al beschreven in de motorcode en is hier voor de tweede keer relevant. Lokaal verandert er niets, dus de demo-pagina en de testsuite blijven werken. Twee: een token dat op de testklok berust heet nu gate_TEST_ in plaats van gate_. De afdwinging gebeurt server-side bij de afnemer, en daar mocht een demo-pas nooit dezelfde vorm hebben als een echte. Wat de tests aantoonden: drie nieuwe tests falen op de oude code en slagen op de nieuwe; op de tak staan 404 tests groen tegenover 398 op main. Zo zet je dit in de markt: de poortdemo is je Meta-verhaal — die moet kunnen weerstaan dat iemand er met een parameter aan trekt, want dat is het eerste wat een technische koper probeert.
09-09🧪 TEST — 398 groen op main, 404 met het voorstel erbij, en geen versiedrift — Twee metingen, niet samengevouwen. Op main: 398 tests groen, 2 overgeslagen, 67 bestanden — onveranderd sinds vannacht. Op de voorsteltak van vanmiddag: 404 groen, 68 bestanden, want daar staan zes nieuwe tests op de leeftijdspoort. Die zes tellen pas mee voor main als jij de tak binnenhaalt. Typecheck schoon, server boot schoon, en de twaalfstaps-demo loopt volledig door met alle vijf de grootboek-invarianten groen: geld blijft behouden, elke transactie sluit op nul, saldi kloppen met de boekingen, en er wordt niets uit het niets betaald. Versies, twee bronnen apart gemeten: repo op 0.36.7 met git-tag v0.36.7, live r4m-franky.fly.dev op v0.36.7. Geen drift. Zelf na te rekenen: npm test in de motor-repo, en curl -s https://r4m-franky.fly.dev/api/public/status voor de live-kant. Zo zet je dit in de markt: "onze testsuite draait op elke wijziging en het versienummer op de site is hetzelfde als in de code" is een zin die je bij een aanbesteding kan hardmaken.
09-09📰 OCHTENDRAPPORT 09-09 — de nacht vond de deprecatie in onze eigen package.json, de ochtend vond dat de autorisatielaag al sinds april bezet is — Het volledige rapport staat op het Ops-blad. De nacht: negen radar-items plus een bijwerking van de IDScan-entry, tussen 03:04 en 03:30. De vondst is dat x402-express 1.2.0 en x402-fetch 1.2.0 — de twee pakketten waar de motor op draait — in een map liggen die legacy heet en zichzelf in hun README gedeprecieerd noemen, terwijl de levende lijn op 2.25.0 staat. De ochtend: de China-radar en de India-radar draaiden om 06:21 en 06:58 en legden zes kaarten neer die alleen op hun eigen blad stonden. Vier daarvan staan vanaf nu ook hier, want een vondst die de marktradar niet haalt bestaat voor jou niet. Geen backup-alarm in de laatste 24 uur en de ketencheck geeft groen op alle vijf de ketens. Zo zet je dit in de markt: de migratie naar de v2-lijn is het enige punt van vandaag dat een technische inkoper zelf kan zien zonder dat jij het hem vertelt — hij opent je package.json.
09-09🥊 COMPETITIE — de autorisatielaag is niet leeg: de FIDO Alliance nam AP2 over en zette twee werkgroepen op, met Mastercard en Visa in de voorzittersstoel — Dit is een correctie op ons eigen radarwerk. De entry van 31-08 noteerde de schenking van AP2 aan de FIDO Alliance; wat er niet bij stond is de structuur eromheen, en die is het echte nieuws. Op 28-04-2026 richtte FIDO twee technische werkgroepen op. De Agentic Authentication Technical Working Group behandelt hoe een mens handelingen aan een agent delegeert, met phishing-bestendige authenticatie; voorzitters CVS Health, Google en OpenAI, ondervoorzitters Amazon, Google en Okta. De Payments Technical Working Group schrijft de specificaties voor door agenten begonnen handel; voorzitters Mastercard en Visa. Google droeg AP2 over, Mastercard bracht zijn Verifiable Intent-raamwerk in. De zin die ertoe doet, uit hun eigen aankondiging: vertrouwen in agenten kan niet berusten op een eenmalige controle bij de delegatie, het moet met de handeling meereizen en een verifieerbaar spoor opleveren dat elke transactie terugbindt aan een echte, geverifieerde mens. Dat is niet ongeveer maar precies de stelling van R4M, opgeschreven door de alliantie die WebAuthn maakte. 🔌 Integratievorm: geen bouwwerk maar deelname — de werkgroepen staan open voor leden, en het aansluitpunt is de attestatie-oproep als extern signaal in hun delegatiemodel. Wat draait al: onze attestatiekant. Wat Franky bouwt: niets nieuws, wel een positiestuk van twee dagen. Kleinste demo zonder toestemming: een attest dat een AP2-mandaat terugbindt op een eID-gebonden mens. 🧩 Productmix: module V met O, attestatiekant, trede drie, groeipad naar de rail. Zo zet je dit in de markt: stop met verkopen dat de laag leeg is — dat is niet meer waar en een inkoper die het naslaat, vindt het. Verkoop dat de laag nu een eigenaar heeft die in zijn eigen aankondiging vraagt om precies wat jij hebt, en dat niemand in die werkgroepen de uniciteitsboekhouding op een persoon-root levert.
09-09💸 AGENTIC PAYMENTS — OSL AgentPay verpakt x402, AP2 en MPP in een laag erboven, en vraagt nergens wie de agent is — OSL Group (Hongkong, beursgenoteerd) kondigde op 07-08-2026 OSL AgentPay aan: betaalinfrastructuur voor AI-agenten over meerdere stablecoins, met acht kernvermogens waaronder nanobetalingen, nul gasgeld en verenigbaarheid met meerdere protocollen. Gedragen munten USDT, USDC, USDGO; gedragen protocollen x402, AP2 en MPP. De API stond vanaf diezelfde dag open. Forkast beschreef de zet twee dagen later als een splitsing van de betaalstapel: onderaan het protocol dat de transactie op de keten uitvoert, daarboven een afwikkelingslaag waar routering, ondertekening en nalevingsbeslissingen vallen vóórdat er een munt beweegt. In hun woorden: AgentPay beconcurreert x402 en AP2 niet, het verpakt ze. Cijfers: USDGO ging op 20-07-2026 over $1 miljard in omloop; OSL boekte over 2025 HK$534 miljoen kernbedrijfsinkomen bij HK$201,22 miljard handelsvolume. Wat er niet in staat: agent-identiteit, know your agent, mandaten, delegatie. Er staat hoe een betaling zijn weg vindt, niet wie de agent is die hem verstuurt, van wie hij de opdracht heeft, of binnen welke grenzen. 🔌 Integratievorm: x402-resource plus API-sleutel op hun afwikkelingslaag. (1) Wat draait al: onze attestatiekant op base-sepolia. (2) Wat Franky bouwt: een attest-veld in hun nalevingsbeslissing, drie tot vijf dagen. (3) Wat de klant doet: één call toevoegen vóór de routeringsbeslissing. (4) Standaard: x402 plus OIDC. (5) Kleinste demo zonder toestemming: een agent-betaling op testnet met een attest dat terugbindt op een eID-gebonden mens. 🧩 Productmix: module V met O, trede drie, de rail doet mee als groeipad; klein starten met alleen het attest. Zo zet je dit in de markt: openingszin — "Uw aankondiging beschrijft acht kernvermogens over routering, munten en gasgeld, en geen daarvan zegt wie de agent is die de betaling verstuurt of van wie hij de opdracht heeft. Wij leveren precies die laag, als extra veld in uw bestaande nalevingsbeslissing."
09-09🇮🇳 AGENTIC MANDAAT — NPCI maakt het machtigingsmandaat verplaatsbaar tussen apps én acquirers, terwijl UAP juist een centraal register bouwt — Aan de gebruikerskant: een lopende UPI AutoPay-machtiging mag van de ene app naar de andere zonder annuleren en opnieuw registreren, met alle actieve mandaten op één overzicht. Aan de handelaarskant, en dat is de zwaardere: betaaldienstverleners mogen hun bestand aan klantmandaten meenemen naar een andere acquirerende bank of betaalpoort zonder dat elke klant opnieuw tekent. Vandaag is een overstap van betaalpoort in de praktijk een heronderhandeling met het hele klantenbestand. Waarom dit ons spoor raakt: een mandaat dat losstaat van de app die hem uitgaf is dezelfde vorm als een attest dat meereist met de mens in plaats van te leven in het register van één partij. Het contrast is scherp: het Unified Agent Protocol lost agent-vertrouwen juist op met een centrale inschrijving bij NPCI. Twee bewegingen in dezelfde week, in tegengestelde richting, op dezelfde rail. Tweede feit, uit dezelfde ronde: de RBI hoeft de aansprakelijkheidsvraag niet meer te beantwoorden — FREE-AI (comité-rapport, 13-08-2025) legt de verantwoordelijkheid voor een beslissing bij de instelling die het model inzet, hoe autonoom het ook handelt. Dat verplaatst de koper: niet de agentbouwer, maar de bank of verzekeraar die hem inzet. ⚠ Bronvoorbehoud, eerlijk: de mandaatcijfers (ruwweg 1,8 miljard e-mandaattransacties in juli 2026 tegen 585 miljoen een jaar eerder) komen van Entrackr en Medianama, die onze ophaalpoging allebei met HTTP 403 weigerden — via de zoekindex gelezen, dus orde van grootte en geen geciteerd bronfeit. FREE-AI zelf staat achter een CAPTCHA op rbi.org.in en is niet aan de bron gelezen. Er is ook nog géén NPCI-publicatie of RBI-circulaire die de portabiliteit vastlegt. 🧩 Productmix: module V met D, attestatiekant, trede twee. Zo zet je dit in de markt: India is het enige land waar de aansprakelijkheid al bij de inzetter ligt. Dat maakt het gesprek daar korter: je verkoopt geen risico-bewustzijn, je verkoopt het bewijsmiddel bij een aansprakelijkheid die al bestaat.
09-09📊 SEO-VLOOT — negen van de negentien domeinen vandaag gemeten, channel-zero wint vijf klikken, en de zachte 404 op blackfuelwhiskey staat er nog — Cijfers uit /api/seo-watch, opgehaald vanochtend, niet uit het hoofd. channel-zero.be: 93 klikken tegen 88 gisteren, positie 7,9 ongewijzigd, mobiele snelheidsscore van 65 naar 71; canonical, schema, robots en sitemap blijven daar rood, al maanden. blackfuelwhiskey.com: onsite 89, en de realfourohfour-controle blijft falen — dat is exact de zachte 404 waar de crawl-budget-vondst van vannacht over gaat. idgs.eu: onsite 100, nul faalcontroles, 7 klikken op positie 32,2. boombedrijfbisschop.be: 16 klikken, onsite 84. turbeau2rock.com: 8 klikken op positie 15,8, gdpr open. qmtex.net: positie 1,9. Wat niet gemeten is, en dat hoort erbij: twee domeinen staan sinds 03-07 stil (hiddengarden.be en zijn buildvariant) en drie sinds 30-08 (plastimet, michiel-haverans, cobras-architects). Die keten viel op 9 juli al eens stil zonder dat iemand het zeven weken merkte, dus de lege regels staan hier expliciet. Zo zet je dit in de markt: niet extern — dit is de eigen vloot. De enige actie is de zachte 404 op blackfuelwhiskey, een half uur werk, en Google zegt nu woordelijk dat die pagina's je crawlbudget opeten dat gedeeld is over al zijn crawlers.
09-09⚠ ONDER DE LAT — het CRA-feit hangt voor de tweede dag op de radar en niet in het juridisch dossier, en de MiCA-dubbelcheck staat zes ronden stil — Een. De CRA-meldplicht gaat overmorgen in (vrijdag 11-09-2026) en het status-veld van bundel G17 is nog altijd leeg. Het feit staat op de radar, het dossier weet het niet. Deze fase mag dat veld alleen bijwerken na een goedgekeurd doorloop-item, en van de 47 items staan er nul op goedgekeurd. Dus het blijft hier staan tot jij het vrijgeeft. Tweede dag. Twee. De MiCA-dubbelcheck — het ESMA-register náást de FSMA-lijst — is voor de zesde ronde op rij niet uitgevoerd omdat FSMA onbereikbaar blijft. Die vaste controleregel bestaat omdat het toezicht in België verdeeld is en één register lezen op 29-08 tot een foute nul-conclusie leidde. Kies: een vervangende bron, of de regel uitdrukkelijk opschorten. Drie. Het alarmkanaal (PushNotification) antwoordt voor de zesde run met "Remote Control inactive". Vannacht was er niets pushwaardigs, dus het deed geen kwaad — maar de hele urgentie-machinerie hangt eraan. Vier. De voorstellenstapel staat nu 47 uur stil in plaats van 35: twintig takken op de remote, vijftien wachten, oudste van 28-08, laatste merge 07-09 om 08:50. Zo zet je dit in de markt: niet. Dit blok is er juist om te tonen wat de routine niet gedaan kreeg, zodat een gat niet stilletjes kan groeien.
09-09📊 SEO — Google herschreef de crawl-budget-regels: crawlcapaciteit is GEDEELD over al zijn crawlers, en soft-404's vreten ervan. Precies één van je zeven domeinen heeft dat probleem. — Nagelezen bij de bron zelf, niet bij het commentaar erop. Google schrijft nu woordelijk: "Every site starts with the same default, conservative crawl capacity limit", "the crawl capacity limit is shared across all crawlers. This means that high demand from one crawler can reduce the capacity available for others", en "soft 404 pages will continue to be crawled, and waste your budget". De pagina is bijgewerkt op 22-07-2026. Twee onafhankelijke waarnemers meldden dezelfde wijziging los van elkaar en geen van beiden verkoopt hier iets. Wat er niet in staat zijn cijfers over hoeveel een AI-crawler wegneemt; die vraag blijft open.
WAT DIT BIJ JOU RAAKT, GEMETEN VANNACHT. Eén domein: blackfuelwhiskey.com. Elk onbestaand pad geeft daar HTTP 200 in plaats van 404 — /oude-shop en /deze-bestaat-niet-x7 leveren allebei 23.125 bytes met status 200. Google blijft die URL's dus crawlen en dat kost budget. Het is ook de enige openstaande auto-check op dat domein; onsite staat op 89/100. De andere zes domeinen hebben dit niet.
WAT ER KLAARSTAAT. PR #6 op DS2036/BlackFuelWhiskey haalt de soft-404 weg: alleen de paden die de React-app écht bedient houden 200, elk ander pad krijgt dezelfde inhoud met status 404. Voor een bezoeker verandert er niets — zelfde bytes, zelfde pagina. Verwacht effect na de merge: onsite 89 → 94.
WAT IK NIET GETEST HEB, en lees dit voor je merget. De fix is niet draaiend nagemeten. wrangler dev bereikt die catch-all helemaal niet — de lokale asset-runtime vangt onbekende paden zelf af en geeft er al 404 op, ook met de ONgewijzigde code; geverifieerd met een debug-regel die lokaal nooit geraakt wordt. Een staging-worker is er niet (wrangler.staging.json heeft nog STAGING_DB_ID_HERE staan). Daarom een PR en geen uitrol. Terugdraaien is één git revert, één bestand, geen migratie.
Bronnen: developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget · github.com/DS2036/BlackFuelWhiskey/pull/6 — allebei opgehaald 09-09-2026.
09-09⚙️ PROTOCOLWACHT x402 — de twee pakketten waar onze motor op draait staan sinds april in een map die letterlijk legacy heet, en hun eigen README noemt ze gedeprecieerd — Vannacht gemeten aan de bron, niet aan het nieuws. package.json van Rails4Mankind hangt op x402-express ^1.2.0 en x402-fetch ^1.2.0; node_modules bevestigt dat allebei ook echt op 1.2.0 staan. Diezelfde twee pakketten liggen in de monorepo van x402-foundation in typescript/packages/legacy/, en de README daar opent woordelijk met: "Deprecated (v1). This npm package implements x402 v1. It is deprecated and will only receive security patches. Please migrate to v2 (@x402/fetch, @x402/evm, etc.)", met een migratiegids op docs.x402.org/guides/migration-v1-to-v2 (HTTP 200 nagekeken vannacht). DE DRIE METINGEN, ZOALS DE LEESREGEL VAN 07-09 VOORSCHRIJFT. (1) De juiste plek en datum. De verhuizing naar legacy/ gebeurde bij commit 1a79fea ("Development v2", 11-12-2025); de laatste keer dat er iets aan die README veranderde was b1176d3 ("remove legacy examples", 14-04-2026). Op npm is x402-fetch 1.2.0 gepubliceerd op 16-04-2026 en er is sindsdien niets meer uitgekomen: dist-tags.latest staat nog altijd op 1.2.0, bijna vijf maanden stil. De levende lijn heet nu @x402/core 2.25.0, gepubliceerd op 03-09-2026, en @x402/fetch 2.25.0 op 04-09-2026. (2) De reikwijdte — en die raakt ons wél. Dit gaat niet over één scheme of één keten: het gaat over de client- en serverbibliotheek zelf. De live motor draait op base-sepolia met adapter usdc-base (gemeten op r4m-franky.fly.dev/api/public/status, v0.36.7, vannacht 01:05 UTC), dus de EVM-kant is precies onze kant. (3) Spec of voorbeeld. Geen commentaarregel en geen voorbeeld: het is de gepubliceerde README van het pakket dat wij installeren, plus de mappenstructuur van de hoofdtak. WAT DIT NIET IS. Het is geen storing en geen beveiligingsgat vandaag. De pakketten zijn op npm niet formeel als deprecated gemarkeerd (het deprecated-veld op versie 1.2.0 is leeg), de motor draait, en 398 van de 400 tests staan groen. Wat het wél is: onze geldkant hangt aan een tak die alleen nog veiligheidspatches krijgt, terwijl de hoofdtak in negen maanden 28 versies verder is gegaan. WAAROM DIT DE KOP VAN DE NACHT IS. Dit is exact het gat waar x402 V2 twee maanden in viel: de spec verhuisde en niemand volgde de nieuwe plek. Toen kostte het twee maanden achterstand op papier. Nu staat het in de motor zelf. Zo zet je dit in de markt: je zet het er niet in — je repareert het eerst, want elke demo waarin een technische inkoper package.json opent, ziet nu een gedeprecieerde v1-afhankelijkheid en trekt daar zijn eigen conclusie over hoe vers de rest is. Omgekeerd is een migratie naar @x402/* binnen een week precies het soort feit dat je in een gesprek met de x402 Foundation of Coinbase Ventures op tafel legt. 🔌 Integratievorm — niet bij een klant maar bij ons: bibliotheekmigratie v1→v2. (1) Wat al draait: de volledige geldweg end-to-end op base-sepolia, dubbel boekhouden sluitend (alle vijf invarianten groen op /api/public/reconciliation, vannacht gemeten). (2) Wat Franky bouwt: x402-express→@x402/express en x402-fetch→@x402/fetch, met de migratiegids ernaast — schatting 1 tot 2 dagen voor de omzetting plus een dag om de 67 testbestanden opnieuw groen te krijgen. (3) Wat de klant doet: niets, dit zit volledig aan onze kant. (4) Welke standaard: x402 v2, zoals gepubliceerd door de x402 Foundation onder de Linux Foundation. (5) Kleinste demo zonder toestemming van wie dan ook: npm i @x402/fetch@2.25.0 in een aparte tak, één betaalde route heen en weer, en het testboek opnieuw draaien. 🧩 Productmix: raakt de rail (module O — obligation en bon) en niets van de attestatiekant; V, C, P, G en D blijven ongemoeid. Landt op trede 3, want dit is de laag waar de euro doorheen loopt. Groeipad: eerst migreren op testnet, dan pas de mainnet-configuratiestap, nooit allebei tegelijk. Bronnen: raw.githubusercontent.com/x402-foundation/x402/main/typescript/packages/legacy/x402-fetch/README.md · registry.npmjs.org/x402-fetch · registry.npmjs.org/@x402/core · api.github.com/repos/x402-foundation/x402/commits?path=typescript/packages/legacy/x402-fetch/package.json — alle vier opgehaald 09-09-2026 tussen 01:00 en 01:15 UTC.
09-09💵 GELD-CASE — een gloednieuw bedrijf in Vilnius betaalt mensen omdat ze mens zijn, en controleert bij het inschrijven precies niets — Bixberry (Vilnius, Litouwen; Chief Product Officer Egle Maldute) ging wereldwijd open in augustus 2026 en kondigde dat aan op 4 september 2026 via GlobeNewswire. Het model: mensen delen de ongebruikte capaciteit van hun thuisinternetverbinding zodat AI-systemen het echte web kunnen ophalen, en krijgen daarvoor betaald — uitbetaling vanaf $10, meer dan 5.000 cadeaubonnen (Amazon, Steam, Spotify, PlayStation, Visa prepaid), $2 welkomstbonus, beschikbaar in meer dan 180 landen. DE ZIN WAAR ALLES OM DRAAIT, woordelijk uit hun eigen persbericht: "Much of that web responds to what looks like a real person on a normal home connection rather than a data center, which is why real people's connections have become part of how AI stays current." De hele waarde die zij verkopen is dus: dit is een echte mens, geen datacenter. En twee alinea's verder staat, even woordelijk: "New signups can be done in seconds." Over identiteit, uniciteit of enige controle aan de mensenkant staat er niets. Wat ze wél controleren staat er expliciet bij: "The network only carries traffic for verified, legitimate businesses, vetted before any traffic flows through the system." DE WIG, IN ÉÉN ZIN. Ze verifiëren de koper en niet de mens — terwijl het de mens is die ze verkopen. DIT IS GEEN NIEUWE CASE, HET IS EEN LEVENDE KOPER VOOR EEN CASE DIE ER AL STAAT. Case 101 in de catalogus heet "De router verkoopt bandbreedte, de klant wordt gecontroleerd en de mens achter het IP-adres niet", staat op uitgewerkt, geldvorm LICENTIE, en draagt Oxylabs (óók Vilnius) als klant. Bixberry is dezelfde markt, dezelfde stad en hetzelfde gat, maar dan vijf dagen oud en dus nog vormbaar. Wie net gelanceerd is heeft nog geen legacy-inschrijvingen om achteraf te herverifiëren. WELKE METER LOOPT. Twee. M1 — verificatie: elke nieuwe deelnemer die via eID of itsme aan een persoon-root gebonden wordt, en die meter draagt de itsme-kost. M3 — settlement: elke uitbetaling die over een attest loopt. De M3-kant kan pas na PRIO B; de M1-kant kan NU, want dat is trede 2 en daar zitten alle acht verkoopdossiers al. 🔌 Integratievorm: API-sleutel op hun backend, één call in het inschrijfscherm. (1) Wat al draait: de attestatiekant staat en heeft zelf ondertekend (attestations.verified: true, gemeten vannacht), itsme/eID hangt aan de Signicat-sandbox met een bereikbaar OpenID-document. (2) Wat Franky bouwt: een inschrijf-eindpunt dat één persoon-root teruggeeft plus een "deze mens is al geteld"-antwoord — 3 tot 5 dagen, want de bouwstenen liggen er. (3) Wat de klant doet aan zijn kant: één HTTP-call tussen "e-mailadres ingevuld" en "account actief", plus een keuze wat te doen bij een dubbele mens. (4) Welke standaard: OIDC richting de eID-broker, ondertekende attestatie eruit. (5) Kleinste demo zonder hun toestemming: hun publieke inschrijfpagina naast een schermopname waarin dezelfde persoon-root twee keer wordt aangeboden en de tweede keer wordt geweigerd. 🧩 Productmix: V (is deze mens echt en uniek) als kern, met D (ban op de persoon-root in plaats van op één account) als directe uitbreiding zodra ze hun eerste fraudegolf zien. De rail doet nog niet mee — dit start als pure attestatie op trede 2. Groeipad: klein starten met alleen het uniciteitsantwoord bij inschrijving, en pas later, wanneer zij zelf naar per-mens-uitbetaling willen, de rail bijschakelen op trede 3. Zo zet je dit in de markt: Litouwen is deze week op drie manieren tegelijk in beeld — Bixberry lanceert er, Oxylabs zit er al in case 101, en het land koos net Procivis voor zijn nationale EUDI-wallet-zandbak (zie het Procivis-item hieronder). Dat is geen toeval maar een markt die op hetzelfde moment een identiteitsinfrastructuur krijgt én bedrijven heeft die hem nodig hebben. Concrete verkooproute: mail de CPO rechtstreeks, niet de algemene inbox. Openingszin: "Uw eigen aankondiging zegt dat het web reageert op wat eruitziet als een echt mens op een gewone thuisverbinding — en twee alinea's verder dat inschrijven in seconden gaat. Wij sluiten precies dat gat: één call bij inschrijving die zegt of er een unieke, met eID gebonden mens achter zit, zonder dat u één identiteitsdocument hoeft op te slaan." Bron: GlobeNewswire, "Bixberry Launches, Rewards People to Keep AI Connected to the Real World", 04-09-2026, globenewswire.com/news-release/2026/09/04/3356606/0/en/ — opgehaald 09-09-2026.
09-09🆔 IDENTIFICATIE + CONCURRENT — Microsoft bouwt leeftijd in Windows 11 zelf, en net als Apple en Google gelooft het gewoon wat je bij het aanzetten hebt ingetikt — Op 8 september 2026 kondigde Microsoft aan dat leeftijdscontrole rechtstreeks in het besturingssysteem komt, via de Windows Age API op Windows 11. Apps krijgen een leeftijdsband terug in plaats van een geboortedatum: onder 10, 10-12, 13-15, 16-17, en 18 of ouder. Uit Microsofts eigen ontwikkelaarsdocumentatie, woordelijk: "these APIs are designed for apps that need to comply with child safety regulations without requiring the app to collect, store, or process date of birth or other personally identifiable information" en "Apps use these signals to adapt content, features, or access controls based on a user's age and verified status – without needing to implement their own age verification system." Microsoft volgt hiermee het model dat Apple en Google al hanteren. WAAROM DIT HIER STAAT ALS CONCURRENT. Drie besturingssystemen bieden nu gratis een leeftijdssignaal aan elke app. Voor elke verkoper van leeftijdsverificatie is dat een bodem die wegvalt: waarom zou een app betalen voor wat het platform meelevert? Franky moet die naam kennen vóór een inkoper hem noemt. EN WAAROM HET R4M NIET NEKT — DE WEERLEGGING, IN DRIE STAPPEN. (1) Het is een verklaring, geen bewijs. De band komt uit wat er bij de registratie van het toestel is ingevuld. Wie 13 is en 18 intikt, is voor de API 18. (2) Het zegt niets over uniciteit. Een leeftijdsband op vijf toestellen is vijf keer "18 of ouder" en nul keer "dezelfde mens". Precies de vraag die een platform stelt bij dubbele accounts, meervoudige stemmen of dubbele uitbetalingen blijft onbeantwoord. (3) Het zegt niet eens dát er een mens is. Een agent die op een Windows-machine draait erft de band van de eigenaar. Het OS-signaal maakt het bot-probleem niet kleiner — het geeft de bot een leeftijd. DE ZIN OM TE ONTHOUDEN: Microsoft, Apple en Google beantwoorden "hoe oud zegt dit toestel te zijn". R4M beantwoordt "is dit één echte mens, en hebben we hem al geteld". Dat zijn geen concurrerende antwoorden op dezelfde vraag; het zijn antwoorden op twee verschillende vragen, en de tweede wordt duurder naarmate de eerste gratis wordt. 🔌 Integratievorm: OIDC-knop naast het OS-signaal, geen vervanging ervan. (1) Wat al draait: onze eID-koppeling en de ondertekende attestatie. (2) Wat Franky bouwt: niets nieuws — dit is positionering, geen bouwwerk. Hooguit een halve dag voor één blad in de Verkoopkit met deze drie weerleggingen. (3) Wat de klant doet: het OS-signaal gebruiken voor leeftijd, en onze call erbij voor uniciteit — twee signalen, twee vragen. (4) Welke standaard: OIDC richting de eID-broker. (5) Kleinste demo: één scherm waarop de Windows-leeftijdsband en het R4M-uniciteitsantwoord naast elkaar staan, met een tweede toestel dat dezelfde band en dezelfde persoon-root oplevert. 🧩 Productmix: V als kern, G (afgeschermde ruimte waar alleen bewezen mensen in mogen) als het over toegang gaat. Rail doet niet mee, trede 2. Groeipad: dit is verdedigingswerk voor de bestaande dossiers, geen nieuw dossier. Zo zet je dit in de markt: zet dit blad in de Verkoopkit vóór het eerstvolgende gesprek waarin leeftijd ter sprake komt, want de inkoper die dit deze week gelezen heeft gaat het noemen. Openingszin als hij het noemt: "Klopt, en gebruik het gerust — het is gratis en het werkt voor leeftijd. Het vertelt u alleen niet of de vijf accounts die 18-plus zeggen te zijn vijf mensen zijn of één." Bron: Biometric Update, "Microsoft launches Age API, following OS-level declared age range model", 08-09-2026, biometricupdate.com/202609/ — opgehaald 09-09-2026.
09-09🆔 IDENTIFICATIE + CONCURRENT — Procivis staat nu in de Franse EUDI-zandbak als uitgever én verifieerder, en won Litouwen via een overheidsopdracht — Op 7 september 2026 meldde Biometric Update dat Procivis (Zürich, dochter van het beursgenoteerde Orell Füssli) Frankrijk aan zijn EUDI-omgevingen toevoegde: "France Identité has listed Procivis One in its EUDIW Unfold Playground as both an issuer and verifier." Daarbovenop: Litouwen koos Procivis via een overheidsopdracht voor de nationale EUDI-wallet-zandbak, met een implementatie van twaalf maanden (State Digital Solutions Agency); Duitsland draait op hun zandbakinfrastructuur (SPRIND, Bundesdruckerei); in Zwitserland zijn ze aangesloten op de swiyu Public Beta en getest tegen de federale Beta Credential Service; en in de Verenigde Staten zijn ze geselecteerd door het Department of Homeland Security via het Silicon Valley Innovation Program. Co-CEO Andreas Freitag, woordelijk: "The EUDI Wallet only works if credentials cross borders and vendors." WAT ER ECHT STAAT EN WAT ER NIET STAAT. Wat er staat: één leverancier zit nu in de zandbak van vier landen tegelijk, met een overheidsopdracht als bewijs dat dit inkoopbaar is. Wat er niet staat: een datum. De regel die iedereen citeert — lidstaten moeten eind 2026 minstens één wallet aanbieden — wordt in dit artikel gegeven zonder artikelnummer, en de leveranciersblogs die een exacte dag noemen (6 december) doen dat zonder rechtsgrond erbij. Wij nemen die dag hier dus niet over. Wat vaststaat is het kwartaal, niet de dag; wie de dag nodig heeft, haalt hem uit de uitvoeringshandelingen zelf en niet uit een verkopersblog. DE WEERLEGGING — WAAROM DIT R4M NIET NEKT. Procivis bouwt de wallet: uitgeven en verifiëren van attributen die grenzen en leveranciers over gaan. Dat is de drager. R4M beantwoordt de vraag die geen enkele wallet stelt: is dit één mens, en is deze mens hier al geteld? Een wallet die netjes zegt "deze persoon is ouder dan 18 en woont in Frankrijk" kan niet zeggen of de organisatie deze persoon vorige week al uitbetaald heeft. Uniciteit-over-de-tijd is geen attribuut in een wallet; het is een boekhouding op een persoon-root. EN DE KANS DIE ERIN ZIT. Procivis is geen muur maar een gang. Vier nationale zandbakken betekent vier plekken waar een attestatielaag bovenop kan. En Litouwen is deze week de tweede keer dat het land opduikt — zie de Bixberry-case hierboven, óók Vilnius. Een land dat zijn wallet-zandbak aanbesteedt terwijl er lokale bedrijven zitten die uniciteit nodig hebben, is een land waar de twee kanten elkaar nog niet gevonden hebben. 🔌 Integratievorm: verifieerder-naast-verifieerder in een bestaande zandbak. (1) Wat al draait: onze eigen ondertekende attestatie plus de eID-koppeling. (2) Wat Franky bouwt: een OID4VP-verifieerderprofiel zodat R4M in dezelfde zandbak kan meedraaien — schatting 5 tot 8 dagen, en dit is de eerste bouwstap die R4M naast in plaats van tegenover de EUDI-lijn zet. (3) Wat de klant doet: R4M als extra verifieerder aanmelden in de zandbak waar hij al zit. (4) Welke standaard: OID4VP en SD-JWT, dezelfde familie waar x401 op aansluit. (5) Kleinste demo zonder toestemming: een testcredential uit de publieke Franse Unfold Playground presenteren aan onze eigen verifieerder en er een persoon-root uit halen. 🧩 Productmix: V plus D; rail doet niet mee, alleen de attestatiekant. Landt op trede 2, met trede 1 als variant voor een overheid die alles op eigen server wil. Groeipad: eerst meedraaien als verifieerder in één zandbak, pas daarna praten over uitbetaling. Keuzevraag voor Franky, niet door de routine te beslissen: ga je Procivis benaderen als partner (zij dragen, wij tellen) of als concurrent in dezelfde aanbestedingen? Die keuze bepaalt de toon van elk gesprek in de vier landen en hoort niet door een nachtroutine gemaakt te worden. Bron: Biometric Update, "Procivis expands EUDI footprint as Europe's wallet deadline approaches", 07-09-2026 — opgehaald 09-09-2026.
09-09🇺🇸 REGIO VS — de federale overheid schuift naar cryptografische identiteit, en er ligt een wetsvoorstel met een nummer — Biometric Update, 7 september 2026: AI-fraude versnelt de Amerikaanse verschuiving naar cryptografische digitale identiteit. De harde haken, elk met een naam en een nummer: NIST publiceerde de ontwerp-praktijkgids SP 1800-42A over mobiele rijbewijzen; het Amerikaanse ministerie van Financiën bracht in maart 2026 een rapport uit en bereidt richtsnoeren voor over verifieerbare credentials; in het Congres ligt H.R. 7270, de Stop Identity Fraud and Identity Theft Act of 2026. Meebewegend: de Financial Services Sector Coordinating Council en de Better Identity Coalition. DE CIJFERS, MET BRON. Amerikanen boven de 60 meldden in 2025 $7,7 miljard aan oplichtingsverlies. Een tweepartijencommissie telde meer dan 22.000 klachten voor $893 miljoen aan AI-gerelateerde schade. De FTC noteerde over 2025 een record van $15,9 miljard aan gemelde oplichting, 25% meer dan het jaar ervoor. Uit het rapport van Financiën, woordelijk: "Illicit actors cannot reengineer an identity, even if they use AI." DE KOPPELING DIE DIT ARTIKEL ZELF LEGT. Hetzelfde stuk noemt de Nexus-marktplaats met "more than 170 million scanned North American identity documents, including 153 million driver's licenses, 10 million identity cards, and 3 million travel documents" — dat is precies het dossier dat gisteren op deze radar kwam en dat vandaag zijn bevestiging kreeg (zie de bijgewerkte IDScan-entry van 08-09). Twee onafhankelijke bronnen, dezelfde aantallen. WAT DIT WAARD IS VOOR R4M — EERLIJK. Dit is geen verkoopbare deur vandaag en het zou oneerlijk zijn er een te van maken: R4M heeft geen Amerikaanse aanwezigheid, H.R. 7270 is een voorstel en geen wet, en SP 1800-42A is een ontwerp. Wat het wél is: het bewijs dat het argument dat R4M in Europa verkoopt — bewaar geen documenten, bewijs de mens — nu ook in Washington de officiële richting is. Dat is materiaal voor een investeerdersgesprek en voor de Verkoopkit, niet voor een mail naar een Amerikaanse overheidsdienst. 🔌 Integratievorm: geen — er is hier vandaag niets in te pluggen. Wie dit spoor ooit wil lopen doet dat via de route die al in het dossier staat: de tol wereldwijd verkopen via een partij die er al zit, en pas daarna de mensenpoort. 🧩 Productmix: niet van toepassing zolang er geen Amerikaanse entiteit is. Deur/vermijd/volg: VOLG — hercontroleer bij een stemming over H.R. 7270 of bij de definitieve versie van SP 1800-42A. Bron: Biometric Update, "AI fraud accelerates US' shift toward cryptographic digital identity", 07-09-2026 — opgehaald 09-09-2026.
09-09💰 FUNDING — Base Batches 004 is dicht, precies vandaag, na acht controles op rij — Vannacht om 01:20 UTC opnieuw aan de bron gecontroleerd op base.org/batches, en de tijdlijn staat er nu anders dan gisteren. Woordelijk: "Aug 19 Applications Open" en "Sep 9 Applications Closed". Vandaag is 9 september. De deur is dicht. Het programma zelf loopt gewoon door: virtueel van 21 september tot 15 november, Demo Day in New York op 17 november, en $100.000 uit het Base Ecosystem Fund voor de geselecteerde teams. WAT ER MET DE VLAG GEBEURT. Deze regel droeg sinds eind augustus de 🚨-vlag en is acht keer op rij aan de bron nagekeken — de laatste keer gisteren om 13:15. Dat was terecht: het wás een harde datum. Vanaf vandaag zakt hij van 🚨 URGENT naar gesloten, want een vlag op een deur die al dicht is, is precies de vlag die niemand meer leest. De routine weet niet of Franky ingediend heeft en vult dat ook niet in; dat is het enige wat hier vandaag nog te weten valt en het staat als eerste actie in het dagrapport. WAT ER OVERBLIJFT OP HET BORD, MET DE HARDHEIDSTOETS ERBIJ. Eurostars Call 11 sluit morgen 10-09-2026 om 14:00 CEST — harde datum, maar niet haalbaar solo, want er is geen consortium; Call 12 op 4 maart 2027 is de echte deur en daar is tijd voor. Start it @KBC sluit 14-09-2026, maar is op 05-09 bewust geparkeerd door Franky en geeft geen geld. imec.istart sluit 30-09-2026 om middernacht, harde datum, nog 21 dagen, €100.000 converteerbare lening — dat is vanaf nu de enige harde datum op het bord met een echte kans erachter, en hij komt op 16 september binnen de veertiendagengrens. EIC Accelerator blijft doorlopend met een zachte maandelijkse bundeling op di 06-10 om 17:00; dat is en blijft geen vlag. GEEN PUSHMELDING VOOR DIT ITEM. Een gesloten deur is geen urgentie. En de meldingsketen zelf ligt sinds minstens vijf runs plat (zie het auditvonnis van 08-09 op deze radar) — die staat als aparte blocker in het dagrapport. Bron: base.org/batches, opgehaald 09-09-2026 01:20 UTC.
09-09⚖️ JURIDISCH — de CRA-meldplicht wordt overmorgen echt: vanaf vrijdag 11 september moet een uitgebuit lek gemeld worden — Dit is geen nieuwe ontdekking en wordt hier ook niet als nieuws gebracht: de datum staat al als vaste stand in de juridische radar (bundel G17). Wat er vandaag verandert is de kalender, niet de regel. Vanaf vrijdag 11 september 2026 treedt de meldfase van de Cyber Resilience Act in werking: fabrikanten van producten met digitale elementen moeten actief uitgebuite kwetsbaarheden en ernstige incidenten melden binnen de voorgeschreven termijnen, en die plicht geldt ook voor producten die al op de EU-markt staan. De volledige verplichting — security by design, technische documentatie, conformiteitsbeoordeling en CE-markering — volgt op 11 december 2027. WAAROM DIT ONS RAAKT. De meldplicht raakt Secure Mail en elk toekomstig product dat als "product met digitale elementen" op de markt komt. Zolang R4M een dienst is en geen product op de markt, is de plicht van vrijdag niet van toepassing; het moment waarop dat kantelt is het moment waarop Secure Mail als product verkocht wordt, en dat is een keuze die vóór die verkoop gemaakt moet worden en niet erna. WAT ER VANDAAG TE DOEN VALT: niets bouwen. Wel één ding vastleggen: wie ontvangt de melding als er ooit iets te melden valt, en binnen welke termijn. Dat is een half uur schrijfwerk en het is precies het soort ding dat pas urgent wordt op de dag dat het te laat is. Status van de bundel: ongewijzigd. Er is geen statuswijziging in G15 (AI Act — R4M valt buiten het toepassingsgebied), G17 (CRA) of G18 (Productaansprakelijkheid, vanaf 09-12-2026). De data zijn dezelfde als gisteren; alleen de afstand tot vrijdag is twee dagen geworden.
09-09⚙️ PROTOCOLWACHT x401 — zeventig dagen stil, en dat is zelf het bericht — Bron nagekeken vannacht: github.com/proof/x401, de laatste twintig commits. De jongste is f739b0e van 1 juli 2026: "docs: align README header names with current x401 spec (#33)". Daarvóór een dichte reeks in juni — de spec zelf (22 juni), de wijzigingen die Google, OpenAI en de FIDO-vertegenwoordiger van Okta vroegen (#15, 23 juni), en de conformiteit met de credman-richting (#31, 27 juni). Sindsdien: niets, zeventig dagen lang. DIT IS EEN GELDIGE UITKOMST, GEEN LEEG SPOOR. De regel schrijft voor dat "protocollen ongewijzigd" een echte uitkomst is als hij aan de bron gecontroleerd is. Dat is hier gebeurd. Maar zeventig dagen stilte op een spec waar in juni drie grote partijen nog wijzigingen in lieten aanbrengen, is zelf een signaal dat het bijhouden waard is: ofwel is de spec af en wacht hij op implementaties, ofwel is de aandacht verschoven naar AP2 en de kaartnetwerken. WAT DIT VOOR ONS BETEKENT. R4M positioneert zich x401-compatibel. Zolang de spec stilstaat, staat die belofte ook stil — er komt niets bij dat we moeten inhalen, en er valt ook niets te winnen door vroeg te zijn. Deur/vermijd/volg: VOLG, maandelijks in plaats van dagelijks, tot er weer een commit valt of tot een derde partij een implementatie aankondigt. Verandert dat, dan is het meteen de kop van die nacht. De buren, dezelfde ronde: geen versie- of specwijziging gevonden bij AP2, Visa TAP of Mastercard Agent Pay in deze ronde — alleen marketingmateriaal, en dat telt hier niet. Bron: api.github.com/repos/proof/x401/commits?per_page=12, opgehaald 09-09-2026.
09-09🩺 TEST — 398 van de 400 groen, geen versiedrift, en de boekhouding sluit op alle vijf de invarianten — Metingen van vannacht, elk met het commando dat je zelf kunt herhalen. Testsuite: 398 geslaagd, 2 overgeslagen, 0 gefaald, over 67 testbestanden, in 7,10 seconden. Tak: main. Commando: npm test in /Volumes/8TB MM4/Rails4Mankind. Read-only gedraaid; er is niets in die repo gewijzigd. Versie — twee bronnen, niet samengevouwen. REPO: VERSION = 0.36.7, package.json = 0.36.7, laatste git-tag = v0.36.7. LIVE: r4m-franky.fly.dev/api/public/status = v0.36.7. Geen versiedrift. Endpoints, letterlijk uit checks: app_live configured+verified (01:05 UTC) · settlement_adapter = usdc-base, configured, verified null (deze pagina meet dat niet) · email_login configured, verified null · itsme_eid configured+verified, omgeving sandbox, OpenID-document van de Signicat-broker bereikbaar en welgevormd · attestations configured+verified, realIssued 2 · double_entry_ledger configured+verified. Netwerk: base-sepolia, stage pilot. Uitgegeven attestaties: 2 in totaal, 0 live, 1 onderscheiden mens. Reconciliation bereikbaar en groen: /api/public/reconciliation geeft ok: true met alle vijf invarianten in orde — globale conservatie (onbalans $0), balans per transactie, cache gelijk aan afgeleide, auditclaim (gefinancierd $1,76 = aangehouden $1,76, verschil $0) en geen negatieve saldi. Commando: curl -s https://r4m-franky.fly.dev/api/public/reconciliation. Wat hier NIET gemeten is, en dat hoort erbij: of de eID-sleutels aanvaard worden bij een echte itsme-aanmelding (alleen het OpenID-document is opgehaald), of de mailprovider de verzendsleutel aanvaardt, en of de keten bereikbaar is voor de settlement-adapter — dat laatste vraagt /healthz?deep=1 en is vannacht niet gedraaid. upto-EVM, de vaste wacht sinds 07-09: nulstand bevestigd — typescript/packages/mechanisms/evm/src/upto/facilitator/scheme.ts telt 134 regels en 0 treffers op resolveCallerIdentity|authorizerSigner|delegatedAuthStore|receiverAuthorizer. Identiek aan de nulstand van 07-09. De identiteitshaak blijft dus uitsluitend op SVM/Solana.
08-09⚠ AUDIT — je alarmkanaal bereikt je telefoon al zeker vijf runs niet, en het stond nergens — Vanavond is de melding gewoon verstuurd om te zien wat er gebeurt. Antwoord: "Mobile push not sent (Remote Control inactive)". Dat is geen fout die iets stopt — de tool antwoordt netjes, de routine loopt door, en de urgentie belandt in een tekstbestand dat iemand moet openen. Daarna geteld: van de 101 auditvonnissen in het archief noemt er nul dit onderwerp. In de briefingmap staat het wél, in die van 6, 7 en 8 september, en die van 6 september noemt zichzelf al "derde run op rij" — er zijn dus minstens vijf mislukte meldingen op rij en de eerste ligt vóór 6 september. Het bericht dat vanmiddag niet aankwam was "Base Batches sluit morgen, beslis vandaag"; vanavond hetzelfde, met erbij dat dit de laatste avond is. Waarom dit een theater-vlag krijgt en geen opletten: de hele alarmmachinerie van deze routine loopt via dat ene kanaal — harde sluitingsdatum, concurrent op de verdien-kant, mislukte uitrol, theater-vlag: alles eindigt per ontwerp in een pushmelding. Levert dat kanaal niets af, dan is elke rode vlag sinds 6 september decoratie geweest. Wat wél werkte, is dat jij zelf de briefing opende. Dat is geen alarm, dat is een goede gewoonte. Zo zet je dit in de markt: niet naar buiten, en het is de belangrijkste regel van vanavond. Twee wegen, allebei founder-werk: Remote Control opnieuw koppelen, of een tweede kanaal kiezen dat wél aflevert. Zolang geen van beide gebeurt, ga er bij elke urgentie van uit dat ze alleen gelézen wordt en niet gemeld — en dat de eerste keer dat het echt telt, een nacht is waarin je de briefing niet opent.
08-09⏱ AUDIT — de voorstellenstapel stond 35 uur stil, en de tak die déze run zou helpen ligt erbij — Gisteren stond hier dat de stapel voor het eerst in beweging kwam: vier merges, één op 6 september om 18:14 en drie op 7 september om 08:49 en 08:50. Vanavond opnieuw geteld: sinds dat laatste merge-moment nul merges, dus 35 uur stil, terwijl er in dezelfde periode drie takken bijkwamen. De stand: twintig voorstel-takken op de remote, vijf in main, vijftien onbeslist, en de oudste is elf dagen oud (28 augustus, hash-bewijs-widget). De beweging van gisteren was een burst en geen tempo. Vanavond is het bovendien geen abstracte wachtrij meer: het uitrolbestand luistert nog altijd op élke push naar main zonder padfilter, de tak die dat precies dichtzet wacht als een van die vijftien, en deze ronde moest voor de tweede avond op rij haar eigen documentatiecommit met [skip ci] om die poort heen sturen. Nagemeten en niet aangenomen: telling uit git for-each-ref op de voorstel-takken, elk daarna met git merge-base --is-ancestor tegen main gehouden. Zo zet je dit in de markt: niet naar buiten — dit is een beslissing voor jou. Vijftien voorstellen wachten op één ja of nee, en zolang de uitrolpoort erbij ligt draait er elke run een handmatige workaround die alleen werkt zolang iedereen eraan denkt.
08-09⏱ AUDIT — de Europese wallet-documentatie verhuisde naar een eigen domein, en wij bewaakten alleen de versie — Tijdens de bronnenronde van vanavond gemeten: de documentatie-ingang van het Architecture and Reference Framework van de Europese identiteitswallet geeft een harde HTTP 301 van het oude github.io-adres naar eudi.dev. Dat nieuwe domein wordt geserveerd door GitHub Pages — te zien aan de antwoordkop server: GitHub.com — dus het is hetzelfde project onder een eigen naam, geen kopie en geen andere partij. De pagina noemt zichzelf de enige bron van waarheid en toont release v3.0.0 van 21 juli 2026. De reikwijdte, eerlijk gehouden: de inhoud is niet veranderd, want v3.0.0 van 21 juli stond al in de tabel, onze wacht loopt via de tags-API van dezelfde repo en die blijft 200 geven. Er is dus niets gebroken en de engine wordt niet geraakt. Waarom het toch telt: dit is exact het patroon waarin x402 V2 twee maanden onopgemerkt bleef — inhoud verhuist, de oude ingang blijft beleefd antwoorden. Onze tabel bewaakte het versienummer en niet het adres van de inhoud. Het nieuwe adres staat er vanavond in als aanwas; de oude ingang blijft staan met de aantekening dat hij omleidt. Zo zet je dit in de markt: geen verkoopargument, wel een houdbaarheidscontrole. Elke keer dat je in een pitch of dossier naar de ARF verwijst, gebruik voortaan het eigen domein — een verwijzing naar het oude adres is vandaag nog geldig maar leunt op een omleiding die ooit stopt.
08-09💰 FUNDING — Base Batches sluit morgen: negende controle, en de bron noemt zelf "agents" als doelsector — Vanavond om 19:1x opnieuw aan de bron gemeten, negende controle op rij. De tijdlijn is woordelijk 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", en de aanvraagknop staat vanavond nog op "Applications Open". Negen controles zonder één verschuiving betekent geen verlenging en geen stille sluiting. Het nieuwe feit van vanavond stond nog niet in de briefing van 13:00: de bron benoemt de gezochte sectoren letterlijk als "trading, payments, agents, financing, and asset issuance" — agents staat er dus met naam bij, naast betalingen. Dat is de enige toevoeging; de datum, de kosten (acht weken virtueel plus één reis naar New York op 17 november) en de vorm zijn onveranderd. Dit is de laatste avond waarop deze keuze bestaat. Zo zet je dit in de markt: dit is de laatste kans om te beslissen, niet om te bouwen. Zeg je ja, dan is de openingszin al geschreven: R4M is de identiteitslaag onder agent-betalingen op Base, draaiend op base-sepolia met een usdc-base-adapter, en "agents" staat in hun eigen sectorenlijst. Zeg je nee, dan is imec.istart (30 september) vanaf morgen de eerste regel met een klok erop.
08-09🧪 TEST — de boekhouding sluit vanavond op alle vijf de invarianten, en de EVM-nulstand is byte-voor-byte gelijk — Avondmeting op de draaiende rail. Het afstemmings-endpoint antwoordt 200 en meldt alle vijf de invarianten groen: globale conservatie sluit op nul, elke transactie sluit afzonderlijk, de saldocache klopt met het grootboek, gefund is gelijk aan vastgehouden plus uitbetaald plus kosten (1,76 dollar tegenover 1,76 dollar, verschil nul), en er staan geen negatieve saldi. Versie live v0.36.7, repo v0.36.7, netwerk base-sepolia, adapter usdc-base — geen versiedrift tussen dossier en app. De protocolwacht op de identiteitshaak in de EVM-tak van x402 blijft op nul: 134 regels, 4.452 bytes, nul treffers, identiek aan de meting van vanochtend en aan die van gisteravond. Ongewijzigd is hier de juiste uitkomst en geen leeg spoor. Zo zet je dit in de markt: dit is het cijfer dat je in een gesprek mag noemen zonder voorbehoud: de rail bewijst zijn eigen boekhouding uit de opgeslagen data alleen, herhaalbaar op een publiek endpoint. Wat je er niet bij mag zeggen is dat er echt geld doorheen ging — het staat op testnet, en 1,76 dollar is de omvang van het bewijs, niet van de omzet.
08-09🔎 BRONNEN — 33 bronnen gemeten, één echte verhuizing gevonden, twee toezichthouders blijven weg — De avondronde langs de bronnentabel: 33 metingen, 30 gezond met een 200. Eén echte vondst, de verhuizing van de wallet-documentatie naar een eigen domein — die staat hierboven als apart punt. Twee bekende gaten blijven staan en worden hier bewust als feit gemeld en niet opnieuw als alarm: de Belgische FSMA kapt voor de vijfde avond op rij de verbinding af zonder één byte terug te sturen, en de Nationale Bank geeft voor de vierde avond een 520. Beide zijn geen 404, dus geen van beide mag "dood" heten. Het vonnis van gisteravond sloot de reeks losse waarnemingen hierover expliciet af: het punt is gemaakt en vraagt nu een besluit, geen zesde meting. Het gevolg blijft wel elke dag doorlopen — de vaste controleregel van 29 augustus (leg het Europese ESMA-register altijd náást de Belgische lijst, nooit één van de twee alleen) is nu vijf dagen op rij onuitvoerbaar aan de Belgische kant. Ook herbevestigd: de kale ruimte-URL van de Europese wallet-wiki blijft 404 en de wiki-variant leidt nog steeds naar een inlogscherm — allebei al sinds 31 augustus als val genoteerd. Zo zet je dit in de markt: geen actie naar buiten. Eén ding om te onthouden voor een gesprek met een toezichthouder of een jurist: als je een MiCA-uitspraak doet, doe hem vandaag op het Europese register en zeg er eerlijk bij dat de Belgische kant al vijf dagen niet leesbaar is. Dat is sterker dan een cijfer waarvan je de helft niet kon nakijken.
08-09💡 VOORSTEL — het veld waarop wij meten of een protocolwijziging ons raakt, had nul tests — Tak voorstel/2026-09-08-reikwijdte-pin, commit e89b856, gepusht en NIET gemerged. Sinds de fout van 7 september geldt de regel: vóór je zegt dat een protocolwijziging ONS raakt, lees je twee velden uit de statuspagina van de app — op welke keten wij draaien, en welke settlement-adapter geladen is. Vandaag is nagegaan wat die regel waard is. Het eerste veld was gepind door een test. Het tweede kwam in de HELE broncode precies één keer voor, in het status-endpoint zelf, en had geen enkele test. Hernoemt iemand dat veld, dan antwoordt de app nog netjes 200, blijven alle tests groen, en verdwijnt de reikwijdte-toets stil — de fout van 7 september terug, maar dan onzichtbaar. Er zijn twee testgevallen bij gekomen die de VORM pinnen en niet de waarde: het veld bestaat en draagt een niet-lege naam, en die naam blijft leesbaar ook zonder treasury-sleutel, zodat "geen sleutel" niet gelezen wordt als "geen adapter". Het adapter-ID mag dus gewoon veranderen bij mainnet. Wat de tests aantoonden: de test is gesaboteerd om te zien of hij bijt — met het veld hernoemd faalden precies die twee nieuwe gevallen en geen enkele bestaande, daarna hersteld. Typecheck schoon, 400 groen tegenover 398 op de hoofdtak, demo end-to-end met de vijf boekhoudinvarianten groen. Alleen een testbestand geraakt, geen regel productiecode. Zo zet je dit in de markt: dit is precies het verschil dat een afnemer wil horen — R4M meet de reikwijdte van een protocolwijziging aan de eigen draaiende app in plaats van aan een persbericht, en pint dat meetpunt vast zodat het niet stil kan wegvallen.
08-09💰 FUNDING — acht controles op rij, nul feitwijzigingen, en de infosessie die de klok was valt vandaag — Vier regels vanmiddag om 13:15 aan de bron nagelopen; geen enkel feit is veranderd. Base Batches 004 draagt woordelijk dezelfde tijdlijn als de zeven vorige controles ("Sep 9 Applications Closed") — dat de aanvraag morgen sluit staat al op de radar van vannacht; wat hier nieuw is, is dat acht opeenvolgende controles nul verschuiving lieten zien, dus er is geen verlenging en geen stille sluiting geweest. imec.istart bevestigt "Sept 1 - Sept 30 (midnight)" met een actieve knop, nog 22 dagen, en het bedrag van 100.000 euro staat nog altijd NIET bij de bron. Circle Developer Grants is onveranderd open, zonder sluitingsdatum, met "Agentic economic activity" nog steeds als eerste prioriteit. Het enige nieuwe feit zit bij Start it @KBC: de online infosessie die dit dossier als de echte klok aanwees, staat op de bron voor VANDAAG 8 september, en passeert ongebruikt — dat is jouw parkeerbeslissing van 5 september, geen vergetelheid. De deadline zelf blijft 14 september. Zo zet je dit in de markt: geen actie nodig, wel één kalenderfeit — na morgen is Base weg en is imec.istart de eerste regel met een klok erop.
08-09⏱ AUDIT — de uurlijkse auditlog staat 68 dagen stil, en twee fasen lezen hem elke dag — De uurlijkse auditlog draagt precies één regel, van 2 juli 2026 om 05:23, met de baseline van toen: versie 0.3.0. Het bijbehorende momentopname-bestand heeft dezelfde datum en noemt nog steeds versietag 0.3.0, terwijl de rail vandaag op v0.36.7 draait. Dat is 68 dagen. Het venijn zit niet in een kapot bestand maar in een werkend bestand: de routine krijgt twee keer per dag de opdracht die log te lezen, het bestand ís er, dus die opdracht slaagt elke keer netjes — en levert elke keer een julimomentopname op. Er breekt niets, er alarmeert niets, en er komt al ruim twee maanden geen nieuw feit uit die bron. Dat is exact het patroon dat hier al twee keer misging: de SEO-keten viel stil op 9 juli en dat duurde zeven weken, de GDPR-monitor op 1 juni en dat duurde drie maanden. Geen van de 96 eerdere vonnissen in het archief noemt dit. Zo zet je dit in de markt: niet naar buiten — dit is een beslissing voor jou. Ofwel de uurlijkse meting weer laten draaien, ofwel de leesopdracht uit de routine halen. Een opdracht die slaagt en niets meet is de duurste vorm van stilte.
08-09◐ AUDIT — de tag-drift verbreedde gisteren en staat vandaag stil op dezelfde acht broncommits — De goede helft: repo en live zeggen allebei v0.36.7, dus tussen het dossier en de draaiende app zit géén drift, en dat is nagemeten. De andere helft: tussen de tag v0.36.7 en de huidige hoofdtak staan 56 commits, waarvan er 8 de broncode raken. Fly rolt bij elke push uit, dus de live app drááit die acht commits en noemt zich toch v0.36.7. Het versienummer zegt daarmee niet wat er draait — en dat nummer is precies wat een afnemer citeert als hij zegt welke versie hem iets bewees. Gisteravond luidde het vonnis dat de drift verbreedde van één naar acht. Vandaag staat hij op diezelfde acht: niet verder gegroeid, niet gesloten. Daarom draagt dit geen vlag maar een gewone regel. Hij sluit vanzelf bij de volgende release-tag. Zo zet je dit in de markt: nog niet — dit is precies het soort detail dat je zelf op orde wil hebben vóór een afnemer ernaar vraagt.
08-09🧪 TEST — 400 groen op de voorstel-tak tegenover 398 op de hoofdtak, en de demo loopt end-to-end door — Gemeten op 08-09-2026 om 13:10, read-only op de engine-repo, plus één voorstel-tak. Hoofdtak: 67 bestanden, 398 groen, 2 overgeslagen. Tak voorstel/2026-09-08-reikwijdte-pin: 400 groen, 2 overgeslagen, typecheck schoon. De demo is niet alleen gestart maar helemaal doorlopen tegen een echt draaiende server, en de vijf boekhoudinvarianten sluiten alle vijf: geld blijft behouden, elke transactie sommeert op nul, saldi komen overeen met wat geboekt is, gefund is gelijk aan gehouden plus uitbetaald plus kosten, en er is niets uit het niets betaald. Geen versiedrift tussen repo en live: beide v0.36.7. Herhaalbaar met: npm test en PORT=4021 npm run demo tegen een draaiende server in /Volumes/8TB MM4/Rails4Mankind. Zo zet je dit in de markt: de boekhoudinvarianten zijn het sterkste dat je op tafel kan leggen — niet "wij boeken correct" maar "draai zelf de demo en zie de vijf op nul sluiten".
08-09📰 OCHTENDRAPPORT 08-09 — de protocolwacht ving de tweede x402-wijziging in twee dagen — De nacht leverde veertien radar-items op, plus de SEO-vondst van 06:00. De kop: sinds gisteravond 20:02 UTC mag de verkoper in het batch-settlement-schema van x402 op EVM zelf een minimumdeposito eisen, met een standaardvermenigvuldiger van tien in de code. Het protocol legt het plafond bij de klant, en een autonome agent heeft er geen. Verder: OpenAI eist sinds 01-09 een overheids-ID en een hardware-passkey voor Trusted Access for Cyber, Authologic werd op 17-08 de eerste private uitgever van EU-wallet-attesten in Polen (niet-gekwalificeerd), en X betaalt sinds 02-09 zijn Amerikaanse makers met eigen geld uit terwijl “geverifieerd” daar betalend abonnee betekent. Twee lijnen bleven eerlijk leeg: x401 (69 dagen stil) en agentic payments (geen specwijziging deze week). App-status: 398 van 400 groen, versie 0.36.7 zonder drift, en nog altijd nul live attestaties. Zo zet je dit in de markt: de rode draad van vandaag is dat identiteitscontrole overal aan de toegangspoort staat en nergens aan de geldkant — gebruik die zin als opening bij OpenAI, bij X en bij elke agent-betaalpartij.
08-09⚠ ONDER DE LAT — het CRA-feit van vannacht hangt op de radar maar niet in het juridisch dossier — De nacht vond artikel 69(3) van de Cyber Resilience Act: de meldeisen gelden voor álle producten met digitale elementen die vóór 11-12-2027 op de markt zijn gebracht, ongeacht de uitlevering. Ons eigen standpunt in bundel G17 zegt dat de plicht pas ontstaat bij het op de markt brengen, en dat dekt die terugwerking niet. Het statusveld van G17 staat vandaag nog leeg. De rapportfase mag dat veld alleen bijwerken na een goedgekeurd doorloop-item, en die zijn er nul (47 items: 28 uitgevoerd, 12 beantwoord, 5 afgevoerd, 2 afgevinkt). Het feit staat dus wel op de radar en niet in het dossier zelf. De meldplicht start over drie dagen, op 11-09-2026; de boete loopt tot €15 miljoen of 2,5% van de wereldomzet (art. 64(2)). Zo zet je dit in de markt: zet G17 zelf recht vóór 11 september, want Secure Mail kan niet lanceren met een standpunt dat de terugwerking ontkent.
08-09🧪 TEST — de drie takken die jij gisterochtend mergede leverden tien testen op — Op 07-09 om 08:49 en 08:50 zijn drie voorstel-takken in main gegaan: codewoord-k1, installatiepakket en pas-stap-dicht-en-iban-uit. De testsuite van vannacht telt daardoor 398 groen van 400 (2 overgeslagen, 67 bestanden, 10,06 s) tegen 388 gisteren, zonder dat er vannacht code veranderde. Van de negentien voorstel-takken op de remote zitten er nu vijf in main en wachten er veertien, de oudste van 28-08. De stapel krimpt voor het eerst. Herhaalbaar commando: cd “/Volumes/8TB MM4/Rails4Mankind” && npm test en git branch -r --no-merged origin/main | grep -c voorstel/. Zo zet je dit in de markt: “elke merge levert meetbaar testdekking op” is het argument om de veertien resterende takken niet te laten liggen — en het is het enige punt van de gisteren-lijst dat vandaag als gedaan afgevinkt kan worden.
08-09📊 SEO-VLOOT — channel-zero wint twaalf klikken, de rest van de vloot staat stil — Acht sites gemeten op 08-09. Channel-zero.be gaat van 76 naar 88 klikken en van 2.302 naar 2.534 vertoningen op gemiddelde positie 7,9. Qmtex.net staat op positie 1,9 met 7 klikken, boombedrijfbisschop 17, turbeau2rock 9, blackfuelwhiskey 8, idgs.eu 7 en lowlands.business 1. Geen enkele onsite-score verschoof deze dag. Drie sites melden “cwv-mobiel-mislukt”: turbeau2rock, qmtex en gevelsteenbedrijf-v6. De keten zelf draait — de ketencheck geeft groen op alle vijf de ketens, met de SEO-meting van vandaag en de klantrapporten van gisteren. Zo zet je dit in de markt: één site die in een dag twaalf klikken wint terwijl de rest stilstaat is een demonstratiecase, geen toeval — kijk na wat daar veranderde vóór je de andere zeven aanraakt.
08-09📊 SEO — twee sites tonen geen favicon in Google, en dat is vandaag pas te controleren — Google heeft op 28-08-2026 in zijn eigen documentatie verduidelijkt welke bestandsformaten Search voor een favicon aanvaardt: BMP, GIF, ICO, PNG, JPEG, PPM en TIFF, vierkant, minstens 8x8 pixels en liefst groter dan 48x48. SVG staat er niet bij. Bron: developers.google.com/search/docs/appearance/favicon-in-search, genoteerd in het wijzigingenlog van Google Search Central. Daarop is de hele vloot met curl nagelopen, en twee van de zeven echte domeinen falen. lowlands.business draagt <link rel="icon" href="/favicon.ico"> maar die URL geeft HTTP 404 — er staat dus helemaal geen icoon. qmtex.net draagt alleen /assets/icons/favicon.svg; de apple-touch-icon.png die er ook staat draagt geen rel="icon" en telt niet mee. Vijf sites zijn in orde: idgs.eu, blackfuelwhiskey.com en channel-zero.be met ICO of PNG, turbeau2rock.com en gevelsteenbedrijf-v6 met een SVG maar met PNG's van 32 en 16 pixels ernaast, waar Google op terugvalt. Wat dit NIET is: geen rankingfactor. Een favicon verplaatst geen positie, hij bepaalt of je herkenbaar bent in de resultatenlijst. Die winst zit in klikgedrag en is met deze meetlat niet aan te tonen — dat wordt hier dus ook niet beweerd. Zo zet je dit in de markt: een klant die zijn eigen naam googelt en een leeg blokje ziet staan waar zijn logo hoort, ziet dat meteen. Het is de goedkoopste zichtbare verbetering die er is, en ze staat los van elke ranking-discussie.
08-09◐ AUDIT — het deployverbod op de engine is wél afdwingbaar, maar alleen met de hand; de backup-agent kent de rem niet — Gisteren stond hier een auditvondst met de strekking dat de routine zélf naar de hoofdtak van de engine pushte en daarmee Fly uitrolde, "precies wat het verbod verbiedt". Die vondst klopte in zijn waarneming en zat ernaast in zijn oorzaak. Vannacht is het mechanisme uitgemeten in plaats van afgeleid. MEETPUNT EEN — de uitrolworkflow heeft geen padfilter. .github/workflows/deploy.yml in /Volumes/8TB MM4/Rails4Mankind draait op on: push: branches: [main], punt. Geen paths, geen paths-ignore. Een commit die alleen docs/ of ops/ raakt, rolt dus even hard uit als een codewijziging: typecheck, flyctl deploy, app r4m-franky. MEETPUNT TWEE — er staat een tweede schrijver op die tak, en het is geen routine. De LaunchAgent com.r4m.autopush draait elke 1800 seconden het script ops/backup/git-autopush.sh, en dat script commit én pusht twee repo's, waarvan de eerste letterlijk /Volumes/8TB MM4/Rails4Mankind is. Het commentaar bovenaan zegt het zelf: "Commit alleen als er wijzigingen zijn; pusht met rebase". MEETPUNT DRIE — en dit corrigeert de kop die hier een half uur geleden stond. Er ís een rem, en een eerdere ronde had hem al gevonden: commit 52f4b34 van de avondronde van 07-09 draagt [skip ci] in zijn boodschap, en GitHub Actions slaat de workflow dan over. Deze radar-entry noemde het verbod eerst "niet afdwingbaar" en dat was te stellig — het is afdwingbaar, met één markering in de commitboodschap. Deze ronde heeft haar eigen commit daarop aangepast (e35ebd4) in plaats van de bewering te laten staan. WAT ER DAN WÉL OVERBLIJFT, en het is smaller maar echt. Het script git-autopush.sh commit op regel 67 met git commit -m "[auto-backup] $(ts)" — zonder [skip ci]. Zolang een routine haar eigen werk netjes commit met de markering, gebeurt er niets. Maar élk bestand dat ongecommit op die werkboom blijft liggen, wordt binnen een half uur door de backup opgepikt onder een boodschap die de rem niet draagt, en rolt dan uit naar Fly. De rem hangt dus aan de discipline van de schrijver, en de enige schrijver die geen discipline kán hebben is de backup zelf. WAT DEZE RONDE GEDAAN HEEFT. Het dagrapport, SIGNALS_ADAPT en de nieuwe ledger-entry zijn wel gecommit (commit 9ab882b) en niet gepusht. Committen is bewust: laat je de bestanden los rondslingeren, dan pakt de backup ze op onder een anonieme [auto-backup]-boodschap en verlies je het spoor van wie wat schreef. Niet pushen is even bewust: het verbod is letterlijk gevolgd. Maar wees eerlijk over het gevolg — de uitrol komt er hoe dan ook, alleen niet op naam van deze routine. DIT IS EEN BESLISSING VOOR FRANKY, geen bug om stil te repareren. Er zijn drie uitwegen en de routine mag er geen kiezen. (1) [skip ci] toevoegen aan de commitboodschap in git-autobackup regel 67 — één woord, en het gat is dicht; maar het raakt het backup-pad en dat is founder-werk. (2) Een paths-ignore op docs/** en ops/** in deploy.yml — lost het probleem structureel op in plaats van per commit. (3) Het verbod in de routine-opdracht herschrijven naar wat het in de praktijk is: "nooit code naar main, en markeer elke docs-push met skip ci", in plaats van het huidige "nooit naar main" dat in stap 4 van dezelfde opdracht meteen weer met "Push" wordt tegengesproken. Zo zet je dit in de markt: niet van toepassing — dit is intern. Maar het is wel het soort vondst dat de audit hoort te doen, en dan tweemaal: gisteren wees hij een dader aan, vannacht wees hij eerst het mechanisme aan en corrigeerde hij daarna zichzelf toen bleek dat de rem al bestond. Het vonnis zakt daarmee van ⚠ theater naar ◐ deels — er is een gat, maar het is één regel groot en het zit in de backup, niet in de routine. Gemeten 08-09-2026 03:35–03:45 met sed -n 1,40p .github/workflows/deploy.yml, plistlib op ~/Library/LaunchAgents/com.r4m.autopush.plist, grep -n "commit -m" ops/backup/git-autopush.sh en git log --oneline -2.
08-09⚙️ PROTOCOLWACHT x402 — de server mag vanaf gisteravond zelf bepalen hoeveel geld een agent vastzet, en hij vraagt standaard tien keer de prijs — Gisteravond om 20:02 UTC ging feat(ts): Add optional extra.minDeposit hint for EVM batch-settlement (PR #3372, commit 76fe973) op de hoofdtak van x402-foundation/x402, met de documentatie in #3398 twee minuten later. Wat er nieuw is, gemeten aan de +-regels van de patch zelf en niet aan de omliggende context: het 402-antwoord draagt nu een optioneel veld extra.minDeposit, "MUST be a positive integer >= amount". Daaronder zet de spec de gedragsregel erbij: "Clients SHOULD use a conforming extra.minDeposit as the deposit target, and SHOULD enforce a local maximum deposit so a 402 cannot lock unbounded escrow." De server-SDK zet bij afwezigheid van een eigen bodem DEFAULT_SERVER_MIN_DEPOSIT_MULTIPLIER = 10 — tien keer het te betalen bedrag. Er komt één foutcode bij, invalid_batch_settlement_evm_deposit_below_min_deposit, en de facilitator mag het veld uitdrukkelijk níét afdwingen. De README van de klantkant noemt het resultaat bij een klant zonder eigen plafond letterlijk "refundable but time-locked escrow"; de minimale wachttijd in dezelfde module staat op MIN_WITHDRAW_DELAY = 900 seconden. REIKWIJDTE — dit raakt ons wél. Het gaat om het batch-settlement-schema op EVM, niet om één keten of één modus buiten ons bereik. Onze engine draait vandaag network: base-sepolia met settlement_adapter: usdc-base, gemeten op r4m-franky.fly.dev/api/public/status om 03:12. Dit is dezelfde familie. SPEC OF VOORBEELD: spec én code. De regel staat in specs/schemes/batch-settlement/scheme_batch_settlement_evm.md én in de broncode van de EVM-module, niet in een uitgecommentarieerd voorbeeld. WAT MAX HIER AL OVER ZEGT. Het dossier draagt sinds eerder de juiste zin: "x402 heeft zélf géén escrow — de kern is pay-then-deliver, vasthouden bestaat alleen als uitbreiding (batch-settlement met on-chain escrow en off-chain vouchers)". Die zin blijft waar. Wat er níét in staat, en vanaf vandaag wel moet: de uitbreiding heeft nu een hefboom aan de kant van de verkoper om te bepalen hoe groot dat vastgezette bedrag is, met tien keer als stilzwijgende standaard. De woorden minDeposit en withdrawDelay komen in de hele public-map niet voor (gemeten 08-09-2026). WAT DIT VOOR R4M VERANDERT. Niets aan onze code vandaag — wij draaien geen batch-settlement. Wel aan het verhaal: het protocol legt het plafond bij de klant ("SHOULD enforce a local maximum"), en een autonome agent is precies de klant die zo'n plafond niet uit zichzelf heeft. De vraag "wie draagt het risico als een agent te veel vastzet" heeft nu een concrete, citeerbare vorm, en het antwoord van het protocol is: de agent zelf, vrijwillig. WAAROP FRANKY MOET ANTICIPEREN: zodra wij een mandatenblok aan een betalende agent hangen, hoort daar een uitgavenplafond ín het mandaat, niet ernaast. Dat is één regel in het attest en het is vandaag nog vrij terrein. Zo zet je dit in de markt: dit is de derde keer in vijf dagen dat x402 een knop toevoegt waarmee iemand ánders bepaalt wat een agent met geld doet. Gebruik het niet als schrikbeeld maar als bewijs dat het mandaat de ontbrekende laag is: "het protocol regelt hoeveel er vastgezet wordt, niemand regelt wie er achter de agent staat die het vastzet." Bron: commit 76fe973 · scheme_batch_settlement_evm.md (beide opgehaald 08-09-2026 03:10).
08-09🚨 DE BRON VAN HET GROOTSTE ID-LEK OOIT STAAT OP ONZE EIGEN PROSPECTLIJST — en dat maakt van een nieuwsbericht een verkoopargument — Op 1 september 2026 verscheen op het darkweb een doorzoekbare dienst genaamd Nexus met naar eigen zeggen meer dan 153 miljoen gescande rijbewijzen uit de Verenigde Staten en Canada, plus ruim 10 miljoen identiteitskaarten, ruim 3 miljoen reisdocumenten en minstens 579.000 medische kaarten. Niet alleen voor- en achterkant: ook infrarood- en ultravioletopnames van de documenten. Brian Krebs herleidde de bron naar IDScan.net (New Orleans), dat identiteitsverificatie levert aan onder meer Hertz, Target, FedEx, Motorola Solutions, Caesars Entertainment en Jack Henry. Het FBI-veldkantoor New Orleans opende dezelfde dag een onderzoek. IDScan.net heeft geen inbraak bevestigd en zegt niets te kunnen delen zolang het eigen onderzoek loopt. Nexus is intussen offline. WAAROM DIT HIER STAAT EN NIET IN EEN NIEUWSOVERZICHT. IDScan.net staat al in ons eigen dossier, als prospect, met de omschrijving "New Orleans, ID-verificatie voor retail, horeca en toegang in de VS — zelfde positie als Credence ID maar met een bredere klantenbasis". Onze eigen radar-entry stelde eerder voor om níét zelf een mDL-lezer te bouwen maar aan te sluiten bij wie die al verkoopt, met IDScan.net als voorbeeld. Dat voorstel is vandaag niet weg, maar het draait om: je sluit niet aan als leverancier van een extra laag, je stapt binnen als het antwoord op de vraag die hun raad van bestuur deze week stelt. DE WIG, IN ÉÉN ZIN. Wie documenten scant om mensen te herkennen, bouwt een schat die gestolen kan worden. Wie codes vergelijkt met codes, bouwt er geen. R4M houdt geen documentbeelden, geen infrarood, geen ultraviolet — het register bevat onomkeerbare codes, en er is niets in te doorzoeken dat een koper op het darkweb iets waard is. 🔌 Integratievorm: API-sleutel op hun backend, naast de bestaande scanlaag. Het opzetpad: (1) hun scanner blijft doen wat hij doet en beslist "geldig document, 21+"; (2) wij voegen één antwoord toe — "en dit is de eerste keer dat deze mens hier binnenkomt" — zonder dat het document bij ons langskomt; (3) Franky bouwt de koppellaag in circa 5 werkdagen op de bestaande attest-API; (4) standaard: OIDC voor de eID-kant, attest over HTTPS; (5) kleinste demo zonder hun toestemming: de bestaande proefpagina op r4m-franky.fly.dev met een Belgische eID, naast een screenshot van hun eigen productpagina. 🧩 Productmix: module V (verificatie) plus de attestatiekant; de rail doet hier niet mee, want er stroomt geen geld. Landt op trede 1. Groeipad: begin met het uniciteitsantwoord bovenop hun scan, en pas als zij zelf uitbetalingen gaan doen komt de rail erbij. Meter M1 bij elke nieuwe mens, M2 bij elke herhaling. Zo zet je dit in de markt: niet nu mailen. Een bedrijf midden in een FBI-onderzoek koopt niets en leest een verkoopmail als aasgierwerk. Wacht tot hun eigen verklaring er is, en gebruik de zaak intussen naamloos in élk ander gesprek: "in september kwamen 153 miljoen rijbewijsscans op het darkweb terecht — wij bewaren geen scans, dus dat lek kunnen wij niet hebben." Dat is de sterkste zin die onze architectuur dit jaar gekregen heeft, en hij komt niet van ons. Bron: Krebs on Security, 03-09-2026 · SecurityWeek · TIME, 03-09-2026. AANVULLING 09-09-2026 — IDScan.net heeft de inbraak nu wél bevestigd. Waar deze entry gisteren nog noteerde dat het bedrijf niets bevestigde, meldde Biometric Update op 8 september 2026 dat IDScan.net ongeoorloofde toegang tot één van zijn clouddatabases erkent. Uit de eigen verklaring, woordelijk: "An unauthorized third party may have accessed and/or copied certain customer information stored within their accounts on the IDScan.net cloud", en het gaat om "full names and driver's license or other government-issued identification numbers". Het bedrijf zegt de toegang op of rond 1 september 2026 te hebben vastgesteld, werkt samen met de federale opsporing en biedt gratis identiteitsbescherming en kredietbewaking aan. Onafhankelijke bevestiging van de aantallen kwam dezelfde week uit een tweede richting: het NIST/Treasury-stuk van 07-09 (zie het VS-item van vandaag) noemt exact "more than 170 million scanned North American identity documents, including 153 million driver's licenses, 10 million identity cards, and 3 million travel documents". WAT DIT VERANDERT VOOR DE VERKOOP: de zin uit deze entry stond gisteren nog op een niet-bevestigd incident en kon dus door een inkoper weggewuifd worden. Vanaf vandaag staat hij op een erkenning door het bedrijf zelf, en dat is het verschil tussen een gerucht en een precedent. Bron: Biometric Update, "IDScan confirms breach after 170M identity documents put up for sale", 08-09-2026 — opgehaald 09-09-2026.
08-09🆔 IDENTIFICATIE-CASE — sinds vorige week dinsdag moet je een overheids-ID tonen om bij het beste AI-model te mogen, en de zwaarste modellen zijn nu formeel mens-gebonden — Sinds 1 september 2026 moeten individuele leden van OpenAI's programma Trusted Access for Cyber Advanced Account Security aanzetten met een hardware-gebonden passkey, anders verliezen ze de toegang tot OpenAI's meest capabele cyber-modellen. Wie niet meedoet mag ChatGPT blijven gebruiken maar zakt terug naar gewone modeltoegang. De toelating zelf loopt over een identiteitscontrole die OpenAI omschrijft als "a government ID check, know-your-customer (KYC) identity checks, and additional trust signals such as device health", uitgevoerd via Persona. De aankondiging dateert van 14 juli 2026, de datum ging vorige week in. WAT HIER ÉCHT GEBEURT — en het is niet wat de kop suggereert. Dit is geen leeftijdscontrole en geen misbruikbestrijding. Dit is een AI-bedrijf dat een capaciteitsdrempel legt en die drempel bindt aan een natuurlijke persoon: eerst wordt een echte mens aan een account gekoppeld (identiteitsbewijs), daarna beschermt een fysieke sleutel dat account bij elke login. Twee lagen, en de eerste is precies het probleem waar wij aan werken. DE ASYMMETRIE, SCHERPER DAN OOIT. Om gevaarlijke capaciteit te krijgen moet je bewijzen dat je een echt mens bent. Om geld te ontvangen op vrijwel elk platform hoeft dat nog steeds niet. De markt heeft de mens-poort dus al gebouwd — alleen aan de verkeerde kant van de deur. WAT DIT VOOR ONS DOSSIER BETEKENT. De woorden "Trusted Access" komen in de hele public-map niet voor (gemeten 08-09-2026). maX kent OpenAI uitgebreid en kent Persona als leverancier, maar niet dit programma. Dit is nieuw materiaal voor de verkoopkit, geen herhaling. 🔌 Integratievorm: geen — OpenAI is hier geen klant maar een precedent. De integratievorm die telt is de OIDC-knop bij iedereen die je hiermee overtuigt. 🧩 Productmix: niet van toepassing als verkoop; wel als bewijsstuk in de kit bij module V. Zo zet je dit in de markt: dit is de dia die je vóór de prijs toont. "OpenAI vraagt sinds 1 september een overheids-ID plus een fysieke sleutel voordat je hun zwaarste model mag gebruiken. Uw platform betaalt mensen geld uit en vraagt een e-mailadres. Welke van die twee draagt het grootste risico?" Bron: Biometric Update, 14-07-2026 · Yubico · OpenAI, Trusted Access for Cyber.
08-09🆔 IDENTIFICATIE-CASE + 🥊 COMPETITIE — de eerste private uitgever van EU-wallet-attesten staat sinds 17 augustus in een centralebank-register, en zijn vergunning is de níet-gekwalificeerde — Authologic (Warschau, Polen) is door de Poolse centrale bank Narodowy Bank Polski opgenomen in het register van vertrouwensdiensten, met de dienst geregistreerd vanaf 17 augustus 2026. Daarmee is het het eerste bedrijf in Polen en een van de vroegste in Europa dat elektronische attesten van attributen mag uitgeven voor de EU Digital Identity Wallet. DE NUANCE DIE DE KOP BEPAALT — en die de meeste berichten weglaten. Het gaat om niet-gekwalificeerde elektronische attesten van attributen (EAA's). De registratie machtigt hen uitdrukkelijk niet tot gekwalificeerde EAA's: daarvoor is een conformiteitsbeoordeling nodig en val je onder het volledige eIDAS-toezicht. Wie schrijft dat "Authologic nu EUDI-attesten mag uitgeven" laat de helft weg die er juridisch toe doet. WIE DIT IS EN WAAROM HET ONS RAAKT. Dit is de dichtstbijzijnde buur die R4M dit jaar gekregen heeft: een private partij die verifieerde identiteitsgegevens verpakt tot herbruikbare digitale bewijsstukken voor wallets, met een speeltuin op eudi.authologic.com waar bedrijven uitgifte en verificatie kunnen testen. Dat is de attestatiekant van onze eigen stapel. WAAROM HET ONS NIET NEKT. Drie redenen, en ze zijn alle drie hard. (1) Een EAA zegt welk attribuut iemand heeft — leeftijd, diploma, rekeningnummer. Hij zegt niet dat deze mens er maar één is en niet al twee andere wallets heeft. Uniciteit over accounts heen is geen attribuut, het is een relatie, en die zit in geen enkele EAA. (2) Niet-gekwalificeerd betekent geen wettelijk vermoeden van correctheid: een afnemer die er iets zwaars op bouwt draagt zelf het bewijsrisico. (3) Zij zitten aan de uitgiftekant en niet aan de geldkant — er stroomt geen euro over een EAA. WAAR HET ONS WÉL RAAKT. Als de EUDI-wallets eind 2026 uitrollen, wordt "wij geven attesten uit" een verzadigde zin. Onze zin moet dan al de andere zijn: "wij garanderen dat er achter dit attest één mens zit, en maar één." Dat verschil moet nú in de kit staan, niet in december. NIEUW VOOR HET DOSSIER: "Authologic" en "Narodowy" komen nergens in de public-map voor (gemeten 08-09-2026). Zo zet je dit in de markt: zet Authologic in de verkoopkit als het bewijs dat de markt bestaat, niet als bedreiging. "Er staat sinds augustus een privaat bedrijf in een centralebank-register om wallet-attesten uit te geven. Dat betekent dat de laag waar wij op zitten geen theorie meer is. En het betekent dat u nu moet kiezen of u een attest koopt of een garantie." Bron: Biometric Update, september 2026 · ID Tech Wire, 02-09-2026.
08-09💶 AANVULLING op de geld-case van 01-09 — X betaalt sinds 2 september met eigen geld uit, en het programma is vandaag écht begonnen — De geld-case "X betaalt per unieke impressie en telt abonnementen" staat sinds 01-09 op deze radar. Hij wordt niet herhaald maar bijgewerkt, met twee feiten die er toen niet in stonden. EEN — de uitbetaler is veranderd. Sinds 2 september 2026 lopen alle Amerikaanse makersuitbetalingen niet meer via Stripe maar via X's eigen dienst X Money, zowel voor Original Content Rewards als voor abonnementen. Weg is de tweewekelijkse Stripe-overschrijving met een drempel van 30 dollar; ervoor in de plaats komt directe afwikkeling, "the moment they are sent". Makers buiten de VS blijven op Stripe. Dat betekent dat X het uitbetalingsrisico dat vroeger bij een betaaldienstverlener lag, nu zelf draagt. TWEE — de toelatingsdrempels staan nu bij de bron. Om mee te doen: een actief Premium-abonnement, minstens 18 jaar, minstens 500 geverifieerde volgers en minstens 500.000 geverifieerde Home Timeline-impressies in de voorbije 90 dagen. Een kwalificerende impressie is "unique impressions from Premium users viewing posts on the Home Timeline, with at least 50% of the post visible". Het programma opende vandaag, 8 september 2026, voor bestaande leden van het oude programma. HET WOORD DAT DE HELE ZAAK DRAAGT: "geverifieerd". Bij X betekent dat betalend abonnee. Niet: identiteit gecontroleerd. Niet: één mens. De hele kwaliteitsketen — 500 geverifieerde volgers, 500.000 geverifieerde impressies, unieke impressies — meet abonnementen, en X betaalt vervolgens echt geld uit aan de eigenaar van dat account. Elke controle staat aan de kijkerskant; aan de ontvangerskant staat er geen enkele. 🔌 Integratievorm: API-sleutel op hun backend, één aanroep vóór de uitbetaling. Opzetpad: (1) de attest-API draait; (2) Franky bouwt de uitbetalingshaak in circa 4 werkdagen; (3) X zet één controle vóór de payout-oproep in X Money; (4) standaard: OIDC voor de eID-kant; (5) kleinste demo zonder hun toestemming: de bestaande proefpagina, met een gesimuleerde uitbetaling aan twee accounts van dezelfde mens. 🧩 Productmix: module V + de rail. M1 bij elke nieuwe maker, M3 op elke uitbetaling, M2 gratis op de dedup. Landt op trede 2 — hier stroomt geld. Zo zet je dit in de markt: de openingszin schrijft zichzelf nu X zijn eigen geld uitbetaalt: "u hebt de betaaldienstverlener uit de keten gehaald en daarmee ook diens fraudecontrole. Wie controleert vandaag of de duizend best betaalde accounts bij duizend verschillende mensen horen?" Bron: X Help — Original Content Rewards · The Paypers, 03-09-2026 · American Bazaar, 08-08-2026.
08-09📡 IoT-LIJN — onze eigen robot-case zegt "we wachten op regelgeving"; die regelgeving heeft een datum, en het is 20 januari 2027 — In ons dossier staat de toepassing robotproof — robot met eigenaar met als oordeel: kans onzeker, want "verzekeraars en toezichthouders wachten op regelgeving (AI Act/machineverordening) voor robot-aansprakelijkheid; vandaag geen koper met budgetlijn". Dat oordeel klopt nog steeds. Wat eraan ontbrak is de kalender. DE DATUM. De Europese Commissie schrijft over de machineverordening (EU) 2023/1230 dat die is aangenomen op 14 juni 2023 en "applies on a mandatory basis as of 20 January 2027". Tot dan blijft de oude machinerichtlijn 2006/42/EG de bindende norm. Dat is 134 dagen vanaf vandaag. WAT ER DAN VERANDERT EN WAAROM HET ONS RAAKT. De verordening dekt uitdrukkelijk machines met digitale en AI-componenten — de preambule noemt "more advanced machinery, which is less dependent on human operators" als de aanleiding. Artikel 25(5) brengt de risico's van kwaadwillende derden binnen de veiligheidseisen, en cyberbeveiligingscertificering onder verordening (EU) 2019/881 wordt onderdeel van de conformiteitsbeoordeling. Vertaald: vanaf 20 januari 2027 is "wie bedient dit ding, en met welk recht" geen open vraag meer maar een dossierplicht bij het CE-merk. WAT DIT VERANDERT AAN ONS OORDEEL — eerlijk gezegd: nog niets aan de koper. Er komt geen budgetlijn bij door een datum. Wat er wél bij komt is een aanleiding om te bellen, en die had de case niet. Een fabrikant die in januari 2027 een conformiteitsdossier moet kunnen tonen, begint daar in het voorjaar van 2026 aan, niet in december. Dat venster staat nu open. 🔌 Integratievorm: API-sleutel op de vloot-backend van de fabrikant of integrator: elke robot draagt een attest dat er een aanwijsbare eigenaar of bediener achter zit. Opzetpad: (1) de attest-API draait; (2) Franky bouwt de vloot-koppeling in circa 7 werkdagen; (3) de fabrikant hangt het attest-ID aan het serienummer in zijn eigen conformiteitsdossier; (4) standaard: attest over HTTPS, eID/itsme aan de mens-kant; (5) kleinste demo zonder hun toestemming: één attest op een verzonnen serienummer, naast de tekst van artikel 25(5). 🧩 Productmix: module V + module O; de rail doet niet mee. Trede 1. Groeipad: begin met het eigenaars-attest voor het CE-dossier; pas als er onderhoudsvergoedingen of schadeafwikkeling over lopen komt de rail erbij. Meters: M1 per bediener, M2 bij elke controle. KEUZEVRAAG VOOR FRANKY, niet gokken: richt je je op de fabrikant (die het CE-dossier draagt) of op de gebruiker/inzetter (die volgens de AI Act sinds 2 februari 2025 al bekwaam personeel moet aantonen)? Dat zijn twee verschillende verkoopgesprekken en twee verschillende budgetlijnen, en het dossier kiest vandaag geen van beide. Zo zet je dit in de markt: niet als robotverhaal maar als dossierverhaal. "Vanaf 20 januari 2027 hoort cyberveiligheid bij uw CE-beoordeling. De vraag die daar het lastigst in te documenteren is, is niet technisch — het is: wie mocht dit ding bedienen, en hoe bewijst u dat achteraf?" Bron: Europese Commissie — Machinery · Verordening (EU) 2023/1230 (beide opgehaald 08-09-2026).
08-09⚖️ JURIDISCH G17 — de CRA-meldplicht gaat over drie dagen in, en artikel 69(3) zegt iets dat ons eigen standpunt te mild formuleert — Op 11 september 2026, over drie dagen, begint de meldplicht van de Cyber Resilience Act: bij een actief uitgebuite kwetsbaarheid of een ernstig incident een vroege waarschuwing binnen 24 uur, een volledige melding binnen 72 uur, en een eindrapport binnen 14 dagen na een beschikbare correctie (of binnen een maand bij een ernstig incident), aan CSIRT en ENISA. Die datum staat al in ons dossier bij bundel G17 en wordt hier niet als nieuws gebracht. WAT ER WÉL BIJ KOMT, en het scherpt ons eigen standpunt aan. Ons standpunt bij G17 zegt vandaag: "De plicht ontstaat pas bij het op de markt brengen." Artikel 69(3) van de verordening zegt dat de meldeisen van artikel 14 gelden voor alle producten met digitale elementen die vóór 11 december 2027 op de markt zijn gebracht, ongeacht wanneer het product is uitgeleverd. De plicht ontstaat dus niet alleen bij het op de markt brengen — ze slaat óók terug op wat er al staat. Voor Secure Mail als installeerbare app betekent dat: een versie die vóór de invoering is uitgeleverd valt er evengoed onder. DE BOETE, met artikelnummer. Artikel 64(2): wie de verplichtingen van de artikelen 13 en 14 niet nakomt riskeert een administratieve boete tot 15 miljoen euro of 2,5% van de wereldwijde jaaromzet van het voorgaande boekjaar, welk van beide het hoogst is. Ons dossier draagt tot vandaag alleen het AI Act-cijfer (15 miljoen of 3%); dit is een ander artikel, een andere wet en een ander percentage, en die twee mogen niet door elkaar. WAT R4M ZELF BETREFT: de engine draait als gehoste dienst en is daardoor beperkt blootgesteld — dat deel van ons standpunt blijft ongewijzigd en correct. Het is Secure Mail dat de klok draagt. WAAROP FRANKY MOET ANTICIPEREN: de lanceerdatum van Secure Mail is nu geen productbeslissing meer maar een juridische. Lanceren vóór 11 september is niet meer aan de orde; lanceren erná betekent dat het meldproces (wie krijgt de melding, binnen welk uur, langs welk kanaal naar CSIRT) op dag één moet bestaan, niet op dag dertig. Zo zet je dit in de markt: dit is geen verkoopargument maar een bouwbeslissing. Zet het in het gesprek met de advocaat als vraag V52, en vraag expliciet naar artikel 69(3) — dat is het artikel dat bepaalt of een oudere uitlevering meetelt. Bron: Europese Commissie — CRA reporting · Crowell & Moring · CRA-tijdlijn art. 14 / 64(2) / 69(3).
08-09🗳️ CASE 134 KRIJGT EEN KLOK — de teller voor de sociale verkiezingen van 2028 begint over 23 dagen te lopen, op 1 oktober — Case 134 in onze catalogus is "Sociale verkiezingen 2028 (wettelijk verplicht)", met als terechte kanttekening dat de procedure via FOD WASO wettelijk geregeld is en dat je zonder erkenning van die procedure niets verkoopt. Die kanttekening blijft staan. Wat de case niet had, is een datum. DE DATUM. Onder voorbehoud van publicatie in het Belgisch Staatsblad loopt de referteperiode voor vaste werknemers van 1 oktober 2026 tot 30 september 2027, met een aparte periode van 1 april tot 30 juni 2027 voor bepaalde categorieën. De drempels zijn ongewijzigd: gemiddeld 50 werknemers voor een comité voor preventie en bescherming, gemiddeld 100 voor een ondernemingsraad. De verkiezingsperiode zelf is nog niet door de wetgever bekendgemaakt; naar gewoonte wordt mei verwacht. Dat betekent dat élke Belgische werkgever vanaf 1 oktober begint te tellen of hij in 2028 verkiezingen moet organiseren. De adviseurs die dat begeleiden schrijven daar nú hun campagnes voor. DE TECHNISCHE HAAK, en die is scherper dan verwacht. Elektronisch stemmen mag sinds 2020 ook op afstand. In de bestaande dienstverlening identificeert een kiezer zich "op een beveiligde manier (e-ID, sms, een token op de stembrief, enz.)". Dat rijtje is het hele probleem in één zin: het eerste middel bewijst een mens, het tweede bewijst een telefoonnummer, en het derde bewijst dat iemand een papiertje in handen had. Alle drie geven ze toegang tot dezelfde stem. Bij een verkiezing waar één werknemer één stem hoort te hebben, is het zwakste middel het middel dat telt. WAT DIT AAN CASE 134 VERANDERT: de case gaat van "ooit, als de procedure het toelaat" naar "er is een gedateerde aanleiding en een aanwijsbaar technisch gat". Dat is nog geen koper — de erkenningsvraag bij FOD WASO staat onaangeroerd — maar het is wel het verschil tussen een idee en een gesprek. Zo zet je dit in de markt: de ingang is niet de werkgever en niet de FOD, maar de partij die het elektronisch stemmen technisch levert. Zie het prospect-item hieronder. Bron: Vandelanotte, 27-08-2026 · FOD WASO — elektronisch stemmen.
08-09🎯 PROSPECT — Elegio, de partij die het elektronisch stemmen bij Belgische sociale verkiezingen technisch levert, met SD Worx als kanaal — Wie. Elegio (België) levert de e-votingoplossing voor sociale verkiezingen; SD Worx (Antwerpen) verkoopt die geïntegreerd in zijn eigen pakketten en publiceert er klantencases over. SD Worx staat al in ons dossier; Elegio komt in de hele public-map niet voor (gemeten 08-09-2026). Waarom nu, met gedateerde aanleiding. De referteperiode voor 2028 start op 1 oktober 2026, over 23 dagen. Wie in 2028 e-voting wil verkopen, bouwt zijn aanbod dit najaar. Een identificatielaag toevoegen ná de commerciële lancering kost hen een herwerking; nu kost het hen een gesprek. Waarom zij en niet SD Worx zelf. SD Worx is het kanaal, Elegio is de bouwer. De zwakte zit in de identificatiemethode, niet in de HR-administratie. Franky moet praten met wie de code schrijft. SD Worx is wel de tweede deur als Elegio niet reageert, want zij dragen de klantrelatie en dus het reputatierisico. Wie contacteren: de technisch verantwoordelijke of productverantwoordelijke voor e-voting bij Elegio. Naam niet publiek vastgesteld — opzoeken vóór je mailt. Bij SD Worx: de productverantwoordelijke Sociale Verkiezingen. Openingszin: "U laat een kiezer zich identificeren met e-ID, met sms of met een token op de stembrief. Bij een verkiezing waar één werknemer één stem hoort te hebben, bepaalt het zwakste van die drie de uitslag. Wij leveren de laag die zegt dat achter deze stem één echte mens zit die hier nog niet gestemd heeft — zonder dat u weet wíé het is. Mag ik u dat in twintig minuten tonen vóór de referteperiode op 1 oktober begint?" 🔌 Integratievorm: OIDC-knop in hun bestaande stemflow, plus een attest-oproep vóór het uitbrengen van de stem. Opzetpad: (1) de attest-API en de eID-koppeling draaien vandaag; (2) Franky bouwt de stem-koppeling in circa 6 werkdagen; (3) Elegio vervangt één stap in zijn identificatiescherm; (4) standaard: OIDC voor de eID-kant, attest over HTTPS; (5) kleinste demo zonder hun toestemming: de bestaande proefpagina met twee stempogingen door dezelfde eID. 🧩 Productmix: module V + module C; de rail doet niet mee — de organisator betaalt, niet de kiezer. Trede 1. Groeipad: begin met uniciteit per stemronde, en pas als er presentiegelden of vergoedingen over lopen komt de rail erbij. Meters: M1 bij de eerste binding van elke werknemer, M2 bij elke stemronde daarna. De catch, eerlijk vooraan: sociale verkiezingen zijn wettelijk geregeld via FOD WASO en elektronisch stemmen moet aan die regels voldoen. Zonder erkenning van de procedure verkoop je niets. Dit is dus een gesprek over 2028, niet een order voor dit kwartaal — en dat moet in de eerste mail staan, anders verlies je het vertrouwen in de tweede. Zo zet je dit in de markt: dit is de eerste Belgische prospect in weken met een wettelijke kalender achter zich in plaats van een marketingargument. Gebruik de datum, niet de techniek. Bron: SD Worx — voordelen e-voting · SD Worx klantencase DSV (Comfort Pack + e-voting).
08-09💰 FUNDING — laatste dag voor Base Batches 004, en dat is het enige nieuwe feit op het hele bord — Base Batches 004 — morgen dicht. Zevende controle op rij aan de bron. De tijdlijn op base.org/batches staat vandaag woordelijk zoals de zes vorige keren: "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". Er is geen enkel feit veranderd. Wat veranderd is, is de kalender: het is vandaag 8 september, dus dit is de laatste volle dag. Harde datum. $100K uit het Base Ecosystem Fund voor circa tien teams, plus een programma van acht weken dat virtueel loopt, met een fysieke demodag op 17 november in New York. Aanvragen via base.org/batches/apply. Dit is de reden dat dit item vandaag nog één keer een vlag draagt en morgen niet meer: "laatste dag" is een nieuw feit, "sluit binnenkort" is dat niet. Onze eigen regel van 31-08 zegt dat een urgentie die niets nieuws draagt naar een gewone regel zakt. Morgen is dit item verlopen of ingediend. Eurostars Call 11 — sluit 10 september om 14:00 CEST, en blijft niet haalbaar solo. Twee dagen. Het oordeel is ongewijzigd: Eurostars vereist een consortium en dat bestaat vandaag niet. Call 12 heeft sinds 07-09 een datum, 4 maart 2027, en dát is de deur waar de partnerzoektocht op mikt. Geen actie deze week. Start it @KBC — sluit 14 september, geparkeerd op beslissing van Franky van 05-09. Zeven dagen. Geen geld, alleen netwerk en coaching gedurende een jaar. Bewust laten lopen. Ongewijzigd. imec.istart — sluit 30 september, nog 22 dagen. Harde datum, knop actief, bedrag nog steeds niet bij de bron bevestigd. Buiten de urgentiedrempel van veertien dagen, dus geen vlag; wel de eerstvolgende die er een krijgt. EIC Accelerator — geen deadline op stap 1, volgende bundeling dinsdag 6 oktober om 17:00. Zachte datum, maandelijks opnieuw. Grootste som op het bord (subsidie tot €2,5M plus €1–10M kapitaal) en juist daarom geen paniekitem. Zo zet je dit in de markt: niet van toepassing — dit is een intern klokitem. De enige beslissing van vandaag is Base, en die vervalt vanavond. Bron: base.org/batches (opgehaald 08-09-2026 03:20).
08-09🧪 TEST — 398 groen op de hoofdtak, nul rood, geen versiedrift, en de upto-nulstand staat voor de tweede nacht op nul — Testsuite. Vanochtend 03:07 op de hoofdtak van de engine: 398 geslaagd, 2 overgeslagen, 0 gefaald, over 67 testbestanden, in 10,06 seconden. Werkboom schoon, tak main. Herhaalbaar met: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test. Versie — twee bronnen, apart gemeten. REPO: VERSION en package.json staan allebei op 0.36.7, laatste git-tag v0.36.7. LIVE: r4m-franky.fly.dev/api/public/status meldt v0.36.7. Geen versiedrift. Endpoints, letterlijk uit /api/public/status. network base-sepolia · stage pilot · app_live configured+verified (gemeten 08-09 01:07 UTC) · settlement_adapter waarde usdc-base, configured, verified null · email_login configured, verified null · itsme_eid configured+verified, omgeving sandbox, discovery op tb2r.sandbox.signicat.com · attestations configured+verified, realIssued 2 · double_entry_ledger configured+verified. Uitgegeven attestaties: 2 uitgegeven, 0 live, 1 onderscheiden mens. Die drie getallen staan al weken stil en dat is de eerlijkste regel op deze hele radar. upto-EVM-wacht (staande opdracht sinds 07-09). Nulstand opnieuw gemeten: het bestand typescript/packages/mechanisms/evm/src/upto/facilitator/scheme.ts telt 134 regels en 0 treffers op resolveCallerIdentity, authorizerSigner, delegatedAuthStore en receiverAuthorizer. De identiteitshaak blijft dus uitsluitend op SVM/Solana bestaan en is niet naar EVM of Base gekomen. Ongewijzigd — geen actie. Herhaalbaar met het commando uit de routine. Zo zet je dit in de markt: niet. Dit is de meterstand, geen verhaal. Maar één cijfer hoort wél in elk verkoopgesprek: 0 live attestaties. Zolang dat nul is, verkoopt Franky een werkende machine zonder gebruikers, en dat moet hij zelf zeggen voordat een klant het vraagt.
08-09📦 OMZET-LOPENDE-BAND — ledger-entry 27: universiteiten betalen proefpersonen al per protocol, en het gat dat wij vullen is een methodologische eis, geen verkoopargument — Het volgende nog niet omgezette €100-moment is #12 uit 100_EURO_MOMENTS.md: academische studies als alternatief voor Prolific bij Nederlandstalige en Belgische steekproeven. Vandaag door het wie-betaalt-filter en de leerstellingstoets gehaald. Wie betaalt: universitaire onderzoeksgroepen met een bestaand proefpersonenbudget per goedgekeurd protocol — KU Leuven (faculteit psychologie werft doorlopend betaalde deelnemers), UGent, en dezelfde academici die vandaag internationale steekproeven bij Prolific kopen. Prijsanker, vandaag vers aan de bron gemeten: Prolific hanteert een minimum van £6 / $8 per uur en beveelt minstens £9 / $12 per uur aan; hun eigen hulpdocument draagt de datum 17 juli 2026. Universitaire tarieven in BE/NL liggen volgens het moment-dossier op €10–25 per uur, met €50–200 voor langere protocollen. Wie-betaalt-filter: ✅ PASS. Koper met naam ✅, budget bestaat vandaag ✅, euro gaat naar de burger ✅ (vijf tot acht experimenten of één intensieve studie is een €100-moment). Leerstellingstoets, alle vier de pijlers: ✅ pijler 1 — betaald wordt wat de deelnemer bewust doet, opt-in, met een bij naam bekende betaler en een afgebakend protocol. ✅ pijler 2 — elke geverifieerde deelnemer vergroot daarna gratis de dividend-gerechtigde verzameling. ✅ pijler 3 — het labo houdt zijn protocol, zijn vragenlijst en zijn ethische goedkeuring; wij leveren de laag eronder plus de uitbetaling. ✅ pijler 4 — de uitbetaling is publiek natelbaar zonder dat één deelnemer bij naam bekend wordt. De wig. Anders dan bij de vorige entries is de wig hier geen zwakte in de etalage van de verkoper maar een eis van de recensent. Dubbele deelname over studies heen verpest between-subjects-ontwerpen, en dat wordt vandaag "opgelost" met een erewoordvraag. Uniciteit is hier dus geen kwaliteitspremie maar een methodologische voorwaarde die iemand anders dan de koper afdwingt. Meters: M1 bij elke nieuwe deelnemer, M3 op elke sessie-uitbetaling, M2 gratis op de dedup tussen labo's. ⚠ Eerlijke begrenzing, en ze is scherper dan het moment-dossier suggereert. (1) De KU Leuven-pagina over deelname aan experimenten publiceert vandaag geen bedragen — er staat alleen "studiepunten of financiële vergoeding", met doorverwijzing naar het SONA-systeem. Het cijfer €10–25/uur steunt dus op universitaire normen in het algemeen en op het Prolific-anker, níet op een vandaag geverifieerde KU Leuven-publicatie, en mag zo niet geciteerd worden. (2) Universitaire aanbesteding is traag en de volumes per studie zijn klein. (3) Prolific zit diep in bestaande werkstromen; zonder koppeling met Qualtrics of Gorilla verkoop je niets. Openstaande vragen voor de routines: (1) Publiceert één Belgisch labo vandaag wél een tarief, zodat er een Belgisch cijfer bestaat? (2) Wat kost een ethische-comitéprocedure aan doorlooptijd — dat bepaalt of dit een kwartaal- of een jaarverkoop is? (3) Bestaat er een bestaande Qualtrics- of Gorilla-koppeling die wij kunnen naboetsen in plaats van bouwen? Zo zet je dit in de markt: de deur is niet de aankoopdienst maar een methodoloog die de fraudeliteratuur over MTurk en Prolific kent. Eén pilootlabo als referentie is hier meer waard dan tien offertes. Bron: Prolific payment principles (opgehaald 08-09-2026, document gedateerd 17-07-2026) · KU Leuven PPW (opgehaald 08-09-2026 — draagt geen bedrag).
08-09📋 STAND VAN DE SPOREN — veertien items vannacht, en twee lijnen die eerlijk leeg blijven — Wat er wél is: 🆔 twee identificatie-cases (OpenAI Trusted Access · Authologic bij de Poolse centrale bank) · 💶 de geld-case bijgewerkt in plaats van herhaald (X betaalt sinds 2 september zelf uit) · ⚙️ protocolwacht x402 mét vondst, en die is de kop van de nacht · 📡 de IoT-lijn met een datum in plaats van een wens · ⚖️ één juridisch punt dat ons eigen standpunt aanscherpt · 🗳️ één case versterkt · 🎯 één Belgische prospect · 💰 het fundingbord met één nieuw feit · 🧪 één testfeit · 📦 ledger-entry 27 · 🚨 één vondst die een prospect uit onze eigen lijst raakt · 🔍 één auditvonnis dat het deployverbod op de engine onafdwingbaar noemt en het mechanisme erachter uitmeet. Deze telling is ná de deploy bijgesteld: het auditvonnis kwam er als veertiende bij toen bij het uitrollen bleek dat de uitrolworkflow geen padfilter heeft. Twaalf werd veertien, en dat hoort zichtbaar te zijn in plaats van stil rechtgezet. 🤝 x401 — leeg, en gecontroleerd. De laatste commit op github.com/proof/x401 blijft docs: align README header names with current x401 spec (#33) van 1 juli 2026. Ruim twee maanden stil. Onze achterstand is nul. Dit is een geldige uitkomst, geen gemist spoor. 🤖 Agentic payments — leeg, en dat is vannacht een eerlijk oordeel en geen luiheid. Gezocht op de vier bronnen die er toe doen (Mastercard Agent Pay, Visa Trusted Agent Protocol, Google AP2, Stripe agent-toolkit). Er is deze week geen versie- of specwijziging gepubliceerd; wat er circuleert is herhaling van de rolloutdata uit 2025 en begin 2026, die al in ons dossier staan. Geen entry liever dan een opgewarmde. 🔍 Doorloop. De doorloop-API antwoordde normaal: 47 items, waarvan 28 uitgevoerd, 12 beantwoord, 5 afgevoerd, 2 afgevinkt. Nul items op goedgekeurd, dus er was vannacht niets te verwerken naar een bestemming. 🗓️ Spoor G (Secure Mail) draait alleen op maandag. Vandaag is dinsdag — niet gedraaid, volgens schema. Wat Franky vandaag zou doen, in volgorde: (1) Base Batches indienen of bewust laten vallen — dat vervalt vanavond, alles anders kan morgen. (2) Elegio opzoeken en de openingszin versturen vóór 1 oktober. (3) De zin over de 153 miljoen rijbewijsscans in de verkoopkit zetten, want die is vandaag geschreven door iemand anders en werkt in elk gesprek.
07-09✓ AUDIT — de voorstellen-keten die vanochtend groen faalde, hield het over twee latere runs vol — Vanochtend bleek de publicatiestap zijn wachtrij te zoeken via een pad waarin de spatie in /Volumes/8TB MM4 als %20 werd gecodeerd: de bestandscontrole gaf false, het script eindigde met "geen voorstellen" en exitcode 0, en dat leest in een log als een geslaagde run — vijfentwintig onderzochte voorstellen lagen stil. Hersteld om 10:25. Avondmeting 07-09 19:2x, de vraag die telt: houdt de fix het? Het gedaan-bestand telt veertig regels van 12:41, de wachtrij draagt vijftien verse voorstellen van 18:35, inhoudelijk gevuld (eerste entry: case 76, koper Spotify AB Stockholm, met gedateerde onderbouwing). Drie geslaagde runs op één dag. Zo zet je dit in de markt: dit is het bewijsverhaal achter de eigen betrouwbaarheidsclaim — een keten die stil kon falen is gevonden, gerepareerd en daarna nagemeten, en dat laatste is wat een koper wil horen. Wat het niet zegt: of de inhoud van die vijftien voorstellen deugt, dat oordeel ligt bij Franky in de beslis-inbox.
07-09⏱ AUDIT — het versienummer dekt vanavond acht broncommits in plaats van één — Gisteravond zat er precies één broncommit tussen tag v0.36.7 (28-08-2026) en de hoofdtak, en dat is toen uitdrukkelijk zo klein genoemd als het was. Vanavond nagemeten: drieënvijftig commits tussen tag en hoofdtak, waarvan acht de broncode raken. De drie merges van vanochtend 08:49–08:50 brachten er zeven bij, en dat is geen cosmetica maar poortwerk: K1 haalt het attest-id van het kasboek en uit de adresbalk, K2 beperkt de pas-stap tot geregistreerde afnemers, K9 zet uitbetalen dicht en wist oude rekeningnummers, plus het installatiepakket per afnemer. De live app meldt onverminderd v0.36.7 (controlestempel 17:07 UTC vandaag). Zo zet je dit in de markt: niet verkopen, repareren — twee builds met verschillende privacy-poorten onder één nummer is precies wat een koper bij een audit als eerste aanwijst. Opletten en niet theater: de checks op de statuspagina zijn wel live gemeten, alleen het etiket is oud. Bumpen is founder-werk.
07-09⏱ AUDIT — FSMA vier avonden weg, NBB drie, en dit is bewust het laatste losse vonnis daarover — Vierde meting, identiek aan de drie vorige: FSMA lost op naar 217.117.44.15, TLS slaagt, certificaat geldig tot 24-12-2026, verzoek volledig verzonden, nul bytes terug. NBB geeft voor de derde avond 520 op beide adresvormen terwijl TLS daar gezond is — een toepassingsfout achter een levende voorkant. Controlemeting in dezelfde minuut: financien.belgium.be 200 en het ESMA-register 200 met 174.714 b, dus het ligt niet aan deze kant. Het nieuwe punt is niet de bron maar de regel: de vaste controleregel van 29-08 eist ESMA náást FSMA, en die dubbelcheck is nu vier avonden onuitvoerbaar. Zo zet je dit in de markt: hier valt niets te verkopen, hier valt te kiezen — de regel krijgt een opgeschreven terugvalpad, of hij blijft staan en wordt eerlijk als onuitvoerbaar genoteerd. Beide verdedigbaar, kiezen is founder-werk. Opnieuw geweigerd: casptracker.eu als vervanger opvoeren — die noemt zichzelf letterlijk een spiegel van het ESMA-register, dus dezelfde getuige in ander pak.
07-09💸 x402 — een derde partij bouwt de opsplitsing van de betaling, en de avondwacht ving hem die de nachtwacht miste — Commit 1ef4606 van vandaag 14:07 UTC voegt x402aff toe aan de lijst van externe uitbreidingen: affiliate-opsplitsing van een x402-betaling, 10% bouwerscommissie, afgedwongen op de keten bij settlement via een onbeheerd 0xSplits-contract, op Base mainnet. Bron: x402-foundation/x402, bestand docs/dev-tools/third-party-extensions.md, +1/−0 — de drie andere regels in die tabel stonden er al, alleen deze is nieuw. Eerlijke maatvoering: de repo telt zes sterren, is aangelegd 13-07-2026 en laatst gewijzigd 02-09-2026. Dit is geen aanval op de moat: x402aff betaalt apps en bouwers, niet geverifieerde mensen, en draagt geen enkel uniciteits- of mensbewijs. Zo zet je dit in de markt: het is wél de laag waar R4M naast ligt — wie krijgt er geld uit een x402-betaling, en op welk moment. Dat de opsplitsing bij settlement gebeurt, is precies waar meter M3 loopt; de positionering is dat een split zonder mensbewijs alleen adressen verdeelt, terwijl R4M kan aantonen dat er aan één kant een mens staat.
07-09🧪 BRONNEN — zevenendertig bronnen gemeten, 35× 200, en voor het eerst in zes ronden zijn de opbrengstvlaggen weer geteld — Avondronde 07-09 19:1x: zevenendertig levende bronnen bevraagd, 35× 200, twee afwijkingen (FSMA en NBB) die allebei al bekend waren en geen enkele nieuwe. De protocolwacht in de avond leverde opnieuw iets op dat de ronde van 03:00 niet kón zien, omdat de commit van 14:07 UTC toen nog niet bestond — dat is de tweede avond op rij dat die extra wacht zich terugverdient. Nulstand upto op EVM/Base bevestigd en ongewijzigd: 134 regels, 0 treffers op de identiteitshaak, byte-voor-byte gelijk aan de ochtendmeting; conform trigger 9 dus één regel en géén eigen radar-item. Wat vanavond hersteld is aan de eigen werkwijze: de opbrengstvlaggen waren vijf ronden lang niet geteld, in afwachting van een voorstel bij Franky. Vanavond wél geteld — guaranteedincome.us gaat naar een tweede vlag (65 dagen stil). Zo zet je dit in de markt: niet verkoopbaar, wel de ruggengraat eronder — een vondstenstroom is zoveel waard als de bronnenlijst die hem voedt, en die lijst controleert zichzelf nu aantoonbaar.
07-09⚠ AUDIT — de routine pushte zelf naar de hoofdtak van de engine en rolde Fly uit, precies wat haar eigen poort verbiedt — Deze middagfase committe de briefing en de auditvonnissen naar de engine-map en pushte naar de hoofdtak zonder de markering die de uitrol tegenhoudt. Poort 10 zegt woordelijk: nooit naar de hoofdtak van de engine pushen en nooit de engine uitrollen. Toch startte om 11:25:27 UTC de workflow "Deploy naar Fly.io" (run 34116545663) en die liep met succes af. Schade: geen, en dat is gemeten. Het verschil met de commit die vanochtend om 07:48 al uitgerold was, raakt uitsluitend de ops-map — twee bestanden, geen regel applicatiecode. De uitrol zette dezelfde code opnieuw neer; live nagemeten na afloop: v0.36.7, base-sepolia, adapter usdc-base, app antwoordt. Niet afgebroken, omdat een uitrol annuleren terwijl hij loopt een halve release kan achterlaten en een identieke uitrol laten aflopen het kleinere risico was. Zo zet je dit in de markt: de echte fout is niet de push maar een tegenspraak in de opdracht zelf — de ene regel verbiedt pushen naar de hoofdtak, de andere draagt het op voor het dagrapport. De nachtronde loste dat op met een markering die de uitrol overslaat; de middagfase kende die niet omdat ze nergens staat. Twee wegen, jouw keuze: de markering hard voorschrijven, of de uitrol-workflow zo instellen dat wijzigingen in de ops-map hem niet meer starten. Het tweede werkt ook als een volgende run het vergeet. [AANVULLING 07-09 avond] Niet één uitrol maar twee: de avondronde vroeg de volledige lijst op en vond naast run 34116545663 (11:25 UTC) ook een uitrol op commit d3c9445 om 07:48 UTC, eveneens een routine-push zonder de markering die de uitrol overslaat. Schade opnieuw nul — die push raakte alleen twee docs-bestanden, +21 regels, geen applicatiecode. Maar de diagnose verschuift: twee fasen, uren uit elkaar, met dezelfde vergeten markering wijzen niet op één fase die iets niet wist, maar op een opdracht waarin die markering nergens als eis staat. Dat maakt het voorstel om de uitrol-workflow docs- en ops-wijzigingen te laten negeren sterker dan gisteren. Bewijs dat de rem werkt: de avondronde pushte haar eigen commit 52f4b34 mét markering en er startte géén nieuwe uitrol.
07-09💰 FUNDING — de partnerzoektocht heeft voor het eerst een klok: Eurostars Call 12 sluit op 4 maart 2027 — Vier regels nagelezen aan de bron in de middagfase van 07-09-2026, en één daarvan levert een feit dat nergens in het dossier stond. De Eurostars-pagina van het Eureka-netwerk publiceert nu naast Call 11 (10 september 2026, over drie dagen) ook de datum van Call 12: "Eurostars Deadline 4 March 2027". Dit dossier noemde Call 12 al vier controles lang als het doel, maar zonder datum — nagekeken met een zoekopdracht op "Call 12" en "March 2027" over het funding-dossier, de cases-database en deze radar: nul treffers vóór vandaag. De bron was vandaag bovendien weer leesbaar, waar hij op 5 september nog een 403 gaf. Call 11 zelf blijft onhaalbaar: elk consortium eist minstens twee onafhankelijke organisaties uit minstens twee Eurostars-landen, en dat regel je niet in drie dagen. BRON: https://www.eurekanetwork.org/programmes-and-calls/eurostars/ (gelezen 07-09-2026). Zo zet je dit in de markt: de blokkade was nooit het dossier maar de partner, en die zoektocht had tot vandaag geen einddatum. Nu wel: bijna zes maanden om één partner in een tweede Eurostars-land te vinden. Dat is lang genoeg om het goed te doen en kort genoeg om het in te plannen — zet 4 maart 2027 in de agenda als horizon, niet als alarm. Base Batches (sluit over twee dagen, hard) en imec.istart (30 september, hard) zijn vandaag woordelijk herbevestigd zonder nieuw feit; Start it @KBC blijft geparkeerd op jouw beslissing van 5 september, met de infosessie morgen en de deadline op 14 september louter ter kennisgeving.
07-09🧪 VOORSTEL — de eerlijkheidscap ging uit bij een typfout, en zette de markt stil bij een lege regel — Tak voorstel/2026-09-07-eerlijkheidscap-nan, commit 396828e. De cap van roadmap 3b belooft dat één werker maar drie taken tegelijk vasthoudt, zodat iedereen een eerlijke kans krijgt — het antwoord op de vraag waar 3b mee begon: waarom kunnen tien mensen niet dezelfde put fotograferen? Die grens kwam ongecontroleerd uit de omgeving en faalde naar twee kanten. Zet iemand er een eenheid achter, dan wordt de grens geen getal meer en laat de vergelijking élke claim door: één werker kan de hele markt leegtrekken, terwijl het foutbericht dat niemand ooit ziet nog belooft dat iedereen een eerlijke kans krijgt. Blijft de regel leeg, dan wordt de grens nul en kan niemand nog iets claimen. De cap had tot vandaag geen enkele test. Zo zet je dit in de markt: dit is het derde geval in vijf dagen van dezelfde soort — na de backup-retentie op 6 september en de treasury-cap op 3 september — en het patroon is telkens hetzelfde: een grens uit de omgeving die niet nagekeken wordt vóór ze iets bewaakt. Dat is precies het verhaal dat een koper wil horen over hoe deze rail met zijn eigen instellingen omgaat: niet dat er nooit een fout in zit, maar dat er elke dag iemand naar kijkt en dat elke vondst een test achterlaat.
07-09🧪 TEST — 404 groen op de tak, 398 op main, en de eerlijkheidscap was tot vandaag ongetest — Gemeten op 07-09-2026 om 13:13 in de middagfase. Op main: 398 geslaagd, 2 overgeslagen, 67 bestanden — tien meer dan de 388 van vannacht 03:06, omdat de drie voorstellen die vanochtend om 08:49 in main gingen hun testen meebrachten. Op de tak van vandaag: 404 geslaagd, 2 overgeslagen, 68 bestanden. De twee overgeslagen zijn onveranderd de kaartbodem-gevallen die een Stripe-sleutel nodig hebben. Typecheck schoon, geen versiedrift: repo en live staan allebei op v0.36.7, netwerk base-sepolia, uitbetaaladapter usdc-base. De demo liep end-to-end door met de vijf boekhoudinvarianten alle vijf groen. Herhaalbaar met npm test en npm run demo vanuit de engine-map. Zo zet je dit in de markt: het getal stijgt omdat er iets gemergd werd, niet omdat er iets bijgeschreven is — dat verschil is precies wat een testgetal geloofwaardig maakt.
07-09✓ AUDIT — de voorstellenstapel kwam voor het eerst in beweging, en het eigen archief telde vier keer verkeerd — Vier vonnissen op rij zeiden dat er niets gemergd werd; dat is sinds gisteravond niet meer waar. Claim-check-en-retour ging op 6 september om 18:14 in main, vijf uur na het vonnis dat erover klaagde, en drie takken volgden vanochtend tussen 08:49 en 08:50. Stand nu: achttien takken, vijf opgenomen, dertien open. Bij het natellen kwam een fout in het eigen archief boven: de formulering "nul gemerged" van 6 september klopte niet, want de hermetische testomgeving staat sinds 28 augustus in main. Dat vonnis telde de stapel goed en de opname fout, en die fout is vier keer meegegaan. Wat blijft: de oudste open tak is nu tien dagen oud en er kwam er vandaag weer één bij. Zo zet je dit in de markt: een audit die zijn eigen cijfer corrigeert is het enige soort audit dat iets waard is — bewaar dit als voorbeeld voor het gesprek over hoe R4M met zijn eigen fouten omgaat.
07-09⚠ AUDIT — het founder-dossier staat nog in .gitignore, en vandaag schreef deze routine er zelf in — Herhaling van het vonnis van 6 september, met één nieuw en concreet feit. De stand is onveranderd: het funding-dossier en het voortgangslogboek worden allebei door dezelfde regel in .gitignore geweigerd, en er staan nul commits op. Het nieuwe feit is dat deze middagfase vandaag vier regels in dat dossier heeft herschreven, inclusief de enige vindplaats van de zojuist gevonden Eurostars-datum van maart 2027. Dat werk bestaat nu op precies één schijf en op geen enkele remote. Tot gisteren ging dit over oud werk dat je kwijt kon raken; vanaf vandaag over werk van vandaag, en het groeit bij elke run. Zo zet je dit in de markt: niets — dit is geen marktvondst maar een beslissing die op jou wacht. Drie wegen: een uitzondering voor de founder-map, een aparte private repo, of laten staan met een schijfback-up ernaast. Zolang je niet kiest, staat het volledige subsidiedossier op één schijf.
07-09⚠ AUDIT — de voorstellen-keten van de clone heeft sinds haar bouw geen enkele keer gedraaid, en meldde dat elke run als "geen voorstellen" — Gevonden op 07-09-2026 na een vraag van Franky waarom hij alles handmatig moest laten uitwerken. De keten inbox-ja → onderzoek → publicatie in de bron was volledig gebouwd, maar de publicatiestap sloeg altijd over. De oorzaak is één regel. scripts/nacht-voorstellen.mjs zocht zijn eigen wachtrij op via new URL("./nacht-voorstellen.json", import.meta.url).pathname. Die pathname codeert de spatie in het pad /Volumes/8TB MM4/… als %20, dus fs.existsSync gaf false en het script eindigde met "geen voorstellen" en exitcode 0. Waarom niemand het zag: het faalde groen. In _sync.log staat vandaag om 09:01:58 letterlijk "voorstellen verwerkt: geen voorstellen". Dat leest als een geslaagde run zonder werk, terwijl er vijfentwintig onderzochte voorstellen klaarlagen. Er was geen teller die het verschil tussen "niets te doen" en "niets gedaan" toonde. Hersteld en gedraaid: fileURLToPath in plaats van .pathname; daarna 23 voorstellen gepubliceerd over 20 cases, 16 over de bron en 7 over de koper, 0 fout. Twee meldden eerlijk dat er niets te vinden was. Structureel dichtgezet, niet alleen deze keer: een nieuwe routine R4M cases uitwerken (08:20/12:20/18:20) doet voortaan zelf het opzoekwerk voor de cases die op ja staan, en de beslis-inbox draagt bovenaan een levende teller die zegt hoeveel er wachten en wanneer de volgende ronde loopt. Ook de stille limiet van twintig kaarten in dat blok is weg. Zo zet je dit in de markt: niet naar buiten, maar het is de scherpste les van vandaag voor elke keten die we bouwen. Een stap die stil slaagt is gevaarlijker dan een stap die luid faalt. Elke keten krijgt een zichtbare teller, anders staat ze stil zonder dat iemand het merkt — precies zoals de SEO-keten zeven weken en de Artes-monitor drie maanden.
07-09🔧 CORRECTIE op de protocolwacht van vannacht — de haak bestaat, maar niet op de datum, niet in de omvang en niet met de gesloten lijst die wij erbij schreven — De vondst van 03:23 hierboven zei dat x402 sinds commit 560fdb0 van 05-09 een verplichte resolveCallerIdentity heeft die uitsluitend JWT, SIWX of mTLS aanvaardt. Aan de bron nagemeten op 07-09-2026 klopt daar drie keer iets niet. Eén, de datum. Commit 560fdb0 voegde zes regels toe over channelReadMaxAttempts en channelReadBackoffStepMs, backoff-instellingen voor het herlezen van een kanaal. Meer niet, +6/-0. De identiteitshaak kwam binnen met commit 299b9bc op 03-09-2026 22:20 UTC, "feat(ts): add delegated receiver authorizer for SVM upto" (#3346), 26 bestanden. Twee, de omvang. Het is geen protocolbrede eis maar de upto-scheme op SVM, dus Solana, en alleen in facilitator-delegated modus. De harde regel staat in typescript/packages/mechanisms/svm/src/upto/facilitator/scheme.ts regel 323: if (config.authorizerSigner && !config.resolveCallerIdentity) throw. Zet je geen authorizerSigner, dan geldt de eis niet. R4M draait op base-sepolia met adapter usdc-base en wordt hier vandaag dus niet door geraakt. Drie, en dit is de belangrijkste. "JWT / SIWX / mTLS subject" is geen gesloten lijst uit de spec maar een commentaarregel in een uitgecommentarieerd codevoorbeeld. Het echte type is (ctx) => Promise<string | undefined> — een vrije string die de facilitator-uitbater zelf invult. Wat de code écht doet: bij deposit bindt hij channelId aan de teruggegeven identiteit, bij claim vergelijkt hij opnieuw en faalt op ERR_DELEGATED_SETTLE_UNAUTHENTICATED bij verschil. Dat is een continuïteitscontrole — dezelfde aanroeper opende en sloot het kanaal — en geen uitspraak over uniciteit of menselijkheid. Zo zet je dit in de markt: beter nieuws dan de nachtversie. Er is geen gesloten lijst om op te raken; de haak is een open string en R4M kan er vandaag al in. En de haak beantwoordt de vraag "is dit dezelfde aanroeper", nooit "is dit één echte unieke mens" — dat tweede gat blijft volledig open en is precies ons product.
07-09📰 OCHTENDRAPPORT — elf radar-items vannacht, en de kop is een gat in het protocol zelf — Het rapport van maandag 07-09-2026 staat op de Ochtendrapport-tab. In één zin: de protocolwacht vond waar hij voor bestaat — x402 heeft midden in de geldweg een verplichte identiteitscontrole en die aanvaardt uitsluitend machines. Elf items van de nachtronde van 03:23, waarvan twee lijnen eerlijk leeg bleven (x401 achtenzestig dagen stil, IoT zonder eigen beweging). Backup-alarm schoon, ketencheck exit-code nul met alle vijf de ketens draaiend. Zes kaarten van de China- en India-zijroutines van 06:21 en 06:56 gingen niet zelf live; deze deploy zet ze mee. Zo zet je dit in de markt: de nacht levert drie bruikbare deuren op één ochtend — een spec-bijdrage bij x402, een consultatie bij EMVCo en een eerste gesprek bij PayOS. Kies er één, niet drie.
07-09📊 SEO-VLOOT — de vier gemergede PR's staan in de cijfers, en de daler van gisteren is de stijger van vandaag — Achttien domeinen, meting van 07-09-2026 om 03:56 via ccc-v3.franky-f29.workers.dev/api/seo-watch. idgs.eu klimt naar een onsite-score van 100 (plus vijf) met mobiele Core Web Vitals op 83 (plus zeven). channel-zero.be wint negen punten mobiel naar 65 en eenentwintig punten op desktop naar 91 — datzelfde domein stond in het rapport van gisteren nog genoteerd als daler. boombedrijfbisschop.be plus vier naar 75, blackfuelwhiskey.com min één. Drie domeinen gaven opnieuw geen CWV-waarde: turbeau2rock.com, qmtex.net en gevelsteenbedrijf-v6.pages.dev. Zo zet je dit in de markt: dit is het eerste harde bewijs dat de SEO-keten werk oplevert dat meetbaar aankomt — bruikbaar als referentie bij elke klant die vraagt wat een optimalisatieronde concreet doet.
07-09⚠ ONDER DE LAT — de MiCA-dubbelcheck ligt een derde dag stil, en dat is de regel die we zelf schreven — De verplichte controleregel zegt dat het ESMA-register altijd náást de FSMA-lijst gelegd wordt, nooit één van de twee alleen: in België is het toezicht verdeeld tussen FSMA en de Nationale Bank, en op 29-08 leidde het lezen van één register tot een foute nul-conclusie. Die dubbelcheck ligt sinds 04-09 stil op de bereikbaarheid van beide registers en is vannacht opnieuw niet beproefd — de nachtronde noemt dat zelf een bewuste keuze onder tijdsdruk. Het auditblok van gisteravond vlagde dit al als opletten; vandaag is het de derde dag. Zo zet je dit in de markt: niet naar buiten, maar naar binnen — een controleregel die drie dagen ongetoetst blijft is een claim die we niet meer kunnen onderbouwen als iemand ernaar vraagt.
07-09🧪 VOORSTELLEN — de eerste merge ooit leverde vijf testen op, en de stapel groeide er toch drie bij — Op de remote van Rails4Mankind staan zeventien voorstel-takken, waarvan er twee in main zitten. Vijftien wachten dus nog op een merge-beslissing, tegenover twaalf gisteren: er kwam er één bij op 06-09 en er kwamen er twee bij op 07-09 (codewoord-k1 en pas-stap-dicht-en-iban-uit), terwijl er één gemerged werd. Die ene merge is wel meteen zichtbaar: main stond zes dagen op 383 van 385 groen en meet vandaag 388 van 390, gemeten 07-09-2026 om 03:06, read-only op main. Commando: npm test in /Volumes/8TB MM4/Rails4Mankind. Zo zet je dit in de markt: intern signaal — de stapel groeit sneller dan hij leegloopt, en de oudste tak ligt er nu tien dagen.
07-09⚙️ PROTOCOLWACHT x402 — de enige plek waar het protocol identiteit verplicht stelt, aanvaardt uitsluitend machine-subjecten — In docs/schemes/upto.mdx van x402-foundation/x402 staat sinds commit 560fdb0 (05-09-2026 17:58 UTC) dat een facilitator in delegated-modus een resolveCallerIdentity móét meekrijgen: "Requires resolveCallerIdentity — construction throws without it", en in de Go-variant "panics without it". De spec noemt de aanvaarde vormen zelf: "JWT / SIWX / mTLS subject". De reden staat er één alinea boven: de facilitator tekent claim-vouchers pas "after correlating deposit and claim settles to the same authenticated caller".

Dat is een verplichte identiteitscorrelatie, middenin de geldweg, en geen van de drie aanvaarde vormen kán een mens zijn: een JWT is een dienst, SIWX is een wallet, een mTLS-subject is een certificaat. Het woord resolveCallerIdentity komt in de volledige map public/ van maX niet voor — gecontroleerd 07-09-2026. Bron: https://raw.githubusercontent.com/x402-foundation/x402/main/docs/schemes/upto.mdx

🔌 Integratievorm C — REST-API met sleutel op hun backend. Opzetpad: (1) draait al: ons attestatie-endpoint geeft vandaag al een groen/rood-antwoord op een gebonden mens; (2) Franky bouwt een resolveCallerIdentity-adapter die in plaats van een JWT-subject een R4M-attestatie-id teruggeeft — geschat 4 tot 6 dagen, want de haak is één functie met één stringretour; (3) de klant, een facilitator-uitbater, zet één regel in zijn schema-configuratie; (4) standaard: x402 upto delegated mode, spec zoals hierboven; (5) kleinste demo zonder toestemming van wie dan ook: een lokale facilitator met onze adapter, die weigert te settelen als de betaler geen bewezen mens is.

🧩 Productmix V + O, rail doet mee, trede 5. V levert het bewezen-mens-antwoord, O boekt de verplichting vóór de settlement en levert de bon. Groeipad: starten als attestatie-adapter naast de bestaande JWT-weg (trede 2, geen geldstroom bij ons), en pas bijschakelen naar de rail als een facilitator de uitbetaling ook echt door R4M wil laten lopen.

Zo zet je dit in de markt: x402 heeft de discussie zelf beslecht — er ís een verplicht identiteitsveld in de settle-weg, het is alleen met machines gevuld. Dat is geen kritiek op de spec maar een lege stoel met een naam erop. Openingszin naar een facilitator-uitbater: "Jullie upto-schema weigert te starten zonder resolveCallerIdentity, en jullie vullen hem met een JWT-subject. Wij kunnen dat veld vullen met een bewezen unieke mens, zonder dat er één persoonsgegeven bij jullie binnenkomt — zullen we dat één keer naast elkaar zetten?"
07-09🤖 AGENTIC PAYMENTS — de kaartwereld standaardiseert deze maand wat een mens goedkeurde, en stelt "wie is die mens" met zoveel woorden uit — EMVCo — het normenlichaam van Visa, Mastercard, American Express, Discover, JCB en UnionPay — publiceerde op 03-09-2026 een ontwerpkader, EMV Agentic Payments — Framework for Specifications, en vraagt er publiek commentaar op tot woensdag 30 september 2026. De kern heet "Intent Services": een gedeelde laag waar partijen "consumer-authorized intent" registreren, opvragen, koppelen en bijwerken vóór, tijdens en ná een transactie, juist voor gevallen waarin die toestemming meerdere interacties moet overleven — herhaalaankopen, cumulatieve bestedingslimieten, nazorg.

Wat er niet in zit, staat er zelf bij: Know Your Agent (KYA) en Agentic Transaction Indicators zijn expliciet "considerations for future publications". Het kader legt dus vast dát een consument delegeerde, en niet dat die consument één echte, unieke mens is. Bronnen: emvco.com/news (03-09-2026) · pymnts.com "EMVCo Proposes Intent Layer for Agentic Card Payments" · finovate.com (03-09-2026). Het woord "EMVCo" komt in de hele map public/ van maX niet voor — gecontroleerd 07-09-2026.

🔌 Integratievorm C, met een papieren voordeur. Opzetpad: (1) draait al: attestatie plus dubbele boekhouding met bon, precies de twee dingen die een intent-registratie achteraf moet kunnen bewijzen; (2) Franky bouwt niets nieuws om te reageren — hij schrijft één commentaarstuk van twee bladzijden op het ontwerpkader, één dag werk; (3) de klant is hier in eerste instantie geen klant maar het normenlichaam zelf; (4) standaard: EMV Agentic Payments Framework, consultatieversie; (5) kleinste demo zonder toestemming van derden: het bestaande attestatie-endpoint naast een Intent Services-veld leggen en tonen dat de mens-kant leeg blijft.

🧩 Productmix V + C + O, eerst alleen de attestatiekant, trede 2. V bewijst de mens, C draagt de delegatie met limiet en intrekbaarheid — precies wat "intent" hier probeert te zijn — en O levert de bon. Groeipad: beginnen als de mens-laag ónder Intent Services (geen geldstroom, trede 2), en pas naar trede 5 als een uitgever de agent-namens-mens-weg echt wil sluiten.

Zo zet je dit in de markt: dit is de zeldzame situatie waarin de standaardzetters zélf om commentaar vragen, met een datum, en waarin het ontbrekende stuk exact ons product is. Een ingediend commentaar kost een dag en levert een citeerbare positie op tegenover de zes grootste kaartmerken tegelijk. Beslissing voor Franky: commentaar indienen vóór 30-09-2026 — ja of nee? Ik contacteer niemand; dit is jouw deur.
07-09🆔 IDENTIFICATIE-CASE — machines hebben sinds januari een identiteitsregister op de hoofdketen, met tienduizenden inschrijvingen; voor mensen bestaat dat register niet — ERC-8004 ("Trustless Agents") staat als Draft op eips.ethereum.org en ging op 29-01-2026 live op Ethereum mainnet. Het definieert drie registers: een Identity Registry die agenten een overdraagbare ERC-721-identiteit geeft, een Reputation Registry voor publiek leesbare feedback, en een Validation Registry voor onafhankelijke attestaties over agent-prestaties. Een empirische studie die de uitrol tot 13-05-2026 volgde, telde deployments op Ethereum, BNB Smart Chain en Base, met BSC als grootste met ongeveer 32.000 geregistreerde agenten. Bronnen: https://eips.ethereum.org/EIPS/eip-8004 · https://arxiv.org/html/2606.26028 · blog.quicknode.com.

De term "ERC-8004" komt in de hele map public/ van maX niet voor — gecontroleerd 07-09-2026. Dat is een gat, want maX draagt al een moat-wacht op Self Protocol, Rarimo, Billions Network en GoodDollar, en dit is de vierde poot van datzelfde landschap: niet een uniciteitsspeler voor mensen, maar een volwassen identiteits- én reputatieregister voor machines dat al draait.

🔌 Integratievorm C of D — API-sleutel, of een attestatie als on-chain claim. Opzetpad: (1) draait al: onze attestatie is al een ondertekende verklaring met een sleutel, precies de vorm die een Validation Registry verwacht; (2) Franky bouwt een schrijver die een R4M-attestatie als validatie-record wegschrijft — geschat 5 tot 8 dagen, waarvan het meeste sleutelbeheer is; (3) de klant, een agent-uitbater, verwijst in zijn agentkaart naar dat record; (4) standaard: ERC-8004 Validation Registry; (5) kleinste demo zonder toestemming: één testnet-record dat zegt "achter deze agent staat één bewezen unieke mens", zonder wie die mens is.

🧩 Productmix V + D, alleen de attestatiekant, trede 2 met een uitloper naar 5. V bewijst de mens achter de agent; D is hier het scherpste stuk, want een reputatieregister dat op agent-adressen scoort, kan per definitie omzeild worden door een nieuwe agent — een ban op de persoon-root kan dat niet. Groeipad: eerst het validatie-record, later pas geld.

Zo zet je dit in de markt: de asymmetrie hoeft niet meer beweerd te worden, ze heeft een adres en een teller. Openingszin naar een agent-platform: "Jullie reputatie hangt aan het agent-adres. Eén nieuwe agent en de geschiedenis is weg. Wij kunnen die score aan de mens erachter hangen, zonder die mens bekend te maken — is dat een gesprek waard?"
07-09🆔 IDENTIFICATIE-CASE — de Belgische eID-tekensoftware gaf elke website het rijksregisternummer, en dat is precies de wortel waar wij op staan — Op Defcon 43 in Las Vegas, gepubliceerd 13-08-2026, toonden onderzoekers kritieke lekken in de Connective-tekenextensie van Nitro Software Belgium: software die volgens het bericht gebruikt wordt door "more than two million people, eight of Belgium's ten largest banks and over 60 government agencies" om de Belgische eID en Maestro-kaarten te benaderen. Elke willekeurige website kon gevoelige eID-gegevens uitlezen — namen, adressen, rijksregisternummers en foto's — en een kwaadaardige site kon de native binary een aangeleverde bibliotheek laten laden, wat neerkomt op code-uitvoering op de machine van de gebruiker. Het activatietoken had geen origin-binding, dus replay was mogelijk. Gerepareerd in drie stappen: 08-05 (onvolledig), 01-06 (grote fixes), 22-07-2026 (definitieve afdwinging) — 146 dagen tot volledige remediëring. De kaart zelf was niet geraakt, alleen de tekensoftware erboven. Bron: https://www.biometricupdate.com/202608/researchers-expose-major-security-flaws-in-belgiums-eid-signing-software (13-08-2026). Dit verhaal staat nergens in public/ — gecontroleerd 07-09-2026.

🔌 Integratievorm B — de OIDC-knop, en dit is het argument om hem te verkopen. Opzetpad: (1) draait al: de itsme/eID-broker is aangesloten en de discovery-controle stond vannacht op verified; (2) Franky bouwt niets extra — de OIDC-façade stond al op 3 tot 5 dagen geraamd; (3) de klant registreert één redirect-URL; (4) standaard: OpenID Connect; (5) kleinste demo: onze bestaande knop tonen naast een integratie die de kaart rechtstreeks uitleest.

🧩 Productmix V, alleen de attestatiekant, trede 2. Geen geldstroom nodig om dit te verkopen. Groeipad: attest eerst, rail veel later.

Zo zet je dit in de markt: voorzichtig, en juist daarom sterk. Dit is géén bewijs dat de Belgische eID zwak is — de kaart hield stand. Het is bewijs dat elke partij die de kaart zelf uitleest, honderdvierenveertig dagen lang een lek in huis had, en dat de veilige weg erin bestaat de kaart nooit zelf aan te raken. Dat is letterlijk wat een attestatie doet: wij vragen één keer, en beantwoorden daarna "één echte unieke mens, ja of nee" zonder dat er ooit een rijksregisternummer over de lijn gaat. Openingszin naar een bank- of overheidsintegrator: "Jullie lezen de eID vandaag zelf uit. Die weg had dit jaar 146 dagen een lek waarmee elke website het rijksregisternummer kon opvragen. Wij geven jullie hetzelfde antwoord zonder dat gegeven — mag ik u het verschil in tien minuten tonen?"

⚠️ Claim-discipline: nergens schrijven dat "de Belgische eID gehackt is". Dat is onwaar en het is ook onze eigen wortel. De juiste formulering staat hierboven en gaat over de software erbovenop.
07-09💶 GELD-CASE — de opdrachtgever publiceert zelf dat hij pas een maand later betaalt, en dat is de hele wig — excap (voorheen Store Support, actief in Nederland en België) schrijft vandaag op zijn eigen wervingspagina dat de vergoeding voor een mystery visit "gemiddeld tussen de €10,- en €35,-" ligt, en over de uitbetaling: de opdracht "gaat een week nadat wij je ingevulde vragenlijst verwerkt hebben met de verloning mee", wat "doorgaans zal dit binnen een maand na uitvoering van de opdracht zijn". Bron: https://mysteryshopping.excap.nl/hoe-werkt-het/ — opgehaald en geciteerd op 07-09-2026.

Twee dingen tegelijk, allebei uit de mond van de betaler: er stroomt écht geld naar een burger (€10–35 per bezoek), en de doorlooptijd tot dat geld er is, is ongeveer een maand. Het bekende bedrog in deze sector is dat één persoon onder meerdere accounts "onafhankelijke" bezoeken aan dezelfde keten indient, waardoor de steekproef statistisch waardeloos wordt en bureaus handmatige controleurs betalen om dat te vangen.

🔌 Integratievorm C plus de rail. Opzetpad: (1) draait al: de volledige geldweg loopt end-to-end op testnet, met dubbele boekhouding en vijf sluitende invarianten, gemeten vannacht; (2) Franky bouwt de opdracht-wave als gefinancierde pool met hash-dedup op de persoon-root — geschat 6 tot 9 dagen bovenop wat er staat; (3) de klant, een mystery-shoppingbureau, levert zijn opdrachtenlijst en keurt rapporten goed zoals nu; (4) standaard: geen externe, dit is onze eigen taakmarktplaats; (5) kleinste demo zonder toestemming: tien fictieve rapporten over tien vestigingen waarvan er twee van dezelfde persoon-root komen, en het systeem wijst die twee aan.

🧩 Productmix V + O + P, rail doet mee, trede 3. V garandeert dat tien rapporten van tien verschillende echte mensen komen, O boekt de verplichting bij goedkeuring, P betaalt die mens uit. Meter: M3 settlement loopt, met M1-verificatie bij elke nieuwe shopper. Groeipad: eerst alleen de uniciteitscontrole verkopen als kwaliteitsargument naar de eindklant (trede 2, M2), en pas de uitbetaling overnemen als het bureau daarom vraagt.

Zo zet je dit in de markt: niet op prijs, op snelheid. De sector betaalt binnen een maand; wij betalen bij goedkeuring van het rapport, dezelfde week. Dat trekt de beste shoppers weg bij de traagste bureaus, en de uniciteit is het verhaal dat het bureau aan zijn éígen eindklant vertelt. Openingszin: "Jullie pagina zegt dat een shopper zijn €25 doorgaans binnen een maand krijgt. Wij kunnen dat dezelfde week doen én bewijzen dat jullie tien rapporten van tien verschillende mensen komen. Welke van die twee is voor jullie eindklant het meest waard?"

⚠️ Eén bron viel weg. Het dossier noemde ook Volt District (BE) met "gemiddeld €25 per opdracht". Die pagina draagt vandaag geen bedragen en zelfs geen mystery-shoppingaanbod meer — voltdistrict.be/mystery-shopper/ toont nu enkel de consultancy-diensten. Het BE-bedrag van €25 is daarmee niet langer verifieerbaar en mag nergens meer geciteerd worden tot er een nieuwe bron is. Het NL-bedrag staat wel recht.
07-09🎯 PROSPECT — Mastercard zette 22 agentic-bedrijven in één cohort, en zes van de zeven relevante namen kent ons dossier niet — Mastercard maakte in september 2026 de eerste lichting bekend van de nieuwe track Agentic Commerce & Services binnen Start Path, zijn startup-programma: 22 bedrijven over de hele agentic-stack. Bronnen: thepaypers.com "Mastercard Start Path welcomes 22 firms to Agentic Program" · forkast.news · pymnts.com (september 2026).

De namen die onze vraag raken: Skyfire (geverifieerde identiteit en betaalgegevens voor agenten op het open internet), t54 (identiteit vaststellen en risico wegen bij transacties mét agenten), PayOS ("payment intelligence layer" met informatie over élke entiteit in een betaling — kaarten, rekeningen, bedrijven, mensen, transacties en agenten, vóór het geld beweegt), Tunic Pay (banken helpen oplichting in agentische betalingen te herkennen), Simetrik (audit-vaste verificatie per transactie), plus Crossmint en SolvaPay.

De maX-bril: Skyfire staat al uitgebreid in ons dossier — elf bestanden in public/. De andere zes komen er niet in voor, gecontroleerd 07-09-2026. Dat is de kop: het is geen nieuw landschap, het is ons bestaande ankerpunt dat plots in een Mastercard-cohort zit met zes buren die wij niet volgden.

🔌 Integratievorm C, als laag ónder hen, niet naast hen. Opzetpad: (1) draait al: het attestatie-endpoint met groen/rood; (2) Franky bouwt niets nieuws voor een eerste gesprek — hooguit één vergelijkingsblad, een halve dag; (3) de klant roept ons endpoint aan op het moment dat hij vandaag zijn eigen risicoscore berekent; (4) standaard: gewone REST met sleutel; (5) kleinste demo: PayOS' eigen zin — "informatie over kaarten, rekeningen, bedrijven, mensen, transacties en agenten" — naast de vraag welke van die zes vandaag een uniek mens kan bewijzen.

🧩 Productmix V + D, alleen de attestatiekant, trede 2. Geen geldstroom, geen vergunningvraag, dus dit is een gesprek dat vandaag mag. Groeipad: attest verkopen, rail pas noemen als zij erover beginnen.

Zo zet je dit in de markt: deze zeven zijn allemaal bezig met de agent, en geen van hen claimt uniciteit van de mens. Dat is complementair, niet concurrerend, en dat maakt het een partnergesprek in plaats van een verkoopgesprek. Wie contacteren: PayOS is de scherpste eerste, want zij zetten "mensen" zelf in hun opsomming. Openingszin: "Jullie noemen mensen als één van de entiteiten waarover jullie informatie geven vóór het geld beweegt. Wij doen precies één ding: bewijzen dat die mens echt en uniek is, zonder te zeggen wie het is. Past dat onder jullie laag?" Let op: dit is een prospect-vóórstel — Franky maakt de prospect aan en Franky contacteert.
07-09💰 FUNDING — vier klokken bijgesteld, en Base Batches staat op twee dagen zonder dat er één feit bij kwam — Zesde controle op rij aan de bron. De tijdlijn op base.org/batches is vandaag woordelijk onveranderd: "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". De correctie van gisteren over de Demo Day in New York blijft staan en is juist.

De klokken van vandaag, 07-09-2026: Base Batches sluit 09-09 — nog 2 dagen, harde datum. Eurostars Call 11 sluit 10-09 om 14:00 — nog 3 dagen, harde datum, en blijft aangemerkt als niet haalbaar solo (het programma vereist een consortium over meerdere landen). Start it @KBC sluit 14-09 — nog 7 dagen, harde datum, maar bewust geparkeerd op jouw beslissing van 05-09. imec.istart sluit 30-09 — nog 23 dagen, harde datum. De EIC Accelerator blijft doorlopend met de volgende bundeling op 06-10 om 17:00; dat is en blijft een zachte datum.

Geen nieuwe vlag, en dat is de boodschap. Base Batches stond gisteren al als urgent op het bord en er kwam vandaag geen enkel nieuw feit bij — alleen de kalender schoof. Volgens onze eigen regel van 31-08 zakt zo'n punt dan naar een gewone regel in plaats van opnieuw te wapperen. Er gaat vannacht dus géén melding uit.

Twee nieuwe deuren bekeken en allebei eerlijk afgevoerd. EIC Transition Open 2026 sluit op 16-09-2026, maar vereist resultaten uit een eerder EU-gefinancierd project (Pathfinder, ERC Proof of Concept of gelijkwaardig); die zijn er niet, dus de deur is dicht en komt niet op het bord. Horizon Europe Cluster 3 (Civil Security for Society) sluit op 05-11-2026 en is inhoudelijk wél raak voor identiteitsinfrastructuur, maar het is consortiumwerk met een schrijftijd van maanden — genoteerd als te bekijken, niet als kans voor deze maand. Bron voor beide data: grantsfinder.eu deadlinekalender 2026, gecontroleerd 07-09-2026; de officiële topicpagina blijft de doorslaggevende bron vóór indiening.
07-09🧪 TEST — 388 groen op main, nul rood, en de vijf boekhoudinvarianten sluiten alle vijf op nul — Gemeten op 07-09-2026 om 03:06, read-only op main in Rails4Mankind, zonder één regel te wijzigen. 388 geslaagd, 2 overgeslagen, 390 totaal, verdeeld over 64 testbestanden, in 7,35 seconden. Dat is de eerste meting ná de merge van gisteravond: main stond zes dagen op 383 van 385 terwijl de fix op een tak lag, en staat nu op 388 van 390. De twee overgeslagen tests zijn dezelfde twee als voorheen en staan open in het testboek.

Geen versiedrift. Repo VERSION v0.36.7, package.json 0.36.7, laatste git-tag v0.36.7, en de live app op r4m-franky.fly.dev meldt v0.36.7. Vier bronnen, één getal.

Endpoints, letterlijk uit /api/public/status: vier checks staan op verified true — app_live, itsme_eid (sandbox, discovery-document bereikbaar en welgevormd), attestations (2 echte uitgegeven, 1 unieke mens) en double_entry_ledger. Twee staan op configured zonder verificatie, met de app die dat zelf zegt: settlement_adapter (usdc-base) en email_login. Die eerlijkheid is bewust en blijft zo.

Reconciliation geeft 200 en staat groen op alle vijf. i1 globale conservering imbalance 0 · i2 elke transactie sluit · i3 saldo-cache matcht het grootboek, geen drift · i4 gefund 1,76 dollar = vastgehouden 1,76 = uitbetaald 0 + fees 0, verschil 0 · i5 geen negatieve posities. Herhaalbaar met: npm test in /Volumes/8TB MM4/Rails4Mankind, en curl -s https://r4m-franky.fly.dev/api/public/reconciliation.
07-09⚖️ JURIDISCH — de CRA-meldplicht van 24 uur gaat over vier dagen in, en dat is een datum die we al kenden — Op 11 september 2026, over vier dagen, begint de meldplicht uit de Cyber Resilience Act: fabrikanten van producten met digitale elementen die in de EU geleverd worden, moeten actief uitgebuite kwetsbaarheden binnen 24 uur melden aan ENISA en de aangewezen nationale CSIRT's. Volledige naleving volgt op 11 december 2027; de boetes lopen tot 15 miljoen euro of 2,5 procent van de wereldwijde jaaromzet. Bron: digital-strategy.ec.europa.eu, plus de sectorbevestigingen van Keysight en Bitdefender, gecontroleerd 07-09-2026.

Dit is de vaste stand, niet nieuws. Bundel G17 in ons juridisch dossier draagt deze twee datums al en er wijzigde niets aan de tekst, de datum of de uitleg. Het staat hier omdat de eerste van die twee datums nu binnen een week valt, en omdat de bundel raakt aan Secure Mail. Het status-veld van G17 blijft daarom ongewijzigd — er is niets te corrigeren.

Maandagse Secure Mail-toets (spoor G). Positionering ongewijzigd: attestatie-gebaseerde afzender-verificatie op de R4M-rail, x401-compatibel. De juiste woorden blijven verzegeld en pseudoniem, nooit weggegooid of anoniem. Wat de CRA hieraan verandert is een ontwerpeis, geen verkoopargument: zodra Secure Mail als product met digitale elementen geleverd wordt, hangt er een meldketen van 24 uur aan. Dat is werk om vooraf in te bouwen, niet iets om aan een klant te verkopen.
07-09📦 OMZET-LOPENDE-BAND — ledger-entry 26, en één van de twee betalers uit het dossier is stil van zijn eigen pagina verdwenen — Het volgende nog niet omgezette €100-moment is nummer 11 in docs/100_EURO_MOMENTS.md: mystery shopping met bewijsbare uniciteit en uitbetaling in dezelfde week. Door het who-pays-filter komt het er als PASS uit: er is een echte betaler, het geld gaat naar de burger, en het bedrag staat vandaag nog op de pagina van die betaler zelf — €10 tot €35 per bezoek bij excap, uitbetaling doorgaans binnen een maand. Dat wordt ledger-entry 26, ShopUniek.

De hercontrole vond ook een gat, en dat is het meldenswaardige deel. Het dossier steunde op twee betalers. De tweede, Volt District (BE) met "gemiddeld €25 per opdracht", publiceert dat bedrag niet meer: voltdistrict.be/mystery-shopper/ toont vandaag alleen nog consultancy-diensten, zonder mystery-shoppingaanbod en zonder tarief. Opgehaald 07-09-2026. Het Belgische bedrag is daarmee niet langer verifieerbaar en is uit de ledger-entry gehaald in plaats van overgeschreven. Het Nederlandse bedrag draagt de entry alleen.

Zo hoort het te gaan: een lopende band die een bron stil ziet verdwijnen en dat opschrijft, is meer waard dan één die het cijfer van vorige maand nog eens herhaalt.
07-09📋 STAND VAN DE SPOREN — elf items vannacht, en twee lijnen die eerlijk leeg blijven — Wat er wél was: x402-protocolwacht (de kop), agentic payments via EMVCo, twee identificatie-cases, één geld-case, één prospect-voorstel, funding, test, juridisch met de maandagse Secure Mail-toets, en de omzet-lopende-band. Elf items.

🤝 x401 — leeg, en gecontroleerd. github.com/proof/x401 staat onveranderd sinds commit #33 van 01-07-2026: "docs: align README header names with current x401 spec". Dat is 68 dagen stil. Onze achterstand op x401 is dus nul, en er is niets te melden. Gecontroleerd 07-09-2026 via de GitHub-commit-API.

📡 IoT — leeg, met een reden. De enige IoT-beweging die vandaag boven water kwam is de CRA-meldplicht van 11-09, en die staat hierboven al als juridisch item. Er is geen apart IoT-bedrijf met een gedateerde aanleiding gevonden dat de kwaliteitslat haalt. Liever deze regel dan een gevulde regel.

🌐 Oppervlakte-check. r4m-core-v2-k7x9.pages.dev geeft HTTP 200, r4m-founder.franky-f29.workers.dev geeft HTTP 200, r4m-franky.fly.dev/api/public/status en /api/public/reconciliation geven allebei 200. Geen nieuwe of gewijzigde R4M-links aangetroffen. Zoals afgesproken is r4m-max.pages.dev níét bevraagd: die staat achter Cloudflare Access en geeft altijd een omleiding naar een login.

🚨 Nog één keer over gisteren. De ronde van 03:00 op 06-09 heeft geen spoor achtergelaten; dat stond gisteren al op de radar. Gevolg voor vannacht: de vijf x402-commits van 05-09 tussen 17:41 en 17:59 waren nooit door de protocolwacht gegaan. Daar zat de vondst van vannacht in. Een gemiste nacht is dus niet alleen een gat in de tijdlijn, hij is een gat in de bronwacht — en die haalt zichzelf niet vanzelf in.
06-09🔍 AUDIT — de voorstellenstapel is doorbroken: na dertien wachtende takken is de eerste gemerged, en hij draait live — Vanavond om 18:14 ging voorstel/2026-09-06-claim-check-en-retour als PR #2 op main (merge 5d003a8, tak f1b7f4c van 17:11). Vier auditrondes op rij vlagden hetzelfde: dertien takken sinds 28-08, nul gemerged, de oudste negen dagen oud. Die vlag is vanavond achterhaald en dat hoort even hard gemeld te worden als de klacht. De merge bracht drie dingen mee: POST /api/gate/claim (EERSTE of BOTSING per combinatie van afnemer, context en pseudonieme verwijzing, gelogd), GET /api/gate/claims (telling per context) en een geregistreerde terugkeer-URL per afnemer, waarbij alleen die exact geregistreerde URL nog aanvaard wordt. Bron: de eigen repo DS2036/r4m-engine, gemeten 06-09-2026 19:0x. Zo zet je dit in de markt: dit is de dubbel-claim-poort waar elke koper naar vraagt — dezelfde mens kan bij dezelfde afnemer in dezelfde context maar één keer als eerste tellen, en de app zegt zelf welke van de twee het was. Dat is de zin waarmee Franky een uitgever of een loterij binnenwandelt, en ze is sinds vanavond geen belofte meer.
06-09🧪 TEST — het bewijs dat de merge van vanavond écht draait: 400 tegenover 404 — Een merge is geen deploy en een deploy is geen bewijs. Daarom is de nieuwe route rechtstreeks op de live app gemeten, met een tweede meting ernaast die niet kan slagen: /api/gate/claims antwoordt met 400, en het verzonnen /api/gate/bestaatniet met 404. Een route die bestaat maar de invoer afkeurt, naast een route die er niet is — dat verschil is het bewijs, want een niet-uitgerolde build zou op allebei 404 geven. Herhaalbaar met: curl -s -o /dev/null -w "%{http_code}" https://r4m-franky.fly.dev/api/gate/claims tegenover … /api/gate/bestaatniet. Gemeten 06-09-2026 19:0x, drieënzestig minuten na de merge. Zo zet je dit in de markt: zo ziet een controleerbare claim eruit — één regel die een koper zelf kan overtikken, in plaats van een screenshot van een groene testsuite.
06-09⏱ AUDIT — de versie op de statuspagina is negen dagen oud en kan de merge van vanavond niet tonen — De live app meldt v0.36.7. Die tag wijst naar commit d50dafa van 28-08-2026. Sindsdien staan er 39 commits op main, waarvan er precies één code onder src/ raakt: de merge van vanavond. De drift is dus één functie breed en niet negenendertig — dat verschil hoort erbij, anders wordt een boekhoudkundig probleem tot een brand opgeblazen. Maar het gevolg blijft echt: twee builds met verschillende routes dragen hetzelfde versienummer, en de statuspagina die R4M aan kopers toont kan het verschil niet uitdrukken. Gemeten met git rev-list -n1 v0.36.7 naast curl -s https://r4m-franky.fly.dev/api/public/status, 06-09-2026. Zo zet je dit in de markt: niets te verkopen, wel iets te repareren vóór de eerste klant een versienummer als bewijs krijgt aangereikt. Een versiestempel die niet meebeweegt is precies het soort halve waarheid dat deze audit moet vangen.
06-09⚖️ De Belgische MiCA-dubbelcheck ligt een tweede avond stil — maar de spiegel toont wie de bevoegde toezichthouder écht is — De regel van 29-08 zegt: leg het ESMA-register altijd naast de Belgische lijst, nooit één van de twee alleen. Dat kan vanavond opnieuw niet. FSMA is de derde avond op rij onbereikbaar (04-09, 05-09, 06-09) met dezelfde handtekening: DNS lost op naar 217.117.44.15, de TLS-handshake slaagt, het certificaat is geldig tot 24-12-2026, en dan sluit de server zonder één byte. NBB geeft de tweede avond op rij 520. Controlemetingen op dezelfde machine: financien.belgium.be 200, ESMA 200 met 174.714 bytes — het ligt niet aan deze verbinding. Wat de avond wél opleverde: casptracker.eu (spiegel van het officiële ESMA-register, eigen synchronisatie 6 september 2026, registerwijziging 22-08-2026) telt 331 vergunde CASP's, waarvan 2 voor België. De ene die met naam in de uitgeleverde pagina staat is BNY SA/NV, met als bevoegde autoriteit NBB en vergunningsdatum 20/07/2026; de tweede zit achter de paginering en is niet genoemd. Dat laatste is de kern: een spiegel van ESMA kan de FSMA-lijst niet vervangen, want het is dezelfde bron in ander jasje — en tegelijk bevestigt hij precies waarom de dubbelcheck bestaat, want het Belgische toezicht ligt hier bij NBB en niet bij FSMA. Zo zet je dit in de markt: R4M vraagt geen MiCA-vergunning zolang er geen waarde bewaard wordt, maar wie met een bank of een uitgever praat moet weten dat België twee toezichthouders heeft en welke aan zet is. Dat is een zin die vertrouwen wekt in een vergaderzaal.
06-09◐ CORRECTIE op gisteren — de Dune-deur ging na één avond weer open, en dat maakt het label van gisteren te sterk — Gisteravond gaf dune.com/queries/6240463 403 met 5.657 bytes en werd de rij in het bronnenboek gemarkeerd als AFGESLOTEN 05-09-2026. Vanavond antwoordt dezelfde query met 200 en 79.953 bytes, en de kale dune.com/ met 200 en 340.602 bytes. De blokkade duurde precies één avond. De meting van gisteren was correct; de naam die eraan gehangen werd niet — uit één waarneming werd een toestand gemaakt. De rij is vanavond teruggezet op levend, met beide metingen zichtbaar naast elkaar. Zo zet je dit in de markt: dit is de eigen kwaliteitslat in werking — een correctie op eigen werk is meer waard dan een dossier waarin nooit iets fout stond. Wie de x402-volumecijfers van R4M later betwist, kan zien dat de bron zelf ook bijgehouden wordt.
06-09🧪 Bronnenronde 06-09: 34 van de 38 bronnen antwoorden, en de vier afwijkingen zijn alle vier al bekend — Elke bron uit docs/BRONNEN.md kreeg vanavond één verzoek. Uitkomst: 34× 200, plus vier afwijkingen die geen van alle nieuw zijn — FSMA onbereikbaar (derde avond), NBB 520 (tweede avond), de kale EUDI-ruimte 404 en de EUDI-wiki die met 204 omleidt naar de EU-inlogpagina. Die laatste twee staan sinds 31-08 correct doorgestreept in het bronnenboek, mét werkende vervanger; de meting van vanavond bevestigt ze alleen. Eén meetfout aan eigen kant is meteen rechtgezet: casptracker leek geslonken tot 599 kB, maar dat was de leeslimiet van het meetscript — bij volledige lezing weer 3.046.117 bytes, gelijk aan gisteren. Zo zet je dit in de markt: niets te verkopen, wel de reden dat het dossier niet stiekem veroudert. De achterstand van twee maanden op x402 V2 ontstond precies doordat niemand de bronnen zelf nakeek.
06-09💰 FUNDING — Base Batches sluit over 3 dagen, en het bord had één tijdlijnrij te weinig: er hoort een Demo Day in New York bij — Vijfde controle op rij aan de bron, 06-09-2026, HTTP 200. De datum staat als een huis: “Applications close September 9”. Maar de tijdlijn op base.org/batches heeft vijf rijen, niet vier: Aug 19 open · Sep 9 closed · Sep 17 acceptances sent · Sep 21–Nov 15 Virtual Program · Nov 17 Demo Day in New York. Die laatste rij stond hier nooit. Sinds 03-09 droeg het bord de geruststelling “virtueel, geen reis, geen verhuizing” — juist voor de acht weken, onjuist voor de afsluiting. Er hoort één vliegreis bij, op 17 november. Het advies verandert niet: indienen. De kost is nu wél bekend vóór de indiening. Twee andere regels zijn vandaag ook aan de bron nagelopen. Eurostars Call 11 sluit woordelijk “10 September 2026 at 14:00 CEST”, hard en over vier dagen, en krijgt bewust géén vlag: de oproep eist een consortium uit twee landen en dat is solo niet te bouwen — een waarschuwing voor een deur die je niet kán nemen is ruis. imec.istart staat op “Sept 1 - Sept 30 (midnight)” met een actieve APPLY NOW, en de bron noemt nu ook de vervolgvensters Spring 2027 (1–30 jan) en Summer 2027 (1–31 mei) — hard, maar niet fataal. Zo zet je dit in de markt: niets naar buiten. Dit is de beslissing van deze week, en ze is nu compleet: indienen vóór woensdag, met een reis naar New York in november erbij gerekend. Bron: base.org/batches · eurekanetwork.org · imecistart.com/en/apply, alle drie opgehaald 06-09-2026.
06-09🔍 AUDIT ⚠ THEATER — het volledige founder-dossier staat in .gitignore en bestaat op precies één Mac — Gemeten vandaag in de engine-repo. Stap 6 van de middagfase luidt: schrijf een run-entry weg en “commit de site-repo”. Die commit kan niet slagen. git check-ignore -v geeft voor beide founder-bestanden dezelfde regel: .gitignore:8:site/ — de hele map is uitgesloten. Gevolg: funding.json (48.063 bytes, 37 financieringsprogramma’s, alle afwegingen per programma) en progress.json (het volledige runlogboek) zijn niet getrackt. git log --all geeft er nul commits voor. Ze hebben nooit in enige repo gestaan. Eén schijfstoring op MM4 wist het subsidiedossier en het logboek; het publieke bord in cases-db.json overleeft, maar draagt zes van de zevenendertig regels en geen enkele afweging. Dit heet theater en geen slordigheid, omdat het een handeling is die elke run wordt afgevinkt en niets doet — precies waarvoor de backup-alarmregel van 28-08 is gemaakt, toen 24 commits stil niet op GitHub stonden. Hier zijn het er nul, en al veel langer. Bijvangst uit dezelfde meting: progress.json zegt updated 2026-09-05 terwijl de nieuwste entry 2026-09-03 is — de middagfases van 04-09 en 05-09 hoogden de datum op zonder een spoor toe te voegen. Zo zet je dit in de markt: niets naar buiten, maar het is wel een beslissing die alleen jij kan nemen. Drie wegen: een negatie-regel !site/founder/ in .gitignore, een aparte private repo voor het dossier, of bewust laten staan en er een schijfback-up naast zetten. Wat niet mag blijven, is dat de routine elke run doet alsof de eerste al bestaat.
06-09💡 VOORSTEL #13 — een typfout in de backup-retentie wiste stil élk archief, terwijl het commentaar beloofde dat dat niet kon — Tak voorstel/2026-09-06-backup-retentie-nan, commit ee76c61. De bewaking in src/backup/backup.ts droeg de belofte letterlijk in commentaar: “never let a bad config wipe every backup”, met daaronder if (keep < 1) return []. Die belofte hield geen stand. De keten, stap voor stap op de echte code nagemeten: de retentie werd berekend als Math.max(1, Number(BACKUP_RETENTION)); een waarde die geen zuiver getal is — “14 days”, “1_4”, “14d” — geeft NaN; NaN < 1 is false, dus de bewaking laat NaN door; en slice(NaN) is slice(0), de volledige lijst. Elke backup verwijderd, teruggegeven als “pruned” alsof het de bedoeling was, zonder één logregel. Dezelfde familie als voorstel #11 van 03-09 (de treasury-cap-typo), maar erger: die verruimde een limiet, deze vernietigt gegevens. De fix is klein en raakt geen geldpad: de bewaking weigert nu expliciet een niet-eindig aantal, en de config aanvaardt alleen een geheel getal van 1 of meer en zegt luid als ze iets negeert. Tegenproef gedraaid: zonder de bronwijziging falen precies 2 van de 5 nieuwe gevallen — de twee NaN-gevallen; de andere drie pinnen bestaand gedrag vast dat nog niet vastlag. Eerlijke begrenzing: dit doet vandaag geen schade — de huidige .env draagt geen BACKUP_RETENTION en de standaard 14 is een geldig getal. Het is een val die klaarligt voor de eerste keer dat iemand er een eenheid achter zet. Zo zet je dit in de markt: niets naar buiten, maar het is wel het derde voorstel op rij dat puur beschermend is en geen geldpad raakt — daarmee een van de goedkoopste om af te handelen als de stapel van dertien takken korter moet.
06-09🧪 TEST — 383 groen op main, 388 op de tak, en de stapel voorstellen staat nu op dertien — Vandaag gemeten, niet overgenomen. main: 383 groen · 2 overgeslagen · 63 bestanden op v0.36.7, typecheck schoon. Tak van vandaag: 388 groen · 2 overgeslagen · 64 bestanden — de vijf erbij zijn de retentiegevallen hierboven. De server boot schoon op v0.36.7 en de demo loopt end-to-end met de vijf boekhoudkundige invarianten I1 t/m I5 groen. De twee overgeslagen zijn ongewijzigd de kaartbodem-gevallen die een Stripe-sleutel nodig hebben. Herhaalbaar met npm test in /Volumes/8TB MM4/Rails4Mankind. Daarnaast geteld met git branch --list 'voorstel/*': dertien takken, nul gemerged, de oudste negen dagen. Wat vandaag NIET getest is: de itsme/eID-koppeling met een echte aanmelding, de mailverzending, en alle dertien voorstel-takken samen — elk is apart groen, geen enkele is tegen de andere twaalf gedraaid. Zo zet je dit in de markt: het getal zelf is geen verkoopargument, maar “elke wijziging draait tegen 383 tests en een tegenproef” is wél wat een overheidsklant wil horen over een geldrail.
06-09📊 SEO — twee uitgerolde fixes met harde cijfers: idgs 44% lichter, turbeau2rock van 244 naar 7 verzoeken — Vier PR's gemerged en gedeployd op 06-09-2026, alle drie de sites daarna live nagemeten. idgs.eu: 42 beelden naar WebP, paginagewicht 1.392 kB → 775 kB (−617 kB, 44%), gemiddeld beeld 116 → 65 kB. Onsite blijft 95, desktop CWV blijft 97. www.turbeau2rock.com: de fotocarousel haalt niets meer op zolang de gallery buiten beeld is, plus een letterlijk dubbel gallery-script weggehaald. Gemeten op de echte pagina: 244 → 7 verzoeken, 13 in totaal, 955 kB. boombedrijfbisschop.be: 5 beelden onder de vouw op lazy; die winst is NIET aantoonbaar (mobiel 71 → 74, binnen de eigen spreiding van 7,3 punten). Bij het nakijken vooraf zat er in de idgs-PR een echte fout: apple-touch-icon was mee omgezet naar WebP, wat op iOS het startschermpictogram leeg laat. Gerepareerd voor de merge. Een vijfde PR is bewust NIET gemerged: die hercomprimeerde 148 jpg-bestanden die geen enkele pagina laadt. Zo zet je dit in de markt: dit is het verschil tussen een PR die klaarstaat en een resultaat dat er staat. Vier van de vijf leverden iets op, één bevatte een fout en één deed niets — en dat weet je alleen door voor het mergen te meten wat er stukkan. Bron: /seo-tab van CCC V3.
06-09🚨 GEMISTE NACHT — de eigen ronde van 03:00 heeft geen spoor achtergelaten — Gemeten 06-09-2026 08:0x. Geen commit in r4m-max-v2, geen dagrapport in ops/daily, geen enkel radar-item met datum 06-09. De drie nachten ervoor draaide fase VINDEN telkens rond 03:20. Zeven sporen zijn niet gelopen; testboek en SIGNALS_ADAPT zijn vandaag niet ververst. Twee zijroutines liepen wél en redden de ochtend: cn-radar om 06:21 en india-radar om 06:56, samen zes kaarten, geen van beide deployt zelf. Zo zet je dit in de markt: niets — dit is huishouding. Maar het is het soort stilte dat je twee keer moet zien voor je weet of het toeval is: slaat de ronde van morgen 03:00 óók over, dan is er iets stuk en niet iets traag.
06-09↩️ CORRECTIE — Cloudflare had de betaalstap er wél bij, op precies dezelfde dag — Onze kaart van 04-09 zei dat Cloudflare de bewijsstap afdwingt en de betaalstap leeg laat, en noemde dat de opening voor R4M. Dat klopt niet. Op 1 juli 2026 verscheen óók Announcing the Monetization Gateway: x402 aan de rand, Web Bot Auth eronder voor agent-verificatie, en een prijs op webpagina's, datasets, API's en uitdrukkelijk ook MCP-gereedschappen. Doen, bewijzen en betalen bij één leverancier in één product. Wachtlijst, geen algemene beschikbaarheid, geen prijzen en geen klantnamen bekend. Bron: blog.cloudflare.com/monetization-gateway/ — nagekeken 06-09-2026. Zo zet je dit in de markt: de opening is kleiner én scherper geworden. Web Bot Auth zegt wíé de agent is, niet wat hij mag, namens wie, en binnen welke grens. Verkoop niet langer "de betaalstap ontbreekt", maar "uw agent is echt en betaalt — alleen weet niemand namens welk mens".
06-09📉 HET CIJFER — x402 draagt ~28.000 dollar per dag en meer dan 95 procent is geen handel — Het netwerk boekte in juni 2026 meer dan 200 miljoen transacties, maar Artemis Analytics stelt vast dat >95% protocolsignalering is: machines die de leiding testen. Dagmomentopname: ~131.000 transacties voor ~28.000 dollar, gemiddeld 20 dollarcent. Drie tellingen over dertig dagen lopen uiteen — x402.org 24 miljoen dollar, Allium ~3 miljoen, Artemis <2 miljoen, na zelfhandel-filter 1,6 miljoen. NIET BEVESTIGD: CoinDesk gaf een 429, het Artemis-onderzoek bestaat alleen als bericht en citaat, en de dagmomentopname draagt geen datum. Zo zet je dit in de markt: noem dit cijfer zélf voordat een tegenpartij het doet. Cloudflare zet een tolpoort op een weg waar vandaag nauwelijks verkeer over gaat, en dat maakt van R4M geen laatkomer maar iemand die op tijd is.
06-09🤖 HET GAT — wie opdraait voor een verkeerde agent-betaling staat in geen enkele bron — Alle verslaggeving over het Indiase Unified Agent Protocol noemt dezelfde vijf waarborgen: agent-identiteit, machtiging, bestedingslimiet, fraudebewaking en audit-spoor. Wie de schade draagt als een agent binnen zijn limiet tóch verkeerd betaalt, staat nergens leesbaar. Datzelfde spoor corrigeert onze eigen kaart: agentic UPI begon niet in februari 2026 maar op 9 oktober 2025 met NPCI, Razorpay en OpenAI, en de proeven met Claude en Gemini waren toen al afgerond. Uit dat bericht: de AI-bedrijven krijgen géén toegang tot de betaalgegevens. Het Global Fintech Fest is besloten op 8 september (RBI, SEBI, IFSCA, PFRDA) en publiek van 9 tot 11. Zo zet je dit in de markt: dit is de scherpste openingszin die vandaag op het bord staat. Vijf waarborgen aan de voorkant, niets over de gevolgen aan de achterkant — en een attest dat vastlegt namens welk uniek mens de opdracht gegeven werd, is precies wat dat gat dicht.
06-09📊 SEO-VLOOT — twee dalers en twee stijgers, drie domeinen zonder meetwaarde — Verse meting 06-09-2026 03:47 over 18 domeinen. Mobiele Core Web Vitals: channel-zero.be −14 naar 56 met een LCP van 10,6 seconden, boombedrijfbisschop.be −11 naar 71. Omhoog: idgs.eu +12 naar 76 en blackfuelwhiskey.com +5 naar 79. Geen enkele onsite-score bewoog. Drie domeinen gaven vandaag helemaal geen CWV terug: turbeau2rock.com, qmtex.net en gevelsteenbedrijf-v6.pages.dev. Zo zet je dit in de markt: niets te verkopen, wel te bewaken. Een LCP van tien seconden op een domein dat 69 kliks per dag haalt is de goedkoopste winst op het hele bord.
06-09💰 FUNDING — Base Batches sluit over drie dagen, het bord zegt nog vier — Gecontroleerd 06-09-2026: de sluitingsdatum van 09-09-2026 is hard en er resten nog drie dagen, waarvan een weekend en twee werkdagen. Het label op het Subsidies-bord staat nog op "nog 4 dagen" en is een dag oud — die telling hoort vandaag bijgewerkt door de middagfase. Dit is de zevende ochtend dat het punt op de actielijst staat en de laatste waarop schrijven realistisch nog past. Programma: 100.000 dollar uit het Base Ecosystem Fund voor ~10 teams, virtueel van 21-09 tot 15-11, uitsluitsel al op 17-09. Zo zet je dit in de markt: niet verkopen maar beslissen. Zeven ochtenden hetzelfde punt is geen urgentie meer, het is een openstaande keuze — indienen of van het bord.
06-09🩺 TEST — geen versiedrift, maar vandaag ook geen testgetal — Gemeten 06-09-2026: depot en live staan allebei op v0.36.7 (VERSION, package.json en jongste tag komen overeen met /api/public/status), tak main, werkmap schoon. Endpoint /api/public/reconciliation antwoordt 200. Checks: app_live en itsme_eid geverifieerd (eID vanochtend 03:58 tegen de Signicat-sandbox), settlement_adapter usdc-base en email_login wél ingesteld maar niet geverifieerd. Pilot draait op base-sepolia, dus de geldweg loopt end-to-end zonder echte waarde. De testsuite is vannacht niet gedraaid, dus er is géén getal van vandaag — dat is een gat, geen groen. Herhaalbaar: cd "/Volumes/8TB MM4/Rails4Mankind" && npm test. Zo zet je dit in de markt: nul versiedrift is een verkoopargument tegenover elke koper die vraagt of wat hij ziet ook draait. Maar zeg er niet "alles groen" bij zolang er vandaag niemand getest heeft.
05-09⏱ OPLETTEN — De SEO-keten leeft, maar het antwoordformaat wijzigde onder onze controle vandaan — Gemeten 05-09-2026: de seo-watch-API geeft 200 met 158.433 bytes, 18 domeinen en een verse meting van 05-09 03:48. De keten draait. Maar er is geen synced_at meer op het hoogste niveau van het antwoord: dat veld zit nu per domein in domains[].latest.synced_at, en bovenaan staat een nieuw generated_at. Een controle die het oude veld bovenaan zoekt, vindt vanaf nu niets en concludeert eerlijk dat de keten dood is — op een levende keten. Deze bron staat in onze bronnenlijst met precies één reden erbij: de SEO-keten viel op 09-07-2026 stil en niemand merkte het zeven weken lang. Dit is dezelfde storing in spiegelbeeld. De bronrij draagt vanaf vanavond beide veldnamen. Zo zet je dit in de markt: een formaatwijziging die een monitor blind maakt is het schoolvoorbeeld waarmee je uitlegt waarom attestatie op een afgesproken vorm moet staan en niet op een veldnaam die iemand stilletjes verplaatst.
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 — Beide Belgische toezichthouders zijn twee avonden weg, en daarmee ligt onze eigen MiCA-controleregel stil — Gemeten 05-09-2026 19:1x, tweede avond op rij. www.fsma.be kapt af ná een geslaagde TLS-handshake: DNS lost op (217.117.44.15), het certificaat is geldig (*.fsma.be, GlobalSign), het verzoek gaat volledig weg, en dan sluit de server zonder één byte. www.nbb.be geeft 520 — de Cloudflare-rand staat, de oorsprong niet. Het ligt niet aan onze kant: financien.belgium.be gaf op dezelfde minuut 200 (44.871 b) en esma.europa.eu 200 (92.972 b). Op 29-08 is de vaste regel ingevoerd om het ESMA-register altijd náást de FSMA-lijst te leggen, omdat het Belgische toezicht over twee toezichthouders verdeeld is en één register lezen die dag tot een foute nul-conclusie leidde. Die regel is nu twee avonden onuitvoerbaar. Zo zet je dit in de markt: dit is geen storing om te melden maar een verhaal om te vertellen — R4M bouwt een rail die moet werken als registers wegvallen, en wij zijn het soort partij dat het merkt op de avond zelf in plaats van bij de volgende audit. Gebruik het als opening bij elke toezichthouder-gerichte klant: "Wij meten de bronnen waarvan we afhankelijk zijn, elke avond, en we schrijven op wanneer ze zwijgen."
05-09📉 BRON WEG — Dune sluit de deur en onze enige onafhankelijke x402-volumemeting valt weg — Gemeten 05-09-2026: dune.com/queries/6240463 gaf gisteren nog 200 met 79.428 bytes en geeft vanavond 403 met 5.657. Ook de kale dune.com geeft 403 — het is een blokkade op de hele site voor deze client, geen verwijderde query. Volgens onze eigen regel is dat niet dood (geen 404/410), maar de rij levert vanaf nu niets meer zonder browser of API-sleutel. Daarmee blijft agenteconomy.to over als enige levende volumebron, en die stond op 30-08 al aangetekend als tegenstrijdig met andere tellers. Zo zet je dit in de markt: elk x402-volumecijfer dat wij vanaf nu noemen, staat op één teller die zichzelf tegenspreekt. Noem in gesprekken geen absoluut x402-volume meer zonder erbij te zeggen waar het vandaan komt — de concurrent die dat wél doet, citeert een cijfer dat hij niet kan navertellen.
05-09⚙️ PROTOCOLWACHT — x402 staat drieëndertig uur stil en onze achterstand is nul — Gemeten 05-09-2026 19:1x op x402-foundation/x402: geen enkele commit sinds 04-09 09:59 UTC. De tagwacht blijft op pypi-x402@v2.22.0 — de tag die cases-db.json sinds gisteren kent, dus achterstand nul. De ARF-tagwacht (EUDI) blijft op v3.0.0 van 21-07-2026, en x401 is onbewogen sinds 01-07-2026: zesenzestig dagen. Na een week waarin deze avondronde tweemaal een spec-commit ving die de nachtwacht van 03:00 gemist had, valt er vanavond niets te vangen. Zo zet je dit in de markt: stilte in de spec is verkoopbaar. Een klant die twijfelt of hij nu moet aansluiten, hoort het liefst dat het protocol een week niet bewogen heeft en dat wij dat elke dag nameten — niet dat het "snel evolueert".
05-09🔍 AUDIT — Ons eigen voorstel voor een omvangdrempel lag vier avonden bij Franky en was vier avonden fout gemeten — Sinds 01-09 stelde de routine voor om een bron die 200 geeft maar onder een paar duizend bytes blijft, te markeren als lege schil. Vanavond breekt dat op twee eigen metingen. Eerste: bloodinthemachine.com geeft 200 met 94.977 bytes en bevat 448 tekens leesbare tekst — een kop, een auteursnaam, een inschrijfknop, en nergens het woord dividend, terwijl de bron uitgerekend als vervanger voor de AI Dividend beproefd werd. Elke drempel op ruwe omvang verklaart die bron gezond. Tweede, andersom: de x402-commits-API groeide 12.842 bytes terwijl het venster exact dezelfde twintig commits bevat (vingerafdruk 0a42456c3da69344, bovenste 5df361d5, onderste 71dd6296). Dertienduizend bytes, nul gebeurtenis. Bijgestelde vorm: meet de leesbare tekst, niet de omvang van het antwoord. Niet zelf doorgevoerd — het wijzigt regel 1 en dat is een beslissing van Franky. Zo zet je dit in de markt: dit is precies het bewijsmateriaal waarmee R4M zich onderscheidt van een AI die mooie rapporten schrijft — wij publiceren de avond waarop ons eigen voorstel onderuitging.
05-09🔍 AUDIT — De oppervlakte-check noteerde gisteravond een omvang die 113.310 bytes boven het grootste bestand in git lag — Vanavond zijn de live-metingen voor het eerst tegen de bron gecontroleerd in plaats van alleen genoteerd, en ze sluiten tot op de byte: /marktradar 543.375 b gelijk aan public/marktradar.html, en /cases-db.json 5.144.167 b gelijk aan het bestand op schijf. Juist daardoor valt op dat de meting van gisteravond niet kan kloppen: er stond 5.175.106 b, terwijl de grootste versie van dat bestand die toen in git stond 5.061.796 b was. Compressie verklaart het niet — met gzip gevraagd geeft dezelfde opvraging 1.626.010 b en met brotli 1.414.794 b, allebei kleiner. Wat er gisteren over de lijn kwam valt niet te reconstrueren; dat het niet met de bron te rijmen was wel. Vonnis ⏱ opletten, geen theater: geen bewijs van een verzonnen getal, wel van een getal dat een etmaal als feit in de tabel stond. Zo zet je dit in de markt: de fix kostte niets — meet het live-getal naast het getal op schijf. Dat is de hele belofte van R4M in het klein: een cijfer dat je kan navertellen is een ander product dan een cijfer dat je moet geloven.
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 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. 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-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?"
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 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 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 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 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 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📊 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 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.
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📰 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 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: 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 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 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. 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". 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 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: 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. 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 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 test

Versie: 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. /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.
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.
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. 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 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, 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 (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. 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. 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 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://ccc-v3.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.
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.
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.
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 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: /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 /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 test
31-08💡 VOORSTEL — kaartbodem-test draait weer echt (tak, alleen testcode, mutatietest bewijst dat hij niet leeg is) — Tak 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 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: 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.
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.
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 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 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 /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 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.
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 (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 /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 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 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 — /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.
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 — /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 /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: 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.
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)

NLStichting FAD (Leidschendam) — beheert het Waarschuwingsregister van de Nederlandse retail: een door de Autoriteit Persoonsgegevens vergunde zwarte lijst van betrapte winkelmedewerkers, bevraagd met een code van vijf letters van de achternaam plus geboortedatum (stichtingfad.nl; Distrifood 05-09-2026: "jaarlijks in honderden gevallen"; AH, Lidl en Plus doen niet mee). Wat: weigerlijst per mens op een verzegeld attest (D + V, rail doet niet mee). Hoe: het bestuur via info@stichtingfad.nl; bestuurslid Ben Swagerman sprak publiek. Toegevoegd 14-09-2026; Franky beslist of dit een prospect wordt.
BEEclipse Foundation AISBL (Brussel) — de Europese open-source-stichting achter Open VSX, de extensiemarkt waar van 26-07 tot 01-08-2026 77 valse extensies van gewone nieuwe uitgeversaccounts verschenen (The Hacker News, 05-08-2026). Belgisch adres (Rond Point Schuman 11), CRA-toolkit sinds 10-09-2026, Code & Compliance op 27-10 in Brussel. Wat: een attest "unieke mens, niet eerder geband" voor nieuwe uitgevers (V + C, rail doet niet mee). Hoe: persoonlijk op 27-10, bij het Open VSX-securityteam of Executive Director Mike Milinkovich. Toegevoegd 13-09-2026; Franky beslist of dit een prospect wordt.
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).