diff --git a/docs/using-platform/11_middleware.md b/docs/using-platform/11_middleware.md
index 04cffd5d..1ddd2a16 100644
--- a/docs/using-platform/11_middleware.md
+++ b/docs/using-platform/11_middleware.md
@@ -15,7 +15,7 @@ Follow these steps to add the middleware:
 1. Select to which of your **smart contract sets** the middleware needs to connect, and click **Continue**.
 2. Choose [Graph Middleware](#the-graph-middleware) or [Smart Contract Portal Middleware](#the-smart-contract-portal-middleware)
 3. Choose a **Middleware name**. Choose one that will be easily recognizable in your dashboards.
-4. Select the **storage provider**
+4. Select the **storage provider** if needed.
 5. Choose a **deployment plan**. Select the type, cloud provider, region and resource pack. [More about deployment plans.](../launch-platform/managed-cloud-deployment/13_deployment-plans.md)
 6. You see the **resource cost** for this middleware displayed at the bottom of the form. Click **Confirm** to add the smart contract set.
 
@@ -48,10 +48,10 @@ Navigate to the **smart contract set** that you connected to the middleware, go
 
 #### Subgraph raw configuration
 
-Inside the root you will find a file called `subgraph.config.template.json` that contains the raw configuration of the subgraph. The important section is the **datasources** section.
+Inside the root you will find a file called `subgraph.config.json` that contains the raw configuration of the subgraph. The important section is the **datasources** section.
 
 - **Name** - here we defined the smart contracts with their name (the name of the artifact created in the 'deployments' folder when running the deploy task)
-- **Address & Startblock** - You will notice the startblock and address to be 0. These will be filled in using the `graph:config` task based on the hardhat deployments.
+- **Address & Startblock** - You will notice the startblock and address to be 0. You must fill these in when your contract has been deployed. The block number and the address can be found in the **deployment** folder, under **ignition**.
 - **Module** - In the modules array all the indexing modules to activate for this smart contract.
 
 #### About the indexing modules
@@ -88,22 +88,17 @@ Follow these steps to create a custom indexing module:
 
 - Primitives to generate a GraphQL schema: `subgraph/datasource/x.gql.json` - In order to allow composability, the schema are not defined in the GraphQL format but rather in a dedicated JSON format which is can be assembled and compiled to GraphQL.
 - Template to generate a subgraph manifest: `subgraph/datasource/x.yaml` - This file lists all the events that the datasources should listen to, and links that to the corresponding indexing logic.
-- Indexing logic: `subgraph/datasources/x.ts` and (optionally) `subgraph/fetch/x.ts` - This is the core logic that processes the events and to index the onchain activity.
+- Indexing logic: `subgraph/datasources/x.ts` and (optionally) `subgraph/fetch/x.ts` - This is the core logic that processes the events to index the onchain activity.
 
 [To learn more, check it out on Github.](https://github.com/OpenZeppelin/openzeppelin-subgraphs)
 
-#### Tweak the subgraph configuration
-
-You can tweak the `subgraph.config.template.json` file to your liking, and run the `graph:config task`. This will generate `subgraph.config.json` for the next steps.
+#### Start your subgraph
 
 The following tasks need to be run in this sequence:
 
-- `graph:compile` - Uses `subgraph.config.json` to generate the GraphQL schema and subgraph configuration.
-- `graph:codegen` - Generates the AssemblyScript types for your contracts ABI based on the output of `graph:compile`.
-- `graph:build` - Compiles the WASM files based on the outputs generated by `graph:codegen`.
-- `graph:deploy` - Deploys the WASM files to IPFS and updates the middleware to start or update the indexing.
-
-To make this a bit easier, the `graph:all` task executes all these steps in the right order.
+- `btp-scs subgraph codegen` - Generates the AssemblyScript types for your contracts ABI.
+- `btp-scs subgraph build` - Compiles the WASM files based on the outputs generated by `btp-scs subgraph codegen`.
+- `btp-scs subgraph deploy` - Deploys the WASM files to IPFS and updates the middleware to start or update the indexing.
 
 The indexing of your smart contracts has now started. This can take a while, but once done you can query the middleware for your data in seconds using the **GraphQL API**. You can find the **endpoint** in the **Connect-tab**.
 
@@ -166,25 +161,25 @@ Standard Webhooks has built [SDKs and useful tools](https://www.standardwebhooks
 An example using Typescript, [Elysia](https://elysiajs.com/) and [standard webhooks](https://www.standardwebhooks.com/).
 
 ```ts
-import { Elysia, t } from "elysia";
-import { Webhook } from "standardwebhooks";
+import { Elysia, t } from 'elysia';
+import { Webhook } from 'standardwebhooks';
 
 async function webhookConsumerBootstrap(secret: string) {
   const webhookConsumer = new Elysia().post(
-    "/scp-listener",
+    '/scp-listener',
     ({ headers, body }) => {
       try {
         const wh = new Webhook(btoa(secret));
         const verifiedPayload = wh.verify(JSON.stringify(body.payload), {
-          "webhook-id": headers["btp-portal-event-id"]!,
-          "webhook-signature": headers["btp-portal-event-signature"]!,
-          "webhook-timestamp": headers["btp-portal-event-timestamp"]!,
+          'webhook-id': headers['btp-portal-event-id']!,
+          'webhook-signature': headers['btp-portal-event-signature']!,
+          'webhook-timestamp': headers['btp-portal-event-timestamp']!,
         });
         console.log(
           `Received a webhook event: ${JSON.stringify(verifiedPayload)}`
         );
       } catch (err) {
-        console.error("Webhook payload invalid", err);
+        console.error('Webhook payload invalid', err);
         throw err;
       }
     },
@@ -211,7 +206,7 @@ async function webhookConsumerBootstrap(secret: string) {
 webhookConsumerBootstrap(process.env.WEBHOOK_SECRET!)
   .then((app) => app.listen(process.env.PORT || 5555))
   .catch((error: Error) => {
-    console.error("Failed to start webhook consumer", error);
+    console.error('Failed to start webhook consumer', error);
     process.exit(1);
   });
 ```
@@ -223,7 +218,7 @@ The websocket endpoint exposes functionality to get real time updates on process
 The url can be copied from the Connect tab.
 
 ```ts
-import type { TransactionReceipt } from "viem";
+import type { TransactionReceipt } from 'viem';
 
 // Should include an api key (eg wss://smart-contract-portal-middleware.settlemint.com/sm_pat_.../ws)
 const webSocketHost = process.env.WS_URL!;
@@ -247,7 +242,7 @@ export async function waitForTransactionReceipt(transactionHash: string) {
     webSocket.onerror = reject;
     webSocket.onclose = () => {
       if (!isResolved) {
-        reject(new Error("Nothing received from the WebSocket"));
+        reject(new Error('Nothing received from the WebSocket'));
       }
     };
     if (webSocket.readyState === WebSocket.OPEN) {
@@ -283,4 +278,4 @@ When setting up a new middleware, you'll need to adjust the Attestation Indexer
 
 The Attestation Indexer's GraphQL API provides the capability to execute intricate queries on attestations. It allows for filtering based on attributes such as type, issuer, and subject, enabling the retrieval of specific attestations or sets of attestations that satisfy particular conditions.
 
-![GraphQL](../../static/img/using-the-platform/eas-graphql.png)
\ No newline at end of file
+![GraphQL](../../static/img/using-the-platform/eas-graphql.png)
diff --git a/docs/using-platform/12_firefly.md b/docs/using-platform/12_firefly.md
index 6749d94f..ea208b30 100644
--- a/docs/using-platform/12_firefly.md
+++ b/docs/using-platform/12_firefly.md
@@ -7,7 +7,7 @@ Firefly FabConnect is an open-source middleware that lets you interact with your
 - Check any transaction receipt.
 - Create event streams and subscriptions.
 
-:::warning
+:::warning Warning
 
 Before you start, make sure you are running: