deWeb Architecture

The deWeb Framework consists of three core components: User Authentication, Royalty Distribution and Token Engine.

 

User Authentication

This component handles the following:

User Sign-Up & Sign-In

Users create virtual accounts on EOS mainnet

Social sign-in support for all major social platforms and SMS

Users are associated to Marketers via the domain they use to sign-up

Interoperability

Support for cross-Operator and cross-Marketer transactions

Marketers

Configure their domains:

Language

deApps

Marketers are associated to Operators based on their domains

Account recovery

Marketers can recover accounts for users 

Operators can recover accounts for Marketers

Users can migrate between Marketers

Marketers can migrate between Operators

Royalty Engine

Every deApp needs a source of revenue. When revenue is received, it gets passed to the royalty engine and immediately gets divided between deWeb, Developers, the Operator and the Marketer that provided service to the user.

For example:

In this case, the revenue generated will be split:
30% to the three developers
20% to the Operator
45% to the Marketer 
5% deWeb

deWeb takes a 5% royalty for use of the deWeb Framework

The Operator selected by the Marketer charges 20% royalties

The Marketer leverages three deApps which charge 10% royalties each for a total of 30%

A Marketer running a service charges a fee from their customers 

 

Token Engine

The Token Engine is both a stand-alone deApp as well as a core module that can be used by other deApps. It currently enables:

Issuing Bancor Liquid Tokens on EOS with a USDB stablecoin reserve - at no cost to the token issuer

Buying/Selling tokens using credit cards, EOS, BTC, ETH, LTC and more

Transferring tokens between users

Token holder directories

Setting token weekly allowance:

If the allowance is off (set to 0%) then the token price will remain stable at $1

If the allowance is on (for example set to 2%) then:

The token will emit 2% of the reserve on a weekly basis, generating a recurring source of income to the token issuer. The income is subject to fees that are processed by the Royalty Engine and paid to service providers.

There are two ways value can get passed from the token to the Royalty Engine:

Burn

When a token is burned, the USDB stable coin in reserve gets passed to the Royalty Engine.

Allowance

As allowance removed value from the reserve, that reserve gets passed to the Royalty Engine.

 

Token Engine deApp

The Token Engine is both a stand-alone deApp as well as a core module that can be used by other deApps. It currently enables:

Tokens

There are currently three types of tokens available for creation.

Stable

Reserve is always 100%.  Value gets passed to the Royalty Engine via token burn.

Dynamic

Token starts with 100% reserve in stable token.  Reserve ratio goes down over time based on allowance. As the reserve ratio goes down, excess reserve gets passed to the Royalty Engine.

Beneficiary

Tokens created by one person where another person is defined as the beneficiary and allowance is sent to the beneficiary either to a known crypto address (on any major chain) or via Twitter.

How it Works

All user generated tokens are built leveraging the Bancor Protocol for liquidity.
They all begin with a 100% reserve in USDB stable token. Each token creator determines the allowance of their token.

The allowance is the amount that is withdrawn from the token reserve and sent to the royalty engine for distribution between deWeb, Developers, Operators and Marketers per week.

Bancor formula:

Price

=

Reserve Balance

Smart Token's Total Supply

*

Reserve Ratio

For Example

JAN, 1

Alice makes a token for her podcast. She selects to have a 10% allowance, meaning 10% of the reserve is sent to the royalty engine each week. She adds two deApps, one for an easy to use smartphone wallet and one for a highly rated voting system.  When making the token, the domain is owned by Marketer 2 who uses the infrastructure of Operator 4. The deApps charge 1% and .5% royalties, respectively. The Operator charges 2% and the Marketer charges 1.75%.

Price:

$1

Reserve Balance:

0

Supply:

0

Reserve Ratio:

100%

Market Cap:

0

10%

Allowance:

JAN, 1

Minutes later, Bill buys $1000 worth of Alice's token as he wants the right to vote for the future guests of the show.

Price:

$1

Reserve Balance:

$1000

Supply:

1000

Reserve Ratio:

100%

$1000

Market Cap:

Allowance:

10%

10% of the value ($100) is removed from the reserve and processed by the Royalty Engine and made available to deWeb, the Developers, the Operator, the Marketer,  and the Token Creator. Alice gets 90% of the royalties and uses it to support the creation of her podcast.

JAN, 8 

Price:

$1

Reserve Balance:

$900

Supply:

1000

Reserve Ratio:

90%

Market Cap:

$1000

Allowance:

10%

Now that one week has passed the reserve ratio is 90%. Bill buys another $1000 worth of Alice’s token. This pushes the price from $1 to $1.0776.

JAN, 8 

Price:

$1.0776

Reserve Balance:

$1900

Supply:

1,959.1152

Reserve Ratio:

90%

Market Cap:

$2111.1425

Allowance:

10%

How Allowance Gets Processed by the Royalty Engine

$100 is removed from the reserve and distributed as outlined below:

$90

Token Creator Alice

$1.75

Marketer 2

$1.5

Operator 4

$1 

Developer 1,

$.5

Developer 2

$5

Token Engine

$0.25

deWeb.io

 
 

Use Cases

deWeb’s power comes from cooperation.  Any deApp that has a revenue model and can benefit from additional developers and marketers can benefit from deWeb.

Thomas Wants to Build an Online Retro Themed Arcade

As the Core Developer, Thomas codes the basic functionality of his favorite retro games like Pac-Man, Donkey Kong and Pinball. 

Thomas is likely to use the fiat in/out deApp and the deApp that allows him to send tokens via Twitter.  Other developers can convert their retro games into deApps that Thomas can use for a fee as well.

Operators will host the code and ensure the deApp is available. Marketers will customize and onboard users. For example, one Marketer may translate the website into Chinese as a customization.

As revenue is earned it gets processed by the Royalty Engine and is distributed immediately based on the set fees of each service provider in the chain.

Rena Wants to Build a Social Network

As the Core Developer, Rena codes the basic functionality of a social network. Rena is likely to use the voting deApp.  Other developers may also create deApps, such as TikTok style features, and make those available for a fee.

Operators can host the code and ensure the deApp is available. Marketers can customize it and onboard users. For example, a marketer may customize the UI to have larger text to target an elderly market.

As revenue is earned it gets processed by the Royalty Engine and is distributed immediately based on the set fees of each service provider in the chain.

Amanda Wants to Build a Fantasy Sports deApp

As the Core Developer, Amanda codes the basic functionality of a fantasy sports deApp.

Amanda is likely to use the fiat in/out and Token Engine deApps.  There may also be other developers who can create support for more sports.

Operators can host the code and ensure the deApp is available. Marketers can customize and onboard users. For example, a Marketer may choose to only display cricket and change the language to best serve their specific fantasy sports community.

As revenue is earned it gets processed by the Royalty Engine and is distributed immediately based on the set fees of each service provider in the chain.

voice.png