Mefiance sur le BNB, etude du smart contract

[TheWolf666]

(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

Code:

function freeze(uint256 _value) returns (bool success) {
        if (balanceOf[msg.sender] < _value) throw;            // Check if the sender has enough
		if (_value <= 0) throw; 
        balanceOf[msg.sender] = SafeMath.safeSub(balanceOf[msg.sender], _value);                      // Subtract from the sender
        freezeOf[msg.sender] = SafeMath.safeAdd(freezeOf[msg.sender], _value);                                // Updates totalSupply
        Freeze(msg.sender, _value);
        return true;
    }

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.

Code:

    function burn(uint256 _value) returns (bool success) {
        if (balanceOf[msg.sender] < _value) throw;            // Check if the sender has enough
		if (_value <= 0) throw; 
        balanceOf[msg.sender] = SafeMath.safeSub(balanceOf[msg.sender], _value);                      // Subtract from the sender
        totalSupply = SafeMath.safeSub(totalSupply,_value);                                // Updates totalSupply
        Burn(msg.sender, _value);
        return true;
    }

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

Code:

    /* Allow another contract to spend some tokens in your behalf */
    function approve(address _spender, uint256 _value)
        returns (bool success) {
		if (_value <= 0) throw; 
        allowance[msg.sender][_spender] = _value;
        return true;

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.

[1714179080]

1714179080

[1714179080]

1714179080

[1714179080]

1714179080

[1714179080]

1714179080

[JeremyB]

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:

Code:

/* Allow another contract to spend some tokens in your behalf */

Je me dis que cette fonction a une autre utilité que celle que tu lui prêtes.
Et dans le code on voit:

Code:

allowance[msg.sender][_spender] = _value;

Qui indique une relation entre un sender et un spender, cette même variable allowance que l'on va retrouver dans la fonction

Code:

/* A contract attempts to get the coins */
function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {
        if (_to == 0x0) throw;                                // Prevent transfer to 0x0 address. Use burn() instead
		if (_value <= 0) throw; 
        if (balanceOf[_from] < _value) throw;                 // Check if the sender has enough
        if (balanceOf[_to] + _value < balanceOf[_to]) throw;  // Check for overflows
        if (_value > allowance[_from][msg.sender]) throw;     // Check allowance
        balanceOf[_from] = SafeMath.safeSub(balanceOf[_from], _value);                           // Subtract from the sender
        balanceOf[_to] = SafeMath.safeAdd(balanceOf[_to], _value);                             // Add the same to the recipient
        allowance[_from][msg.sender] = SafeMath.safeSub(allowance[_from][msg.sender], _value);
        Transfer(_from, _to, _value);
        return true;
    }

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

Code:

msg.sender

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.

[Saint-loup]

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]

Code:

allowance[msg.sender][_spender] = _value;

Code:

if (_value > allowance[_from][msg.sender]) throw;     // Check allowance

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)

Code:

 if (balanceOf[_from] < _value) throw;                 // Check if the sender has enough

[...]

balanceOf[_from] = SafeMath.safeSub(balanceOf[_from], _value);                           // Subtract from the sender

[TheWolf666]

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:

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.

[JeremyB]

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.

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.

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

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.

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.

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:

Code:

/**
    * @dev Approve the passed address to spend the specified amount of tokens on behalf of msg.sender.
    * @param _spender The address which will spend the funds.
    * @param _value The amount of tokens to be spent.
    */
    function approve(address _spender, uint _value) public onlyPayloadSize(2 * 32) {

        // To change the approve amount you first have to reduce the addresses`
        //  allowance to zero by calling `approve(_spender, 0)` if it is not
        //  already 0 to mitigate the race condition described here:
        //  https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
        require(!((_value != 0) && (allowed[msg.sender][_spender] != 0)));

        allowed[msg.sender][_spender] = _value;
        Approval(msg.sender, _spender, _value);
    }

• ZRX

Code:

    function approve(address _spender, uint _value) returns (bool) {
        allowed[msg.sender][_spender] = _value;
        Approval(msg.sender, _spender, _value);
        return true;
    }

• LINK:

Code:

/**
   * @dev Approve the passed address to spend the specified amount of tokens on behalf of msg.sender.
   * @param _spender The address which will spend the funds.
   * @param _value The amount of tokens to be spent.
   */
  function approve(address _spender, uint256 _value) returns (bool) {
    allowed[msg.sender][_spender] = _value;
    Approval(msg.sender, _spender, _value);
    return true;
  }

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.

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

A noter aussi qu'il n'y a pas de sécurité qui limite l'utilisation de ce contrat a son auteur uniquement.
Etrange.

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

[TheWolf666]

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

Code:

totalSupply = initialSupply;                        // Update total supply

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

Code:

totalSupply = SafeMath.safeSub(totalSupply,_value);                                // Updates totalSupply

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.

Code:

balanceOf[msg.sender] = initialSupply;              // Give the creator all initial tokens

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?

[JeremyB]

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)

[asche]

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

Pour rappel l'ICO de Binance portait sur 100 000 BNB et 50% (200 000) des coins: https://www.binance.vision/glossary/binance-coin
Je suppose que l'on est à moins maintenant à cause des burns.

100M pas 100k

Ca colle en rien avec le circulating supply de coinmarketcap...

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

'il n'y a pas de sécurité qui limite l'utilisation de ce contrat a son auteur uniquement.
Etrange.

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 :

Code:

        if (_value > allowance[_from][msg.sender]) throw;     // Check allowance

[JeremyB]

Bien vu pour les milliers/millions.

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
...
Coinmarketcap c'est de la daube et ça l'a toujours été

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

La seule fonction qui est limitée à l'auteur est la fonction burn je pense.

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

[asche]

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

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.

[JeremyB]

En l'occurrence non pas dans ce smart contract 

Code:

function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {
        if (_to == 0x0) throw;                                // Prevent transfer to 0x0 address. Use burn() instead

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

[Saint-loup]

En l'occurrence non pas dans ce smart contract  

Code:

function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {
        if (_to == 0x0) throw;                                // Prevent transfer to 0x0 address. Use burn() instead

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

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

(8) Market Capitalization (Cryptoasset)
Market capitalization of the cryptoasset is calculated by multiplying the existing reference price of the cryptoasset (3) by the current circulating supply (7). Let’s take the market capitalization of Bitcoin as an example:

Let (C) be the last known reference price of Bitcoin from CoinMarketCap in USD.
Let (S) be the current circulating supply of Bitcoin.
Let (D) be the derived market capitalization for Bitcoin.

For this example, let (C) = 10,000 USD / 1 BTC and let (S) = 17,000,000 BTC.

D = C * S
D = 10,000 USD / 1 BTC * 17,000,000 BTC = 170,000,000,000 USD

Therefore, the derived market capitalization for Bitcoin is $170,000,000,000 USD.

https://coinmarketcap.com/methodology/

[JeremyB]

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 ?

[asche]

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.

[JeremyB]

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.

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.

[guigui371]

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 !!