Waarom tokengoedkeuringen bestaan

Gevorderd4 nov 2026 · 5 min leestijd

Tokengoedkeuringen bestaan zodat een specifiek smart contract later een token uit uw wallet mag besteden — tot een allowance die u instelt — onder gangbare tokenregels die vrije ophalingen verbieden. Het contract kan de tokens niet zomaar pakken.

Belangrijkste punten

Tokengoedkeuringen bestaan omdat gangbare tokenregels een contract verbieden om vrij uw saldo op te halen — een benoemde spender heeft eerst een allowance nodig.
Op DEX- en dApp-paden via de wallet is Goedkeuren / Approve de toestemmingslaag. De swap of storting is meestal een aparte bevestiging.
Allowance is typisch per token en per spender. Eén goedkeuring dekt niet elk token en niet elk contract.
Onbeperkte goedkeuringen bestaan voor gemak (minder herhalingen, minder gas). Ze laten ook breder blijvend risico open als die spender later faalt.
Restant-allowance is on-chain staat. De site sluiten of de wallet ontkoppelen wist die niet.
Nieuwere Permit- / Permit2-achtige flows verlenen nog steeds bestedingsmacht — vaak met minder frictie, niet met optioneel lezen.

Kort antwoord

Tokengoedkeuringen bestaan zodat een specifiek smart contract later een token uit uw wallet mag besteden — tot een allowance die u instelt — onder gangbare tokenregels die vrije ophalingen verbieden.

In gewone taal:

Het contract kan de tokens niet zomaar pakken. Het heeft eerst bestedingstoestemming nodig. Die toestemming staat on-chain. Ze kan de tradeklik overleven. Onbeperkt, restant, intrekken en Permit-achtige snelkoppelingen volgen allemaal uit dat ontwerp.

De Glossary-definitie — wat een goedkeuring is — staat op Wat is tokengoedkeuring?.

Deze pagina zet één oordeel vast: Goedkeuren is geen willekeurige frictie. Het is hoe bestedingsmacht wordt gedelegeerd.

De tradingvraag

U opent een swap via de wallet. De koersweergave oogt in orde. U klikt door — en de wallet vraagt Goedkeuren / Approve vóór de trade kan afronden.

Vraag:

Is dit overbodige UI-rompslomp — of vraagt het platform om bestedingsmacht die de tokenregels eisen?

Dat zijn andere verhalen.

Rompslomp-framing laat u doorstampen.

Ontwerp-framing laat u token / spender / bedrag lezen vóór u ondertekent.

Live scene: swap geblokkeerd tot Goedkeuren

U houdt USDC aan en wilt swappen op een DEX via de wallet.

U verbindt de wallet. Verbinden is geen goedkeuring.
U voert de omvang in en ziet een koersweergave.
Bevestigen stokt: de wallet toont Approve USDC voor een spender-contract (vaak een router).
U ondertekent de allowance. Dat kost meestal gas.
Een tweede bevestiging voert de swap uit.
Na de uitvoering kan ongebruikte allowance nog on-chain blijven voor dat token en die spender.

Aha:

«Oh — de trade had eerst toestemming nodig. En die toestemming kan na de trade blijven.»

Wat de allowance is, en hoe u de prompt leest → Wat is tokengoedkeuring?.

Hoe u restant-toestemmingen bekijkt of intrekt → wanneer u de checklist nodig hebt, zie de beheer-/intrekking-User Guides.

Ontwerpreden: waarom de regel bestaat

Onder breed gebruikte ERC-20-achtige regels verhuizen saldi niet naar een willekeurig contract alleen omdat een website dat vroeg.

Een typisch ophaalpad heeft nodig:

U (de eigenaar) machtigt een spender.
Die spender roept later iets als `transferFrom` aan binnen de resterende allowance.

Zonder die machtiging zou het contract het token niet van uw adres mogen leegtrekken.

Dat is de veiligheidsdefault — en de reden waarom DEX-flows Goedkeuren tonen wanneer ze een token moeten verplaatsen dat u al aanhoudt.

Native netwerkcoins slaan vaak dezelfde ERC-20-achtige approve-stap over. NFT-achtige operatorgoedkeuringen zijn een verwante toestemmingsfamilie: één klik kan een contract over veel items machtigen. Deze pagina blijft bij het fungible approve-patroon dat spot-DEX-traders het eerst tegenkomen.

Waarom de DEX vraagt vóór (of rond) de trade

Een platform dat swapt, stort of anderszins uw ERC-20-saldo verplaatst, heeft bestedingsmacht nodig voor een specifieke spender.

Dus vraagt het product meestal:

om allowance wanneer er geen bestaat (of wanneer een begrensde allowance op is)
daarna om bevestiging van de marktactie

Goedkeuren verleent toestemming.

De trade besteedt tokens onder die toestemming (of faalt als toestemming ontbreekt).

Beide klikken als «gewoon doorgaan» behandelen, plakt twee verschillende beslissingen aan één gewoonte.

Ontwerpgevolgen die u blijft tegenkomen

Per token, per spender

USDC goedkeuren voor Router A keurt USDT niet goed, en keurt Router B niet goed.

Een eerste bezoek met meerdere tokens kan meerdere Goedkeuren-prompts betekenen. Dat is de bereikregel die werkt — niet de app die u «voor de lol» extra laat klikken.

Waarom onbeperkt bestaat

Onbeperkte (of max) goedkeuringen zijn gangbaar omdat ze herhaalde prompts en herhaald gas snijden.

Ze verbreden ook blijvend risico: als die spender nu kwaadaardig, buggy of later gecompromitteerd is, kan die al toestemming hebben om dat token op te halen zonder een nieuwe Goedkeuren van u.

Gemak en blijvend risico zijn dezelfde ontwerp-munt.

Waarom restant-allowances blijven

Allowance wordt on-chain vastgelegd voor die eigenaar–token–spender-relatie.

De frontend kan verdwijnen. Uw «ontkoppelen» kan lukken. De mapping kan blijven tot ze is verbruikt, verlaagd of ingetrokken.

Daarom kunnen oude platforms die u niet meer gebruikt nog in uw risicoboek meetellen.

Waarom intrekken / verlagen bestaat

Opruimen is een aparte on-chain schrijfactie. Die kost meestal gas en vraagt uw handtekening.

Ontkoppelen ≠ intrekken.

Intrekken/verlagen helpt toekomstige ophalingen te stoppen. Het draait tokens die al zijn weggenomen niet terug.

Praktijkstappen en tools → beheer-/intrekking-User Guides. Fee-detail → Wat zijn netwerkkosten (gas)?.

Nieuwere patronen: minder frictie, dezelfde toestemmingsfamilie

Sommige flows gebruiken Permit-achtige handtekeningen zodat allowance zonder aparte approve-transactie kan worden gezet.

Sommige ontwerpen (inclusief Permit2-achtige hubs) leiden via een gedeeld goedkeuringscontract: één blijvende goedkeuring aan de hub, daarna latere handtekeningen met bedrag-/tijdlimiet voor apps.

Deze patronen bestaan om de pijn van twee stappen te verminderen en, in sommige ontwerpen, om verval of fijnere grenzen toe te voegen.

Ze maken lezen niet optioneel. Een phishingpagina die een slechte permit-achtige handtekening oogst, kan nog steeds bestedingsmacht verlenen in dezelfde familie als een slechte klassieke Goedkeuren.

Diepe Permit2-architectuur blijft buiten deze pagina. Het oordeel over de actuele stand is eenvoudig: snelkoppelingen verplaatsen nog steeds bestedingsmacht.

Waarom aanvallers om hetzelfde ontwerp geven

Drainers houden van goedkeuringen en permit-achtige handtekeningen omdat ze blijvende bestedingstoestemming kunnen monetariseren zonder uw seed phrase te stelen.

Nep-«claim»-, «verify»-, «sync»- of «mint»-prompts vragen vaak hetzelfde toestemmingsoppervlak dat de echte DEX voor eerlijke swaps nodig heeft.

Motief hoort hier. Volledige gids over officiële links en phishing → Hoe verifieert u officiële links en voorkomt u phishing.

Werkscènes (snel gelezen)

Scene	Wat het ontwerp uitlegt
Swap geblokkeerd tot Goedkeuren	Spender kan niet ophalen zonder allowance
Onbeperkt «zodat ik niet opnieuw goedkeur»	UX-gemak vs breder blijvend risico
Trade klaar; allowance nog live	On-chain toestemming ≠ websitesessie
Permit2-achtige hub: één keer goedkeuren	Blijvende hub-toestemming + latere begrensde handtekeningen
Nep-claim vraagt Approve / Permit	Aanvallers hergebruiken de bestedingstoestemmingslaag

U hoeft niet elke rij elke keer.

Benoem of u bestedingsmacht verleent — en aan wie — vóór u opschaalt.

Verwar dit niet met

Wat een goedkeuring is (definitie / herkenning) → Wat is tokengoedkeuring?
Hoe bekijken of intrekken (praktijkchecklist) → beheer-/intrekking-User Guides
Gasfee-rekenwerk → Wat zijn netwerkkosten (gas)?
Officiële links / phishing vermijden → Hoe verifieert u officiële links en voorkomt u phishing
Verbinden / sleutels / bewaringsmodel → verwante pagina’s over wallet en zelfbewaring

Deze pagina is niet «goedkeuring opnieuw gedefinieerd».

Het is waarom de toestemmingslaag bestaat — en waarom onbeperkt, restant, intrekken en Permit-achtige snelkoppelingen uit dat ontwerp volgen.

Als u via de wallet handelt — inclusief op een platform zoals edgeX — behandel elke Goedkeuren- of permit-achtige prompt als een verlening van blijvende bestedingsmacht onder tokenregels, niet als een decoratief vinkje.

Lees token, spender en bedrag vóór u ondertekent.

Voor de kale definitie blijft u bij Wat is tokengoedkeuring?.

Gerelateerde artikelen

Klaar voor de volgende stap?

Ga vanaf deze pagina via de officiële links verder naar registratie of trading.

Begin met handelen op edgeX

Disclaimer

Deze inhoud is uitsluitend bedoeld voor educatieve doeleinden en vormt geen beleggingsadvies. Handelen in digitale activa en derivaten brengt risico's met zich mee. Zorg dat je de producten begrijpt en houd rekening met je eigen situatie voordat je handelt.

Uitleg