Technical Spec: Lido<>Cosmos bridge

Authored by Kai Tyurin

This doc describes possible technical specification for a bridge-agnostic model of managing Lido staked Eth on Cosmos chains.

The aim of the spec is to solve issues of liquidity fragmentation and reduce any bridge-related issues, such as vendor lock and possible vulnerabilities. It mostly addresses this section of the previously made stETH bridging spec: https://hackmd.io/@lido/BJGOoX2hF#Ethereum-state-communication-channel

Overview

┌───────────────────┐      ┌─────────────────┐       ┌───────────────┐
│  Ethereum         │      │  Neutron        │       │Cosmos chain 1 │
│                   │      │                 │       │      ┌─────┐  │
│ ┌─────┐  ┌────┐   │      │    ┌─────┐      │   ┌───┼─────►│Users│  │
│ │Users│  │Lido│   │      │    │Users│      │   │   │      └─────┘  │
│ └──▲──┘  │DAO │   │      │    └─▲───┘      │   │   │               │
│    │     └─┬──┘   │      │      │          │   │   └───────────────┘
│    │       │      │      │      │          │   │
│    │       │      │      │ ┌────▼────┐     │   │   ┌───────────────┐
│ ┌──▼────┐  │      │      │ │Lido     │  IBC│   │   │Cosmos chain 2 │
│ │Lido   │  │      │      │ │Satellite│◄────┼───┼─┐ │      ┌─────┐  │
│ │Mission◄──┘      │      │ └────▲────┘     │   │ └─┼─────►│Users│  │
│ │Control│         │      │      │          │   │   │      └─────┘  │
│ └─▲─────┘         │      │      └───────┐  │   │   │               │
│   │               │      │              │  │   │   └───────────────┘
│   │  ┌─────────┐  │      │ ┌─────────┐  │  │   │
│   ├─►│Bridge   │◄─┼──────┤►│Bridge   ├──┤  │   │   ┌───────────────┐
│   │  │adapter 1│  │      │ │adapter 1│  │  │   │   │Cosmos chain 3 │
│   │  └─────────┘  │      │ └─────────┘  │  │   │   │      ┌─────┐  │
│   │               │      │              │  │   └───┼─────►│Users│  │
│   │  ┌─────────┐  │      │ ┌─────────┐  │  │       │      └─────┘  │
│   ├─►│Bridge   │◄─┼──────┤►│Bridge   ├──┤  │       │               │
│   │  │adapter 2│  │      │ │adapter 2│  │  │       └───────────────┘
│   │  └─────────┘  │      │ └─────────┘  │  │
│   │               │      │              │  │
│   │  ┌─────────┐  │      │ ┌─────────┐  │  │
│   └─►│Bridge   │◄─┼──────┤►│Bridge   ├──┘  │
│      │adapter 3│  │      │ │adapter 3│     │
│      └─────────┘  │      │ └─────────┘     │
│                   │      │                 │
└───────────────────┘      └─────────────────┘

High-level components

The whole thing consists of several main parts:

1. Mission control [settled on Ethereum]
   1. holds locked wstETH on the Ethereum side
   2. allows Lido DAO to manage Satellite on the Neutron side
   3. communicates with bridge adapters in order to transfer messages through the bridges
2. Satellite [settled on Neutron]
   1. mints wstETH on Neutron
   2. handles possible Eth-staking-on-Cosmos logic
   3. handles possible rebase of stETH-on-Cosmos
3. Bridge adapters
   1. implement all the bridge-specific behavior

Modular system

Each component consists of several modules:

1. Mission control:
2. Common module
3. Receiver module
4. Sender module

Satellite:

1. Common module
2. Receiver module
3. Sender module

Any bridge adapter:

1. Common adapter interface module
2. Bridge-specific sender module
3. Bridge-specific receiver module

By messages (handled by Sender and Receiver) we mean the day-to-day messages mostly issued by users. These messages are bi-directional since tokens can be transferred in both directions thus both Mission control and Satellite need to have both modules. Regular messages are to be executed as fast as possible.

❗ For more sensitive messages, such as the Satellite upgrade, a special handler can be implemented. Such a handler can have additional timelock/ability to overrule the message or some other hardening. Still, it’s out of the scope of MVP and can be defined further.

Modules specifications

Common

Storage

storage name	type	who can access	description
bridge_adapters	[<address, name>]	bridge_adapters_update [write]	list of bridge adapters to work with
owner	address	owner_update [write]	address that is able to manage the contract

Methods

method name	who can call	inputs	description
bridge_adapters_update	owner	[to_add]
[to_delete]	adds or removes bridge adapters
owner_update	owner	new_owner	updates owner

Receiver

Storage

storage name	type	who can access	description
threshold	int	update_threshold [write]
execute_message [read]	number of bridges that should approve the message to consider it
receive_messages	id → <hash → <message (optional), votes>, time, status>	add_message [read/write]
execute_message [read/write]	messages to process

Methods

method name	who can call	inputs	description
add_message	bridge adapters	id
hash
data [optional]	if message doesn’t exist, creates it
if message exists and executed, all changes are ignored
if message exists timeout is expired, it’s recreated
for existing/created message adds a new hash to the map or adds a voting for existing one
execute_message	permissionless	id
hash
data [optional]	if message exists for given id/hash and bridge votes for it more than threshold, validates and executes the message
update_threshold	owner	new_threshold	sets new threshold

Why such a complex messages structure? Why have hash → <message (optional), votes> map instead of just hash, message (optional), votes structure?

We assume a bridge might misbehave. During misbehaving it’s able to create spam hashes for different message ids and thus dos txs from being transferred. By having a single hash we’d need to have a logic of deciding which one is correct. Having a map of them we’re always able to execute the correct message regardless of spam made by any misbehaving bridge.

Why have a timeout?

Without timeout during the bridge hack an attacker is able to make a “reserve for a future”, e.g., transfer transaction of a huge amount of tokens to the smart contract that will divide the sent tokens between this attacker and any future one. Such a smart contract will be a proposal of collusion, and without any built-in expiration for a message it needs to be explicitly removed.

Sender

Storage

storage name	type	who can access	description
send_messages	id → <msg, hash>	create_transfer [write]
send_transfer [read]	create_transfer puts messages there

Methods

method name	who can call	inputs	description
create_transfer	permissionless	asset to transfer
gas payment compensation
recipient	creates send_message and calls send transfer for it
send_transfer	permissionless	send_message id
gas payment compensation
list of bridges [optional?]	sends messages to corresponding bridge adapters
crete_general_msg	owner	general message
gas payment compensation	creates send_message with an arbitrary message content

Why do we need a separate permissionless send_tranfer method? Why not do everything by a single method?
For recovering the tx in case of bridge hack/outage/bug

Common adapter interface

Storage

storage name	type	who can access	description
owner	address	update_owner [write]
send_message [read]	Mission control or Satellite address

Methods

method name	who can call	inputs	description
send_message	owner	message
gas payment compensation	sends message to the adapter on the other side
update_owner	owner	new_owner	updates the owner

Full bridge outage

Two important things should be of our attention:

1. in practice, we’re talking about only two bridges: Wormhole and Axelar
2. the threshold shouldn’t be less than 2 since in this case single bridge being hacked compromises the whole system

It creates the risk of one of the bridges being down for a long time and completely blocking the system of operations.

There’re several possible scenarios preventing that:

1. onboarding “minor” bridges: Gravity/Sifchain/…

   1. no additional security risk since the system is resistant to a single bridge hack
   2. the third bridge might be disabled by default and activated only when it’s needed
   3. this also can be used to smoothly handle temporary outages

2. making pseudo-bridge managed by multisig (this multisig will behave as a bridge and will be able to approve the necessary messages when it’s needed)

   ⚠️ it creates the risk of collusion between this multisig and a bridge attacker

3. making pseudo-bridge controlled by Neutron DAO/SubDAO — same as previous but more decentralized

Bridge adapters design

This is TBD yet. Still, as it was already mentioned, de facto we’re talking about two bridges: Axelar and Wormhole.

Axelar

Satellite bridge by Axelar has the native support of general messages passing which makes the integration very straightforward.

https://docs.axelar.dev/dev/general-message-passing/overview

Wormhole

At the moment, Wormhole functionality is much less. In Cosmos, Wormhole is deployed on 3 chains:

1. Injective
2. Terra v2
3. Terra Classic

❗ Regardless of the recipient being on one of those chains, Lido Satellite settled on Neutron still being able to get those messages via Interchain Queries and send them via Interchain Accounts

❗ This also can be treated as an opportunity allowing to diversify Wormhole bridging through different Cosmos chains, even when direct transfers on Neutron become possible

Unfortunately, currently, even NFT transfers aren’t supported for Cosmos chains.

The other drawback is that the transaction is needed to be explicitly claimed on the other side of the chain via issuing a special transaction.

However, as already described in the existing research, it’s doable to overcome these issues with a special token workaround.

Because Lido StarLadder has a modular architecture, it will be possible to smoothly migrate the system to a new adapter if new features are provided.

Other bridges

For any other bridge existing now or going to be deployed in the future, it’ll be possible to write an adapter for.

Roadmap

The proposed model can be implemented iteratively.

v1.0: wstETH bridging with a single bridge.
v1.1: adding one more bridge
v1.2: adding a third bridge for more reliability
v2.0: adding staking directly on the
v3.0: adding rebasing stETH bridging

Benefits and drawbacks

Benefits:

1. Avoiding liquidity fragmentation
2. No bridge vendor-lock
3. Smooth work even one of the bridges outage
4. More control over assets
5. Bridge-related security risks are reduced

Drawbacks:

1. Double price for bridge transfers
2. Additional smart-contract risk
3. Probably pretty complicated off-chain infrastructure