Skip to main content

Entities (+)


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.

Entity Architecture

Inside the merkle subgraph, the schema.graphql file is responsible of defining the following Sablier entities:


FactoryInstances of SablierV2MerkleStreamerFactory
CampaignInstances of SablierV2MerkleStreamerLL, the primary entity tracking the up to date state of an Airstream/Merkle campaign
ActionEmitted events transformed into historical entries (e.g. Claim, Create, Clawback)
ActivityAn entity tracking daily usage (one item per day) for each campaign (e.g. amount claimed per day)
AssetThe ERC20 asset that is being streamed


WatcherA 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 interfaces:

  • 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.

Airstream.idA self-explanatory structure built using the following structure: contractAddress-chainId0xAB..12-1115511

The example from the table above translates to: a stream on Sepolia (chain id 1115511), with the contract address 0xAB..12.


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.

Data Flow

The data flow applied to this subgraph is identical to the one used in the protocol subgraph.