$BEPRO
This article outlines the use-cases, technical specifications, and reasons for the existence of the $BEPRO token.
Last updated
This article outlines the use-cases, technical specifications, and reasons for the existence of the $BEPRO token.
Last updated
ERC20 tokens on the market normally constitute different types of assets, values or use-cases for different types of protocols (when they exist) or dependency factors in different types of technologies.
Regarding information about the $BEPRO token, we had this information spread across Medium Posts, direct answers to community members, and documentation of the protocol (technical oriented). Therefore, we decided to create a centralised place to understand WHY the $BEPRO token exists, and WHY Bepro Network as a whole would never work in a decentralized manner without it. In short, $BEPRO works as a utility token inside the Protocol(s) of which are the ONLY way to ensure decentralization and financial stability over the protocol's assets.
In this post we will break down the various use-cases for $BEPRO by showing its utilities and functions in securing the network.
We recommend taking a look into The Bepro.Network, Why The Bepro.Network?before reading the information below so that you can fully grasp the protocol and product
After understanding the full use-case and flow of actions on the Protocol, you will find that certain key actions require Council members to create proposals for distributions of rewards.
After a bounty has left the draft time, there is no way to remove the bounty value from the network - Assuring that the value is locked to be distributed to the developer after a proposal has been created by a Council Member.
Only council members, members who have locked 25M $BEPRO on the network, can propose bounty distributions for the developer who took part in the bounty/hackathon development, taking a 3% fee if their proposal is the selected proposal to close the bounty, and generating Active Income for certain $BEPRO holders in the protocol(s).
For a bounty to be closed and distributed, it can't have been disputed and has to be open for more than three days. This ensures proposal compliance as any other council member can just as easily dispute a proposal and open a suitable one, by using their locked $BEPRO.
This action in legacy marketplaces such as Fiverr is taken from a central authority that works as an intermediary who takes custody of those funds for a period of time as well as takes a direct fee by doing it, thus creating a full dependency on their platform. This without an ERC20 token that works as an oracle would never be possible (see example below).
Examples Let's consider $1k for the development of a specific function in a Smart Contract.
The question now becomes: How possible is it for a Council Member to try to hijack the protocol and use its custody solution on the protocol to ensure all the payments would go to themselves? The answer is in financial incentives and general token value.
Example
| Bounty Payment | Fee (3%) | Cost of +25M $BEPRO | Active Return (%) |
|---|---|---|---|
Here represents a stability service for the token to ensure the correlation on the Protocol TVL and its safety correlated with the $BEPRO value, a utility token to ensure decentralized custody of the protocol.
The usage of the Protocol from a white-label perspective "costs" 1M $BEPRO.
Given that the 1M $BEPRO is locked in the NetworkFactory.sol and is always available for redemption by the owner allows this "stake" to show as a utility from the technology created at Bepro.Network, decentralizing its future incentives and democratic distribution perspectives in the long term.
The operator stakes $1M BEPRO to use the white-label infrastructure and can redeem the $1M when he wants, but with one caveat - he can only redeem his 1M $BEPRO once his white-label has no amount of ERC20s in Bounties nor in Curation Tokens ($BEPRO) - ensuring that while it is being used (the software), the 1M $BEPRO staked ensures its usage.
More information on this soon (See roadmap)
Since Bepro-js represents a showcase of the usage of 2) implemented to Bepro.Network directly, we decided to deploy the protocol using only $BEPRO as the only ERC20 available (implemented in the Bepro Network Protocol v1).
This works as an experiment to ensure development use case between developers of the ecosystem and distribution of $BEPRO between several developers. This creates a growth/ecosystem incentive to incentivize the growth of 2), while making developers know $BEPRO, hold $BEPRO and decide to know more about the ecosystem by ultimately understanding how the BEPRO Protocol can be used for its own financial incentives. $BEPRO ultimately represents the currency used by some organizations to pay TAIKAI Labs for previous development over bepro-js and other SDKs, which end up using the Protocol to process these payments.
To conclude, $BEPRO is the way to extend the life of Bepro.Network after TAIKAI Labs' acquisition for the next 5 years. It forms the bridge between the now and when the network will achieve full decentralization, while preserving use-cases and utilities for the network, bepro-js, white-labels, and its tools.
See more at https://development.bepro.network
The Bepro Protocol, as mentioned at Protocol Workflow has a number of variables that should be updated every time new triggers from the outside world change: the $BEPRO token price, the amount of councils in existence, and other events that should prompt value changes in the Protocol's variables. This is to ensure stability and financial incentives for the use of the Network/Product.
For v2 the variables of
25M $BEPRO for council (Amount of $BEPRO required)
3% Fee for distributions (Fee set for distributions)
1M $BEPRO for stake to white-label (Amount of $BEPRO required)
and more..
All these variables will be set via Protocol Variables Governance Processes where $BEPRO holders will handle protocol variables updates in a similar fashion as used in Compound
1,000€
30€
25,000€
0.12%
10,000€
300€
25,000€
1.2%
100,000€
3K€
25,000€
12%