Technisch eingeordnet
Hidden Owner / Ownership not renounced
Manche Scanner melden einen „Hidden Owner“ oder dass das Ownership
nicht renounced wurde.
Der LIG1Core verwendet jedoch kein klassisches Owner-Modell mit einer
allgemeinen owner()-Rolle und einer
renounceOwnership()-Funktion.
Stattdessen verwendet LIG1 klar definierte technische Rollen.
Dazu gehört unter anderem eine bei Deployment festgelegte
Initializer-Adresse.
Diese Adresse ist nicht mit einem allgemeinen Owner gleichzusetzen,
der beliebige Einstellungen des Tokens verändern kann.
Die Initialisierungsfunktionen für zentrale Systemkomponenten sind
zusätzlich so aufgebaut, dass sie nur ausgeführt werden können,
solange die jeweilige Adresse noch nicht gesetzt wurde.
Entscheidend ist daher nicht allein, ob ein Scanner ein klassisches
„renounced ownership“ erkennt, sondern welche Rechte im veröffentlichten
Contract tatsächlich vorhanden sind.
Im geprüften LIG1Core nicht vorhanden
Contract modifiable / Smart Contract veränderbar
Im veröffentlichten LIG1Core wurde keine eigene Upgrade-Funktion
identifiziert, mit der eine neue Implementierung eingesetzt werden kann.
Ebenso existieren im geprüften Core keine Setter, mit denen die
zentralen Tokenregeln wie MaxWallet, maximaler Supply,
Buy-/Sell-Gebühren oder die 100-Tage-Regel nachträglich geändert
werden können.
Diese zentralen Werte sind im LIG1Core als Konstanten definiert.
Scannerbegriff erklärt
Blacklist
Im LIG1Core existiert innerhalb der Pool-Zustände der Begriff
QUARANTINED.
Das Vorhandensein eines solchen Zustands bedeutet jedoch nicht
automatisch, dass ein Betreiber beliebige Nutzer-Wallets sperren kann.
Im geprüften LIG1Core wurde keine öffentlich oder administrativ
aufrufbare Funktion identifiziert, mit der Wallets auf eine Blacklist
gesetzt werden können.
Ebenso wurde im vorliegenden Core keine nachträgliche Setter-Funktion
identifiziert, mit der der bestehende Pool beliebig auf
QUARANTINED gestellt werden kann.
Keine globale Pause im geprüften Core
Transfer Pausable
LIG1 besitzt interne Statusvariablen für bestimmte Abläufe bei
privaten und systembezogenen Liquiditätsvorgängen.
Diese Steuerungen sind nicht mit einer allgemeinen
„Alle Transfers stoppen“-Funktion gleichzusetzen.
Im geprüften LIG1Core wurde keine globale
pause()- oder unpause()-Funktion
identifiziert, mit der ein Administrator den normalen LIG1-Handel
vollständig anhalten und später wieder freigeben könnte.
Vorhanden und beabsichtigt
Anti-Whale / MaxWallet
Diese Scannerfeststellung beschreibt eine tatsächlich vorhandene
Eigenschaft von LIG1.
Maximaler Bestand einer normalen Wallet
2.000.000 LIG1
Das entspricht 0,2 % des maximal möglichen LIG1-Supply.
Die MaxWallet-Regel ist bewusst Bestandteil von LIG1.
Sie soll eine sehr starke Konzentration von LIG1 auf einzelnen
normalen Wallets begrenzen.
Diese Regel wird nicht entfernt, nur um einen besseren
Scanner-Score zu erhalten.
Vorhanden und beabsichtigt
Mintable – können weitere LIG1 erzeugt werden?
Ja. Die Bezeichnung „Mintable“ ist bei LIG1 grundsätzlich korrekt.
Weitere LIG1 können über den vorgesehenen Reward-Mechanismus entstehen.
Absolute Obergrenze
1.000.000.000 LIG1
Der maximale Gesamtbestand ist im LIG1Core fest begrenzt.
„Mintable“ bedeutet deshalb nicht, dass ein Owner unbegrenzt
neue LIG1 erzeugen kann.
Der LIG1Core begrenzt den maximalen Gesamtbestand auf
1 Milliarde LIG1 und den für Rewards vorgesehenen Anteil auf
maximal 980 Millionen LIG1.
Zusätzlich bestehen weitere Schutzmechanismen:
Rewards müssen über den vorgesehenen RewardController freigegeben
werden, die begünstigte Wallet muss die Ausführung selbst vornehmen,
und der Contract prüft weitere Wallet-, Mengen- und Zeitlimits.
Vor jedem Reward-Mint wird außerdem geprüft, dass weder das
maximale Reward-Volumen noch der absolute Max Supply überschritten wird.
Kurz gesagt:
Weitere LIG1 können innerhalb des vorgesehenen Reward-Systems entstehen.
Der maximale Gesamtbestand kann dabei jedoch nicht über
1.000.000.000 LIG1 steigen.
Verkauf vorgesehen
Honeypot / Sell Restriction
LIG1 besitzt einen ausdrücklich implementierten Verkaufsweg.
Ein Verkauf an den aktiven Pool wird im LIG1Core erkannt und über
die vorgesehene Sell-Logik verarbeitet.
Zusätzlich wurden reale Verkäufe des aktuellen LIG1 auf Base
erfolgreich ausgeführt. Dabei wurden LIG1 an den Pool übertragen
und die verkaufende Wallet erhielt USDC.
Damit ist ein tatsächlicher Verkauf nicht nur theoretisch im Code
vorgesehen, sondern auch durch reale On-Chain-Transaktionen
nachvollziehbar.
Vorhanden und transparent
Buy Tax / Sell Tax
LIG1 besitzt bewusst festgelegte Gebühren.
Kauf: 0,1 %
Verkauf innerhalb der ersten 100 Tage einer Kauf-Tranche:
1 %
Verkauf nach 100 Tagen:
0,1 %
Die Gebührenwerte sind im geprüften LIG1Core als Konstanten definiert.
Im vorliegenden Core wurde kein Setter identifiziert, mit dem ein
Betreiber diese Werte nachträglich erhöhen kann.
Keine 100-Tage-Verkaufssperre
Die 100-Tage-Regel
Die 100-Tage-Regel bedeutet nicht, dass gekaufte LIG1 für
100 Tage unverkäuflich sind.
Sie bestimmt die Höhe der Verkaufsgebühr einer Kauf-Tranche.
Innerhalb der ersten 100 Tage gilt die höhere Sell-Gebühr von 1 %.
Nach Ablauf der 100 Tage gilt für diese Tranche die niedrigere
Sell-Gebühr von 0,1 %.
Die Tranches werden im LIG1Core nach dem FIFO-Prinzip
(First In, First Out) verarbeitet.