TheGraph has a limit of returning a maximum of 1000 elements per request, with a default of 100 elements. Keep this limit in mind when building your queries. Read how to paginate (opens in a new tab).

Indexing errors

In rare cases indexing errors of new data may occur in subgraph nodes. In that case queries will throw an error with no data by default. We're reacting fast on such accidents. But while it isn't fixed, you can add param subgraphError: allow to your queries to ignore these errors and work with existing data.


When working with TheGraph, all address values are stored in lowercase. This means that when passing variables to queries, it's important to convert the transmitted value to lowercase, or use the _contains_nocase postfix.


When working with TheGraph, efficiency matters. The secret sauce lies in their unique id: ID! (TheGraph IDs) for @entity directives in schemas. These IDs, when used in queries, speed up request execution time.

To maintain clarity and distinction from TheGraph IDs, Azuro assigns specific prefixes to its entity IDs, such as sportId for sports and gameId for games. To construct a unique TheGraph ID, Azuro merges various entity parameters, ensuring each ID is one of a kind.

Want to use, for example, Game or Condition TheGraph IDs in your code? It's as easy as this:

const gameEntityID = `${liquidityPoolAddress.toLowerCase()}_${gameId}`
const conditionEntityID = `${coreAddress.toLowerCase()}_${conditionId}`

Check out the full list of TheGraph ID getters (opens in a new tab)
Remember, when using these getters, ensure that addresses are converted to lowercase.

Entity Duplications

There can be several LP contracts within a single blockchain network. There are several reasons for this, such as managing different currency pools or addressing risk management concerns.

Each LP contract can contain multiple Core contracts, with each Core contract differing in terms of the logic used for different casino games or pre-match/live betting. For example, the logic for pre-match/live betting may differ from that used for other casino games.


The presence of multiple identical contracts in the Azuro Protocol can lead to entities with the same Azuro IDs (e.g. gameId, conditionId). This is because entities created on different contracts may share the same ID, which can make it difficult to distinguish between them.

For example, different LPs may have the same games with the same gameId, while conditions created on Core contracts may have the same conditionId.

When interacting with entities in the Azuro Protocol, it's important to use the coreAddress and lpAddress properties to identify the specific contract to which the entity belongs.

For example, when querying for games, you should include the lpAddress as a filter to ensure that you are only retrieving games from the correct LP contract. Similarly, when placing bets, you should include the coreAddress to ensure that the bet is being placed on the correct Core contract.

By using these additional properties to identify the specific contract and entity, you can help prevent issues related to duplicate IDs and ensure that your application is able to function as intended.