Wrapped MIR Token token: ico review, security check & audits
Overview
Wrapped MIR is an ERC20 token that represents the MIR coin on the Ethereum network. MIR is a core element of the decentralized Mirror Protocol created on the Terra blockchain.
The Mirror project generates synthetic crypto tokens called Mirror Assets (mAssets) that reflect the price behavior of corresponding fiat counterparts. Users can trade them on secondary markets like the underlying assets.
The difference in prices creates arbitrage opportunities. If a fiat asset is traded at a higher price on the exchange, the market participants can mint additional coins and sell them on Terraswap to gain benefit. If the cost is lower, the mAsset is purchased and burned.
MIR is a governance token, which is generated through the process of mining. The fixed supply of coins makes it inflation-resistant. It is used for staking to secure the system, farming tokens from other DeFi projects, as a reward, and for protocol management. Liquidity providers are rewarded with MIR tokens that come from the fees paid for closing positions on mAssets, trading. MIR holders who stake MIR also earn the withdrawal fees. To earn MIR tokens users can stake LUNA (the Terra native coin), provide liquidity to MIR/UST pair or to any mAsset/UST pool pairs.
MIR stakers can participate in system management and create new governance proposals. The voting power depends on the amount of MIR staked by users. If the proposal is rejected that deposit is forfeit.
Wrapped MIR is exchanged with MIR at a 1:1 ratio. It can be bought, traded, and stored like any other digital asset.
Wrapped MIR Token token price chart
Security checks of MIR token
An overflow/underflow happens when an arithmetic operation reaches the maximum or minimum size of a type. For instance if a number is stored in the uint8 type, it means that the number is stored in a 8 bits unsigned number ranging from 0 to 2^8-1. In computer programming, an integer overflow occurs when an arithmetic operation attempts to create a numeric value that is outside of the range that can be represented with a given number of bits – either larger than the maximum or lower than the minimum representable value.
The return value of a message call is not checked. Execution will resume even if the called contract throws an exception. If the call fails accidentally or an attacker forces the call to fail, this may cause unexpected behaviour in the subsequent program logic.
Due to missing or insufficient access controls, malicious parties can withdraw some or all Ether from the contract account. This bug is sometimes caused by unintentionally exposing initialization functions. By wrongly naming a function intended to be a constructor, the constructor code ends up in the runtime byte code and can be called by anyone to re-initialize the contract.
Due to missing or insufficient access controls, malicious parties can self-destruct the contract.
One of the major dangers of calling external contracts is that they can take over the control flow. In the reentrancy attack (a.k.a. recursive call attack), a malicious contract calls back into the calling contract before the first invocation of the function is finished. This may cause the different invocations of the function to interact in undesirable ways.
The Solidity assert() function is meant to assert invariants. Properly functioning code should never reach a failing assert statement.
Several functions and operators in Solidity are deprecated. Using them leads to reduced code quality. With new major versions of the Solidity compiler, deprecated functions and operators may result in side effects and compile errors.
There exists a special variant of a message call, named delegatecall which is identical to a message call apart from the fact that the code at the target address is executed in the context of the calling contract and msg.sender and msg.value do not change their values. This allows a smart contract to dynamically load code from a different address at runtime. Storage, current address and balance still refer to the calling contract.
External calls can fail accidentally or deliberately, which can cause a DoS condition in the contract. To minimize the damage caused by such failures, it is better to isolate each external call into its own transaction that can be initiated by the recipient of the call. This is especially relevant for payments, where it is better to let users withdraw funds rather than push funds to them automatically (this also reduces the chance of problems with the gas limit).
As for block.number, considering the block time on Ethereum is generally about 14 seconds, it's possible to predict the time delta between blocks. However, block times are not constant and are subject to change for a variety of reasons, e.g. fork reorganisations and the difficulty bomb. Due to variable block times, block.number should also not be relied on for precise calculations of time.
The implementation of a cryptographic signature system in Ethereum contracts often assumes that the signature is unique, but signatures can be altered without the possession of the private key and still be valid. The EVM specification defines several so-called ‘precompiled’ contracts one of them being ecrecover which executes the elliptic curve public key recovery. A malicious user can slightly modify the three values v, r and s to create other valid signatures. A system that performs signature verification on contract level might be susceptible to attacks if the signature is part of the signed message hash. Valid signatures could be created by a malicious user to replay previously signed messages.
The implementation of a cryptographic signature system in Ethereum contracts often assumes that the signature is unique, but signatures can be altered without the possession of the private key and still be valid. The EVM specification defines several so-called ‘precompiled’ contracts one of them being ecrecover which executes the elliptic curve public key recovery. A malicious user can slightly modify the three values v, r and s to create other valid signatures. A system that performs signature verification on contract level might be susceptible to attacks if the signature is part of the signed message hash. Valid signatures could be created by a malicious user to replay previously signed messages.
A smart contract's data (e.g., storing the owner of the contract) is persistently stored at some storage location (i.e., a key or address) on the EVM level. The contract is responsible for ensuring that only authorized user or contract accounts may write to sensitive storage locations. If an attacker is able to write to arbitrary storage locations of a contract, the authorization checks may easily be circumvented. This can allow an attacker to corrupt the storage; for instance, by overwriting a field that stores the address of the contract owner.
Solidity supports function types. That is, a variable of function type can be assigned with a reference to a function with a matching signature. The function saved to such variable can be called just like a regular function.