Kroma security record

In the contract `GovernanceToken`, the role `BRIDGE` and `_owner` have authority over the following function: - `mint` Any compromise to these accounts may allow the hacker to take advantage of this authority and mint tokens to a specified address. In the contract `GovernanceToken`, the role `BRIDGE` has authority over the following function: - `burn` Any compromise to the `BRIDGE` account may allow the hacker to take advantage of this authority and burn tokens from a specified address. In the contract `Ownable2StepUpgradeable`, the role `_owner` has authority over the following functions: - `transferOwnership` - `renounceOwnership` Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and transfer or renounce the ownership.

The contract `GovernanceToken` serves as the implementation contract behind its proxy contract, the role proxy admin has the authority to update the implementation contract. Any compromise to the proxy admin account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.

In the contract `CallOrder` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and function call with value, function multi-call with value, and function delegate call.  ----- In the contract `SelectorRoleControlUpgradeable` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and grant/revoke the selector role and pause/unpause the contract.  ----- In the contract `SlotOrder` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set/get the slot.  ----- In the contract `EcoProxyAdmin` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and upgrade the proxy to implementation and call a function on the new implementation.  ----- In the contract `ERC1155MintableUpgradeable` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and mint NFTs to any address.  ----- In the contract `EcoERC1155URIControl` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and set URI, base URI and initial URI.  ----- In the contract `ERC20L2BridgedUpgradeable` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and burn tokens from any address and mint tokens to any address.  ----- In the contract `ERC20MintableUpgradeable` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and mint tokens to any address.  ----- In the contract `ERC721SequencialMintUpbradeable` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and mint NFTs to any address  ----- In the contract `ERC721TypedUpgradeable` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and set base URI, and token type. 

In the above contracts, the role `admin` has the authority to update the implementation contract behind the proxy contract. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.

In the contract `CallOrder` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and function call with value, function multi-call with value, and function delegate call.  ----- In the contract `SelectorRoleControlUpgradeable` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and grant/revoke the selector role and pause/unpause the contract.  ----- In the contract `SlotOrder` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set/get the slot.  ----- In the contract `EcoProxyAdmin` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and upgrade the proxy to implementation and call a function on the new implementation.  ----- In the contract `ERC20L2BridgedUpgradeable` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and burn tokens from any address and mint tokens to any address.  ----- In the contract `ERC20MintableUpgradeable` the role `_admin` has authority over the functions shown in the diagram below. Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and mint tokens to any address.  In the contract `SpectrumCoreState` the role `_admin` has authority over the functions - setCoreInfo() - setDeXInfo() - setIndexToken() - setIndexEvalRate() Any compromise to the `_admin` account may allow the hacker to take advantage of this authority and set core information( bridge address, fee address, fund underlying address, etc), set DEX information( weth address, router address, and path), set index token information and set index token's eval rate.

In the contract `SpectrumCore`, `SpectrumETH`, `L2SpectrumETH`,`SelectorRoleControlUpgradeable`, `EcoProxyAdmin`, `WrappingNativeCoin`, `EcoERC20Upgradeable` and `ERC20L2BridgedUpgradeable`, the role `admin` has the authority to update the implementation contract behind the proxy contract. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.

The contracts `GovernanceToken` inherit the following non-upgradeable contracts: 1. KromaMintableERC20 2. ERC20Votes 3. ERC20 There are no storage gaps preserved in these contracts. Any logic contract that acts as a base contract that needs to be inherited by other upgradeable children should have a reasonable size of storage gap preserved for the new state variable introduced by the future upgrades.

When updating upgradeable smart contracts for new features or bug fixes, it's essential to keep the state variables' declaration order unchanged to avoid storage layout issues. A practical solution is to include unused state variables or explicitly named storage gaps (like `__gap`) in the base contracts. This foresight allows reserved slots for future use, ensuring that any additions to the contract's state won't disrupt the storage pattern of derived contracts or the compatibility with previously deployed versions. The problem of "Lack of Storage Gap in Upgradeable Contract" occurs when these storage gaps are not incorporated into the base contract's logic. As a result, if new state variables are added to the base contract, they might overwrite existing variables in the child contracts due to storage slot collisions. For detailed guidelines and best practices, refer to the following OpenZeppelin documentation: - https://docs.openzeppelin.com/contracts/4.x/upgradeable#storage_gaps - https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable#storage-gaps

The contract serves as the underlying entity to interact with one or more third-party protocols. The scope of the audit treats third-party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=7 import { IKromaBridge } from "../../eco-libs/kroma/interfaces.sol"; ``` - The contract `SpectrumCoreLogic` interacts with third-party contract with `IKromaBridge` interface via `memSnap.info.bridge`. ```solidity=17 interface IidxAssetWrapper ``` - The contract `SpectrumCoreLogic` interacts with third-party contract with `IidxAssetWrapper` interface via `idxAsset`. ```solidity=221 idxAmount = IstETH(payable(requestedAsset)).submit{ value: amount }(address(0)); ``` - The contract `SpectrumCoreLogic` interacts with third-party contract with `IstETH` interface via `requestedAsset`. ```solidity=113 ethAmount = IEcoUniswapV3Router(memDex.router).exactInput( ``` - The contract `SpectrumCoreEntry` interacts with third-party contract with `IEcoUniswapV3Router` interface via `memDex.router`.