Panaroma security record

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.

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.

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; ```

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

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.

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.

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`.