CertiK reviewed Pepe Community (Pepe Community - Audit) on 8 Sep 2023: 16 findings, 0 critical; 2 marked fixed, 2 acknowledged, 12 open.
Report hosted on skynet.certik.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 1 | 1 |
| Medium | 0 | 1 | 1 |
| Low | 12 | 0 | 0 |
All of the `PEPE` tokens are sent to the contract deployer address. This is a centralization risk because the deployer can distribute tokens without obtaining the consensus of the community. Any compromise to this address may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project. The detailed holder list can be found at: [https://etherscan.io/token/0xbe042e9d09cb588331ff911c2b46fd833a3e5bd6#balances](https://etherscan.io/token/0xbe042e9d09cb588331ff911c2b46fd833a3e5bd6#balances). As of 09/01/2023, the addresses of major holders are listed below: - 3.44% of the tokens are in the address [0x3cc936b795a188f0e246cbb2d74c5bd190aecf18](https://etherscan.io/address/0x3cc936b795a188f0e246cbb2d74c5bd190aecf18) - 2.78% of the tokens are in the address [0xcEFD289a028d1b0a2E3Cd618EDf5a5256a6328CE](https://etherscan.io/address/0xcEFD289a028d1b0a2E3Cd618EDf5a5256a6328CE) - 2.68% of the tokens are in the liquidity pool address [0x8616B44b734817a2C954016A57CF2c4D72D6f838](https://etherscan.io/address/0x8616B44b734817a2C954016A57CF2c4D72D6f838)
In function `_transfer()`, the use of `tx.origin` can be manipulated by an attacker, enabling them to bypass transfer delays or block transfers intended for other users. ```solidity=1146 if (transferDelayEnabled){ if (to != owner() && to != address(uniswapV2Router) && to != address(uniswapV2Pair)){ require(_holderLastTransferTimestamp[tx.origin] < block.number, "_transfer:: Transfer Delay enabled. Only one purchase per block allowed."); _holderLastTransferTimestamp[tx.origin] = block.number; } } ``` The transparency of `tx.origin` is limited within a contract. In a call chain scenario like A->B->C->D, where D is deep within the chain, `msg.sender` in D will represent C, while `tx.origin` will reflect A. If it is crucial to have the original sender's address in D, each function in contracts B, C, and D could incorporate an additional parameter to pass along the origin: A would provide its address (via this) to B, B would transmit the value to C, and C would pass it further to D. Using `tx.origin` for authorization purposes is not recommended in Solidity documentation because it can be exploited by a malicious contract if a legitimate user interacts with it. Therefore, caution should be exercised when relying on `tx.origin` for authorization, and alternative approaches should be considered. Refer to: https://docs.soliditylang.org/en/v0.7.0/security-considerations.html#tx-origin
| Address | Chain | Source code |
|---|---|---|
| 0xbe04…5bd60xbe042e9d09cb588331ff911c2b46fd833a3e5bd6 | Chain: Ethereum | Source code: Verified source |
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us