Starbridge: A Trust-Minimized Bridge Between Stellar and Other Blockchains

Over the last few years, we’ve seen blockchains grow in adoption and utility, establishing their place in the global financial system. At the same time, while they’ve grown in popularity, there is increasing fragmentation, mirroring the fragmentation we’ve seen (and been trying to solve) in traditional finance.

Stellar, on the other hand, is becoming an established interoperability layer between a wide variety of financial systems with a growing number of Stellar anchors connecting fiat currencies with stablecoins issued on Stellar. Today, users can redeem assets in their Stellar wallets off-network for an actual dollar, peso, or another fiat currency in their pocket — or more importantly, they can exchange between currencies at a faster rate and lower cost than they could on existing rails.

‍

But if Stellar is to strive towards its mission to create equitable access to the world’s financial infrastructure, it needs to be a bridge – not just to the financial system as it stands today, but the financial system it’s evolving into, which now includes other blockchain networks. That’s why participants in the Stellar ecosystem, like Pendulum and Flare, are enabling access to other blockchains through the development of technologies bridging blockchain-to-blockchain.

Today, we’re announcing a new project: Starbridge, a trust-minimized integration between Stellar and Ethereum.

The development and design of Starbridge is just getting started, and we’re setting out with the following requirements:

‍

‍

• Interoperate with Ethereum – As a starting point Starbridge will interoperate with one network, Ethereum where a significant amount of DeFi is being built today.
• Transfer value – Stellar assets and Ethereum ERC-20 tokens should be transferable.
• Symmetrically bidirectional – Stellar assets and Ethereum ERC-20 tokens should be transferable in both directions, with equal capabilities and functionality.
• Preselected assets – Multiple preselected assets should be supported, with some governance function or capability for the addition of new assets.
• Decentralized – Governance of the deployed technologies forming Starbridge should be decentralized with at least closed participation to minimize, or mitigate, the trust that users need to place in a single Starbridge operator.
• Offline wallet support – If the source and destination wallets in a transfer are different wallets, the wallets should not need to be online at the same time.
• Fees – Blockchain network fees should be paid by the source or destination wallet.
• Throughput – The deployed technologies forming Starbridge should introduce no constraint on throughput in comparison to the throughput capabilities of the blockchain networks integrated.
• Latency – The deployed technologies forming Starbridge should introduce no more than a five second latency on-top of the confirmation or finality times of the blockchain networks.

For the full list of requirements, see docs/requirements.md.

Starbridge will transfer two types of assets to facilitate symmetrical bidirectional capabilities: local assets and wrapped assets.

‍

‍

• Local assets – The assets you’ll find on a blockchain that people are using already. Like the lumen (XLM) on Stellar.
• Wrapped assets – Created on the destination blockchain by Starbridge to represent a local asset being sent from the sending blockchain.

Starbridge will use these assets to perform two different types of transfers:

• A send of a local asset that will be used as a wrapped asset.
  
  

• A return of a wrapped asset that unlocks a local asset.
  
  

‍

When local assets are deposited into the bridge, they will be locked up in an account or contract. Most stats for bridges look at total-value-locked (TVL) as a measurement for success, the methodology being that more deposits equals higher TVL.

Here’s how Starbridge works at a high level. The account/contract where assets are locked up will be controlled by a group of Starbridge operators. Each Starbridge operator will hold their own unique key, and all together, they will control the account/contract. Control and decentralization will be established using an m-of-n signer setup.

When we say m-of-n, we mean there is some number of signers, n, who can authorize transactions, and for a transaction to be authorized a subset of those signers, m, must sign.

‍

‍

For example, if the signer configuration is 3-of-5 any 3-of-the-5 signers need to sign to authorize. This means there’s tolerance to failure, tolerance to nefarious or negligent behavior, and decentralized control of the locked value.

The flow of a transfer takes only a few steps:

‍

‍

1. To start a transfer, a wallet will deposit a local asset into one chain or, if it is returning a wrapped asset, burn the asset using the issuing account or contract. When they do this, the wallet will specify a destination for the transfer on the other chain.
2. The receiving wallet will request the Starbridge nodes to replicate the deposit onto the other chain.
3. The Starbridge nodes all independently observe the deposit on the sending chain, in the context of the relative confirmation/finality times of the respective blockchain.
4. Once Starbridge has observed the event with confidence, the nodes will sign the inverse operation for the destination chain.
5. The receiving wallet collects signatures until it has enough signatures to meet the m-of-n requirement.
6. The receiving wallet uses the signatures to submit a transaction or call a contract on the destination chain, completing the transfer.

Starbridge’s design will also come with the capability to reverse transfers that can’t be completed. A reversal will work much the same way a send does, except the sender becomes the receiver on the same chain.

Starbridge is in very early development, and we’re continuing to iterate on the design and its capabilities. As this project gets more refined, we'll look at success measurements, and hope to assess ways we can go beyond TVL by creating metrics informed by interoperability and access, which are at the heart of our mission. We think Starbridge is a meaningful way that we’ll be able to maintain and build Stellar’s role in the financial system, by fostering access within and beyond blockchain. By increasing accessibility to Stellar’s strengths, both through traditional payment rails and other blockchains, the financial system can continue to evolve and innovate to ever-greater heights.

To read more about the design, see docs/design.md. To follow Starbridge’s progress, visit github.com/stellar/starbridge, join the Stellar Developers Discord, and watch this space.