From 75ac4a9d6f5aaf7aade2b474b30ade3862868536 Mon Sep 17 00:00:00 2001 From: Kols Date: Mon, 9 Dec 2024 10:22:33 +0100 Subject: [PATCH 1/3] chore: fixed broken links on Optimistic ISM page --- docs/protocol/ISM/third-party-ISMs/optimistic-ISM.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/protocol/ISM/third-party-ISMs/optimistic-ISM.mdx b/docs/protocol/ISM/third-party-ISMs/optimistic-ISM.mdx index a35d204d..a259428e 100644 --- a/docs/protocol/ISM/third-party-ISMs/optimistic-ISM.mdx +++ b/docs/protocol/ISM/third-party-ISMs/optimistic-ISM.mdx @@ -6,7 +6,7 @@ Prioritizing safety over liveness `OptimisticISM` is coming soon and is not yet implemented. This page is shown for informational purposes only. Details may change as the design matures. ::: -The `OptimisticISM` encodes the optimistic verification security model pioneered by [Optics](https://docs.celo.org/protocol/bridge/optics) and adopted by [Synapse](https://docs.synapseprotocol.com/synapse-interchain-network-sin/synapse-interchain-network/deep-dive-optimistic-pos), [Nomad](https://docs.nomad.xyz/the-nomad-protocol/verification-mechanisms/optimistic-verification), and [Connext](https://blog.connext.network/optimistic-bridges-fb800dc7b0e0). +The `OptimisticISM` encodes the optimistic verification security model pioneered by [Optics](https://docs.celo.org/protocol/bridge/optics) and adopted by [Synapse](https://docs.synapseprotocol.com/docs/RFQ/Security/#proofs), [Nomad](https://docs.nomad.xyz/the-nomad-protocol/verification-mechanisms/optimistic-verification), and [Connext](https://blog.connext.network/optimistic-bridges-fb800dc7b0e0). `OptimisticISMs` rely on a fraud window after message verification, during which `m` of `n` **watchers** configured on the `OptimisticISM` have an opportunity to flag messages as fraudulent, preventing them from being delivered to their recipient. From ad2b86461d450f8c5fc263f7d847765f441c031e Mon Sep 17 00:00:00 2001 From: Kols Date: Mon, 9 Dec 2024 10:48:56 +0100 Subject: [PATCH 2/3] fixed broken MailboxClient github link on the Mailbox Client Library page --- docs/reference/libraries/mailboxclient.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/reference/libraries/mailboxclient.mdx b/docs/reference/libraries/mailboxclient.mdx index ba27f683..850fe61e 100644 --- a/docs/reference/libraries/mailboxclient.mdx +++ b/docs/reference/libraries/mailboxclient.mdx @@ -1,6 +1,6 @@ # `MailboxClient` Library -Inheriting from [`MailboxClient`](https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/v3/solidity/contracts/MailboxClient.sol) is a simple way to ensure your contract knows where to send or receive interchain messages to or from. +Inheriting from [`MailboxClient`](https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/v3/solidity/contracts/client/MailboxClient.sol) is a simple way to ensure your contract knows where to send or receive interchain messages to or from. This mix-in contract maintains a pointers to the three contracts Hyperlane developers may need to interact with: From e0185768fa7e00694f21e096cefd7990c6743d9d Mon Sep 17 00:00:00 2001 From: Kols Date: Mon, 9 Dec 2024 11:41:08 +0100 Subject: [PATCH 3/3] chore: fixed broken Router github link on the Router Library page --- docs/reference/libraries/router.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/reference/libraries/router.mdx b/docs/reference/libraries/router.mdx index 870b36db..503c9fa3 100644 --- a/docs/reference/libraries/router.mdx +++ b/docs/reference/libraries/router.mdx @@ -2,7 +2,7 @@ import RouterDiagram from "@site/src/diagrams/router.md"; # `Router` Library -Application developers looking to write their contracts once and deploy them on multiple chains should consider building with the [`Router`](https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/solidity/contracts/Router.sol) pattern. +Application developers looking to write their contracts once and deploy them on multiple chains should consider building with the [`Router`](https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/v3/solidity/contracts/client/Router.sol) pattern. In this pattern, an instance of the application's contracts is deployed on each application-supported chain. Each instance is made aware of the addresses of instances on other chains. These instances use Hyperlane to communicate information and state to and from instances on remote chains.