Panaroma Token

CertiKFiles named in the report

CertiK reviewed Panaroma (Panaroma Token) on 18 Sep 2023: 15 findings, 0 critical; 8 marked fixed, 7 open.

No open critical findings
Open the reportOpen Panaroma’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings15

Statuses are the security firm’s own, from its report.

SeverityOpenAcknowledgedFixed
Critical000
High100
Medium100
Low508
HighCentralization Risks in PanaromaToken.solOpen

In the `Panaroma Token` project, the privileged role `owner` is adopted to ensure the dynamic runtime updates and management of the project. ### Owner #### BurnContract In the contract `BurnContract` the role `owner` has authority over the functions shown in the list below: * `withdrawTokens()` - Transfers all specified tokens to the owner address * `withdraw()` - Transfers all native tokens (ie. ETH) to the owner address Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and to withdraw tokens. #### BlackList In the contract `BlackList` the role `owner` has authority over the functions shown in the list below: * `destroyBlackFunds()` - Burn blacklisted funds * `removeBlackList()` - Remove address from blacklist * `addBlackList()` - Add address to blacklist Any compromise to the `owner` account may allow the hacker to take advantage of this authority to manage the blacklist and control blacklisted funds. #### Ownable In the contract `Ownable` the role `owner` has authority over the functions shown in the list below: * `transferOwnership()` - Transfer ownership to another address Any compromise to the `owner` account may allow the hacker to take advantage of this authority to transfer ownership. #### PanaromaToken In the contract `PanaromaToken` the role `owner` has authority over the functions shown in the list below: * `mintTo()` - Mint tokens to a specified address * `mint()` - Mint tokens to caller of function * `setParams()` - Set basis points and maximum fee * `addTeamMember()` - Add an address to Team array * `setburnAddress()` - Set address to burn tokens to * `deprecate()` - Mark token address as obsolete * `burnFrom()` - Burn tokens contained in a specific address * `addInvestors()` - Add an address to Investor array * `addAdvisors()` - Add an address to Advisor array * `addFounders()` - Add an address to Founder array Any compromise to the `owner` account may allow the hacker to take advantage of this authority to mint/burn tokens, set various crucial state variables, and also collect fees. #### Pausable In the contract `Pausable` the role `owner` has authority over the functions shown in the list below: * `pause()` - Pause certain contract functionality * `unpause()` - Unpause certain contract functionality Any compromise to the `owner` account may allow the hacker to take advantage of this authority to pause and unpause contracts. --- ### Update 09/19/2023 The client confirmed that the contract `BurnContract.sol` was removed from the scope of the audit. Therefore, all centralization risks related to the contract `BurnContract.sol` are no longer valid.

MediumUsage of Deprecated token contractOpen

Users will still be allowed to create allowances and make transfers using deprecated contracts. Based on the current implementation, when a contract is deprecated, the new address will be entered using the following function `deprecate()`: ```solidity function deprecate(address _upgradedAddress) public onlyOwner { deprecated = true; upgradedAddress = _upgradedAddress; Deprecate(_upgradedAddress); } ``` Once a contract is deprecated, the `approve()` function will continue to allow users to create approvals using the deprecated token contract through the use of the `approveByLegacy()` function: ```solidity function approve(address _spender, uint _value) public onlyPayloadSize(2 * 32) { if (deprecated) { return UpgradedStandardToken(upgradedAddress).approveByLegacy(msg.sender, _spender, _value); } else { return super.approve(_spender, _value); } } ``` It is important to note that the `approveByLegacy()` function still is not implemented so there should be a compiler error. However, assuming that the implementation will allow users to create approvals using legacy token contracts, users will be able to make new approvals even after the contract has been deprecated. The following are the `transfer()` and `transferFrom()` functions: transfer(): ```solidity function transfer(address to, uint256 value) public returns (bool) { bool result = super.__transfer(to, value); uint256 transferFee; ... ``` transferFrom(): ```solidity function transferFrom(address from, address to, uint value) public whenNotPaused { require(!isBlackListed[from]); super.transferFrom(from, to, value); uint256 transferFee; ``` In both the `transfer()` and `transferFrom()` functions, there is nothing preventing transfers from being made even when the contract is deprecated.

LowIncorrect ERC-20 InterfaceOpen

The contract interface defined as ERC20Basic has a missing `transfer` function. Current implementation should include the definition of: ```solidity function transfer(address to, uint value) public; ```

LowMissing Emit EventsOpen

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

LowMissing Error MessagesOpen

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

LowNot Recommended and Unlocked Compiler VersionOpen

The contracts use older Solidity versions such as `0.4.17` and `0.6.6`. Solidity frequently releases new compiler versions. Using an older version can prevent access to Solidity's new security features. Also, the latest version may be too early to be trusted. The contracts also use unlocked compiler versions. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to different compiler versions. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

LowState Variable Should Be Declared ConstantOpen

State variables that never change should be declared as `constant` to save gas. --- ```solidity=350 uint256 private stageOne = 10; // 0.001 % if feeDenominator = 10000 ``` - `stageOne` should be declared `constant`. --- ```solidity=351 uint256 private stageTwo = 8; // 0.001 % if feeDenominator = 10000 ``` - `stageTwo` should be declared `constant`. --- ```solidity=352 uint256 private stageThree = 5; ``` - `stageThree` should be declared `constant`. --- ```solidity=353 uint256 private stageFour = 2; ``` - `stageFour` should be declared `constant`. --- ```solidity=354 uint256 private feeDenominator = 1000; ``` - `feeDenominator` should be declared `constant`.

Contracts in scope

No deployed address is recorded for this audit.

The report names a repository or files. Open the report to see its scope.

Repository and files the report names (4)

  • BurnContract.sol
  • PanaromaToken.sol
  • SafeMath.sol
  • TransferHelper.sol

Part of Panaroma’s security record

Panaroma
Audits1 audit by 1 firmLast audit Sep 2023, by CertiK.
Critical findingsNo open critical findingsIn 1 report.
Open Panaroma’s security record

Security firm

CertiK

1,044 projects reviewed · 1,375 reports · latest May 2025

See CertiK’s audits

Something 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