kayabaNerve
commented
11 months ago https://github.com/serai-dex/serai/issues/394#issuecomment-1823925493 reposits the model using an on-chain oracle to achieve stake requirements only relative to the sriXYZ value (and not any associated liquidity), achieving the same effect as #402 and enabling closing it.
A multisig has two requirements to be secure:
1) It must not be profitable for any subset of validators to turn malicious 2) Upon malicious activity, liquidity providers must be made whole
Since a compromised multisig is able to drain the pool of all contained coins, XYZ and SRI (via swapping non-existent XYZ to drain the SRI side of the pool), the stake allocation requirement for any external network is:
multiplied by
n / t, which is 1.5 in practice,plus some margin in order to protect against price fluctuations between XYZ and SRI.
This means for the 67% of stake required to take over a multisig, 1.01x the value of profit theoretical must be paid (ignoring the margin). While 1.01x may be insufficient to make liquidity providers whole (due to slippage), the entire validator set's stake (150% potential revenue from malicious activity) is usable to repay liquidity providers given we can't actually tell which validators in the set were malicious. Accordingly, we have the justification to slash all of them and move on. While ideally, we can later prove some innocent and reimburse them if coins remain, the primary goal is to reimburse liquidity providers. The primary reason for the margin is to ensure it's unprofitable to steal, NOT to itself be the margin needed to re-acquire lost coins.
This is distinct from most comparable networks which only include the value of their external coins in their stake allocation requirements. This is generally due to only using a single multisig for all sets so upon compromise, the value of the liquidity coin is written off to 0. Due to Serai being robust against the compromise of any individual multisig, we do need to include the value of the SRI within our calculations. Accordingly, Serai, in comparison to other networks, has 2x as high of a stake allocation requirement.
Given that existing networks, and Serai theoretically, are primarily limited by the amount of stake allocated, the focus becomes reducing this requirement.
A prior issue, #60, covers the design of the AMM and is notable here as an concentrated-liquidity based AMM would offer greater market efficiency with reduced liquidity (and accordingly reduced allocated stake requirements). The main issue is the complexity it'd cause.
401 proposes increasing the notated stake allocation for validators who additionally provide liquidity, achieving just a 0.5x of pool value stake requirement (1x compared to external value).
402 discusses the usage of light clients combined with STARKs to prevent the SRI side of the pool from being drained, halving stake requirements.
While #60 cannot be directly assigned a numeric advantage here, #401 (with 100% of LP provided by the validators) and #402 together would reduce the stake requirements of Serai to just 0.25x the pool value, or 0.5x the external value on the network.