Introducing DSLA Protocol v1.0 and the future of third-party risk management

The Downside of Convenience

Whether as individuals or as organisations, we delegate increasingly more functions of our lives to third-party service providers. But with increased convenience, comes increased exposure to risk. And most users lack the expertise, capital and time to manage it.

So we created DSLA Protocol.

It enables the different stakeholders of a given service to trade third-party risk with each other, using Decentralized Service Level Agreements (SLA).

Decentralized SLAs are peer-to-peer outsourcing contracts, running on a blockchain network. They can store and release cryptocurrency, based on the performance analytics of third-party services.

Instead of simply providing coverage like insurance products, Decentralized SLAs bring an extra layer of trust to the user-provider relationship, by guaranteeing consistent returns for users, and by incentivising providers for speed, power, uptime and more.

DSLA Protocol

Today, we are excited to tell you more about how DSLA Protocol is going to put your third-party risk management on autopilot. We are targeting an L1 Ethereum mainnet launch on March 31, 2021, with L2, Harmony and Avalanche deployments to follow shortly after.

All deployments are contingent on the results of ongoing security audits.

DSLA Protocol v1 introduces a series of in-house innovations:

• Risk Hedging, enabling developers, users, and liquidity providers to transfer risk between peers using Decentralized Service Level Agreements (SLA);

• Reliability Forecasts, enabling third-party risk assessment at a glance, through the wisdom of the SLA marketplace and its participants;

• Leveraged Premiums, enabling developers, users, and liquidity providers to better market their SLA contracts and modulate the cost of SLA premiums;

• A Triple Token Design, to separate the functions of SLA enforcement, and tokenisation of SLA positions;

• SLA Maintenance Rewards, to incentivise the creation of decentralized service level agreements, and the availability of subsequent reliability forecasts;

• Native Token Burns, everytime a SLA is verified, to ensure the long-term sustainability of DSLA Protocol and utility of DSLA Token;

• Programmable SLAs, enabling the addition of new types of SLAs and use cases over time, developed by the community;

• Developer Tools, enabling developers to add risk management capabilities to their service, or design risk-aware customer experiences from scratch;

• No Code Tools, enabling third-party service providers to add risk management widgets to their service, without technical knowledge.

These innovations make DSLA Protocol the 1st ever Risk Prediction Market Maker. Although we generally identify ourselves as a Risk Management framework.

Risk Hedging

In DSLA Protocol, service stakeholders can transfer third-party risk between peers, by staking on the outcome of periodic events, called SLA verifications.

A stakeholder is a user, a provider or someone willing to stake on either side of the user-provider relationship.

If a SLA verification establishes that the terms of a SLA have been honoured by the third-party service provider, the contract creator earns a cryptocurrency reward. And if the SLA is breached, the contract stakeholders can claim the cryptocurrency reward for themselves.

DSLA Protocol is permissionless, so the contract creator does not need to be affiliated to the provider to create a SLA.

Instead, anybody can stake on either side of the user-provider relationship to take on risk or offset risk, then earn SLA staking rewards based on the outcome of SLA verifications.

SLA Contract Types

DSLA Protocol is specialized in DeFi (Decentralized Finance) Risk Reduction, with an initial focus on mitigating staking efficiency drops.

Staking Efficiency is the percentage of rewards collected by a staking service provider, compared to the rewards he would have collected in ideal conditions.

It gives users a sense of how much returns they are missing out on, compared to the initial returns promised by their staking service provider.

This use case has been developed by Stacktical, the core development team of DSLA Protocol. But it only scratches the surface of its capabilities, as the protocol can evolve through the addition of other types of SLA, and support new use cases in a wide range of industries.

In fact, we went as far as rewarding SLA contract type developers, every time a risk prediction market uses their code during a SLA verification.

Reliability Forecasts

As the SLA marketplace gets populated, and tokenized SLA positions get issued, the sentiment surrounding a third-party service will become quantifiable.

Beyond user reviews, DSLA Protocol is the 1st risk management framework to rely on the wisdom of the crowd to establish service delivery goals, and facilitate third-party risk assessment.

Tokenized SLA Positions

To either offset or take on risk, users and liquidity providers need to stake cryptocurrency to a SLA. Upon staking, stakeholders are issued a new, liquid token representing their SLA position.

The tradable nature of these tokens will surely come in handy later.

Triple Token Model

Along with the DSLA utility token, that is already issued, DSLA Protocol dynamically issues and relies on two other tokens to empower its SLA use cases.

DSLA Protocol’s Triple Token Model is comprised of:

• DSLA, our utility token empowering periodic SLA verifications and governance,
• DSLA-SP, a token representing a user position for offsetting risk
• DSLA-LP, a token representing a provider position for taking on risk

SLA Maintenance Rewards

Although they are supposed to drive customer satisfaction, traditional service level agreements are disconnected from the economic remediation of breaches. They also create an incentive for providers to deliver minimum service at minimum cost.

Decentralized SLAs, on the contrary, have the ability to grant cryptocurrency to both Users and Providers, based on how much a service deviates from the Service Level Objectives (SLO) defined in the SLA.

[ ](https://info.uniswap.org/pair/0xd0fbb87e47da9987d345dbdf3a34d4266cf5ebe9

Both sides of the user-provider relationship can be vouched for.

The more the service exceeds expectations, the more rewards are granted to the SLA contract creator. Users, on the other end, are free to overcollateralize their third-party risk, to earn bigger compensations.

SLA Verification Token Burn

To align the DSLA token supply with the usage of the DSLA Protocol, DSLA token are burned like fuel, everytime a SLA contract is verified. Starting from our mainnet launch, the 7B supply of DSLA tokens will decrease over time, as service stakeholders transfer third-party risk on the marketplace.

Developer Tools

DSLA Protocol’s ambition is to empower communities of developers and infrastructure operators to reduce their users exposure to service delays, interruptions and financial losses.

Along with the ability to develop custom SLA contract types, developers can integrate DSLA Protocol into their own services, to take their user experience to higher quality standards, or develop new use cases from scratch.

No Code Tools

An increasing number of non-technical stakeholders, such as organizations legal and compliance departments, are expressing strong interest in using DSLA Protocol for its business workflow automation capabilities.

DSLA.network, our flagship Ðapp, will enable users without technical knowledge to export and embed parts of the DSLA experience where they see fit.

e.g. In the clause of a business agreement.

Tokenomics

DSLA Protocol introduces a new way to tokenize third-party risk.

In order to understand its economic incentives, it is necessary to understand the motivations of its stakeholders. ** There are two main types of stakeholders in DSLA Protocol: **Providers and Users.

Providers create and provide liquidity to Decentralized SLA contracts, to trade the outcome of periodic SLA verifications with a positive bias.

This unit of time is the DSLA period.

When they create a Decentralized SLA, Providers decide how many DSLA periods will the contract last, the goal of the contract (SLO, or Service Level Objective), and how frequent should the reliability of the service be calculated and verified (SLI, or Service Level Indicator).

Providers stake DSLA tokens to pay for periodic verifications.

After a DSLA Period is finished, it can be verified.

The verification fee is split between:

• The User doing the verification (25%), to:
  • cover the cost of calling this function in the protocol;
  • incentivize a fast verification after the period is finished.
• The Developer that created the verification logic (25%), to:
  • cover development and infrastructure costs;
  • incentivize the creation of new SLA contract types.
• Core developers (25%), to cover infrastructure costs.

The rest of DSLA tokens is burned (25%).

Users provide liquidity to existing Decentralized SLA contracts, to trade the outcome of periodic SLA verifications with a negative bias.

If after comparing the SLI with the SLO, the terms of the SLA have been honoured by the third-party service provider, the Provider earns a cryptocurrency reward. And if the SLA is breached, Users can claim compensations.

Now let’s have a look at how rewards and compensations are calculated.

Provider Incentive

The provider reward equals the Users pool, multiplied by the DSLA period reward rate.

\[periodIncentive = \frac{verifiedPeriodId}{SLAAmountOfPeriods}\]

For example, if:

• A SLA has 12 DSLA periods
• The DSLA period to verify is the 3rd
• The SLI deviation is 4%

\[rewardRate = periodIncentive*sliDeviation=\frac{3}{12}*4=1\%\]

Where sliDeviation is defined as below:

\[sliDeviation = \frac{SLI-SLO}{\frac{SLI+SLO}{2}}\]

Users Compensations

The Users pool is completely protected by the Provider pool.

This means that if the Users pool is 2000 DSLA tokens, then after a DSLA period is deemed as Not Respected, the Users pool will be 4000 DSLA tokens.

After a SLA is created, staking is either open to anyone, or open to whitelisted users.

In order to ensure that the rewards and compensations are correctly distributed no matter the circumstances, the staking process should comply with the following rules:

• There are going to be 2 pools in place, the Users pool and Provider pool;

• The Users pool should never be bigger than the Providers pool;

• The Providers pool should never be smaller than the Users pool, except after the contract is finished (when the contract is breached or the last period is respected);

• The users can stake at any period, if the SLA is not terminated;

• The provider can stake at any period, if the SLA is not terminated;

• The users can only withdraw stake after the contract is terminated;

• The provider can withdraw stake at any time, as long as his pool is greater than or equal to the users pool;

• Only the SLA creator can stake on the provider pool;

• Everyone can stake on the users pool, except for whitelisted SLAs.

DSLA-SP & DSLA-LP Tokens

After every DSLA period both pools are going to increase or decrease in size. In order to keep track of the stakeholders stakes and claiming right without taking care of DSLA periods, tokenised SLA positions are issued to the SLA creator taking on risk, or to SLA users offsetting risk.

DSLA-LP and DSLA-SP tokens are minted/burned after every stake/withdrawal.

Both the lpTokens and the spTokens are minted using functions that track their value over time.

As minting is going to be applied only on not finished contracts, then we can assume that the spTokens value is going to decrease over time, because after every respected period there’s going to be a reward for the provider from the users pool, which will decrease the userStakedTokens/spTokens ratio.

Using the same logic, we can say that lpTokens value is going to increase over time because of the rewards after a respected period, which will increase the providerStakedTokens/lpTokens ratio.

The burning process in both cases is tied to the staking rules. The withdraw result is then proportional to the DSLA-LP and DSLA-SP that the caller is going to burn in order to withdraw her tokens.

lpToken minting

The mint process is intended to maintain the providerPoolSize/lpTokenTotalSupply ratio:

\[\frac{providerPoolSize}{lpTokenTotalSupply} = \frac{providerPoolSize+providerStake}{lpTokenTotalSupply+mintedLpTokens}\]

And the formula for minted lpTokens is:

\[mintedLpTokens = providerStake* \frac{lpTokenTotalSupply}{providerPoolSize}\]

Where the lpToken minting rate is:

\[lpMintingRate = \frac{lpTokenTotalSupply}{providerPoolSize}\]

This minting rate is going to be fixed for the current period, no matter if the provider stakes more tokens or if he withdraws.

For instance, if at a given period the provider DSLA pool is 100, the lpToken total supply is 98, then the minting rate is:

\[lpMintingRate = \frac{98}{100}=0.98\]

If the provider stakes 100 DSLA, then he is going to get:

\[\scriptsize mintedLpTokens = providerStake* \frac{lpTokenTotalSupply}{providerPoolSize}=100*\frac{98}{100}=\text{98 lpTokens}\]

The minting rate changes only after a period is verified because the provider pool size is going to change, but the lpToken total supply is going to stand still.

Imagine there is a reward of 50 DSLA after a respected period, the new lpToken minting rate would be:

\[lpMintingRate_1=\frac{lpTokenTotalSupply_1}{providerPoolSize_1+reward_1} = \frac{196}{250}= 0.784\]

Which means that if the provider stakes 100 DSLA again, the lpTokens minted would be:

\[\small lpMintedTokens=stake*lpMintingRate=100*0.784 =\text{78.4 lpTokens}\]

This minted token will keep the $lpMintingRate_1$:

\[lpMintingRate_1=\frac{lpTokenTotalSupply_1}{providerPoolSize_1} = \frac{274.4}{350}= 0.784\]

The lpToken is then a deflationary token i.e. after every period, the average value of staked per lpTokens token is going to increase.

lpToken burning

The caller is going to receive a proportion of the provider pool, represented by how much lpTokens is willing to burn, but keeping the user providerPoolSize/lpTokens ratio:

\[\frac{providerPoolSize}{lpTokenTotalSupply} = \frac{providerPoolSize-callerWithdraw}{lpTokenTotalSupply-burnedLpTokens}\]

The burned lpTokens and caller withdraw formulas are:

\[burnedLpTokens = callerWithdraw* \frac{lpTokenTotalSupply}{providerPoolSize}\] \[callerWithdraw = burnedLpTokens* \frac{providerPoolSize }{lpTokenTotalSupply}\]

From here, we can state two formulas:

• $lpBurnRate$: how many lpTokens the caller is going to burn for every withdrawn staked token

  \[lpBurnRate = \frac{lpTokenTotalSupply}{providerPoolSize}\]

• $dpWithdrawRate$: how many staked tokens the caller is going to receive for every burned spToken

\[dpWithdrawRate = \frac{providerPoolSize }{lpTokenTotalSupply}\]

spToken minting

The mint process is intended to maintain the usersPoolSize/spTokenTotalSupply ratio:

\[\frac{usersPoolSize}{spTokenTotalSupply} = \frac{usersPoolSize+userStake}{spTokenTotalSupply+mintedSpTokens}\]

And the formula for minted lpTokens is:

\[mintedSpTokens = userStake* \frac{spTokenTotalSupply}{usersPoolSize}\]

Where the spToken minting rate is:

\[spMintingRate = \frac{spTokenTotalSupply}{usersPoolSize}\]

For instance, if the user pool size is 100, the spToken total supply is 200:

\[spMintingRate=\frac{200}{100}= 2\]

Which means that if a user stakes 100 DSLA on the period 2, then the spTokens minted are:

\[mintedSpTokens = stake*spMintingRate=100*2 = \text{200 spTokens}\]

Not that even after the stake, the $spMintingRate$ stays the same:

\[spMintingRate = \frac{spTokenTotalSupply}{usersPoolSize}=\frac{400}{200}=2\]

spToken burning

The caller is going to receive a proportion of the users pool, represented by how much spTokens is willing to burn, but keeping the user usersPoolSize/spTokens ratio:

\[\frac{usersPoolSize}{spTokenTotalSupply} = \frac{usersPoolSize-callerWithdraw}{spTokenTotalSupply-burnedSpTokens}\]

The burned spTokens and caller withdraw formulas are:

\[burnedSpTokens = callerWithdraw* \frac{spTokenTotalSupply}{usersPoolSize}\] \[callerWithdraw = burnedSpTokens* \frac{usersPoolSize }{spTokenTotalSupply}\]

From here, we can state two formulas:

• $spBurnRate$: how many spTokens the caller is going to burn by every withdrawn staked token

\[spBurnRate = \frac{spTokenTotalSupply}{usersPoolSize}\]

• $duWithdrawRate$: how many staked tokens the caller is going to receive by every burned spToken

\[duWithdrawRate = \frac{usersPoolSize }{spTokenTotalSupply}\]

The spToken is then an inflationary token. i.e. After every period, the average value of staked token per spToken is going to decrease.

Security Audits & Bug Bounty

Although it is not the type of risk address by DSLA Protocol, security is close to the project’s DevOps DNA. In order to properly secure our mainnet launch, our team has sought the assistance of leading security firms and experts in the industry, and will maintain its efforts after launch.

Our security process for DSLA Protocol includes:

• An audit from leading smart contract auditor CertiK
• An audit from leading german security firm Chainsulting
• A security bug bounty campaign live on Immunefi
• Two independant audits from white hat hackers
• Comprehensive internal, manual and automated testing

Although we were able to address all the bugs we encountered during internal and external auditing so far, we cannot guarantee all DSLA Protocol bugs in existence have been discovered.

It is an unavoidable reality of any software development effort.

In order to launch DSLA Protocol on March 31, 2021, we will need at least two successful audits from our partners. One clear, one more to go.

---

About DSLA Protocol

DSLA Protocol is a risk management framework that enables developers and infrastructure operators to reduce their users exposure to service delays, interruptions and financial losses, using self-executing service level agreements, bonus-malus insurance policies, and crowdfunded liquidity pools.

Its flagship use case is to offset the financial losses of proof-of-stake delegators and DeFi users, while incentivizing the good performance and reliability of staking pool operators and DeFi service providers such as Uniswap (AMM) and OpenSea (NFT).

To learn more about DSLA Protocol, please visit stacktical.com, browse our official blog, and follow @stacktical on Twitter.