Shibarium
Badges
About
Shibarium is an EVM-compatible, proof of stake sidechain for Ethereum. It is built by developers behind the Shiba Inu token ecosystem. The main bridge to Ethereum is currently validated by Shibarium validators and allows for asset as well as data movement... between Shibarium and Ethereum.
Badges
About
Shibarium is an EVM-compatible, proof of stake sidechain for Ethereum. It is built by developers behind the Shiba Inu token ecosystem. The main bridge to Ethereum is currently validated by Shibarium validators and allows for asset as well as data movement... between Shibarium and Ethereum.
Why is the project listed in others?
Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.
Consequence: projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds.
Learn more about the recategorisation here.
2024 May 09 — 2025 May 09
Funds can be stolen if
- a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL),
- validators decide to mint more tokens than there are locked on Ethereum thus preventing some existing holders from being able to bring their funds back to Ethereum,
- validators submit a fraudulent checkpoint allowing themselves to withdraw all locked funds.
Users can be censored if
Users can submit transactions to an L1 queue, but can’t force them. The sequencers cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencers censor or are down, they are so for everyone.
Currently the system permits invalid state roots. More details in project overview.
Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 9/12 that is tasked with protecting and supplying the data.
There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
As a fork of Polygon PoS, state updates are settled if signed by at least 2/3+1 of the Shibarium validators stake, without checking whether the state transition is valid. The validator set is gated by a whitelist, which is not public.
Users can be censored if validators on Shibarium decide to not mint tokens after observing an event on Ethereum.
Funds can be stolen if validators decide to mint more tokens than there are locked on Ethereum thus preventing some existing holders from being able to bring their funds back to Ethereum.
Funds can be stolen if validators submit a fraudulent checkpoint allowing themselves to withdraw all locked funds.
Ethereum
Actors:
- Is allowed to interact with StakeManagerExtension - can update the validator registry address used to check whitelist inclusion.
- Is allowed to interact with ValidatorRegistry - can update the whitelist of validators.
- Is allowed to interact with StakeManager - can replace all validators.
- Is allowed to interact with DepositManager - can update the root chain it references.
- Is allowed to interact with SlashingManager - can update how much of the slashed funds go to the proposer and reporter.
- Is allowed to interact with RootChain - can delete arbitrary checkpoints.
- Can upgrade the implementation of ERC1155Predicate, MintableERC721Predicate, RootChainManager, EventsHub, StakeManager, ERC20Predicate, ERC721Predicate, EtherPredicate.
Ethereum
Smart contract allowing whitelisted addresses to send messages to contracts on the child chain.
Defines the whitelist of validators that can stake and therefore participate in the PoS consensus protocol.
Contract handling users’ withdrawal finalization for tokens escrowed in DepositManager.
Simple contract that allows the owner to call an update function on arbitrary contracts.
Contract storing chain checkpoints. Note that validity of these checkpoints is not verified, it is assumed to be valid if signed by 2/3 of the validators.
Main configuration contract to manage tokens, token types, escrows (predicates) for given token types. It also serves as an entry point for deposits and withdrawals effectively acting as a token router.
Contains logging and getter functions about staking.
This contract can store any token.
NFTs used to represent a withdrawal in the withdrawal PriorityQueue (Only used for tokens initially deposited via DepositManager).
Contract to deposit and escrow ETH, ERC20 or ERC721 tokens. This contract can store any token.
Contract that allows the consensus supermajority to slash validators.
This contract stores the following tokens: ETH.
Maintains the addresses of the contracts used in the system.
Value Secured is calculated based on these smart contracts and tokens:
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).