Wir sagen nicht nur, welche Regeln LIG1 hat. Wir zeigen, wie sie geprüft werden.
Ein Smart Contract sollte nicht allein aufgrund von Aussagen beurteilt werden. Entscheidend ist, was tatsächlich im veröffentlichten Contract festgelegt ist und was durch konkrete Tests nachgewiesen werden kann.
Auf dieser Seite trennen wir deshalb klar zwischen verifiziertem Contract, Quellcodeprüfung und ausgeführten Funktionstests.
Prüfstatus ansehenWas bedeutet der Prüfstatus?
Nicht jede Aussage auf dieser Seite besitzt denselben Nachweisgrad. Deshalb kennzeichnen wir transparent, worauf ein Ergebnis beruht.
✓ Verifiziert
Der veröffentlichte Contract wurde mit dem tatsächlich auf Base vorhandenen Bytecode abgeglichen. Creation- und Runtime-Bytecode wurden als Exact Match bestätigt.
⌕ Im finalen Code geprüft
Die betreffende Regel ist im verifizierten Quellcode des final deployten Contracts konkret vorhanden. Das bestätigt die Implementierung der Regel, ist aber nicht automatisch dasselbe wie ein ausgeführter Live-Funktionstest.
○ Funktionstest ausstehend
Für einen endgültigen Verhaltensnachweis ist ein konkreter Test auf dem finalen System erforderlich. Solange dieser Nachweis fehlt, wird die Eigenschaft hier nicht als live getestet bezeichnet.
1. Identität des geprüften Contracts
Netzwerk: Base
LIG1 Core:
0x5b517A3d16213d1FD38e21CDEc3cFe0bE5b81Af9
Token: LIGONE (LIG1)
Solidity: 0.8.34
Verifikation: 31. August 2026
Ergebnis:
Creation Match = Exact Match
Runtime Match = Exact Match
Was bedeutet „Exact Match“?
Bei der Verifikation wird der veröffentlichte Quellcode erneut kompiliert. Das Ergebnis wird anschließend mit dem Bytecode des tatsächlich deployten Contracts verglichen.
Ein Exact Match bedeutet, dass der abgeglichene kompilierte Code mit dem entsprechenden On-Chain-Bytecode übereinstimmt. Damit kann die folgende Codeanalyse auf den verifizierten finalen LIG1-Core bezogen werden.
Das beweist jedoch nicht automatisch, dass jede wirtschaftliche Funktion unter allen realen Handelsbedingungen bereits praktisch getestet wurde. Deshalb dokumentieren wir Funktionstests separat.
2. Feste Grundwerte
Im verifizierten LIG1-Core sind zentrale Werte als Konstanten festgelegt.
1.000.000.000 LIG1
Maximaler Gesamtbestand laut MAX_SUPPLY.
20.000.000 LIG1
Für die initiale System-Liquidität laut INITIAL_SYSTEM_LP.
980.000.000 LIG1
Maximal für das Reward-System laut MAX_REWARD_SUPPLY.
2.000.000 LIG1
MaxWallet-Grenze laut MAX_WALLET.
0,1 %
Kaufgebühr laut BUY_FEE = 10 bei einem Gebührennenner von 10.000.
1 % → 0,1 %
Verkaufsgebühren laut SELL_FEE_HIGH = 100 und SELL_FEE_LOW = 10.
100 Tage
Haltezeit laut HOLD_PERIOD = 100 days.
18 Dezimalstellen
LIG1 verwendet die ERC-20-Standard-Dezimalstellen des eingesetzten OpenZeppelin-Contracts.
3. MaxWallet – Begrenzung pro Wallet
Soll-Regel
Eine normale Wallet soll maximal 2.000.000 LIG1 halten können. Das entspricht 0,2 % des maximal vorgesehenen Bestands von einer Milliarde LIG1.
Codeprüfung
Der finale verifizierte Contract enthält
MAX_WALLET = 2_000_000 ether.
Funktionstest
Ein früherer Test in der Testumgebung löste beim Überschreiten der Grenze
einen Revert mit max wallet exceeded aus.
Dieser Test wird hier bewusst nicht als Live-Test des deployten Base-Systems
ausgegeben.
Status: Im finalen Code geprüft · finaler Live-Funktionstest separat zu dokumentieren.
4. Kauf von LIG1
Der Contract unterscheidet Poolbewegungen von normalen Wallet-Transfers.
Für Käufe existiert ein eigenes Buy-Event.
Im finalen Code festgelegt
Die Kaufgebühr beträgt 0,1 %.
Der Contract besitzt außerdem die Struktur
hasPurchasedLIG1 sowie eine FIFO-Tranchenverwaltung.
Warum sind Tranchen wichtig?
Ein Kauf wird zeitlich erfasst. Dadurch kann die spätere Behandlung beim Verkauf von der Haltedauer der jeweiligen gekauften Menge abhängen.
Status: Code geprüft · konkrete Live-Kauftransaktion und Gebührenberechnung separat nachweisen.
5. Die 100-Tage-Regel
Die 100-Tage-Regel ist nicht nur ein Text auf einer Webseite.
Der verifizierte Contract enthält ausdrücklich
HOLD_PERIOD = 100 days und eine eigene
Tranche-Struktur mit Menge und Zeitstempel.
Jede Tranche hat einen Zeitpunkt
Die Struktur speichert amount und timestamp.
Damit können gekaufte Mengen zeitlich voneinander unterschieden werden.
FIFO-Struktur
Zusätzlich existiert ein trancheCursor.
Die Struktur ist für eine Verarbeitung der Tranchen in Reihenfolge angelegt.
Gebührenstufen
Im Contract sind sowohl 1 % als auch 0,1 % als Verkaufsgebühren festgelegt.
Was noch praktisch nachgewiesen werden muss
Ein vollständiger Langzeittest des final deployten Systems muss zeigen, welche konkrete Verkaufsmenge aus welchen Tranchen verarbeitet wird und welche Gebühr dabei tatsächlich anfällt. Ein echter 100-Tage-Live-Test kann naturgemäß erst nach Ablauf der entsprechenden Haltedauer vollständig abgeschlossen werden.
Status: Struktur und Konstanten im finalen Code geprüft · Langzeit-Live-Nachweis ausstehend.
6. Verkauf und Gebühren
Der Contract enthält ein eigenes Sell-Event sowie zwei feste
Verkaufsgebühren.
1 %
SELL_FEE_HIGH = 100
0,1 %
SELL_FEE_LOW = 10
Gebührenweg
Der Core besitzt eine feste Verbindung zum liquidityVault und
eine Schnittstelle onFeeReceived(amount).
Für die öffentliche Testdokumentation werden wir reale Verkäufe nicht nur mit „funktioniert“ kennzeichnen. Wir können dabei Transaktionsdaten, Bruttomenge, berechnete Gebühr und tatsächliches Ergebnis gegenüberstellen.
Status: Gebührenwerte und Gebühren-Schnittstelle im finalen Code geprüft · Live-Verkaufstest separat dokumentieren.
7. Reward-System
Der finale Core begrenzt Rewards auf mehreren Ebenen. Das ist technisch wichtiger als eine einzelne maximale Gesamtmenge.
980 Mio. LIG1
Maximale Reward-Supply im Core.
10.000 LIG1
Maximaler Reward-Mint pro Wallet laut MAX_REWARD_PER_WALLET.
3 / 24 Stunden
MAX_REWARDS_24H = 3 begrenzt die Anzahl der Reward-Ausführungen innerhalb des vorgesehenen 24-Stunden-Mechanismus.
10 Mio. / 30 Tage
MAX_REWARD_30_DAYS = 10_000_000 ether. Der Contract führt dafür 720 Stundenwerte.
Berechtigungen
Die Reward-Ausführung ist mit dem separaten RewardController verbunden. Im Contract befinden sich Prüfungen gegen bereits ausgeführte Rewards sowie gegen Wallet-, Gesamt- und Zeitlimits.
Status: Limits und Kontrolllogik im finalen Code vorhanden · einzelne Live-Reward-Fälle separat dokumentieren.
8. System-Liquidität
Die Initialisierung des Pools ist im Core an mehrere Bedingungen gebunden. Der Pool muss ein Contract sein und als LIG1/USDC-Paar erkannt werden. Außerdem müssen SystemLPVault und PrivateLPManager zuvor initialisiert sein.
Initiale LIG1-Menge
Bei erfolgreicher Poolinitialisierung mintet der Core 20.000.000 LIG1 direkt an den Pool.
USDC
Die übergebene USDC-Menge wird bei der Initialisierung in den Pool übertragen. Eine Initialisierung mit null USDC wird abgewiesen.
LP-Token
Der Pair-Contract führt anschließend mint(systemLPVault) aus.
Der Core verlangt, dass dabei tatsächlich Liquidität größer null erzeugt wird.
Status: Initialisierungslogik im finalen verifizierten Code geprüft.
9. Private LP
Der LIG1-Core besitzt eine getrennte Schnittstelle für den
privateLPManager.
LP-Einzahlung und LP-Auszahlung werden über eigene Zustände kontrolliert.
Einzahlung
beginLPDeposit() und endLPDeposit() dürfen nur vom
PrivateLPManager gesteuert werden.
Auszahlung
Auch beginLPWithdrawal() und endLPWithdrawal()
prüfen den aufrufenden PrivateLPManager.
Getrennte Rollen
Bei der Initialisierung wird geprüft, dass zentrale Systemadressen nicht unzulässig identisch sind.
Status: Core-Schnittstellen und Zugriffskontrollen im finalen Code geprüft · vollständiger Live-Private-LP-Ablauf separat dokumentieren.
10. Warum auch fehlgeschlagene Tests wichtig sind
Ein guter Smart-Contract-Test besteht nicht nur daraus, dass erlaubte Transaktionen funktionieren. Mindestens genauso wichtig ist die Frage, ob unerlaubte Vorgänge tatsächlich abgewiesen werden.
Erlaubter Vorgang
Die Transaktion soll erfolgreich durchgeführt werden.
Grenzfall
Wir prüfen Werte direkt an einer festgelegten Grenze.
Verbotener Vorgang
Der Contract soll die Transaktion gezielt zurückweisen.
Ein Revert kann deshalb ein erfolgreiches Testergebnis sein: Wenn eine Wallet beispielsweise eine festgelegte Obergrenze überschreiten soll und der Contract genau diesen Vorgang verhindert, hat die Schutzregel im Test eingegriffen.
11. Aktueller Gesamtstand
Contract-Bytecode: ✓ Exact Match verifiziert
Maximaler Bestand: ✓ im finalen Code geprüft
20 Mio. initiale System-LP: ✓ im finalen Code geprüft
MaxWallet 2 Mio. LIG1: ✓ im finalen Code geprüft
Buy-Fee 0,1 %: ✓ im finalen Code geprüft
Sell-Fee 1 % / 0,1 %: ✓ im finalen Code geprüft
100-Tage-Konstante und Tranchen: ✓ im finalen Code geprüft
Reward-Limits: ✓ im finalen Code geprüft
System-LP-Initialisierung: ✓ im finalen Code geprüft
Private-LP-Schnittstellen: ✓ im finalen Code geprüft
100-Tage-Live-Langzeittest: ○ naturgemäß noch ausstehend
Diese Seite wird nicht dadurch glaubwürdiger, dass überall „bestanden“ steht. Sie wird glaubwürdiger, wenn klar erkennbar bleibt, was bereits bewiesen wurde und was noch bewiesen werden muss.
Transparenz statt Vertrauen auf Zuruf
LIG1 soll nicht einfach geglaubt werden. Der Contract, seine Regeln und die Testergebnisse sollen nachvollziehbar sein.
Deshalb wird diese Dokumentation mit weiteren konkreten Testergebnissen ergänzt, sobald sie am finalen System eindeutig nachgewiesen wurden.
Prüfen. Verstehen. Dann selbst entscheiden.