NIEUW 08-08-2026 03:36UITLEGlees dit eerst
Waar dit over gaat — x402 en x401, in mensentaal
Twee afspraken duiken in bijna elk idee hieronder op. Wie ze niet kent, leest de rest als jargon; wie ze eenmaal snapt, ziet meteen waar R4M staat.
x402 — de robot betaalt. Een afspraak waarmee een website tegen een robot kan zeggen: “dit kost 2 cent — betaal en je mag binnen.” De robot betaalt meteen, zonder account en zonder kaart. Het internet had al dertig jaar een ongebruikte foutcode “402 Payment Required” liggen; die is nu ingevuld.
x401 — de robot bewijst wie zijn baas is. Dezelfde truc, maar voor identiteit: “bewijs eerst dat er een echte, geverifieerde mens achter je zit, en dat die je dit mág laten doen.” Geen aparte app: een taal die een bestaande app leert spreken.
En de helft die leeg staat. x402 stuurt geld náár een dienst. x401 zegt iets óver een mens. Geen van beide stuurt geld náár een mens. Dat is precies de derde pijl uit Deel B — de richting die nog niemand standaardiseerde, en waar R4M al staat.
Uitleg & opmerkingen
Waarom dit blok bovenaan staat: deze pagina is bedoeld om ’s ochtends in vijf minuten te lezen, ook door iemand die niets van betalingen of identiteit weet. Elk idee hieronder heeft daarom een “Simpel gezegd”-regel. Kan een idee niet in mensentaal, dan is het nog niet af.
Bijvoorbeeld: jouw agent moet vijftig prijzen ophalen achter betaalmuurtjes van 2 cent (dat is x402). De verkoper wil weten dat er een echte klant achter zit en geen scriptje (dat is x401). En als jij achteraf een vergoeding krijgt voor je gegevens of je werk, moet dát geld bij jou aankomen en controleerbaar zijn — dat laatste stuk is van R4M.
Schaal, ter kalibratie: x402 valt sinds 2026 onder de Linux Foundation met onder meer Google, Visa, Mastercard, AWS, Circle en Stripe. Over de omvang doen wij geen uitspraak — de transactie- en agentaantallen die hier stonden bleken onverifieerbaar; zie de correctie op de x402-tab voor wat er wél gemeten is (~$28.000 per dag over het hele protocol, naar schatting de helft test- of wash-verkeer). cijfers · uitleg x402 · uitleg x401
Cijfers uit externe bronnen, niet uit onze eigen meting — ze horen thuis in een radarronde, niet als claim in Deel A.
NIEUW 08-08-2026 03:36GECONTROLEERDgeen idee meer
DR0 · Dit staat er al — dus het telt niet als idee
Vóór er iets nieuws op deze pagina komt, wordt de tab zelf nagelezen. Vier dingen die als “nieuw idee” werden aangedragen, staan er al in, en scherper: x401 als voordeur is blok D1, inclusief het losse prototype r4m-x401-proto en de kernzin “x401 is geen app, het is een taal”. De lege EU-issuer-stoel is Zet 2, mét de nuance dat uniciteit per nationale populatie blijft. De Lawful Access Module is Zet 3, met de volgorde-regel dat hij pas verkoopbaar is ná blok D11. Honderd gezinnen × €50 is Zet 4, met D12 en D13 eronder.
Simpel gezegd: “Voor je een idee opschrijft, kijk je eerst of het er al staat. Vier van de vijf keer stond het er al — dan is het geen idee maar een herhaling.”
Zo bouw je dit in
Wat de gebruiker zietNiets. Dit blok is een controle vooraf, geen idee.
Wat de app zelf doetNiets.
Wat er nieuw bij moetNiets — behalve dat elk idee hieronder deze drie regels moet kunnen invullen. Lukt dat niet, dan is het geen bouwidee maar tekst voor de tab, en dan staat dat er ook zo bij.
Waar dit in de app landt
Via de app: nergens nieuw — dat is net de conclusie. D1 wijst naar src/identity/, Zet 3 naar src/identity/evidenceVault.ts plus de tabellen identity_evidence en evidence_access_log, Zet 4 naar src/routes/marketplace.ts met pools en tasks. Die code bestaat en draait.
In de app: niets verandert. Dit blok bestaat om te voorkomen dat er tijd gaat naar iets dat al gebouwd is.
Uitleg & opmerkingen
Waarom dit blok bestaat: een ideeënpagina zonder geheugen wordt een lijst die elke maand hetzelfde voorstelt. Dit blok is het geheugen. Ook al gedekt en dus buiten beeld: mandaten en delegatie (D2), levenscyclus van het bewijs (D3), payout-adresbeveiliging (D4), sanctiescreening (D5), conformance-testvectoren (D8), verdienmodel (D9), QTSP-horizon (D10).
NIEUW 08-08-2026 03:36RADARklaar om te loggen in Deel E
DR-R · Eerste radarronde, klaar om te loggen
Deel E zegt: wekelijks een kwartier, doel “nooit meer verrast worden zoals met x401”. Onder Radar-changelog staat vandaag nog “nog geen radar-rondes gelogd”. Dit is die eerste ronde, in het formaat dat Deel E vraagt — maximaal vijf regels gevolgen voor R4M, elk met bron.
Simpel gezegd: “Eén keer per week vijftien minuten kijken wat er buiten veranderd is, zodat je niet weer wakker wordt met een nieuwe standaard die je niet zag aankomen. Dit is de eerste keer.”
Zo bouw je dit in
Wat de gebruiker zietNiets. Dit zijn vijf regels voor het changelog van Deel E.
Wat de app zelf doetNiets.
Wat er nieuw bij moetNiets te bouwen, maar twee regels zetten wel een klok: regel 3 op de x401-voordeur (blok D1) en regel 5 op de plek waar de app je identiteit ophaalt.
Waar dit in de app landt
Via de app: niet in de app — dit is een radarronde voor Deel E. Enige uitzondering: regel 4 (MyGov.be) raakt op termijn src/routes/identity.ts, waar GET /providers vandaag de lijst met eID-aanbieders teruggeeft. Komt MyGov.be erbij, dan is dat één extra provider in die lijst, geen verbouwing.
In de app: op het scherm 🪪 Jouw pas verschijnt er dan een extra keuze naast itsme en demo. Verder niets.
De vijf regels, met bron
1 · x402 staat nu onder de Linux Foundation, met onder meer Google, Visa, Mastercard, AWS, Circle, Stripe, Cloudflare en Anthropic aan tafel. De laag waarop R4M aansluit is institutioneel geworden — dat versterkt Zet 2 en haalt het “x402 is hype”-tegenargument onderuit. bron
Te controleren vóór dit ergens anders in de tab wordt overgenomen: twee bronnen geven twee oprichtingsdata (2 april en 14 juli 2026). Niet publiceren zonder één harde bron.
2 · De betaalreuzen bezetten de betaalkant, niet de uitbetaalkant. Mastercard lanceerde Agent Pay for Machines met Coinbase, Stripe, Polygon, Ripple en Solana; AWS bracht Bedrock AgentCore Payments met wallets en uitgavenlimieten. Allemaal agent → dienst. Geen van hen doet dienst → bewezen mens. De derde pijl in Deel B blijft leeg. bron
3 · x401 is bij FIDO binnen. Proof werd sponsor-lid en dient x401 in bij de agentic-authentication-werkgroep; Circle, OpenAI, Google en Okta staan erachter. Hoe verder de spec institutionaliseert, hoe minder ruimte om als issuer nog vorm te geven — Zet 2 wordt dringender. bron · Proof
4 · België heeft een naam gekregen. BOSA zet MyGov.be neer als het Belgische antwoord op de eIDAS 2.0-walletplicht, naast itsme voor dagelijkse authenticatie. In deze tab staat overal “itsme / EUDI / demo” — MyGov.be en BOSA komen er nergens in voor. bron
5 · De acceptatieplicht heeft een datum. Private partijen die sterke klantauthenticatie doen, moeten EUDI-attestaties aanvaarden — genoemd wordt december 2027 voor financiële instellingen, met ARF v3.0.0 (21-07-2026) als huidige spec (SD-JWT VC en mDL, via OpenID4VCI/OpenID4VP). Dat is een verkoopdatum, geen techniekdetail: vanaf dan heeft een bank een verplichting en R4M een aanbod. bron
NIEUW 08-08-2026 03:36APART BOUWENhangt niet aan D11
DR1 · De bon voor de mens die het geld krijgt
Het Grootboek staat live en zegt vandaag eerlijk “nog niet gevuld”: het double-entry-fundament ligt er, de dual-write staat achter een feature flag die nog niet om is. De publieke kant bestaat dus wel, de kant van de ontvanger niet. Eén controleerbare bon per uitbetaling — met drie eerlijke standen: onderweg, vastgehouden door een controle, aangekomen.
Simpel gezegd: “Als jouw geld niet aankomt, hoor je overal hetzelfde: het is onderweg. Bij R4M krijg je een bon: een link die iedereen kan nakijken, ook zonder account, waarop staat dat dit bedrag naar één bewezen persoon vertrok — en of het onderweg, vastgehouden of aangekomen is.”
Zo bouw je dit in
Wat de gebruiker zietBij elke uitbetaling een linkje “bekijk je bon”. Wie erop klikt — ook zonder account — ziet één van drie standen: onderweg, vastgehouden door een controle, of aangekomen. Zoals track-and-trace van een pakje.
Wat de app zelf doetDe app maakt bij elke uitbetaling al een verplichting aan en houdt bij hoe ver die staat. Die stand bestaat dus al; hij is alleen nog nergens te zien voor de persoon om wie het gaat.
Wat er nieuw bij moetEén pagina die op bonnummer antwoordt, en één publiek adres dat die stand teruggeeft zonder namen. Geen nieuwe tabel: het bonnummer ís de bestaande verplichting.
Voor de bouwer: stand komt uit src/settlement/settler.js (createObligation / trySettleOne); nieuw endpoint naast /api/public/reconciliation in src/routes/publicApi.js; pagina naast app/grootboek.html.
Waar dit in de app landt
Via de app: bovenop wat er al draait. De standen komen uit GET /api/public/obligations en /api/public/ledger; de uitbetaling zelf zit in POST /api/app/me/:id/uitbetalen (src/routes/consumerApp.ts) en landt als rij in payout_requests en obligations. De drie eerlijke standen bestaan al in de settlement-laag: settled, pending en rejected uit src/settlement/adapter.ts. De bon is een publieke pagina die één obligation-id opzoekt — nieuwe weergave, geen nieuwe waarheid.
In de app: op het scherm Naar je bankrekening staat vandaag Je aanvragen met een status. Daar komt per aanvraag een deelbare link bij. Wie erop klikt — je boekhouder, de sponsor, een journalist — ziet dezelfde drie standen zonder in te loggen. Het bestaande app/grootboek.html is de auditeurs-versie; dit is de versie voor de mens zelf.
Eerst nodig: de dual-write achter R4M_LEDGER_DUAL_WRITE staat nog uit. Zolang die vlag niet om is, toont de bon de oude ledger-rijen — eerlijk, maar niet de dubbele boekhouding.
Uitleg & opmerkingen
Waarom bijbouwen: de glazen kassa is vandaag machine-leesbare JSON voor een auditeur. Deze bon maakt hem voelbaar voor de persoon om wie het gaat. Klein blok: een pagina die één bon-id neemt en de status uit het bestaande endpoint toont. Het hangt niet aan D11 en niet aan de advocaat.
Bijvoorbeeld: bij creators en freelancers houdt een fraudecontrole een bedrag soms wekenlang vast zonder dat iemand kan tonen waar het steekt. Dat probleem is beschreven; een bon met een eerlijke “vastgehouden”-stand is er het antwoord op.
Waarom het kan mislukken: een eerlijke status is pas eerlijk als er ook “vastgehouden” op mág staan. De eerste keer dat een echte klant dat ziet, vraagt iemand of dat niet gewoon verborgen kan worden.
Onder de motorkap — routes, tabellen, test
Waar het in de code landt: nieuwe publieke route naast de bestaande GET /api/public/reconciliation (src/routes/publicApi.ts). De drie standen bestaan al als data: onderweg = een open rij in obligations, vastgehouden = een mislukte of geblokkeerde rij in settlement_attempts, aangekomen = de rij in ledger. Er wordt dus niets nieuws gemeten, alleen getoond.
Wat er nieuw bij moet: de route zelf plus de vertaling van die drie tabellen naar drie woorden. Geen nieuwe tabel, geen wijziging aan de betaalkant.
Hoe je het test: npm run demo op poort 4099, neem een obligation-id uit de uitvoer, open de bon en controleer dat de stand meeschuift van onderweg naar aangekomen.
NIEUW 08-08-2026 03:36CONTENTDeel C · concurrentiematrix
DR2 · Een vierde kolom in de concurrentiematrix
De matrix vergelijkt R4M met World en met Proof/x401. Sinds deze zomer zijn de grote betaalbedrijven zelf ingestapt in de x402-stack. Staan die niet in de tabel, dan lijkt het alsof ze niet gezien worden. Staan ze er wél in, dan valt meteen op dat ze allemaal dezelfde helft doen.
Simpel gezegd: “Visa, Mastercard, AWS en Google zijn nu ook bezig met betalende robots. Zet ze in de tabel, en je ziet in één oogopslag dat ze allemaal het betalen regelen — en niemand het uitbetalen aan een bewezen mens.”
Zo bouw je dit in
Wat de gebruiker zietNiets. Dit is één kolom in een tabel op deze tab.
Wat de app zelf doetWat de app hier moet doen, doet ze al: uitbetalen aan een bewezen mens, met een kasboek dat iedereen kan nakijken.
Wat er nieuw bij moetNiets. Wel de regel van de matrix zelf aanhouden: elk vinkje krijgt een bron, en de tabel wijst naar het echte kasboek in plaats van naar een belofte.
Waar dit in de app landt
In de app: niet. Dit is tekst in Deel C, geen code. Bewust hier gezegd: een vierde kolom in een tabel voelt als werk, maar er verandert geen regel in r4m-engine.
In de app: niets. Wie deze twee zinnen niet leest, gaat een dag zoeken naar de plek waar dit gebouwd moet worden.
Uitleg & opmerkingen
Wat erbij komt: één kolom “betaalreuzen (x402-stack)” met dezelfde drie rijen die er al staan — EU-overheids-eID, revealbaar onder wettig bevel, eigen payout-rail — en per vinkje een bron, zoals de matrix zelf eist (“alleen velden die wij kunnen staven”). Het is geen nieuwe claim: het is de bestaande claim, met de zwaarste namen ernaast.
Bijvoorbeeld: in een gesprek vraagt iemand “doet Visa dit straks niet gewoon zelf?”. Met de vierde kolom is het antwoord één blik op de tabel: zij regelen dat de robot betaalt, niemand van hen regelt dat een bewezen mens uitbetaald wordt met een publiek kasboek erbij.
Waarom het kan mislukken: Visa en Mastercard hebben wél uitbetaalrails (Visa Direct, Mastercard Send). Het onderscheid is niet “zij betalen niet uit”, maar “zij koppelen uitbetaling niet aan één bewezen unieke persoon met een publiek kasboek”. Wie die nuance in de tabel weglaat, geeft een recensent gratis munitie.
Onder de motorkap — routes, tabellen, test
Raakt de app niet. Dit is tabwerk: één kolom in de matrix van Deel C. Geen route, geen tabel, geen module. Dat expliciet zeggen hoort erbij — anders blijft een contentpunt in de bouwwachtrij hangen alsof er code voor nodig is.
NIEUW 08-08-2026 03:36CONTENTtien minuten werk
DR3 · België bij naam noemen in Zet 1
Zet 1 zegt: bouw op de Europese identiteits-wallet in plaats van op itsme alleen. België heeft daar ondertussen een naam voor — MyGov.be, van BOSA — en die staat nergens in de tab.
Simpel gezegd: “Iedereen in België kent itsme. Wat bijna niemand weet: de overheid bouwt daarnaast de officiële Europese versie, en die heet hier MyGov.be. Wie dat woord gebruikt in een gesprek met een ambtenaar, laat meteen zien dat hij zijn wereld kent.”
Zo bouw je dit in
Wat de gebruiker zietVandaag niets. Later één extra keuze op het inlogscherm, naast itsme — voor de burger blijft het één knop.
Wat de app zelf doetDe app vraagt je identiteit op bij een aanbieder. Wélke aanbieder dat is, is een instelling.
Wat er nieuw bij moetVandaag alleen twee zinnen in Zet 1 en één regel in de radar. Pas als de Belgische wallet publieke koppelgegevens heeft, wordt het een taak.
Voor de bouwer: aanbieder-laag zit in src/routes/identityOidc.js.
Waar dit in de app landt
Via de app: de tekst niet, de provider wél — later. GET /api/identity/providers geeft nu de beschikbare eID-aanbieders terug en POST /api/identity/verify doet de verificatie; de OIDC-koppeling zit in src/routes/identityOidc.ts met oidc_flows als tabel. MyGov.be wordt daar één extra ingang, geen tweede identiteitslaag.
In de app: op 🪪 Jouw pas komt "MyGov.be" naast itsme te staan zodra BOSA live is. Tot dan verandert er niets aan het scherm.
Uitleg & opmerkingen
Wat erbij komt: twee zinnen in Zet 1, en één regel in de wekelijkse radar: “welke lidstaten live/pilot” wordt “welke lidstaten live/pilot — BE: MyGov.be (BOSA), status?”.
Bijvoorbeeld: je zit bij een gemeente en zegt “wij sluiten aan op de Europese wallet”. De ambtenaar hoort een abstract Europees verhaal. Zeg je “wij sluiten aan op MyGov.be van BOSA, en daarmee meteen op de 26 andere landen”, dan hoort hij zijn eigen dossier.
Waarom het kan mislukken: wat BOSA aankondigt en wat er in 2027 effectief draait, zijn twee dingen. Zonder datum en bron staat er over een half jaar een claim in de tab die niemand nog kan natrekken.
Onder de motorkap — routes, tabellen, test
Waar het in de code landt: de providerlijst is al een instelling, geen verbouwing — GET /api/identity/providers in src/routes/identity.ts. De echte aanmeldstroom loopt via src/routes/identityOidc.ts, dezelfde weg als /api/identity/itsme/login en /callback.
Wat er nieuw bij moet: vandaag alleen de naam in de lijst en in de teksten. De echte koppeling pas als BOSA een testomgeving heeft; tot dan is dit tabwerk van tien minuten en geen bouwwerk.
Hoe je het test: curl localhost:4099/api/identity/providers — de nieuwe naam hoort in het antwoord te staan zonder dat er iets aan de aanmeldstroom verandert.
NIEUW 08-08-2026 03:36CLAIM-HYGIËNEzelfde geest als de claim-audit
DR4 · De lege stoel dateren
In Zet 2 staat: er zit geen Europese eID-verankerde issuer in de x401-registry. Dat is vandaag waarschijnlijk waar — de zoekronde van 08-08-2026 vond er ook geen — maar het is een uitspraak over iets wat je níet gevonden hebt. Zulke uitspraken verlopen, en één tegenvoorbeeld haalt het blok onderuit.
Simpel gezegd: “Zeggen dat er geen enkele Europese aanbieder is, is iets anders dan bewijzen dat er geen is. Zet de datum erbij waarop je gekeken hebt — dan is het eerlijk, en zie je meteen wanneer het tijd is om opnieuw te kijken.”
Zo bouw je dit in
Wat de gebruiker zietNiets. Dit is één herformulering in Zet 2.
Wat de app zelf doetNiets.
Wat er nieuw bij moetNiets te bouwen, wel dezelfde discipline als in de app: daar draagt elk publiek cijfer een bron. Een uitspraak over de buitenwereld hoort net zo goed een datum te dragen.
Waar dit in de app landt
In de app: niet. Een datum bij een claim is redactiewerk in Deel C.
In de app: niets.
Uitleg & opmerkingen
Wat erbij komt: herformuleren naar “gecontroleerd op DD-MM-JJJJ: geen Europese eID-verankerde issuer in de registry”, plus de registry-check als vaste regel in de wekelijkse radar.
Dezelfde les, al eens betaald: twee tegenstrijdige testaantallen op de site waren op 02-08-2026 de aanleiding voor de claim-auditregel in Deel E. Dit is dezelfde fout, maar dan met een claim over de buitenwereld in plaats van over onszelf.
Waarom het kan mislukken: een datum bij een claim maakt hem eerlijk, maar ook zichtbaar oud. Loopt de radar niet, dan wijst het label zelf naar de verwaarlozing — precies wat DR5 probeert weg te nemen.
Onder de motorkap — routes, tabellen, test
Raakt de app niet. Dit is claim-hygiëne op de tab plus één vaste regel in de wekelijkse radar. Geen code.
NIEUW 08-08-2026 03:36ROUTINEschrijft nooit zelf in de tab
DR5 · De radar die zichzelf klaarzet
De radar is een goede afspraak: elke week een kwartier kijken of er buiten iets veranderd is. Het changelog is alleen nog leeg. Een routine die de zeven radarvragen afgaat, per vraag hoogstens drie bronnen ophaalt en er een kladronde van maakt, laat alleen het oordelen over.
Simpel gezegd: “Een goed voornemen zonder duwtje wordt niet uitgevoerd. Laat de machine het saaie deel doen — zoeken en verzamelen — zodat er voor jou alleen nog een kwartier oordelen overblijft.”
Zo bouw je dit in
Wat de gebruiker zietMaandagochtend staat er één kaart klaar op de startpagina van deze tab, met vijf regels en vijf links, en de knoppen ✔ / ✘ / ❓ eronder.
Wat de app zelf doetNiets. De rail wordt hier niet aangeraakt — dit gaat volledig langs de tab.
Wat er nieuw bij moetEen routine die het zoekwerk doet en het resultaat als voorstel instuurt. Niets wordt toegepast zonder jouw klik, en een claim wordt nooit herschreven.
Voor de bouwer: zelfde pijp als de andere routines: tools/stuur-voorstel.sh.
Waar dit in de app landt
In de app: buiten de app, en dat is de ontwerpkeuze. De routine loopt naast r4m-engine en levert af via tools/stuur-voorstel.sh in r4m-maX. Ze krijgt geen schrijfrechten op de rail en geen databank-toegang — precies zoals de dagcheck en de gebruikstest.
In de app: niets. Dit is een routine voor jou, niet voor een gebruiker.
Uitleg & opmerkingen
Hoe het aansluit: de kladronde gaat als voorstel naar deze tab via tools/stuur-voorstel.sh, precies zoals r4m-dagcheck-max en r4m-gebruikstest dat doen. De routine schrijft nooit zelf in de tab en herformuleert nooit een claim; bij twijfel wordt het type: rood. Blok DR-R hierboven is wat zo’n ronde oplevert — die is nu met de hand gedaan.
Bijvoorbeeld: op maandagochtend staat er één kaart klaar met vijf regels en vijf links. Jij leest ze in een kwartier, duwt er drie weg en houdt er twee — en de radar-changelog vult zich vanzelf, zonder dat er iemand een avond moet gaan zoeken.
Waarom het kan mislukken: een automatische radar levert vooral ruis — veel aankondigingen, weinig gevolgen. Produceert de kladronde elke week vijf regels “interessant maar irrelevant”, dan klik je hem na een maand ongelezen weg, en is de lege changelog vervangen door een volle die niemand leest.
Onder de motorkap — routes, tabellen, test
Raakt de rail niet. De routine leeft naast maX en levert via tools/stuur-voorstel.sh een voorstel af, net als de dagcheck en de gebruikstest. Ze schrijft nooit in r4m-engine en nooit rechtstreeks in de tab.
NIEUW 08-08-2026 03:45STRATEGIEgeteld, niet gevoeld
DR6 · De markt heeft 4.400 kopers en 477 verkopers
De hele agent-economie bouwde de afgelopen twee jaar aan de koperskant: robots die kunnen betalen. De verkoperskant bleef leeg. Eén telling uit maart 2026 zet dat in cijfers: ongeveer 4.400 kopers tegenover 477 verkopers op het x402-netwerk. En van die 477 is er geen enkele waar een bewezen échte mens achter staat.
Simpel gezegd: “Een festival waar 4.400 mensen honger hebben en er staan 477 frietkramen. Je hoeft geen betere hongerige mens te worden. Je gaat aan de kant staan waar er te weinig van zijn — daar bepaal jij de prijs.”
Zo bouw je dit in
Wat de gebruiker zietNiets nieuws: de verkoperskant bestaat al — een inbox met je eigen prijs, een taak met bewijs, een uitbetaling.
Wat de app zelf doetAlles werkt, maar een robot kan niet ontdekken dát dit aanbod bestaat. Er is geen etalage.
Wat er nieuw bij moetEén publieke lijst van wat er te koop is, zodat een agent het kan vinden zoals hij vandaag een dienst vindt.
Voor de bouwer: catalogus naast /api/public/config, gevoed door de bestaande betaalde ingangen.
Waar dit in de app landt
Via de app: in wat er al staat, niet in nieuwe code. De verkoperskant die geteld wordt is letterlijk src/x402/paywall.ts: de betaalmuur op POST /inbox/:handle en de twee betaalde data-endpoints /api/data/verified-observations en /api/data/coverage. Elke betaalde levering komt in x402_sales. Dat zijn de kramen — ze bestaan en ze zijn geteld.
In de app: op het scherm Verdiensten — wie betaalde jou ziet een mens precies dit cijfer van de andere kant: elke regel is een robot die aan zijn kraam betaalde.
Eerst nodig: wil je aan de vraagkant gevonden worden, dan moeten die endpoints in de x402-vindplaatsen staan (Bazaar, AgentCore). Vandaag staan ze er niet — dat is een aparte stap.
Uitleg & opmerkingen
Hoe het aansluit: Inbox402, LeadFlip, PayLink402 en Witness zijn allemaal verkoperskant. Dit cijfer verandert de toon van de pitch: niet “wij zijn de eersten” (een claim die je moet verdedigen) maar “wij staan aan de kant van de markt waarvan publiek geteld is dat hij leeg is” (een cijfer dat de ander zelf kan narekenen). Dat is dezelfde claim-discipline als in het productregister.
Via de app: een verkoper aanmaken is vandaag één aanroep. POST /api/inbox/register maakt een betaalde handle, POST /api/inbox/:handle/price zet de eigen prijs, en de 402-uitdaging wordt per verzoek uit díé prijs opgebouwd (src/x402/paywall.ts, dynamische prijs per inbox). Elke afgehandelde verkoop landt in de tabel x402_sales én als regel in het kasboek. R4M kan dus letterlijk verkopers maken — precies het schaarse goed. Wat ontbreekt is vindbaarheid: een verkoper die geen agent kan vinden, verkoopt niets. Dat is PayLink402 als vast adres plus een directory-listing (agent-card / MCP), en dát is het eerstvolgende stuk werk — geen nieuwe motor, een etalage.
HR-voorbeeld: een jobbeurs met 4.400 recruiters en 477 kandidaten. Wie aan de schaarse kant staat, wordt gebeld en bepaalt de voorwaarden. Precies daarom werkt omgekeerd rekruteren: de kandidaat zet “open voor aanbiedingen” aan en de recruiter betaalt de kándidaat per benadering, niet de tussenpersoon.
Vóór dit ergens anders in de tab komt: dit getal komt uit één secundaire bron. Zoek een primaire telling (facilitator-statistiek of on-chain analyse) vóór het als R4M-claim wordt gebruikt. Zelfde regel als bij de oprichtingsdatum van de x402 Foundation.
Waarom het kan mislukken: een lege markt kan ook gewoon een markt zijn waar niemand op zit te wachten. CoinDesk schreef in maart 2026 dat de vráág er nog niet is — zie DR7. Weinig aanbod én weinig vraag is geen kans, dat is een lege straat.
Bron: Nerd Level Tech — x402 standards race
Onder de motorkap — routes, tabellen, test
Waar het in de code landt: POST /api/inbox/register en POST /api/inbox/:handle/price in src/routes/inbox.ts, met de tabellen inboxes en inbox_messages. De betaalde ingang zelf is POST /inbox/:handle, afgeschermd door de x402-deur in src/x402/paywall.ts.
Wat er nieuw bij moet: niets aan de motor. Wat ontbreekt is de vindbaarheid: een verkoper die niemand kan vinden, telt niet mee in die 477. Dat is een lijst-vraag, geen bouwvraag.
Hoe je het test: registreer een handle, zet er een prijs op, en laat de demo-koper betalen — de rij verschijnt in inbox_messages en in het kasboek.
NIEUW 08-08-2026 03:45CIJFERSeerlijkheid als wapen, niet als principe
DR7 · De grote x402-cijfers zijn opgeblazen — en dat is winst voor ons
Coinbase meldt tienduizenden actieve agents en tientallen miljoenen dollars omzet. Chainalysis telde diezelfde transacties na en stelt vast dat een groot deel van de piek eind 2025 memecoin-verkeer was, geen robots die diensten kochten. CoinDesk vatte het in maart 2026 samen als: de vraag is er gewoon nog niet.
Simpel gezegd: “Een winkel die iedereen meetelt die langs de etalage loopt en dat ‘bezoekers’ noemt. De teller staat hoog, de kassa niet.”
Zo bouw je dit in
Wat de gebruiker zietHet kasboekscherm, dat vandaag eerlijk zegt “nog niet gevuld”.
Wat de app zelf doetDe app rekent gemiddelden uit échte uitbetalingen, niet uit schattingen — dat is de hele doctrine.
Wat er nieuw bij moetNiets bouwen. Dit blok gaat over durven: hun opgeblazen teller naast ons kasboek leggen en de klant zelf laten kijken.
Voor de bouwer: /api/public/honest-math en /api/public/reconciliation uit src/routes/publicApi.js, zichtbaar in app/grootboek.html.
Waar dit in de app landt
Via de app: niet als code, wél als bewijs dat er al is. De glazen kassa die je naast hun teller legt, bestaat: /api/public/honest-math, /api/public/reconciliation en /api/public/solvency. Er hoeft niets gebouwd te worden om dit argument te maken — enkel geciteerd.
In de app: op Verdiensten staan alleen bedragen die echt betaald zijn. Dat is het verschil met een bezoekersteller, en het is de reden dat het argument standhoudt als iemand doorvraagt.
Uitleg & opmerkingen
Hoe het aansluit: dit is de meest onderbenutte troef van de hele tab. De markt verkoopt opgeblazen tellers; onze doctrine is honest numbers only en er ís een publiek reconciliation-endpoint. We hoeven niemand zwart te maken — we zetten de glazen kassa naast hun teller en laten de klant kijken. Hoort als eigen blok in Deel A of Deel E, met de drie bronnen naast elkaar.
Via de app: de tegenhanger is al gebouwd — vijf publieke endpoints waar een buitenstaander onze cijfers kan natellen: /api/public/reconciliation, /solvency, /obligations, /ledger en /honest-math. Er is dus geen regel code nodig, wél één verkooppagina die die vijf links naast de Chainalysis- en CoinDesk-bron zet. Waar het vandaag schuurt: honest-math rapporteert eerlijk “nog niet gevuld” zolang er geen echte uitbetalingen zijn. Het wapen laadt pas bij de eerste mainnet-micro-uitbetaling — één echte payout geeft dat endpoint een echt getal, en pas dán kun je het naast hun teller leggen.
HR-voorbeeld: een vacaturesite die klikken telt als sollicitaties. Iedereen in de sector weet dat het niet klopt, en iedereen gebruikt het getal toch — tot iemand het naast de echte aanwervingen legt.
Waarom het kan mislukken: wie de cijfers van de markt afbreekt, breekt ook de markt af waarin hij zelf zit. “x402 stelt nog niets voor” is een zin die een investeerder onthoudt. De formulering moet zijn: de láág is institutioneel (zie DR-R), de tellers zijn opgeblazen — dat zijn twee verschillende dingen.
Bron: Chainalysis · CoinDesk · RZLT (de Coinbase-cijfers)
Onder de motorkap — routes, tabellen, test
Waar het in de code landt: de twee endpoints bestaan al en zijn publiek: GET /api/public/honest-math rekent het echte gemiddelde uit de uitbetalingen in ledger, en GET /api/public/reconciliation is de glazen kassa. Beide in src/routes/publicApi.ts.
Wat er nieuw bij moet: geen code in de rail — een blok op de tab dat die twee endpoints uitleest. Eén ding blokkeert de inhoud: het grootboek meldt vandaag eerlijk "nog niet gevuld" omdat de dubbele boeking achter de vlag R4M_LEDGER_DUAL_WRITE nog niet omstaat. Zolang dat zo is, toont het blok een lege kassa — wat eerlijk is, maar niet overtuigend.
Hoe je het test: curl localhost:4099/api/public/honest-math en /api/public/reconciliation naast elkaar leggen.
NIEUW 08-08-2026 03:45KLOKeen datum verkoopt beter dan een idee
DR8 · De EUDI-klok: 24-12-2026 en 24-12-2027
Twee harde datums uit de verordening. Elke EU-lidstaat moet vóór 24 december 2026 minstens één digitale identiteitswallet aanbieden. Eén jaar later zijn gereguleerde partijen — banken, verzekeraars, telecom, platformen — verplicht die wallet te aanvaarden. x401 werkt uitdrukkelijk mét overheids-ID’s. R4M is al eID-geworteld.
Simpel gezegd: “De overheid deelt in december aan iedereen een officieel pasje op de gsm uit, en een jaar later moet elke bank dat pasje kunnen lezen. Wie de kaartlezer dan al klaar heeft staan, verkoopt kaartlezers.”
Zo bouw je dit in
Wat de gebruiker zietDezelfde ene knop op het verificatiescherm — straks met de wallet van je eigen land ertussen.
Wat de app zelf doetDe app haalt je identiteit op bij een aanbieder en bewaart het bewijs verzegeld. Dat verandert niet.
Wat er nieuw bij moetEen aanbieder bijzetten, geen verbouwing. Dát is wat Zet 1 in de praktijk betekent, en de twee datums zetten er een klok op.
Voor de bouwer: src/routes/identityOidc.js → /api/identity/verify → verzegeld in src/identity/evidenceVault.js.
Waar dit in de app landt
Via de app: op de bestaande identiteitslaag, als vertaalstuk. Een EUDI-attestatie (SD-JWT VC via OpenID4VP) komt binnen langs src/routes/identityOidc.ts, wordt identities.person_hash — de uniciteitssleutel die er al is — en het bewijsmateriaal gaat verzegeld naar src/identity/evidenceVault.ts, met elke inzage gelogd in evidence_access_log. De rail eronder verandert niet.
In de app: de gebruiker merkt er bijna niets van, en dat is het punt: op 🪪 Jouw pas kiest hij zijn overheidswallet in plaats van itsme, en de rest van de app werkt identiek.
Eerst nodig: de acceptatieplicht (24-12-2027) geldt voor banken en verzekeraars, niet voor R4M. Wij zijn de leverancier, niet de verplichte partij — dat onderscheid moet in de pitch staan.
Uitleg & opmerkingen
Hoe het aansluit: de brug EUDI → x401 is geen nieuw product maar een vertaalstuk bovenop wat er al ligt. Belangrijker is wat de datums doen met de pitch: ze zetten een klok op Zet 2 en op blok D1. Een gesprek dat begint met “over zestien maanden moet u dit verplicht aanvaarden” loopt anders dan een gesprek dat begint met een goed idee.
Via de app: de voordeur bestaat al: GET /api/identity/itsme/login en GET /api/identity/itsme/callback (OIDC, bouwbrug 11a). Die callback maakt bij een eerste login een worker aan en bewaart operationeel alleen een gezouten hash; het door de provider getekende bewijs gaat verzegeld naar src/identity/evidenceVault.ts. De klok verandert daar één ding aan: dezelfde callback moet straks náást itsme ook een EUDI-issuer aankunnen — een tweede provider in dezelfde route, geen tweede systeem. De x401-claims (meerderjarig, gemachtigd namens een organisatie) komen uit exact diezelfde flow. De gate blijft founder-actie #1, de Signicat-sandbox: zonder die sleutel is dit blind bouwen.
HR-voorbeeld: een werkgever die vandaag een kopie van je identiteitskaart in een mapje bewaart, heeft een datalek in huis. Straks vraagt hij alleen nog “bewijs dat je meerderjarig bent en hier mag werken” en krijgt hij precies dát antwoord terug — geen kopie, geen mapje. Dat is de selective disclosure waar x401 op leunt.
Waarom het kan mislukken: de Commissie twijfelde zelf al publiek of alle lidstaten die eerste datum halen. Een deadline waar de wetgever soepel mee omgaat, is geen deadline meer — en dan sta je met een kaartlezer voor een pasje dat nog niemand heeft. Deze twee datums horen mét die kanttekening op de tab, nooit zonder.
Bron: EU-Commissie — de verordening · Namirial — status per lidstaat
Onder de motorkap — routes, tabellen, test
Waar het in de code landt: de voordeur bestaat al voor itsme: de omleiding en het terugkeerpunt in src/routes/identityOidc.ts, met oidc_flows als tussenopslag. Wat er binnenkomt wordt één rij in identities (de code per persoon) plus een verzegelde kopie via src/identity/evidenceVault.ts in identity_evidence, en elke inzage daarvan wordt gelogd in evidence_access_log.
Wat er nieuw bij moet: de wallet levert een ander soort bewijs aan dan itsme (een ondertekende attestatie in plaats van een aanmeldresultaat). Dat is één extra vertaalstap in dezelfde module, niet een tweede identiteitslaag. De rest van de app merkt er niets van, want die kijkt alleen naar de code in identities.
Hoe je het test: dezelfde weg als de itsme-brug: eerst tegen een testomgeving, dan pas echt. Zolang die testomgeving er niet is, is dit een datum op de kalender en geen bouwopdracht.
NIEUW 08-08-2026 03:45BOUWENthuisveld — alle blokken bestaan al
DR9 · De sollicitatie waar geen deepfake doorkomt
Vier stappen, allemaal op bestaande blokken. Eén: de robot van een recruiter wil een kandidaat bereiken en betaalt daarvoor 20 cent (x402, bewezen op testnet). Twee: diezelfde robot moet bewijzen dat hij écht namens dat bedrijf handelt (x401, blok D1). Drie: de kandidaat aan de andere kant is bewijsbaar één echt mens (Pass). Vier: de kandidaat krijgt die 20 cent — het is zijn aandacht.
Simpel gezegd: “Twee mensen die hun badge laten zien vóór ze beginnen te praten — en wie gestoord wordt, krijgt een koffie voor zijn tijd.”
Zo bouw je dit in
Wat de gebruiker zietDe kandidaat kiest een naam voor zijn inbox, zet zijn eigen prijs en haalt zijn geld op — die drie knoppen bestaan al. Nieuw is één schakelaar: “alleen robots met een geldig bewijs mogen mij bereiken”.
Wat de app zelf doetEen robot die een bericht wil sturen krijgt eerst te horen wat het kost, betaalt, en pas dan komt het bericht binnen. Het bedrag wordt meteen verdeeld: het grootste deel naar de kandidaat.
Wat er nieuw bij moetAlleen de badge-controle vóór de betaalpoort. Die wordt apart geprototypeerd en pas na review ingebracht — de rest draait al.
Voor de bouwer: ingang /inbox/:handle; prijs per inbox via src/x402/paywall.js; boeking in src/routes/inbox.js; uitbetaling via src/settlement/settler.js; badge-controle uit r4m-x401-proto (blok D1).
Waar dit in de app landt
Via de app: volledig op bestaande onderdelen. Stap 1 (betalen) is POST /inbox/:handle met de dynamische prijs uit inboxes.price_micro in src/x402/paywall.ts. Stap 2 (de baas bewijzen) is de x401-voordeur uit blok D1 — het enige stuk dat nog niet bestaat, en de reden dat r4m-x401-proto eerst apart gebouwd wordt. Stap 3 (één echte kandidaat) is identities.person_hash, met de sybil-regel die al door de tests gedekt is. Stap 4 (de kandidaat krijgt het geld) is de 88/8/4-splitsing — niet te verwarren met de 20-40-40-verdeling van UiTPAS, die van een klant is (pashouder 20%, organisator 40%, lokaal bestuur 40%). Twee verdeelsleutels, twee eigenaars: 88/8/4 is de onze en staat in src/routes/marketplace.ts, met de bon uit DR1 erbovenop.
In de app: de kandidaat zet zijn bedrag op Jouw prijs per bericht, ziet de recruiter binnenkomen bij Ontvangen berichten, en de 20 cent verschijnt bij Verdiensten — wie betaalde jou. Drie schermen die vandaag al bestaan; er komt één regel bij die zegt of de afzender zijn baas bewezen heeft.
Eerst nodig: stap 2 bestaat nog niet. Zonder de x401-voordeur is dit een betaalde inbox met een sybil-check — nuttig, maar niet het verhaal.
Uitleg & opmerkingen
Hoe het aansluit: er is niets nieuws voor nodig. Inbox402 werkt, Pass werkt, StaffCard402 staat beschreven, en de x401-voordeur is blok D1 met een eigen prototype. Dit blok is geen nieuw product maar de eerste verticaal waarin die drie samen een verhaal vormen dat een HR-directeur in één zin navertelt.
Via de app: dit is grotendeels al gebouwd, en dát is het punt. De premiemachine staat er: POST /api/bounties/:id/refer legt de eerste aanraking vast, POST /api/bounties/referrals/:id/attest-hire en attest-tenure zijn de twee betaalmomenten, en GET /api/bounties/fiscal/281_50 levert de Belgische fiscale fiche. De betaalde inbox staat er (POST /api/inbox/register, levering via /inbox/:handle achter de paywall). Pass staat er. Het enige nieuwe is de x401-controle vóór die deur: technisch één middleware naast mountPaywall() in src/app.ts. De paywall levert nu al het betalersadres via de X-PAYMENT-header; x401 voegt eraan toe wíé die betaler is. Twee headers, één deur.
HR-voorbeeld: dit ís het HR-voorbeeld. Nep-recruiters, deepfake-directeurs die om een overschrijving vragen en kandidaten die niet bestaan — alle drie sterven ze aan dezelfde deur. Dat deepfake-kandidaten in video-interviews een reëel probleem zijn, is in 2026 gedocumenteerd; Proof bouwt er zelf een verkoopverhaal omheen.
Waarom het kan mislukken: een betaalde inbox werkt pas als er aan beide kanten iemand staat. Eén kant bouwen is een halve brug. En recruiters betalen vandaag liever niets dan 20 cent — het bewijs moet dus niet zijn “het werkt technisch” maar “een recruiter heeft het écht betaald”. Klein en warm beginnen, in één sector waar we zelf mensen kennen.
Bron: Jones Walker — de deepfake-kandidaat · Proof — hiring fraud
Onder de motorkap — routes, tabellen, test
Waar het in de code landt — vier stappen, drie bestaan al:
1 · Betalen. POST /inbox/:handle achter de x402-deur uit src/x402/paywall.ts; de prijs staat per handle in inboxes. Bewezen op testnet.
2 · Bewijzen wie de afzender is. Dit is het enige nieuwe: een controle vóór de betaaldeur, als extra tussenstap in src/app.ts waar de deur nu al gemonteerd wordt. Dat is blok D1, met eigen prototype.
3 · Bewijzen dat de ontvanger één echt mens is. Bestaat: POST /api/identity/verify en de code per persoon in identities; dezelfde controle die elders een tweede account van dezelfde mens weigert.
4 · Uitbetalen. Bestaat: POST /api/inbox/:handle/withdraw met src/x402/payouts.ts, geboekt in ledger en zichtbaar in het publieke kasboek.
Hoe je het test: npm run demo draait de hele economie in twaalf stappen door, inclusief het weigeren van een tweede account van dezelfde persoon. Slaagt die, dan werkt de motor onder dit verhaal.