mobileRumblefishLogo
Menu
Porting Merkl to Stellar: Full Protocol Migration to SorobanEVM-to-Soroban redesign bringing DeFi incentive infrastructure to the Stellar ecosystem
Porting-Merkl-to-StellarCaseStudyWideImage
About the project

Merkl is the leading onchain incentive infrastructure, having distributed over $1.6B in rewards for 250+ companies across 60+ chains. Having established itself as the go-to infrastructure for on-chain reward campaigns on EVM-compatible networks, Merkl sought to bring its proven protocol to Stellar - a fast-growing blockchain ecosystem powered by its own smart contract platform, Soroban.

The challenge was significant. EVM and Stellar/Soroban are architecturally incompatible: different execution models, storage paradigms, authorization systems, and programming languages meant there was no simple path to migration. What Merkl needed wasn't a port - it was a full redesign of the protocol's internals, preserving identical business logic while adapting every layer of the system to Soroban's native patterns.

That's where we came in. With deep expertise across both ecosystems, our team took on the task of reimplementing Merkl's complete smart contract infrastructure in Rust on Soroban - delivering a production-ready deployment within just four weeks.

Collaboration timeframe:4 weeks
Tech stack:
Soroban SDK Stellar Blockchain OpenZeppelin EVM Solidity
Services:Smart Contract Development, Blockchain Development, Stellar Product Development, DeFi Development
Team size:1 blockchain developer
Challenges

The migration presented a unique combination of deep technical complexity and strict delivery requirements, spanning every layer of the protocol stack.

Fundamental Blockchain Architecture Differences

EVM and Stellar operate on entirely different principles at every level. Where EVM uses a global key-value store with a single persistence model, Soroban takes a more intentional approach - a ledger-entry-based model with explicit instances. These persistent and temporary storage scopes give developers precise control over data lifetime and cost. This design makes Soroban contracts leaner and more fee-efficient by default, but it also means that migrating from EVM requires rethinking how state is laid out from scratch, rather than simply rewriting syntax.

No 1:1 Language Translation

Solidity and Rust are fundamentally different languages with incompatible programming models. Solidity's contract patterns, like inheritance, modifiers, events, and require statements, have no direct equivalents in Soroban. Each had to be reimplemented idiomatically in Rust using traits, custom error types, and Soroban's own event system. This wasn't a translation exercise; it required deep fluency in both languages and their respective idioms simultaneously.

Cryptographic Compatibility

Merkl's reward distribution relies on Merkle tree verification using keccak256 hashing. keccak256 is not natively available in Soroban in the same form as on EVM, and differences in how the two platforms handle byte encoding mean that a naive implementation would silently produce incorrect results. Ensuring cryptographic parity, so that proofs generated on EVM could be correctly verified on Soroban, required meticulous work at the level of byte encoding and hashing behavior.

Cross-Contract Authorization Model

Merkl's AccessControlManager integration relies on EVM's role-based access control pattern. Soroban has its own native authorization framework that works fundamentally differently. Rather than a pattern to replicate, it is a platform-level mechanism that must be integrated correctly from the ground up. Reimplementing the access control layer required understanding Soroban's auth model from first principles, rather than mapping Solidity patterns onto an incompatible substrate.

Upgradeability Without Proxy Patterns

On EVM, contract upgradeability is an architectural workaround: since deployed bytecode is immutable, upgrades are simulated through proxy contracts (OpenZeppelin's TransparentUpgradeableProxy or UUPSUpgradeable) that delegate calls to a swappable implementation. Replicating this pattern on Soroban would have been the wrong approach entirely. Soroban supports native in-place WASM bytecode replacement as a first-class platform feature, preserving the same contract address and storage. The challenge was designing the right access-control layer around this capability rather than rebuilding EVM's proxy infrastructure from scratch.

Solutions

We approached the project not as a translation task but as a complete protocol redesign - one that preserved every aspect of Merkl's business logic while making each component feel native to the Soroban ecosystem.

Conscious Storage Architecture Design

Rather than mapping EVM's flat storage model directly onto Soroban, a deliberate storage architecture was designed from the ground up. Each piece of contract state was analyzed for its access frequency and required lifetime, then assigned to the appropriate Soroban scope - instance storage for contract-level configuration, persistent storage for long-lived user data, and temporary storage for ephemeral values. This approach produced a leaner, more cost-efficient contract than a naive port would have allowed.

Idiomatic Rust Implementation

Every Solidity pattern in the original Merkl contracts was reimplemented using Rust's native idioms and the Soroban SDK. Inheritance hierarchies became Rust traits; Solidity modifiers were replaced with composable guard functions and custom error types; OpenZeppelin event patterns were replaced with Soroban's structured event system. The result is a codebase that belongs naturally to the Soroban ecosystem rather than bearing the seams of a forced transplant.

Byte-Level Cryptographic Parity

To ensure that Merkle proofs generated on EVM could be verified correctly on Soroban, the full keccak256 hashing and byte encoding pipeline was implemented in Rust and verified against EVM's exact behavior at every step. The verification logic was rigorously tested against known EVM outputs to guarantee consistent proof validity across both chains - a critical requirement for any cross-chain reward system.

Native Auth Framework Integration

Rather than replicating Solidity's role-based access control pattern, the authorization layer was rebuilt from scratch using Soroban's native auth primitives. This integration respects the platform's security model and ensures that authorization checks behave correctly within Soroban's execution environment, including in cross-contract call scenarios.

Governor-Controlled Native Upgradeability

Instead of implementing proxy patterns, the upgradeability mechanism was built directly around Soroban's native WASM replacement host function. An access-control wrapper was designed to ensure that only addresses holding the Governor role can trigger contract upgrades, delivering the same security guarantees as the EVM implementation with significantly less architectural complexity. Because Soroban was designed with upgradeability in mind from the start, the resulting mechanism is cleaner, more auditable, and free from the edge cases that proxy-based upgrade patterns introduce on EVM.

The Results

Merkl launched successfully on Stellar, bringing battle-tested DeFi incentive distribution infrastructure to an entirely new ecosystem. Key achievements include:

Protocol Integrity
  • Full business logic parity with the EVM implementation preserved across all contract modules
  • Cryptographically verified Merkle proof compatibility between EVM and Soroban environments
  • Zero regressions in reward distribution correctness
Delivery
  • Production-ready deployment completed within 4 weeks by a single blockchain developer
  • Clean architecture reviewed and ready for external audit
Looking Forward: A New Standard for Cross-Chain Protocol Expansion

This project demonstrates that complex DeFi infrastructure can be migrated across fundamentally incompatible blockchain architectures without compromising on correctness, security, or native platform fit. The approach developed here - full semantic redesign rather than line-by-line porting, idiomatic implementation in the target language, and first-principles integration with platform-native features - establishes a replicable template for cross-ecosystem expansion.

As Stellar's DeFi ecosystem matures, Merkl's presence on Soroban positions the protocol to capture a growing share of on-chain incentive activity on the network, bringing the same capabilities that power Aave, Morpho, and Optimism campaigns to an entirely new audience.

This engagement demonstrates Rumble Fish's ability to operate with equal technical fluency across EVM and non-EVM ecosystems, delivering production-grade blockchain infrastructure wherever our clients need to grow.

Customer's testimonial
Guillaume Nervo_TestimonialAvatar
Porting Merkl to Stellar was a technically demanding project as EVM and Soroban are fundamentally different environments, and we needed someone who could navigate both with equal confidence. Rumble Fish delivered exactly that. The work was completed remarkably fast without cutting corners on correctness or security. We now have a production-ready deployment on Stellar that we're proud of.
Guillaume NervoCo-Founder, Merkl
Guillaume Nervo_TestimonialAvatar
Check our case studies
Previous projectCross‑chain bridge with tapplet security and DeFi‑ready ERC‑20lastCaseStudyBanner
Previous projectCreating a tool for EVM developerslastCaseStudyBanner
Have an idea?
Let’s work
together!
We will answer any questions you may have related to your startup journey!Do you prefer e-mail?
hello@rumblefish.pl