For an introduction into the base Sablier primitives and some architectural choices, make sure to check out the protocol subgraph before reading about the merkle subgraph.
Inside the merkle subgraph, the
schema.graphql file is
responsible of defining the following Sablier entities:
SablierV2MerkleStreamerLL, the primary entity tracking the up to date state of an Airstream/Merkle campaign
|Emitted events transformed into historical entries (e.g. Claim, Create, Clawback)
|An entity tracking daily usage (one item per day) for each campaign (e.g. amount claimed per day)
|The ERC20 asset that is being streamed
|A singleton data store for subgraph-level unique indexes such as the campaign or action index
The structure of these entities is built on the same rules and mindset which was applied on the protocol entities.
Airstreams will be assigned a unique
contract address once they are deployed by the Merkle Factory. While this makes
it easy to identify items at the contract level, we need to consider the following for both subgraphs and client
- items should be uniquely identifiable across multiple chains
- items should be identifiable with short, easy to digest names (TBD)
To address the first observation, the subgraph uses the following identifier for an Airstream.
|A self-explanatory structure built using the following structure:
The example from the table above translates to: a stream on Sepolia (chain id
1115511), with the contract address
We've chosen not to apply aliases to Airstreams for now. In the future, we may ask the campaign creator to provide a name or an alias to be used in the URL.
The data flow applied to this subgraph is identical to the one used in the protocol subgraph.