Symbiotic is a shared security protocol enabling decentralized networks to control and customize their own multi-asset restaking implementation.

Symbiotic core consists of:

• Collateral: a new type of asset that allows stakeholders to hold onto their funds and earn yield from them without needing to lock these funds in a direct manner or convert them to another type of asset.
• Vaults: the delegation and restaking management layer of Symbiotic that handles three crucial parts of the Symbiotic economy: accounting, delegation strategies, and reward distribution.
• Operators: entities running infrastructure for decentralized networks within and outside of the Symbiotic ecosystem.
• Resolvers: contracts or entities that are able to veto slashing incidents forwarded from networks and can be shared across networks.
• Networks: any protocols that require a decentralized infrastructure network to deliver a service in the crypto economy, e.g., enabling developers to launch decentralized applications by taking care of validating and ordering transactions, providing off-chain data to applications in the crypto economy, or providing users with guarantees about cross-network interactions, etc.

Prize distribution and scoring

• Total Prize Pool: $120,000

• Primary Prize Pool: $112,500

• The prize distribution has 2 possible triggers:

  • If one or more valid medium severity findings are found, the total pot size is $50,000
  • If one or more valid high severity findings are found, the total pot size is $120,000

• $7,500 of the prize pot is reserved for Low Severity findings. These reports are judged based on quality and reviewers are then ranked from 1st to 5th for the purpose of prize allocation.

  • 1st: $3k
  • 2nd: $2k
  • 3rd: $1k
  • 4th: $750
  • 5th: $750

• Scoring described in the competition scoring page.

• Findings Severities described in detail on our docs page.

Documentation

• https://docs.symbiotic.fi/
• Technical Documentation

Scope

• symbiotic-fi/core
• commit: 1246641ae4b7bc4064fff7bf216589fefaa6a09c
• nSLOC: 1970

Contracts

Smart contract
NetworkRegistry.sol
SlasherFactory.sol
VaultConfigurator.sol
OperatorRegistry.sol
DelegatorFactory.sol
VaultFactory.sol
service/MetadataService.sol
service/NetworkMiddlewareService.sol
service/OptInService.sol
libraries/Checkpoints.sol
libraries/ERC4626Math.sol
libraries/Subnetwork.sol
common/StaticDelegateCallable.sol
common/MigratableEntityProxy.sol
common/Registry.sol
common/MigratablesFactory.sol
common/Factory.sol
common/MigratableEntity.sol
common/Entity.sol
vault/VaultStorage.sol
vault/Vault.sol
slasher/Slasher.sol
slasher/BaseSlasher.sol
slasher/VetoSlasher.sol
delegator/BaseDelegator.sol
delegator/FullRestakeDelegator.sol
delegator/NetworkRestakeDelegator.sol

Build Instructions

• forge build
• forge test \--isolate

• Basic POC test

Out of scope

1. “Factory and MigratablesFactory allow the owner of the contract to whitelist implementations of which users can then deploy clones. If one of these whitelisted implementations turns out to be vulnerable later on, there is no way to remove them, allowing users to deploy vulnerable contracts. Since the factories are immutable, such problems can only be mitigated by re-deploying and re-configuring them after project launch.” - we implemented a view function `blacklisted()` to identify such implementations on-chain, but we don’t restrict deploying them and migrating through them
2. “Vaults experiencing multiple full slashes could become unusable. As slashes are only adjusting stakes but not shares, the share computation on deposits can lead to inflated share decimals when deposits happen after slashes due to the following calculation: assets.mulDiv(totalShares + 10 ** _decimalsOffset(), totalAssets + 1, rounding); After a full slash, newly deposited assets are simply multiplied with the amount of existing shares. After multiple such repetitions, the share amount becomes larger than 256 bits. However, we consider this unproblematic as vaults that have been slashed fully once or even twice likely will not attract new deposits anyways.” - we assume that in case of a full slash, the vault won’t receive new funds, or the owner may recreate the vault (as there is no problem with a migration of the funds)
3. Factory and MigratablesFactory allow for the entities to be created uninitialized. We don’t allow the use of write functions until they are initialized. However, improper integrations (if they don’t use a provided `isInitialzied()` function to check the status) may still suffer because of such behavior.
4. Factory and MigratablesFactory allow for the entities to be created (with CREATE2) uninitialized. Therefore, the constructed salt from parameters on deployment may differ from parameters on initialization.
5. `claimBatch()` may revert in case of front-run (by the claimer himself) with a single `claim()` function.
6. Networks are responsible for the proper usage of the core contracts.
7. New deposits into the vault may be slashed by already existing slashing requests.
8. Trust assumptions by each party

• Automated findings by Lightchaser
  • symbioticfi-report

Contact Us

For any issues or concerns regarding this competition, please reach out to the Cantina core team through the Cantina Discord.