Integrating Stellar to a Cross-Chain Liquidity Aggregator | Rubic Case Study

Project context

Rubic is a decentralized exchange and bridge aggregator with around 400k users, support for more than 90 networks, and integrations across 220 DEXs. Their platform already supported cross-chain swaps across EVM and several EVM ecosystems.

The goal was to add Stellar as a destination chain.

Rubic already had routing logic, bridge integrations, APIs, and SDKs. Our role was focused on Stellar: building the contracts, APIs, and execution flow required to move assets from EVM networks into Stellar and complete swaps using local AMMs.

Our scope included:

• Stellar smart contracts for swap execution and fee collection
• Stellar Aggregator API for quotes, swaps, transaction generation, and status tracking
• integration with bridges and Stellar AMMs
• EVM to Stellar routing logic
• transaction construction on Stellar
• refund paths for failed swaps

We worked closely with Rubic’s backend and product teams to connect this into their existing system.

How the flow works

From a user’s perspective, swapping into Stellar looks straightforward. Choose tokens, approve, confirm the swap, and receive funds.

Behind that flow:

1. Rubic aggregates liquidity and bridges to find the best route.
2. The source asset is swapped on EVM into USDC.
3. USDC is bridged to Stellar.
4. Stellar contracts run the final swap through AMM DEXs.
5. The output token is sent to the user.

Quotes, transaction payloads, and status tracking are exposed through Rubic’s API and SDK so other applications can use the same pipeline.

Our work covered everything on the Stellar side, from receiving bridged assets to executing DEX swaps and delivering tokens to users.

Working with Stellar

Integrating Stellar as a target chain introduced constraints that shaped the swap flow and architecture. Key specifics included:

• authorisation via require_auth()
• accounts must be activated with XLM
• receiving tokens requires trustlines
• DEXs do not support custom swap recipients
• bridges like Allbridge cannot send assets directly to contracts
• contract storage has a limited lifetime

Stellar contracts are built in Rust with Soroban. We adapted Rubic’s existing swap logic to this environment by translating established UX workflows into Soroban-native execution paths.

Account activation and trustlines

On Stellar, users cannot receive tokens unless:

• their account is activated with XLM
• a trustline exists for each non-native asset

Before executing a swap, we check both.

If a trustline is missing, the frontend asks the user to approve opening it, while the relayer temporarily provides the required XLM. By the time the swap runs, the destination account is ready and the output token can be delivered

Transaction signatures

We implemented token and contract interactions without using approve/transferFrom. While these functions exist in Stellar, most implementations avoid them to simplify the user experience and prevent additional transaction signatures.

Instead, the flow works as follows:

1. The user signs the transaction with user.require_auth().
2. The contract can then perform token operations on the user’s behalf, for example token.transfer(user, …). Internal calls automatically verify the authorization.
3. The relayer is authorized in the same way, allowing the swap to execute in a single transaction.

Bridging into Stellar

Allbridge and similar providers can only send assets to externally owned accounts.

Bridged tokens therefore arrive at a relayer address first. The relayer calls the Stellar contract, which pulls in the funds, runs the swap, and sends the result to the user.

The relayer never holds the output assets. It only acts as a temporary hop so execution can move into the contract.

Working with Stellar AMMs

Stellar AMMs don’t allow specifying swap recipients, and calling the DEX directly would require the relayer to hold trustlines for every possible output token. To solve this, we built a contract that:

• Pulls tokens from the relayer.
• Executes the DEX swap.
• Receives the output asset.
• Transfers the result directly to the user.

This keeps all asset movement inside the contract, so the relayer never needs trustlines for output tokens.

Authorization for contract calls

Since Stellar contracts don’t propagate authorization automatically, we implemented a system where the backend precomputes all required permissions and embeds them into the transaction. The swap contract consumes these permissions during execution, allowing the full swap path to complete in a single transaction while fully complying with Stellar’s explicit authorization rules.

Refunds

Cross-chain refunds are slow and costly, so we built an optimized solution: failed swaps automatically refund users in the intermediate Stellar token, based on predefined deadlines. This avoids unnecessary round trips to the source chain.

Contract data lifetime

Since Stellar contract storage has a limited lifetime, we built automatic TTL extensions for active entries and leverage Stellar’s simulation layer to restore older data when needed, preventing silent state expiration.

Security and UX

We designed the system so users never submit raw calldata. Instead, they express intent, and the backend builds validated transactions that enforce that intent, preventing arbitrary contract calls while keeping swap routing flexible and user-friendly.

Results

• Production-ready EVM to Stellar swap flow
• Support for multiple Stellar DEXs
• No approve or transferFrom patterns
• Relayers never hold output tokens
• Refund logic on Stellar
• TTL-safe contract storage
• Full integration with Rubic’s API and SDK

Final note

Integrating Stellar required rethinking standard EVM assumptions around accounts, authorization, and swaps. We worked closely with Rubic to build a cross-chain flow that leverages Stellar’s native design while keeping the user experience consistent.

For founders building cross-chain products, the key insight from our work is this: supporting a new ecosystem isn’t about porting code—it’s about adapting your architecture and designing the flow so that fundamentally different systems work together seamlessly.

‍