feat: V2.2 docs (#138)

* feat: update docs for v2.2 release build: upgrade docusaurus to v3.1.1 feat: update contracts reference for v2.2 feat: update access control feat: add crete a lockup tranched stream guide refactor: use new create functions in lockup linear and lockup dynamic guides refactor: update periphery guides chore: update repos refactor: concepts docs: remove governance, update glossary and hooks refactor: note in diagrams feat: new shapes in stream types update repos update markdown files fix broken links andrei feedback * docs: update concepts pages * fix: streaming equations * remove protocol fee from fees section * update guide * update guide: hooks * update guide: hooks * update etherscan part 1 * update guides * docs: add grants as a use case * include gas benchmarks * docs: guide to create airstreams * feat: document frames and stream preview (#155) chore: add some extra features to streams and airstreams * replace staging with main * feat: add authentication info box (#156) * polish * diagrams * chore: remove autofill (#154) * rename BATCH to BATCH_LOCKUP * fix bugs * fix hyperlink to airstream create example * refactor: wording updates * Add 1.2.0 deployments * re-order use cases * update sepolia addresses * use token streaming, hyperlink segments and tranches * add governance * add missing deployment addresses in previous versions * include npm release version in older deployments * update etherscan page with v2.2 screenshots * refactor: polish wording * feat: add mainnet addresses * refactor: order contracts alphabetically * Add last deployments * polish wording * update admin address for Blast * fix(deployments): lightlink merkle factory address * refactor: polish wording refactor: fix typos refactor: misc improvements * fix: fix Blast address * fix typo --------- Co-authored-by: Razvan Gabriel Apostu <razvan.gabriel.apostu@gmail.com> Co-authored-by: gavriliumircea <48255669+gavriliumircea@users.noreply.github.com> Co-authored-by: Paul Razvan Berg <prberg@proton.me> Co-authored-by: andreivladbrg <andreivladbrg@gmail.com>
sablier-labs · Jul 5, 2024 · 51de521 · 51de521
1 parent 86457f3
commit 51de521
Show file tree

Hide file tree

Showing 143 changed files with 5,279 additions and 3,932 deletions.
diff --git a/bun.lockb b/bun.lockb
diff --git a/docs/api/01-overview.mdx b/docs/api/01-overview.mdx
@@ -38,12 +38,12 @@ the [official vendor docs](https://thegraph.com/docs/en/quick-start/).
 
 ### Envio's Indexers
 
-[Envio](https://envio.dev/) offers a suite of fast and flexible tools to access on-chain data. Their HyperIndex service
+[Envio](https://envio.dev/) offers a suite of fast and flexible tools to access onchain data. Their HyperIndex service
 provides for a similar GraphQL driven API to access cached data and serve it into our client interfaces.
 
 We designed a set of indexers that mimic the features and entities exposed by subgraphs and take advantage of the speed
 and optimized environment configured through HyperIndex. Read more on the dedicated page about our `protocol-envio` and
-`merkle-envio` [indexers](/api/indexers/overview).
+`merkle-envio` [indexers](/api/indexers/endpoints).
 
 All networks share the same indexer endpoint (for one indexer type), as Envio promotes a cross-chain indexing
 architecture.
@@ -65,13 +65,13 @@ Sablier deployments).
 
 ## Merkle API (Rust)
 
-To support our Merkle distribution (a.k.a. [Airstreams](/apps/features#airstreams)) system we developed a backend
+To support our Merkle distribution (a.k.a. [Airstreams](/apps/features/airstreams)) system we developed a backend
 service called `@sablier/v2-merkle-api`. This backend deals with the validation, creation and management of Merkle
 trees, used to define eligibility and claiming rules for Sablier's Airstream campaigns.
 
 This service is open-source and can be used by integrators as a plug-n-play solution to support (and even deploy)
 similar campaigns from their own dashboards. Read more on the dedicated page about the `merkle-api`
-[backend](/api/merkle-api/overview).
+[backend](/api/merkle-api/intro).
 
 <LinkPreview
   href="https://github.com/sablier-labs/v2-merkle-api"

diff --git a/docs/api/indexers/01-endpoints.mdx b/docs/api/indexers/01-endpoints.mdx
@@ -13,9 +13,9 @@ deployment. The data from all of chains that Sablier is deployed on can be queri
 
 :::
 
-## Sablier V2 - Protocol-Envio
+## Protocol-Envio
 
-The `protocol-envio` indexer tracks events mainly emitted by the
+The `protocol-envio` indexer mainly tracks events emitted by the
 [`@sablier/v2-core`](/contracts/v2/reference/overview#core) contracts. It deals with core protocol actions like
 creating, withdrawing, or transferring streams.
 
@@ -33,16 +33,15 @@ Use [Hasura's online explorer](https://cloud.hasura.io/public/graphiql?) to view
   href="https://github.com/sablier-labs/v2-subgraphs/tree/main/apps/protocol-envio"
   icon="github"
   subtitle="Github - sablier-labs/v2-subgraphs"
-  title="Sablier V2 protocol subgraph (Envio)"
+  title="Sablier V2 Envio Subgraph"
 />
 
-## Sablier V2 - Merkle-Envio (Airstreams)
+## Merkle-Envio (Airstreams)
 
 This subgraph tracks events emitted by the [`@sablier/v2-periphery`](/contracts/v2/reference/overview#periphery)
-contracts, specifically the
-[`Merkle Factory`](/contracts/v2/reference/periphery/contract.SablierV2MerkleStreamerFactory). It deals with airstream
-specific actions like the factory creating a campaign, admin clawbacks or users claiming streams as defined in the
-attached Merkle tree.
+contracts, specifically the [`Merkle Factory`](/contracts/v2/reference/periphery/contract.SablierV2MerkleLockupFactory).
+It deals with airstream-specific actions like the factory creating a campaign, admin clawbacks, or users claiming
+streams as defined in the attached Merkle tree.
 
 [endpoint-protocol]: https://indexer.bigdevenergy.link/9e37ca4/v1/graphql
 

diff --git a/docs/api/indexers/05-development.mdx b/docs/api/indexers/05-development.mdx
@@ -18,11 +18,9 @@ We recommend using:
 If you're integrated the Sablier V2 subgraphs, we recommend using request and response wrappers/middleware to format
 results coming from Envio's indexer in the same shape as those from The Graph. Suggestions:
 
-1. Write queries in both systems (based on the
-   [querying language specifics](/api/indexers/differences#querying-language)) using the same `operationName` and swap
-   query strings between vendors based on it
-2. Write response middleware that converts results into similar shapes (see these
-   [important notes](api/indexers/differences#important-notes))
+1. Write queries in both systems (based on the [querying language specifics](differences#querying-language)) using the
+   same `operationName` and swap query strings between vendors based on it
+2. Write response middleware that converts results into similar shapes (see these [important notes](differences))
 
 <LinkPreview
   href="https://github.com/sablier-labs/v2-subgraphs"

diff --git a/docs/api/indexers/merkle/02-queries.md b/docs/api/indexers/merkle/02-queries.md
@@ -4,7 +4,7 @@ sidebar_position: 2
 title: "Queries"
 ---
 
-Building on top of the [entity structure](/api/subgraphs/merkle/structure) defined earlier, here are some common GraphQL
+Building on top of the [entity structure](/api/subgraphs/merkle/entities) defined earlier, here are some common GraphQL
 queries for fetching data from the Sablier V2 subgraph.
 
 ### Recent streams

diff --git a/docs/api/indexers/protocol/04-queries.md b/docs/api/indexers/protocol/04-queries.md
@@ -51,8 +51,8 @@ query getStreams($first: Int!, $subgraphId: numeric!) {
 
 ### Streams by sender (with support for the old V2.0)
 
-To support both [proxy senders](/api/subgraphs/protocol/structure#the-proxender) (case 3) and
-[native senders](/api/subgraphs/protocol/structure#the-proxender) (case 2) we query for:
+To support both [proxy senders](/api/subgraphs/protocol/structure) (case 3) and
+[native senders](/api/subgraphs/protocol/structure) (case 2) we query for:
 
 - streams where the connected account is the native sender
 - streams where the connected account is the proxender - the owner of the proxy labeled as a sender

diff --git a/docs/api/merkle-api/02-functionality.mdx b/docs/api/merkle-api/02-functionality.mdx
@@ -56,13 +56,13 @@ the API deals with the padding of each value (with the decimals of the token) on
 
 ### Description
 
-|                  |                                                        |
-| :--------------- | ------------------------------------------------------ |
-| **Endpoint**     | `/api/create`                                          |
-| **Method**       | `POST`                                                 |
-| **Query Params** | `{decimals: number}`                                   |
-| **Body**         | `FormData` on `{data: File}`                           |
-| **Response**     | See in [Rust](api-create-response) Overview TS (below) |
+|                  |                                                                                                                             |
+| :--------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| **Endpoint**     | `/api/create`                                                                                                               |
+| **Method**       | `POST`                                                                                                                      |
+| **Query Params** | `{decimals: number}`                                                                                                        |
+| **Body**         | `FormData` on `{data: File}`                                                                                                |
+| **Response**     | See in [Rust](https://github.com/sablier-labs/v2-merkle-api/blob/main/src/data_objects/response.rs#L22) Overview TS (below) |
 
 ```typescript
 type Response = {
@@ -118,6 +118,12 @@ For more insight, check out the implementation details.
 
 Call this route to check if a recipient is eligible to claim a stream from the Merkle/Airstream campaign.
 
+:::info
+
+This endpoint uses an authentication scheme. Please reach out if you need to use our deployed endpoints in your app.
+
+:::
+
 ### Prerequisites
 
 To check eligibility for an address, you'll be required to provide:
@@ -131,12 +137,12 @@ To get a hold of the second item you can see some options here in the
 
 ### Description
 
-|                  |                                                             |
-| :--------------- | ----------------------------------------------------------- |
-| **Endpoint**     | `/api/eligibility`                                          |
-| **Method**       | `GET`                                                       |
-| **Query Params** | `{address: string, cid: string}`                            |
-| **Response**     | See in [Rust](api-eligibility-response) Overview TS (below) |
+|                  |                                                                                                                             |
+| :--------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| **Endpoint**     | `/api/eligibility`                                                                                                          |
+| **Method**       | `GET`                                                                                                                       |
+| **Query Params** | `{address: string, cid: string}`                                                                                            |
+| **Response**     | See in [Rust](https://github.com/sablier-labs/v2-merkle-api/blob/main/src/data_objects/response.rs#L32) Overview TS (below) |
 
 ```typescript
 type Response = {
@@ -188,12 +194,12 @@ page.
 
 ### Description
 
-|                  |                                                          |
-| :--------------- | -------------------------------------------------------- |
-| **Endpoint**     | `/api/validity`                                          |
-| **Method**       | `GET`                                                    |
-| **Query Params** | `{cid: string}`                                          |
-| **Response**     | See in [Rust](api-validity-response) Overview TS (below) |
+|                  |                                                                                                                             |
+| :--------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| **Endpoint**     | `/api/validity`                                                                                                             |
+| **Method**       | `GET`                                                                                                                       |
+| **Query Params** | `{cid: string}`                                                                                                             |
+| **Response**     | See in [Rust](https://github.com/sablier-labs/v2-merkle-api/blob/main/src/data_objects/response.rs#L41) Overview TS (below) |
 
 ```typescript
 type Response = {
@@ -225,7 +231,3 @@ For more insight, check out the implementation details.
   subtitle="Github - sablier-labs/v2-merkle-api"
   title="validity.rs"
 />
-
-[api-create-response]: https://github.com/sablier-labs/v2-merkle-api/blob/main/src/data_objects/response.rs#L22
-[api-eligibility-response]: https://github.com/sablier-labs/v2-merkle-api/blob/main/src/data_objects/response.rs#L32
-[api-validity-response]: https://github.com/sablier-labs/v2-merkle-api/blob/main/src/data_objects/response.rs#L41
diff --git a/docs/api/merkle-api/03-examples.mdx b/docs/api/merkle-api/03-examples.mdx
@@ -18,8 +18,8 @@ To get a hold of a campaign's IPFS CID you can:
 
 <ol type="A">
   <li>
-    Check the [create](/contracts/v2/reference/periphery/interfaces/interface.ISablierV2MerkleStreamerFactory#Event)
-    event emitted by the Merkle factory
+    Check the [create](/contracts/v2/reference/periphery/interfaces/interface.ISablierV2MerkleLockupFactory#events)
+    events emitted by the Merkle factory
   </li>
   <li>Use the Sablier V2 [subgraphs / indexers](/api/overview) to query for that particular piece of information.</li>
 </ol>
@@ -63,17 +63,16 @@ For approach "B", run the following query against the official endpoints:
 
 ## Check eligibility for an address
 
-To check if an address is eligible, you'll have to use the
-[/api/eligibility](/api/merkle-api/functionality#eligibility-apieligibility) route provided by the v2-merkle-api
-backend.
+To check if an address is eligible, you'll have to use the [/api/eligibility](functionality#eligibility-apieligibility)
+route provided by the v2-merkle-api backend.
 
 #### Steps
 
-1. Get the campaign CID (see [the example](/api/merkle-api/examples#get-a-campaigns-cid) above)
+1. Get the campaign CID (see [the example](examples#get-a-campaigns-cid) above)
 2. Call the`/api/eligibility` route using the CID and the wallet address
 
 Please read more on the dedicated route documentation within the
-[/api/eligibility](<(/api/merkle-api/functionality#eligibility-apieligibility)>) section of the functionality page.
+[/api/eligibility](functionality#eligibility-apieligibility) section of the functionality page.
 
 As an alternative, you can also check the eligibility of an address (and bypass the backend) by simply searching for
 that address in the list stored within the IPFS file from step 1. You'll still have to download the file first, using
@@ -88,8 +87,8 @@ To get a hold of a `tokenId` linked to a claim you can:
 
 <ol type="A">
   <li>
-    Listen to the [claim](/contracts/v2/reference/periphery/interfaces/interface.ISablierV2MerkleStreamerLL#claim)
-    method and the Claim event emitted by the Merkle contract instance
+    Listen to the [claim](/contracts/v2/reference/periphery/interfaces/interface.ISablierV2MerkleLL#claim) method and
+    the Claim event emitted by the Merkle contract instance
   </li>
   <li>Use the Sablier V2 [subgraphs / indexers](/api/overview) to query for that particular piece of information.</li>
 </ol>
@@ -165,7 +164,7 @@ To check if a user has already claimed their stream from a campaign you can:
 
 <ol type="A">
   <li>
-    Call the [hasClaimed](/contracts/v2/reference/periphery/interfaces/interface.ISablierV2MerkleStreamer#hasclaimed)
+    Call the [hasClaimed](/contracts/v2/reference/periphery/interfaces/interface.ISablierV2MerkleLockup#hasclaimed)
     method form the Merkle contract instance
   </li>
   <li>Use the Sablier V2 [subgraphs / indexers](/api/overview) to query for that particular piece of information.</li>

diff --git a/docs/api/merkle-api/04-development.mdx b/docs/api/merkle-api/04-development.mdx
@@ -49,7 +49,8 @@ After a campaign is created via the API, we use Pinata to upload and pin the fil
 1. Click Create Key
 1. From the popup, take the API Key and the API Secret and put them in the `.env` file. The `IPFS_GATEWAY` variable can
    be any IPFS gateway but we recommend using a private one (Pinata offers this as well). For more details about the
-   interactions with IPFS, check [`src/services/ipfs.rs`](./src/services/ipfs.rs).
+   interactions with IPFS, check
+   [`src/services/ipfs.rs`](https://github.com/sablier-labs/v2-merkle-api/blob/main/src/services/ipfs.rs).
 1. Select the "Access Controls" tab
 1. Click on the "Request Token" button
 1. Copy the token and put in th `.env` file in the `PINATA_ACCESS_TOKEN` variable

diff --git a/docs/api/subgraphs/01-endpoints.mdx b/docs/api/subgraphs/01-endpoints.mdx
@@ -161,7 +161,7 @@ api.thegraph.com/subgraphs/name/sablier-labs/sablier-v2-<CHAIN>
 ## Sablier V2 - Airstreams
 
 This subgraph tracks the events emitted by the [`@sablier/v2-periphery`](/contracts/v2/reference/overview#periphery)
-contracts, specifically [`MerkleFactory`](contracts/v2/reference/periphery/contract.SablierV2MerkleStreamerFactory). It
+contracts, specifically [`MerkleFactory`](/contracts/v2/reference/periphery/contract.SablierV2MerkleLockupFactory). It
 deals with airstream-specific actions like the factory creating a campaign, admin clawbacks, or users claiming stream
 NFTs as defined in the attached Merkle tree.
 

diff --git a/docs/api/subgraphs/merkle/01-entities.mdx b/docs/api/subgraphs/merkle/01-entities.mdx
@@ -19,13 +19,13 @@ responsible of defining the following Sablier entities:
 
 ### Primary
 
-| Entity   | Description                                                                                                                |
-| -------- | -------------------------------------------------------------------------------------------------------------------------- |
-| Factory  | Instances of `SablierV2MerkleStreamerFactory`                                                                              |
-| Campaign | Instances of `SablierV2MerkleStreamerLL`, the primary entity tracking the up to date state of an Airstream/Merkle campaign |
-| Action   | Emitted events transformed into historical entries (e.g. Claim, Create, Clawback)                                          |
-| Activity | An entity tracking daily usage (one item per day) for each campaign (e.g. amount claimed per day)                          |
-| Asset    | The ERC20 asset that is being streamed                                                                                     |
+| Entity   | Description                                                                                                        |
+| -------- | ------------------------------------------------------------------------------------------------------------------ |
+| Factory  | Instances of `SablierV2MerkleLockupFactory`                                                                        |
+| Campaign | Instances of `SablierV2MerkleLL`, the primary entity tracking the up to date state of an Airstream/Merkle campaign |
+| Action   | Emitted events transformed into historical entries (e.g. Claim, Create, Clawback)                                  |
+| Activity | An entity tracking daily usage (one item per day) for each campaign (e.g. amount claimed per day)                  |
+| Asset    | The ERC20 asset that is being streamed                                                                             |
 
 ### Secondary
 

diff --git a/docs/api/subgraphs/merkle/02-queries.md b/docs/api/subgraphs/merkle/02-queries.md
@@ -4,7 +4,7 @@ sidebar_position: 2
 title: "Queries"
 ---
 
-Building on top of the [entity structure](/api/subgraphs/merkle/structure) defined earlier, here are some common GraphQL
+Building on top of the [entity structure](/api/subgraphs/merkle/entities) defined earlier, here are some common GraphQL
 queries for fetching data from the Sablier V2 subgraph.
 
 ### Recent streams

diff --git a/docs/api/subgraphs/protocol/02-structure.mdx b/docs/api/subgraphs/protocol/02-structure.mdx
@@ -120,15 +120,13 @@ while also marking them as the sender. In that case, this initial address will b
 :::warning Warning: Deprecated
 
 Sablier V2.0 involved users deploying a "PRBProxy" contract through which they interacted with the Sablier contracts.
-With Sablier V2.1+ this is not the case any more as streams are now designed to be managed without these forwarder
-contracts. Therefore, you don't need to worry about `proxenders` and `proxy` if you're not looking to support old
-versions of the protocol.
+With Sablier V2.1+, this is not the case any more as streams are now designed without any proxy contracts. Therefore,
+you don't need to worry about `proxenders` and `proxy` if you're not looking to support old versions of the protocol.
 
 :::
 
-[In V2.0] While not mandatory for the core functionality, Sablier (through its
-[periphery](https://github.com/sablier-labs/v2-periphery)) made use of
-[PRBProxy](https://github.com/paulrberg/prb-proxy). The official client interfaces provided support for functionality
+[In V2.0] While not mandatory for the core functionality, Sablier made use of [PRBProxy](https://github.com/paulrberg/prb-proxy)
+in its [periphery](https://github.com/sablier-labs/v2-periphery. The official client interfaces provided support for functionality
 exposed through both EOAs and this proxy integration, at the same time.
 
 For streams created within this "extended" ecosystem, a few attributes and entities will change meaning as such:

diff --git a/docs/api/subgraphs/protocol/03-flow.mdx b/docs/api/subgraphs/protocol/03-flow.mdx
@@ -9,7 +9,7 @@ title: "Data flow"
 In order to start indexing all whitelisted Lockup contracts we need a genesis event. With Sablier V2, there is no
 factory pattern so we couldn't rely on a
 [data source](https://thegraph.com/docs/en/developing/creating-a-subgraph/#data-source-templates) contract. The next
-best things for a "genesis" point was to rely on the first event triggered by the earliest registered on-chain contract
+best things for a "genesis" point was to rely on the first event triggered by the earliest registered onchain contract
 
 To reduce the number of dependencies required to kickstart a subgraph, we chose to rely on this approach instead of
 implementing a separate registry contract. Therefore, when setting up a deployment, you'll need to follow a few