Skip to content

Muwp Stellar Technical Feasibility

Muwpayteam edited this page Apr 14, 2024 · 1 revision

Context

MUWP from MuwPay aims to facilitate multitoken cross-chain token swaps, leveraging Stellar’s ecosystem for its fast transactions and low fees. The integration involves using both decentralized exchanges (DEXes) native to Stellar, like StellarX and StellarTerm, as well as external platforms like Changelly for broader asset availability and bridges such as Allbridge for accessing non-native tokens.


Technical Strategy:

1) Smart Contract Development Using Soroban


.

Purpose: Develop and deploy Soroban smart contracts to handle complex operations like route optimization and token swaps.

Snippets of Smart contract implementation in Rust:

// Define the primary contract for token swaps

#[contract]

pub trait SwapContract { fn execute_swap(&self, env: Env, from_token: symbol, to_token: symbol, amount: BigInt);

}

// Define the secondary contract for fetching real-time prices

#[contract]

pub trait PriceFeedContract { fn get_price(&self, env: Env, token: symbol) -> BigInt;

}

// Implementation of the SwapContract that calls the PriceFeedContract pub struct SwapImpl;

#[contractimpl]

impl SwapContract for SwapImpl {

`fn execute_swap(&self, env: Env, from_token: symbol, to_token: symbol, amount: BigInt) {`

    `let price_feed_contract: PriceFeedContractClient = env.get_contract("price_feed_contract_address");`

    `let from_price = price_feed_contract.get_price(env.clone(), from_token);`

    `let to_price = price_feed_contract.get_price(env.clone(), to_token);`


    `// Logic to calculate the best swap route based on the prices`
    `// Further processing and executing the swap on the Stellar network`
`}`

}

This code defines two interfaces (traits) and one implementation for a token swap functionality on the Stellar network:

1. Interfaces:

  • SwapContract: This interface defines a single function called execute_swap. This function takes four arguments:
    • env: This likely represents the environment the contract is running in (e.g., Stellar blockchain environment).
    • from_token: This is a symbol representing the tokens the user wants to swap from.
    • to_token: This is a symbol representing the token the user wants to swap to which is XLM
    • amount: This is a big integer representing the amount of the from_token the user wants to swap.
  • PriceFeedContract: This interface defines a single function called get_price. This function takes two arguments:
    • env: Similar to the SwapContract.
    • token: This is a symbol representing the token for which the price needs to be retrieved.

2. Implementation:

  • SwapImpl: This struct implements the SwapContract interface.
  • The execute_swap function within SwapImpl does the following:
    • It retrieves a reference to a PriceFeedContract using the provided address (price_feed_contract_address).
    • It calls the get_price function on the PriceFeedContract twice: once for the from_token and once for the to_token. This retrieves the current prices of both tokens.
    • There's a comment indicating further logic should follow to:
      • Calculate the best swap route based on the retrieved prices.
      • Perform the actual swap on the Stellar network (using additional functionality not shown here that we going to mention later in this repo ).

Overall, this snippets of code defines the basic framework for the tokens swap contract on Stellar that we will use. It interacts with a separate price feed contract to retrieve token prices and purposely leaves room for further implementation to calculate the optimal swap route and execute the swap itself.

2) Cross-Contract Calls:


Purpose: Leverage Soroban’s capability to interact with other contracts for functionalities like price fetching or liquidity checks:

Snippets of Implementation in Rust:

// Define a contract for handling liquidity management

#[contract]

pub trait LiquidityContract {

``fn add_liquidity(&self, env: Env, token_a: symbol, token_b: symbol, amount_a: BigInt, amount_b: BigInt);``

}

// Implementing the LiquidityContract pub struct LiquidityImpl;

#[contractimpl]

impl LiquidityContract for LiquidityImpl { fn add_liquidity(&self, env: Env, token_a: symbol, token_b: symbol, amount_a: BigInt, amount_b: BigInt) {

// Implementation details here } }`

// Primary trading contract making a cross-call to the LiquidityContract

#[contract]

pub trait TradingContract { fn execute_trade(&self, env: Env, token_a: symbol, token_b: symbol, amount: BigInt); }

pub struct TradeImpl;

#[contractimpl]

impl TradingContract for TradeImpl {

`fn execute_trade(&self, env: Env, token_a: symbol, token_b: symbol, amount: BigInt) {`

    `let liquidity_contract: LiquidityContractClient = env.get_contract("liquidity_contract_address");`

    `let required_liquidity = liquidity_contract.add_liquidity(env.clone(), token_a, token_b, amount, amount);`


    
    `// Additional trading logic after liquidity is ensured`
`}`

}

This code defines another set of interfaces and implementations related to liquidity management and trading on the Stellar network:

1. Interfaces:

  • LiquidityContract: This interface defines a single function called add_liquidity. This function takes five arguments:
    • env: Similar to the previous code.
    • token_a: Symbol representing the first token being added to the liquidity pool.
    • token_b: Symbol representing the second token being added to the liquidity pool.
    • amount_a: Big integer representing the amount of token_a being added.
    • amount_b: Big integer representing the amount of token_b being added.
  • TradingContract: This interface defines a single function called execute_trade. This function takes four arguments:
    • env: Similar to the previous code.
    • token_a: Symbol representing the first token involved in the trade.
    • token_b: Symbol representing the second token involved in the trade.
    • amount: Big integer representing the amount of token_a (presumably) being offered in the trade.

2. Implementations:

  • LiquidityImpl: This struct implements the LiquidityContract interface.

  • The add_liquidity function's implementation involving adding the provided tokens and amounts to a designated liquidity pool on the Stellar network from dexes and bridges.

  • TradeImpl: This struct implements the TradingContract interface.

  • The execute_trade function performs the following:

    • It retrieves a reference to a LiquidityContract using the provided address (liquidity_contract_address).
    • it calls the add_liquidity function on the LiquidityContract with the same amount for both token_a and token_b. This suggest the trading contract requires ensuring there's enough liquidity for the trade before proceeding.
  • This code snippet focuses on liquidity management and its integration with trading functionality.

  • The specific logic for adding liquidity and executing trades is partially shown, but the concept of interacting with a separate LiquidityContract for managing liquidity pools is highlighted in point 3 with the dexes and bridges.

3) Integration with DEXes and Bridges


  • DEXes: Directly integrate with Stellar DEXes through their APIs to perform trades.
  • Bridges: Use Allbridge and similar services to facilitate swaps involving non-Stellar tokens.

Stellar Elements Needed:

  • Horizon API: Interact with Stellar's blockchain for transaction submissions and account monitoring.
  • Stellar Core: Engage directly with the Stellar network for consensus and transaction processing.

Why These Stellar Elements Are Necessary: Horizon API: Essential for interfacing with the Stellar network, managing accounts, and submitting transactions programmatically. Stellar Core: The backbone of Stellar’s network, necessary for engaging with the ledger and participating in the consensus process.

Let's dive into the selection of Dexes and Bridges:

To effectively integrate MUWPAY with the specified DEXes and bridges — StellarX, StellarTerm, Defispot, Changelly, and Allbridge — here’s a strategic approach to ensure seamless functionality and robust service offerings:

Integration Strategy:

  1. API Integration and Configuration:

    • Allbridge: This service bridges assets across various blockchains. API integration here would be crucial for cross-chain transfers that are not natively supported on the Stellar network.
    • StellarX and StellarTerm: These are trading platforms built on the Stellar network. Integrating these requires accessing their APIs to execute trades directly on the Stellar blockchain, managing assets and liquidity.
    • Defispot: As a DEX aggregator, offer APIs to access the best rates across multiple exchanges. Integration would focus on querying these APIs to get optimal swap routes.
    • Changelly: Utilize Changelly's API for fast and straightforward cross-chain exchanges as previously outlined, especially for tokens outside of the Stellar network.
  2. Unified Interface Development:

    • Develop a single, cohesive user interface that easily propose the best routes to select base on these platforms.
  3. Smart Contract Implementation for Automated Routing:

    • Leverage Stellar’s Soroban smart contracts that we explain above to automate the decision-making process in choosing the most efficient route or platform based on real-time data from these integrated services.
    • Ensure that these smart contracts can handle fallbacks in case one service is temporarily unavailable.
  4. Security:

    • Implement stringent security protocols for interacting with external APIs.
  5. Performance Optimization and Cost Management:

    • Monitor and optimize the performance of APIs and smart contracts to reduce slippage and transaction fees.
    • Provide users with transparent cost comparisons to choose the most cost-effective options.
  6. Continuous Monitoring and Updates:

    • Set up a system for monitoring the operational status and updates from these DEXes and bridges, ensuring the MUWPAY platform remains up-to-date with the latest changes and offerings.
    • Regularly review and adjust integrations based on performance metrics and user feedback.

Benefits:

  • Comprehensive Coverage: Users access a wide range of services for trading and transferring assets across multiple blockchains.
  • Optimization of Swaps: Automated calculations to determine the best routes ensure users get the best possible rates.
  • Enhanced User Experience: A streamlined interface that simplifies complex blockchain interactions.

Conclusion:

This technical strategic plan outlines how MUWP can leverage these DEXes and bridges to enhance its platform's capabilities, offering a versatile, efficient, and user-focused service in the stellar defi space. The integration of MUWP with Stellar using Soroban smart contracts and cross-contract calls will enable efficient, secure, and versatile cross-chain token swaps. This approach not only leverages Stellar’s transactional efficiencies but also enhances user experience by providing diverse route and token swap options.