Vorige week beschreven we hoe PolitiCap-regio’s software en data pullen in plaats van pushes te ontvangen. Dat sloot één risicoklasse: onbeheerde hosts krijgen nooit onze deploy-sleutels.
Er bleef een ander gat. Wat als de lokale operator vijandig wordt en gewoon nep-fills in de regionale database stopt, waarna de trade-batch ze naar de hub stuurt?
Het antwoord is dezelfde ruggengraat die al geld beweegt in de 3DN family: het DutchBud-ledger. Elke gesyndiceerde fill moet een banking-receipt dragen. Geen zegel, geen acceptatie.
De aanval in één beeld
Controle over de regionale host betekent controle over MySQL en de node-API-sleutel. Tekenen met een sleutel op dezelfde box helpt niet. Het enige duurzame bewijs is een receipt gemint waar het geld al leeft: het closed-loop ledger van DutchBud (dibs / virtual credits).
Hoe een echte fill nu reist
- Match — MarketMaker of Broker cross op de regionale API.
- Seal — DutchBud boekt de notional-legs en geeft
ledger_ref+ledger_code(HMAC gebonden aan symbol, qty, prijs, partijen, reference). - Outbox — alleen rijen met beide velden gaan de batch in. Ongesigneerde inserts tellen niet voor syndicatie.
- Hub-ingest — per batchregel vraagt de hub DutchBud om te verifiëren en de receipt één keer te consumeren. Mismatch, geen zegel of replay → reject.
Trust-perimeter
Minten blijft op de banking-rol — de hoogste trust-perimeter in onze fintech-stack. Regionale nodes mogen een seal aanvragen; ze kunnen geen geldige ledger_code verzinnen buiten die perimeter.
De hub mint niet. Hij verifieert alleen. Zo blijft managed hosting eerlijk: edges mogen minder vertrouwd zijn dan het geldvlak zonder multi-city markten te breken.
3DN bouwt infrastructure en compute voor operators die controle willen zonder chaos. Pull sloot het deploy-kanaal. Ledger-receipts sluiten het nep-tape-kanaal. Het net is strakker — niet omdat we elke box vertrouwen, maar omdat we dozen geen bank meer laten spelen.
Architectuurstuk: Pull, geen push.
Geef een reactie