Merci @asche pour tes retours. Je connaissais pas Lendosphère, je vais creuser le truc (pas pour le cashback mais pour les projets Ben en tout cas en voyant les conditions d'achats ca n'a pas l'air d'être exclus un bijoutier. Même un site marchand vendant exclusivement de l'or/argent, métaux précieux j'ai encore un doute. Si @JeremyB veut essayer ca m'arrangerai Alors j'ai pas de bijoutier ou vendeur d'or sous la main où je suis. Et j'ai surtout pas de carte Binance pour le moment Mais de toute façon faut pas rêver ça pourrait peut être marcher une paire de fois mais des transactions répétées chez un même marchand devrait déclencher un truc de sécurité de leur côté, pas possible autrement. Ce qui est chiant c'est qu'il faut avoir un certaine somme de bloquée pour être éligible à 8%...
Perso je vise pas les 8% mais déjà 5% serait sympa, surtout si ça passe tout de même sur pas mal d'achats.
|
|
|
Pareil il m'avait semblé voir une liste d'opérations non supportées mais je ne sais plus où. Ou ils ont mis à jour leur page depuis. Ah mince tu crois qu'on peut pas avec l'or, tu viens de démolir mon projet lumineux
|
|
|
Merci pour ta réponse. Dans l'exemple de leur FAQ pour expliquer le calcul, ils indiquent: ** "Settled" purchase or transaction means that the funds of this purchase have arrived to the bank account of the seller, e.g. your grocery store. Je sais pas si ça veut dire que cela fonctionne avec ton épicerie du coin (et du coup normal qu'il n'y ait pas une liste exhaustive) ou si leur exemple est très mal choisi.
|
|
|
Quelqu'un peut me renseigner sur les achats donnant droit à Cashback avec la Binance Card ? Dans leur FAQ ils indiquent que la liste des "qualified merchants" peut changer mais impossible de trouver une liste.
|
|
|
Sympa comme idée 25% XRM 25% NEO 25% LINK 25% HBAR Halab, petite erreur de recopie pour ma part: De toute façon obligé de changer HBAR vient de péter la barre du top 100, donc: 25% NEO 25% LINK 25% HBAR 25% PIVX Merci.
|
|
|
Sympa comme idée 25% XRM 25% NEO 25% LINK 25% HBAR
|
|
|
C'est vrai que pour l'instant ce n'est pas incroyable, je suis à un peu plus de 50% de mon roi.
Si tu ouvres tes box en x2 non ? J'y suis pas encore non plus mais à ce rythme le ROI sera pour dans quelques années... Mais un special event va arriver qui va j'espère changer la donne. La team just organise un évènement pour promouvoir le jeu et faire venir des baleines. Ils vont offrir 33% de réductions à ceux qui achèteront plus de 10M trx de boites (limité aux 10 plus gros acheteurs). Et pour chaque tranche de 100M ajouté par cet évènement, ils rajouteront 10M de trx (capé à 97M, somme qu'ils ont obtenue via les revenues versés aux dev lors d'achat sans passer par un lien d'affiliation). Donc potentiellement +1Milliard de trx dans le jeu... Cet évènement aura lieu le 10 janvier, donc si certains veulent acheter faites-le avant le 10.
Quand j'ai vu cette news, je me suis dit aïe ils commencent à chercher des trucs à la con pour faire marcher leur jeu. Mais bon on verra bien si cela fonctionne, ca serait en tout cas une bonne chose pour la suite. Sinon je suis ça un peu de loin mais il semblerait qu'il y ait eu un "Glitch" ce matin, tout le monde n'aurait apparemment pas reçu le même nb de trx, je sais même pas comment voir ce que j'ai reçu ou pas...
|
|
|
Merci pour le post. Je voulais en faire un mais je n'en ai pas eu le temps, fêtes oblige Le début a été un peu cahotique, et écouter Justin Sun essayer de sauver les meubles, baragouiner pleins de conneries et bugger (hun hun hun hun...) était assez rigolo. J'avais un peu les boules tout de même de m'être levé pour ce bordel, et pas arriver à acheter les boites en tout début à cause du bug sur le wallet Quelques trucs que je note: - pour moi les ref n'ont pas marché, je devrais en avoir au moins 2 et j'ai toujours 0 sur le compte. Je suis allé sur le Discord, pas eu de réponse mais ils ont répondu à un gars à propos d'un problème similaire et on peut regarder sur l'ordi de son filleul dans le local storage si y'a bien la config, puis dans les transactions Tron, j'ai pas encore creusé, on verra ça + tard - ca hype pas des masses pour le moment je trouve, bon ou mauvais signe ? Bon = y être tôt sera payant, Mauvais = ca va rester comme ça et sera un flop - ca sera un jeu de bots pour les gros lots (si le timer arrive à 0 un jour ce qui n'est pas gagné), faut à mon avis même pas essayer de chercher à ce niveau
|
|
|
Ca fait un bail que je n'ai pas utilisé Kraken mais à l'époque il y avait 2 authentifications, une de connexion et une autre pour les ordres/dépôts/retraits...
|
|
|
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.
|
|
|
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 ?
|
|
|
En l'occurrence non pas dans ce smart contract 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
|
|
|
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
|
|
|
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: /** * @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); } function approve(address _spender, uint _value) returns (bool) { allowed[msg.sender][_spender] = _value; Approval(msg.sender, _spender, _value); return true; } /** * @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
|
|
|
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: /* 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: 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 /* 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 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.
|
|
|
Merci pour ton travail (+1 merit ). Pour info j'ai reçu les nouveaux EQL.
|
|
|
Sinon, informations supplémentaires pour le Swap Equal : Il faut déposer au moins 0.02 ETH sur le Wallet Equal pour pouvoir faire la demande de Swap. A noter qu'une fois la demande effectué, vous pouvez renvoyer vos ETH sur votre adresse perso. Juste un petit doute perso, est-ce qu'il y a besoin de les garder sur le wallet Equal pour le swap justement ? Si quelqu'un à l'info, je suis preneur Autrement la demande de swap se fait facilement, et l'interface est très agréable à utiliser ^^ A mon sens plus besoin d'ETH, il y en a besoin à la base pour exécuter la fonction de leur smart contract. Ensuite lors du swap c'est eux qui exécute/envoie donc pas besoin d'ETH pour recevoir. 2 infos: - leur wallet me fait bugger Metamask/MEW (il affiche le portefeuille EQUAL à la place) - j'ai du le désactiver pour utiliser Metamask sur MEW - j'ai eu un "out of gas" sur l'envoi de mes EQL en le faisant à partir de Metamask seul (il doit surement mal lire les infos car MEW m'a proposé ensuite mieux) - il me fallait 56K
|
|
|
Ah ben tout est très relatif. Ton EQL qui fait x8... sauf qu'il a fait -90% avant donc comme flambée, on retrouve juste le prix au lancement Oui c'est sur mais revenir au niveau de Janvier 2018 c'est quand même ultra rare surtout pour un ad Ca me rapelle ces groupes Telegram de "pump & dump" que tu peux rejoindre gratuitement pour savoir quelle crypto ils vont pumper et profiter. Une fois, ils ont préparés tout un évènement, ça devait être épique ... Ils ont teasés, "on annonce le coin a pump a telle heure" ... Hah on était tous au taquet. Finalement l'heure est arrivée, et le coin a just dump. -_-' Y'a pas eu de pump quoi .. C'était pathétique Lol celle-là je l'avais jamais vue/entendue Mais bon au résultat peut être équivalent au classique je rentre dans le pump au moment où il s'arrête et dégringolade directe après...
|
|
|
|