Incorporate review comments in migration guide

Author: devendran-m

condor/migration-guide.md

@@ -18,24 +18,98 @@ Exchanges have different levels of integration with Casper Network, and offer di
 | **[SDK integration](#)** | Some exchanges use the publicly available Casper SDKs (e.g. JavaScript SDK, C#.NET SDK, Go SDK, etc.) | Depending on the SDK language (e.g. JS, Go) and the methods you use, you may or may not need to migrate prior to mainnet launch |
 
 ## Integration-specific Migration Documentation
+
 ### Running our own node
 If you run your own node, your migration experience will likely involve two distinct paths. 
 
 On the one hand, as a node operator you will participate in the actual mainnet upgrade of Casper Network, which will take place a specific date and time (you will have a number of days to stage the upgrade in advance of the activation point), while on the other hand you will have to possibly migrate the method by which you interface with your own node. Continue with the migration details provided for exchanges with direct RPC integration or SDK integration, depending on which applies to you.
 
 ### RPC Integration
-Casper 2.0 implements a number of changes to the JSON RPC interface of the node, which includes new methods, renamed methods and methods with a change in response format. 
-Importantly, the block structure is different in Casper 2.0 vs. Casper 1.x, and `Deploys` have been renamed to `Transactions`. 
 
-At the same time, legacy (Casper 1.x) deploys will continue to be accepted by Casper 2.0, hence if your entire integration comprises only the submission of Deploys (such as transfers in and out of accounts), you may not have to make any changes prior to mainnet activation of Casper 2.0. 
+**Casper Sidecar**
+
+One of the major changes in the **Casper 2.0** upgrade is the introduction of **[casper-sidecar](https://github.com/casper-network/condor-info/blob/a7af985d60aa719454cbd219d4982bd5c79eee84/articles/034-sidecar.md)**.  
+
+The **sidecar** runs as a dedicated process, bound to a node’s **binary port** and/or **SSE port**. It takes full responsibility for running the **JSON-RPC server** and exposing **JSON-RPC endpoints** to the internet.  
+
+As a result, the **node software itself no longer exposes a JSON-RPC API** to consumers—this function is now handled exclusively by the **sidecar**.
+
+**Node Binary Port**
+
+The Casper 2.0 Node now exposes a pure Binary Port API, which allows connection over TCP/IP and pure binary serialization for your remote procedure calls. Depending on your use case, you may be interested in considering this option for interacting with Casper v2.0.
+
+- **Key Considerations:**</br>
+  - Enabling Binary Port for Forward-Facing APIs
+    - Sidecar Dependency: In Casper 2.0, the JSON-RPC service is moved to the casper-sidecar, which forwards requests to the node’s binary RPC port​. 
+    - Operators who need a public-facing API must enable the binary port on the node (the sidecar is a consumer of this service​)
+    - Binary Port doesn't need to be a public port (it only needs to be exposed to sidecar)
+
+**SSE (Server Side Events) Server**
+
+Casper 2.0 introduces a realtime API of events, emitted by the node when processing blocks and/or transactions.
+
+
+**Transactions in Casper 2.0**  
+
+Transactions are a higher-order concept that encapsulate both **Deploys** and **V1 transactions**.  
+
+A **Transaction** is a polymorphic data structure that, for now, can be either:  
+- A **Deploy**, which remains compliant with the **1.x definition**.  
+- A **V1 transaction**, representing the new standard moving forward.  
+
+Secondly, Casper 2.0 includes new methods, renamed methods and methods with a change in response format. 
+
+At the same time, Casper 1.x deploys will continue to be accepted by Casper 2.0, hence if your entire integration comprises only the submission of Deploys (such as transfers in and out of accounts), you may want to take into account the below considerations prior to Mainnet activation of Casper 2.0. 
+
+### Preparing for Casper 2.0: Compatibility Considerations  
 
-➡️ To assess your next steps, please evaluate your integration agains the 1.x -> 2.0 JSON RPC changes detailed in this document. 
+Exchanges **may not need to make immediate changes** before the mainnet activation of **Casper 2.0**; however, this depends on how they interact with the network.  
+
+While the **account-put-deploy** JSON-RPC method continues to accept the same input structure as in **1.x**, the response format of **info_get_deploy** is **not backwards compatible** with **1.x**.  
+
+If an exchange relies on the results of **info_get_deploy**, updates will be required to handle the new response format properly.  
+
+Using 1.x Deploys in a 2.x Node:
+
+   - Casper 2.0 introduces a new Transaction model (replacing the old “Deploy”), but it will continue to accept and execute valid 1.x deploys for now​.
+   
+   - Casper Sidecar's `account_put_deploy` will be compatible with 1.x node `account_put_deploy`
+   
+   - This means the sidecar’s deploy submission method (`account_put_deploy`) remains usable with Casper 2.0 nodes, preserving compatibility for existing integration code. (In the Casper 2.0 JSON-RPC, this method is formally renamed to `account_put_transaction`​)
+   
+   - However, Casper Sidecar's `info_get_deploy` isn't 100% compatible with 1.x nodes `info_get_deploy`. 
+
+Therefore, Exchanges should review how they retrieve deploys/transactions and be aware of the response schema changes when querying for transaction status or details. For schema changes please refer the link [here](https://docs.casper.network/condor/jsonrpc#json-rpc-schema-definitions). 
+
+
+>[!IMPORTANT]
+> **Deprecation of 1.x Structures (e.g. Deploys)**
+> 
+> **1.x structures, such as Deploys, are being deprecated.** While they will continue to function in **Casper 2.0**, they are scheduled to be phased out.  
+> 
+> Exchanges should be aware of this evolution and prepare for the transition towards **TransactionV1** as the go-forward model.
+
+#### **Action Required**  
+
+➡️ Exchanges should review their integration and assess whether their systems depend on **info_get_deploy** results. If so, necessary updates must be made to ensure compatibility with **Casper 2.0**.
+
+➡️ To assess your next steps, please evaluate your integration against the 1.x -> 2.0 JSON RPC changes detailed in the link [here](https://docs.casper.network/condor/jsonrpc#json-rpc-schema-definitions). 
+
+Please refer to this [page](https://docs.casper.network/condor/jsonrpc) for more details on **casper-sidecar** and **JSON RPC** changes.
 
 ### SDK Integration
-Depending on which SDK language (e.g. JS, Go) you use, and which methods you interface with, you might not have to immediately migrate your integration. However, in order to be safe and future-proof, it is strongly recommended to upgrade your SDK to the latest version applicable to your stack. For most languages, this can be done immediately, as the SDKs maintain both forward (2.x) and backward (1.x) compatibility at the same time. 
+Depending on which SDK language (e.g. JavaScript, Go) you use, and which methods you interface with, you might not have to immediately migrate your integration. However, in order to be safe and future-proof, it is strongly recommended to upgrade your SDK to the latest version applicable to your stack. For most languages, this can be done immediately, as the SDKs maintain both forward (2.x) and backward (1.x) compatibility at the same time. 
 
 While it may not be strictly necessary to upgrade your integration if all you do is submit Deploys to the network (e.g. transfers in and out of accounts), it is STRONGLY RECOMMENDED to upgrade to the new SDK now, to experience a seamless upgrade to Casper 2.0 and beyond.
 
+>[!IMPORTANT]
+> **Addressable Entity is not enabled in Casper 2.0.**
+> 
+> Updating to a Casper 2.0-compatible SDK will be necessary when the **addressable entity** is enabled.
+> 
+> Once the **addressable entity** is enabled, exchanges will be required to use an SDK compatible with the Entity.
+
+
 Please see instructions below for your specific SDK language:
 
 | SDK    | Instructions |