diff --git a/pages/knowledge-hub/airdrops/azuro-waves/_meta.json b/pages/knowledge-hub/airdrops/azuro-waves/_meta.json index 061f4da6..89638d77 100644 --- a/pages/knowledge-hub/airdrops/azuro-waves/_meta.json +++ b/pages/knowledge-hub/airdrops/azuro-waves/_meta.json @@ -1,4 +1,5 @@ { "overview": "Overview", - "wave1": "Wave #1" + "wave1": "Wave #1", + "wave2": "Wave #2" } diff --git a/pages/knowledge-hub/airdrops/azuro-waves/overview.mdx b/pages/knowledge-hub/airdrops/azuro-waves/overview.mdx index 12a13050..6e0000a6 100644 --- a/pages/knowledge-hub/airdrops/azuro-waves/overview.mdx +++ b/pages/knowledge-hub/airdrops/azuro-waves/overview.mdx @@ -1,15 +1,15 @@ -import { PageHeadline, Formula, Callout } from 'components' +import { Formula, Callout } from 'components' -# The Azuro Waves +# Azuro Waves -Also referred to as “Community Airdrop 2” +The Azuro Waves program is the successor to [Azuro Score](/knowledge-hub/airdrops/azuro-score/overview). -## About the Azuro Waves +## Overview - The distribution of $AZUR will come in Waves and will be 100% linear towards the points accrued by each address. - The Waves program introduces “Levels” which give point multipliers. This means that all points earned by the eligible activities (which will be 100% transparent), will be multiplied by the level in the Wave which you have. - Conditions for next waves may change but changes will never be retroactive. There will always be clarity about how points work and how $AZUR will be distributed from the beginning of each Wave. -**For information about Wave 1, go to [Wave 1](/knowledge-hub/airdrops/azuro-waves/wave1)** +**Wave 2 is currently ongoing. Click [here](/knowledge-hub/airdrops/azuro-waves/wave2) for more information on the program.** diff --git a/pages/knowledge-hub/airdrops/azuro-waves/wave1.mdx b/pages/knowledge-hub/airdrops/azuro-waves/wave1.mdx index fad58b64..0a1429e9 100644 --- a/pages/knowledge-hub/airdrops/azuro-waves/wave1.mdx +++ b/pages/knowledge-hub/airdrops/azuro-waves/wave1.mdx @@ -1,13 +1,13 @@ -import { PageHeadline, Formula, Callout } from 'components' +import { Formula, Callout } from 'components' # Wave #1 - -Start of Wave 1: 11:00:00 UTC June, 26th, 2024 - +- Start of Wave 1 → 11:00:00 UTC June 26th, 2024 +- End of Wave 1 → 23:59:00 UTC November 13th, 2024 +- **Total airdrop reward → 10 million AZUR** -User airdrop reward for Wave 1 = +Airdrop reward per user = \{Total airdrop reward\} * ( \{User wave points\} / \{Total wave points\} ) @@ -15,14 +15,15 @@ User airdrop reward for Wave 1 = | Activity | Formula | | --- | --- | -| [Predictions/betting](https://azuro.org/ecosystem) | Х points = \{Bet sum\} * min( \{Odds\}; 10) / 5
e.g. 1 point = \$2.5 bet at odds of 2 (European odds format) | +| [Placing Bets](https://azuro.org/ecosystem) | Х points = \{Bet sum\} * min( \{Odds\}; 10) / 5
e.g. 1 point = \$2.5 bet at odds of 2 (European odds format) | | [Liquidity Provision](https://azuro.org/app/liquidity) | 1 point = \$400 in LP/day | -| [DEX pair LP](https://azuro.org/app/dex-farming) | 1 point = 400 AZUR in DEX pair/day
1 point = 0.2272 WETH in DEX pair/day
1 point = 80 USDT in DEX pair/day | +| [DEX LP'ing](https://azuro.org/app/dex-farming) | 1 point = 400 AZUR in DEX pair/day
1 point = 0.2272 WETH in DEX pair/day
1 point = 80 USDT in DEX pair/day | | [\$AZUR Staking](https://azuro.org/app/staking)
(excl. unbonding) | 1 point = 400 AZUR staked/day | | Ecosystem support activities | Ad-hoc. To be announced separately whenever such rewards are to become available. | -The points for LP, AZUR staking, and DEX pair LP are awarded once a day. A minimum holding period of 24 hours is required for the deposits to qualify for the points. -The points for predictions/betting are awarded after 100-300 blocks from the time the bet was placed. All bets placed during the Wave are included, regardless of their outcome and resolve date. +All points are credited once a day. A minimum holding period of 24 hours is required for the deposits to qualify for the points. + +Points awarded for betting activity will be credited after 100-300 blocks from the time the bet was placed. All bets placed during the Wave period will be included, even if their outcome and resolve date occurs after the end of the Wave period. ## Points multipliers @@ -30,7 +31,6 @@ The points for predictions/betting are awarded after 100-300 blocks from the tim | Level ID | Level name | Level multiplier | Points needed | | --- | --- | --- | --- | -| 0 | Grey | | 0 | | 0 | Mist | | 0 | | 1 | Sky | x1.1 | 50 | | 2 | Blue | x1.2 | 5 000 | @@ -39,9 +39,9 @@ The points for predictions/betting are awarded after 100-300 blocks from the tim | 5 | Brilliant | x1.6 | 200 000 | | 6 | Royal | x2 | 500 000 | -Your points are multiplied by the multiplier associated with the Level you have, for as long as you have it. +Levels multiplier offer an additional incentive for Azuro's most loyal and active users. Your weekly points will be multiplied by the multiplier associated with your acquired level at that week. The higher your acquired level, the higher your multiplier! -After the completion of the Wave you will keep your Level minus 1 for the next wave. I.e. if your level at the end of the Wave was for example Ultramarine, you will have the Blue level for the next Wave. +Upon the conclusion of each Wave period, your acquired level will move down one tier for the next Wave. For example, if you have the Ultramarine level at the end of Wave 1, then you will start from the Blue level for Wave 2. If you do not see your level in the Waves tab in the Azuro App, make sure to click the ENHANCE button. You can do this at any stage within the Wave. diff --git a/pages/knowledge-hub/airdrops/azuro-waves/wave2.mdx b/pages/knowledge-hub/airdrops/azuro-waves/wave2.mdx new file mode 100644 index 00000000..e50f56a9 --- /dev/null +++ b/pages/knowledge-hub/airdrops/azuro-waves/wave2.mdx @@ -0,0 +1,66 @@ +import { Formula, Callout } from 'components' + +# Wave #2 + +- Start of Wave 2 → 00:00:00 UTC November 18th, 2024 +- End of Wave 2 → 23:59:00 UTC December 25th, 2024 +- **Total airdrop reward → TBC** + + +Airdrop reward per user = +\{Total airdrop reward\} * ( \{User wave points\} / \{Total wave points\} ) + + +## Points rules + +| Activity | Formula | +| --- | --- | +| [Placing Bets](https://azuro.org/ecosystem) | Х points = \{Bet sum\} * min( \{Odds\}; 10) / 5
e.g. 1 point = \$2.5 bet at odds of 2 (European odds format) | +| [Liquidity Provision](https://azuro.org/app/liquidity) | Discontinued | +| [DEX LP'ing](https://azuro.org/app/dex-farming) | Discontinued | +| [\$AZUR Staking](https://azuro.org/app/staking)
(excl. unbonding) | 1 point = 1 000 AZUR staked/day | +| Ecosystem support activities | Ad-hoc. To be announced separately whenever such rewards are to become available. | + +All points are credited once a day. A minimum holding period of 24 hours is required for the deposits to qualify for the points. + +Points awarded for betting activity will be credited after 100-300 blocks from the time the bet was placed. All bets placed during the Wave period will be included, even if their outcome and resolve date occurs after the end of the Wave period. + +## Points multipliers + +### Levels multiplier + +| Level ID | Level name | Level multiplier | Points needed | +| --- | --- | --- | --- | +| 0 | Mist | | 0 | +| 1 | Sky | x1.1 | 100 | +| 2 | Blue | x1.2 | 200 | +| 3 | Ultramarine | x1.3 | 500 | +| 4 | Bright | x1.4 | 1 200 | +| 5 | Brilliant | x1.6 | 2 500 | +| 6 | Royal | x2 | 6 000 | + +In Wave #2, points that count towards levels multiplier can only be earned from AZUR staking. To illustrate, if you have 650 points from AZUR staking and 5 000 points from betting activities, your levels multiplier will be Ultramarine (x1.3). + +Your weekly points will be multiplied by the multiplier associated with your acquired level at that week. The higher your acquired level, the higher your multiplier! + +Upon the conclusion of each Wave period, your acquired level will move down one tier for the next Wave. For example, if you have the Ultramarine level at the end of Wave 1, then you will start from the Blue level for Wave 2. + + +If you do not see your level in the Waves tab in the Azuro App, make sure to click the ENHANCE button. You can do this at any stage within the Wave. +However, if you never do it and the Wave ends - you will not have any Level Multiplier points. + + +### Leaderboard multiplier + +Making it into the weekly leaderboard gives you point multipliers (applicable to the points you generate in that particular week). + +| Weekly leaderboard position | Multiplier | +| --- | --- | +| 1-10 | 2x | +| 11-50 | 1.7x | +| 51-500 | 1.4x | +| 501-1000 | 1.2x | + + +You can [implement Azuro Waves Leaderboard into your UI](https://gem.azuro.org/hub/apps/guides/azuro-waves) + \ No newline at end of file diff --git a/pages/knowledge-hub/azur/azuro-dao.mdx b/pages/knowledge-hub/azur/azuro-dao.mdx index 92eac8d0..c1e1e7b0 100644 --- a/pages/knowledge-hub/azur/azuro-dao.mdx +++ b/pages/knowledge-hub/azur/azuro-dao.mdx @@ -4,14 +4,10 @@ import { Image, Callout } from 'components' AzuroDAO is the protocol’s decentralized autonomous organization, with the mandate of safeguarding smart contract functions and ensuring the protocol’s continual going-concern. In contracts infrastructure, AzuroDAO is the owner of the Factory contract to which a part of the profit share is credited by LP after the completion of each Condition. -In the context of Azuro prediction markets, AzuroDAO plays a critical role of being the arbiter of last resort for disputed event resolutions, as well as to elect qualified data providers into the set. Decisions are congregated and made via onchain voting, where voting power corresponds the amount of staked AZUR and staking duration, specified under [redacted]. +In the context of Azuro prediction markets, AzuroDAO plays a critical role of being the arbiter of last resort for disputed event resolutions, as well as to elect qualified data providers into the set. Decisions are congregated and made via onchain voting, where voting power corresponds the amount of staked AZUR and staking duration, specified under the [redacted] mechanism. As the project scales to steady-state, expect more features to be enshrined into the protocol. AzuroDAO will form the governance backbone of all these features — exact specifications to be disclosed closer to each feature’s release. - -The Schelling point token of AzuroDAO will always be AZUR. There will not be another token for the protocol — in the past, present, or future. - - ## Become a contributor -We are excited to welcome new contributors to Azuro. You can submit your application via this link → https://azuro.typeform.com/contribute +We are excited to welcome new contributors to Azuro. Please submit your application via this link → https://azuro.typeform.com/contribute diff --git a/pages/knowledge-hub/background/a-primer-on-prediction-markets.mdx b/pages/knowledge-hub/background/a-primer-on-prediction-markets.mdx index 2038cd1d..74925fac 100644 --- a/pages/knowledge-hub/background/a-primer-on-prediction-markets.mdx +++ b/pages/knowledge-hub/background/a-primer-on-prediction-markets.mdx @@ -1,3 +1,5 @@ +import { Image } from 'components' + # A Primer on Prediction Markets Prediction markets are fundamentally a simple premise: it is a bidirectional trading market for bettors to express a view over an outcome. diff --git a/pages/knowledge-hub/background/the-bettor-viewer-flywheel.mdx b/pages/knowledge-hub/background/the-bettor-viewer-flywheel.mdx index d9888e96..3acd0a8e 100644 --- a/pages/knowledge-hub/background/the-bettor-viewer-flywheel.mdx +++ b/pages/knowledge-hub/background/the-bettor-viewer-flywheel.mdx @@ -1,17 +1,13 @@ +import { Image } from 'components' + # The Bettor-Viewer Flywheel Betting and prediction markets are not mutually exclusive. Betting volumes contribute to the liquidity stock of a well-functioning prediction market, and the more liquidity is involved in a prediction market, the more accurate its odds will be perceived, since there are more people with skin-in-the-game and more monetary resources at-stake in that said prediction market. An efficient prediction market is the result of two thriving yet distinct user groups feeding off each other: profit-seeking bettors who form the “money base” of the market, and information-curious viewers who form the “attention base” of the market. - - Increased attention helps get prediction markets to the eyes of profit-seeking bettors; - - Bettors place bets against what they deem to be mispriced odds on a prediction market, contributing to that market’s volume and repricing of odds; - - Interested viewers put greater weight on the accuracy of the prediction market due to the increased volumes, increasing attention and attracting more bettors into the mix; - - Bettors place increasingly sized bets against the prediction market’s odds as open interest (OI) grows and the market becomes able to take in top-dollar bets; - - Volumes boom, and viewers increasingly regard the prediction market as the source of truth for that event, further increasing its popularity which attracts more bettor eyeballs; - -- ad infinitum. \ No newline at end of file +- ad infinitum. diff --git a/pages/knowledge-hub/background/the-liquidity-bottleneck.mdx b/pages/knowledge-hub/background/the-liquidity-bottleneck.mdx index e24d7c64..6d4ddc1a 100644 --- a/pages/knowledge-hub/background/the-liquidity-bottleneck.mdx +++ b/pages/knowledge-hub/background/the-liquidity-bottleneck.mdx @@ -1,4 +1,4 @@ -import { Image, Button, Callout } from 'components' +import { Image } from 'components' # The Liquidity Bottleneck diff --git a/pages/knowledge-hub/go-defi/sophon-farm.mdx b/pages/knowledge-hub/go-defi/sophon-farm.mdx index 2f1eb324..50979531 100644 --- a/pages/knowledge-hub/go-defi/sophon-farm.mdx +++ b/pages/knowledge-hub/go-defi/sophon-farm.mdx @@ -1,9 +1,7 @@ -import { PageHeadline, Image, Callout } from 'components' +import { Image, Callout } from 'components' # Sophon Farm -Liquid staking with Sophon farming program - Starting 22nd of August, 2024, AZUR stakers can utilize their stAZUR tokens on Sophon's platform to farm Sophon Points (SP). These points will be converted to SOPH tokens once the Sophon Mainnet goes live and they launch the SOPH token. Staking stAZUR with Sophon allows you to earn double rewards, since staking stAZUR with Sophon is equivalent to holding stAZUR in your wallet. diff --git a/pages/knowledge-hub/go-defi/uniswap-dex-lp.mdx b/pages/knowledge-hub/go-defi/uniswap-dex-lp.mdx index 7d630e63..354971d7 100644 --- a/pages/knowledge-hub/go-defi/uniswap-dex-lp.mdx +++ b/pages/knowledge-hub/go-defi/uniswap-dex-lp.mdx @@ -1,7 +1,11 @@ -import { PageHeadline, Image, Callout } from 'components' +import { Image, Callout } from 'components' ## Uniswap DEX LP + +This program has been discontinued. + + By participating in the DEX LP Incentives program, you can earn rewards distributed over a 90-day period. **Starting at TGE**: 6,000,000 tokens will be allocated over 90 days. diff --git a/pages/knowledge-hub/how-azuro-works/components/virtual-funds.mdx b/pages/knowledge-hub/how-azuro-works/components/virtual-funds.mdx index 8030c6e7..0b5b9784 100644 --- a/pages/knowledge-hub/how-azuro-works/components/virtual-funds.mdx +++ b/pages/knowledge-hub/how-azuro-works/components/virtual-funds.mdx @@ -26,7 +26,7 @@ $$ $$ \text{ where } -\\R \text{ is the Reinfrocement of a Condition, } +\\R \text{ is the Reinforcement of a Condition, } \\sum(bets) \text{ is the sum of bets on all outcomes of a Conidition, } \\max(payout) \text{ is the maximum potential payout to players for a Condition. } $$ diff --git a/pages/knowledge-hub/how-azuro-works/tl-dr.mdx b/pages/knowledge-hub/how-azuro-works/tl-dr.mdx index ae6b67b8..bec82270 100644 --- a/pages/knowledge-hub/how-azuro-works/tl-dr.mdx +++ b/pages/knowledge-hub/how-azuro-works/tl-dr.mdx @@ -44,12 +44,19 @@ $$ Initially, Conditions “book” liquidity from the LP via its Reinforcement (as it represents the Condition’s max potential loss). Assuming \$5M LP TVL (and implied \$200k Reinforcement on this active Condition), Azuro LP’s available capacity now stands at \$4.8M. -Let’s say this Condition (\$200k Reinforcement) accumulates \$500k total bets with a \$150k potential loss. In this case, the Condition’s Virtual Fund is -\$450k (\$200k - \$500k - \$150k). - -Let’s assume that the LP capacity is down to \$1M (the Condition’s \$200k Reinforcement is already part of the “booked” \$4M liquidity). The Condition’s Virtual Fund of -\$450k will now push the capacity further down to \$550k (\$1M - \$450k). +Let’s say this Condition (\$200k Reinforcement) accumulates \$100k total bets with a \$50k max loss. In this case, the Condition’s Virtual Fund is \$50k (\$200k - \$50k - \$100k), which frees up LP capacity from \$4.8M (\$5M-\$200k) to \$4.95M (\$5M-\$50k). Once the LP’s capacity runs out, it is no longer able to service further bets, that is until capacity frees up (from settled Conditions, LP profits from previously settled bets, new LP deposits, etc.). + +In rare cases, Virtual Fund balance may turn negative. This could happen when the Data Provider severely underestimates a market's betting demand and sets the Reinforcement amount too low relative to the market's actual sum of bets. + +For example: +- Assume a Condition has \$200k Reinforcement, \$300k total bets, and \$500k max loss; +- Its resulting Virtual Fund balance will be -\$600k, freeing up LP capacity from \$4.8M (\$5M-\$200k) to \$5.6M (\$5M+\$600k). + + + ## Event resolution and rewards distribution The Data Provider resolves the set of Conditions making up a prediction market, depending on its associated real-world results. Where necessary, [AzuroDAO](/knowledge-hub/azur/azuro-dao) may act as the arbiter of last resort. diff --git a/pages/knowledge-hub/introduction/event-resolution-azuro-dao.mdx b/pages/knowledge-hub/introduction/event-resolution-azuro-dao.mdx index 824528ac..c5fd4b9d 100644 --- a/pages/knowledge-hub/introduction/event-resolution-azuro-dao.mdx +++ b/pages/knowledge-hub/introduction/event-resolution-azuro-dao.mdx @@ -1,7 +1,11 @@ +import { Image } from 'components' + # Event Resolution: AzuroDAO Unlike first-generation prediction markets which burdens the tokenholder base for all event resolutions, Azuro prediction markets operate under a tiered resolution process. -In Azuro, the [Data Provider](/knowledge-hub/how-azuro-works/protocol-actors/data-providers) retains the right to resolve the event in good-faith. The [AzuroDAO](/knowledge-hub/azur/azuro-dao) views data provider resolutions under the “innocent until proven guilty” principle: only when a resolution is disputed, then AzuroDAO may step in as the arbiter of last resort. AZUR will be the Schelling point token in presiding over dispute resolutions, whereby voting power is assigned based on the [redacted] mechanism. +In Azuro, the [Data Provider](/knowledge-hub/how-azuro-works/protocol-actors/data-providers) retains the right to resolve the event in good-faith. The [AzuroDAO](/knowledge-hub/azur/azuro-dao) views data provider resolutions under the “innocent until proven guilty” principle: only when a resolution is disputed, then AzuroDAO may step in as the arbiter of last resort. + +AZUR will be the Schelling point token in presiding over dispute resolutions, whereby voting power is assigned based on the [redacted] mechanism. In the future, Azuro will look to leverage Web Proofs to resolve events directly from its official source (i.e., premierleague.com) to resolve Premier League markets) once Web Proofs become viable enough for practical implementation. diff --git a/pages/knowledge-hub/introduction/lp-utilization-virtual-funds.mdx b/pages/knowledge-hub/introduction/lp-utilization-virtual-funds.mdx index 17f4962a..cfad2437 100644 --- a/pages/knowledge-hub/introduction/lp-utilization-virtual-funds.mdx +++ b/pages/knowledge-hub/introduction/lp-utilization-virtual-funds.mdx @@ -1,7 +1,11 @@ +import { Image } from 'components' + # LP Utilization: Virtual Funds When you place a bet on Azuro prediction markets, you’re effectively putting in liquidity into the market’s underlying [vAMM](/knowledge-hub/how-azuro-works/components/vAMM) (and shifting its onchain odds in the process). This liquidity will remain with the vAMM until the [Condition](/knowledge-hub/how-azuro-works/components/conditions)’s resolution (and the prediction market is dissolved), or until you decide to redeem your position in advance of the resolution[*]. This forms part of a prediction market’s vAMM [Virtual Fund](/knowledge-hub/how-azuro-works/components/virtual-funds) calculation, which is the sum of betting flows and the worst-case max potential loss to the protocol, in excess of [Reinforcement](/knowledge-hub/how-azuro-works/components/reinforcement). Since all concurrent prediction markets share the same [singleton LP](/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers), each needs to check whether there’s sufficient liquidity on the Azuro LP prior to accepting more bets. The capacity of the singleton LP is updated block-by-block in real-time, where it will continue to facilitate more bets from any active prediction market under its umbrella as long as the sum of Virtual Fund balances across all of its currently active vAMMs does not exceed the pool’s own TVL. -Data providers stream sell-side odds and bettors aim to exploit any mispricing of said odds, all the while vAMMs maintain Virtual Fund balances by algorithmically ‘booking’ liquidity from the singleton LP on a block-by-block basis. This is capital-efficiency at its finest: through the elegance of the Virtual Fund accounting system, Azuro prediction markets are autonomously allocated optimal liquidity levels from the singleton LP, without needing sophisticated entities to act as an opinionated market-maker for liquidity provisioning. \ No newline at end of file +Data providers stream sell-side odds and bettors aim to exploit any mispricing of said odds, all the while vAMMs maintain Virtual Fund balances by algorithmically ‘booking’ liquidity from the singleton LP on a block-by-block basis. + +This is capital-efficiency at its finest: through the elegance of the Virtual Fund accounting system, Azuro prediction markets are autonomously allocated optimal liquidity levels from the singleton LP, without needing sophisticated entities to act as an opinionated market-maker for liquidity provisioning. \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/oddsmaking.mdx b/pages/knowledge-hub/introduction/oddsmaking.mdx index fbf14377..1ff9d4c4 100644 --- a/pages/knowledge-hub/introduction/oddsmaking.mdx +++ b/pages/knowledge-hub/introduction/oddsmaking.mdx @@ -1,11 +1,13 @@ +import { Image } from 'components' + # Oddsmaking: Sell-side vs. Buy-side Oddsmaking on Azuro is a race to the bottom: [Data Providers](/knowledge-hub/how-azuro-works/protocol-actors/data-providers) compete for the right to stream odds for certain events. With no custody / legal / operational risk (”cost of trust”) inherent to being an oddsmaker on traditional betting platforms, Azuro Data Providers can be literally anyone with an internet connection: the only prerequisite is to have specialized knowledge in the markets you’re providing odds for, as well as the backing reputation in order to convince [AzuroDAO](/knowledge-hub/azur/azuro-dao) to elect[*] you into the set. -Alas, you get the best possible sell-side odds sourced purely from competition, unbound by the cost of trust. In Azuro, Data Providers are just software service providers, not custodial entities akin to the traditional oddsmaker on a betting platform. This is how the protocol, despite relatively lower levels of activity and TVL when compared to centralized betting behemoths, is still able to offer the best odds for most events. - Just like how social media lowers the barriers of entry and shifts the makeup of information transmitters from entrenched MSMs to any citizen journalist, Azuro lowers the barriers of entry and shifts the makeup of oddsmakers from a few privileged entities entrenched with extensive regulatory moat and banking connections, to anyone of merit possessing specialized knowledge in the field. +Alas, you get the best possible sell-side odds sourced purely from competition, unbound by the cost of trust. In Azuro, Data Providers are just software service providers, not custodial entities akin to the traditional oddsmaker on a betting platform. This is how the protocol, despite relatively lower levels of activity and TVL when compared to centralized betting behemoths, is still able to offer the best odds for most events. + However, the odds derivation process doesn’t end here (else Azuro would just be a betting platform, not a prediction markets protocol). The beauty of Azuro, lies in combining offchain oddsmaking (sell-side odds) with onchain betting flows (buy-side odds): bettors from around the world can come in and place their bets if they feel the sell-side odds are still mispriced. This makes up the buy-side oddsmaking component on Azuro: every bet placed on an outcome will shift the sell-side odds that is originally streamed by the Data Provider, pushing onchain odds to reflect the equilibrium between the Data Provider's opinion and the free market’s opinion. Each Azuro prediction market runs under the vAMM mechanism, which is what gives onchain bettors the ability to shift sell-side odds all the way to the free market equilibrium. \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/pricing-mechanism-azuro-vamms.mdx b/pages/knowledge-hub/introduction/pricing-mechanism-azuro-vamms.mdx index 40bf72c9..d945fe15 100644 --- a/pages/knowledge-hub/introduction/pricing-mechanism-azuro-vamms.mdx +++ b/pages/knowledge-hub/introduction/pricing-mechanism-azuro-vamms.mdx @@ -1,9 +1,17 @@ +import { Image } from 'components' + # Pricing Mechanism: Azuro vAMMs In the context of prediction markets, conventional AMMs used by first-generation protocols require sophisticated entities to hold inventory over its constituent “YES” and “NO” tokens as a byproduct of its initial liquidity bootstrapping process, as well as the active management of said liquidity when the prediction market is live. The Azuro [vAMM](/knowledge-hub/how-azuro-works/components/vAMM) do not require separate bootstrapping instances: they immediately inherit liquidity from the [singleton LP](/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers) on market creation. -Counterintuitively, Azuro data providers do not stream odds via decimal points (or percentages) — they do it by specifying the liquidity bands for each outcome within a [Condition](/knowledge-hub/how-azuro-works/components/conditions). Suppose a Condition ”FullTimeResult” has three outcomes “1X2”: the [Data Provider](/knowledge-hub/how-azuro-works/protocol-actors/data-providers) will first ‘book’ a certain amount of [Reinforcement](/knowledge-hub/how-azuro-works/components/reinforcement) (i.e., \$100k) from the singleton LP, then split it across the three outcomes (i.e.; \$30k on 1; \$50k on X; \$20k on 2). This Reinforcement split is what sets the market’s initial (sell-side) odds: 30%, 50%, and 20%. +Counterintuitively, Azuro data providers do not stream odds via decimal points (or percentages) — they do it by specifying the liquidity bands for each outcome within a [Condition](/knowledge-hub/how-azuro-works/components/conditions). + +Suppose a Condition ”FullTimeResult” has three outcomes “1X2”: +- The [Data Provider](/knowledge-hub/how-azuro-works/protocol-actors/data-providers) will first ‘book’ a certain amount of [Reinforcement](/knowledge-hub/how-azuro-works/components/reinforcement) (i.e., \$100k) from the singleton LP, then split it across the three outcomes (i.e.; \$30k on 1; \$50k on X; \$20k on 2). +- This Reinforcement split is what sets the market’s initial (sell-side) odds: 30%, 50%, and 20%. + +Each Condition is represented as a vAMM. Depending on the number of outcomes in a Condition, the vAMM could be a 2-pool, 3-pool, 4-pool, you name it! -Each Condition is represented as a vAMM. Depending on the number of outcomes in a Condition, the vAMM could be a 2-pool, 3-pool, 4-pool, you name it. When bettors place a bet, they trade one side of the pool, which lowers the odds for the said outcome while increasing the odds of the other outcomes. This self-adjusting price mechanism is similar to conventional AMMs: assuming a 2-pool AMM consisting of \$A and \$B, if a trader buys \$A with \$B, it will push the price of \$A while simultaneously lowering the price of \$B. +When bettors place a bet, they trade one side of the pool, which lowers the odds for the said outcome while increasing the odds of the other outcomes. This self-adjusting price mechanism is similar to conventional AMMs: assuming a 2-pool AMM consisting of \$A and \$B, if a trader buys \$A with \$B, it will push the price of \$A while simultaneously lowering the price of \$B. Each vAMM maintains its own [Virtual Fund](/knowledge-hub/how-azuro-works/components/virtual-funds), in which its balance fluctuates according to the real-time betting flows of its underlying prediction market. \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/the-end-of-impermanent-loss.mdx b/pages/knowledge-hub/introduction/the-end-of-impermanent-loss.mdx index b3ba216a..a4f63010 100644 --- a/pages/knowledge-hub/introduction/the-end-of-impermanent-loss.mdx +++ b/pages/knowledge-hub/introduction/the-end-of-impermanent-loss.mdx @@ -1,4 +1,4 @@ -import { Image, Button, Callout } from 'components' +import { Image, Callout } from 'components' # The End of Impermanent Loss @@ -14,13 +14,13 @@ Therefore, Data Providers are incentivized to price (and reprice) sell-side odds Suppose that a Data Provider is pricing sell-side odds for a football match: - The match is evenly contested, and is now in the 88th minute with a 1-1 scoreline. Onchain probabilities stand at 8-86-6 (8% team A, 86% draw, 6% team B). -- Suddenly, team A scores a goal in the 90th minute, which results in a 2-1 scoreline and could potentially win them the match. Odds abruptly shift from 8-88-6 to 95-4-1 (95% team A, 4% draw, 1% team B). +- Suddenly, team A scores a goal in the 90th minute, which results in a 2-1 scoreline and could potentially win them the match. Odds abruptly shift from 8-86-6 to 95-4-1 (95% team A, 4% draw, 1% team B). If the above happens on other prediction markets, it is virtually certain that LPers will be on the hook and eat losses as a result of the abrupt shift in odds — they won’t be able to pull out their liquidity in time before arbitrageurs swoop in and reprice the odds, to their detriment. -However, due to the privileged position that the Data Provider has on prediction markets they’re pricing for (in addition to being incentivized to maximize their own profits), as soon as the goal happened, the Data Provider will be able to pause markets and front-run bettors to reprice the sell-side odds closer to 95%. +However, due to the privileged position that the Data Provider has on markets they’re pricing for (in addition to being incentivized to maximize their own profits), the Data Provider will be able to pause markets as soon as the goal happens and front-run bettors to reprice the sell-side odds closer to 95%. -Since data providers are also able to set “stop-loss” thresholds to auto-pause markets in the event of extremely abrupt onchain price swings (i.e., 10% swing within three blocks), even if the data provider somehow loses out in speed to onchain arbitrageurs, the maximum loss that they could incur (and by extension, the singleton LP and the protocol) will not exceed their “stop-loss” limit, which is defined before market creation and continuously monitored during when the market is live. +Since data providers are also able to set “stop-loss” thresholds to auto-pause markets in the event of extremely abrupt onchain price swings (i.e., 10% swing within three blocks), even if the data provider somehow loses out in speed to onchain arbitrageurs, the maximum loss that they could incur (and by extension, the singleton LP and the protocol) will not exceed their “stop-loss” limit, which is defined before market creation and always continuously monitored during when the market is live. Effectively, the protocol deliberately throttles the speed to which its onchain odds can move in reaction to an abrupt external catalyst, in favor of protecting the principal of its LPers. Although this may result in slightly lagged repricing of odds (a few seconds), we believe this tradeoff is justified for the sake of maintaining deep and ‘sticky’ liquidity on the singleton LP, ensuring that Azuro prediction markets will always have ample stock of funds to draw upon over the long run. diff --git a/pages/knowledge-hub/introduction/what-is-azuro.mdx b/pages/knowledge-hub/introduction/what-is-azuro.mdx index 3fc8ca98..0b911b86 100644 --- a/pages/knowledge-hub/introduction/what-is-azuro.mdx +++ b/pages/knowledge-hub/introduction/what-is-azuro.mdx @@ -1,8 +1,12 @@ +import { Image } from 'components' + # What Is Azuro? Azuro is a decentralized protocol for prediction markets. Unlike most of its industry peers, Azuro does not use the orderbook model as the mechanism underpinning its prediction markets, opting for a dynamic AMM-based approach under a singular concentrated liquidity pool model. -With its innovative [vAMM](/knowledge-hub/how-azuro-works/components/vAMM) mechanism and the [LiquidityTree](/knowledge-hub/how-azuro-works/liquidity-tree) fund accounting system, prediction markets are seeded by Azuro’s singleton pool — free and open for anyone to participate as an LP. All Azuro prediction markets inherit the full might of Azuro’s [singleton LP](/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers), allowing each to scale (and service bets) to the ‘true’ demand levels of its underlying event — up to the pool’s capacity. +Utilizing [vAMMs](/knowledge-hub/how-azuro-works/components/vAMM) and the [LiquidityTree](/knowledge-hub/how-azuro-works/liquidity-tree) fund accounting system, all prediction markets on Azuro inherit the full might of Azuro's singleton LPs. This allows each market to 'book' liquidity and scale (and service bets) in an unconstrained manner, up to the **entire** capacity of the pool. + +Anyone can be an [LP](/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers) on Azuro: simply choose a preferred pool and deposit your funds. When LP'ing on Azuro, you're automatically exposed to all prediction markets that are seeded by the pool you're LP'ing in, allowing you to passively earn stablecoin yield off the betting activity from all of these markets. In addition, Azuro apps compete with each other to offer [bettors](/knowledge-hub/how-azuro-works/protocol-actors/bettors) with the best interface and user experience. Anyone in the world can spin-up a front-end, connect to the protocol, and facilitate bets — there is no designated canonical app that could be Azuro’s single point-of-failure. @@ -17,4 +21,4 @@ The Azuro project is made up of three separate yet interconnected branches: - **AzuroSDK:** Web components that make it quick & easy to build applications on Azuro Protocol. Betting interfaces are only one of the many instances of apps on Azuro. -- **AzuroDAO:** A decentralized system to govern the Azuro Protocol at steady-state. AZUR will serve as the Schelling point token, operating under vsAZUR tokenomics. +- **AzuroDAO:** A decentralized system to govern the Azuro Protocol at steady-state. AZUR will serve as the Schelling point token, operating under the [redacted] mechanism. diff --git a/public/images/concepts/a-primer-on-pm.png b/public/images/concepts/a-primer-on-pm.png new file mode 100644 index 00000000..e6b92dac Binary files /dev/null and b/public/images/concepts/a-primer-on-pm.png differ diff --git a/public/images/concepts/bettor-viewer-flywheel.png b/public/images/concepts/bettor-viewer-flywheel.png new file mode 100644 index 00000000..61ffb6ff Binary files /dev/null and b/public/images/concepts/bettor-viewer-flywheel.png differ diff --git a/public/images/concepts/end-of-impermanent-loss-1.png b/public/images/concepts/end-of-impermanent-loss-1.png new file mode 100644 index 00000000..a681481c Binary files /dev/null and b/public/images/concepts/end-of-impermanent-loss-1.png differ diff --git a/public/images/concepts/end-of-impermanent-loss-2.png b/public/images/concepts/end-of-impermanent-loss-2.png new file mode 100644 index 00000000..f2d4a0d1 Binary files /dev/null and b/public/images/concepts/end-of-impermanent-loss-2.png differ diff --git a/public/images/concepts/event-resolution.png b/public/images/concepts/event-resolution.png new file mode 100644 index 00000000..98752989 Binary files /dev/null and b/public/images/concepts/event-resolution.png differ diff --git a/public/images/concepts/lp-utilization.png b/public/images/concepts/lp-utilization.png new file mode 100644 index 00000000..70863f1e Binary files /dev/null and b/public/images/concepts/lp-utilization.png differ diff --git a/public/images/concepts/oddsmaking1.png b/public/images/concepts/oddsmaking1.png new file mode 100644 index 00000000..ec4585c5 Binary files /dev/null and b/public/images/concepts/oddsmaking1.png differ diff --git a/public/images/concepts/oddsmaking2.png b/public/images/concepts/oddsmaking2.png new file mode 100644 index 00000000..c5550604 Binary files /dev/null and b/public/images/concepts/oddsmaking2.png differ diff --git a/public/images/concepts/pricing-mechanism.png b/public/images/concepts/pricing-mechanism.png new file mode 100644 index 00000000..9d9794a7 Binary files /dev/null and b/public/images/concepts/pricing-mechanism.png differ diff --git a/public/images/concepts/what-is-azuro.png b/public/images/concepts/what-is-azuro.png new file mode 100644 index 00000000..95096382 Binary files /dev/null and b/public/images/concepts/what-is-azuro.png differ