Terug naar orders

Swappie P2P Whitepaper

Technische architectuur voor trustless peer-to-peer Bitcoin handel via iDEAL

Inhoudsopgave

  1. 1. Introductie
  2. 2. Doel van het project
  3. 3. Probleemstelling
  4. 4. Architectuuroverzicht
  5. 5. Het Multisignature Contract
  6. 6. De Tikkie/iDEAL Payment Oracle
  7. 7. Tikkie/iDEAL Integratie
  8. 8. CLTV Timelock en Automatische Refund
  9. 9. Transactiekosten (Mining Fees)
  10. 10. Veiligheidsmodel
  11. 11. Order Lifecycle
  12. 12. Privacy en Data
  13. 13. Beschikbaarheid
  14. 14. Juridische en regulatoire analyse
  15. 15. Legal Opinion
  16. 16. Governance
  17. 17. Oracle: aansprakelijkheid en rol
  18. 18. Risk Disclosure
  19. 19. Compliance-strategie
  20. 20. API en bankrelaties
  21. 21. Security
  22. 22. Disclaimer

1. Introductie

Swappie P2P is een non-custodial peer-to-peer marktplaats voor Bitcoin. Het platform stelt kopers en verkopers in staat om direct met elkaar te handelen zonder dat een centrale partij fondsen beheert of transacties goedkeurt. De veiligheid wordt niet gegarandeerd door escrow of vertrouwen, maar door cryptografische contracten op de Bitcoin blockchain.

De kern van het systeem bestaat uit drie componenten:

  1. Een 2-of-2 multisignature contract tussen de verkoper en een onafhankelijke oracle
  2. Een Tikkie/iDEAL payment oracle die de betaalstatus verifieert via de iDEAL API
  3. Een CLTV timelock die het refund-pad na 14 dagen activeert, waarmee de verkoper zijn fondsen kan terughalen met alleen zijn eigen sleutel

De website zelf is uitsluitend een interface. Alle waarden, voorwaarden en afspraken liggen vast in het Bitcoin contract. Het platform kan volledig functioneren zonder de website. De website begeleidt gebruikers door het proces, maar de bron van waarheid is altijd de blockchain.

2. Doel van het project

Bitcoin handelen wordt in Europa steeds lastiger gemaakt. Gecentraliseerde exchanges vereisen uitgebreide KYC-procedures (Know Your Customer): identiteitsdocumenten, selfies, adresbewijzen, en in sommige gevallen zelfs herkomst van fondsen. Voor veel gebruikers voelt dit als een onacceptabele inbreuk op hun privacy. Niet omdat zij iets te verbergen hebben, maar omdat zij hun persoonlijke gegevens niet bij nog een commercieel platform willen achterlaten.

Swappie is gebouwd vanuit de overtuiging dat Bitcoin handelen eenvoudig, privacyvriendelijk en voor iedereen toegankelijk moet zijn. Het project is ontstaan uit frustratie met de steeds hogere drempels die Europese regelgeving opwerpt voor iets dat in essentie een simpele transactie is: de ene partij heeft euro's, de andere partij heeft Bitcoin, en beide willen ruilen.

2.1 Volledig KYC-loos

Swappie vereist geen account, geen registratie en geen enkele vorm van identificatie. Er worden geen persoonsgegevens verzameld of opgeslagen. Niet van kopers, niet van verkopers, en niet van transacties. Het platform weet niet wie je bent en hoeft dat ook niet te weten, omdat de veiligheid niet afhangt van identiteit maar van cryptografische contracten.

Dit is geen bug, het is het kerndoel van het project. De architectuur is vanaf het begin ontworpen om nul kennis over gebruikers te hebben. Geen e-mailadressen, geen telefoonnummers, geen IP-logging, geen transactiegeschiedenis. Wanneer een contract verloopt of wordt afgerond, worden de bijbehorende gegevens verwijderd. Er is simpelweg niets om op te slaan.

2.2 Geen custodial risico, geen langdurige opslag

Swappie houdt op geen enkel moment fondsen aan. Bitcoin wordt uitsluitend vastgezet in on-chain multisig contracten met een harde einddatum van 14 dagen. Na die periode wordt het refund-pad actief en kan de verkoper met alleen zijn eigen sleutel de fondsen terughalen. De CLTV timelock op de blockchain dwingt dit af ongeacht de beschikbaarheid van de oracle of het platform.

Fiat geld raakt Swappie nooit aan. De iDEAL betaling gaat rechtstreeks van koper naar verkoper. Swappie ontvangt, ziet of verwerkt geen enkel geldbedrag. Het platform faciliteert uitsluitend de contractlogica.

2.3 Een Europees perspectief

Swappie is momenteel gebouwd rondom iDEAL via Tikkie, waardoor het platform direct beschikbaar is voor alle Nederlandse bankrekeningen. De architectuur is echter niet gebonden aan iDEAL. Het enige dat de oracle nodig heeft is een verifieerbare betaalstatus: een API die bevestigt of er is betaald.

Met de komst van Wero, het pan-Europese betaalinitiatief van het European Payments Initiative, ontstaat de mogelijkheid om hetzelfde model uit te breiden naar heel Europa. Wero is ontworpen als directe account-to-account betaling, vergelijkbaar met iDEAL, maar beschikbaar in alle eurozone-landen. Dit zou Swappie kunnen transformeren van een Nederlandse oplossing naar een Europese peer-to-peer Bitcoin marktplaats, zonder dat de fundamentele architectuur hoeft te veranderen. Alleen de betaaloracle wordt aangesloten op een nieuwe API.

De visie is een Europa waarin iedereen, ongeacht land of bank, eenvoudig en privacyvriendelijk Bitcoin kan handelen met een directe bankbetaling, beveiligd door wiskundige garanties in plaats van vertrouwen in een derde partij.

3. Probleemstelling

Bij traditionele peer-to-peer Bitcoin handel bestaat altijd het risico dat een van de partijen niet nakomt. De koper kan betalen zonder Bitcoin te ontvangen, of de verkoper kan Bitcoin vrijgeven zonder betaling te ontvangen. Bestaande oplossingen gebruiken doorgaans een van twee modellen:

  • Centralized escrow: Een derde partij houdt de Bitcoin vast totdat beide partijen akkoord gaan. Dit vereist volledig vertrouwen in de escrow-dienst en maakt die partij tot custodian van de fondsen.
  • Reputation-based systemen: Gebruikers handelen op basis van reputatiescores. Dit werkt tot het niet werkt. Een partij met een goede reputatie kan op elk moment besluiten niet na te komen.

Swappie lost dit op door de uitkomst van een transactie volledig te laten bepalen door verifieerbare feiten: is er betaald via iDEAL, ja of nee? Het antwoord op die vraag wordt geverifieerd door een oracle en vastgelegd in de contractlogica. Geen van de partijen hoeft de ander te vertrouwen.

4. Architectuuroverzicht

4.1 Deelnemers

Elke transactie heeft drie rollen:

  • Verkoper: Plaatst Bitcoin in het multisig contract en stelt de verkoopvoorwaarden in (prijs, Tikkie link).
  • Koper: Selecteert een order, voert een Bitcoin ontvangstadres in en betaalt via iDEAL.
  • Oracle: Een geautomatiseerde co-signer, momenteel beheerd door de oprichter van Swappie, die de iDEAL betaalstatus verifieert via de Tikkie API en het contract mede-ondertekent wanneer aan de betaalvoorwaarde is voldaan.

4.2 Systeemdiagram

┌──────────┐     ┌──────────────┐     ┌──────────┐
│ Verkoper │     │   Bitcoin     │     │  Oracle  │
│          │────▶│  Multisig     │◀────│          │
│ Key A    │     │  Contract     │     │ Key B    │
└──────────┘     │  (2-of-2)     │     └────┬─────┘
                 └──────┬───────┘          │
                        │                  │
                        ▼                  ▼
                 ┌──────────────┐   ┌──────────────┐
                 │  Bitcoin     │   │ Tikkie/iDEAL │
                 │  Blockchain  │   │     API      │
                 └──────────────┘   └──────────────┘
                        │
                        ▼
                 ┌──────────────┐
                 │    Koper     │
                 │  (ontvangt   │
                 │   Bitcoin)   │
                 └──────────────┘

5. Het Multisignature Contract

5.1 Structuur

Swappie gebruikt Taproot-gebaseerde contracten (P2TR) met een 2-of-2 multisignature constructie. De twee sleutelhouders zijn de verkoper en de oracle. De koper is geen onderdeel van het multisig, maar is de begunstigde die Bitcoin ontvangt wanneer het contract wordt vervuld. Taproot biedt de beste combinatie van privacy en efficiëntie: de interne scriptstructuur is niet publiek zichtbaar op de blockchain en de transacties zijn compacter dan bij oudere formaten. Het doel is om de contractdetails (tapleaves en scriptstructuur) in de toekomst publiekelijk beschikbaar te maken, zodat iedereen onafhankelijk kan verifiëren dat een gepubliceerd script exact overeenkomt met het on-chain P2TR-adres. Dit biedt transparantie voor wie wil controleren, zonder de privacy op de blockchain aan te tasten.

Het contract bevat de volgende elementen:

  • De publieke sleutel van de verkoper (Key A)
  • De publieke sleutel van de oracle (Key B)
  • De Tikkie link van de verkoper, opgeslagen in de metadata van het contract, zodat de oracle de betaalstatus kan verifiëren zonder een externe database
  • Het Bitcoin ontvangstadres van de koper
  • Een CLTV timelock voor automatische refund na 14 dagen

5.2 Deposit en refund mechanisme

Het contract is zo opgezet dat iedereen Bitcoin kan storten op het contractadres. Dit maakt het mogelijk om een order te plaatsen vanuit elk wallet of adres. Er is geen beperking op het aantal depositors of de herkomst van de fondsen.

Bij een refund, bijvoorbeeld wanneer de order verloopt zonder verkoop, wordt het exacte bedrag teruggestuurd naar het adres van waaruit het oorspronkelijk is gestort. Als er meerdere depositors zijn, ontvangt elke depositor precies het bedrag dat hij of zij heeft ingelegd. Dit voorkomt dat fondsen naar een verkeerd adres gaan en zorgt ervoor dat iedereen altijd zijn eigen Bitcoin terugkrijgt.

5.3 Pre-signing door de verkoper

Wanneer een verkoper een order plaatst, wordt het Bitcoin bedrag vergrendeld in het 2-of-2 multisig contract. De verkoper ondertekent op dat moment een pre-signed transactie die zegt:

"Als de iDEAL betaling is voltooid volgens de oracle, mag mijn Bitcoin worden verstuurd naar het adres van de koper."

Deze pre-signed transactie wordt vastgelegd en wacht op de tweede handtekening van de oracle. De verkoper hoeft na dit punt niets meer te doen. Het verdere proces is volledig geautomatiseerd.

5.4 Contract script (Taproot)

Het contract maakt gebruik van Taproot (P2TR) en combineert twee spend paden in een script tree. Het betaalpad en het refund-pad worden als afzonderlijke tapleaves opgenomen.

Taproot Script Tree:

Leaf 1 (Betaalpad):
    // Vereist handtekeningen van verkoper EN oracle
    // De oracle tekent uitsluitend wanneer iDEAL status "paid" is
    // Tikkie link zit in de contract metadata (OP_RETURN)
    <verkoper_pubkey> OP_CHECKSIGVERIFY
    <oracle_pubkey> OP_CHECKSIG

Leaf 2 (Refund-pad):
    // Na 14 dagen wordt het refund-pad actief
    // Na 14 dagen kan de verkoper met alleen zijn eigen sleutel refunden
    // Momenteel triggert de oracle dit automatisch namens de verkoper
    // Refund gaat naar de oorspronkelijke deposit adressen
    <locktime_14d> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <verkoper_pubkey> OP_CHECKSIG

In het betaalpad zijn beide handtekeningen vereist. De verkoper heeft al pre-signed, dus de transactie wordt pas uitgevoerd wanneer de oracle zijn handtekening toevoegt. Het bestemmingsadres wordt bepaald op het moment van spend door de oracle op basis van het adres dat de koper heeft opgegeven. In het refund-pad wordt de timelock na 14 dagen actief, waarna de verkoper technisch met alleen zijn eigen sleutel de fondsen kan terughalen. Momenteel heeft de verkoper nog geen toegang tot zijn sleutel via de interface, waardoor de oracle de refund in de praktijk automatisch triggert namens de verkoper. De Tikkie link van de verkoper wordt meegenomen in de metadata van het contract, zodat de oracle deze kan uitlezen zonder een externe database te raadplegen.

6. De Tikkie/iDEAL Payment Oracle

6.1 Wat is de oracle?

De oracle is een dienst die als enige taak heeft, vaststellen of een iDEAL betaling daadwerkelijk is voltooid. De oracle kan niet eenzijdig fondsen verplaatsen. Hij kan uitsluitend het contract mede-ondertekenen wanneer de betaalvoorwaarde waar is.

De oracle functioneert als een brug tussen het traditionele betalingssysteem (iDEAL/Tikkie) en de Bitcoin blockchain. Hij vertaalt een fiat-betaalstatus naar een cryptografische handtekening.

Huidige status: De oracle wordt momenteel beheerd door de oprichter van Swappie. De oracle draait dus gecentraliseerd als onderdeel van de Swappie-infrastructuur. De oprichter is zowel verantwoordelijk voor de website als voor de oracle. Dit wordt niet verhuld: het is een bewuste keuze in deze fase van het project. Het plan is om in de toekomst naar een meer open en gedecentraliseerd model te bewegen, waarbij meerdere onafhankelijke oracles dezelfde betaalstatus verifiëren. Dit vereist zorgvuldige afwegingen rondom de beveiliging van API endpoints en het voorkomen van misbruik.

6.2 Verificatieproces

Wanneer een koper een order selecteert en het koopproces start, genereert het systeem via de Tikkie API een iDEAL betaallink met een vast bedrag. Het verificatieproces verloopt als volgt:

  1. Betaallink generatie: Via de Tikkie API wordt een iDEAL betaling gegenereerd met het exacte bedrag dat op dat moment geldt voor de order. Bij een vaste prijs is dit het vooraf ingestelde bedrag. Bij een dynamische (fluid) prijs wordt het bedrag berekend op het moment van generatie op basis van de actuele marktkoers.
  2. Status polling: Na het genereren van de betaallink controleert de oracle zes keer op vaste intervallen of de betaling is voltooid. Dit gebeurt door de status-endpoint van de Tikkie API te raadplegen.
  3. Betaallink verloop: De betaallink verloopt voordat de laatste controle plaatsvindt. Dit garandeert dat een betaling die wordt uitgevoerd altijd wordt opgepikt door de oracle. Er is geen moment waarop een betaling kan plaatsvinden zonder dat de oracle het ziet.
  4. Statusvalidatie: De oracle controleert de JSON response van de Tikkie API op de status PAID. Alleen wanneer deze status aanwezig is, beschouwt de oracle de betaalvoorwaarde als vervuld.
  5. Ondertekening: Bij een bevestigde betaling ondertekent de oracle het contract automatisch. Samen met de pre-signed handtekening van de verkoper vormt dit de 2-of-2 vereiste, waarna de Bitcoin wordt vrijgegeven naar het adres van de koper.

6.3 Wat de oracle controleert

De oracle verifieert de volgende status via de Tikkie/iDEAL API:

  • Betaalstatus: De Tikkie API retourneert uitsluitend een status: PAID, EXPIRED of DELETED. De oracle ondertekent alleen wanneer de status PAID is.

De Tikkie API geeft geen informatie over het betaalde bedrag, de identiteit van de betaler of de bankgegevens van betrokken partijen. Swappie ontvangt uitsluitend de betaalstatus en verder niets. Een niet-voltooide, verlopen of verwijderde betaling resulteert niet in ondertekening.

6.4 Huidige werking en toekomstvisie

In de huidige implementatie draait de oracle als onderdeel van de Swappie backend. De oracle raadpleegt de Tikkie/iDEAL API, verifieert de betaalstatus en ondertekent het contract wanneer aan de voorwaarden is voldaan. Dit proces verloopt volledig geautomatiseerd zonder menselijke tussenkomst.

Het doel is om de oracle op termijn los te koppelen van de website, zodat deze onafhankelijk kan functioneren. Technisch gezien heeft de oracle alleen de Tikkie API en het Bitcoin contract nodig om te werken. De website automatiseert en visualiseert het proces, maar is architecturaal geen vereiste voor de werking van het contract.

7. Tikkie/iDEAL Integratie

7.1 Open bedrag mechanisme

Swappie maakt gebruik van de Tikkie API met open bedrag. Dit betekent dat er niet vooraf een vast bedrag aan de Tikkie link is gekoppeld. In plaats daarvan wordt het exacte bedrag bepaald op het moment dat de koper daadwerkelijk de aankoop start.

Dit maakt twee prijsmodellen mogelijk:

  • Vaste prijs: De verkoper stelt een vast eurobedrag in per order. Bij aankoop wordt dit bedrag direct gebruikt voor de iDEAL betaling.
  • Dynamische (fluid) prijs: De verkoper stelt een prijsstructuur in die gekoppeld is aan de actuele Bitcoin marktkoers. Op het moment dat de koper koopt, wordt de actuele waarde berekend en vastgezet als het iDEAL bedrag. Zo betaalt de koper altijd de actuele marktwaarde.

Het open bedrag mechanisme garandeert dat de prijsafspraak van de verkoper altijd wordt nageleefd, ongeacht wanneer de koper besluit te kopen.

7.2 Betaalstroom

  1. Koper selecteert een order en voert een Bitcoin ontvangstadres in
  2. Het systeem berekent het exacte eurobedrag op basis van de prijsstructuur van de verkoper
  3. Via de Tikkie API wordt een iDEAL betaallink gegenereerd met dit vaste bedrag
  4. De koper betaalt via iDEAL. Het geld gaat rechtstreeks van koper naar verkoper
  5. Swappie ontvangt of beheert op geen enkel moment fiat geld
  6. De oracle verifieert de betaalstatus via de API
  7. Bij bevestiging wordt het contract ondertekend en Bitcoin vrijgegeven

8. CLTV Timelock en Automatische Refund

8.1 Waarom 14 dagen?

Elk contract heeft een harde einddatum van 14 dagen na aanmaak. Deze periode is bewust gekozen omdat het de maximale geldigheidsduur is van een Tikkie betaallink. Na 14 dagen is het technisch niet meer mogelijk om via de Tikkie link te betalen, wat betekent dat de betaalvoorwaarde van het contract nooit meer kan worden vervuld.

8.2 Hoe de timelock werkt

Het contract bevat een OP_CHECKLOCKTIMEVERIFY (CLTV) clausule. Dit is een Bitcoin Script opcode die een transactie ongeldig maakt totdat een bepaald tijdstip is bereikt. Na dat tijdstip wordt het refund-pad van het contract actief:

  • Het refund-pad wordt actief na het verstrijken van de timelock
  • Het refund-pad vereist technisch alleen de sleutel van de verkoper — de oracle is hiervoor niet nodig
  • Momenteel heeft de verkoper nog geen toegang tot zijn sleutel via de interface, waardoor de oracle de refund in de praktijk automatisch triggert
  • Het plan is om key-export in de toekomst beschikbaar te maken, zodat de verkoper volledig zelfstandig kan refunden

Dit mechanisme waarborgt dat fondsen technisch nooit permanent vastzitten in een contract: het refund-pad is na 14 dagen beschikbaar met alleen de verkoper-sleutel. In de huidige implementatie triggert de oracle de refund automatisch namens de verkoper.

8.3 Veiligheidsmarge

Om te voorkomen dat een koper precies op het moment van de timelock betaalt (wat tot een race condition zou leiden), hanteert het platform een veiligheidsmarge. Orders worden op de website al circa een uur voor de daadwerkelijke contractverloop niet meer getoond als beschikbaar. Zo is er altijd een buffer tussen de laatste mogelijke betaling en het activeren van het refund-pad.

9. Transactiekosten (Mining Fees)

9.1 Geen platformkosten — zero-fee architectuur

Swappie hanteert een principieel zero-fee model. Het platform rekent geen commissies, servicefees, spreadopslagen, inhoudingen of enige andere vorm van vergoeding. Dit is geen marketingstrategie of tijdelijke actie, maar een architecturaal kenmerk van het protocol: elke transactie verloopt rechtstreeks van het contractadres naar het ontvangende adres van de koper, zonder tussenliggende adressen of afsplitsingen. Er is technisch geen mechanisme ingebouwd om fees te heffen.

Swappie is ontwikkeld als een hulpmiddel voor de Bitcoin-gemeenschap, zonder winstoogmerk en zonder commercieel verdienmodel. Het project wordt onderhouden als een solo-developer initiatief met als enige doel het faciliteren van veilige, peer-to-peer Bitcoin-transacties via het bestaande Nederlandse betaalverkeer. Er zijn geen investeerders, geen tokenomics en geen plannen om in de toekomst fees te introduceren.

De enige kosten die van toepassing zijn op een transactie, zijn Bitcoin netwerkkosten (mining fees). Deze zijn inherent aan elke blockchain-transactie en worden niet door Swappie bepaald, maar door het Bitcoin-netwerk zelf.

9.2 Dynamische fee-berekening

De mining fee wordt berekend op het moment van de release-transactie (wanneer Bitcoin naar de koper wordt verstuurd). Dit is bewust, omdat de hoogte van de fee afhangt van:

  • Het adrestype van de koper: Verschillende Bitcoin adresformaten (Legacy, SegWit, Native SegWit, Taproot) vereisen verschillende transactiegroottes en dus verschillende fees. Het systeem optimaliseert voor de laagst mogelijke fee.
  • Netwerkcondities: De actuele mempool-drukte bepaalt het optimale fee-tarief op het moment van verzending.

De mining fee wordt verrekend met het bedrag dat de koper ontvangt. Dit wordt transparant getoond voordat de transactie wordt uitgevoerd.

10. Veiligheidsmodel

10.1 Veiligheidsgaranties

  • Swappie kan geen fondsen stelen: De oracle beschikt over één van de twee sleutels in het multisig contract en is ontworpen om uitsluitend te ondertekenen naar het adres dat de koper heeft opgegeven. De oracle heeft geen financieel belang bij transacties (zero-fee). De website is een interface, geen custodian.
  • De verkoper kan niet weglopen met het geld: De Bitcoin zit vergrendeld in het 2-of-2 contract. De verkoper kan alleen via het refund-pad (na 14 dagen) of via het betaalpad (na bevestigde iDEAL betaling) bij de fondsen.
  • De koper kan niet betalen zonder Bitcoin te ontvangen: De oracle ondertekent automatisch wanneer de betaling is bevestigd. Er is geen menselijke tussenkomst nodig.
  • Fondsen kunnen technisch niet permanent vastzitten: De CLTV timelock activeert het refund-pad na 14 dagen. Het refund-pad vereist alleen de verkoper-sleutel. Momenteel triggert de oracle de refund automatisch namens de verkoper.

10.2 Vertrouwensmodel van de oracle

De oracle is het enige punt waar een beperkte mate van vertrouwen vereist is. Het vertrouwensmodel is als volgt:

  • De oracle is ontworpen om niet te stelen: De oracle ondertekent uitsluitend naar het adres dat de koper heeft opgegeven. De oracle-software is geautomatiseerd en heeft geen financieel belang bij transacties.
  • De oracle kan alleen maar ondertekenen of niet ondertekenen: Bij niet-ondertekenen loopt het contract af na 14 dagen, waarna het refund-pad actief wordt. Het refund-pad vereist alleen de verkoper-sleutel en is onafhankelijk van de oracle.
  • De oracle verifieert objectieve feiten: De oracle controleert geen subjectieve claims, maar een objectieve API response van iDEAL/Tikkie. De betaling is voltooid of niet. Er is geen ruimte voor interpretatie.

Het worst-case scenario is dat de oracle niet beschikbaar is of weigert te ondertekenen. In dat geval kan het betaalpad niet worden getriggerd totdat de oracle weer online is. Het refund-pad vereist echter alleen de verkoper-sleutel en is na 14 dagen beschikbaar onafhankelijk van de oracle. Momenteel heeft de verkoper nog geen toegang tot zijn sleutel via de interface, waardoor de oracle de refund in de praktijk triggert. De beheerder spant zich in om de oracle zo snel mogelijk te herstellen bij uitval. Key-export voor verkopers is gepland als toekomstige functionaliteit. Belangrijk: de oracle ondertekent uitsluitend wanneer de iDEAL API de status PAID retourneert. Zonder daadwerkelijke betaling wordt er geen Bitcoin vrijgegeven.

10.3 Geen custodial risico

Swappie is op geen enkel moment in het proces custodian van fondsen:

  • Bitcoin wordt vergrendeld in een on-chain contract, niet op een Swappie wallet
  • Fiat geld gaat rechtstreeks van koper naar verkoper via iDEAL
  • Er worden geen private sleutels van gebruikers opgeslagen door het platform. De oracle beschikt over een eigen sleutel die op gescheiden infrastructuur wordt bewaard
  • Er zijn geen accounts of deposito's

11. Order Lifecycle

Een volledige transactie doorloopt de volgende stappen:

  1. Order aanmaken (verkoper):
    • Verkoper stelt prijsstructuur in (vast of dynamisch)
    • Verkoper voert zijn Tikkie link in (open bedrag)
    • Bitcoin wordt vergrendeld in het 2-of-2 multisig contract
    • Verkoper pre-signed de release-transactie
    • CLTV timelock wordt ingesteld op 14 dagen
  2. Order live:
    • Order verschijnt op de marktplaats
    • Toont BTC bedrag, prijs in EUR en resterende looptijd
    • Order verdwijnt automatisch circa een uur voor contractverloop
  3. Koper selecteert order:
    • Koper voert Bitcoin ontvangstadres in
    • Systeem berekent exact eurobedrag
    • iDEAL betaallink wordt gegenereerd via Tikkie API
  4. Betaling:
    • Koper betaalt via iDEAL
    • Geld gaat direct van koper naar verkoper
    • Oracle start verificatie (6 controles)
  5. Verificatie en release:
    • Oracle detecteert status PAID in Tikkie API response
    • Oracle ondertekent het contract (2e handtekening)
    • Bitcoin wordt vrijgegeven naar het adres van de koper
    • Mining fee wordt dynamisch berekend en verrekend
  6. Refund (indien niet verkocht):
    • Na 14 dagen activeert de CLTV timelock het refund-pad
    • Refund-pad vereist alleen de verkoper-sleutel; momenteel triggert de oracle dit automatisch
    • Bitcoin keert terug naar het oorspronkelijke adres van de verkoper

12. Privacy en Data

Swappie slaat geen direct identificeerbare persoonsgegevens op. Alle gegevens die worden verwerkt zijn anonieme technische gegevens:

  • Er is geen registratie of account vereist
  • Er worden geen namen, e-mailadressen of telefoonnummers opgeslagen
  • De interface toont uitsluitend tijdelijke contractgegevens en betaalstatusinformatie
  • Na het verstrijken of afronden van een contract worden alle bijbehorende gegevens binnen 24 uur permanent verwijderd
  • De iDEAL betaling is een directe transactie tussen koper en verkoper. Swappie ziet alleen de status, niet de bankgegevens

13. Beschikbaarheid

Het platform is beschikbaar via twee kanalen:

  • Website: swappie.online is de primaire interface voor het bekijken, plaatsen en kopen van orders.
  • Telegram bot: Dezelfde contractinteractie is beschikbaar via de Swappie Telegram bot. De onderliggende werking is identiek aan die van de website.

Beide interfaces communiceren met dezelfde contracten op de Bitcoin blockchain. Een order die via de website is aangemaakt kan via Telegram worden bekeken en vice versa.

14. Juridische en regulatoire analyse

De juridische positie van Swappie is getoetst in overleg met Jaeger Advocaten-belastingkundigen. Op basis van de technische architectuur en het operationele model is geconcludeerd dat Swappie niet kwalificeert als financiele dienstverlener en buiten de reikwijdte valt van KYC-wetgeving en toezichtregels voor crypto-aanbieders. Hieronder volgt een gedetailleerde analyse per regelgevingskader.

14.1 MiCA (Markets in Crypto-Assets Regulation)

De Europese MiCA-verordening vereist dat Crypto-Asset Service Providers (CASPs) een vergunning aanvragen. Een CASP is een entiteit die crypto-assets bewaart, verhandelt, uitwisselt of overdraagt namens derden. Swappie valt niet onder deze definitie om de volgende redenen:

  • Geen bewaarneming (custody): Swappie bewaart op geen enkel moment crypto-assets. Bitcoin wordt vergrendeld in een on-chain 2-of-2 multisig contract. De oracle, die momenteel door de oprichter van Swappie wordt beheerd, beschikt over één van de twee sleutels en is ontworpen om uitsluitend te ondertekenen naar het adres dat de koper heeft opgegeven.
  • Geen uitwisseling (exchange): Swappie voert geen uitwisseling uit van crypto tegen fiat. De fiat-betaling verloopt rechtstreeks van koper naar verkoper via iDEAL. De crypto-overdracht wordt uitgevoerd door het contract op de blockchain. Swappie is in geen van beide transacties partij.
  • Geen overdracht namens derden: De overdracht van Bitcoin wordt getriggerd door de contractlogica na verificatie van de betaalstatus door de oracle. De oracle, hoewel momenteel beheerd door de oprichter van Swappie, handelt als geautomatiseerde co-signer op basis van een objectieve API-response.
  • Geen orderuitvoering: Swappie koppelt geen kopers aan verkopers en voert geen orders uit. Het platform toont beschikbare contracten. De gebruiker kiest zelf welk contract hij aangaat.

Swappie functioneert als een technische interface voor interactie met bestaande contractmechanismen op de Bitcoin blockchain. Dit valt onder de categorie van technische dienstverlening, niet onder de definitie van een CASP volgens MiCA Art. 3(1)(16).

14.2 AMLD5 / AMLD6 (Anti-Money Laundering Directives)

De Europese anti-witwasrichtlijnen (AMLD5 en AMLD6) verplichten entiteiten die crypto-diensten aanbieden tot het uitvoeren van KYC-procedures en het melden van verdachte transacties. Deze verplichtingen zijn van toepassing op entiteiten die:

  • Crypto-assets bewaren of beheren namens klanten
  • Crypto-assets uitwisselen tegen fiat of andere crypto-assets
  • Klantrelaties onderhouden

Swappie voldoet aan geen van deze criteria. Er worden geen klantrelaties onderhouden (er zijn geen accounts). Er vindt geen bewaarneming plaats (fondsen zitten in on-chain contracten). Er wordt geen uitwisseling uitgevoerd (de contractlogica en het betaalsysteem doen dit autonoom). Er is geen informatie beschikbaar om verdachte transacties te melden, omdat het platform geen kennis heeft van de identiteit van gebruikers.

14.3 Nederlandse regelgeving (AFM / DNB)

In Nederland is De Nederlandsche Bank (DNB) de toezichthouder voor crypto-dienstverleners. Registratie bij DNB is verplicht voor partijen die crypto-wisseldiensten of bewaarportemonnees aanbieden. De Autoriteit Financiële Markten (AFM) houdt toezicht op beleggingsdiensten.

  • Geen crypto-wisseldienst: Swappie wisselt geen crypto tegen fiat. De fiat-betaling is een directe iDEAL-transactie tussen koper en verkoper. De crypto-overdracht is een autonome contractexecutie op de blockchain.
  • Geen bewaarportemonnee: Swappie biedt geen wallet-dienst aan. Het platform bewaart geen private sleutels en heeft geen toegang tot fondsen van gebruikers.
  • Geen beleggingsdienst: Swappie biedt geen beleggingsadvies, vermogensbeheer of orderuitvoering aan. Het platform is een technische interface, geen financieel adviseur of broker.
  • Geen VASP (Virtual Asset Service Provider): Swappie kwalificeert niet als VASP onder de Wwft (Wet ter voorkoming van witwassen en financieren van terrorisme). Het platform draagt geen virtuele activa over, bewaart ze niet en wisselt ze niet uit namens derden. Alle acties worden geïnitieerd en uitgevoerd door de gebruikers zelf: de verkoper vergrendelt Bitcoin in een multisig contract, de koper betaalt via iDEAL en het contract wordt afgewikkeld door de oracle op basis van een objectieve betaalstatus. Swappie handelt op geen enkel moment namens een gebruiker.

Op basis van deze analyse is registratie bij DNB of een vergunning van de AFM niet vereist. Het platform opereert als een technische dienstverlener die een interface biedt voor interactie met blockchain-contracten.

14.4 PSD2 (Payment Services Directive)

PSD2 reguleert betaaldienstverleners in de EU. Een betaaldienstverlener is een entiteit die betaaltransacties uitvoert, betalingsrekeningen beheert of geld overmaakt namens klanten.

  • Geen betaaldienst: Swappie verwerkt geen betalingen. De iDEAL betaling wordt geïnitieerd door de koper en uitgevoerd door de bank van de koper via het iDEAL/Tikkie netwerk. Swappie is geen partij in de betaalstroom.
  • Geen geldoverdracht: Swappie maakt geen geld over en beheert geen betaalrekeningen. Het platform leest uitsluitend een betaalstatus (betaald/niet betaald) via de Tikkie API.
  • Geen money transmitter: Swappie ontvangt, bewaart of verzendt op geen enkel moment fiat geld. De betaling gaat direct van de bankrekening van de koper naar de bankrekening van de verkoper. Swappie ontvangt via de Tikkie API uitsluitend een betaalstatus (PAID, EXPIRED of DELETED), geen bedrag, geen bankgegevens en geen identiteit van de partijen.

14.5 Classificatie: waarom Swappie geen exchange, broker of CASP is

Samengevat past Swappie niet in de gangbare classificaties van financiele dienstverleners:

  • Geen exchange: Een exchange matcht kopers en verkopers en voert transacties uit. Swappie toont beschikbare contracten. De gebruiker kiest zelf, betaalt zelf en ontvangt Bitcoin via het contract. Swappie voert niets uit.
  • Geen broker: Een broker handelt namens klanten. Swappie handelt niet namens wie dan ook. Alle acties worden geïnitieerd en voltooid door de gebruiker zelf.
  • Geen CASP: Een CASP verleent diensten met betrekking tot crypto-assets (bewaring, uitwisseling, overdracht). Swappie doet geen van deze drie. Het contract op de blockchain doet de overdracht. De iDEAL-betaling doet de uitwisseling. Het multisig contract doet de bewaring.
  • Geen money transmitter: Een money transmitter verplaatst geld namens derden. Swappie raakt geen geld aan. De fiat-betaling gaat direct via het banksysteem, de crypto-overdracht gaat direct via de blockchain.

Swappie is een technische dienstverlener die een interface biedt voor interactie met een bestaand, autonoom contractmechanisme. De rol is vergelijkbaar met die van een blockchainverkenner (block explorer) of een wallet-interface: het toont data en vereenvoudigt interactie, maar beheert geen fondsen en voert geen transacties uit.

15. Legal Opinion

De bovenstaande analyse is getoetst en bevestigd door Jaeger Advocaten-belastingkundigen. Het advocatenkantoor heeft een legal opinion opgesteld die het volgende bevestigt:

  • Classificatie: Swappie kwalificeert als technische dienstverlener en niet als crypto-asset service provider (CASP), betaaldienstverlener, exchange, broker of money transmitter.
  • Regelgevingsanalyse: Op basis van de huidige EU- en Nederlandse regelgeving (MiCA, AMLD5/6, Wwft, PSD2) is registratie bij DNB of een vergunning van de AFM niet vereist voor het aanbieden van een technische interface voor blockchain-contracten.
  • Risicobeoordeling: Het operationele model van Swappie introduceert geen custodial risico, geen betaalrisico en geen witwasrisico vanuit het perspectief van het platform, aangezien het platform geen fondsen beheert, geen transacties uitvoert en geen persoonsgegevens verwerkt.

Het volledige legal opinion document is op verzoek beschikbaar voor toezichthouders en geïnteresseerde partijen via Telegram.

16. Governance

Transparantie over wie het platform bestuurt en onderhoudt is essentieel om het onderscheid met een gecentraliseerde exchange te onderbouwen. Hieronder wordt de governance structuur van Swappie toegelicht.

16.1 Organisatiestructuur

  • Platform ontwikkeling: De website en Telegram bot worden ontwikkeld en onderhouden door de oprichter. De broncode van de interface heeft geen invloed op de contractlogica op de blockchain.
  • Oracle operatie: De oracle draait als een onafhankelijke dienst, gescheiden van de website-infrastructuur. De oracle voert uitsluitend geautomatiseerde verificatie uit op basis van de Tikkie/iDEAL API en ondertekent contracten zonder menselijke tussenkomst.
  • Hosting: De website wordt gehost op standaard webinfrastructuur. De contracten en de oracle functioneren onafhankelijk van de website. Uitval van de website heeft geen invloed op lopende contracten.
  • Inkomsten: Swappie hanteert een principieel zero-fee model zonder winstoogmerk. Er is technisch geen mechanisme ingebouwd om fees te heffen: transacties verlopen rechtstreeks van het contractadres naar de koper, zonder tussenliggende adressen. Er zijn geen investeerders, geen tokenomics en geen commercieel verdienmodel.

16.2 Decentralisatie-principes

Hoewel de website-interface gecentraliseerd wordt beheerd, is de kernfunctionaliteit gedecentraliseerd:

  • Contracten worden uitgevoerd op de Bitcoin blockchain, niet op servers van Swappie
  • Fondsen worden beheerd door het multisig contract, niet door Swappie
  • Betalingen verlopen via het iDEAL banksysteem, niet via Swappie
  • De oracle verifieert objectieve feiten via een publieke API, zonder discretionaire bevoegdheid
  • Gebruikers kunnen dezelfde contractinteractie uitvoeren zonder de website

De website is vergelijkbaar met een frontend voor een smart contract: het vereenvoudigt de interactie, maar is niet noodzakelijk voor de werking van het onderliggende systeem.

17. Oracle: aansprakelijkheid en rol

De oracle is het meest kritische onderdeel van het systeem vanuit zowel technisch als juridisch perspectief. Deze sectie beschrijft de exacte rol, verantwoordelijkheden en waarborgen rondom de oracle.

17.1 Rol en beperkingen

De oracle heeft een strikt afgebakende rol:

  • De oracle controleert uitsluitend de betaalstatus via de Tikkie/iDEAL API
  • De oracle ondertekent het contract automatisch wanneer de status PAID is bevestigd
  • De oracle is ontworpen om uitsluitend te ondertekenen naar het adres dat de koper heeft opgegeven
  • De oracle kan geen contractvoorwaarden wijzigen na aanmaak van het contract
  • De oracle heeft geen discretionaire bevoegdheid. De beslissing om te ondertekenen is een binair gevolg van de API response

17.2 Selectie en onafhankelijkheid

De oracle opereert als een onafhankelijke dienst die gescheiden is van de website-infrastructuur. De onafhankelijkheid wordt gewaarborgd door:

  • De oracle draait op een aparte infrastructuur, onafhankelijk van de webserver
  • De oracle heeft geen toegang tot de website-database of gebruikersinterface
  • De oracle communiceert uitsluitend met de Tikkie/iDEAL API en de Bitcoin blockchain
  • De oracle-software voert geen andere taken uit dan betaalstatusverificatie en contractondertekening

17.3 Faalscenario's en mitigatie

  • Oracle offline: Als de oracle niet beschikbaar is, worden geen contracten via het betaalpad ondertekend. Het refund-pad vereist alleen de verkoper-sleutel en is na 14 dagen beschikbaar onafhankelijk van de oracle. Momenteel heeft de verkoper nog geen toegang tot zijn sleutel via de interface, waardoor bij oracle-uitval de refund pas wordt getriggerd zodra de oracle weer operationeel is. De beheerder spant zich in om de oracle zo snel mogelijk te herstellen.
  • Oracle weigert te ondertekenen: Identiek aan het offline-scenario. Omdat de oracle uitsluitend ondertekent na verificatie van de iDEAL API, is het onmogelijk dat Bitcoin wordt vrijgegeven zonder dat er daadwerkelijk is betaald. De iDEAL API retourneert alleen de status PAID bij een voltooide, onomkeerbare banktransactie.
  • Oracle ondertekent onterecht (false positive): Dit kan alleen voorkomen als de Tikkie/iDEAL API een onjuiste betaalstatus retourneert. De oracle verifieert uitsluitend de betaalstatus (PAID, EXPIRED of DELETED). Alleen bij status PAID wordt ondertekend.
  • API-manipulatie: De communicatie met de Tikkie/iDEAL API verloopt via beveiligde (TLS) verbindingen met authenticatie. De API wordt beheerd door ABN AMRO (Tikkie) en het Nederlandse banksysteem (iDEAL). Manipulatie van deze API vereist compromittering van het Nederlandse banksysteem.

Beschikbaarheidscontrole bij aanvang: Voordat een betaallink wordt gegenereerd, controleert het systeem de status van de oracle. Als de oracle op dat moment niet bereikbaar is, kan de gebruiker niet doorgaan met het koopproces. De betaalpagina wordt pas geladen wanneer de oracle actief is. Dit voorkomt dat een koper een betaling start die vervolgens niet kan worden geverifieerd.

Er bestaat echter een kleine kans op een race condition. Het kan voorkomen dat een betaallink wordt gegenereerd terwijl de oracle nog online is, maar kort daarna offline gaat. In dat geval kan de betaling wel worden voltooid via iDEAL, maar kan de oracle de betaalstatus niet direct verifiëren. De verkoper kan in dit scenario het contract niet annuleren zolang de oracle offline is, wat kan betekenen dat er iets langer gewacht moet worden op de verificatie. Zodra de oracle weer beschikbaar is, wordt de betaalstatus alsnog gecontroleerd en het contract ondertekend.

In de praktijk is dit risico minimaal. De oracle provider heeft een track record van 100% uptime, en het tijdvenster tussen het genereren van een betaallink en de eerste statuscontrole is klein. De kans dat de oracle precies in dat venster offline gaat is verwaarloosbaar.

17.4 Toekomstige waarborgen

De huidige oracle-architectuur is ontworpen met toekomstige uitbreiding in gedachten:

  • Multi-oracle systeem: Meerdere onafhankelijke oracles die dezelfde betaalstatus verifiëren. Consensus tussen oracles voorkomt eenzijdige fouten.
  • Dispute resolution: Een geschillenbeslechtingsmechanisme waarbij een derde partij kan arbitreren in uitzonderlijke gevallen waar de API-status onduidelijk is.
  • Oracle-rotatie: Periodieke wisseling van de oracle-dienst om afhankelijkheid van een enkele partij te minimaliseren.

17.5 Privacy van de oracle

De oracle heeft een strikt beperkte informatiepositie. Het enige dat de oracle kan vaststellen is of een iDEAL betaling is voltooid of niet. De oracle heeft geen inzicht in:

  • De identiteit van de koper of verkoper
  • Bankgegevens van betrokken partijen
  • Het doel of de context van de transactie
  • Historische transactiepatronen of gebruikersgedrag

De oracle ontvangt van de Tikkie API uitsluitend een betaalstatus: PAID, EXPIRED of DELETED. De API retourneert geen bedrag, geen bankgegevens en geen informatie over de identiteit van betrokken partijen. De oracle functioneert als een puur binaire poortwachter: betaald of niet betaald, en verder niets.

18. Risk Disclosure

Het gebruik van Swappie brengt risico's met zich mee. Gebruikers dienen deze risico's te begrijpen voordat zij het platform gebruiken. Hieronder worden de belangrijkste risico's beschreven.

18.1 Technische risico's

  • Contract bugs: Hoewel het multisig contractmechanisme gebaseerd is op bewezen Bitcoin Script primitieven (OP_CHECKMULTISIG, OP_CHECKLOCKTIMEVERIFY), bestaat het theoretische risico op fouten in de implementatie.
  • Oracle failure: Als de oracle niet beschikbaar is of niet correct functioneert, kunnen betalingen niet worden geverifieerd en wordt er geen Bitcoin vrijgegeven via het betaalpad. Het refund-pad vereist alleen de verkoper-sleutel en is na 14 dagen beschikbaar onafhankelijk van de oracle. Momenteel heeft de verkoper nog geen toegang tot zijn sleutel, waardoor de refund pas wordt getriggerd zodra de oracle weer operationeel is. Omdat de betaallink na de verificatieperiode verloopt, is het niet mogelijk dat een koper betaalt nadat de oracle al offline is.
  • Network congestion: Bij hoge drukte op het Bitcoin netwerk kunnen transacties langer duren of hogere mining fees vereisen. Dit kan van invloed zijn op de snelheid van de release-transactie.
  • Blockchain reorganisatie: In het uitzonderlijke geval van een blockchain-reorganisatie kan een bevestigde transactie ongedaan worden gemaakt. Dit risico is inherent aan het Bitcoin netwerk en niet specifiek voor Swappie.

18.2 Financiële risico's

  • Koersvolatiliteit: De waarde van Bitcoin kan sterk fluctueren tussen het moment van aankoop en ontvangst. Swappie biedt geen bescherming tegen koersschommelingen.
  • iDEAL chargebacks: iDEAL-betalingen zijn definitief en onherroepelijk. In tegenstelling tot creditcardbetalingen kent iDEAL geen chargeback-mechanisme. Een terugboeking is uitsluitend mogelijk via een gerechtelijke procedure of een formele fraudeclaim bij de bank, waarvoor een politierapport vereist is (bijvoorbeeld bij een gehackte bankrekening). Dit maakt iDEAL bij uitstek geschikt als betaalmiddel voor peer-to-peer transacties: zodra de betaling is voltooid en door de oracle geverifieerd, is deze feitelijk onomkeerbaar. Dit is een bewuste ontwerpkeuze die verkopers maximale zekerheid biedt.
  • Mining fees: De mining fee wordt dynamisch berekend en verrekend met het bedrag dat de koper ontvangt. Bij hoge netwerkdrukte kunnen de fees hoger uitvallen dan verwacht.

18.3 Juridische risico's

  • Regelgevingswijzigingen: De Europese en Nederlandse regelgeving voor crypto-assets is in ontwikkeling. Toekomstige wetgeving kan de juridische positie van peer-to-peer platforms beïnvloeden. Swappie monitort ontwikkelingen in MiCA, AMLD en nationale regelgeving.
  • Bankbeleid: Banken kunnen hun beleid ten aanzien van crypto-gerelateerde transacties wijzigen. Dit kan gevolgen hebben voor de beschikbaarheid van iDEAL-betalingen via Tikkie voor dit type transacties.
  • API-toegang: De Tikkie API wordt beheerd door ABN AMRO. Wijzigingen in de API-voorwaarden of intrekking van API-toegang kan de werking van de betaaloracle beïnvloeden. De contracten op de blockchain blijven in dat geval functioneren via de CLTV timelock (automatische refund).

18.4 Gebruikersrisico's

  • Verkeerd Bitcoin adres: Als een koper een onjuist Bitcoin adres invoert, wordt de Bitcoin naar dat adres gestuurd. Dit is onomkeerbaar. Swappie kan dit niet terugdraaien.
  • Verlies van toegang: Als een verkoper de private sleutel verliest die nodig is voor het refund-pad, kan hij na afloop van de timelock niet zelfstandig refunden. In de praktijk wordt dit risico beperkt doordat het contract wordt aangemaakt via de Swappie interface, die de sleutels tijdelijk in het browsergeheugen bewaart gedurende de sessie. Gebruikers worden geadviseerd hun sleutelgegevens veilig op te slaan.

19. Compliance-strategie

Swappie opereert zonder KYC-verplichting, maar hanteert niettemin maatregelen om misbruik van het platform te beperken en de integriteit van het handelsproces te waarborgen.

19.1 Waarom KYC niet van toepassing is

KYC-verplichtingen gelden voor entiteiten die financiele diensten verlenen, klantrelaties onderhouden of fondsen beheren. Swappie doet geen van deze drie:

  • Er zijn geen klantrelaties. Er zijn geen accounts, geen profielen en geen terugkerende gebruikersidentificatie.
  • Er worden geen fondsen beheerd. Bitcoin zit in on-chain contracten, fiat gaat direct via het banksysteem.
  • Er worden geen financiele diensten verleend. Swappie is een technische interface, geen financieel intermediair.

KYC toepassen zou bovendien technisch inconsequent zijn: het platform heeft geen mechanisme om identiteiten te verifiëren, op te slaan of te koppelen aan transacties, omdat er geen accounts of transactiehistorie bestaan.

19.2 Misbruikpreventie

Hoewel Swappie geen KYC toepast, zijn er meerdere mechanismen die misbruik beperken:

  • Rate limiting: Het aantal orders dat kan worden aangemaakt is beperkt per tijdsperiode om spam en manipulatie te voorkomen.
  • Contractlimieten: Elk contract heeft een maximale waarde en een vaste looptijd van 14 dagen. Dit beperkt de omvang van individuele transacties.
  • iDEAL als poortwachter: Elke koper moet betalen via iDEAL, wat vereist dat de koper een geverifieerde Nederlandse (of Europese) bankrekening heeft. Het banksysteem voert zelf al KYC uit op rekeninghouders. Swappie hoeft dit niet te dupliceren.
  • Transparantie van de blockchain: Alle Bitcoin-transacties zijn publiek verifieerbaar op de blockchain. Dit biedt inherente transparantie die bij traditionele financiele systemen niet bestaat.
  • Automatische afwikkeling: Er is geen ruimte voor menselijke manipulatie in het afwikkelingsproces. De oracle ondertekent of ondertekent niet op basis van een objectieve API-response.

19.3 Samenwerking met toezichthouders

Swappie staat open voor dialoog met toezichthouders. Het platform opereert transparant: de werking is volledig beschreven in deze whitepaper, de contractlogica is verifieerbaar op de blockchain, en de juridische positie is getoetst door een advocatenkantoor. Bij vragen van toezichthouders is het volledige legal opinion document beschikbaar.

20. API en bankrelaties

20.1 Tikkie API gebruik

Swappie maakt gebruik van de Tikkie API voor het genereren van iDEAL betaallinks. Het gebruik van de API is in overeenstemming met de Tikkie API-voorwaarden:

  • Tikkie is een product van ABN AMRO en is ontworpen voor het genereren van betaalverzoeken tussen particulieren en bedrijven
  • Swappie gebruikt de open-bedrag functionaliteit om iDEAL betalingen te genereren met een exact bedrag op het moment van aankoop
  • De API wordt uitsluitend gebruikt voor het genereren van betaallinks en het opvragen van betaalstatussen. Er worden geen bankgegevens of persoonsgegevens via de API verwerkt

20.2 iDEAL en het banksysteem

De iDEAL betaling in het Swappie-proces is een standaard bankbetaling:

  • De koper betaalt via zijn eigen bank-app of -website via iDEAL
  • Het geld wordt direct overgemaakt van de bankrekening van de koper naar de bankrekening van de verkoper
  • Swappie is geen betaalinstelling en verwerkt geen betalingen. Het platform leest uitsluitend de betaalstatus (betaald/niet betaald) via de Tikkie API
  • De banken van koper en verkoper voeren zelf KYC uit op hun rekeninghouders conform de Wwft (Wet ter voorkoming van witwassen en financieren van terrorisme)

20.3 Continuïteitsrisico

De afhankelijkheid van de Tikkie API introduceert een continuïteitsrisico. Als ABN AMRO de API-voorwaarden wijzigt of de toegang intrekt, kan Swappie geen nieuwe betaallinks genereren. Dit heeft de volgende gevolgen:

  • Lopende contracten worden niet beïnvloed. De oracle controleert reeds gegenereerde betaalstatussen onafhankelijk van de beschikbaarheid van de API voor nieuwe links.
  • Contracten zonder betaling verlopen na 14 dagen. Het refund-pad wordt actief en vereist alleen de verkoper-sleutel. Momenteel triggert de oracle de refund automatisch.
  • De architectuur is ontworpen om de betaaloracle aan te sluiten op alternatieve betaalsystemen (zoals Wero). Een wijziging van betaalprovider vereist geen wijziging van de contractlogica op de blockchain.

21. Security

21.1 Contractbeveiliging

De multisig contracten zijn gebaseerd op bewezen Bitcoin Script primitieven die al jaren in productie worden gebruikt door het bredere Bitcoin ecosysteem:

  • OP_CHECKMULTISIG voor de 2-of-2 handtekeningverificatie
  • OP_CHECKLOCKTIMEVERIFY voor de 14-dagen timelock
  • OP_IF / OP_ELSE voor de routing tussen het betaalpad en het refund-pad

Deze opcodes zijn onderdeel van de Bitcoin consensus-regels en worden gevalideerd door elk full node op het netwerk. Er is geen custom scripting of experimentele functionaliteit gebruikt.

21.2 Infrastructuurbeveiliging

  • Alle communicatie verloopt via TLS-versleutelde verbindingen
  • De oracle-infrastructuur is gescheiden van de website-infrastructuur
  • Private sleutels van de oracle worden opgeslagen in een beveiligde omgeving en zijn niet toegankelijk via de website
  • De website slaat geen gevoelige data op. Er zijn geen databases met persoonsgegevens, wachtwoorden of financiele informatie

21.3 Bug bounty

Swappie nodigt beveiligingsonderzoekers uit om kwetsbaarheden te melden. Meldingen kunnen worden gedaan via Telegram. Verantwoorde disclosure wordt gewaardeerd en waar mogelijk beloond.

22. Disclaimer

Swappie.online is een onafhankelijk platform en heeft geen enkele relatie met Swappie.com (de refurbished telefoon website). Swappie.online is een zelfstandig gebouwd peer-to-peer Bitcoin handelsplatform met eigen technologie en eigen content.

22.1 Geen financieel of juridisch advies

Dit document beschrijft de technische architectuur en juridische analyse van het Swappie platform. Het vormt geen financieel advies, beleggingsadvies of juridisch advies. Gebruikers dienen zelf professioneel advies in te winnen voordat zij financiele beslissingen nemen.

22.2 Software disclaimer

Swappie is software. Het platform wordt aangeboden "as is" zonder enige garantie, expliciet of impliciet. Het gebruik van het platform is op eigen risico van de gebruiker. Swappie is niet aansprakelijk voor verlies van fondsen, technische storingen of andere schade die voortvloeit uit het gebruik van het platform.

22.3 Gebruikersverantwoordelijkheid

Gebruikers zijn zelf verantwoordelijk voor:

  • Het invoeren van een correct Bitcoin ontvangstadres
  • Het veilig bewaren van hun private sleutels
  • Het naleven van toepasselijke wetgeving in hun jurisdictie
  • Het begrijpen van de risico's verbonden aan het handelen in Bitcoin
  • Het verifiëren van ordervoorwaarden voordat zij een transactie starten

22.4 Verwijzingen

Voor verdere informatie verwijzen wij naar:

22.5 Persoonlijke noot

Swappie is een soloproject, gebouwd door een enkele developer. Het is geen bedrijf met een team van tientallen engineers. Dat betekent dat er fouten kunnen zitten in de software. Wat wel vaststaat is dat de kern van het platform, de multisig contracten en de betaalverificatie, zo sterk en veilig is gebouwd als technisch mogelijk is. De contractlogica is gebaseerd op bewezen Bitcoin Script primitieven en de betaalverificatie leunt op het Nederlandse banksysteem.

Ik hoop dat mensen van deze tool genieten en het zien als een eerlijk alternatief voor gecentraliseerde exchanges. Een plek waar je Bitcoin kunt kopen en verkopen zonder je persoonlijke data in te hoeven leveren. Waar de code het werk doet, niet een bedrijf dat aan je gegevens verdient. Bedankt voor het vertrouwen.

Swappie P2P · Versie 2.2 · Laatste update 28 maart 2026