Trade on BingX with 45% Fee Discount and Bonus Up to 200 USDT

Sunday, March 28, 2021 UTC

Introducing DSLA Protocol v.1.0 & 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 Prediction Markets, enabling developers, users, and liquidity providers to trade risk with each other 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;

• SLA Futures Positions, tokenised LONG/SHORT positions issued to the SLA creator taking on risk (LONG), or to SLA users offsetting risk (SHORT);

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

• SLA Staking 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 Prediction Markets

Prediction Markets let you trade the outcome of real world events.

In DSLA Protocol, service stakeholders can trade third-party risk with each other, 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 SHORT, user position for offsetting risk

• DSLA-LP, a token representing a LONG, provider position for taking on risk

SLA Staking 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.

Both sides of the user-provider relationship can be bet on.

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 trade 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.

Provider Staking Rewards

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

p e r i o d I n c e n t i v e = \frac{v e r i f i e d P e r i o d I d}{S L A A m o u n t O f P e r i o d s}

For example, if:

▪ A SLA has 12 DSLA periods

▪ The DSLA period to verify is the 3rd

▪ The SLI deviation is 4%

r e w a r d R a t e = p e r i o d I n c e n t i v e * s l i D e v i a t i o n = \frac{3}{12} * 4 = 1 %

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 LONG/SHORT positions are issued to the SLA creator taking on risk (going LONG with DSLA-¨LP), or to SLA users offsetting risk (going SHORT with DSLA-SP).

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 dTokens 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{p r o v i d e r P o o l S i z e}{l p T o k e n T o t a l S u p p l y} = \frac{p r o v i d e r P o o l S i z e + p r o v i d e r S t a k e}{l p T o k e n T o t a l S u p p l y + m i n t e d L p T o k e n s}

And the formula for minted lpTokens is:

m i n t e d L p T o k e n s = p r o v i d e r S t a k e * \frac{l p T o k e n T o t a l S u p p l y}{p r o v i d e r P o o l S i z e}

Where the lpToken minting rate is:

l p M i n t i n g R a t e = \frac{l p T o k e n T o t a l S u p p l y}{p r o v i d e r P o o l S i z e}

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:

l p M i n t i n g R a t e = \frac{98}{100} = 0.98

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

m i n t e d L p T o k e n s = p r o v i d e r S t a k e * \frac{l p T o k e n T o t a l S u p p l y}{p r o v i d e r P o o l S i z e} = 100 * \frac{98}{100} = 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:

l p M i n t i n g R a t e_{1} = \frac{l p T o k e n T o t a l S u p p l y_{1}}{p r o v i d e r P o o l S i z e_{1} + r e w a r d_{1}} = \frac{196}{250} = 0.784

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

l p M i n t e d T o k e n s = s t a k e * l p M i n t i n g R a t e = 100 * 0.784 = 78.4 lpTokens

This minted token will keep the lpMintingRate1

l p M i n t i n g R a t e_{1} = \frac{l p T o k e n T o t a l S u p p l y_{1}}{p r o v i d e r P o o l S i z e_{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{p r o v i d e r P o o l S i z e}{l p T o k e n T o t a l S u p p l y} = \frac{p r o v i d e r P o o l S i z e - c a l l e r W i t h d r a w}{l p T o k e n T o t a l S u p p l y - b u r n e d L p T o k e n s}

The burned lpTokens and caller withdraw formulas are:

b u r n e d L p T o k e n s = c a l l e r W i t h d r a w * \frac{l p T o k e n T o t a l S u p p l y}{p r o v i d e r P o o l S i z e}

c a l l e r W i t h d r a w = b u r n e d L p T o k e n s * \frac{p r o v i d e r P o o l S i z e}{l p T o k e n T o t a l S u p p l y}

From here, we can state two formulas:

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

l p B u r n R a t e = \frac{l p T o k e n T o t a l S u p p l y}{p r o v i d e r P o o l S i z e}

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

d p W i t h d r a w R a t e = \frac{p r o v i d e r P o o l S i z e}{l p T o k e n T o t a l S u p p l y}

spToken minting

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

\frac{u s e r s P o o l S i z e}{s p T o k e n T o t a l S u p p l y} = \frac{u s e r s P o o l S i z e + u s e r S t a k e}{s p T o k e n T o t a l S u p p l y + m i n t e d S p T o k e n s}

And the formula for minted lpTokens is:

m i n t e d S p T o k e n s = u s e r S t a k e * \frac{s p T o k e n T o t a l S u p p l y}{u s e r s P o o l S i z e}

Where the spToken minting rate is:

s p M i n t i n g R a t e = \frac{s p T o k e n T o t a l S u p p l y}{u s e r s P o o l S i z e}

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

s p M i n t i n g R a t e = \frac{200}{100} = 2

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

m i n t e d S p T o k e n s = s t a k e * s p M i n t i n g R a t e = 100 * 2 = 200 spTokens

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

s p M i n t i n g R a t e = \frac{s p T o k e n T o t a l S u p p l y}{u s e r s P o o l S i z e} = \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{u s e r s P o o l S i z e}{s p T o k e n T o t a l S u p p l y} = \frac{u s e r s P o o l S i z e - c a l l e r W i t h d r a w}{s p T o k e n T o t a l S u p p l y - b u r n e d S p T o k e n s}

The burned spTokens and caller withdraw formulas are:

b u r n e d S p T o k e n s = c a l l e r W i t h d r a w * \frac{s p T o k e n T o t a l S u p p l y}{u s e r s P o o l S i z e}

c a l l e r W i t h d r a w = b u r n e d S p T o k e n s * \frac{u s e r s P o o l S i z e}{s p T o k e n T o t a l S u p p l y}

From here, we can state two formulas:

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

l p B u r n R a t e = \frac{l p T o k e n T o t a l S u p p l y}{p r o v i d e r P o o l S i z e}

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

d p W i t h d r a w R a t e = \frac{p r o v i d e r P o o l S i z e}{l p T o k e n T o t a l S u p p l y}

spToken minting

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

\frac{u s e r s P o o l S i z e}{s p T o k e n T o t a l S u p p l y} = \frac{u s e r s P o o l S i z e + u s e r S t a k e}{s p T o k e n T o t a l S u p p l y + m i n t e d S p T o k e n s}

And the formula for minted lpTokens is:

m i n t e d S p T o k e n s = u s e r S t a k e * \frac{s p T o k e n T o t a l S u p p l y}{u s e r s P o o l S i z e}

Where the spToken minting rate is:

s p M i n t i n g R a t e = \frac{s p T o k e n T o t a l S u p p l y}{u s e r s P o o l S i z e}

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

s p M i n t i n g R a t e = \frac{200}{100} = 2

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

m i n t e d S p T o k e n s = s t a k e * s p M i n t i n g R a t e = 100 * 2 = 200 spTokens

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

s p M i n t i n g R a t e = \frac{s p T o k e n T o t a l S u p p l y}{u s e r s P o o l S i z e} = \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{u s e r s P o o l S i z e}{s p T o k e n T o t a l S u p p l y} = \frac{u s e r s P o o l S i z e - c a l l e r W i t h d r a w}{s p T o k e n T o t a l S u p p l y - b u r n e d S p T o k e n s}

The burned spTokens and caller withdraw formulas are:

b u r n e d S p T o k e n s = c a l l e r W i t h d r a w * \frac{s p T o k e n T o t a l S u p p l y}{u s e r s P o o l S i z e}

c a l l e r W i t h d r a w = b u r n e d S p T o k e n s * \frac{u s e r s P o o l S i z e}{s p T o k e n T o t a l S u p p l y}

From here, we can state two formulas:

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

s p B u r n R a t e = \frac{s p T o k e n T o t a l S u p p l y}{u s e r s P o o l S i z e}

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

d u W i t h d r a w R a t e = \frac{u s e r s P o o l S i z e}{s p T o k e n T o t a l S u p p l y}

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.

Open New Telegram Opportunities

LinkFork is Your Ultimate Social Network Hub on Telegram. Absolutely Free.

Cryptocurrency Calendar

Add Event

Notifier

API

Website Widget

Crypto Marketing

Listing Monitoring

Cashback

Events

Insides

Chat

Twitter

Instagram

Facebook

Introducing DSLA Protocol v.1.0 & the Future of Third-party Risk Management

The Downside of Convenience

DSLA Protocol

Risk Prediction Markets

SLA Contract Types

Reliability Forecasts

Tokenized SLA Positions

Triple Token Model

SLA Staking Rewards

SLA Verification Token Burn

Developer Tools

No Code Tools

Provider Staking Rewards

Users Compensations

DSLA-SP & DSLA-LP Tokens

lpToken minting

lpToken burning

spToken minting

spToken burning

spToken minting

spToken burning

Security Audits & Bug Bounty

About DSLA Protocol

About

Representatives

Developers

Community

Telegram