Developer Hub
📦 Releases
07/21 Multi Outcomes (Preparation)

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

  1. New functions addLiquidityNative and withdrawLiquidityNative to operate with liquidity in native token

    addLiquidityNative(
      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
  2. New function bet to place bets using native token or/and to batch multiple bets

    bet(
      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.

  3. New function withdrawPayouts to withdraw payouts using native token or/and to batch multiple bets

    withdrawPayouts(WithdrawPayoutData[] calldata data)
     
    struct WithdrawPayoutData {
      address core;
      uint256 tokenId; // bet token ID
      bool isNative;
    }

LP.sol

  1. The following methods have been removed:

    • betNative
    • addLiquidityNative
    • withdrawLiquidityNative
    • claimAffiliateRewardFor
    • daoFee
    • oracleFee
  2. addLiquidity has been changed

    addLiquidity(
      uint128 amount,
      bytes calldata data // reserved for future use, now just pass "0x"
    ): uint48 depositId
  3. The parameters of bet() and betFor() 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
  1. Getting fees values has been changed

    uint64[3] public fees
     
    fees[0] // DAO fee
    fees[1] // data provider fee
  2. getLeaf() replaced with getLastDepositId()

    getLastDepositId(): uint48 depositId
  3. viewPayout() and withdrawPayout() have returned value of payout amount

    viewPayout(address core, uint256 tokenId): uint128 amount
    withdrawPayout(address core, uint256 tokenId): uint128 amount

PrematchCore.sol

  1. condition structure has been changed

    struct 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
  2. Getter isOutcomeWinning has beed added:

    isOutcomeWinning(uint256 conditionId, uint64 outcome): bool
  3. Getter isConditionResolved has been added:

    isConditionResolved(uint256 conditionId): bool

GraphQL

Change Log

Game

  • ipfsHash has been removed. Game information is now provided directly to the createGame method on the smart contracts and can be accessed through the NewGame 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, the wonOutcome field has been migrated to wonOutcomes: [Outcome!]. wonOutcomeId replaced with wonOutcomeIds.
  • 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 field isResolved: boolean is added.

Event

  • The leafId field in LiquidityAdded and LiquidityRemoved events has been renamed to depositId.

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:

  1. 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)

  2. Read the change logs in this article and do necessary changes. The main points are here:

    1. wonOutcomeId, wonOutcomewonOutcomeIds, wonOutcomes.
    2. operations (bet, withdrawPayout, addLiquidity, withdrawLiquidity) with native tokens should be proceed using “ProxyFront” contract.
    3. the parameters passed to bet and betFor methods on the LP contract have been changed.
  3. 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!