Merge pull request #267 from Azuro-protocol/devrel1

upd concepts

pages/concepts/how-azuro-works/components/_meta.json

@@ -1,5 +1,5 @@
 {
-  "betting-engines": "Prediction Engines",
+  "betting-engines": "Betting Engines",
   "conditions": "Conditions",
   "reinforcement": "Reinforcement",
   "pools": "Pools",

pages/concepts/how-azuro-works/components/betting-engines.mdx

@@ -1,6 +1,6 @@
-# Prediction Engines
+# Betting Engines
 
-A Prediction Engine (aka Betting Engine) is a collective term for contracts that encompass the logic of creating [Conditions](/concepts/protocol/conditions),
+A Betting Engine is a collective term for contracts that encompass the logic of creating [Conditions](/concepts/protocol/conditions),
 accepting bets, computing payouts for bets, and calculating [Affiliate](/concepts/basic/affiliates) [rewards](/concepts/basic/rewards).
 
 These contracts are plugged into the [Pool](/concepts/protocol/pools) by its owner via the [Factory](/contracts/factory),

pages/concepts/how-azuro-works/protocol-actors/apps.mdx

@@ -1,31 +1,16 @@
-import { Card } from 'components'
+import { Card, Callout } from 'components'
 
 
-# Frontends (Affiliates)
+# Apps (Frontends)
 
-Frontends can be apps, widgets, tools, integrations or even standalone products which use the liquidity provided by liquidity pools created on Azuro solution and deliver a UI for users to interact with. While some frontends can copy exisiting products and create new UIs with localization & specialization, more sophisticated developers can go further and create new products altogether, building new pools and other overlays on top of Azuro's infrastructure and underlying liquidity.
+Apps can be interfaces, widgets, tools, integrations or even standalone products that connects to the protocol and has a UI for users to interact with. While some apps can copy exisiting products and create new interfaces with localized and/or specialized features, sophisticated developers can go further and create new products altogether, building new pools and other overlays on top of the protocol’s suite of smart contracts.
 
-In the simplest example (i.e. a prediction app like [bookmaker.XYZ](https://bookmaker.xyz)) - by integrating Azuro - the frontend gains opportunity to access the liquidity pools created on the basis of Azuro solution, outsource risk management, and may simply focus on interactions with Users and development of UX.
+In the case of [bookmaker.XYZ](https://bookmaker.xyz/) (a betting interface), the app instantly inherits all markets (with its underlying liquidity) that are hosted via Azuro smart contracts, and may simply focus on user acquisition and UI/UX improvements.
 
-Frontend operators [earn a % of the profits](/concepts/basic/rewards) realized by the [Pools](/concepts/protocol/pools)
-(from the part associated with their own users' activity). Each Frontend Operator provides their address to the smart
-contract with their users' bets and the [LP](/contracts/lp) contract distributes part of the profits to the frontend address.
+Apps [earn a % of the profits](https://gem.azuro.org/concepts/how-azuro-works/protocol-actors/rewards) realized by the [Pools](https://gem.azuro.org/concepts/how-azuro-works/components/pools) (from the part associated with their own users' activity). Apps will provide their addresses to allow the protocol to link it with their users' bets, allowing the [LP contract](https://gem.azuro.org/contracts/lp) to distribute part of generated protocol revenue to the given address.
 
-Frontend operators have the ability to choose which markets to display on their app. They can select from the list of supported conditions live on the protocol and remove events that are not needed.
+Apps have the ability to choose which markets to display on their app. They can select from the list of supported conditions live on the protocol and remove events that are not needed.
 
----
-
-For a list with live Frontends check: [azuro.org/ecosystem](https://azuro.org/ecosystem).
-
-Despite the fact that the [Azuro DAO](/concepts/governance/overview) has no control over whoever connects their front-end
-platforms with the Azuro Protocol, the Azuro DAO encourages front-end operators who intend to do so to comply with
-any laws applicable to the operation of such platforms.
-
-The Azuro DAO expressly disclaims any liability for the activity of front-end operators who connect their platform with Azuro.
-
-<div className="mt-8">
-  <Card
-    title="Build own frontend"
-    to="/hub"
-  />
-</div>
+<Callout type="warning">
+AzuroDAO encourages apps to comply with any laws applicable to the jurisdictions they’re under. We expressly disclaim any liability in relation to the activities of any app connected to the protocol, as we have no control over the operations of said apps.
+</Callout>

pages/concepts/how-azuro-works/protocol-actors/bettors.mdx

@@ -1,12 +1,14 @@
 import { PageHeadline, Callout } from 'components'
 
-<PageHeadline
-  title="Players"
-  subTitle="Predicting powered by Azuro is non-custodial - instead transacting directly with the smart-contracts."
-/>
+# Bettors (Players)
 
-Players can access the markets via websites, apps or widgets (known as "Frontends") that connect to Azuro to deliver services to end users.
-An up-to-date list with frontends can be found here: [azuro.org/ecosystem](https://azuro.org/ecosystem)
+Bets on Azuro are non-custodial — you interact directly with smart contracts.
+
+Bettors can access Azuro markets via websites, interfaces, or widgets (known as "Apps") that connect to Azuro to deliver services to end-users.
+
+Bettors play an important role towards the functioning of Azuro prediction markets. Profit-motivated bettors seek out mispricings of sell-side odds (pushed by the Data Provider) across Azuro prediction markets, and place bets against it — adjusting onchain odds back to market equilibrium in the process.
+
+Betting volume is what drives accurate probabilities of prediction markets — no bettors, no volume, no functioning prediction market.
 
 <Callout type="info">
   When accessing markets supported by Azuro, players do not need to make deposits or withdrawals. Although the UX/UI on

pages/concepts/how-azuro-works/protocol-actors/data-providers.mdx

@@ -1,16 +1,24 @@
+import { Callout } from 'components'
+
 # Data Providers
 
-A Data Provider is an entity connected to the Azuro Protocol to create and cancel events, create, resolve or cancel [Conditions](/concepts/protocol/conditions) and update the odds. Data Providers are the entities ensuring there are Conditions to predict on, and that the probabilities for these conditions are such that the pool generates a profit from the predicting over time.
+The Data Provider is an entity connected to the protocol with the responsibility to create and cancel events, as well as update (or reprice) sell-side odds. Data Providers ensure that there are Conditions to predict on, and that the probabilities for these conditions are such that the pool generates a profit from the predicting over time.
+
+When creating a new Condition, the Data Provider sets the following:
+
+Total Reinforcements for each condition and the respective outcomes
+
+Margin for each condition/outcomes, thus setting the odds
+
+For its services, the Data Provider receives a share of the profit that is due to the Pool. It can be either the Pool owner or any other address, for additional security.
 
-At the time of creation of Conditions the Data Provider sets:
-1. Total virtual [reinforcements](/concepts/protocol/reinforcement) for each condition and the respective outcomes
-2. Margin for each condition/outcomes thus setting the [odds](/concepts/protocol/odds)
+In contracts infrastructure, the Data Provider is represented as an address to which a part of the profit share is credited by LP after the completion of each Condition.
 
-The Data Provider receives a share of the profit that is due to the [Pool](/concepts/protocol/pools). It can be either the Pool owner or any other address, for additional security.
+Currently, the Data Provider is also responsible for resolving Conditions in good-faith, with AzuroDAO acting as the arbiter of last resort in case of disputes. For instance, Pinnacle (one of Azuro’s Data Providers) has published an extensive document outlining the general rules to which it intends to use as a basis to resolve markets (https://www.pinnacle.com/en/future/betting-rules).
 
-In contracts infrastructure, the Data Provider is represented as an address to which a part of the profit share
-[is credited](/concepts/basic/rewards) by [LP](/contracts/lp) after the completion of each Condition.
+Data Providers are required to put up collateral up to the total Reinforcement amount that they expect to use for the pricing of sell-side odds across involved prediction markets.
 
-When it comes to resolving the Conditions, the Data Provider on Azuro follows a certain set of rules, derived from one of the most reputable established sports-betting data sources (https://www.pinnacle.com/en/future/betting-rules).
 
-It is envisioned that there may be multiple data providers active on Azuro at a later stage, therefore these rules may change, evolve, or vary depending on the data provider in the future.
+<Callout type="feature">
+Currently, data providers are still permissioned due to the critical nature of the role. Once the protocol reaches a certain level of maturity, we aim to open up the data provider role to the free market — permissionless data providers elected via AzuroDAO.
+</Callout>

pages/concepts/how-azuro-works/protocol-actors/liquidity-providers.mdx

@@ -2,22 +2,22 @@ import { Callout } from 'components'
 
 # Liquidity Providers
 
-Providing liquidity into one of Azuro's [pools](/concepts/protocol/pools) exposes the LP to virtually all prediction markets supported by the
-respective pool. It's an opportunity to get 1-click exposure to thousands of prediction markets.
+Providing liquidity into one of Azuro's [pools](https://gem.azuro.org/concepts/how-azuro-works/components/pools) exposes the LP to all prediction markets supported by the pool — one-click exposure to thousands of markets, concurrently.
 
-The liquidity pools earn through the spread embedded in the [odds](/concepts/protocol/odds) which players can predict. The profit of the
-liquidity pool is the difference between the tokens seeded from the pool into the [Conditions](/concepts/protocol/conditions) and the tokens
-returned to the pool after those Conditions are resolved.
+The liquidity pools earn through the spread embedded in the odds (sell-side) which players can bet on. The profit of the liquidity pool is the difference between the tokens seeded from the pool into the Conditions and the tokens returned to the pool after those Conditions are resolved.
 
-The more players and predicting there is on the protocol - the higher the likelihood the pool is profitable.
-I.e. - the longer the duration of each LP's position - the higher the likelihood that it yields positive return.
+The more bet volumes serviced by the pool, the higher the likelihood that the pool is profitable. And the longer the duration of an LP's position, the higher the likelihood that it yields a positive return.
 
-Azuro DAO does not control the liquidity pools nor has any interest in liquidity pools. Azuro DAO simply provides technical measures for indefinite number of users of cryptocurrency to create liquidity pools and add liquidity to already created one.
+AzuroDAO has no control over the LP, nor holds any interest in the LP. We simply develop the infrastructure to allow users to create new LPs and add liquidity to existing LPs.
 
 **APR is calculated in two steps:**
 1. The daily returns are determined by dividing the total rewards received by liquidity pool for resolved events within a day by the volume of the liquidity pool at the end of that day.
 2. The daily returns are then annualized for a one-year period.
 
+<Callout type="feature">
+Visit the [Azuro Portal](https://app.azuro.org/) to provide liquidity.
+</Callout>
+
 <Callout type="alert">
   **RISKS:**
 - There is a significant chance that liquidity positions held under a week will be in the red (in the negative).

pages/concepts/how-azuro-works/rewards.mdx

@@ -1,33 +1,38 @@
 import { Callout, Formula } from 'components'
 
-# Rewards
+# Reward Distribution
 
+The term "reward" within Azuro protocol refers to the fee of the Pool's profit that is distributed to those who contribute to its operation.
 
-The term "reward" within Azuro protocol refers to the fee of the [Pool](/concepts/protocol/pools)'s profit that is distributed to those who contribute to its operation.
+Currently, there are 4 types of contributors in the Pool, each entitled to rewards from protocol revenue: Liquidity Providers (LPs), Data Providers, Apps, and AzuroDAO.
 
-Currently, there are 4 types of contributors in the Pool, each with a corresponding reward: [Liquidity Providers](/contracts/lp) reward, [Data Providers](/concepts/basic/data-providers) reward, [Affiliates](/concepts/basic/affiliates) reward, [Azuro DAO](/concepts/azuro-dao/overview) reward.
+## LPs and Data Providers
 
-### Liquidity and Data Providers
+For LPs and Data Providers, after the completion of each [Condition](/concepts/how-azuro-works/components/conditions), the profit or loss of the pool is multiplied by the reward rate (20% and 10% respectively) and added to the contributor reward balance.
 
-For LPs and Data Providers, after the completion of each [Condition](/concepts/protocol/conditions), the profit or loss of the pool is multiplied by the reward rate (20% and 10% respectively) and added to the contributor reward balance.
+## Apps (Frontends)
 
-### Affiliates (Frontends)
-
-Affiliates' (Frontends) reward is paid monthly, separately for each chain.
+Apps' reward is paid monthly, separately for each chain.
 
 <Formula>
 $$
-\begin{array}{r l}
-\text{Affiliate Reward} &= 70\% \times \text{Affiliate Revenue} \\
-&\left(\text{but not higher than the Spread Reward Cap}\right)
+\begin{array}{c}
+\textit{AppReward} = 70\% \times \textit{AppRevenue} \\
+\textit{SpreadRewardCap} = 50\% \times \textit{Spread} \times \textit{BetSize} \\
 \end{array}
 $$
 </Formula>
 
-- **Affiliate Revenue** = Monthly Pool Revenue (preditctions made minus winnings) via the Affiliate address
-- **Spread Reward Cap** = (50% of Spread)*(Prediction Size) for all predictions (aka bets) associated with the affiliate address, resolved in the calendar month
-- **Spread** = The spread (aka vig, aka margin) for each particular bet
-- **Prediction size** = The amount (in respective cryptocurrency) of each particular prediction
+<Formula>
+$$
+\begin{array}{c}
+\text{where} \\
+\textit{AppReward} \text{ is not higher than } \textit{SpreadRewardCap}, \\
+\textit{Spread} \text{ is the vig (aka margin) for each particular bet,} \\
+\textit{BetSize} \text{ is the amount (aka wagered cryptocurrency) of each particular bet.}
+\end{array}
+$$
+</Formula>
 
 
 ### DAO