Merge pull request #52 from SocketDotTech/fix/addresses

Fix/addresses

consts.ts

@@ -0,0 +1,2 @@
+export const DEPLOYMENT_URL =
+  "https://github.com/SocketDotTech/socket-DL/raw/master/deployments/prod_addresses.json";

docs/Build/Contract Setup/configuring-plugs.md

@@ -21,12 +21,12 @@ Plugs should be deployed on respective chains before they can be connected to th
 
 | Parameters | Description |
 | --- | --- |
-| siblingChainSlug | ChainSlug of the network the sibling plug is deployed on, you can find all [chainSlugs here](../../Dev%20Resources/Deployments.mdx) |
+| siblingChainSlug | ChainSlug of the network the sibling plug is deployed on, you can find all [chainSlugs here](../../dev-resources/Deployments.mdx) |
 | siblingPlug | Address of the plug deployed on the sibling chain |
 | inboundSwitchboard | Switchboard address used for receiving messages from siblingPlug |
 | outboundSwitchboard | Switchboard address used for sending messages to siblingPlug |
 
-You can find addresses for all verified Switchboards and Socket contracts in [Deployments](../../Dev%20Resources/Deployments.mdx)
+You can find addresses for all verified Switchboards and Socket contracts in [Deployments](../../dev-resources/Deployments.mdx)
 
 ## Connecting your Plugs
 
@@ -64,6 +64,6 @@ For reference, checkout [this example tx](https://goerli.etherscan.io/tx/0x37040
 
 Furthermore, you can do the following to check the connection is successful :
 - Call the `getPlugConfig` function on the Socket contract that returns the config for your Plug for a given destination ChainSlug
-- Use the [Check Connection API](../../Dev%20Resources/APIReference/CheckConnection.md) that reads the configs and aids you to make sure your connection is correct
+- Use the [Check Connection API](../../dev-resources/APIReference/CheckConnection.md) that reads the configs and aids you to make sure your connection is correct
 
 <!-- // TODO: ADD GIF; ITs time to send it -->

docs/Build/Contract Setup/receiving.md

@@ -24,7 +24,7 @@ interface IPlug {
 
 :::note
 
-Only [`Socket`](../../Dev%20Resources/Deployments.mdx) on a given chain should be allowed to call the `inbound` method on a Plug as seen in the example below.
+Only [`Socket`](../../dev-resources/Deployments.mdx) on a given chain should be allowed to call the `inbound` method on a Plug as seen in the example below.
 
 :::
 

docs/Build/Contract Setup/sending.md

@@ -44,4 +44,4 @@ Once the tx is finalised:
 - An event `MessageOutbound` is emitted by Socket containing all relavent details.
 - Your message will be allocated a unique ID called (`msgId`) you can look it up in the `MessageOutbound` log
 
-You can use the tx-hash to track the delivery and execution on the destination chain via [this API](../../Dev%20Resources/APIReference/Track.md).  
+You can use the tx-hash to track the delivery and execution on the destination chain via [this API](../../dev-resources/APIReference/Track.md).  

docs/Build/_MockSocket.txt

@@ -0,0 +1,24 @@
+---
+id: mock-socket
+title: Mock Socket
+# sidebar_position: 3
+---
+
+Once you've integrated Socket / PlugBase into your contract, you'd want to write tests, test the integration works as expected etc.
+
+MockSocket is a contract which simulates the interactions b/w your Plug and Socket. It does this by calling the `inbound` method 
+
+mocks the functioning of Socket's cross-chain message passing. 
+
+Using MockSocket you can write tests to verify your integration with Socket works as expected.
+
+For connecting to MockSocket you do this 
+
+For sending a message you do this 
+
+Here's how receiving works 
+
+If XYZ state change happens as expected, congrats things work as expected.
+
+### How it works 
+When a plug calls the `outbound` method on MockSocket, 

docs/Build/hello-world.md

@@ -6,7 +6,7 @@ sidebar_position: 1
 
 In this speed run tutorial, we'll be writing a contract to send/receive messages between chains. This is a code along tutorial, you can copy the code snippets into Remix or the dev environment of your choice. In case you are stuck, you can take peak at the [entire code on GitHub](https://github.com/SocketDotTech/socketDL-examples/blob/main/src/SpeedRunDL/SocketSpeedRunGoerli.sol). We'll be highlighting key functions and what they do throughout the tutorial. Some configuration variables have been hardcoded in the example.
 
-We'll be deploying the same copy of the contract on Goerli and Mumbai testnet and sending the message "Hello World" from Goerli to Mumbai. You can also deploy it on any [supported networks](../Dev%20Resources/Deployments.mdx). Let's get started!
+We'll be deploying the same copy of the contract on Goerli and Mumbai testnet and sending the message "Hello World" from Goerli to Mumbai. You can also deploy it on any [supported networks](../dev-resources/Deployments.mdx). Let's get started!
 
 
 ### Step 1 : Boilerplate code 
@@ -219,7 +219,7 @@ For instance, on Goerli you would call `connectPlug` with the address of the con
 
 ### Step 8 : Hello World
 
-To send your first message, call the `sendMessage` function on Goerli. You need to send a fee in ETH as `value` when calling `sendMessage`. This fee can be calculated using the [Fee Estimate API](../Dev%20Resources/APIReference/EstimateFee.md) 
+To send your first message, call the `sendMessage` function on Goerli. You need to send a fee in ETH as `value` when calling `sendMessage`. This fee can be calculated using the [Fee Estimate API](../dev-resources/APIReference/EstimateFee.md) 
 
 https://surge.dlapi.socket.tech/estimate-fees?srcChainSlug=5&dstChainSlug=80001&integrationType=FAST&msgGasLimit=100000
 
@@ -229,7 +229,7 @@ You can enter the `totalFee` returned by this API as `value` when sending the tr
 
 <br/><br/>
 
-That's it! You can now track the status of your message using the [Status Tracking API](../Dev%20Resources/APIReference/Track.md). Once your message is executed on Mumbai, you'll be able to see the `message` value set to "Hello World" on Mumbai.
+That's it! You can now track the status of your message using the [Status Tracking API](../dev-resources/APIReference/Track.md). Once your message is executed on Mumbai, you'll be able to see the `message` value set to "Hello World" on Mumbai.
 
 <img src="/img/success-hello-world.png" width="400px"/>
 
@@ -238,6 +238,6 @@ That's it! You can now track the status of your message using the [Status Tracki
 
 :::note You're Plugged!
 
-You've successfully sent your first message via SocketDL. Explore more in [Tutorials](../Dev%20Resources/TutorialSection/Counter.md) and [Examples](./ExampleSection/examples.md).
+You've successfully sent your first message via SocketDL. Explore more in [Tutorials](../dev-resources/TutorialSection/Counter.md) and [Examples](./ExampleSection/examples.md).
 
 :::

docs/Build/testing-DL.md

@@ -4,17 +4,23 @@ title: Testing integration
 sidebar_position: 3
 ---
 
-### Testing SC integration
+- Testing DL 
+- MockSocket -- how it works, local testing 
+- Testing Plug connection 
+
+### MockSocket
+
+### Testing integration locally
 MockSocket is a test tool that Plugs can use to test their integration with Socket. MockSocket simulates the functionality of Socket without actually sending a cross-chain message. It does this by calling the `inbound` method on the Plug directly when an `outbound` message transaction is initiated. 
 
 Plugs can use MockSocket to test their SC integration with Socket. Find example tests that utilise MockSocket in [`SocketDL-examples`](https://github.com/SocketDotTech/socketDL-examples/tree/main/test). Plugs can assert the intended state changes on the destination chain and verify successful execution of the message.
 
-MockSocket is not an E2E testing solution for message delivery on Plugs. It does not account for validity of message, gasPrice hikes on blockchains etc. For E2E testing, Plugs can be deployed on any [supported testnets](../Dev%20Resources/Deployments.mdx).
+MockSocket is not an E2E testing solution for message delivery on Plugs. It does not account for validity of message, gasPrice hikes on blockchains etc. For E2E testing, Plugs can be deployed on any [supported testnets](../dev-resources/Deployments.mdx).
 
 ### Testing Plug connection
 
 #### API
-The [Check Connection helper API](../Dev%20Resources/APIReference/CheckConnection.md) can be used to verify a connection is successfully established between two Plugs.
+The [Check Connection helper API](../dev-resources/APIReference/CheckConnection.md) can be used to verify a connection is successfully established between two Plugs.
 
 
 #### On-chain

docs/Learn/Components/Switchboards.md

@@ -8,7 +8,7 @@ Switchboards contain the following things:
 
 Switchboards allow developers to permissionlessly authenticate Packets before they get executed on their Plugs, we think there are various authenticaion models that people can leverage to manage tradeoffs for their applications. 
 
-Anyone can build a switchboard that satisfies the [ISwitchboard interface](../../Dev%20Resources/Interfaces/ISwitchboard.md). It needs to be registered to Socket before Plugs can use it via the `registerSwitchboard()` method on Socket. Registering a Switchboard is completely permissionless. 
+Anyone can build a switchboard that satisfies the [ISwitchboard interface](../../dev-resources/Interfaces/ISwitchboard.md). It needs to be registered to Socket before Plugs can use it via the `registerSwitchboard()` method on Socket. Registering a Switchboard is completely permissionless. 
 
 Socket Labs has bootstrapped some switchboards with different tradeoffs for end developers, we encourage developers to feel free to leverage these switchboards if they are suitable for their usecase.
 - Optimistic Switchboard: Allow 1/N trust-minimised and cheap validation by introducing a challenge mechanism pre-execution where N parties can stop the packet from getting executed. This Switchboard will be extremely cheap to leverage but will have a latency of the challenge period. 

docs/Learn/Concepts/Fees.md

@@ -25,14 +25,14 @@ Plugs need to pay a fee for getting messages included in packets, verified on th
 | Execution Fee | Fees paid to Executors for executing the message payload on the destination chain |
 
 ### Estimating Fees 
-Fees can be estimated off-chain using the [Fee Estimation API](../../Dev%20Resources/APIReference/EstimateFee.md). The API calculates the total fee to be sent while sending a message and also returns a breakdown of each fee component.
+Fees can be estimated off-chain using the [Fee Estimation API](../../dev-resources/APIReference/EstimateFee.md). The API calculates the total fee to be sent while sending a message and also returns a breakdown of each fee component.
 
 ### Estimating Fees on-chain 
 
 Sending a cross-chain message requires the message to be verified and executed on the destination chain and the fees for this need to be calculated with the destination chain `gasPrice`. But the gasPrice of the destination chain is not known on the source chain. To enable this calculation, Socket maintains an siblingChain gas fee mapping on the ExecutionManager, TransmitManager and Switchboards. These fees are updated periodically by off-chain agents with the `FEES_UPDATER_ROLE`
 
 #### How to fetch fee estimate
-Plugs can use [ISocket](../../Dev%20Resources/Interfaces/ISocket.md) to call `getMinFees` method on Socket. This method takes the payload execution gasLimit, destination chain ID, payload size and plug address as input and calculates the total fee. This enables Plugs to be completely on-chain and not rely on any off-chain services for fee calculation or to interact with Socket. 
+Plugs can use [ISocket](../../dev-resources/Interfaces/ISocket.md) to call `getMinFees` method on Socket. This method takes the payload execution gasLimit, destination chain ID, payload size and plug address as input and calculates the total fee. This enables Plugs to be completely on-chain and not rely on any off-chain services for fee calculation or to interact with Socket. 
 
 `getMinFees` returns the totalFee, which is to be sent in the native token of the chain when calling `outbound` on Socket. 
 

docs/Learn/Concepts/Tracking.md

@@ -18,7 +18,7 @@ title: Tracking Messages & Packets
 
 When plugs send a message, a `MessageOutbound` event is emitted with a `msgId`, which is a unique identifier for each message. This is generated by performing bitwise operations on the local chain ID and message count
 
-The status of a message can be tracked using an API built by Socket. More on this in [Status Tracking API](../../Dev%20Resources/APIReference/Track.md)
+The status of a message can be tracked using an API built by Socket. More on this in [Status Tracking API](../../dev-resources/APIReference/Track.md)
 
 Socket transmits packets from one chain to another. Messages need to get included into these packets to be delivered to the destination chain. Packets are also assigned a unique identifier `packetId`, generated from the local chain ID, capacitor address and packet count on given capacitor. 
 

docs/Learn/_category_.json

@@ -1,6 +1,6 @@
 {
   "label": "Learn about DL",
-  "position": 3,
+  "position": 4,
   "link": {
     "type": "generated-index",
     "description": "Introduction to SocketDL"

docs/Learn/glossary.md

@@ -8,11 +8,11 @@ We have introduced a lot of new terms and that is by design. We think for someth
 
 Here is a quick run-down of some of the terms that you will come across the entire documentation:
 - **Socket**: Socket is the [core contract](https://github.com/SocketDotTech/socket-DL/blob/master/contracts/socket/Socket.sol) deployed on all networks that are supported. All core modules and functions exist within Socket
-- **Plug/Plugs**: Plugs are smart contract applications that connect with Socket to send and receive cross-chain messages via the [IPlug interface](../Dev%20Resources/Interfaces/IPlug.md). Plugs are generally adapter contracts that connect your main Smart contract to the messaging infrastructure.
+- **Plug/Plugs**: Plugs are smart contract applications that connect with Socket to send and receive cross-chain messages via the [IPlug interface](../dev-resources/Interfaces/IPlug.md). Plugs are generally adapter contracts that connect your main Smart contract to the messaging infrastructure.
 - **Message**: Message is the payload you want to transmit along with relavent meta-data like destination chainSlug etc. 
 - **Packet**: Packets are a collection of messages sent from one chain to another. The validity of messages in a packet is verified on the destination chain based on the logic prescribed in the configured switchboard. [Read more](./Components/Packet.md).
 - **Sealed Packet**: As soon as the transmitter seals the packet on the source-chain with their signature it's called "SealedPacket". Read more about how transmitters work [here](./lifecycle.md#sending-a-message). 
 - **Capacitor**: Capacitor is responsibile for storing messages in the form of a Packet. The packet is released when the transmitter calls the `sealPacket` method on the capacitor. Capacitors allow for native batching of payloads for better gas-performance. [Read more](./Components/Capacitors.md).
 - **Switchboard**: Switchboards are the authenticaion/verification modules that allow developers to have custom verification for their payloads/messages. They can be permissionlessly built and deployed by the community. [Read more](./Components/Switchboards.md)
 - **Transmitter**: Transmitters are the entities responsible for transmission of Packet across layers, their activity is completely on-chain and managed by TransmitManager. [Read more](./Components/TransmitManager.md)
-- **ChainSlug**: ChainSlug is a unique identifier for a particular network or Socket deployment. It's different than Chain ID or Network ID used on EVM networks. You can find the assigned ChainSlugs in the [deployments section](../Dev%20Resources/Deployments.mdx)
+- **ChainSlug**: ChainSlug is a unique identifier for a particular network or Socket deployment. It's different than Chain ID or Network ID used on EVM networks. You can find the assigned ChainSlugs in the [deployments section](../dev-resources/Deployments.mdx)

docs/Learn/lifecycle.md

@@ -61,4 +61,4 @@ Once the packet is verified, executors then call `execute` on a message. During
 
 If these are verified, then the message can be executed. `Executors` call the execute() method on Socket which checks if the above cases are verified and calls the `inbound` method on the destination plug. It passes the designated payload to the Plug, which can be arbitrarily executed.
 
-In case the message cannot be executed due to insufficient gas limit or other errors, Socket will re-try execution periodically. More in [Execution Failure](../Dev%20Resources/TutorialSection/RetryMessageExecution.md).
+In case the message cannot be executed due to insufficient gas limit or other errors, Socket will re-try execution periodically. More in [Execution Failure](../dev-resources/TutorialSection/RetryMessageExecution.md).

docs/dev-resources/_Troubleshoot.txt

@@ -0,0 +1,15 @@
+---
+id: troubleshoot
+title: Troubleshooting Integration
+# sidebar_position: 3
+---
+
+Packet not sealed on Source Chain 
+
+Packet not proposed on Destination chain (You can do this directly, yay!)
+
+Packet not executed yet 
+    - see if gasLimit is insufficient 
+    - or message itself is reverting 
+    - Put hash in tenderly, debug
+    - cache stuff (see how stargate does this) and retry 

docs/introduction.mdx

@@ -17,7 +17,7 @@ Together, these enable building robust cross-chain applications
 1. **Arbitrary Message Passing** : Arbitrary Message Passing allows a contract on Chain A to send a message (`bytes` encoded) to a contract on Chain B. This allows contracts on different chains to read and write to each other's state.
 2. **Modular Architecture** : SocketDL has a modular architecture which allows dApps to choose parts of the Socket stack they'd like to use. For instance, dApps can use Socket for message verification and validation, but can build their own off-chain agents for message delivery and execution.
 3. **Security w/ Configurability** : Socket allows [Plugs](./Learn/Components/Plugs.md) to configure [Switchboards](./Learn/Components/Switchboards.md) used for message passing w/ other plugs. dApps can configure different levels of security using switchboards. For example, using native bridge for critical messaging, but n/n validator consensus for faster relatively less secure communication.
-4. **Easy spec to build** : Smart contracts simply need to inherit [PlugBase](https://github.com/SocketDotTech/socketDL-examples/blob/main/src/base/PlugBase.sol) and support a simple [interface](./Dev%20Resources/Interfaces/IPlug.md) to add cross-chain capabilities to its functions
+4. **Easy spec to build** : Smart contracts simply need to inherit [PlugBase](https://github.com/SocketDotTech/socketDL-examples/blob/main/src/base/PlugBase.sol) and support a simple [interface](./dev-resources/Interfaces/IPlug.md) to add cross-chain capabilities to its functions
 
 Learn more about SocketDL [architecture](./Learn/protocol-architecture.md), [message lifecycle](./Learn/lifecycle.md) & [components](./Learn/Components/_category_.json).
 

package.json

@@ -26,7 +26,8 @@
     "postcss": "^8.4.23",
     "prism-react-renderer": "^1.3.5",
     "react": "^17.0.2",
-    "react-dom": "^17.0.2"
+    "react-dom": "^17.0.2",
+    "swr": "^2.2.2"
   },
   "devDependencies": {
     "@docusaurus/module-type-aliases": "2.2.0",

src/components/Contracts/SwitchboardAddresses.tsx

@@ -1,4 +1,4 @@
-import React, { useState } from "react";
+import React, { useEffect, useState } from "react";
 import Dropdown from "./Dropdown";
 import deployments from "./deployments.json";
 import { config } from "./config";

src/components/Contracts/config.ts

@@ -23,4 +23,16 @@ export const config = {
     blockExplorerUrl: "https://arbiscan.io",
     logoURI: "https://movricons.s3.ap-south-1.amazonaws.com/Arbitrum.svg",
   },
+  56: {
+    chainId: 56,
+    chainName: "BNB Chain",
+    blockExplorerUrl: "https://bscscan.com",
+    logoURI: "https://movricons.s3.ap-south-1.amazonaws.com/BSC.svg",
+  },
+  2999: {
+    chainId: 2999,
+    chainName: "Aevo",
+    blockExplorerUrl: "https://explorer.aevo.xyz",
+    logoURI: "/img/aevo-logo.png",
+  },
 };