Comment on page

Security & Bounties

An overview of Shell's security


Security Statement

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.

Ocean Safeguards

In the future, the Shell DAO (not yet launched) will be able to transfer protocol revenue between wallets or change the protocol beneficiary wallet, as well as adjust Ocean unwrap fees.
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).

Proteus Pool Safeguards

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: Uninitialized, Pending, Queued, Executed, or Expired. 

For normal transactions, any owner on the multisig can submit a transaction by calling submitTransaction. This puts the transaction into the Pending state, 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 Pending state. Once the required number of confirmations is reached, any owner can move the transaction into the Queued state 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 Executed state. 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 Expired state 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 freezePool function 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 submitUnfreezePool function and pass in the pool address. At this point, the unfreeze transaction is in the Pending state 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 executeTransaction since 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.


Shell has a bug bounty program on Immunefi. Please submit bugs there.

On-Chain Monitoring

Shell conducts on-chain security monitoring with Forta. Anyone can subscribe to updates from the Shell Forta bot.
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.


Legacy Audits (Shell v1)