This is part 2 of a series of posts exploring bridges in crypto, read part 1 here.

As we discussed in the previous post, bridges are, to put it in simplest terms, a communication mechanism between two siloed networks. And while we mostly use them for bridging assets today from chain A to chain B, they can be very generalised protocols, enabling much more use cases like:

• Money markets with cross chain borrow-lending.

• Mint NFT’s on a secondary chain and reserve the asset on canonical chain.

• Swapping assets on aggregators on a chain but utilizing the liquidity on all chains for minimum slippage.

  And much more.

Since there’s a plethora of verticals to build upon, bridging protocols in the crypto space build networks which might enhance and cater to specific purposes, niches, and markets.

Bridging protocols can be categorised amongst different attributes that go into the architecture and trust assumptions that they’re built on.

Trusted bridges require the user to give up control of their assets and rely on the reputation and competence of the operator to manage funds (example: WBTC).

Trustless bridges are based on smart contracts and native algorithms governing them. The user remains in custody of their funds in a transparent manner via a smart contract. (example: Connext).

• Natively verified bridges run a light client of each other’s chain to verify and communicate.

examples: Near Rainbow Bridge, TBTC bridge.

• Locally verified bridges only require the two parties interacting cross chain to verify the transaction.

example: Connext, Hop.

• Externally Verified bridges rely on external verifiers not native to either chain to verify and communicate.

examples: Thorchain, Synapse, Stargate*.

* While Stargate is externally verified, there’s contentions about its trustlessness or lack thereof( more here ).

• Lock + Mint < - > Burn + Redeem

• Liquidity Pool based

• Native asset swaps.

First let’s put these architectural choices on a scale of attributes.

• The bridging ecosystem is as safe as the weakest link of bridge. Naturally, natively verified bridges are most secure and trustless and generalizable, but they give up extensibility and scaling

• Locally verified bridges are quite safe too and has the security of the weaker chain of the two, with a trust assumption that both parties are economically adversarial. The added benefit of this model is that it’s also extensible and scalable.

• Externally verified bridges rely on external parties off chain to pass messages. Users completely depend on external operators and their design/ competence for safety. Hence are in most cases least secure. However they are most scalable and generalizable.

This brings us to the trade-offs that each design choice makes, and the interoperability trilemma.

The crux of the problem in designing bridge architecture lies in navigating across the trilemma above. You can pick two of the qualities and give away some or most of the third one. (in yellow some examples of popular bridges)

As evident from above Connext is a locally verified architecture network. It retains the security of underlying chain and is very scalable/extensible to other domains. However this compromises on generalizable message passing which unlock many more use cases.

To tackle the interoperability problem, Connext came up with a novel network upgrade Amarok. Amarok network upgrade basically makes the entirety of connext network more modular.

Above image taken from Connext medium, showcases the multi-layer approach to various modes of bridging.

Of note, as a locally verified bridging protocol, Connext will utilize several trust minimized messaging layers for generalized message passing. The most important of which is a close partner Nomad.

Perhaps the most exciting stack is application layer which allows cross chain apps to be built on top of Connext (xapps).

The next post will explore Amarok in depth, and take a look at some xapps being built.

Thanks!

This is part 2 of a series of posts exploring bridges in crypto, read part 1 here.

As we discussed in the previous post, bridges are, to put it in simplest terms, a communication mechanism between two siloed networks. And while we mostly use them for bridging assets today from chain A to chain B, they can be very generalised protocols, enabling much more use cases like:

• Money markets with cross chain borrow-lending.

• Mint NFT’s on a secondary chain and reserve the asset on canonical chain.

• Swapping assets on aggregators on a chain but utilizing the liquidity on all chains for minimum slippage.

  And much more.

Since there’s a plethora of verticals to build upon, bridging protocols in the crypto space build networks which might enhance and cater to specific purposes, niches, and markets.

Bridging protocols can be categorised amongst different attributes that go into the architecture and trust assumptions that they’re built on.

Trusted bridges require the user to give up control of their assets and rely on the reputation and competence of the operator to manage funds (example: WBTC).

Trustless bridges are based on smart contracts and native algorithms governing them. The user remains in custody of their funds in a transparent manner via a smart contract. (example: Connext).

• Natively verified bridges run a light client of each other’s chain to verify and communicate.

examples: Near Rainbow Bridge, TBTC bridge.

• Locally verified bridges only require the two parties interacting cross chain to verify the transaction.

example: Connext, Hop.

• Externally Verified bridges rely on external verifiers not native to either chain to verify and communicate.

examples: Thorchain, Synapse, Stargate*.

* While Stargate is externally verified, there’s contentions about its trustlessness or lack thereof( more here ).

• Lock + Mint < - > Burn + Redeem

• Liquidity Pool based

• Native asset swaps.

First let’s put these architectural choices on a scale of attributes.

• The bridging ecosystem is as safe as the weakest link of bridge. Naturally, natively verified bridges are most secure and trustless and generalizable, but they give up extensibility and scaling

• Locally verified bridges are quite safe too and has the security of the weaker chain of the two, with a trust assumption that both parties are economically adversarial. The added benefit of this model is that it’s also extensible and scalable.

• Externally verified bridges rely on external parties off chain to pass messages. Users completely depend on external operators and their design/ competence for safety. Hence are in most cases least secure. However they are most scalable and generalizable.

This brings us to the trade-offs that each design choice makes, and the interoperability trilemma.

The crux of the problem in designing bridge architecture lies in navigating across the trilemma above. You can pick two of the qualities and give away some or most of the third one. (in yellow some examples of popular bridges)

As evident from above Connext is a locally verified architecture network. It retains the security of underlying chain and is very scalable/extensible to other domains. However this compromises on generalizable message passing which unlock many more use cases.

To tackle the interoperability problem, Connext came up with a novel network upgrade Amarok. Amarok network upgrade basically makes the entirety of connext network more modular.

Above image taken from Connext medium, showcases the multi-layer approach to various modes of bridging.

Of note, as a locally verified bridging protocol, Connext will utilize several trust minimized messaging layers for generalized message passing. The most important of which is a close partner Nomad.

Perhaps the most exciting stack is application layer which allows cross chain apps to be built on top of Connext (xapps).

The next post will explore Amarok in depth, and take a look at some xapps being built.

Thanks!