Edited 10tokens.asciidoc with Atlas code editor

10tokens.asciidoc

@@ -162,7 +162,7 @@ http://bit.ly/2CUf7WG[The ERC20 standard] defines a common interface for contrac
 
 +symbol+:: Returns a human-readable symbol (e.g., "USD") for the token.
 
-+decimals+:: Returns the number of decimals used to divide token amounts. For example, if +decimals+ is +2+, then the token amount is divided by 100 to get its user representation.
++decimals+:: Returns the number of decimals used to divide token amounts. For example, if +decimals+ is +2+, then the token amount is divided by 100 to get its user pass:[<span class="keep-together">representation</span>].
 
 [[ERC20_interface]]
 ===== The ERC20 interface defined in Solidity
@@ -710,7 +710,7 @@ However, the burden of managing ERC20 tokens correctly is pushed to the user int
 
 ((("ERC20 token standard","issues with ERC20 tokens")))The adoption of the ERC20 token standard has been truly explosive. Thousands of tokens have been launched, both to experiment with new capabilities and to raise funds in various "crowdfund" auctions and ICOs. However, there are some potential pitfalls, as we saw with the issue of transferring tokens to contract addresses.
 
-One of the less obvious issues with ERC20 tokens is that they expose subtle differences between tokens and ether itself. Where ether is transferred by a transaction that has a recipient address as its destination, token transfers occur within the _specific token contract state_ and have the token contract as their destination, not the recipient's address. The token contract tracks balances and issues events. In a token transfer, no transaction is actually sent to the recipient of the token. Instead, the recipient's address is added to a map within the token contract itself. A transaction sending ether to an address changes the state of an address. A transaction transferring a token to an address only changes the state of the token contract, not the state of the recipient address. Even a wallet that has support for ERC20 tokens does not become aware of a token balance unless the user explicitly adds a specific token contract to "watch." Some wallets watch the most popular token contracts to detect balances held by addresses they control, but that's limited to a small fraction of existing ERC20 contracts.
+One of the less obvious issues with ERC20 tokens is that they expose subtle differences between tokens and ether itself. Where ether is transferred by a transaction that has a recipient address as its destination, token transfers occur within the _specific token contract state_ and have the token contract as their destination, not the recipient's address. The token contract tracks balances and issues events. In a token transfer, no transaction is actually sent to the recipient of the token. Instead, the recipient's address is added to a map within the token contract itself. A transaction sending ether to an address changes the state of an address. A transaction transferring a token to an address only changes the state of the token contract, not the state of the recipient address. Even a wallet that has support for ERC20 tokens does not become aware of a token balance unless the user explicitly adds a specific token contract to "watch." Some wallets watch the most popular token contracts to detect balances held by addresses they control, but that's limited to a small fraction of existing ERC20 pass:[<span class="keep-together">contracts</span>].
 
 In fact, it's unlikely that a user would _want_ to track all balances in all possible ERC20 token contracts. Many ERC20 tokens are more like email spam than usable tokens. They automatically create balances for accounts that have ether activity, in order to attract users. If you have an Ethereum address with a long history of activity, especially if it was created in the presale, you will find it full of "junk" tokens that appeared out of nowhere. Of course, the address isn't really full of tokens; it's the token contracts that have your address in them. You only see these balances if these token contracts are being watched by the block explorer or wallet you use to view your address.
 
@@ -776,7 +776,7 @@ ERC223 is not widely implemented, and there is some debate in https://github.com
 * To transfer tokens using a +send+ function, similar to ether transfers
 * To be compatible with ERC820 for token contract registration
 * To allow contracts and addresses to control which tokens they send through a `tokensToSend` function that is called prior to sending
-* To enable contracts and addresses to be notified of the tokens' receipt by calling a `tokensReceived` function in the recipient, and to reduce the probability of tokens being locked into contracts by requiring contracts to provide a +tokensReceived+ function
+* To enable contracts and addresses to be notified of the tokens' receipt by calling a `tokensReceived` function in the recipient, and to reduce the probability of tokens being locked into contracts by requiring contracts to provide a pass:[<span class="keep-together"><code>tokensReceived</code></span>] function
 * To allow existing contracts to use proxy contracts for the +tokensToSend+ and +tokensReceived+ functions
 * To operate in the same way whether sending to a contract or an EOA
 * To provide specific events for the minting and burning of tokens