07/21 Multi Outcomes (Preparation)
Azuro Protocol is preparing for a major release to provide access to new features:
- Events with multiple outcomes. This will be the first step towards adding new sports;
- A new system for calculating rewards for frontend operators;
- New freebet management system.
The plan is to migrate the contracts from 2.7.3 to 2.10.0 version.
The new version of the protocol will be incompatible with the current one. Clients need to migrate and upgrade to the new version.
Main changes:
- New Core and Express(Combo) contracts;
- The methods working with native tokens moved from LP to ProxyFront;
- Conditions support more than 2 outcomes. No more need for additional regrouping (markets aggregation) on the client side.
Migration plan:
- Azuro will provide a testnet of the current and future versions.
- Frontends will have time to change the code of their applications and test these changes.
- We will announce the migration in advance at the test stand - it will be a dress rehearsal before the migration on the prod.
- Next, we will announce the migration date on the prod. Frontends should be ready to switch at the specified time.
Stages of migration in production:
- Azuro will stop creating prod events on current contracts.
- After all events are resolved, Azuro will trigger rewards redeem for all frontend operators.
- The protocol will be switched to new contracts.
About all migration dates (on the test stand and in production) we will notify you in advance. The approximate date of migration on the prod at the moment is August 15/16 at 11:00 (CET).
Contracts
Change Log
- Added ability to flexibly manage reserved liquidity for created conditions: change reinforcement and margin.
- Operations (bet, withdrawPayout, addLiquidity, withdrawLiquidity) with native tokens should be proceed using “ProxyFront” contract.
- Core contract renamed to PrematchCore.
- Affiliate rewards calculation model changed to off-chain.
ProxyFront.sol
-
New functions
addLiquidityNative
andwithdrawLiquidityNative
to operate with liquidity in native tokenaddLiquidityNative( address lp, bytes calldata data // reserved for future use, now just pass "0x" ) payable
withdrawLiquidityNative( address lp, uint48 depositId, // LP token ID uint40 percent // withdrawal percentage (100% = 1^12) ) payable
-
New function
bet
to place bets using native token or/and to batch multiple betsbet( address lp, BetData[] calldata data ) payable struct BetData { address core; uint128 amount; uint64 expiresAt; BetDataStruct extraData; }
ℹ️Note that using
bet
for placing bets in ERC20 tokens requires users to make an approve of tokens spending. -
New function
withdrawPayouts
to withdraw payouts using native token or/and to batch multiple betswithdrawPayouts(WithdrawPayoutData[] calldata data) struct WithdrawPayoutData { address core; uint256 tokenId; // bet token ID bool isNative; }
LP.sol
-
The following methods have been removed:
betNative
addLiquidityNative
withdrawLiquidityNative
claimAffiliateRewardFor
daoFee
oracleFee
-
addLiquidity
has been changedaddLiquidity( uint128 amount, bytes calldata data // reserved for future use, now just pass "0x" ): uint48 depositId
-
The parameters of
bet()
andbetFor()
have been changed, added returning of bet token ID value// ICoreBase struct CoreBetData { uint256 conditionId; // The match or game ID uint64 outcomeId; // ID of predicted outcome } // betData.data for prematch (PrematchCore) is ICoreBase.CoreBetData // betData.data for express (BetExpress) is ICoreBase.CoreBetData[] // IBet struct BetData { address affiliate; // address indicated as an affiliate when placing bet uint64 minOdds; bytes data; // core-specific customized bet data } bet( address core, uint128 amount, uint64 expiresAt, IBet.BetData calldata betData ): uint256 tokenId betFor( address bettor, address core, uint128 amount, uint64 expiresAt, IBet.BetData calldata betData ): uint256 tokenId
claimReward(): uint128 claimedAmount
-
Getting fees values has been changed
uint64[3] public fees fees[0] // DAO fee fees[1] // data provider fee
-
getLeaf()
replaced withgetLastDepositId()
getLastDepositId(): uint48 depositId
-
viewPayout()
andwithdrawPayout()
have returned value of payout amountviewPayout(address core, uint256 tokenId): uint128 amount
withdrawPayout(address core, uint256 tokenId): uint128 amount
PrematchCore.sol
-
condition
structure has been changedstruct Condition { uint256 gameId; uint128[] payouts; uint128[] virtualFunds; uint128 totalNetBets; uint128 reinforcement; uint128 fund; uint64 margin; uint64 endsAt; uint48 lastDepositId; uint8 winningOutcomesCount; ConditionState state; address oracle; } getCondition(uint256 conditionId): Condition
-
Getter
isOutcomeWinning
has beed added:isOutcomeWinning(uint256 conditionId, uint64 outcome): bool
-
Getter
isConditionResolved
has been added:isConditionResolved(uint256 conditionId): bool
GraphQL
Change Log
Game
ipfsHash
has been removed. Game information is now provided directly to thecreateGame
method on the smart contracts and can be accessed through theNewGame
event. All data from this event is still available in other fields for your convenience.
Condition
- The main objective of this major release is to introduce support for multi-outcome conditions (markets). In previous versions, all
Condition
entities only supported two outcomes for each condition, with a single winning outcome (wonOutcome
) in cases where the condition was resolved without cancellation. With the new contracts, conditions can now have more than two outcomes, including multiple winning outcomes, such as the Double Chance market. As a result, thewonOutcome
field has been migrated towonOutcomes: [Outcome!]
.wonOutcomeId
replaced withwonOutcomeIds
. - A new service field
_winningOutcomesCount
has been added.
Freebet
- In current version there is field
burned: boolean
which represents if Freebet NFT was burned (as consequence is resolved). This field continue to exist in new version and represent only state of token burning. In the new version freebets can be resolved without burning. Therefore, a new fieldisResolved: boolean
is added.
Event
- The
leafId
field inLiquidityAdded
andLiquidityRemoved
events has been renamed todepositId
.
Migration Guide
To accommodate the current implementation, a new version of the Subgraph has been added. Please note that this version requires the use of the new Core contracts (the new versions of Prematch and Express). We recommend implementing these features in our development environment. You can utilize the following endpoints to implement multiple outcomes:
-
Setup testnet environment in your application:
Gnosis 2.7.3 (graph v2)
LP:
0xe068Bf88317fA2eb3EAEcBfe1e486d8b2dDe7761
PREMATCH_CORE:0xfb22dFfdeb3aed0Ee9475c1aDaDF1e8991193D3c
BET_EXPRESS:0xd3ac70B5326c201c8527da6999d9A0C74f7A1Adc
TOKEN:0xe91D153E0b41518A2Ce8Dd3D7944Fa863463a97d
Subgraph: https://thegraph.azuro.org/subgraphs/name/azuro-protocol/azuro-api-gnosis-dev-v2 (opens in a new tab)Polygon Mumbai 2.7.3 (graph v2)
LP:
0xe47F16bc95f4cF421f008BC5C23c1D3d5F402935
PREMATCH_CORE:0x53193ae93495fED11322Eac595Dc1A58c483f0bB
BET_EXPRESS:0xa8951593Abd2b28F142238A2128a2F4301464EaA
TOKEN:0xe656De3EC9eFf1B851e0b39AFFaa1478353885a4
Subgraph: https://thegraph.azuro.org/subgraphs/name/azuro-protocol/azuro-api-mumbai-dev-v2 (opens in a new tab)Arbitrum Goerli 2.7.3 (graph v2)
LP:
0x482e419711E63d0E49CbDC696858Ef1E4764771e
PREMATCH_CORE:0x2Bf9190486CffF61eA2AD4f2aa8B47458e8C0767
BET_EXPRESS:0xecbFd2e4AaFaB41e8e5f8eE429D982a7A6A64Af8
TOKEN:0x600d18607e2805f4c669381f28fdcd1d5074b4b4
Subgraph: https://thegraph.azuro.org/subgraphs/name/azuro-protocol/azuro-api-arbitrum-goerli-dev-v2 (opens in a new tab)Linea Goerli 2.7.3 (graph v2)
LP:
0xc365224ef4Fa75D56a280C5A3925caDbF7bd8eeE
PREMATCH_CORE:0x2b3cDdf565Ab5ED9DD7AcFaD4428B7E913F9B001
BET_EXPRESS:0x77500b84C074Cc59fF002b22Cd49ceFaE0B79970
TOKEN:0xa07e6dA79723961a7a933566c42D3Cf1dbE5B19c
Subgraph: https://thegraph.azuro.org/subgraphs/name/azuro-protocol/azuro-api-linea-goerli-dev-v3 (opens in a new tab)Gnosis 2.10.0 (updated from 2.7.3, graph v3)
LP:
0x4e5BBE3e1f559C8010b516C603B619a932de3DF4
PREMATCH_CORE:0x6f60d66e853A769391B105d21C410AD035512Cc2
BET_EXPRESS:0x1dD7BA44c23a621BBfD6c4322DA6E1CA81C17700
PROXY_FRONT:0x135a1256a8b48643DD0823fE189ADD1c2a012DBa
TOKEN:0xe91d153e0b41518a2ce8dd3d7944fa863463a97d
ACCESS:0xBfbA0B1abE87A028Fb2CD26555Eabf0Ae71F6100
AZURO_BET:0xF2ef2267261dF0F5599b27c255D0AF6B20f62651
Subgraph: https://thegraph.azuro.org/subgraphs/name/azuro-protocol/azuro-api-gnosis-dev-v3 (opens in a new tab)Mumbai 2.10.0 (updated from 2.7.3, graph v3)
LP:
0xe47F16bc95f4cF421f008BC5C23c1D3d5F402935
PREMATCH_CORE:0x8ea11e2aefab381e87b644e018ae1f78aa338851
BET_EXPRESS:0xc0a46fc9952e4b804960a91ece75f89952a2c205
PROXY_FRONT:0xa43328ABd99ae605A87661E7fC84a0e509DE6BD0
TOKEN:0xe656De3EC9eFf1B851e0b39AFFaa1478353885a4
ACCESS:0x430bdD95Eb2Cc894101160a5052119a7Dd629C6a
AZURO_BET:0xC68c93cE0E9447068eaf08e118D215001F5742bd
Subgraph: https://thegraph.azuro.org/subgraphs/name/azuro-protocol/azuro-api-mumbai-dev-v3 (opens in a new tab)Arbitrum Goerli 2.10.0 (updated from 2.7.3, graph v3)
LP:
0x02a88e08142B262Cc66c81977d8FbE86aFe90C58
PREMATCH_CORE:0x72A3e11B4683fA3C4b91C387509C7324E0Ea8B6B
BET_EXPRESS:0xA663E719B9B81cd62C59495181D594F4D47d9085
PROXY_FRONT:0x4eDedEab8ecB17cB569a1aCEe4D60a49AECabB10
TOKEN:0x600d18607e2805f4c669381f28fdcd1d5074b4b4
ACCESS:0x974E421249cea227D2DA5B353f98885dC3aDA215
AZURO_BET:0xD8B7C6F54cCfbDbA70f01bBc3773CF574b9f63fa
Subgraph: https://thegraph.azuro.org/subgraphs/name/azuro-protocol/azuro-api-arbitrum-goerli-dev-v3 (opens in a new tab) -
Read the change logs in this article and do necessary changes. The main points are here:
wonOutcomeId
,wonOutcome
→wonOutcomeIds
,wonOutcomes
.- operations (bet, withdrawPayout, addLiquidity, withdrawLiquidity) with native tokens should be proceed using “ProxyFront” contract.
- the parameters passed to
bet
andbetFor
methods on the LP contract have been changed.
-
Wait when Azuro announce about migration in testnet. Azuro will provide additional details on this process.
Deprecation Notice
After migrating to the new version the Subgraphs V1 and V2 will be disabled!