Supra - Hypernova
Summary
Hypernova: This is the core contract of the protocol. This contract’s duty is to emit necessary data that is required for bridging the tokens. This contract contains only 2 external (non-view) functions postMessage(), upgradeImplementation(). None of the above mentioned functions can be called by end-users. postMessage() can only be called by tokenBridge contract and upgadeImplementation() can only be called by an Admin address which is stored in the contract at the time of initialization. Bridge base fee, admin address and token bridge contract address are stored in the contract at the time of initialization. RelayOperator: This contract is used by relayer to update the gas price of the destination chain (Supra) and token bridge contract fetches the latest gas price from here. Only 2 external (non-view) functions updateGasPrice(). upgradeImplementation(). None of the functions can be called by end-users. UpdateGasPrice() can only be called by relayer, whose address is stored at the time of initialization. (upgradeImplementation() same as in Hypernova) admin address, token bridge contract address and relayer address gets stored in the contract at the time of initialization. TokenBridge: This contract is used by the end users to bridge their tokens (only registered tokens) and native currency (eg. ETH) to Supra. Users’ tokens get locked in the token bridge contract and postMessage function of hypernova is called which emits an event with all the necessary data required by the destination contracts to complete the transaction. Before bridging, the token needs to be registered. Only admin / owner has the powers to register new token, pause/unpause the bridge and upgrade the implementation. For end-users, there are only 2 functions sendTokens() and sendNative(). First one for tokens and second one for native currency. Other external functions are for admin / owner. Token Vault & Vault Implementation: The contract implements a token vault system using an upgradeable proxy pattern. The TokenVault.sol serves as a proxy contract that inherits from OpenZeppelin's ERC1967Proxy, allowing for upgradeability of the vault's implementation. The main business logic resides in VaultImplementation.sol, which is a bridge-controlled token vault that can handle both ERC20 and native tokens (ETH).
Issues (20)
Low | Medium | High | Critical | Total | |
|---|---|---|---|---|---|
Not fixed | 3 | - | - | - | 3 |
Fixed | 15 | 2 | - | - | 17 |
| Total | 18 | 2 | 0 | 0 | 20 |