From b9acc8c1428cbc373d4883e1712173b7b25fcf06 Mon Sep 17 00:00:00 2001 From: Kevin Neilson Date: Wed, 12 Feb 2025 08:32:07 -0800 Subject: [PATCH] revisions --- .../precompiles/ux/erc20/erc-20-interface.md | 19 ------------------ .../interoperability/xcm/xc20/interact.md | 20 ++++++++++++++++++- .../remote-batched-evm-calls.md | 2 +- .../interoperability/remote-staking-xcm.md | 2 +- 4 files changed, 21 insertions(+), 22 deletions(-) delete mode 100644 .snippets/text/builders/ethereum/precompiles/ux/erc20/erc-20-interface.md diff --git a/.snippets/text/builders/ethereum/precompiles/ux/erc20/erc-20-interface.md b/.snippets/text/builders/ethereum/precompiles/ux/erc20/erc-20-interface.md deleted file mode 100644 index 99fdf53fb..000000000 --- a/.snippets/text/builders/ethereum/precompiles/ux/erc20/erc-20-interface.md +++ /dev/null @@ -1,19 +0,0 @@ -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 \ No newline at end of file diff --git a/builders/interoperability/xcm/xc20/interact.md b/builders/interoperability/xcm/xc20/interact.md index 31f72d36e..b9c3745da 100644 --- a/builders/interoperability/xcm/xc20/interact.md +++ b/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 } diff --git a/tutorials/interoperability/remote-batched-evm-calls.md b/tutorials/interoperability/remote-batched-evm-calls.md index 44a50b971..ee4e1921b 100644 --- a/tutorials/interoperability/remote-batched-evm-calls.md +++ b/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: diff --git a/tutorials/interoperability/remote-staking-xcm.md b/tutorials/interoperability/remote-staking-xcm.md index b7deec3ef..04ae4d601 100644 --- a/tutorials/interoperability/remote-staking-xcm.md +++ b/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.