Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduction of allocated stake requirements meta-issue #400

Open
kayabaNerve opened this issue Oct 17, 2023 · 2 comments
Open

Reduction of allocated stake requirements meta-issue #400

kayabaNerve opened this issue Oct 17, 2023 · 2 comments
Labels
discussion This requires discussion

Comments

@kayabaNerve
Copy link
Member

kayabaNerve commented Oct 17, 2023

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:

  • The value of the external coins present on Serai
  • The value of the SRI provided as liquidity against the external coins

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.

@kayabaNerve
Copy link
Member Author

#394 (comment) 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.

@kayabaNerve
Copy link
Member Author

kayabaNerve commented Dec 5, 2023

#402 was closed as won't fix with the merging of #459 (which achieved the desired effect).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion This requires discussion
Projects
None yet
Development

No branches or pull requests

1 participant