GITBOOK-28: change request with no subject merged in GitBook

Author: Eddie Ye

.gitbook/assets/Connext_quick_overview.png

@@ -0,0 +1,61 @@
+# What is Connext?
+
+Connext is a modular protocol for securely passing funds and data between chains. Developers can use Connext to build crosschain apps (**xApps**) - applications that interact with multiple domains (blockchains and/or rollups) simultaneously.
+
+## Why Do We Need xApps?
+
+Blockchains do not scale to the level of volume needed for mainstream adoption.
+
+Ethereum and other programmable blockchains solve this problem by [moving users, funds, and data to multiple parallel domains](https://ethereum.org/en/layer-2/) (sidechains, rollups, and other chain-like constructions). This, however, creates a new challenge: a _fragmented_ user experience.
+
+Similar to how Youtube users do not need to understand Google's distributed database infrastructure, decentralized application users should not need to consciously think about what chain they are on, or how to move between chains. In other words, applications should _abstract_ the multichain experience by becoming xApps, and do so while retaining the security and trust-minimization properties of the underlying chains.
+
+## Design Philosophy
+
+Connext is built with three core design principles in mind that make it the best option for developers looking to build xApps without compromising on trustlessness.
+
+### Modularity
+
+Connext utilizes a modular hub-and-spoke architecture, which derives its security from Ethereum L1 and _plugs into_ the battle-tested **canonical** messaging bridges that underpin the security of each Ethereum-connected domain.
+
+Messages in Connext are added to a merkle root generated on each spoke domain, which are then optimistically aggregated into a singular root on Ethereum L1. In the event that fraud occurs, the system falls back to using the canonical messaging bridge for each chain ecosystem. In other words, a message passed between Polygon and Optimism is secured by a proof that is posted to Ethereum and verified by the Polygon PoS bridge and Optimism rollup bridge. Similarly, a message passed within the Cosmos ecosystem is verified by IBC.
+
+This mechanism gives developers the **best possible** trust guarantees for whichever chains they want to build on. For fraud to occur in our Polygon to Optimism example, there would need to be a compromise of Polygon or Optimism's canonical bridges _and_ Connext's failsafe mechanisms.
+
+### Security
+
+Bridges and crosschain messaging are some of the most critical infrastructure in the space, with a high potential risk for catastrophe in the event of hacks or bugs. In the past 18 months, almost **$2B** has been lost to bridge hacks.
+
+Connext utilizes Watchers, automated offchain actors, that observe the network and halt message passing in the event that fraud or a hack is observed. This ensures that damage due to the failure of any individual part of the network is minimized.
+
+Additionally, Connext follows a strict philosophy of secure development, requiring rigorous external review for code changes and working closely with the security community to educate auditors on bridge security risks and collaborate on creating best practices.
+
+### Simplicity
+
+Migrating to a completely new multichain development workflow can be challenging.
+
+Rather than reinventing the wheel, Connext tries to mimic and extend existing development patterns as much as possible. The protocol implements a single, simple primitive - `xcall` - which allows devs to asynchronously interact with contracts living on another chain/rollup similarly to how you would `call` a contract living on the same chain/rollup.
+
+Connext additionally plugs into the tooling and supporting infrastructure that is _already_ widely used in the ecosystem. Have a development workflow that isn't well supported by Connext? [Let us know](https://discord.gg/pef9AyEhNz) and our community can help build support for it!
+
+## What Can I Build With Connext?
+
+In short, pretty much anything! Here are some of the ideas that members of our community are working on:
+
+* Executing the outcome of **DAO votes** across chains
+* Lock-and-mint or burn-and-mint **token bridging**
+* **Aggregating DEX liquidity** across chains in a single seamless transaction
+* Crosschain **vault zaps** and **vault strategy management**
+* **Lending funds** on one chain and borrow on another
+* Bringing **UniV3 TWAPs** to every chain without introducing oracles
+* **NFT bridging** and chain-agnostic NFT marketplaces
+* **Storing data on Arweave/Filecoin** directly from within an Ethereum smart contract
+
+## Where Do I Go Next?
+
+If the above information was overwhelming, don't worry! We have plenty more resources to help you learn about Connext:
+
+* If you're a developer and want to start building with `xcall`, check out our Developer Quickstart and Examples.
+* Want to learn more about how the protocol works? Read through the How Connext Works section.
+* Are you an infrastructure operator? Help run the network by operating a Connext router.
+* Still not sure where to go? Join our [Discord](https://discord.gg/pef9AyEhNz) server and chat with us in the `#dev-hub` channel.

.gitbook/assets/UnderTheHood_Compressed.png

@@ -0,0 +1,78 @@
+# Table of contents
+
+## ✨ Concepts
+
+* [What is Connext?](README.md)
+* [How It Works](concepts/how-it-works/README.md)
+  * [Architecture](concepts/how-it-works/architecture.md)
+  * [Transaction Lifecycle](concepts/how-it-works/transaction-lifecycle.md)
+* [Background](concepts/background/README.md)
+  * [What is a Bridge?](concepts/background/what-is-a-bridge.md)
+  * [Modular Bridges](concepts/background/modular-bridges.md)
+  * [Message Verification](concepts/background/verification-mechanisms.md)
+* [Use Cases](concepts/use-cases.md)
+* [FAQ](concepts/faq.md)
+
+## 🤝 Developers
+
+* [Introduction](developers/intro.md)
+* [Quickstart](developers/quickstart.md)
+* [Guides](developers/guides/README.md)
+  * [Frontend](developers/guides/sdk-frontend-integration.md)
+  * [SDK](developers/guides/sdk-guides.md)
+  * [Estimating Fees](developers/guides/estimating-fees.md)
+  * [Tracking xCalls](developers/guides/xcall-status.md)
+  * [Authentication](developers/guides/authentication.md)
+  * [Handling Failed xCalls](developers/guides/handling-failures.md)
+  * [Nested xCalls](developers/guides/nested-xcalls.md)
+* [Reference](developers/reference/README.md)
+  * [SDK](developers/reference/sdk/README.md)
+    * [SdkShared](developers/reference/sdk/sdkshared.md)
+    * [SdkBase](developers/reference/sdk/sdkbase.md)
+    * [SdkPool](developers/reference/sdk/sdkpool.md)
+    * [SdkRouter](developers/reference/sdk/sdkrouter.md)
+    * [SdkUtils](developers/reference/sdk/sdkutils.md)
+    * [Types](developers/reference/sdk/types.md)
+  * [Contracts](developers/reference/contracts/README.md)
+    * [Calls](developers/reference/contracts/calls.md)
+    * [Routers](developers/reference/contracts/routers.md)
+    * [Stableswap](developers/reference/contracts/stableswap.md)
+  * [Subgraphs](developers/reference/subgraphs/README.md)
+    * [Entities](developers/reference/subgraphs/entities.md)
+    * [Sample Queries](developers/reference/subgraphs/sample-queries.md)
+    * [Subgraph Resources](developers/reference/subgraphs/subgraph-resources.md)
+  * [Integration](developers/reference/integration/README.md)
+    * [Adapters](developers/reference/integration/adapters.md)
+    * [Receivers](developers/reference/integration/receivers.md)
+* [Examples](developers/examples/README.md)
+  * [Simple Bridge](developers/examples/simple-bridge.md)
+  * [Authenticated Greeter](developers/examples/authenticated-hello.md)
+  * [Ping Pong](developers/examples/ping-pong.md)
+
+## 📦 Usecases
+
+* [xERC20](usecases/xerc20/README.md)
+  * [How xERC20 Tokens Work with Connext](usecases/xerc20/how-xerc20-tokens-work-with-connext.md)
+  * [Requirements](usecases/xerc20/requirements.md)
+  * [Setup Guide](usecases/xerc20/setup-guide.md)
+* [Chain Abstraction](usecases/chain-abstraction/README.md)
+  * [Chain Abstraction Guide](usecases/chain-abstraction/chain-abstraction-guide.md)
+* [xGovernance](usecases/xgovernance.md)
+
+## 📜 Resources
+
+* [Subgraphs](resources/subgraphs.md)
+* [Deployments](resources/deployments.md)
+* [Supported Chains](resources/supported-chains.md)
+
+## 🖥 Routers
+
+* [Basics](routers/routers-intro.md)
+* [Spinning Up](routers/spinning-up.md)
+* [Guides](routers/guides/README.md)
+  * [Community Guides](routers/guides/community-guides.md)
+  * [Providing Liquidity](routers/guides/liquidity.md)
+  * [Managing Your Router](routers/guides/management.md)
+  * [Security](routers/guides/security.md)
+* [Reference](routers/reference/README.md)
+  * [Configuration](routers/reference/configuration.md)

.gitbook/assets/addRouterLiquidity.png

@@ -0,0 +1,15 @@
+# Background
+
+
+
+{% content-ref url="what-is-a-bridge.md" %}
+[what-is-a-bridge.md](what-is-a-bridge.md)
+{% endcontent-ref %}
+
+{% content-ref url="modular-bridges.md" %}
+[modular-bridges.md](modular-bridges.md)
+{% endcontent-ref %}
+
+{% content-ref url="verification-mechanisms.md" %}
+[verification-mechanisms.md](verification-mechanisms.md)
+{% endcontent-ref %}

.gitbook/assets/assets.png

@@ -0,0 +1,27 @@
+# Modular Bridges
+
+The vast majority of generalized bridges out there today are _monolithic_. This means that they are tied to a specific verification mechanism that is implemented as a core part of the bridge construction.
+
+Connext is the first example of a generalized crosschain messaging mechanism that is _modular_, plugging into the best available verification method for a given ecosystem.
+
+## Clusters
+
+To understand why Connext is designed the way that it is, let us first explore the concept of [Clusters](https://blog.celestia.org/clusters/).
+
+A cluster is a sovereign set of domains that share security and can communicate with one another using trust-minimized methods. For example, Ethereum and its rollups form a cluster. Cosmos chains are another cluster. Singular "monolithic" chains, such as Solana are also their own cluster.
+
+<figure><img src="../../.gitbook/assets/clusters (1).png" alt=""><figcaption></figcaption></figure>
+
+In the [Message Verification](verification-mechanisms.md) section, we broke down the different methods that exist to secure a message that travels between two domains. As we noted, the **best available mechanism** for verifying messages is different based on the specific pair of domains we want to communicate between. Another way to say this is that there is a _heterogenous_ topology for message verification mechanisms across all networks.
+
+For example, between a rollup and its L1, the most secure verification mechanism is to use the rollup bridge itself.
+
+{% hint style="danger" %}
+The security of a domain is always the security of its weakest link. This means that _any_ method of passing messages to a rollup that isn't the rollup bridge introduces at least _some_ trust assumptions and security overhead, which in turn weakens the benefit of using a rollup (vs a less secure domain such as a sidechain) in the first place.
+{% endhint %}
+
+On the other hand, the most secure way to verify a message that passes between two discrete chains is a light client (zk or otherwise). Light client implementations exist in some places, but not everywhere yet - and it's highly unlikely that a single light client protocol will "win" every single pathway between sovereign chains.
+
+## Pluggable Verification
+
+Modular bridges make the verification layer (and potentially other parts!) of the [bridging stack](what-is-a-bridge.md) pluggable. By doing this, they can leverage _existing_ methods of message verification wherever possible. This gives the best possible security for applications that may want to interact with multiple (heterogenous) domains simultaneously.