Social Insurance for Systematically Important Infrastructure

TL;DR

• Systemically Important Infrastructure in the SORA ecosystem are applications deemed to be vitally important by the SORA Parliament
• SII dApps will be governed by the SORA Parliament and in exchange will be insured against loss of funds for users by hacks or bugs
• In exchange for SII, governance of the dApps needs to be delegated to the SORA Parliament
• The first SII on the SORA network was the HASHI bridge, with Polkaswap proposed for becoming an SII

One of the downsides of Decentralized finance is the lack of a safety net in case there is a scenario like a hack or a bug. Centralized entities and the status quo have opted for the extreme measure of prohibiting DeFi and such activities as a way to protect customers (and ultimately themselves) from the liabilities that such situations can bring, especially since it’s dealing with peoples’ money.

Some entities have even gone as far as to insert disclaimers in their wallet confirmations as a way to deter some of the risks associated with decentralized finance in certain jurisdictions, such as the SEC in the United States. See more.

Instead of simply waiving responsibility, the SORA ecosystem aims to actually protect users, and one way this is accomplished is by Social Insurance functions, that borrow some concepts from deposit insurance (cf., Federal Deposit Insurance Corporation (FDIC)), by insuring dApps, and by consequence, their users against losses caused by attacks or bugs. To put this into context, let’s study the FDIC as an example and how it protects users.

Insurance Against Failures

Before the implementation of the FDIC in 1933, the banking sector in the United States was similar to the cryptosphere. There were banking closures or “run on the bank” scenarios during the Great Depression, which caused customers to withdraw their funds en masse, resulting in the total loss of savings for people who didn’t hurry to withdraw their funds from affected banks.

Basically, there was no guarantee for the safety of funds within the banking system, other than confidence in the bank. As a way to encourage stability, and maintain public confidence in banks, the US government established the FIDC to insure deposits in member US banks, with a coverage of up to $250,000 for people who opted to save in a FIDC-insured bank. In case of a bank failure, users would not end up empty-handed, like their counterparts prior to the FIDC establishment. Although that protection seems fairly effective, anyone with deposits that exceeded the $250K cap would lose the excess, so some states went as far as to implement extra insurances that would cover the offsets.

In a similar vein, the SORA Social Insurance for Systematically Important Infrastructure (SII) has been implemented to encourage trust in the SORA network, as well as to protect users. Unlike the FDIC, there is no cap regarding the amount deposited into SII, but like the FDIC, entities, in this case, dApps are required to be “members,” or, in this case, Systematically Important Infrastructure to qualify for this insurance.

But, what is SII and how is a dApp considered systematically important?

Systematically Important Infrastructure

There are applications deemed vitally important to the SORA network, such as the (approved by referendum) HASHI Bridge or (proposed) Polkaswap, that could potentially, in the future, be vulnerable to external attacks or bugs that result in a loss of user funds. For dApps such as these, there is a Social Insurance implemented by the SORA Parliament that covers losses to users as a direct result of an attack or bug.

All dApps can apply to the SORA Parliament for Social Insurance, however, only the ones that are deemed systematically important infrastructure (SII) will qualify. There are certain requirements and consequences to this implementation.

First, an SII dApp should handle or potentially handle enough user funds where failure would hurt the overall SORA economy. If this is not the case, then a dApp is not systemically important.

Second, the dApp should have a development process such that updates can be voted on via on-chain referendums. This is important because only updates that happen on-chain can be governed by the SORA Parliament.

Third, the quality of the dApp should be such that catastrophic failure leading to a loss of user funds is extremely unlikely. The goal of the SORA Social Insurance for SII programme is to reward high-quality dApps with an increased boost in confidence for users, not to reward shoddy engineering.

Any dApp that meets the above criteria should consider applying to become an SII, however, the selection will be carried out on a case-by-case basis, and voted for by the SORA Parliament, and, until the Parliament is set up, will be approved or rejected via on-chain referendums. Although the HASHI Bridge is already an SII voted on via referendum before the launch of the SORA v2 network, Polkaswap has been the first to be proposed since the v2 network launch, as it is critical infrastructure for asset liquidity on the SORA network.

Once a dApp has fulfilled the parameters to be considered an SII, or membership requisites following the FDIC example, there is one more important step that has to be taken, the app must delegate its governance to the SORA Parliament.

Delegation of governance will ensure that the dApp follows all the processes and protocols established by the SORA Parliament for the safety and security of users against hacks and bugs, and will therefore be entitled to Social Insurance. Unfortunately, there are some bad players that could commit insurance fraud to escape with user funds and expect Social Insurance to cover the user’s losses, therefore this measure is in place to avoid such scenarios (which is also why updates should all be on-chain).

Win-Win-Win Situation

SORA SII Social Insurance doesn’t cover user errors and DeFi is inherently risky, but to curb user losses as much as possible from protocol failures or exploits, measures like the SII-Social Insurance are helpful to mitigate risks. However, there are also risks that the SORA Parliament could be exposed to if the SII were freely available and distributed to all dApps, which is why once the Parliament is set up, a comprehensive vetting process needs to be established.

With network and user safety in mind, delegating SII dApp governance to the SORA Parliament is a win-win-win scenario to allow dApps, users, and the SORA Parliament to collaborate and place the wider community and network’s needs before centralized developer control. This can increase community confidence in using SII dApps on the SORA network.

Because apps entitled to SII are Systematically Important, separating governance, development, and user capital can reduce the likelihood of structural risks arising in the SORA economy.

Finally, it is important to consider that these measures are ultimately in place for user protection. Unfortunately, there are many projects that prioritise the bottom line over users, or that are not really building for the long term, so it is necessary at this point to bring some order to the DeFi Wild West, without compromising decentralization itself. All of these measures are in place to protect users, and guarantee that the SORA network is stable and trustworthy. Ultimately, the goal is for the community to rest assured that funds are SAFU.