﻿---
title: "Token-Vesting"
description: "Beim Token-Vesting wird eine Zuteilung nach einem Zeitplan verfügbar. Dieser Beitrag erklärt Cliff und lineare Freigabe, die zu prüfenden On-Chain-Nachweise und warum gevestete Token nicht automatisch verkauft sind."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Token-Vesting

> Nur zu Bildungszwecken; keine Anlageberatung. Anlagen können zu Verlusten führen.

<a id="answer"></a>

## Direkte Antwort

Token-Vesting ist eine Regel, nach der die Zuteilung eines Begünstigten gemäß einem Zeitplan statt vollständig auf einmal verfügbar wird. Ein **Cliff** ist die Wartezeit vor dem ersten Vesting; danach können Token fortlaufend, in periodischen Tranchen oder bei Meilensteinen gevestet werden.

Vesting bedeutet nicht automatisch Minting oder Verkauf. Token können bereits existieren und gesperrt sein oder erst bei der Freigabe erzeugt werden. Ein gevesteter Betrag kann noch nicht abgerufen, durch eine andere Regel nicht übertragbar, weiter gehalten oder erst später verkauft werden.

Für die Analyse sind fünf Ereignisse zu trennen: **zugeteilt, gevestet, abgerufen, übertragbar und verkauft**. Nur das letzte ist ein tatsächlicher Verkauf; seine Preiswirkung hängt von Erwartungen, Verhalten der Inhaber und ausführbarer Liquidität ab.

<a id="mechanism"></a>

## Funktionsweise

1. **Rechtliche und veröffentlichte Bedingungen lesen.** Zuteilung, Begünstigten, Start, Cliff, Ende, Freigabeintervall, Meilensteine, Widerrufsrechte und Änderungsbefugnis feststellen.
2. **Implementierung prüfen.** Token-Adresse, Vesting-Vertrag, Begünstigten, Zeitstempel, freigegebenen Betrag, Abruftransaktionen, Proxy- oder Administratorrechte und verifizierten Quellcode kontrollieren. OpenZeppelins `VestingWallet` ist eine Implementierung, kein allgemeiner Standard.
3. **Angebotsbegriffe abgleichen.** Prüfen, ob gesperrte Token im Gesamtangebot enthalten sind und ob eine Freigabe nur das Umlaufangebot, nicht aber das Gesamtangebot ändert. ERC-20 definiert Übertragungen, jedoch weder „Umlaufangebot“ noch einen Vesting-Zeitplan.
4. **Weg zum Markt nachvollziehen.** Gevestete Token werden erst zu potenziellem Angebot, wenn sie abrufbar und übertragbar sind. Einzahlungen bei Börsen, Bridges, Liquiditätspools oder neuen Wallets belegen eine Bewegung, keinen Verkauf.
5. **Szenarien mit Liquidität vergleichen.** Möglichen Verkaufsanteil schätzen und mit Orderbuchtiefe oder AMM-Reserven vergleichen. Tiefe und Handelsvolumen getrennt ausweisen; vergangenes Volumen ist kein garantiertes Kaufangebot.

Für eine Zuteilung `A`, Cliff-Freigabe `C`, Cliff-Zeitpunkt `T_c` und Endzeitpunkt `T_e` lautet eine mögliche lineare Regel:

`vested(t) = 0` vor `T_c`; andernfalls `C + (A - C) × min((t - T_c) / (T_e - T_c), 1)`

Reale Verträge können andere Rundungs-, Zeitstempel-, Widerrufs- oder Meilensteinregeln verwenden. Maßgeblich sind daher die bindenden Dokumente und der Vertragscode.

<a id="example"></a>

## Rechenbeispiel

Ein Mitwirkender erhält 12,000,000 Token. Während eines 12-monatigen Cliffs vestet nichts. In Monat 12 vesten 3,000,000 Token; die übrigen 9,000,000 vesten über die nächsten 24 Monate mit 375,000 pro Monat.

In Monat 18 sind sechs monatliche Tranchen nach dem Cliff gevestet. Insgesamt sind es `3,000,000 + 6 × 375,000 = 5,250,000` Token. Wurden bereits 2,000,000 abgerufen, sind 3,250,000 gevestet, aber nicht abgerufen. Daraus folgt nicht, wie viele Token übertragen oder verkauft wurden.

Sind aktuell 100,000,000 Token im Umlauf und wird die Tranche aus Monat 12 übertragbar, entspricht sie 3% des Umlaufangebots. Verkauft der Begünstigte 20% davon, beträgt der geplante Verkauf 600,000 statt 3,000,000 Token. Die Marktwirkung ist anhand aktueller ausführbarer Liquidität zu testen.

<a id="risks"></a>

## Risiken und Prüfungen

- **Unvollständiger oder änderbarer Zeitplan.** Nebenabreden, Meilensteine, Administratorschlüssel, Governance oder Upgrades können den Kalender ändern. Festhalten, wer jede Bedingung ändern darf.
- **Vertrags- und Verwahrungsrisiko.** Fehler, kompromittierte Schlüssel, falsche Begünstigte, Migrationen oder Abruffehler können Freigaben verzögern oder umleiten. Adressen und finalisierte Transaktionen prüfen.
- **Fehlerhafte Angebotsklassifizierung.** Anbieter behandeln Treasury-, gesperrte, gebridgte, verbrannte oder nicht abgerufene Bestände unterschiedlich. Definitionen vor Prozentrechnungen abgleichen.
- **Liquiditäts- und Konzentrationsrisiko.** Eine große Tranche weniger Empfänger mit niedrigen Kosten kann dünne Kauforders überfordern; eine Freigabe beweist jedoch keine Verkaufsabsicht.
- **Scheingenauigkeit.** Kalender können Blockzeitstempel, Sekunden, diskrete Perioden, Rundungen oder manuelle Abrufe nutzen. Nahe am Ereignis den Vertragszustand statt nur einen Dashboard-Countdown lesen.

<a id="misconceptions"></a>

## Häufige Irrtümer

### „Gevestet“ bedeutet „verkauft“

Nein. Vesting begründet einen Anspruch. Abruf, Übertragung, Einzahlung und Verkauf sind getrennte Handlungen mit eigenen Nachweisen.

### Ein Cliff gibt die gesamte Zuteilung frei

Nicht zwingend. Der Cliff bestimmt nur den ersten Vesting-Zeitpunkt; erste Tranche und weitere Kurve hängen vom konkreten Zeitplan ab.

### Eine Freigabe erhöht immer das Gesamtangebot

Nein. Bereits erzeugte gesperrte Token können ohne Änderung des Gesamtangebots übertragbar werden. Bei Erzeugung zur Freigabe kann es steigen; Vertrag und Angebotsrechnung prüfen.

### Eine große Freigabe garantiert einen Kursrückgang

Nein. Erwartungen, Nachfrage, Absicherung, Empfängerverhalten und Liquidität wirken ebenfalls. Verkaufsanteil und Preiswirkung sind Szenarien, keine Gewissheiten.

<a id="related"></a>

## Verwandte Themen

- [Umlaufangebot](/de/crypto/circulating-supply/)
- [Token-Emission](/de/crypto/token-emission/)
- [Token-Freigabe](/de/crypto/token-unlock/)
- [Vesting-Cliffs und Liquidität analysieren](/de/crypto/token-vesting-cliff-liquidity/)
- [Tokenomics](/de/crypto/tokenomics/)

<a id="sources"></a>

## Quellen

- [VestingWallet](https://docs.openzeppelin.com/contracts/5.x/api/finance#VestingWallet) - OpenZeppelin (abgerufen: 2026-08-22)
- [ERC-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (abgerufen: 2026-08-22)
- [Pricing](https://docs.uniswap.org/contracts/v2/concepts/advanced-topics/pricing) - Uniswap (abgerufen: 2026-08-22)

Source: https://wiki.fcontext.com/de/crypto/vesting/index.mdx
