Goal: Add a MarketData entity to the subgraph schema that is used to easily query the payouts of a condition, the current fpmm price of the asset and the most recent orderbook price of the asset.
The MarketData entity is created in 2 places:
When an FPMM is created, if the entity does not already exist
When a Token is registered on the Exchange, if the entity does not already exist
This is necessary because we cannot create MarketData on ConditionPreparation. This is because the ERC1155 token ids only exist after a collateral token has been used to mint new ERC1155 tokens, i.e on splitPosition. On ConditionPreparation, the CTF does not and cannot know the token ids.
The MarketPosition entity now references this MarketData entity in the market field instead of a simple string.
Querying MarketPositions will now let us easily fetch various fields, see below:
Query
`{
marketPositions(
first:10,
where:
{market: "66355124231942466449381349418530439565445786890155807449321941637845118306804"}){
id
market {
id
condition {
id
payouts
}
outcomeIndex
fpmm {
id
outcomeTokenPrices
}
priceOrderbook
}
quantityBought
quantitySold
netQuantity
netValue
valueBought
valueSold
}
Goal: Add a MarketData entity to the subgraph schema that is used to easily query the
payoutsof a condition, the current fpmm price of the asset and the most recent orderbook price of the asset.The MarketData entity is created in 2 places:
This is necessary because we cannot create MarketData on ConditionPreparation. This is because the ERC1155 token ids only exist after a collateral token has been used to mint new ERC1155 tokens, i.e on splitPosition. On ConditionPreparation, the CTF does not and cannot know the token ids.
The MarketPosition entity now references this MarketData entity in the market field instead of a simple string.
Querying MarketPositions will now let us easily fetch various fields, see below: Query `{
}`