diff --git a/pages/hub/apps/get-started.mdx b/pages/hub/apps/get-started.mdx index 7ae04cb1..56958a35 100644 --- a/pages/hub/apps/get-started.mdx +++ b/pages/hub/apps/get-started.mdx @@ -1,6 +1,9 @@ import { Button, Card, Image } from 'components' ## Getting Started +> Explore beyond the easy path; your creativity is the only limit. +> +> Whichever path you choose, you’ll have our liquidity pools, smart contract logic, and risk management to back you up. *Explore beyond the easy path; your creativity is the only limit. Whichever path you choose, you’ll have our liquidity pools, smart contract logic, and risk management to back you up.* ### Choose your path @@ -11,7 +14,7 @@ import { Button, Card, Image } from 'components' text="

- Low-code option

- Prerequisites: Git, Node.js

-

- Result: basic dApp with access to on-chain data in less than a day.

" +

- Result: basic dApp with access to onchain data in less than a day.

" to="https://gem.azuro.org/hub/apps/get-started#-quick-start" /> - Result: basic dApp in less than a day with access to onchain data and broad customization opportunities.

" to="https://gem.azuro.org/hub/apps/sdk/overview" /> - Result: any Azuro app (betting interfaces, bots, game engines, DAOs, etc.).

" to="guides/advanced/overview" /> diff --git a/pages/hub/index.mdx b/pages/hub/index.mdx index 2399602a..5665feb8 100644 --- a/pages/hub/index.mdx +++ b/pages/hub/index.mdx @@ -16,7 +16,7 @@ As an onchain prediction layer, Azuro offers a modular smart contract infrastruc
### 🔮 For applications - *Set up Azuro in your project to tap into our liquidity pools and streamlined risk management.* + *Set up your app to connect to Azuro protocol, inheriting the full might of our singleton LP's liquidity with robust oracle feeds.* 👉 [Getting Started](hub/apps/get-started) @@ -31,7 +31,7 @@ As an onchain prediction layer, Azuro offers a modular smart contract infrastruc
### 🧩 For blockchains - *Azuro brings real-world data, users and transaction volumes that are achievable only in gaming to your blockchain.* + *Unlock a new vertical in prediction markets for your chain. Start the integration process and connect to Azuro within two weeks.* 👉 [Getting Started](hub/blockchains/get-started) @@ -44,4 +44,6 @@ As an onchain prediction layer, Azuro offers a modular smart contract infrastruc --- -Read about [Azuro integrations](/cases/overview) to get inspired 👉 + + Explore past Azuro integration [case studies](/cases/overview) to get inspired! + \ No newline at end of file diff --git a/pages/index.mdx b/pages/index.mdx index 3a7ac1e3..3241693f 100644 --- a/pages/index.mdx +++ b/pages/index.mdx @@ -1,4 +1,4 @@ -import { Button, Card } from 'components' +import { Card } from 'components' # Welcome to Azuro Docs 📘 @@ -10,7 +10,7 @@ Azuro is a decentralized protocol for prediction markets, providing tooling & in +
- -**Mission:** To reinvent the opaque betting industry of today as an open-for-all public good, onchain. - - +**Mission:** To reinvent the opaque betting industry of today as a public good, *onchain*. + **Vision:** To become the global hub for price discovery and the origin of betting lines — the people’s authoritative source for real-time probabilities across major world events. diff --git a/pages/knowledge-hub/additional/_meta.json b/pages/knowledge-hub/additional/_meta.json index 06783e2c..65e8fe3b 100644 --- a/pages/knowledge-hub/additional/_meta.json +++ b/pages/knowledge-hub/additional/_meta.json @@ -1,5 +1,4 @@ { - "faqs": "FAQs", "landscape": "Competitive Landscape", "brand-assets": "Brand Assets", "glossary": "Glossary" diff --git a/pages/knowledge-hub/additional/faqs/contracts.mdx b/pages/knowledge-hub/additional/faqs/contracts.mdx deleted file mode 100644 index 9f1e8d70..00000000 --- a/pages/knowledge-hub/additional/faqs/contracts.mdx +++ /dev/null @@ -1,27 +0,0 @@ -# Contracts - -## What is LiquidityTree? - -LiquidityTree is Azuro’s novel fund accounting system that tracks the balance changes of Virtual Funds across all prediction markets in real-time, block-by-block. - -It forms the backbone of Azuro — facilitating open deposits and unrestricted withdrawals to/from the LP, setting capacity for each prediction market to draw or ‘book’ liquidity from the LP, etc. - -## What is Reinforcement? - -Reinforcement is a measure of the maximum potential loss that the singleton LP can suffer from a particular prediction market. It also represents the initial liquidity base upon creation of a prediction market, set by the responsible data provider with sell-side odds push authority. - -## What is Virtual Fund? - -Virtual Fund is a measure of virtual balances attributed to a prediction market. From the perspective of the singleton LP, the Virtual Fund balance of a prediction market corresponds to the amount of ‘booked’ liquidity that the prediction market draws upon from the LP. - -## What is vAMM? - -Virtual AMM (vAMM) is Azuro’s self-adjusting pricing mechanism on top of pushed sell-side odds from the data provider. Similar to conventional AMMs, vAMMs will shift the onchain odds of a prediction market depending on betting flows coming from bettors. - -## How is protocol revenue distributed? - -The protocol involves three actors when facilitating a bet: apps, LP, and the data provider. - -Apps are entitled to 70% of all generated revenue serviced from their interface (subject to Spread Reward Cap). The singleton LP takes 20% of protocol revenue, while the data provider takes the remaining 10%. AzuroDAO currently does not take any protocol revenue. - -Reward distribution percentages are not fixed. In the future, AzuroDAO will be able to turn on the fee switch and adjust the percentages across each protocol actor. \ No newline at end of file diff --git a/pages/knowledge-hub/additional/landscape.mdx b/pages/knowledge-hub/additional/landscape.mdx index f2c72d12..6df7d8f8 100644 --- a/pages/knowledge-hub/additional/landscape.mdx +++ b/pages/knowledge-hub/additional/landscape.mdx @@ -1,15 +1,17 @@ # Competitive Landscape -| Text | Polymarket | Drift BET | SX Network | Stake.com / Rollbit / Shuffle | **Azuro** | +| 🌊 | Polymarket | Drift BET | SX Network | Stake.com / Rollbit / Shuffle | *Azuro* | |----------------------------------|-----------------------------------|---------------------------------|-------------------------------|-------------------------------|-------------------------------------| -| **Market types** | Politics, exotic, prices, sports | Politics, exotic, sports | Sports, casino, prices, exotic, politics | Casino, sports | ***Sports, politics, exotic*** | -| **Business model** | B2C | B2C | B2B2C | B2C | ***B2B2C*** | -| **Deployment** | Polygon | Solana | SX Chain | Offchain | ***Polygon, Gnosis, Chiliz*** | -| **Custody model** | Non-custodial | Non-custodial | Non-custodial | Custodial | ***Non-custodial*** | -| **Access model** | Singular interface | Singular interface | Singular interface | Singular interface | ***Multiple interfaces*** | -| **Betting flow** | Peer-to-peer | Peer-to-peer | Peer-to-peer | Centralized | ***Peer-to-pool*** | -| **Market creation** | Centralized | Centralized | Permissionless | Centralized | ***Permissionless*** | -| **Mechanism design** | CLOB | CLOB | CLOB | Proprietary | ***vAMM*** | -| **Primary liquidity source** | Centralized market-makers | Centralized market-makers | Public liquidity\* | Proprietary | ***Public liquidity*** | -| **Liquidity provision** | Active | Active | Active | Proprietary | ***Passive*** | -| **Resolution process** | UMA, Polymarket | Drift security council | Market creator, chain validators | Internal | ***Data provider, AzuroDAO*** | +| **Market types (ranked)** | Politics, exotic, sports | Politics, exotic, sports | Sports, casino, exotic, politics | Casino, sports | *Sports, politics, exotic* | +| **Business model** | B2C | B2C | B2B2C | B2C | *B2B2C* | +| **Deployment** | Polygon | Solana | SX Chain | Offchain | *Polygon, Gnosis, Chiliz* | +| **Custody model** | Non-custodial | Non-custodial | Non-custodial | Custodial | *Non-custodial* | +| **Access model** | Singular interface | Singular interface | Singular interface | Singular interface | *Multiple interfaces* | +| **Betting structure** | Peer-to-peer | Peer-to-peer | Peer-to-peer | Proprietary | *Peer-to-pool* | +| **Market creation** | Centralized | Centralized | Permissionless | Centralized | *Permissionless\** | +| **Mechanism design** | CLOB | CLOB | CLOB | Proprietary | *vAMM* | +| **Primary liquidity source** | Market-makers | Market-makers | Onchain\* | Proprietary | *Onchain* | +| **Liquidity provision** | Active | Active | Active | Proprietary | *Passive* | +| **Resolution process** | UMA, Internal | Internal | Market creator | Internal | *Data provider, AzuroDAO\** | + +*\*not yet fully implemented* \ No newline at end of file diff --git a/pages/knowledge-hub/azur/_meta.json b/pages/knowledge-hub/azur/_meta.json index ae42509e..e2799e9f 100644 --- a/pages/knowledge-hub/azur/_meta.json +++ b/pages/knowledge-hub/azur/_meta.json @@ -1,5 +1,5 @@ { "tokenomics": "Tokenomics", - "redacted": "[redacted]", + "st-azur": "stAZUR", "azuro-dao": "AzuroDAO" } \ 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 afbbbb71..92eac8d0 100644 --- a/pages/knowledge-hub/azur/azuro-dao.mdx +++ b/pages/knowledge-hub/azur/azuro-dao.mdx @@ -1,4 +1,4 @@ -import { PageHeadline, Image, Callout } from 'components' +import { Image, Callout } from 'components' # AzuroDAO diff --git a/pages/knowledge-hub/azur/redacted/_meta.json b/pages/knowledge-hub/azur/redacted/_meta.json deleted file mode 100644 index bb81c90b..00000000 --- a/pages/knowledge-hub/azur/redacted/_meta.json +++ /dev/null @@ -1,3 +0,0 @@ -{ - "overview": "What is [redacted]" - } \ No newline at end of file diff --git a/pages/knowledge-hub/azur/redacted/overview.mdx b/pages/knowledge-hub/azur/redacted/overview.mdx deleted file mode 100644 index e85cde56..00000000 --- a/pages/knowledge-hub/azur/redacted/overview.mdx +++ /dev/null @@ -1,3 +0,0 @@ -# What is [redacted] - -[redacted] is Azuro’s tokenized incentivization scheme, governed by AZUR stakers with apps as the primary beneficiary. The system aims to foster a thriving app-centric Azuro economy, where apps are rewarded based on their perceived merit to the protocol’s long-term success. \ No newline at end of file diff --git a/pages/knowledge-hub/go-defi/st-azur.mdx b/pages/knowledge-hub/azur/st-azur.mdx similarity index 72% rename from pages/knowledge-hub/go-defi/st-azur.mdx rename to pages/knowledge-hub/azur/st-azur.mdx index c979fed3..cbd972a7 100644 --- a/pages/knowledge-hub/go-defi/st-azur.mdx +++ b/pages/knowledge-hub/azur/st-azur.mdx @@ -1,13 +1,13 @@ -import { PageHeadline, Image, Callout } from 'components' +import { Image, Callout } from 'components' -# Azuro stAZUR +# stAZUR -Staking AZUR signals your commitment to Azuro. By staking AZUR, you’ll be eligible to earn an estimated ~22% APY, starting 24 Jun 2024 until the end of the staking period. The duration of the staking period is not announced ahead of time. +Staking AZUR signals your commitment to Azuro. By staking AZUR, you’ll be eligible to earn staking yield, starting 24 Jun 2024 until the end of the staking period. The duration of the staking period is not announced ahead of time. Further details to be disclosed closer to the end of the staking period. -Staking rewards are generated off the overall value that is accrued to the Azuro ecosystem. They are not derived off new emissions from the uncirculated AZUR supply. +Staking rewards are denominated in AZUR, and are generated from protocol revenue attributable to AzuroDAO. They are a form of real yield, and are not derived off new emissions from the uncirculated AZUR supply. When staking AZUR, users will receive stAZUR, our liquid staking token that can be used on partner platforms to gain additional rewards from our partners. diff --git a/pages/knowledge-hub/azur/tokenomics.mdx b/pages/knowledge-hub/azur/tokenomics.mdx index 32dcdfa2..63fe947e 100644 --- a/pages/knowledge-hub/azur/tokenomics.mdx +++ b/pages/knowledge-hub/azur/tokenomics.mdx @@ -1,4 +1,4 @@ -import { PageHeadline, Image, Callout } from 'components' +import { Image, Callout } from 'components' # Tokenomics diff --git a/pages/knowledge-hub/introduction/azuroscan.mdx b/pages/knowledge-hub/azuroscan.mdx similarity index 84% rename from pages/knowledge-hub/introduction/azuroscan.mdx rename to pages/knowledge-hub/azuroscan.mdx index 67fa08a3..00701e51 100644 --- a/pages/knowledge-hub/introduction/azuroscan.mdx +++ b/pages/knowledge-hub/azuroscan.mdx @@ -8,8 +8,6 @@ It will be Azuro’s front-facing onchain prediction markets explorer, allowing We envision Azuroscan to be your gateway to world events, driven by Azuro prediction markets. Uncover insights, analyze trends, view historical odds, see betting flows, etc. — all in one place! -What Etherscan is for Ethereum, is what Azuroscan will be for Azuro. - -**Azuroscan →** coming sewn. +**Azuroscan →** coming soon \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/background/_meta.json b/pages/knowledge-hub/background/_meta.json similarity index 100% rename from pages/knowledge-hub/introduction/background/_meta.json rename to pages/knowledge-hub/background/_meta.json diff --git a/pages/knowledge-hub/introduction/background/a-primer-on-prediction-markets.mdx b/pages/knowledge-hub/background/a-primer-on-prediction-markets.mdx similarity index 100% rename from pages/knowledge-hub/introduction/background/a-primer-on-prediction-markets.mdx rename to pages/knowledge-hub/background/a-primer-on-prediction-markets.mdx diff --git a/pages/knowledge-hub/introduction/background/crossing-the-chasm.mdx b/pages/knowledge-hub/background/crossing-the-chasm.mdx similarity index 100% rename from pages/knowledge-hub/introduction/background/crossing-the-chasm.mdx rename to pages/knowledge-hub/background/crossing-the-chasm.mdx diff --git a/pages/knowledge-hub/introduction/background/prediction-markets-v1.mdx b/pages/knowledge-hub/background/prediction-markets-v1.mdx similarity index 84% rename from pages/knowledge-hub/introduction/background/prediction-markets-v1.mdx rename to pages/knowledge-hub/background/prediction-markets-v1.mdx index 241d98db..87c15741 100644 --- a/pages/knowledge-hub/introduction/background/prediction-markets-v1.mdx +++ b/pages/knowledge-hub/background/prediction-markets-v1.mdx @@ -10,6 +10,6 @@ Initial liquidity is seeded to the AMM by an entity (e.g., market makers) — th ## CLOB -Advances made in blockchain scalability (and proving capabilities) results in the renaissance of the onchain CLOB model. In the case of prediction markets, each event has their own orderbook where participants may place bid/ask orders to trade YES and NO tokens. +Advances made in blockchain scalability (and proving capabilities) results in the renaissance of the centralized orderbook (CLOB) model. In the case of prediction markets, each event has their own orderbook where participants may place bid/ask orders to trade YES and NO tokens. Market makers are employed to make liquidity for each orderbook-based prediction market, and price movements will depend on betting flows with regards to liquidity: the more liquidity market-makers dedicate to the orderbook, the less sensitive prices will change per dollar of flow. \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/background/the-bettor-viewer-flywheel.mdx b/pages/knowledge-hub/background/the-bettor-viewer-flywheel.mdx similarity index 100% rename from pages/knowledge-hub/introduction/background/the-bettor-viewer-flywheel.mdx rename to pages/knowledge-hub/background/the-bettor-viewer-flywheel.mdx diff --git a/pages/knowledge-hub/introduction/background/the-liquidity-bottleneck.mdx b/pages/knowledge-hub/background/the-liquidity-bottleneck.mdx similarity index 100% rename from pages/knowledge-hub/introduction/background/the-liquidity-bottleneck.mdx rename to pages/knowledge-hub/background/the-liquidity-bottleneck.mdx diff --git a/pages/knowledge-hub/additional/faqs/_meta.json b/pages/knowledge-hub/faqs/_meta.json similarity index 100% rename from pages/knowledge-hub/additional/faqs/_meta.json rename to pages/knowledge-hub/faqs/_meta.json diff --git a/pages/knowledge-hub/additional/faqs/betting.mdx b/pages/knowledge-hub/faqs/betting.mdx similarity index 69% rename from pages/knowledge-hub/additional/faqs/betting.mdx rename to pages/knowledge-hub/faqs/betting.mdx index b1cd7753..0b844e9e 100644 --- a/pages/knowledge-hub/additional/faqs/betting.mdx +++ b/pages/knowledge-hub/faqs/betting.mdx @@ -7,6 +7,7 @@ Go to the Azuro [app page](https://azuro.org/ecosystem). Find your preferred app ## I don’t have crypto. Wat do? Onramp via reputable CEXs like Binance or Coinbase. Else, you can onramp directly via Metamask, or through fiat onramp partners of the app that you’ve chosen. + Some apps support social-based authentication (login with Google / Facebook / etc.) as well as gasless transactions (no gas token required to place bets). Check with respective apps for specific implementation and user flow guide. ## I won my bet. How to redeem? @@ -15,9 +16,6 @@ All bets on Azuro are direct interactions with the smart contract. The app that ## Bets take forever to resolve. Am I doomed? -On average, Azuro bets resolve within two hours of the event’s end time. If it’s been two hours since the event ended and your bets have not resolved, raise the issue on our Discord. - -Data providers manage a lot of markets, so there might be times when their infrastructure can’t keep up with the load (especially considering the early stages of the Azuro project). But rest assured, your funds are safe — they are locked on smart contracts, not held by the data provider nor any other entity. - - +On average, Azuro bets resolve within two hours of the event’s end time. If it’s been two hours since the event ended and your bets have not resolved, please raise the issue on our [Discord](https://discord.gg/azuro). +[Data Providers](/knowledge-hub/how-azuro-works/protocol-actors/data-providers) manage a lot of markets, so there might be times when their infrastructure can’t keep up with the load (especially considering the early stages of the project). But rest assured, your funds are SAFU — they are locked on smart contracts, not held by the Data Provider nor any other entity. diff --git a/pages/knowledge-hub/faqs/contracts.mdx b/pages/knowledge-hub/faqs/contracts.mdx new file mode 100644 index 00000000..35c020ab --- /dev/null +++ b/pages/knowledge-hub/faqs/contracts.mdx @@ -0,0 +1,27 @@ +# Contracts + +## What is LiquidityTree? + +[LiquidityTree](/knowledge-hub/how-azuro-works/liquidity-tree) is Azuro’s novel fund accounting system that tracks the balance changes of Virtual Funds across all prediction markets in real-time, block-by-block. + +It forms the backbone of Azuro — facilitating open deposits and unrestricted withdrawals to/from the LP, setting capacity for each prediction market to draw or ‘book’ liquidity from the LP, etc. + +## What is Reinforcement? + +[Reinforcement](/knowledge-hub/how-azuro-works/components/reinforcement) is a measure of the maximum potential loss that the singleton LP can suffer from a particular prediction market. It also represents the initial liquidity base upon creation of a prediction market, set by the responsible Data Provider with sell-side odds push authority. + +## What is Virtual Fund? + +[Virtual Fund](/knowledge-hub/how-azuro-works/components/virtual-funds) is a measure of virtual balances attributed to a prediction market. From the perspective of the singleton LP, the Virtual Fund balance of a prediction market corresponds to the amount of ‘booked’ liquidity that the prediction market draws upon from the LP. + +## What is vAMM? + +The [vAMM](/knowledge-hub/how-azuro-works/components/vAMM) (Virtual AMM) is Azuro’s self-adjusting pricing mechanism on top of pushed sell-side odds from the data provider. Similar to conventional AMMs, vAMMs will shift the onchain odds of a prediction market depending on betting flows coming from bettors. + +## How is protocol revenue distributed? + +The protocol involves three actors when facilitating a bet: apps, LP, and the Data Provider. + +Apps are entitled to 70% of all generated revenue serviced from their interface (subject to Spread Reward Cap). The singleton LP takes 20% of protocol revenue, while the Data Provider takes the remaining 10%. AzuroDAO currently does not take any protocol revenue. + +[Reward Distribution](/knowledge-hub/how-azuro-works/reward-distribution) percentages are not fixed, and may be subject to further changes if deemed necessary by AzuroDAO. diff --git a/pages/knowledge-hub/additional/faqs/general.mdx b/pages/knowledge-hub/faqs/general.mdx similarity index 59% rename from pages/knowledge-hub/additional/faqs/general.mdx rename to pages/knowledge-hub/faqs/general.mdx index 63a5f8c9..8501daf1 100644 --- a/pages/knowledge-hub/additional/faqs/general.mdx +++ b/pages/knowledge-hub/faqs/general.mdx @@ -10,17 +10,17 @@ Stake.com is a centralized betting platform that leverages crypto as a payment r Azuro is simply a set of smart contracts that you interact with to place your bets. Your funds will only leave your possession at the moment of bet placement — you hold your own crypto, secured by your own private key. -Events are resolved by the data provider, while AzuroDAO acts as the arbiter of last resort in case of disputes. Data providers are unable to cherry-pick resolutions for each betting slip — if an event is resolved as YES, all YES bets on that event will immediately resolve to TRUE. This protects bettors from discriminatory resolutions on select huge wins or parlays, an occurrence that has always been a problem in the traditional betting industry. +Events are resolved by the [Data Provider](/knowledge-hub/how-azuro-works/protocol-actors/data-providers), while [AzuroDAO](/knowledge-hub/azur/azuro-dao) acts as the arbiter of last resort in case of disputes. Data Providers are unable to cherry-pick resolutions for each betting slip — if an event is resolved as YES, all YES bets on that event will immediately resolve to TRUE. This protects bettors from discriminatory resolutions on select huge wins or parlays, an occurrence that has always been a problem in the traditional betting industry. -In addition, since voting power is determined based on AZUR staked amount and its staking duration, AzuroDAO will largely consist of long-term AZUR stakers that are aligned with the success of the protocol. This mostly ensures that by virtue of sheer game-theory, last resort resolutions that are presided over by AzuroDAO will always be truthful and non-arbitrary. +In addition, since voting power is based on the [redacted] mechanism, AzuroDAO will largely consist of long-term AZUR stakers that are aligned with the success of the protocol. This mostly ensures that by virtue of sheer game-theory, last resort resolutions that are presided over by AzuroDAO will always be truthful and non-arbitrary. ## How does Azuro compare to Polymarket? Polymarket is a prediction markets platform based on the CLOB model. Individual markets are created by the team, and liquidity on each market is supplied by a combination of Polymarket’s designated market-makers and user-incentivized top-of-book orders. Bets are placed via the canonical Polymarket interface, and the aggregation of bets form Polymarket’s view on an event’s probabilities. -Azuro is a protocol for prediction markets, utilizing a singleton LP model. Azuro markets are hosted by the data provider, who pushes sell-side odds for bettors to bet against. Liquidity is drawn from the unified singleton LP, powered by LiquidityTree. Bettors move sell-side odds with their betting flows (buy-side odds), and the resulting onchain odds reflect Azuro’s view on an event’s probabilities. Azuro’s singleton LP profits if the applied spread from the data provider’s sell-side odds is more than the degree of mispricing that is exploited onchain by bettor flows. +Azuro is a protocol for prediction markets, utilizing a [singleton LP](/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers) model. Azuro markets are hosted by the Data Provider, who pushes sell-side odds for bettors to bet against. Liquidity is drawn from the unified singleton LP, powered by [LiquidityTree](/knowledge-hub/how-azuro-works/liquidity-tree). Bettors move sell-side odds with their betting flows (buy-side odds), and the resulting onchain odds reflect Azuro’s view on an event’s probabilities. Azuro’s singleton LP profits if the applied spread from the data provider’s sell-side odds is more than the degree of mispricing that is exploited onchain by bettor flows. -Azuro’s use of data providers as benevolent sophisticated entities (elected by AzuroDAO) allows Azuro prediction markets to cover fast-paced events with non-binary outcomes (i.e., sports), as well as markets with relatively niche interest (since liquidity is inherited from the singleton LP instead of needing to be separately bootstrapped for each prediction market). +Azuro’s use of Data Providers as benevolent sophisticated entities (elected by AzuroDAO) allows Azuro prediction markets to cover fast-paced events with non-binary outcomes (i.e., sports), as well as markets with relatively niche interest (since liquidity is inherited from the singleton LP instead of needing to be separately bootstrapped for each prediction market). Azuro does not maintain a canonical betting interface. Bettors place bets by choosing from one of Azuro’s third-party apps that are connected to the open-source protocol. This ensures that the protocol is able to scale access globally (as each app caters to their own respective localities, customs, and jurisdictional laws), while simultaneously removing the risk of having a single point-of-failure access point. @@ -32,6 +32,6 @@ By implementing all betting logic in form of smart contracts, we eliminate the n ## What is Azuroscan? -Azuroscan is a non-betting interface geared towards information-curious viewers. It indexes rich onchain data that is generated from using the protocol, and displays such data in an easy-to-digest format to casual non-betting viewers. +[Azuroscan](/knowledge-hub/azuroscan) is a non-betting interface geared towards information-curious viewers. It indexes rich onchain data that is generated from using the protocol, and displays such data in an easy-to-digest format to casual non-betting viewers. -We aim to have Azuroscan to be the gateway for people to search and discover the real-time probabilities of various world events, powered by Azuro prediction markets driven by onchain activity and betting volume. +We aim to have Azuroscan to be the gateway for people to search and discover the real-time probabilities of various world events, driven by onchain activity and betting volume on Azuro prediction markets. diff --git a/pages/knowledge-hub/additional/faqs/lping.mdx b/pages/knowledge-hub/faqs/lping.mdx similarity index 55% rename from pages/knowledge-hub/additional/faqs/lping.mdx rename to pages/knowledge-hub/faqs/lping.mdx index ccf30665..cb42d88e 100644 --- a/pages/knowledge-hub/additional/faqs/lping.mdx +++ b/pages/knowledge-hub/faqs/lping.mdx @@ -6,15 +6,15 @@ Head over to [Azuro Portal](http://app.azuro.org/). Find your preferred pool (sp ## How is the displayed APY calculated? -It is based on the pool’s historical performance. This is why you’ll see different pools showing different yields, as it is dependent on the pool’s own supplied amount of liquidity as well as the performance of bettors where the pool is the counterparty. +It is based on the pool’s historical performance. This is why you will see different pools showing different yields, as it is dependent on the pool’s own supplied amount of liquidity as well as the performance of bettors in which the pool is the counterparty. -Past performance doesn’t indicate future results. +Do note that past performance doesn’t indicate future results. ## Why is my LP position showing negative? -All new deposits experience an initial negative skew. This is to counteract attempts to game the system. Most LP positions return a positive yield within a month’s time. +All new deposits experience an initial negative skew. This is to counteract attempts to game the [LiquidityTree](/knowledge-hub/how-azuro-works/liquidity-tree) fund accounting system. -However, there’s a non-zero likelihood that the pool could experience extended bettor performance, which may prolong the time of which your position will be in the red. +Most LP positions return a positive yield within a month’s time. However, there’s a non-zero likelihood that the pool could experience extended bettor performance, which may prolong the time of which your position will be in the red. Although withdrawals can be made at any point past the initial 7-day lock period, we recommend depositing liquidity to the LP only if you have a long time horizon (more than 3 months). We cannot guarantee profitability on your LP position — DYOR and ape responsibly! diff --git a/pages/knowledge-hub/go-defi/_meta.json b/pages/knowledge-hub/go-defi/_meta.json index 366cedde..b58eb389 100644 --- a/pages/knowledge-hub/go-defi/_meta.json +++ b/pages/knowledge-hub/go-defi/_meta.json @@ -1,5 +1,4 @@ { - "st-azur": "Azuro stAZUR", "uniswap-dex-lp": "Uniswap DEX LP", "sophon-farm": "Sophon Farm" } \ No newline at end of file diff --git a/pages/knowledge-hub/how-azuro-works/components/odds.mdx b/pages/knowledge-hub/how-azuro-works/components/odds.mdx index 3e4caf31..6d8ccb98 100644 --- a/pages/knowledge-hub/how-azuro-works/components/odds.mdx +++ b/pages/knowledge-hub/how-azuro-works/components/odds.mdx @@ -1,9 +1,6 @@ -import { PageHeadline, Formula } from 'components' +import { Formula } from 'components' - +# Odds Odds represent the probability of a particular outcome in a Condition actually happening. The odds for each outcome of a [Condition](/knowledge-hub/how-azuro-works/components/conditions) are determined as the ratio of the total Condition funds to the funds of diff --git a/pages/knowledge-hub/how-azuro-works/components/vAMM.mdx b/pages/knowledge-hub/how-azuro-works/components/vAMM.mdx index 35e477ea..23914d84 100644 --- a/pages/knowledge-hub/how-azuro-works/components/vAMM.mdx +++ b/pages/knowledge-hub/how-azuro-works/components/vAMM.mdx @@ -1,6 +1,6 @@ import { Callout, Formula } from 'components' -# vAMM +# vAMM (Virtual AMM) The total volume of Virtual Funds does not always match the real fund of the Condition. When a player places a bet, the ratio of Virtual Funds changes. This self-adjusting pricing mechanism is Azuro’s vAMM. 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 1dc75b45..8030c6e7 100644 --- a/pages/knowledge-hub/how-azuro-works/components/virtual-funds.mdx +++ b/pages/knowledge-hub/how-azuro-works/components/virtual-funds.mdx @@ -1,9 +1,6 @@ -import { PageHeadline, Formula } from 'components' +import { Formula } from 'components' - +# Virtual Funds In CoreBase-based smart contracts, the probability of each outcome within a [Condition](/knowledge-hub/protocol/conditions) is stored in the form of Virtual Funds of outcomes. diff --git a/pages/knowledge-hub/how-azuro-works/liquidity-tree.mdx b/pages/knowledge-hub/how-azuro-works/liquidity-tree.mdx index f8fd57f0..29853d3e 100644 --- a/pages/knowledge-hub/how-azuro-works/liquidity-tree.mdx +++ b/pages/knowledge-hub/how-azuro-works/liquidity-tree.mdx @@ -2,7 +2,7 @@ import { Callout, Image } from 'components' # LiquidityTree -LiquidityTree is a novel data structure based on Segment Tree, tailored to facilitate efficient liquidity provision across multiple active **Conditions** from a unified singleton liquidity pool. +LiquidityTree is a novel data structure based on Segment Tree, tailored to facilitate efficient liquidity provision across multiple active [Conditions](/knowledge-hub/how-azuro-works/components/conditions) from a unified singleton liquidity pool. It is a gas-light mechanism to correctly track the balance changes of individual LPs — float management of active concurrent markets as well as P&L attribution from multiple market resolutions, while at the same time allowing for live deposit and withdrawals. @@ -14,7 +14,7 @@ It is a gas-light mechanism to correctly track the balance changes of individual Deposits and withdrawals will initialize the next unused sequential leaf node. As this is essentially creating a new onchain entry, these transactions are relatively gas-intensive. -However, deposits and withdrawals happen sporadically — the bulk of LP balance changes come from the Reinforcement and Virtual Fund of each active Condition. To avoid overloading the Azuro LP with transactions on every block (and consuming insane amounts of gas), we follow a deferred lazy update approach — balance changes arising from Conditions are merely annotated on the top/parent node, and is only applied “for real” when an individual LP wants to withdraw (to be executed together with the withdrawal transaction). This saves the need to update individual LP balances on every block from each Condition’s Virtual Fund changes (or its resolution). +However, deposits and withdrawals happen sporadically — the bulk of LP balance changes come from the Reinforcement and [Virtual Fund](/knowledge-hub/how-azuro-works/components/virtual-funds) of each active Condition. To avoid overloading the Azuro LP with transactions on every block (and consuming insane amounts of gas), we follow a deferred lazy update approach — balance changes arising from Conditions are merely annotated on the top/parent node, and is only applied “for real” when an individual LP wants to withdraw (to be executed together with the withdrawal transaction). This saves the need to update individual LP balances on every block from each Condition’s Virtual Fund changes (or its resolution). ### General Concept diff --git a/pages/knowledge-hub/how-azuro-works/protocol-actors/apps.mdx b/pages/knowledge-hub/how-azuro-works/protocol-actors/apps.mdx index 6b55a4c1..e75958bf 100644 --- a/pages/knowledge-hub/how-azuro-works/protocol-actors/apps.mdx +++ b/pages/knowledge-hub/how-azuro-works/protocol-actors/apps.mdx @@ -3,14 +3,18 @@ import { Card, Callout } from 'components' # Apps (Frontends) -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. +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 existing 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 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. + +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. + + +--- + Apps [earn a % of the profits](https://gem.azuro.org/knowledge-hub/how-azuro-works/rewards) realized by the [Pools](https://gem.azuro.org/knowledge-hub/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. 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. - - -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. - \ No newline at end of file diff --git a/pages/knowledge-hub/how-azuro-works/protocol-actors/bettors.mdx b/pages/knowledge-hub/how-azuro-works/protocol-actors/bettors.mdx index 57c8b763..482ef25a 100644 --- a/pages/knowledge-hub/how-azuro-works/protocol-actors/bettors.mdx +++ b/pages/knowledge-hub/how-azuro-works/protocol-actors/bettors.mdx @@ -1,18 +1,17 @@ -import { PageHeadline, Callout } from 'components' +import { Callout } from 'components' # Bettors (Players) -Bets on Azuro are non-custodial — you interact directly with smart contracts. +Bettors can access Azuro markets via websites, interfaces, or widgets (aka apps) that connect to Azuro to deliver services to end-users. -Bettors can access Azuro markets via websites, interfaces, or widgets (known as "Apps") that connect to Azuro to deliver services to end-users. +When accessing markets supported by Azuro, players *typically* do not need to make deposits or withdrawals (with the exception of custodial apps). The intended use of Azuro's markets is such that players' funds and winnings can remain in their possession at all times – each bet is a transaction that interacts directly with Azuro smart contracts. Once the game finishes players just need to claim their winnings from the smart contract (if bets are won). -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. + +Do note that apps connected to the protocol are distinct and separate entities from AzuroDAO. We cannot be held responsible for the loss of funds arising from interacting with malicious wallets, websites, apps, or interfaces. Bettors are encouraged to DYOR! + -Betting volume is what drives accurate probabilities of prediction markets — no bettors, no volume, no functioning prediction market. +--- - - When accessing markets supported by Azuro, players do not need to make deposits or withdrawals. Although the UX/UI on - frontends is not overseen by Azuro - the intended use of Azuro's markets is such that players' funds and winnings can - remain in their possession at all times. Such is the case when each prediction is a transaction with the smart-contract. - Once the game finishes players just need to claim their winnings from the smart contract (if their prediction won). - +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](/knowledge-hub/how-azuro-works/protocol-actors/data-providers)) across Azuro prediction markets and place bets against it, adjusting onchain odds back to the free market equilibrium in the process. + +Betting volume is what drives accurate probabilities in the first place. No bettors, no volume, no functioning prediction markets. \ No newline at end of file diff --git a/pages/knowledge-hub/how-azuro-works/protocol-actors/data-providers.mdx b/pages/knowledge-hub/how-azuro-works/protocol-actors/data-providers.mdx index f0c840ab..4511cc9d 100644 --- a/pages/knowledge-hub/how-azuro-works/protocol-actors/data-providers.mdx +++ b/pages/knowledge-hub/how-azuro-works/protocol-actors/data-providers.mdx @@ -22,5 +22,5 @@ Data Providers are required to put up collateral up to the total [Reinforcement] -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. +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 public and enable permissionless data providers (elected by AzuroDAO). diff --git a/pages/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers.mdx b/pages/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers.mdx index f8574cf4..b0803130 100644 --- a/pages/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers.mdx +++ b/pages/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers.mdx @@ -4,41 +4,36 @@ import { Callout } from 'components' Providing liquidity into one of Azuro's [pools](https://gem.azuro.org/knowledge-hub/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 (sell-side)](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/odds) which players can bet on. The profit of the liquidity pool is the difference between the tokens seeded from the pool into the [Conditions](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/conditions) and the tokens returned to the pool after those Conditions are resolved. +Azuro LPs earn through the spread embedded in sell-side [odds](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/odds) pushed by Data Providers, which players can bet on. The profit of the liquidity pool is the difference between the tokens seeded from the pool into the [Conditions](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/conditions) and the tokens returned to the pool after those Conditions are resolved. -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. + +Visit the [Azuro Portal](https://app.azuro.org/) to provide liquidity. + -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. +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. **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. - -Visit the [Azuro Portal](https://app.azuro.org/) to provide liquidity. - - **RISKS:** -- There is a significant chance that liquidity positions held under a week will be in the red (in the negative). -- There is a non-zero chance that this can extend to longer periods of time. It is estimated that for periods above 1 month the likelihood of the pools turning a profit is >99%. But this is not a certainty. +- Liquidity positions held under a week will most likely be in the red (negative yield). +- Negative yield can extend to longer periods of time in the event of bettor outperformance. +- Historical data suggests a >95% likelihood that LPs will return a positive yield on positions held above one month. However, past performance does not indicate future results. + +AzuroDAO does not have any control nor backdoor functionality over the LPs. Azuro LPers are able to withdraw funds from the pool at any point after the initial 7-day lock period. + ## Liquidity Positions ### Adding Liquidity -When a user makes a new liquidity deposit they get exposed to pool losses that may occur on the markets which are already open at the time of the deposit. The positive exposure into pool profits starts with markets that are created after the deposit is made. Therefore it is almost a certainty that a new liquidity position shows negative returns in the first few days (i.e. before it starts getting positive exposure to the new markets coming up on the protocol). - - - New liquidity positions experience an initial negative skew. It is most pronounced in the first several days. - +When a user makes a new liquidity deposit they get exposed to pool losses that may occur on the markets which are already open at the time of the deposit. The positive exposure into pool profits starts with markets that are created after the deposit is made. - - There is a lockup period of **7 days** after liquidity is deposited. This means you can provide liquidity for - 7 days or more. Not less. - +Therefore it is almost a certainty that a new liquidity position shows negative returns in the first few days (i.e. before it starts getting positive exposure to the new markets coming up on the protocol). ### Withdrawing liquidity diff --git a/pages/knowledge-hub/how-azuro-works/reward-distribution.mdx b/pages/knowledge-hub/how-azuro-works/reward-distribution.mdx index 15e96185..5d3b461b 100644 --- a/pages/knowledge-hub/how-azuro-works/reward-distribution.mdx +++ b/pages/knowledge-hub/how-azuro-works/reward-distribution.mdx @@ -6,6 +6,8 @@ The term "reward" within Azuro protocol refers to the fee of the [Pool's](https: 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. +Note that reward split percentages aren't set in stone, and may be subject to further changes if deemed necessary by AzuroDAO. + ## LPs and Data Providers For LPs and Data Providers, after the completion of each [Condition](/knowledge-hub/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. @@ -35,7 +37,7 @@ $$ -### DAO +## DAO The DAO reward being a license fee for the Azuro protocol solution is calculated by deducting all other rewards from the total monthly Pool Revenue. diff --git a/pages/knowledge-hub/how-azuro-works/tl-dr.mdx b/pages/knowledge-hub/how-azuro-works/tl-dr.mdx index 3796093c..ae6b67b8 100644 --- a/pages/knowledge-hub/how-azuro-works/tl-dr.mdx +++ b/pages/knowledge-hub/how-azuro-works/tl-dr.mdx @@ -4,29 +4,29 @@ import { Callout, Formula } from 'components' ## Initialization -Data Provider creates Pool request to [Factory](https://gem.azuro.org/contracts/factory) (owned by AzuroDAO). If approved, Factory deploys a [Pool](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/pools) for the Data Provider and gives access to Azuro LP (and etc.) via [Access](https://gem.azuro.org/contracts/access). +[Data Provider](/knowledge-hub/how-azuro-works/protocol-actors/data-providers) creates Pool request to [Factory](https://gem.azuro.org/contracts/factory) (owned by AzuroDAO). If approved, Factory deploys a [Pool](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/pools) for the Data Provider and gives access to Azuro LP (and etc.) via [Access](https://gem.azuro.org/contracts/access). This allows the Data Provider to create new prediction markets, via a set of [Conditions](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/conditions) making up each prediction market. For example (for a football match): FullTimeResult, BothTeamsToScore, etc. -Data Provider sets [Reinforcement](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/reinforcement) for each Condition. **Reinforcement** represents the initial liquidity seeded from the Azuro LP to serve that **Condition** (e.g., \$200k), distributed across multiple outcomes (e.g., \$30k on Team 1, \$70k on X, \$100k on Team 2). This will also set the **Initial Odds** for each outcome within a **Condition** (\$200k/\$30k = 6.67 odds for Team 1, etc.). +Data Provider sets [Reinforcement](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/reinforcement) for each Condition. Reinforcement represents the initial liquidity seeded from the Azuro LP to serve that Condition (e.g., \$200k), distributed across multiple outcomes (e.g., \$30k on Team 1, \$70k on X, \$100k on Team 2). This will also set the *Initial Odds for each outcome within a Condition (\$200k/\$30k = 6.67 odds for Team 1, etc.). -Data Provider sets margin (i.e., 2.5%) on each Condition. Displayed odds to users will be post-margin, not the “true” odds derived from **Reinforcement** seeding. Post-margin odds will be automatically applied onchain, based on “true” **Initial Odds** (and **Live Odds**) of an outcome. +Data Provider sets margin (i.e., 2.5%) on each Condition. Displayed odds to users will be post-margin, not the 'true' odds derived from Reinforcement seeding. Post-margin odds will be automatically applied onchain, based on 'true' *Initial Odds* (and *Live Odds*) of an outcome. ## Active markets -User bets will add to the **Condition’s** initial liquidity **(Reinforcement)**. If the Condition’s initial liquidity is \$200k and it sees \$50k in bets, its total seeded liquidity becomes \$250k. +User bets will add to the Condition’s initial liquidity (aka Reinforcement). If the Condition’s initial liquidity is \$200k and it sees \$50k in bets, its total seeded liquidity becomes \$250k. -**Live Odds** will deviate from **Initial Odds** depending on betting flows, divided by the Condition’s total seeded liquidity at time of bet. The more flows to one side of the Condition, the lower the outcome’s odds will be (e.g., if this \$50k flows entirely to Team 1, its live odds will become \$250k/\$80k = 3.125, massively down from its initial odds of 6.667). +*Live Odds* will deviate from *Initial Odds* depending on betting flows, divided by the Condition’s total seeded liquidity at time of bet. The more flows to one side of the Condition, the lower the outcome’s odds will be (e.g., if this \$50k flows entirely to Team 1, its *Live Odds* will become \$250k/\$80k = 3.125, massively down from its *Initial Odds* of 6.667). -The above bet entails a potential loss of \$106.25k (\$50k \* 3.125 - \$50k) to the Condition, hence the bet will still be accepted as \$106.25k is still below the Condition’s \$200k **Reinforcement**. +The above bet entails a potential loss of \$106.25k (\$50k \* 3.125 - \$50k) to the Condition, hence the bet will still be accepted as \$106.25k is still below the Condition’s \$200k Reinforcement. -As bettors won’t bet on just one side of a Condition, on aggregate it’s unlikely for potential loss to exceed **Reinforcement**. However, if more bets are disproportionately placed on one side and push the Condition’s potential loss to exceed **Reinforcement**, the bets will be rejected. +As bettors won’t bet on just one side of a Condition, on aggregate it’s unlikely for potential loss to exceed Reinforcement. However, if more bets are disproportionately placed on one side and push the Condition’s potential loss to exceed Reinforcement, the bets will be rejected. -Hence, apart from seeding initial liquidity (and setting initial odds), **Reinforcement** also caps the amount of max loss that could be incurred to the Condition assuming the worst-case scenario (borne out of bad oddsmaking by the data provider, or unforeseen changes relating to the event post market creation that severely tilts the probability of one outcome happening over the other). +Hence, apart from seeding initial liquidity (and setting *Initial Odds*), Reinforcement also caps the amount of max loss that could be incurred to the Condition assuming the worst-case scenario (borne out of bad oddsmaking by the data provider, or unforeseen changes relating to the event post market creation that severely tilts the probability of one outcome happening over the other). ## Singleton LP -As all active **Conditions** share the same singleton **LP**, each active **Condition** needs to ensure there’s sufficient liquidity on the **LP** prior to accepting more bets. The amount denoting the additional liquidity (in excess of **Reinforcement**) that needs to be booked in the **LP** for an active **Condition** before accepting further bets is referred to as the Condition’s [**Virtual Fund**](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/virtual-funds) (aka “float”). +As all active Conditions share the same [singleton LP](/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers), each active Condition needs to ensure there’s sufficient liquidity in the LP prior to accepting more bets. The amount denoting the additional liquidity (in excess of Reinforcement) that needs to be booked from the LP for an active Condition before accepting further bets is referred to as the Condition’s [Virtual Fund](https://gem.azuro.org/knowledge-hub/how-azuro-works/components/virtual-funds) (aka “float”). $$ @@ -42,18 +42,18 @@ $$ $$ -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. +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 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 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). -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.). +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.). ## 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** may act as the arbiter of last resort. +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. -Each **Condition’s** booked liquidity (**Reinforcement** + **Virtual Fund**) that is part of the resolved market is immediately released back to the LP, which replenishes its capacity. +Each Condition’s booked liquidity (Reinforcement + Virtual Fund) that is part of the resolved market is immediately released back to the LP, which replenishes its capacity. -[**Rewards**](https://gem.azuro.org/knowledge-hub/how-azuro-wors/reward-distribution) on each **Condition** is calculated, stored on an onchain vault, then disbursed to relevant protocol actors (i.e., apps, LP, data provider, **AzuroDAO**) on a monthly basis. +[Rewards](https://gem.azuro.org/knowledge-hub/how-azuro-wors/reward-distribution) on each Condition is calculated, stored on an onchain vault, then disbursed to relevant protocol actors (i.e., apps, LP, Data Provider, AzuroDAO) on a monthly basis. diff --git a/pages/knowledge-hub/how-to-use-azuro.mdx b/pages/knowledge-hub/how-to-use-azuro.mdx new file mode 100644 index 00000000..cd14c9ae --- /dev/null +++ b/pages/knowledge-hub/how-to-use-azuro.mdx @@ -0,0 +1,23 @@ +import { Image, Button, Callout } from 'components' + +# How to Use Azuro? + +It is important to note that Azuro is a protocol for applications to integrate with, not a platform for end users to transact on. Depending on how each app integrates Azuro, it's likely that there will be no “deposits” or “withdrawals” akin to traditional betting sites. In most cases, bettors will place bets by interacting with Azuro smart contracts (facilitated by a third-party app) — authorization of said bets must come from each bettor's own private key. + +Each Azuro-powered app has their own distinct interface style and user experience flows. However, since Azuro is an EVM-based protocol, on many of these apps you may need an EVM-compatible wallet to interact with Azuro smart contracts (which includes placing and redeeming bets). + +Sample EVM wallets: [Metamask](https://metamask.io/), [Rabby](https://rabby.io/), [Phantom](https://phantom.app/), [SubWallet](https://www.subwallet.app/), [Keplr](https://www.keplr.app/). + + +You are responsible to **DYOR** on the wallets, websites, apps, and interfaces that you’re choosing to trust. Azuro cannot be held responsible for any loss of funds arising from interacting with malicious wallets, websites, apps, or interfaces. We urge users to **stay safe** and **be vigilant** to scams! + + +--- + +Some apps offer social-based authentication, in which bettors can create a wallet via social accounts like Google, Facebook, Reddit, Discord, or X/Twitter. Check with each app for specific implementations. + +Although Azuro is non-custodial by nature, some apps may choose to operate under a custodial model mainly for abstraction and user onboarding reasons. Apps built as a Telegram bot, or apps part of a wider custodial ecosystem, would be such examples. + + +**Explore Azuro apps → https://azuro.org/ecosystem** + \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/_meta.json b/pages/knowledge-hub/introduction/_meta.json index 4e1377b3..f9c921e9 100644 --- a/pages/knowledge-hub/introduction/_meta.json +++ b/pages/knowledge-hub/introduction/_meta.json @@ -1,7 +1,8 @@ { "what-is-azuro": "What is Azuro?", - "background": "Background", - "azuro-prediction-markets-v2": "Azuro: Prediction Markets, v2", - "placing-your-first-onchain-bet": "Placing Your First Onchain Bet", - "azuroscan": "Azuroscan: Search & Discover" + "oddsmaking": "Oddsmaking: Sell-side vs. Buy-side", + "pricing-mechanism-azuro-vamms": "Pricing Mechanism: Azuro vAMMs", + "lp-utilization-virtual-funds": "LP Utilization: Virtual Funds", + "event-resolution-azuro-dao": "Event Resolution: AzuroDAO", + "the-end-of-impermanent-loss": "The End of Impermanent Loss" } \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/_meta.json b/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/_meta.json deleted file mode 100644 index c7d6a6b3..00000000 --- a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/_meta.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "oddsmaking": "Oddsmaking: Sell-side vs. Buy-side", - "pricing-mechanism-azuro-vamms": "Pricing Mechanism: Azuro vAMMs", - "lp-utilization-virtual-funds": "LP Utilization: Virtual Funds", - "event-resolution-azuro-dao": "Event Resolution: AzuroDAO", - "the-end-of-lp-impermanent-loss": "The End of LP Impermanent Loss" - } \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/event-resolution-azuro-dao.mdx b/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/event-resolution-azuro-dao.mdx deleted file mode 100644 index aca45b85..00000000 --- a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/event-resolution-azuro-dao.mdx +++ /dev/null @@ -1,7 +0,0 @@ -# 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 retains the right to resolve the event in good-faith. The AzuroDAO 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 vsAZUR tokenomics. - -In the future, Azuro will look to leverage Web Proofs to resolve events directly from its official source (i.e., [premierleague.com](http://premierleague.com/) to resolve Premier League markets) once Web Proofs become viable enough for practical implementation. diff --git a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/lp-utilization-virtual-funds.mdx b/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/lp-utilization-virtual-funds.mdx deleted file mode 100644 index 42aac7c5..00000000 --- a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/lp-utilization-virtual-funds.mdx +++ /dev/null @@ -1,7 +0,0 @@ -# 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 (and shifting its onchain odds in the process). This liquidity will remain with the vAMM until the Condition’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 calculation, which is the sum of betting flows and the worst-case max potential loss to the protocol, in excess of Reinforcement. - -Since all concurrent prediction markets share the same singleton LP, 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 the liquidity that they deserve from the singleton LP, without needing sophisticated entities to act as an opinionated market-maker for said liquidity provisioning. \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/oddsmaking.mdx b/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/oddsmaking.mdx deleted file mode 100644 index 2f040433..00000000 --- a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/oddsmaking.mdx +++ /dev/null @@ -1,11 +0,0 @@ -# Oddsmaking: Sell-side vs. Buy-side - -Oddsmaking on Azuro is a race to the bottom: 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 (just like block builders in the context of PBS): 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 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 operating 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. - -However, the odds derivation process doesn’t end here — else, Azuro would “just" be an onchain betting site, 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 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’s equilibrium opinion. \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/pricing-mechanism-azuro-vamms.mdx b/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/pricing-mechanism-azuro-vamms.mdx deleted file mode 100644 index 244794b1..00000000 --- a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/pricing-mechanism-azuro-vamms.mdx +++ /dev/null @@ -1,9 +0,0 @@ -# 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. Azuro vAMMs do not require separate bootstrapping instances: they immediately inherit liquidity from the singleton Azuro LP 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 (aka prediction market). Suppose a Condition ”FullTimeResult” has three outcomes “1X2” — the data provider will first ‘book’ a certain amount of 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 an Azuro 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. - -Each vAMM maintains its own Virtual Fund, 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/azuro-prediction-markets-v2/the-end-of-lp-impermanent-loss.mdx b/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/the-end-of-lp-impermanent-loss.mdx deleted file mode 100644 index bc31354f..00000000 --- a/pages/knowledge-hub/introduction/azuro-prediction-markets-v2/the-end-of-lp-impermanent-loss.mdx +++ /dev/null @@ -1,25 +0,0 @@ -import { Image, Button, Callout } from 'components' - -# The End of LP Impermanent Loss - -Azuro’s data providers play an important role to ensure that the singleton LP is protected from extended periods of Impermanent Loss, and that liquidity provision is a passive set-and-forget endeavour from the perspective of Azuro’s LPers. - -Due to the complexities that comes with the role, data providers are expected to be highly sophisticated entities with deep oddsmaking insight on the markets that they will be providing sell-side odds for. To ensure alignment with the protocol, data providers are required to specify a fixed amount of collateral (in USDT, aka the betting / LP token) as part of their election proposal to AzuroDAO. Once onboarded, the amount of Reinforcement that the data provider could draw upon from the singleton LP will be limited to the amount of collateral that they have put up with. As such, if a data provider wishes to price sell-side odds for high-volume events (e.g., the 2026 World Cup Final, etc.), then they are required to put up more collateral up to the estimated Reinforcement that the said prediction market would necessitate. - -Data providers are ‘privileged’ participants on the prediction markets they’re pricing for, with the ability to reprice sell-side odds at any moment throughout the duration when the market is live, as well as pausing markets (aka not taking further bets) if extenuating circumstances arise. For its services, the data provider is entitled to 10%* of all revenues that are generated from all prediction markets they’re involved with, while also being liable to 25%* of all of the losses (which will be deducted from the collateral they originally put up; see Rewards Distribution). Therefore, data providers are incentivized to price (and reprice) sell-side odds in a way that maximizes profits (and minimizes losses) for themselves, and by extension, the protocol itself. - ---- - -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). - -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 front-run bettors and reprice the sell-side odds closer to the ‘true’ odds of 95% post-goal. For example, in the event that the data provider manages to misprice at 93% sell-side odds, this will still leave only a 2% margin for bettors to exploit. - -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 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 the goal even happened to begin with. - -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 from over the long run. - - -Azuro’s singleton LP has historically returned 15-20% APY to its LPers. Actual yield depends on the amount of liquidity in the pool relative to its serviced bet volume. - \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/event-resolution-azuro-dao.mdx b/pages/knowledge-hub/introduction/event-resolution-azuro-dao.mdx new file mode 100644 index 00000000..824528ac --- /dev/null +++ b/pages/knowledge-hub/introduction/event-resolution-azuro-dao.mdx @@ -0,0 +1,7 @@ +# 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 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 new file mode 100644 index 00000000..17f4962a --- /dev/null +++ b/pages/knowledge-hub/introduction/lp-utilization-virtual-funds.mdx @@ -0,0 +1,7 @@ +# 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 diff --git a/pages/knowledge-hub/introduction/oddsmaking.mdx b/pages/knowledge-hub/introduction/oddsmaking.mdx new file mode 100644 index 00000000..fbf14377 --- /dev/null +++ b/pages/knowledge-hub/introduction/oddsmaking.mdx @@ -0,0 +1,11 @@ +# 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. + +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/placing-your-first-onchain-bet.mdx b/pages/knowledge-hub/introduction/placing-your-first-onchain-bet.mdx deleted file mode 100644 index a46052d2..00000000 --- a/pages/knowledge-hub/introduction/placing-your-first-onchain-bet.mdx +++ /dev/null @@ -1,19 +0,0 @@ -import { Image, Button, Callout } from 'components' - -# Placing Your First Onchain Bet - -Important to note that when it comes to betting, Azuro is not a platform for users — it is a protocol for end-user applications. Depending on how each app integrates Azuro, it's likely that there will be no “deposits” or “withdrawals” akin to traditional betting sites. In most cases, bettors will place bets by interacting with Azuro smart contracts (facilitated by a third-party app) — authorization of said bets must come from each bettor's own private key. - -Each Azuro-powered app has their own distinct interface style and user experience flows. However, since Azuro is an EVM-based protocol, on many of these apps you may need an EVM-compatible wallet to interact with Azuro smart contracts (which includes placing and redeeming bets). Sample EVM wallets: [Metamask](https://metamask.io/), [Rabby](https://rabby.io/), [Phantom](https://phantom.app/), [SubWallet](https://www.subwallet.app/), [Keplr](https://www.keplr.app/). - -Some apps offer social-based authentication, in which bettors can create a wallet via social accounts like Google, Facebook, Reddit, Discord, or X/Twitter. Check with each app for specific implementations. - -Although Azuro is non-custodial by nature, some apps may choose to operate under a custodial model mainly for abstraction and user onboarding reasons. Apps built as a Telegram bot, or apps part of a wider custodial ecosystem, would be such examples. - - -You are responsible to DYOR with regards to the app that you’re choosing to trust. Azuro cannot be held responsible for any loss of funds arising from the use of malicious apps spewing false claims to Azuro. We urge bettors to stay safe and be vigilant to scams! - - - -**Explore Azuro apps → https://azuro.org/ecosystem** - \ 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 new file mode 100644 index 00000000..40bf72c9 --- /dev/null +++ b/pages/knowledge-hub/introduction/pricing-mechanism-azuro-vamms.mdx @@ -0,0 +1,9 @@ +# 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%. + +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. + +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 new file mode 100644 index 00000000..b3ba216a --- /dev/null +++ b/pages/knowledge-hub/introduction/the-end-of-impermanent-loss.mdx @@ -0,0 +1,29 @@ +import { Image, Button, Callout } from 'components' + +# The End of Impermanent Loss + +Azuro [Data Providers](/knowledge-hub/how-azuro-works/protocol-actors/data-providers) play an important role to ensure that the [singleton LP](/knowledge-hub/how-azuro-works/protocol-actors/liquidity-providers) is protected from extended periods of Impermanent Loss, and that liquidity provision is a passive set-and-forget action from the perspective of Azuro LPers. Due to the complexities that comes with the role, Data Providers are expected to be highly sophisticated entities with deep oddsmaking insight on the markets that they will be providing sell-side odds for. + +To ensure alignment with the protocol, Data Providers are required to specify a fixed amount of collateral (in USDT, which is the protocol's betting and LP denomination) as part of their election proposal[*] to [AzuroDAO](/knowledge-hub/azur/azuro-dao). Once onboarded, the amount of [Reinforcement](/knowledge-hub/how-azuro-works/components/reinforcement) that the Data Provider could draw upon from the singleton LP will be limited to the amount of collateral that they have put up with. As such, if a Data Provider wishes to price sell-side odds for high-volume events (e.g., the 2026 World Cup Final, etc.), then they are required to put up more collateral up to the estimated Reinforcement that the said prediction market would necessitate. + +Data Providers are ‘privileged’ participants on the prediction markets they’re pricing for, with the ability to reprice sell-side odds at any moment throughout the duration when the market is live, as well as pausing markets (not taking further bets) if extenuating circumstances arise. For their services, Data Providers are entitled to [10%](/knowledge-hub/how-azuro-works/reward-distribution) of all revenues that are generated from all prediction markets they’re involved with, while also being liable to its losses (to be deducted from their collateral balance). + +Therefore, Data Providers are incentivized to price (and reprice) sell-side odds in a way that maximizes profits and minimizes losses for themselves (and by extension, the protocol itself). + +## In action: preventing LP losses + +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). + +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%. + +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. + +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. + + +Azuro’s singleton LP has historically returned 15-20% APY to its LPers. Actual yield depends on the amount of liquidity in the pool relative to its serviced bet volume. + \ No newline at end of file diff --git a/pages/knowledge-hub/introduction/what-is-azuro.mdx b/pages/knowledge-hub/introduction/what-is-azuro.mdx index 8e6285f5..3fc8ca98 100644 --- a/pages/knowledge-hub/introduction/what-is-azuro.mdx +++ b/pages/knowledge-hub/introduction/what-is-azuro.mdx @@ -1,12 +1,10 @@ -import { Callout } 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 mechanism and the LiquidityTree 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, allowing each to scale (and service bets) to the ‘true’ demand levels of its underlying event — up to the pool’s capacity. +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. -In addition, Azuro apps compete with each other to offer 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. +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. As prediction markets are increasingly being relied upon by society as an unbiased source of truth for world events, enabling trust-minimized and scalable liquidity provision is of paramount importance. Azuro is the only protocol in production today that enables passive algorithmic liquidity provision, where LPs are protected from the risk of Impermanent Loss (IL) — prevalent in first-generation prediction market designs.