Topic: Mefiance sur le BNB, etude du smart contract (Read 352 times)

Et les gars !!!
Juste pour info je viens de passer deux jours a me casser la tete avec un de mes pote nocoiner qui n'arrivais pas a m'envoyer des BNB de son compte binance.JE  vers son compte binance.COM


Genre a croire que le gars etait un abrutit.

Je lui demande des screenshot, tout semble ok.

Je lui dis que MOI je vais lui envoyer 0.1bnb sur son compte .JE et son compte .COM

Et le je me rend compte que les bnb sur le binance.JE sont encore des ERC20 !!!!!

Non mais allo, pourquoi

Preuve ici : https://support.binance.je/hc/en-us/articles/360029108852-How-to-send-BNB-ERC20-token-

la flemme de mettre les screenshot des ses addresses deposit, mais bon j'ai trouve la solution.
Envoyer des BNB (ERC20) vers l'addresse ETH de binance au lieu de l'adresse BNB.

Serieux on marche sur la tete !!

LOL.
J'ai complètement zappé que c'était devenu un BEP2, tout ça pour ça, et de toute façon RAS sur l'ancien smart contract.

Effectivement total supply = circulating supply + Locked/lost supply


On en revient aux données fausses que vous utilisez depuis le début

Total supply : 187,536,714   
Circulating supply : 155,536,713
Max supply : 200,000,000   


J'espère que ça clarifie.

https://info.binance.com/en/currencies/binance-coin

La différence vient du fait que BNB n'est plus sur ERC20. La majorité des tokens a été burn/freeze/swap. Les données etherscan sont donc non représentatives. CMC en revanche devrait avoir les données correctes. Mais ce n'est pas le cas non plus.

OK merci pour la précision.
Mais ca ne change pas que le circulating supply ne peut être supérieur au total supply donc où est l'erreur ?

Oui mais le market cap c'est le prix basé sur le circulating supply , pas sur le total supply

https://coinmarketcap.com/methodology/

En l'occurrence non pas dans ce smart contract 

Par contre y'a encore un truc qui me titille, si tu as une explication je suis preneur.
OK tu dis que les données de cmc sont merdiques on le sait mais là on est sur un très gros écart. Mais surtout disons que le total supply est de 16,579,517 et quelques, le prix est de 30$ environ, ca nous donne un market cap de 497M loin des $4,657,115,242 annoncés sur cmc. Ce qui reléguerait le BNB à la 24ème place et non la 6ème (modulo le fait que toutes les autres data soit bonnes ok mais tu suis ce que je veux dire).
Wtf

En fait oui, c'est logique, de toutes façons tu peux aussi les envoyer sur 0x000...

Je voulais surtout dire qu'il n'est pas possible de burn les tokens d'une autre adresse.

Bien vu pour les milliers/millions.


OK effectivement c'est carrément pas à jour, et du coup le total supply colle avec les transactions de burn listées par ethplorer.


Apparemment non, pas de protection tu peux bruler tes coins si l'envie te prend

Je n'ai pas compris tes doutes sur la fonction burn et la modification du total supply.

1- le créateur publie le contrat sur la blockchain et l'initialise.
2- L'ensemble des tokens générés lui sont transférés.
3- les tokens sont distribués
4- les tokens superflus sont brûlés (seul moment ou le total supply est modifié).


petit rappel : Le MAX SUPPLY de BNB est 187,536,713 BNB.

Le total supply à cet instant (le total supply ne peux que diminuer suite à des burn) : 16,579,517.055253 BNB

---

100M pas 100k



Coinmarketcap c'est de la daube et ça l'a toujours été

---

La fonction freeze est probablement utile pour le staking.

---

Le contrat est public et tu peux interagir directement avec le contrat sur https://etherscan.io/token/0xB8c77482e45F1F44dE1745F52C74426C631bDD52#writeContract

---

Rien d'étrange.

Tout le monde utilise le contrat à chaque transfert, vérification de solde ou autre.
La seule fonction qui est limitée à l'auteur est la fonction burn je pense.

---

Comme déjà mentionné la fonction approve est tout à fait classique et est utilisée à chaque fois que tu utilises DDEX par exemple.

L'autorisation est d'ailleurs vérifiée ici :

Désolé mais je pense que ta théorie de conspiration est erronée.
Mais je comprends mieux d'où vient ton doute: en fait le total supply du contrat est le nombre de BNB qui reste assigné à cette adresse et non le total supply réel.
Si tu regardes coinmarketcap, le total supply est à jour et de plus de 187M.
Pour rappel l'ICO de Binance portait sur 100 000 100M BNB et 50% (200 000 200M) des coins: https://www.binance.vision/glossary/binance-coin
Je suppose que l'on est à moins maintenant à cause des burns.

Mais oui tu as raison sur le fait que le totalSupply n'est touché que par la fonction burn, alors pourquoi le contrat indique 16M ??
Un autre avis serait le bienvenu  
Je ne me suis pas lancé dans le décodage des paramètres de la fonction de création du contrat: https://etherscan.io/tx/0xbdab447ba2fd0a493d93635da202ebcfaa309bcc6a22a95d808c93ce8f1c6c2d mais il serait intéressant de savoir à combien il a été initialisé.

Un autre truc bizarre, dans Ethplorer il y a un onglet Insuance et là on a plusieurs burn dont un de plus de 86M de BNB: https://ethplorer.io/address/0xb8c77482e45f1f44de1745f52c74426c631bdd52#pageSize=100&tab=tab-issuances
Ca colle en rien avec le circulating supply de coinmarketcap...

Edit: correction milliers/millions (merci asche)

Ok, tu as raison, la fonction approve n'est pas problématique.

Donc repartons sur des bases fraiches, apres une nouvelle etude voila ce que j'ai trouvé

totalSupply qui doit contenir le nombre total de BNB est initialise au tout debut


Ensuite il n'est plus touché, a part dans  la function burn

Donc en théorie, la capitalisation totale de 16,579,517 BNB (16 Millions) ne peut pas augmenter (voir capitalisation / Total Supply ici: https://etherscan.io/token/0xB8c77482e45F1F44dE1745F52C74426C631bDD52 )

Sauf que, l'adresse de l'auteur du contrat est aussi initialisée au debut a la creation du contrat.


Normalement tous les tokens ont été donnés a l'auteur du contract, et cette somme devrait être la meme que totalSupply qui est la capitalisation totale donc 16,579,517 BNB

Regardons les transactions de l'auteur du contract: Address: 0x00C5E04176d95A286fccE0E68c683Ca0bfec8454
Les transactions commencent ici: https://ethplorer.io/address/0x00c5e04176d95a286fcce0e68c683ca0bfec8454#transfers=10
On est bien d'accord que cette adresse c'est ca:  balanceOf[msg.sender] = initialSupply;

Sur cette page il y a pour plus de 40 Millions de BNB en sortie. Et si tu regardes les autres pages, ici par example -64 Millions de BNB https://ethplorer.io/address/0x00c5e04176d95a286fcce0e68c683ca0bfec8454#transfers=5

Si on totalise on est a +120 Millions de BNB en circulation, en sortie de l'adresse de l'auteur du contract, mais seulement 16 Millions qui sont compté par le contrat BNB...

Ca veut dire que 104 Millions de BNB ne sont pas dans les échanges, mais peuvent venir a tout moment a la vente.

J'aimerais comprendre. Si quelqu'un a un second avis, ce serait sympa de le dire, je peux complètement me vautrer.

Voila ma Theorie.

BNB a la creation du contract a tout initialisé a 120 Millions.
Puis grace a la fonction burn, ils ont détruit 104 Millions, mais l'adresse de l'auteur du contrat a toujours les 120 Millions.

La difference sert a créer de la monnaie sans que cela se voit. puisque la balance balanceOf[msg.sender] contient toujours la totalité des BNB, mais que le totalSuply a été modifié, la somme de 16 Millions en circulation, qui sert a calculer la valeur nominale de chaque BNB est fausse vu qu'il y a en realite +160 Millions qui ont été delivé en sortie de l'adresse du contrat.
Fraude ou pas?

C'est là où je ne comprend pas ton avis, le code semble simple et tu n'expliques pas clairement où se situe la création de tokens.
Pour les commentaires bien sur tu peux mettre des explications et faire l'inverse dans le code, ce que je voulais dire c'est que si Binance s'était amusé à faire un truc aussi débile, on aurait du en entendre parler haut et fort.


Tu as raison sur ce point l'interface n'est pas respectée. Mais les fonctionnalités sont dispo, les variables balanceOf et totalSupply sont publiques.


Alors je m'avance encore une fois p/r à ma (non) connaissance de Solidity mais si je regarde au hasard d'autres smart contracts de tokens, j'ai peu ou prou exactement le même code et les mêmes commentaires:

• Tether:

• ZRX

• LINK:

Quand tu vois ça sur Etherscan il n'y a aucun doute sur le fait que ce soit le contrat officiel:




A quoi fais tu référence ? Je vois dans le code que des références à msg.sender ou tu parles d'autres choses. Des exemples dans d'autres smart contracts ?


PS: merci @guigui371 tu m'as mis un petit coup de vieux

Le code parle de lui meme. Le code est simple a comprendre, les commentaires c'est autre chose, ils peuvent dire ce qu'ils veulent.

Il est a noter que ce n'est pas un contract compatible ERC-20. Il manque des fonctions indispensable comme balanceOf et totalSupply.

C'est étrange. La fonction "approve" par exemple n'est pas conforme a la definition de celle-ci dans un contrat ERC-20.

La creation est faite de manière très subtile, en utilisant une adresse d'un autre contrat. Donc une adresse d'un autre contrat envoie des token a ce contrat. Le contrat present n'est pas celui que possède tous les token. Un autre contrat, ou plusieurs ont des tokens et peuvent envoyer un nombre indéterminé de token a ce contrat a partir d'une adresse externe.
C'est tordu mais cela ne veut pas dire qu'ils cherchent a masker le nombre total de token. Il faudrait passer plus de temps pour comprendre le mécanisme.

Il est aussi possible que ce contrat en particulier ne soit pas celui utilisé par le token BNB actuellement, ils ont put en publier un autre. Celui ci me semble bien simple. Ou alors ils ont partagé les fonctionnalités sur plusieurs contract "caché" et celui la ne fait que l'interface pour envoyer et recevoir. A noter aussi qu'il n'y a pas de sécurité qui limite l'utilisation de ce contrat a son auteur uniquement.
Etrange.

Je me suis fait cramer de 10minutes...  
Je comptais dire la meme chose que Jeremy, la matrice allowance sert visiblement juste dans la fonction transferFrom pour "caper" comme son nom l'indique le montant autorisé à être transféré (la limite du mandat).

msg.sender c'est l'adresse de celui qui execute le contrat, donc on voit que le 1er utilisateur(le mandant) place la valeur limite de son mandat dans la matrice à la case [son adresse][adresse du mandataire] et que le 2eme utilisateur (le mandataire) lorsqu'il veut executer le mandat en transférant ces coins est capé par cette valeur limite du mandat, puisque la fonction va la vérifier à la case [adresse du mandant][son adresse]



Et on voit mal comment des coins pourraient être créés ex nihilo puisque la fonction transferFrom réduit la balance du mandant d'autant de coins transférés et qu'elle vérifie avant qu'il en dispose d'assez dans sa balance(=> pas de découvert possible)

C'est très intéressant mais par contre es-tu sur de ce que tu avances ?
As tu trouvé d'autres sources validant cela, car cela me semble un peu gros la fonction de création de tokens illimités pour ne pas avoir fait de vagues.
Après je ne connais pas Solidity mais je me débrouille en codage:

Quand je lis le commentaire de la fonction approve:

Je me dis que cette fonction a une autre utilité que celle que tu lui prêtes.
Et dans le code on voit:
Qui indique une relation entre un sender et un spender, cette même variable allowance que l'on va retrouver dans la fonction
Et qui empêchera un transfert si allowance n'est pas suffisant.
Bref ca me semble légitime au vu du code et je ne vois pas de création de tokens. Merci de m'éclairer si je me plante.

Après pour le freeze, c'est sur que ca peut faire flipper. Je pense que c'est un garde fou en cas de piratage pour bloquer une ou plusieurs adresses, on aime ou on aime pas

Pour le burn c'est plutôt cool, car Binance régulièrement rachète des BNB et les brule, surement une des raisons de sa valeur ajd.
Dans le code je vois des ce qui me met la puce à l'oreille que seulement celui à l'origine de la transaction peut appeler cette fonction (sinon tout le monde pourrait cramer les jetons des autres non ?).
Perso j'aime bien cette fonction.

(non BNB ne signifie pas Bonobo)

Le Smart Contract est ici: https://etherscan.io/address/0xB8c77482e45F1F44dE1745F52C74426C631bDD52#code

Dans un autre thread il a été débattu de Binance et j'ai décidé de faire un thread séparé pour expliquer un petit truc qui devrait mettre la puce a l'oreille comme on dit.

Dans ce contrat il y a 3 choses qui sont intéressantes.

La premiere est freeze


Cette fonction en fait bloque des BNB de n'importe quelle adresse et les mets dans une table en attente. Avec la fonction inverse il est possible de unfreeze et donc de rendre a l'adresse en question ces avoirs qui avaient été bloqués. Pluto puissant comme truc, et particulièrement centralisé.

Autre fonction interessante: burn.


Cette fonction détruit purement et simplement les avoirs d'une adresse. Si c'est pas la votre ca va, si c'est la votre, vous avez tout perdu... puissant la aussi. On est loin de la décentralisation de Bitcoin.

Mais le pire est a venir. La fonction approve qui est clairement mal nommée en fait elle devrait s’appeler create_tokens


Cette fonction crée des Tokens (sans limite) et les donne a une adresse.

Conclusion. Le BNB est un contrat qui n'a comme fonction et utilité que de créer de la monnaie a l’infini et de les reprendre si nécessaire.
Il est ainsi possible de manipuler totalement le nombre de Token sur le marché, en créer plus, en supprimer, ou en retirer certains temporairement.
Manipuler le cours est extrêmement simple avec ces 3 fonctions.

C'est un contrat qui est petit mais puissant, et qui permet de contrôler totalement le nombre de tokens BNB disponible.

Les 3 fonctions devraient avoir comme nom, create_token, delete_token, block_token pour être plus explicite.