Merge pull request #788 from moonbeam-foundation/eshaben/rt2600-remov…

…e-mintable-xc20s

remove mintable xc-20 docs

builders/get-started/eth-compare/security.md

@@ -128,17 +128,3 @@ On Ethereum, you can use this check to ensure that a given contract function can
 With the batch precompile, users can perform multiple calls to a contract atomically. The caller of the batch function will be the `msg.sender` and `tx.origin`, enabling multiple contract interactions at once.
 
 With the call permit precompile, if a user wants to interact with a contract multiple times in one transaction, they can do so by signing a permit for each contract interaction and dispatching all of the permits in a single function call. This will only bypass the `tx.origin == msg.sender` check if the dispatcher is the same account as the permit signer. Otherwise, the `msg.sender` will be the permit signer and the `tx.origin` will be the dispatcher, causing an exception to be thrown.
-
-## Mintable XC-20s vs ERC-20s {: #mintable-xc-20s-vs-erc-20s }
-
-[Mintable XC-20s](/builders/interoperability/xcm/xc20/mintable-xc20){target=_blank} are a form of [XC-20s](/builders/interoperability/xcm/xc20/overview){target=_blank} that are minted and burned in Moonbeam directly. Like all XC-20s, Mintable XC-20s are Substrate assets that can be interacted with through an ERC-20 interface via a precompile contract. With Mintable XC-20s specifically, the ERC-20 interface has been extended to include some [additional functionality](/builders/interoperability/xcm/xc20/mintable-xc20/#additional-functions){target=_blank}, such as the ability to mint and burn tokens, freeze and unthaw tokens and accounts, and more. This additional functionality is similar to the standard ERC-20 extensions in Ethereum, like the [ERC20Mintable](https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#ERC20Mintable){target=_blank}, [ERC20Burnable](https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#ERC20Burnable){target=_blank}, and [ERC20Pausable](https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#ERC20Pausable){target=_blank} extensions, **but it is important to note that they are not exactly the same**.
-
-A common Ethereum ERC-20 [`burn` function](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L277-L293){target=_blank} requires that the account the tokens are being burned from has at least the requested amount of tokens to burn.  That is, if a user calls the function trying to burn more tokens that they actually own, the call will fail.
-
-In Substrate, the functionality differs, and that requirement does not exist. Consequently, a user might call the function with a much larger burn amount that what they actually hold, and the call will be successful, but only the amount of tokens they hold will be burned. With that being said, you'll need to manually require that the account has enough tokens, using the [require function](https://docs.soliditylang.org/en/v0.8.17/control-structures.html#panic-via-assert-and-error-via-require){target=_blank}, like so:
-
-```solidity
-require(mintableERC20.balanceOf(from) >= value, "burn amount exceeds balance")
-```
-
-Additionally, it is also important to note that for Mintable XC-20s the maximum `value` (or total supply) that can be minted is actually limited to *uint128*, compared to common mintable ERC-20s where the total supply is capped to *uint256*. A Mintable XC-20 will behave differently if the total supply is over 2^128 (without decimals), the mint will fail due to overflow checks. This is unlikely to happen for traditional tokens as they are not meant to reach such high numbers, but nonetheless is important to mention as this is different than the standard Ethereum ERC-20.