Erc-20 was originally intended as an attempt to provide a common standard of features and interfaces for token contracts on Ethereum, and it has proven to be very successful. Erc-20 has many benefits, including allowing wallets to display account balances of hundreds of different tokens; Create a trading tool that simply provides the address of the token contract to place more tokens in the table. The benefits of creating ERC-20 compatible tokens are so numerous that, today, few other token contracts are created any other way.

What is the Token contract?

There is still a lot of debate about what exactly a token contract is. In essence, a token Contract is a Smart Contract that contains a mapping of an account’s address and its balance. The account balance represents a value defined by the creator of the contract: a token contract might use the balance to represent a physical object, another monetary value, or the holder’s reputation. Units of balance are often referred to as tokens.

When a token is transferred from one account to another, the token contract updates the balance of both accounts. For example, a stroke from 0x2299… 3 ab7 x1f59 0… The transfer of 10 tokens of 3492 will cause the balance list to be updated as shown below:

There are two possible ways to change the total supply of a token if the token contract allows it. The total supply of tokens can be increased by minting new tokens. For example, casting 100 tokens to address 0x4ba5… Ae22 will cause the balance to be updated as shown below:

The total supply of tokens can also be reduced by “destroying” existing tokens. For example, 0 x4919… 413D destroyed 50 tokens, which will cause the balance to update as shown below:

Another way to destroy a token is to send it to an address where the private key has not been created, typically address 0. This makes these tokens unusable, and in this respect it has the same effect as destroying tokens, but does not reduce the total number of tokens. For example, 0 x93f1… 1B09 destroying 50 tokens in this way will result in the balance as shown below:

The simple Token contract holds the above information in a mapping from address to balance. As more complex scenarios emerge, such as dividend payments, alternative or complementary structures often become stronger. However, regardless of the operational details, the externally visible token balance always looks like the diagram above.

Definition of an ERC-20 token contract

An ERC-20 contract is defined by the address of the contract and the total supply of tokens available to it, but it usually also provides something that is not necessary and also provides more details for the user. They include the token’s name, symbol, and decimal place. Each of these is covered in the details below.

Before diving into the details, it’s important to understand this: The Token contract does not have a centralized registry, so there is no guarantee that certain names and symbols are unique. Once you have created a token contract, you should request that it be added to public sites such as Etherscan, MyEtherWallet and CoinMarketCap. Of course, making sure you follow the instructions on the website maximizes your chances of being accepted.

The name of the Token contract is the full name by which the Token contract should be known, such as “My Token”. There is no limit to the length of the name, but full names are more likely to appear incomplete in some wallet applications, so it’s best to keep the name short.

The Token contract is marked by a symbol that the Token contract should be known by, such as “MYT”. Broadly, it is the counterpart of the ticker symbol, and, although there is no strict length limit, it is often three or four letters in length.

Decimal places are often a source of confusion, but with proper explanation they are very easy to understand. Decimal places imply the divisibility of a token, ranging from 0 decimal places (i.e., completely undivisible) to 18 decimal places (almost continuous), with more decimal places if needed. Technically, the meaning of a decimal is to show the number of digits that follow the decimal point when the token value is on the screen. The reason for the existence of decimal places is that Ethereum doesn’t deal with numbers with decimals, only the numeric value of whole numbers. Consider the following two examples:

The first example is LicenseToken, a token contract that displays software licenses allocated for a given software product; With a LicenseToken, users can use the software. Holding less than one LicenseToken makes no sense, so the token creator sets the decimal to zero. Some LicenseToken holder account balances are listed below.

As you can see, there are 100 licenses here, mostly held in one account. When the user purchases a license, a token is transferred from the holding account to the buyer’s account. License verifiers can see if a particular account actually holds a LicenseToken and act accordingly.

The second example is GoldToken, a token contract representing ownership of physical gold. The contract’s creators wanted each unit to represent units of one kilogram of gold, but also wanted to allow users to hold and trade gold in grams (but no less). Since Ethereum does not support decimals, 1token must represent 1 gram of gold, and, in order to represent 1000 grams as a single 1Kg unit to the outside world, the decimal place must be set to 3 (since 10^3 grams, or 1 kg of gold, is the unit the token contract creator wants to display as 1token). Some GoldToken holders can be graphically represented below.

Here you can see that a total of 50Kg of gold is represented (1g per token times 50,000 tokens). However, if the decimal place is set to 3, the user’s situation looks like this:

As you can see, setting the decimal place to 3 literally means that there should be 3 digits following the decimal point when displaying the GoldToken balance.

The decimal place is often referred to as a human element because it allows the token contract to define how they want the balance to be displayed to the user. GoldToken does not process decimal places internally and never uses decimal places in its own calculations because everything is in grams, but it allows users to use the common unit of gold (kilograms) instead of the unit used in the contract (grams).

As shown in GoldToken above, the notion of sharability allows token contracts to display very small values, and tokens also often set the decimal place to 18 to give tokens a near-continuous range of value.

To summarize, the following rules should be followed when deciding how many decimal places to take:

  • Does the Token contract represent an indivisible object? Set the decimal place to 0

  • Does the Token contract represent an object with a specific decimal place? So set the decimal place to that number

  • If neither, set the decimal place to 18

It is important to know the effect of the decimal place on contract creation. The number of tokens created should equal the total number of tokens, in multiples of 10 to the decimal place. As you can see in the GoldToken example, the token creator wanted to create a token to represent 50 kg of gold, but because of three decimal places, they had to issue 50,000 tokens (50 x 10^3) to do it.

Aggregate supply is the last thing that defines an ERC-20 token contract, and, as we mentioned, it is the only mandatory parameter. Although not explicitly mentioned in the ERC-20 specification, the concept of aggregate supply is simple: aggregate supply equals the sum of all balances. Aggregate supply is always shown in the above example, so there is no need to elaborate here.

An ERC-20 token contract function

The ERC-20 Token contract has a range of functions that allow users to discover their balances and also allow the balances to be verified and transferred from one account to another. These functions are described below.

The balance() function provides the number of tokens held by a given address. Remember, anyone can check the balance of any address, just as all data is public on the blockchain.

There are two ways to send a token from one address to another. The tranfer() function can transfer some tokens directly from the message sender to an address. Remember, people don’t check the address, so it’s the responsibility of the sender to make sure the receiver acts as expected.

While it’s great to use transfer() to send toke to another user, the token doesn’t work when it’s being used to pay for a function in a smart contract. This is because, when a smart contract is running, it has no way of getting the details of which address to transfer to where, so there is no guarantee that the user calling the contract has paid the amount required to start the contract.

Imagine having a contract Doer deployed on a network. Doer has a function, doSomething (), which requires 10 Do tokens to run. Joe wants to call dosomething() and also has 50Do tokens in his account. How can Joe pay Doer so that dosomething() can run successfully?

Approve () and transferFrom() are two equations that use a two-step process to solve the above problem. In the first step, a token holder gives approval to another address (usually a smart contract) to transfer a maximum specified number of tokens locally, known as allowence. The Token holder provides this information using approve().

In the example above, the second line shows that the address is 0x1f59… Joe 3492 already allows address 0xD8f0… The Doer of C028 transfers 25 tokens from Joe’s account.

Once a license is created, the smart contract can take the license number of tokens from a user’s quota as part of the operation of the contract. Let’s continue with this example. Joe can now call DoSomething (), and Dosomething () can use transferFrom() to get 10 Do tokens from Joe’s account and start its work. If Joe does not have 10 tokens in his account, or if the quota is less than 10 tokens, doSomething () will crash.

The allowance() function provides the number of tokens allowed to be withdrawn from one given address to another given address. Remember, anyone can check the balance of any address, just as all information is public on the blockchain. It is important to know that quotas are “soft” because all individual or cumulative quotas can exceed the balance of an address. In the table shown above, the holder 0x2299… 3AB7 permits transfers of up to 500 tokens, but his balance, as shown above, is only 90 tokens. Any contracts that use allowance() must take additional account of the user’s balance when calculating the number of tokens available.

An event in the ERC-20 token contract

Erc-20 defines two types of events that must be triggered when a contract takes relevant action. The first type of event is Transfer(), which emits the details of a token Transfer from one address to another. The second type of event is Approval(), which releases details of the transfer of tokens from one address to another. These can be used to track changes in address balances and quotas without querying the blockchain.

Casting the token sends a Transfer() event with an O address as the source.

When a token is destroyed, no event is emitted. Because of this, erC-20 token contracts often destroy tokens by transferring () the token to address 0 instead of actual destruction.

Beyond the ERC – 20

Erc-20 provides a good basis for building token contracts, but it is not without problems. The ERC-223 protocol provides additional features and security measures, but is not compatible with ERC-20. The construction of Token contracts continues to follow ERC-20 today, and developers should track and contribute to the ERC-223 protocol.

The original link: https://medium.com/@jgm.orinoco/understanding-erc-20-token-contracts-a809 a7310aa5 author: Jim McDonald translation & editing: o sword & Elisa articles: the etheric fang lovers (https://ethfans.org/ajian1984/articles/686)Copy the code