Orchid BitwaveMultiSend

code/BitwaveMultiSend.sol
  3:7      error      "./ERC20.sol": Import statements must use double quotes only.                              quotes
  22:16    error      There should be no whitespace between "address payable" and the opening square bracket.    array-declarations
  24:8     warning    Provide an error message for require()                                                     error-reason
  25:8     warning    Provide an error message for require()                                                     error-reason
  34:19    warning    Consider using 'transfer' in place of 'send'.                                              security/no-send
  40:19    warning    Consider using 'transfer' in place of 'send'.                                              security/no-send
  47:8     warning    Provide an error message for require()                                                     error-reason
  48:8     warning    Provide an error message for require()                                                     error-reason

✖ 2 errors, 6 warnings found.

  1// File: openzeppelin-solidity/contracts/math/SafeMath.sol
  2
  3pragma solidity ^0.5.0;
  4
  5/**
  6 * @dev Wrappers over Solidity's arithmetic operations with added overflow
  7 * checks.
  8 *
  9 * Arithmetic operations in Solidity wrap on overflow. This can easily result
 10 * in bugs, because programmers usually assume that an overflow raises an
 11 * error, which is the standard behavior in high level programming languages.
 12 * `SafeMath` restores this intuition by reverting the transaction when an
 13 * operation overflows.
 14 *
 15 * Using this library instead of the unchecked operations eliminates an entire
 16 * class of bugs, so it's recommended to use it always.
 17 */
 18library SafeMath {
 19    /**
 20     * @dev Returns the addition of two unsigned integers, reverting on
 21     * overflow.
 22     *
 23     * Counterpart to Solidity's `+` operator.
 24     *
 25     * Requirements:
 26     * - Addition cannot overflow.
 27     */
 28    function add(uint256 a, uint256 b) internal pure returns (uint256) {
 29        uint256 c = a + b;
 30        require(c >= a, "SafeMath: addition overflow");
 31
 32        return c;
 33    }
 34
 35    /**
 36     * @dev Returns the subtraction of two unsigned integers, reverting on
 37     * overflow (when the result is negative).
 38     *
 39     * Counterpart to Solidity's `-` operator.
 40     *
 41     * Requirements:
 42     * - Subtraction cannot overflow.
 43     */
 44    function sub(uint256 a, uint256 b) internal pure returns (uint256) {
 45        require(b <= a, "SafeMath: subtraction overflow");
 46        uint256 c = a - b;
 47
 48        return c;
 49    }
 50
 51    /**
 52     * @dev Returns the multiplication of two unsigned integers, reverting on
 53     * overflow.
 54     *
 55     * Counterpart to Solidity's `*` operator.
 56     *
 57     * Requirements:
 58     * - Multiplication cannot overflow.
 59     */
 60    function mul(uint256 a, uint256 b) internal pure returns (uint256) {
 61        // Gas optimization: this is cheaper than requiring 'a' not being zero, but the
 62        // benefit is lost if 'b' is also tested.
 63        // See: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/522
 64        if (a == 0) {
 65            return 0;
 66        }
 67
 68        uint256 c = a * b;
 69        require(c / a == b, "SafeMath: multiplication overflow");
 70
 71        return c;
 72    }
 73
 74    /**
 75     * @dev Returns the integer division of two unsigned integers. Reverts on
 76     * division by zero. The result is rounded towards zero.
 77     *
 78     * Counterpart to Solidity's `/` operator. Note: this function uses a
 79     * `revert` opcode (which leaves remaining gas untouched) while Solidity
 80     * uses an invalid opcode to revert (consuming all remaining gas).
 81     *
 82     * Requirements:
 83     * - The divisor cannot be zero.
 84     */
 85    function div(uint256 a, uint256 b) internal pure returns (uint256) {
 86        // Solidity only automatically asserts when dividing by 0
 87        require(b > 0, "SafeMath: division by zero");
 88        uint256 c = a / b;
 89        // assert(a == b * c + a % b); // There is no case in which this doesn't hold
 90
 91        return c;
 92    }
 93
 94    /**
 95     * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),
 96     * Reverts when dividing by zero.
 97     *
 98     * Counterpart to Solidity's `%` operator. This function uses a `revert`
 99     * opcode (which leaves remaining gas untouched) while Solidity uses an
100     * invalid opcode to revert (consuming all remaining gas).
101     *
102     * Requirements:
103     * - The divisor cannot be zero.
104     */
105    function mod(uint256 a, uint256 b) internal pure returns (uint256) {
106        require(b != 0, "SafeMath: modulo by zero");
107        return a % b;
108    }
109}

  1// File: openzeppelin-solidity/contracts/token/ERC20/IERC20.sol
  2
  3pragma solidity ^0.5.0;
  4
  5/**
  6 * @dev Interface of the ERC20 standard as defined in the EIP. Does not include
  7 * the optional functions; to access them see `ERC20Detailed`.
  8 */
  9interface IERC20 {
 10    /**
 11     * @dev Returns the amount of tokens in existence.
 12     */
 13    function totalSupply() external view returns (uint256);
 14
 15    /**
 16     * @dev Returns the amount of tokens owned by `account`.
 17     */
 18    function balanceOf(address account) external view returns (uint256);
 19
 20    /**
 21     * @dev Moves `amount` tokens from the caller's account to `recipient`.
 22     *
 23     * Returns a boolean value indicating whether the operation succeeded.
 24     *
 25     * Emits a `Transfer` event.
 26     */
 27    function transfer(address recipient, uint256 amount) external returns (bool);
 28
 29    /**
 30     * @dev Returns the remaining number of tokens that `spender` will be
 31     * allowed to spend on behalf of `owner` through `transferFrom`. This is
 32     * zero by default.
 33     *
 34     * This value changes when `approve` or `transferFrom` are called.
 35     */
 36    function allowance(address owner, address spender) external view returns (uint256);
 37
 38    /**
 39     * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
 40     *
 41     * Returns a boolean value indicating whether the operation succeeded.
 42     *
 43     * > Beware that changing an allowance with this method brings the risk
 44     * that someone may use both the old and the new allowance by unfortunate
 45     * transaction ordering. One possible solution to mitigate this race
 46     * condition is to first reduce the spender's allowance to 0 and set the
 47     * desired value afterwards:
 48     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
 49     *
 50     * Emits an `Approval` event.
 51     */
 52    function approve(address spender, uint256 amount) external returns (bool);
 53
 54    /**
 55     * @dev Moves `amount` tokens from `sender` to `recipient` using the
 56     * allowance mechanism. `amount` is then deducted from the caller's
 57     * allowance.
 58     *
 59     * Returns a boolean value indicating whether the operation succeeded.
 60     *
 61     * Emits a `Transfer` event.
 62     */
 63    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
 64
 65    /**
 66     * @dev Emitted when `value` tokens are moved from one account (`from`) to
 67     * another (`to`).
 68     *
 69     * Note that `value` may be zero.
 70     */
 71    event Transfer(address indexed from, address indexed to, uint256 value);
 72
 73    /**
 74     * @dev Emitted when the allowance of a `spender` for an `owner` is set by
 75     * a call to `approve`. `value` is the new allowance.
 76     */
 77    event Approval(address indexed owner, address indexed spender, uint256 value);
 78}
 79
 80// File: openzeppelin-solidity/contracts/token/ERC20/ERC20.sol
 81
 82pragma solidity ^0.5.0;
 83
 84
 85
 86/**
 87 * @dev Implementation of the `IERC20` interface.
 88 *
 89 * This implementation is agnostic to the way tokens are created. This means
 90 * that a supply mechanism has to be added in a derived contract using `_mint`.
 91 * For a generic mechanism see `ERC20Mintable`.
 92 *
 93 * *For a detailed writeup see our guide [How to implement supply
 94 * mechanisms](https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226).*
 95 *
 96 * We have followed general OpenZeppelin guidelines: functions revert instead
 97 * of returning `false` on failure. This behavior is nonetheless conventional
 98 * and does not conflict with the expectations of ERC20 applications.
 99 *
100 * Additionally, an `Approval` event is emitted on calls to `transferFrom`.
101 * This allows applications to reconstruct the allowance for all accounts just
102 * by listening to said events. Other implementations of the EIP may not emit
103 * these events, as it isn't required by the specification.
104 *
105 * Finally, the non-standard `decreaseAllowance` and `increaseAllowance`
106 * functions have been added to mitigate the well-known issues around setting
107 * allowances. See `IERC20.approve`.
108 */
109contract ERC20 is IERC20 {
110    using SafeMath for uint256;
111
112    mapping (address => uint256) private _balances;
113
114    mapping (address => mapping (address => uint256)) private _allowances;
115
116    uint256 private _totalSupply;
117
118    /**
119     * @dev See `IERC20.totalSupply`.
120     */
121    function totalSupply() public view returns (uint256) {
122        return _totalSupply;
123    }
124
125    /**
126     * @dev See `IERC20.balanceOf`.
127     */
128    function balanceOf(address account) public view returns (uint256) {
129        return _balances[account];
130    }
131
132    /**
133     * @dev See `IERC20.transfer`.
134     *
135     * Requirements:
136     *
137     * - `recipient` cannot be the zero address.
138     * - the caller must have a balance of at least `amount`.
139     */
140    function transfer(address recipient, uint256 amount) public returns (bool) {
141        _transfer(msg.sender, recipient, amount);
142        return true;
143    }
144
145    /**
146     * @dev See `IERC20.allowance`.
147     */
148    function allowance(address owner, address spender) public view returns (uint256) {
149        return _allowances[owner][spender];
150    }
151
152    /**
153     * @dev See `IERC20.approve`.
154     *
155     * Requirements:
156     *
157     * - `spender` cannot be the zero address.
158     */
159    function approve(address spender, uint256 value) public returns (bool) {
160        _approve(msg.sender, spender, value);
161        return true;
162    }
163
164    /**
165     * @dev See `IERC20.transferFrom`.
166     *
167     * Emits an `Approval` event indicating the updated allowance. This is not
168     * required by the EIP. See the note at the beginning of `ERC20`;
169     *
170     * Requirements:
171     * - `sender` and `recipient` cannot be the zero address.
172     * - `sender` must have a balance of at least `value`.
173     * - the caller must have allowance for `sender`'s tokens of at least
174     * `amount`.
175     */
176    function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) {
177        _transfer(sender, recipient, amount);
178        _approve(sender, msg.sender, _allowances[sender][msg.sender].sub(amount));
179        return true;
180    }
181
182    /**
183     * @dev Atomically increases the allowance granted to `spender` by the caller.
184     *
185     * This is an alternative to `approve` that can be used as a mitigation for
186     * problems described in `IERC20.approve`.
187     *
188     * Emits an `Approval` event indicating the updated allowance.
189     *
190     * Requirements:
191     *
192     * - `spender` cannot be the zero address.
193     */
194    function increaseAllowance(address spender, uint256 addedValue) public returns (bool) {
195        _approve(msg.sender, spender, _allowances[msg.sender][spender].add(addedValue));
196        return true;
197    }
198
199    /**
200     * @dev Atomically decreases the allowance granted to `spender` by the caller.
201     *
202     * This is an alternative to `approve` that can be used as a mitigation for
203     * problems described in `IERC20.approve`.
204     *
205     * Emits an `Approval` event indicating the updated allowance.
206     *
207     * Requirements:
208     *
209     * - `spender` cannot be the zero address.
210     * - `spender` must have allowance for the caller of at least
211     * `subtractedValue`.
212     */
213    function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) {
214        _approve(msg.sender, spender, _allowances[msg.sender][spender].sub(subtractedValue));
215        return true;
216    }
217
218    /**
219     * @dev Moves tokens `amount` from `sender` to `recipient`.
220     *
221     * This is internal function is equivalent to `transfer`, and can be used to
222     * e.g. implement automatic token fees, slashing mechanisms, etc.
223     *
224     * Emits a `Transfer` event.
225     *
226     * Requirements:
227     *
228     * - `sender` cannot be the zero address.
229     * - `recipient` cannot be the zero address.
230     * - `sender` must have a balance of at least `amount`.
231     */
232    function _transfer(address sender, address recipient, uint256 amount) internal {
233        require(sender != address(0), "ERC20: transfer from the zero address");
234        require(recipient != address(0), "ERC20: transfer to the zero address");
235
236        _balances[sender] = _balances[sender].sub(amount);
237        _balances[recipient] = _balances[recipient].add(amount);
238        emit Transfer(sender, recipient, amount);
239    }
240
241    /** @dev Creates `amount` tokens and assigns them to `account`, increasing
242     * the total supply.
243     *
244     * Emits a `Transfer` event with `from` set to the zero address.
245     *
246     * Requirements
247     *
248     * - `to` cannot be the zero address.
249     */
250    function _mint(address account, uint256 amount) internal {
251        require(account != address(0), "ERC20: mint to the zero address");
252
253        _totalSupply = _totalSupply.add(amount);
254        _balances[account] = _balances[account].add(amount);
255        emit Transfer(address(0), account, amount);
256    }
257
258     /**
259     * @dev Destoys `amount` tokens from `account`, reducing the
260     * total supply.
261     *
262     * Emits a `Transfer` event with `to` set to the zero address.
263     *
264     * Requirements
265     *
266     * - `account` cannot be the zero address.
267     * - `account` must have at least `amount` tokens.
268     */
269    function _burn(address account, uint256 value) internal {
270        require(account != address(0), "ERC20: burn from the zero address");
271
272        _totalSupply = _totalSupply.sub(value);
273        _balances[account] = _balances[account].sub(value);
274        emit Transfer(account, address(0), value);
275    }
276
277    /**
278     * @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens.
279     *
280     * This is internal function is equivalent to `approve`, and can be used to
281     * e.g. set automatic allowances for certain subsystems, etc.
282     *
283     * Emits an `Approval` event.
284     *
285     * Requirements:
286     *
287     * - `owner` cannot be the zero address.
288     * - `spender` cannot be the zero address.
289     */
290    function _approve(address owner, address spender, uint256 value) internal {
291        require(owner != address(0), "ERC20: approve from the zero address");
292        require(spender != address(0), "ERC20: approve to the zero address");
293
294        _allowances[owner][spender] = value;
295        emit Approval(owner, spender, value);
296    }
297
298    /**
299     * @dev Destoys `amount` tokens from `account`.`amount` is then deducted
300     * from the caller's allowance.
301     *
302     * See `_burn` and `_approve`.
303     */
304    function _burnFrom(address account, uint256 amount) internal {
305        _burn(account, amount);
306        _approve(account, msg.sender, _allowances[account][msg.sender].sub(amount));
307    }
308}