Here I have taken two of the top 20 ERC20 Token/ICO. 1.BNB(https://etherscan.io/address/0xB8c77482e45F1F44dE1745F52C74426C631bDD52#code) 2.BAT(https://etherscan.io/address/0x0d8775f648430679a709e98d2b0cb6250d2887ef#code) In BNB contract, when deployed it has been coded to set the total supply as the balance of the owner and the tokens are transferred from the owner to whoever buys the token , so the trust part lies in the owner/some particular acccount address, whereas in case of BATokens the tokens are generated and distributed as and when someone sends the ether to the contract, here the trust lies in the smart contract or it is what called as decentralised trust. Since BNB is topping in the etherscan, my doubt is why they haven't implemented the token handling in the contract like BATokens? Is there any technical issues like bugs, loop holes? Or is there any bussiness logics behind that?
1 Answer
This is conceptual.
While it is possible to load up an ERC20 contract with other concerns, let's assume that we will keep it pure.
Who has a token is not the same as what is a token.
A token contract defines the token. This includes how much exists or the method of issuance, and what they can do, which is transfers from one account to another if the conditions are right.
An ICO plan includes exchanging these tokens for funding. That can be treated as a separate concern in the same way a company can issue coupons, tickets, certificates and then exchange them for funds. It is self-evident that initially the company must be in possession, otherwise, how could they offer them for sale?
The tokens may even land in a developer's account. This doesn't mean the developer has any special status. It may be their task to simply forward the tokens from the initial issuance to their client's Treasurer. That might sound like high risk, but it isn't really. If the naive developer refuses to do so, the client (any everyone else) would simply ignore the deployed contract and deploy again, this time with a more reliable developer. Properties that make tokens valuable are yet another separate concern.
What next?
A sale/reward/exchange process can be automated or manual so it is natural to treat that as a separate concern. In the automated case, a sale contract that approximately models a vending machine is loaded up with inventory by the seller. The seller can put some or all of the tokens received when the token contract was created into the automated process.
Thus, it is natural to address certain concerns ceremonially rather than in a token contract. For example, an ICO issuer can:
- Mint the tokens with an ERC20 (or similar) contract.
- Deploy a sale contract.
- Transfer all of the owned tokens into the sale contract with a simple wallet transfer.
The facts of the process are easily verifiable by observers. By definition, if the sale contracts owns the tokens, then the humans do not.
The ICO issuer has some flexibility. They may withhold some of the tokens or reserve the right to create more. Separating the core token functions from sale/offering concerns means that standard contracts can be used for the token itself and the sale process can be addressed separately.
Hope it helps.
