https://blogger.googleusercontent.co...reenshot_1.jpg
Leigh McCulloch: Mar 24, 2022
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.
https://blogger.googleusercontent.co...reenshot_2.jpg
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:
https://github.com/stellar/starbridg...equirements.md
Starbridge will transfer two types of assets to facilitate symmetrical bidirectional capabilities: local assets and wrapped assets.
https://blogger.googleusercontent.co...viJybeUdA4.png
A return of a wrapped asset that unlocks a local asset.
https://blogger.googleusercontent.co...640-h274/4.png
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.
https://blogger.googleusercontent.co...reenshot_3.jpg
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:
https://blogger.googleusercontent.co...7jlHvbkdaV.png
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 https://github.com/stellar/starbridg...docs/design.md
To follow Starbridge’s progress,
join the Stellar Developers Discord
https://discord.com/invite/YuzQvnv9Tn
Website: https://starbridge.one
