Skip to main content

Manual for Networks

  • Collateral(s) has/have an economic value (e.g., ETH exists for around 9 years and is widely used as a financial instrument) and, optionally, aligned with your protocol (depending on your security model); otherwise, 1) profit from attack of your protocol may be greater than the cost of attack; 2) the cost of attack may be so negligible, so an attack with a goal to grief is possible.

  • A set of Vaults is diversified (depending on your security model, e.g., if you use only your Vaults or any ones); otherwise, it may result in a rapid stake decrease with a potential attack.

    • Vaults’ Curators are trustworthy in case of third-party Vaults (depending on your stake diversification).

  • Each Vault with VetoSlasher doesn’t have Veto Duration too close to Vault Epoch Duration (e.g., Veto Duration that is equal to epochDurationepochDuration minus 10 minutes, even having a tiny Network Epoch, may lead for a slashing request not to be executed because of censoring, high gas, delay in monitoring, etc.; therefore, an example possible configuration is: Vault Epoch Duration is 7 days, Network Epoch lasts for 3 days, Veto Duration is 1 day, so 2 days can be used for an execution).

  • Each Vault has an Epoch Duration noticeably greater than the validatorSetCaptureDelayvalidatorSetCaptureDelay (e.g., a waiting time for a capture block to finalize on Ethereum) plus Network Epoch’s duration plus Network Slashing Window (e.g., Network Epoch’s duration plus Veto Duration (in case of VetoSlasher) greater than the Vault Epoch Duration will lead to impossibility to create a slashing request; therefore, an example possible configuration is: Vault Epoch Duration is 14 days, validatorSetCaptureDelay is 15 minutes, Network Epoch lasts for 5 days, maxSlashRequestDelaymaxSlashRequestDelay is 2 days, Veto Duration is 2 days, maxSlashRequestDelaymaxSlashRequestDelay is 2 days, and there is still a 3 days buffer).

  • Each Vault is deployed properly in the sense that the Delegator and the Slasher are set (can be checked via Vault.isInitialized()); otherwise, in the future, it may provide unsupported data (e.g., NetworkRestakeDelegator is supported, but FullRestakeDelegator is not) about the stake or may not be able to slash the stake at all.

  • A set of Operators is diversified; otherwise, it may result in an Operator (or a group of Operators) with a significant share of the whole stake to attack the protocol.

    • Operators are trustworthy in case of a small, either permissionless or permissioned validator set.

  • Each Network you are in the same Vault with (in case of using restaking mechanism) is trustworthy (depending on your stake diversification); otherwise, your economic security may suffer because of the malicious slashings by a "neighbor" Network (e.g., a Vault has 100$ of a stake, a Network 1 is provided with 100$ of this stake, a Network 2 is also provided with 100$; Network 2 maliciously slashes 100$, and the economic security of the Network 1 drops to zero in that Vault).

  • You are aware that NetworkRestakeDelegator.stakeAt()/FullRestakeDelegator.stakeAt() (the function returning a stake for an Operator in your Network) counts the whole existing money as a real stake, meaning that it doesn’t take into account pending slashings from you or your "neighbor" Networks. Hence, it should be covered by your Middleware depending on the Vault’s type and your slashings’ processing logic.

  • You are aware that slashing requests for a single operator should be executed sequentially in the sense of the Capture Timestamp (e.g., a slashing request A with Capture Timestamp equal to 10 should be executed earlier than a slashing request B with it equal to 20; if not, the slashing request A will revert); otherwise, it may result in an Operator to get slashed less than assumed with a further potential attack.