Warum werden bei ICOs Erstversorgungs-/Gesamtversorgungs-Token an die Eigentümeradresse übertragen, anstatt sie im Vertrag selbst zu speichern?

Hier habe ich zwei der Top 20 ERC20 Token/ICO genommen. 1.BNB ( https://etherscan.io/address/0xB8c77482e45F1F44dE1745F52C74426C631bDD52#code )) Im BNB-Vertrag wurde er bei der Bereitstellung so codiert, dass die Gesamtversorgung als Saldo des Eigentümers festgelegt wird und die Token vom Eigentümer an denjenigen übertragen werden, der den Token kauft, sodass der Vertrauensteil beim Eigentümer / einer bestimmten Kontoadresse liegt. Während im Fall von BATokens die Token generiert und verteilt werden, wenn jemand den Ether an den Vertrag sendet, liegt das Vertrauen hier im Smart Contract oder es ist das, was als dezentrales Vertrauen bezeichnet wird. Da BNB im Etherscan an der Spitze steht, ist mein Zweifel, warum sie das Token-Handling nicht wie BATokens im Vertrag implementiert haben? Gibt es technische Probleme wie Bugs, Schlupflöcher? Oder steckt dahinter eine Geschäftslogik?

Antworten (1)

Das ist konzeptionell.

Es ist zwar möglich, einen ERC20-Vertrag mit anderen Anliegen aufzuladen, aber gehen wir davon aus, dass wir ihn rein halten.

Wer einen Token hat, ist nicht dasselbe wie was ein Token ist .

Ein Token-Vertrag definiert das Token. Dazu gehört, wie viel vorhanden ist oder wie die Ausgabe erfolgt und was sie tun können, nämlich Überweisungen von einem Konto auf ein anderes, wenn die Bedingungen stimmen.

Ein ICO-Plan beinhaltet den Austausch dieser Token gegen Finanzierung. Das kann als separates Anliegen behandelt werden, genauso wie ein Unternehmen Coupons, Tickets, Zertifikate ausgeben und diese dann gegen Geld eintauschen kann. Es versteht sich von selbst, dass die Unternehmen zunächst im Besitz sein müssen , wie könnten sie sie sonst zum Verkauf anbieten?

Die Token können sogar auf dem Konto eines Entwicklers landen. Das bedeutet nicht, dass der Entwickler einen besonderen Status hat. Es kann ihre Aufgabe sein, die Tokens von der Erstausgabe einfach an den Schatzmeister ihres Kunden weiterzuleiten. Das mag nach hohem Risiko klingen, ist es aber nicht wirklich. Wenn der naive Entwickler dies ablehnt, würde der Client (alle anderen) den bereitgestellten Vertrag einfach ignorieren und erneut bereitstellen, diesmal mit einem zuverlässigeren Entwickler. Eigenschaften, die Token wertvoll machen, sind ein weiteres separates Anliegen.

Was als nächstes?

Ein Verkaufs-/Belohnungs-/Tauschprozess kann automatisiert oder manuell sein, daher ist es selbstverständlich, dies als separates Anliegen zu behandeln. Im automatisierten Fall wird ein Verkaufsvertrag, der ungefähr einen Verkaufsautomaten modelliert , vom Verkäufer mit Inventar geladen . Der Verkäufer kann einige oder alle Token, die er bei der Erstellung des Token-Vertrags erhalten hat, in den automatisierten Prozess einfügen.

Daher ist es naheliegend, bestimmte Anliegen eher zeremoniell als in einem Token-Vertrag anzusprechen. Ein ICO-Emittent kann beispielsweise:

  1. Prägen Sie die Token mit einem ERC20- (oder ähnlichen) Vertrag.
  2. Stellen Sie einen Kaufvertrag bereit.
  3. Übertragen Sie alle im Besitz befindlichen Token mit einer einfachen Brieftaschenübertragung in den Verkaufsvertrag.

Die Tatsachen des Prozesses sind für Beobachter leicht nachprüfbar. Per Definition, wenn die Kaufverträge die Token besitzen, dann nicht die Menschen.

Der ICO-Emittent hat eine gewisse Flexibilität. Sie können einige der Token zurückhalten oder sich das Recht vorbehalten, weitere zu erstellen. Die Trennung der Token-Kernfunktionen von Verkaufs-/Angebotsbelangen bedeutet, dass Standardverträge für den Token selbst verwendet werden können und der Verkaufsprozess separat angegangen werden kann.

Ich hoffe es hilft.