revisions

builders/interoperability/xcm/xc20/interact.md

@@ -19,7 +19,25 @@ Both types of XC-20s have the standard ERC-20 interface. In addition, all extern
 
 As mentioned, you can interact with XC-20s via an ERC-20 interface. The [ERC20.sol](https://github.com/moonbeam-foundation/moonbeam/blob/master/precompiles/assets-erc20/ERC20.sol){target=\_blank} interface on Moonbeam follows the [EIP-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20){target=\_blank}, which is the standard API interface for tokens within smart contracts. The standard defines the required functions and events that a token contract must implement to be interoperable with different applications.
 
---8<-- 'text/builders/ethereum/precompiles/ux/erc20/erc20-interface.md'
+The interface includes the following functions:
+
+- **name()** — read-only function that returns the name of the token
+- **symbol()** — read-only function that returns the symbol of the token
+- **decimals()** — read-only function that returns the decimals of the token
+- **totalSupply()** — read-only function that returns the total number of tokens in existence
+- **balanceOf**(*address* who) — read-only function that returns the balance of the specified address
+- **allowance**(*address* owner, *address* spender) —  read-only function that checks and returns the amount of tokens that a spender is allowed to spend on behalf of the owner
+- **transfer**(*address* to, *uint256* value) — transfers a given amount of tokens to a specified address and returns `true` if the transfer was successful
+- **approve**(*address* spender, *uint256* value) — approves the provided address to spend a specified amount of tokens on behalf of `msg.sender`. Returns `true` if successful
+- **transferFrom**(*address* from, *address* to, *uint256* value) — transfers tokens from one given address to another given address and returns `true` if successful
+
+!!! note
+    The ERC-20 standard does not specify the implications of multiple calls to `approve`. Changing an allowance with this function numerous times enables a possible attack vector. To avoid incorrect or unintended transaction ordering, you can first reduce the `spender` allowance to `0` and then set the desired allowance afterward. For more details on the attack vector, you can check out the [ERC-20 API: An Attack Vector on Approve/TransferFrom Methods](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit#){target=_blank} overview.
+
+The interface also includes the following required events:
+
+- **Transfer**(*address indexed* from, *address indexed* to, *uint256* value) - emitted when a transfer has been performed
+- **Approval**(*address indexed* owner, *address indexed* spender, *uint256* value) - emitted when an approval has been registered
 
 ### The ERC-20 Permit Solidity Interface {: #the-erc20-permit-interface }
 

tutorials/interoperability/remote-batched-evm-calls.md

@@ -40,7 +40,7 @@ Considering all the steps summarized in the [introduction](#introduction), the f
 
 ## Calculating your Computed Origin Account {: #calculating-your-computed-origin-account }
 
---8<-- 'text/builders/interoperability/xcm/calculate-multilocation-derivative-account.md'
+--8<-- 'text/builders/interoperability/xcm/calculate-computed-origin-account.md'
 
 For our case, we will send the remote EVM call via XCM from Alice's account, which is `5Fe4nNwxJ9ai9hVkUubiy4e6BVs1tzJGDLXAdhUKuePq9CLp`. A parachain ID is omitted from the command since we are sending the XCM instruction from the relay chain. A parents value of `1` indicates that the relay chain is a parent of the destination parachain. The command and response should resemble the following image:
 

tutorials/interoperability/remote-staking-xcm.md

@@ -26,7 +26,7 @@ For development purposes this tutorial is written for Moonbase Alpha and Moonbas
 
 ## Calculating your Computed Origin Account {: #calculating-your-computed-origin-account }
 
---8<-- 'text/builders/interoperability/xcm/calculate-multilocation-derivative-account.md'
+--8<-- 'text/builders/interoperability/xcm/calculate-computed-origin-account.md'
 
 Here, we have specified a parents value of `1` because the relay chain is the origin of the request (and the relay chain is considered a parent to the Moonbase alpha parachain). The relay chain does not have a parachain id so that field is omitted.