Comment on page
Security & Bounties
An overview of Shell's security
The Shell Protocol team holds security as a top priority. Shell contracts are non-custodial, meaning NOBODY (not even the core team or the Shell DAO) is able to access the funds held in any of the core contracts. DeFi can be inherently risky and time is the ultimate test, so all new features are released with utmost care, communication, and appropriate incentives for users.
There are some safeguards in place to actively monitor security threats and to address unforeseen situations.
However, NOBODY can manipulate or confiscate user assets (Shell is 100% non-custodial), freeze the protocol (users can always withdraw their assets at any time), or block new primitives from joining (anyone can build and deploy on Shell).
A pool's deployer can assign a wallet the ability to freeze the pool in case of an emergency. LPs may still withdraw their tokens, but swaps and deposits are disabled.
The Shell core team controls a 2/3 multi-signature wallet, the ShellMultiSig, that can freeze trading on Proteus pools assigned to it.
A transaction submitted through the multisig can be in one of the following states:
For normal transactions, any owner on the multisig can submit a transaction by calling
submitTransaction. This puts the transaction into the
Pendingstate, at which point it must be confirmed by two of three of the multisig owners. Owners can also revoke their confirmation by calling
revokeConfirmation, but only while the transaction is in the
Pendingstate. Once the required number of confirmations is reached, any owner can move the transaction into the
Queuedstate by calling
queueTransaction. At this point, the time lock countdown of two days begins. Once the time lock period has passed, any owner can execute the transaction by calling
executeTransaction, moving it into the
Executedstate. Note that the transaction must be executed within a given grace period of three hours from when the time lock expires. If the transaction has not been executed by the end of this grace period, it will enter the
Expiredstate and the entire process must be repeated by submitting a new transaction. There are two special cases of transactions, freezing and unfreezing a pool.
To freeze a pool, any owner on the multisig can call the
freezePoolfunction and pass in the pool address. The pool will be frozen immediately following this transaction, no confirmations or transactions from other owners are required.
To unfreeze a pool, any owner on the multisig can call the
submitUnfreezePoolfunction and pass in the pool address. At this point, the unfreeze transaction is in the
Pendingstate and requires two of three confirmations from multisig owners. Once the required number of confirmations is reached, the unfreeze transaction can be immediately executed by any owner by calling
executeTransactionsince there is no time lock delay for unfreezing a pool. Note that the one contingency in this case is that the grace period begins as soon as the transaction is initially submitted, meaning the unfreeze transaction must be confirmed and executed within three hours of being initially submitted.
This bot tracks Shell transactions in which wrapping, unwrapping, swapping, depositing, or withdrawals occur over a threshold amount. If transactions occur with unusually high token amounts, the bot sends out an alert.