Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed broken Router github link on the Router Library page #263

Merged
merged 3 commits into from
Dec 13, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/protocol/ISM/third-party-ISMs/optimistic-ISM.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
2 changes: 1 addition & 1 deletion docs/reference/libraries/mailboxclient.mdx
Original file line number Diff line number Diff line change
@@ -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:

Expand Down
2 changes: 1 addition & 1 deletion docs/reference/libraries/router.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down