Ethereum
BSC
Tron
Base
Arbitrum
Hyperliquid L1
Avalanche
Polygon
Berachain
Unichain
Sonic
Cronos
BSquared
Bitlayer
CORE
OP Mainnet
Hemi
Taiko
Gnosis
Mantle
Linea
Blast
Celo
ZKsync Era
Scroll
WorldChain
Swellchain
Manta

The system is permissionless; the only limitation is rebasing tokens

• Constructor inputs like NETWORK_REGISTRY, NETWORK_MIDDLEWARE_SERVICE and others mean Symbiotic core contracts deployment, and are considered to be correctly set up (e.g., using https://docs.symbiotic.fi/deployments/mainnet)
• Regarding permissions "inside" the network: In general, the system allows a high granularity of roles across all the contracts. However, the most important part to mention here is the Settlement.setGenesis() function with a needed permission, which ideally should be called only once at the start, as it can affect the validator set (which represents the network) and, hence, the network's decisions.
• Regarding permissions in the sense of external parties: Basically, all the permissions directly or indirectly belong to the network, and in most cases, different setups mean different security assumptions inside its system (e.g., possible configurations are 1) all the actions are performed based on the majority decision, 2) fully controlled by the protocol's (network's) team). There are a couple of exceptions, such as "slasher" and "rewarder" addresses in BaseSlashing and BaseRewards, which affect the stakers directly and should be thoroughly considered by them.

No, but it's important to mention that the code under the contest is an SDK, so the number of use-cases can be wide and, in the end, it is up to the user of this SDK (network/protocol) to decide on external trust assumptions (e.g., threre is shared vault with several stake consumers and with a custom route for slashed funds; it is up to the network if to consume the stake from this vault or not)

No, the codebase only uses some subjects (ERC20, precompiles) from EIPs, but doesn't implement any

There is an off-chain part of the Symbiotic Relay that implements the validator set usage itself, including message signing, maintenance of validator set headers (which represent the validator set itself) through epochs, and signature aggregations. Mainly, it consumes VotingPowerProvider.getVotingPowers(At)(), KeyRegistry.getKeys(At)(), all of the ValSetDriver functions for validator set derivation and futher interactions with Settlement, EpochManager.getCurrentEpochStart() (and other epochs-related functions), most functions from Settlement for synchronisations, commitments, and verifications. Example dependency on this off-chain part: if any validator set has committed a malicious header by its majority, it is acceptable from the on-chain side.

No

• Each basic contract’s storage is located in an unstructured way, which allows for more convenient utilisation of them when developing a complete system (with proxies, non-standard storage layout schemes, etc)
• We aimed to find an ideal balance between development UX (e.g., through forcefully exposed to external environment functions), bytecode size limitations, and gas costs. Hence,
  • Most of the functionality is virtual, so it can be overridden/reused easily
  • In rare cases, we used external libraries to save bytecode, but implemented internal functions in the contracts which don’t increase bytecode when not used
• Most of the data regarding the middleware’s state is historical. This simplifies the implementation of the off-chain part.

https://github.com/symbioticfi/middleware-sdk/blob/main/audits/Bailsec-RelaySmartContracts.pdf

https://docs.symbiotic.fi/

As is the default, a high severity issue is worth 5 times the value of a medium severity issue. To encourage placing more of an emphasis on the main scope, vulnerabilities found in the ZK and Network portions have a reduced weight. An issue in the ZK or Network portion will be worth 0.1x weight of a normal medium or high. This means a Medium issue in that area is worth a tenth of a Medium in the main scope.

For the circuit.go file, only the func (circuit *Circuit) Define is considered in-scope, while the function func setCircuitData is considered OOS and issues related to it will be considered invalid.

Issues in the SDK view functions that are not used by the state-changing functions and don't pose a threat to the current scope, but may pose issues for protocols which will build on top of the SDK, will be considered valid in this contest. However, since we can't fully evaluate the impact (as it depends on what will be built on top of SDK), these issues will be considered flat Medium.