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.