This section shows an outline of the various entities that make up the graphQL endpoint available from the Archive Protocol.

User Transactions Statuses (userTransactionStatuses)

Returns each transaction hash our system has identified for a particular address in the supplied Blueprint. This can be helpful to get a detailed view of the indexing status and who transactions are not processed, processed, or have errors.

Total positions entity: a source for position identifiers (totalPositions)

totalPositions can be used to fetch the position identifiers available from a blueprint for a particular user address. These position identifiers are then needed in all of the other queries. Currently this is the only entity that doesn't require a position identifier. It also has the standard indexingStatus object to show if the data is fully synched or more processing is required.

Positions entity: transactions by position

Part of what a blueprint does is classify each transaction an address makes within the scope of the blueprint. The scope of a blueprint is usually a protocol, but some protocols can be split up into multiple blueprints if needed. The positions entity returns the key transaction data for all the operations. This is where the protocol stores what tokens and how many tokens went from where to where and how much they were worth at that time. The affects of the transactions on the position as a whole are also tracked in the fields of the position entity.

Many of the calculations and analytics found in our interval data rely on the data returned by the positions entity.

Interval data (3 types): position metrics at a particular block

This data describes the position at a specific time/block. The fields depict token balances, prices, profit, and loss metrics, benchmark metrics, and more. The schema for the interval data is the same across the 3 different types of the tracked intervals. Archive protocol stores intervals at three key times:

1. at each transaction/operation (snapshotIntervalData)
2. at regular intervals (defaults to daily) to create an overview of the position over time (eodIntervalData)
3. on demand to get an up to date interval that can be generated at that moment and saved (onDemandIntervalData)

On demand interval data (onDemandIntervalData)

This entity returns the fields in the interval data schema for the most recent block available.

Many use cases can be satisfied with just this data so Archive protocol makes it available on its own for speed and a simplified view.

Note that exited positions will not return data from the onDemandIntervalData entity.

Snapshot interval data (snapshotIntervalData)

This entity returns the fields in the interval data schema at every block the position has a deposit, withdraw, income, or transfer event.

Eod interval data (eodIntervalData)

This entity returns the fields in the interval data schema at a regular interval which is by default daily. We use 0 UTC as the time for this snapshot of the position.

Interval dependent data (intervalDependentData): data referring to a specific time period

Once Archive protocol stores the interval data we can produce some other useful metrics on top of that. One example of this is the data returned in our intervalDependentData entity.

Querying multiple entities is not currently supported

Currently we limit queries to 1 entity at a time, not counting the requestId entity. So you can not do an onDemandIntervalData query and a positions query in the same request. This may change in the future. Feel free to let us know what you think and if this is a major blocker for your usecase.