We seek to create a Stellar specific bridge that allows users to bridge XLM from the Stellar ecosystem to Cosmos. We’re planning to use a Lock & Mint / Burn & Redeem bridge to allow users to move to XLM from the Stellar network to a new asset, wrapped Stellar (wXLM), specific to use in the Cosmos ecosystem. With the coming release of Soroban to mainnet we believe that bridges between Stellar and other prominent ecosystems, like Cosmos, will see vastly increased demand. After bridging XLM to Cosmos, our future goals include adding support for bridging other popular Stellar assets to Cosmos, bridging Cosmos assets to Stellar, and bridging Stellar tokens to other blockchains.

 

Motivation: 

 

Stellar is a prominent ecosystem but would benefit greatly from having more bridges and being connected to other chains. With our new bridge, we hope to be able to create the functionality that allows Stellar to be connected to the larger ecosystem.

 

Competitors: 

 

No attempts have been made to build a bridge directly between Soroban and Cosmos. 

While bridges such as Ionic and Allbridge are in development or completed, neither of them connect to Cosmos, and they only support stablecoins and native Eth.

Litepaper:

https://docs.google.com/document/d/1R2LCdsRPgZ7x54ZGC0lXxTVjW3zTe7EwPBybtsHootg/edit?usp=sharing

Bridge XLM from Soroban → Cosmos

 

A user wishing to bridge tokens from Soroban to Cosmos will first call a function on the Soroban contract which will take the users XLM, lock it in the bridge contract, and emit an Event on Soroban. Each subsequent Event is assigned a monotonically increasing nonce. Validators running the Orchestrator are checking for these events every few seconds, by making Soroban-RPC calls. Once they see an event has been emitted, they will create a Claim of the event they’ve observed and then send it to Cosmos. 

 

From here our Cosmos bridge module will process these claims. After checking that the submitted claim has a nonce one greater than the last submitted by this validator, the module will either create a new Attestation if this event hasn’t been seen before, or add the claim to an existing Attestation. At the end of each block a check is run to see if 2/3rds of the voting power have confirmed an attestation, in which case we mint the corresponding wXLM (wrapped XLM) and send it to the desired address. 

 

Withdrawing XLM from Cosmos → Soroban

 

When a user wishes to trade in their wrapped XLM for native XLM in Soroban, they will send a message to Cosmos with two fees. The first fee is used for the execution on Cosmos and the second will go to the relayers later. The Cosmos module will process this message, take the wXLM from the account, and place it in a pool of transactions waiting to be processed. Here validators will sign the transactions and once a transaction has enough signatures to go through, a relayer will decide to execute the transaction on Soroban if the second fee is enough to make it a profitable execution. Batching of transactions will not be supported initially but is one of the first upgrades planned after building the MVP.

 

Once a relayer decides to execute a transaction, it marks it as being submitted, and a function is called on the Stellar contract which will return the users funds and emit an event recognizing the execution of this transaction. In the same way the event emitted by a locking of tokens is handled, this event will be processed by the validators and the processed transaction will be removed from the pool of transactions waiting to execute and corresponding wXLM will be burned.

5 main components:

 

A Soroban contract that allows users in the Stellar ecosystem to lock XLM into our bridge contract. This contract will include a function which can be called by users who wish to bridge and will lock XLM into the contract. At the end of this function's execution an event will be emitted for validators to listen to. Similarly the contract will have a function to return XLM to users that emits an event upon completion. It will also be responsible for storing a hash of the most recently updated validator set and confirming that the signatures for a Cosmos → Soroban transaction are valid.

 

The next key component is the validator set, each of which will run a full Cosmos node and the bridge module. The validators will listen for the events emitted when functions on the Soroban contract finish execution and subsequently submit a claim message to the bridges cosmos module. The validator is also responsible for signing transactions when a user wishes to redeem their wXLM for XLM. The validator consists of three components, an oracle which accesses the Stellar blockchain through Soroban-RPC calls made by running a full Stellar Core node and horizon server, an orchestrator which runs the main loop of the validator for bridging logic, a signer to sign transactions headed to Soroban, and the full Cosmos node. We will create our proof of concept to support a single validator at first and then extend the implementation to support the addition of new validators to the valset.

 

The Cosmos module will be listening for the claims sent in by the orchestrator part of validators. The claims it receives are either added to an existing Attestation or create an entirely new attestation. Once two thirds of the validators have created a claim that matches a given attestation the attestation will be executed, either minting or burning tokens, whatever corresponds to the given event. Additionally, the module listens for messages sent by users wishing to revert wXLM back to XLM on Soroban. This module manages the transaction pool and holds the wXLM while waiting for validators to sign a transaction and a relayer to execute on Soroban. This module is also responsible for removing a transaction sending wXLM that a user no longer wants to execute, removing transactions for the tx pool that have timed out, and slashing validators who are not responding.

 

Relayers will make calls to our Soroban contract to return XLM on profitable transactions which have been signed by enough validators. Relayers are needed to execute on Soroban because they will pay the Soroban execution fees after deciding if a transaction is profitable to execute based on its associated fees.

 

A new wrapped XLM token will be created on cosmos which mirrors the max supply of Stellar. It represents Stellar on the Cosmos chain and is what the bridge module mints and burns.

Roadmap:

We expect development to take roughly 6 weeks and have broken up the process into the following deliverables.

 

Deliverable 1: Soroban Contract

• Description: Write a Soroban contract that can receive tokens and emit an event and return XLM back to users after verifying that the signature on the transaction is correct.
• Metric for completion: Public contract in our codebase with a readme to describe the contracts functions and video demonstrating calls to the contract on Soroban testnet.
• Time and budget: ~50 hours x $100/hr - $5000

 

Deliverable 2: Validator setup with Orchestrator able to listen to Soroban events

• Description: Create a process to set up a validator and create the code for the orchestrator and signatures. The validator will run a full Cosmos node and a full Soroban node along with code to run the orchestrator and execute contract logic. The orchestrator will constantly check for events emitted by the Soroban contract through Soroban-RPC calls so it can submit claims to the Styx cosmos module. 
• Metric for completion: Public files in our codebase with a readme to describe the process of setting up a validator and video demonstrating the successful observation of emitted events by a running validator.
• Time and budget: ~100 hours x $100/hr - $10000

 

Deliverable 3: Cosmos Styx Module wXLM- 

• Description: Create a new token on Cosmos, wXLM, and a new Cosmos module that can receive messages from Validators, create Attestations for certain events to add claims to, and be able to mint wXLM upon passing a certain voting threshold. Also, setup the functionality to receive messages for the event when users want to trade in their wXLM for native XLM. Add these messages to a transaction pool and withdraw wXLM from the correct account.

• Metric for completion: Public files in our codebase with a readme to describe the modules functionality and video demonstrating minting and a tx being added to the waiting tx pool.
• Time and budget: ~80 hours x $100/hr - $8000

 

Deliverable 4: Signers and Relayers

• Description: Create the functionality for validators to sign transactions waiting in the tx pool to be processed and sent to Soroban. Write the code that the relayers can run when seeking to submit transactions to Soroban and claim the corresponding fee.

• Metric for completion: Public files in our codebase with a readme to describe functionality and a tutorial on how to run a relayer. Additionally a video demonstrating a relayer calling the Soroban contract to return XLM.
• Time and budget: ~100 hours x $100/hr - $10000

 

Deliverable 5: Listening for events after the return of XLM tokens and extensive testing

• Description: Add support for validators to submit claims for the event emitted after the return of XLM to a Soroban address. Add support for the Styx module to then process these claims, burn wXLM and pay the relayer its reward. Test the end to end process extensively both manually and through thorough integration tests.

• Metric for completion: Public files in our codebase with a readme to describe the end to end flow along with how to run the integration tests. A video demonstrating the successful bridging of XLM to Cosmos and back without a dedicated frontend.
• Time and budget: ~60 hours x $100/hr - $6000

 

Deliverable 6: Frontend

• Description: Create a frontend which allows users to link their wallet through wallet connect and either bridge XLM to Cosmos by calling the Soroban contract or return wXLM to Soroban by calling the Cosmos Styx module. Makes the process of bridging easy and understandable.

• Metric for completion: Hosted frontend that can be visited 
• Time and budget: ~40 hours x $100/hr - $4000

If we are selected for the Activation Award, we'd start by building the full end-to-end product outlined in our spec. Afterwards, there are several ways we'd like to expand our project, including support for batching, supporting functionality of adding validators to the valset, supporting more Stellar-based assets, supporting bidirectionality so Cosmos assets can be bridged to Soroban, and eventually we hope to bridge Soroban to other chains. We hope to apply for the Community Award to finance the improvements to the Soroban Bridge. We then hope to create a token that can be used to pay the relayer fees and use those token sales to finance the upkeep of Styx, support more chains, and grow our userbase.

https://youtu.be/2i6xIBd5aiI

https://docs.google.com/presentation/d/12BiVAbO-eEtSWsNKQOQcUpd8EYaY-H1M3pSFjBwDJ_A/edit?usp=sharing

read

https://www.figma.com/file/MCNoYBwA8wSAx0Qu4lIB1W/Styx-Design?type=design&node-id=19%3A177&mode=design&t=eQKAcKpzSPhTbLLR-1

https://www.figma.com/file/MCNoYBwA8wSAx0Qu4lIB1W/Styx-Design?type=design&node-id=0%3A1&mode=design&t=eQKAcKpzSPhTbLLR-1

read

43000

read

Jaylem Brar - https://www.linkedin.com/in/jaylem-brar-02b1031b6

             Jaylem is the head lecturer of the blockchain developers course at UC Berkeley where he recreated over half the course to teach rust development on cosmos and teach an introduction to zero knowledge proofs. He is also the Co-founder of Kryptik, https://www.kryptik.app/, an open source, chain agnostic wallet which received funding from Carnegie Mellon, Near, Solana, and the Web3 foundation and just completed the 2023 Berkeley Blockchain Xcelerator batch. He was the Berkeley liaison for SDF in 2021 during their sponsorship of Berkeley accelerator and set up a virtual panel for Stellar builders to present to Berkeley students. Additionally, he has consulted for Paypal and Dfinity through Blockchain at Berkeley, interned at Amazon, and graduated with an EECS degree from UC Berkeley.

Kaan Ulupinar - https://www.linkedin.com/in/kaan-ulupinar-275b2216b

Kaan is a full stack developer who has started developing in the Web3 space. A UC Berkeley alum and former Amazon engineer, he has 6+ years of experience developing using AWS, React, and a wide assortment of front and backend frameworks.

Rohan Khandelwal - https://www.linkedin.com/in/rohan-khandelwal

Rohan is a Software Engineer at Microsoft on the internal payments team. He has consulted for companies including Aleo, Osmosis, and Optimism as a project lead for Blockchain at Berkeley. He has assisted Jaylem with the blockchain developers course at Berkeley where he graduated with a CS degree