Door Token
Search…
Smart Contract Audit

DOOR Smart Contract Audit

In order to ensure we followed best practices and were not vulnerable to attacks, we hired an independent 3rd party to audit our Smart Contract code.
You can download and view the results of the audit here: https://doortoken.org//download/dooraudit.pdf
DOOR Smart Contract Code is here.

We used OpenZeppelin to generate our contract.

Here is a copy of the code that was audited
1
/**
2
*Submitted for verification at Etherscan.io on 2021-06-28
3
*/
4
5
// File: node_modules\@openzeppelin\contracts\token\ERC20\IERC20.sol
6
7
// SPDX-License-Identifier: MIT
8
9
pragma solidity ^0.8.0;
10
11
/**
12
* @dev Interface of the ERC20 standard as defined in the EIP.
13
*/
14
interface IERC20 {
15
/**
16
* @dev Returns the amount of tokens in existence.
17
*/
18
function totalSupply() external view returns (uint256);
19
20
/**
21
* @dev Returns the amount of tokens owned by `account`.
22
*/
23
function balanceOf(address account) external view returns (uint256);
24
25
/**
26
* @dev Moves `amount` tokens from the caller's account to `recipient`.
27
*
28
* Returns a boolean value indicating whether the operation succeeded.
29
*
30
* Emits a {Transfer} event.
31
*/
32
function transfer(address recipient, uint256 amount) external returns (bool);
33
34
/**
35
* @dev Returns the remaining number of tokens that `spender` will be
36
* allowed to spend on behalf of `owner` through {transferFrom}. This is
37
* zero by default.
38
*
39
* This value changes when {approve} or {transferFrom} are called.
40
*/
41
function allowance(address owner, address spender) external view returns (uint256);
42
43
/**
44
* @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
45
*
46
* Returns a boolean value indicating whether the operation succeeded.
47
*
48
* IMPORTANT: Beware that changing an allowance with this method brings the risk
49
* that someone may use both the old and the new allowance by unfortunate
50
* transaction ordering. One possible solution to mitigate this race
51
* condition is to first reduce the spender's allowance to 0 and set the
52
* desired value afterwards:
53
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
54
*
55
* Emits an {Approval} event.
56
*/
57
function approve(address spender, uint256 amount) external returns (bool);
58
59
/**
60
* @dev Moves `amount` tokens from `sender` to `recipient` using the
61
* allowance mechanism. `amount` is then deducted from the caller's
62
* allowance.
63
*
64
* Returns a boolean value indicating whether the operation succeeded.
65
*
66
* Emits a {Transfer} event.
67
*/
68
function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
69
70
/**
71
* @dev Emitted when `value` tokens are moved from one account (`from`) to
72
* another (`to`).
73
*
74
* Note that `value` may be zero.
75
*/
76
event Transfer(address indexed from, address indexed to, uint256 value);
77
78
/**
79
* @dev Emitted when the allowance of a `spender` for an `owner` is set by
80
* a call to {approve}. `value` is the new allowance.
81
*/
82
event Approval(address indexed owner, address indexed spender, uint256 value);
83
}
84
85
/**
86
* @dev Interface for the optional metadata functions from the ERC20 standard.
87
*
88
* _Available since v4.1._
89
*/
90
interface IERC20Metadata is IERC20 {
91
/**
92
* @dev Returns the name of the token.
93
*/
94
function name() external view returns (string memory);
95
96
/**
97
* @dev Returns the symbol of the token.
98
*/
99
function symbol() external view returns (string memory);
100
101
/**
102
* @dev Returns the decimals places of the token.
103
*/
104
function decimals() external view returns (uint8);
105
}
106
107
/*
108
* @dev Provides information about the current execution context, including the
109
* sender of the transaction and its data. While these are generally available
110
* via msg.sender and msg.data, they should not be accessed in such a direct
111
* manner, since when dealing with meta-transactions the account sending and
112
* paying for execution may not be the actual sender (as far as an application
113
* is concerned).
114
*
115
* This contract is only required for intermediate, library-like contracts.
116
*/
117
abstract contract Context {
118
function _msgSender() internal view virtual returns (address) {
119
return msg.sender;
120
}
121
122
function _msgData() internal view virtual returns (bytes calldata) {
123
this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691
124
return msg.data;
125
}
126
}
127
128
129
/**
130
* @dev Implementation of the {IERC20} interface.
131
*
132
* This implementation is agnostic to the way tokens are created. This means
133
* that a supply mechanism has to be added in a derived contract using {_mint}.
134
* For a generic mechanism see {ERC20PresetMinterPauser}.
135
*
136
* TIP: For a detailed writeup see our guide
137
* https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
138
* to implement supply mechanisms].
139
*
140
* We have followed general OpenZeppelin guidelines: functions revert instead
141
* of returning `false` on failure. This behavior is nonetheless conventional
142
* and does not conflict with the expectations of ERC20 applications.
143
*
144
* Additionally, an {Approval} event is emitted on calls to {transferFrom}.
145
* This allows applications to reconstruct the allowance for all accounts just
146
* by listening to said events. Other implementations of the EIP may not emit
147
* these events, as it isn't required by the specification.
148
*
149
* Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
150
* functions have been added to mitigate the well-known issues around setting
151
* allowances. See {IERC20-approve}.
152
*/
153
contract ERC20 is Context, IERC20, IERC20Metadata {
154
mapping (address => uint256) private _balances;
155
156
mapping (address => mapping (address => uint256)) private _allowances;
157
158
uint256 private _totalSupply;
159
160
string private _name;
161
string private _symbol;
162
163
/**
164
* @dev Sets the values for {name} and {symbol}.
165
*
166
* The defaut value of {decimals} is 18. To select a different value for
167
* {decimals} you should overload it.
168
*
169
* All two of these values are immutable: they can only be set once during
170
* construction.
171
*/
172
constructor (string memory name_, string memory symbol_) {
173
_name = name_;
174
_symbol = symbol_;
175
}
176
177
/**
178
* @dev Returns the name of the token.
179
*/
180
function name() public view virtual override returns (string memory) {
181
return _name;
182
}
183
184
/**
185
* @dev Returns the symbol of the token, usually a shorter version of the
186
* name.
187
*/
188
function symbol() public view virtual override returns (string memory) {
189
return _symbol;
190
}
191
192
/**
193
* @dev Returns the number of decimals used to get its user representation.
194
* For example, if `decimals` equals `2`, a balance of `505` tokens should
195
* be displayed to a user as `5,05` (`505 / 10 ** 2`).
196
*
197
* Tokens usually opt for a value of 18, imitating the relationship between
198
* Ether and Wei. This is the value {ERC20} uses, unless this function is
199
* overridden;
200
*
201
* NOTE: This information is only used for _display_ purposes: it in
202
* no way affects any of the arithmetic of the contract, including
203
* {IERC20-balanceOf} and {IERC20-transfer}.
204
*/
205
function decimals() public view virtual override returns (uint8) {
206
return 18;
207
}
208
209
/**
210
* @dev See {IERC20-totalSupply}.
211
*/
212
function totalSupply() public view virtual override returns (uint256) {
213
return _totalSupply;
214
}
215
216
/**
217
* @dev See {IERC20-balanceOf}.
218
*/
219
function balanceOf(address account) public view virtual override returns (uint256) {
220
return _balances[account];
221
}
222
223
/**
224
* @dev See {IERC20-transfer}.
225
*
226
* Requirements:
227
*
228
* - `recipient` cannot be the zero address.
229
* - the caller must have a balance of at least `amount`.
230
*/
231
function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
232
_transfer(_msgSender(), recipient, amount);
233
return true;
234
}
235
236
/**
237
* @dev See {IERC20-allowance}.
238
*/
239
function allowance(address owner, address spender) public view virtual override returns (uint256) {
240
return _allowances[owner][spender];
241
}
242
243
/**
244
* @dev See {IERC20-approve}.
245
*
246
* Requirements:
247
*
248
* - `spender` cannot be the zero address.
249
*/
250
function approve(address spender, uint256 amount) public virtual override returns (bool) {
251
_approve(_msgSender(), spender, amount);
252
return true;
253
}
254
255
/**
256
* @dev See {IERC20-transferFrom}.
257
*
258
* Emits an {Approval} event indicating the updated allowance. This is not
259
* required by the EIP. See the note at the beginning of {ERC20}.
260
*
261
* Requirements:
262
*
263
* - `sender` and `recipient` cannot be the zero address.
264
* - `sender` must have a balance of at least `amount`.
265
* - the caller must have allowance for ``sender``'s tokens of at least
266
* `amount`.
267
*/
268
function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
269
_transfer(sender, recipient, amount);
270
271
uint256 currentAllowance = _allowances[sender][_msgSender()];
272
require(currentAllowance >= amount, "ERC20: transfer amount exceeds allowance");
273
_approve(sender, _msgSender(), currentAllowance - amount);
274
275
return true;
276
}
277
278
/**
279
* @dev Atomically increases the allowance granted to `spender` by the caller.
280
*
281
* This is an alternative to {approve} that can be used as a mitigation for
282
* problems described in {IERC20-approve}.
283
*
284
* Emits an {Approval} event indicating the updated allowance.
285
*
286
* Requirements:
287
*
288
* - `spender` cannot be the zero address.
289
*/
290
function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
291
_approve(_msgSender(), spender, _allowances[_msgSender()][spender] + addedValue);
292
return true;
293
}
294
295
/**
296
* @dev Atomically decreases the allowance granted to `spender` by the caller.
297
*
298
* This is an alternative to {approve} that can be used as a mitigation for
299
* problems described in {IERC20-approve}.
300
*
301
* Emits an {Approval} event indicating the updated allowance.
302
*
303
* Requirements:
304
*
305
* - `spender` cannot be the zero address.
306
* - `spender` must have allowance for the caller of at least
307
* `subtractedValue`.
308
*/
309
function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
310
uint256 currentAllowance = _allowances[_msgSender()][spender];
311
require(currentAllowance >= subtractedValue, "ERC20: decreased allowance below zero");
312
_approve(_msgSender(), spender, currentAllowance - subtractedValue);
313
314
return true;
315
}
316
317
/**
318
* @dev Moves tokens `amount` from `sender` to `recipient`.
319
*
320
* This is internal function is equivalent to {transfer}, and can be used to
321
* e.g. implement automatic token fees, slashing mechanisms, etc.
322
*
323
* Emits a {Transfer} event.
324
*
325
* Requirements:
326
*
327
* - `sender` cannot be the zero address.
328
* - `recipient` cannot be the zero address.
329
* - `sender` must have a balance of at least `amount`.
330
*/
331
function _transfer(address sender, address recipient, uint256 amount) internal virtual {
332
require(sender != address(0), "ERC20: transfer from the zero address");
333
require(recipient != address(0), "ERC20: transfer to the zero address");
334
335
_beforeTokenTransfer(sender, recipient, amount);
336
337
uint256 senderBalance = _balances[sender];
338
require(senderBalance >= amount, "ERC20: transfer amount exceeds balance");
339
_balances[sender] = senderBalance - amount;
340
_balances[recipient] += amount;
341
342
emit Transfer(sender, recipient, amount);
343
}
344
345
/** @dev Creates `amount` tokens and assigns them to `account`, increasing
346
* the total supply.
347
*
348
* Emits a {Transfer} event with `from` set to the zero address.
349
*
350
* Requirements:
351
*
352
* - `to` cannot be the zero address.
353
*/
354
function _mint(address account, uint256 amount) internal virtual {
355
require(account != address(0), "ERC20: mint to the zero address");
356
357
_beforeTokenTransfer(address(0), account, amount);
358
359
_totalSupply += amount;
360
_balances[account] += amount;
361
emit Transfer(address(0), account, amount);
362
}
363
364
/**
365
* @dev Destroys `amount` tokens from `account`, reducing the
366
* total supply.
367
*
368
* Emits a {Transfer} event with `to` set to the zero address.
369
*
370
* Requirements:
371
*
372
* - `account` cannot be the zero address.
373
* - `account` must have at least `amount` tokens.
374
*/
375
function _burn(address account, uint256 amount) internal virtual {
376
require(account != address(0), "ERC20: burn from the zero address");
377
378
_beforeTokenTransfer(account, address(0), amount);
379
380
uint256 accountBalance = _balances[account];
381
require(accountBalance >= amount, "ERC20: burn amount exceeds balance");
382
_balances[account] = accountBalance - amount;
383
_totalSupply -= amount;
384
385
emit Transfer(account, address(0), amount);
386
}
387
388
/**
389
* @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens.
390
*
391
* This internal function is equivalent to `approve`, and can be used to
392
* e.g. set automatic allowances for certain subsystems, etc.
393
*
394
* Emits an {Approval} event.
395
*
396
* Requirements:
397
*
398
* - `owner` cannot be the zero address.
399
* - `spender` cannot be the zero address.
400
*/
401
function _approve(address owner, address spender, uint256 amount) internal virtual {
402
require(owner != address(0), "ERC20: approve from the zero address");
403
require(spender != address(0), "ERC20: approve to the zero address");
404
405
_allowances[owner][spender] = amount;
406
emit Approval(owner, spender, amount);
407
}
408
409
/**
410
* @dev Hook that is called before any transfer of tokens. This includes
411
* minting and burning.
412
*
413
* Calling conditions:
414
*
415
* - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
416
* will be to transferred to `to`.
417
* - when `from` is zero, `amount` tokens will be minted for `to`.
418
* - when `to` is zero, `amount` of ``from``'s tokens will be burned.
419
* - `from` and `to` are never both zero.
420
*
421
* To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
422
*/
423
function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
424
}
425
426
contract DOOR is ERC20 {
427
constructor() ERC20("DOOR", "DOOR") {
428
uint256 initialSupply = 4000000000 * (10 ** 18);
429
_mint(msg.sender, initialSupply);
430
}
431
}
Copied!
Last modified 3mo ago