superfluid-finance / protocol-monorepo

Superfluid Protocol Monorepo: the specification, implementations, peripherals and development kits.
https://www.superfluid.finance
Other
872 stars 237 forks source link

[SPEC] Define Various Solvency Models #739

Open hellwolf opened 2 years ago

hellwolf commented 2 years ago

Financial System

In order to define solvency models, we need to first define a financial system model where payment semantics are executed. A minimum financial system functioning on the monetary distribution could formally defined as such:

image

where:

Solvency Models

There are two orthogonal problems with solvency models:

  1. Solvency risk model of the financial system.
  2. Solvency execution model of the financial system.

Solvency Risk Model

The simplest solvency risk model is a binary fcPred based on flow sender's balance amount, if it is negative, then an associated liquidation contract can be executed by anyone with a profit.

E.g. this financial contract could be translated to "if Bob's balance is negative, then anyone can delete the flow between bob and alice and a X amount of tokens are given to the executor of the contract".

This way, we need not to extend the payment semantics at all.

There may be other overlays of risk model where the cost of execution is part of the model too, so that some negative account. For simplicity, this will not be covered here.

Solvency Execution Models

There are properties of the execution models can vary between designs:

Deterministic & Concurrency

Having both deterministic execution order and concurrency would require fcSet to have a stronger condition, e.g. a poset (partially ordered set). It is particularly unscalable (O(N) time complexity as fcSet grows in size) to implement, unless fcPred itself could be optimized/limited to also poset of fcPred sorted by time.

The alternative is having non-deterministic execution order (then trivially being concurrent, albeit not as helpful). And indeed that is the model the current live system on EVM is using.

Atomicity

Although not directly related to solvency models, the ability to be able to bundle financial contracts together creates new possibilities for native execution-level automation.

Technical Notes

BBS

The EVM-v1 Superfluid protocol is using some sort of BufferBasedSolvecy (BBS) model.

BBS is a solution specialized in the context of crypto-economics where buffer is used both for security guarantees for systematic time delays, and for attackers' economic penalty. Additional modification to the system by introducing more roles in-conjunction with an auction of privilege system called TOGA is also enabled in the EVM-v1 implementation.

Assumptions To Revisit

Time Sync Solvency (TSS)?

An often talked about alternative solvency model is a time-keeper to guarantee the advancement of time while tying with its own interest to make sure no liquidity risk in the system.

hellwolf commented 1 year ago

Update:

Financial System

In order to define solvency models, we need to first define a financial system model where payment semantics are executed. A minimum financial system functioning on the monetary distribution could formally defined as such:

image

where:

Solvency Models

There are two orthogonal problems with solvency models:

  1. Solvency risk model of the financial system.
  2. Solvency execution model of the financial system.

Solvency Risk Model

The simplest solvency risk model is a binary fcPred based on flow sender's balance amount, if it is negative, then an associated liquidation contract can be executed by anyone with a profit.

E.g. this financial contract could be translated to "if Bob's balance is negative, then anyone can delete the flow between bob and alice and a X amount of tokens are given to the executor of the contract".

This way, we need not to extend the payment semantics at all.

There may be other overlays of risk model where the cost of execution is part of the model too, so that some negative account. For simplicity, this will not be covered here.

Solvency Execution Models

There are properties of the execution models can vary between designs:

Deterministic & Concurrency

Having both deterministic execution order and concurrency would require fcSet to have a stronger condition, e.g. a poset (partially ordered set). It is particularly unscalable (O(N) time complexity as fcSet grows in size) to implement, unless fcPred itself could be optimized/limited to also poset of fcPred sorted by time.

The alternative is having non-deterministic execution order (then trivially being concurrent, albeit not as helpful). And indeed that is the model the current live system on EVM is using.

Atomicity

Although not directly related to solvency models, the ability to be able to bundle financial contracts together creates new possibilities for native execution-level automation.