Menu
Services
Blog
- Software
- Blockchain
- Web3 product
- Smart Contracts
- Mobile app
- Web platform
- AWS Cloud
- NFT marketplace
- DeFi
- Fintech
- AI product
- dApp
- Crypto wallet
Rumble Fish helps entrepreneurs build and launch bespoke digital products.
We take care of the technology, so you can focus on your business
Join the ecosystem
of our satisfied customers:
of our satisfied customers:
Who we are?
Hi there! We're Rumble Fish - a team of world-class experts in bespoke software development. Our engineers are highly skilled in blockchain, cloud solutions, and defi/fintech development. Our strength and pride is the ability to take ownership of the entire development process and be a true partner and advisor for our customers. Our mission is to craft state-of-the-art digital products using battle-tested technologies. Try us!
40uniquely skilled devs
1pet-friendly office
8years in business
42projects
999passion for coding
What do we do?
Software Development Services and Skills for your needs
Our team is well-versed and experienced in various blockchain development tools and technologies. Our unique skillset allows us to be at the forefront of Web3 development services so if you’re looking for a trusted IT partner to boost your decentralized product - look no further!
We deliver production-ready zero-knowledge proof solutions that actually ship to mainnet, specializing in custom ZK development, rollup scaling solutions, and privacy-preserving smart contracts that reduce processing times from hours to minutes. Try us!
We build fast, compliant, and cost-effective blockchain solutions on the XRP Ledger. From payment systems and tokenization platforms to enterprise DeFi applications, our team delivers production-ready systems that work when billions are on the line.
Rumble Fish builds Stellar and Soroban software for startups, enterprises, and institutions. We develop payment rails, tokenization platforms, smart contracts, and DeFi applications that draw on Stellar's speed, low costs, and financial infrastructure.
We build smart contracts that handle real business complexity without the usual blockchain headaches. From DeFi protocols to custom on-chain systems, we deliver production-ready solutions that scale.
Decentralized Finance (DeFi) development requires an extensive amount of blockchain knowledge, as well as a great understanding of financial mechanisms. We’ve got both that bases covered! Our team has successfully built an impressive number of DeFi products like cryptocurrency exchanges, dApps, lending protocols, or staking platforms. Try us!
Our experienced team will take your AWS cloud solutions to the next level. AWS provides purpose-built tools to support your needs, and it is the preferred choice for any blockchain project. From the plethora of cloud tools and solutions offered by Amazon Web Services, we’ll help you choose and implement the ones that serve your business the best way possible.
AI chatbots can bring value to a wide range of industries by enhancing customer interactions, streamlining processes, and improving overall efficiency. We'll craft a perfect AI assistant for your product.
Need realistic data for AI training, testing, or product development—but privacy, scale, or availability is blocking you? We engineer custom synthetic data solutions that capture the complexity of real-world data without the constraints. From multi-modal generation to domain-specific datasets, we build what platforms can't deliver.
We build custom AI knowledge management systems that turn your scattered enterprise knowledge into instant, accurate answers - no more employees wasting their valuable time hunting through SharePoint and Slack for information. Unlike platforms that trap you in subscriptions, we engineer RAG solutions specifically for your data and security requirements, then hand you complete ownership of the source code and infrastructure.
Looking for a skilled team to help you build an advanced fintech platform able to compete with the biggest in the game? At Rumble Fish, we’ve got what it takes to engineer innovative financial technology systems. We offer end-to-end fintech software development, consulting, and expertise.
Our experts provide you with knowledge, skills, and experience that elevates every project to another level. We’ll gladly take ownership of the entire process and guide you and your team through the intricacies of cutting-edge technology development.
If you’re in need of professional web development services, look no further! Rumble Fish's talented team has extensive experience in delivering top-tier web apps and websites with the use of battle-tested tools and technologies like React or Nest. We know just the right solutions to exceed your business requirements.
Whether you need an Android, an IOS app, or both, the Rumble Fish team is here to help you deliver the beautiful and efficient mobile product that your customers will simply love to use! We craft fast and secure mobile apps with a wow factor to help our customers grow their businesses and reach their goals quicker.
If you're looking for a team capable of turning your product concept into a beautiful and technologically intricate digital solution - look no further! Rumble Fish is your trusted software development partner ready to take you through the entire process of custom digital product creation - from the early stages of ideation to the post-launch support. Whether you're on a mission to build a mobile app, a Web3 product, or an advanced platform - we are here for you!
We design sleek, intuitive, and highly effective interfaces to help you overcome your business challenges. After carefully evaluating and understanding your requirements we switch to the designing mode - the end goal is the beautiful digital solution that people love to use!
Testimonials
See what our customers say about working with us“
Latest case studyPorting Merkl to Stellar: Full Protocol Migration to Soroban
Porting Merkl to Stellar: Full Protocol Migration to Soroban
Collaboration timeframe:4 weeks
Services:Smart Contract Development, Blockchain Development, Stellar Product Development, DeFi Development
We're trusted by global innovators and leaders.Join them!
TURNTABLE
A hybrid of a social network and a music appTURNTABLE
MAKERDAO
The first truly decentralized stablecoin crypto on EthereumMAKERDAO
ZBAY
A private inbox, wallet, and marketplace all in oneZBAY
VERIFYID
An identity verification MVPVERIFYID
Rumblefish Blog
RWA Tokenization Platform Development: The Decisions That Determine Whether It WorksEvery RWA tokenization platform development project starts with the same pitch: take an illiquid asset - real estate, private credit, treasury bills, invoices - and represent ownership as a token that can be split, traded, and settled on-chain. The pitch is simple. The engineering is not, and the part that trips up most teams has nothing to do with smart contracts.
Minting a token is the easy ten percent. The hard ninety percent is everything the token has to represent honestly: who's legally allowed to hold it, what happens when a regulator asks you to freeze a wallet, how the token's value stays pinned to an asset that lives entirely off-chain, and what happens the day someone wants their money back instead of their token. Get any of these wrong, and you're looking at a compliance incident or a broken peg.
This is a walkthrough of the decisions that actually shape an RWA tokenization platform, based on the tradeoffs we've navigated building them.
## Token Standard: Why ERC-20 Is the Wrong Default
The instinct on Ethereum is to reach for ERC-20. It's the standard every wallet, exchange, and DeFi protocol already understands, and for a purely fungible asset with no transfer restrictions, it would be fine. Real-world assets rarely fit that description.
A tokenized security has to enforce who can hold it: accredited investor status, jurisdictional restrictions, lock-up periods, sanctions screening, all checked at transfer time, not just at issuance. Plain ERC-20 has no hook for that. Every restriction ends up bolted on as an off-chain process the smart contract knows nothing about, so the contract will happily execute a transfer your compliance team would have blocked.
[ERC-3643 (T-REX)](https://eips.ethereum.org/EIPS/eip-3643) builds identity and transfer restrictions into the token standard itself. Every holder address links to an on-chain identity claim, verified against a registry of eligible investors, and every transfer runs through a compliance module before it settles. The restriction lives in the same place as the token logic instead of in a separate system that has to stay in sync with it.
The tradeoff is complexity. An ERC-3643 deployment involves an identity registry, a claims topic registry, trusted issuers, and a compliance contract, versus a single contract for plain ERC-20. For a platform that will actually be regulated, that complexity is the feature. We've watched teams try to ship the simple version first and bolt compliance on later. It doesn't retrofit cleanly, because the whole point of the standard is enforcing restrictions at the transfer layer itself, where a bolted-on contract was never designed to check them.
## Chain Selection: Settlement Cost Is a Business Requirement
For a security token settling a handful of times a day, Ethereum mainnet gas costs are a rounding error. For a tokenized payments rail or a platform issuing fractional shares to retail users making frequent small trades, they're the business model.
Stellar, through Soroban, runs typical token transfers for fractions of a cent with finality landing in roughly three to five seconds. That fee profile matters directly for platforms built around frequent, small-value transfers: tokenized remittances, fractional real estate with active secondary trading, stablecoin-denominated payment rails. Stellar also ships with [SEP-8 (Regulated Assets)](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md), a protocol-level mechanism for authorization-required and authorization-revocable assets. That gives you transfer-restriction primitives at the account level, without building an entire compliance layer from scratch the way you would on EVM chains.
XRPL offers a comparable cost and speed profile, plus native freeze and authorization flags on issued currencies, no smart contract required for the basic compliance primitives. That's attractive for simpler asset structures where you need the standard set of freeze and authorize controls and nothing more elaborate.
Ethereum and its L2s remain the default when a platform needs the deepest liquidity and DeFi composability, where the tokenized asset has to plug into lending markets, DEXs, or custody infrastructure already built for the EVM. You pay for that ecosystem depth in gas costs and settlement latency, even on an L2.
The right answer depends on which cost and composability profile matches how the asset will actually be used. A tokenized treasury bill that settles a few times a week and needs to sit as collateral in existing DeFi protocols belongs on Ethereum or an L2. A tokenized real estate platform doing frequent fractional trades among retail holders fits Stellar's fee structure far better.
## Identity and Compliance: On-Chain Claims, Off-Chain Verification
The compliance layer splits into two problems that get conflated more often than they should: verifying who someone is, and enforcing what they're allowed to do once you know.
Identity verification (KYC documents, accredited investor attestations, sanctions screening) doesn't belong on-chain. It involves personally identifiable information, it changes over time, and it needs to integrate with providers like Sumsub or Persona that were never built with blockchain in mind. That stays off-chain.
What goes on-chain is the claim itself. A trusted issuer, your KYC provider or a licensed verification partner, signs an attestation that a wallet address belongs to a verified, eligible holder, and that signed claim gets registered against the identity contract. The smart contract checks that claim without ever touching the documents behind it. This is the model both ERC-3643's identity registry and Stellar's SEP-8 authorization flags are built around: sensitive data stays off-chain, the yes/no answer sits on-chain where the transfer logic can actually use it.
The failure mode we've seen most often is teams trying to keep the on-chain and off-chain systems perfectly synchronized in real time. Don't. Design for eventual consistency instead: a claim gets issued or revoked, propagation to the chain happens within a defined window, and the transfer logic checks the claim's current state at the moment of transfer. A revoked claim should make the next transfer fail immediately, even if the revocation happened five minutes ago and the wallet hasn't tried to move funds since.
## Custody and the Peg: Proving the Token Is Worth What It Says
A tokenized asset is a claim on something that lives off-chain: a bank account, a title deed, a basket of treasuries. The token is only as trustworthy as the mechanism proving that claim is real, and this is where a lot of platforms are quietly weaker than they look.
The minimum viable version is a proof-of-reserve attestation: a custodian or auditor periodically confirms the off-chain asset backing matches the on-chain supply, published as a signed message or a Merkle root anchored on-chain. That's better than nothing, but it's a snapshot. The gap between attestations is exactly where problems hide.
A stronger design reports backing data through an oracle network on a schedule, rather than relying entirely on periodic manual attestation. [Chainlink's Proof of Reserve feeds](https://chain.link/proof-of-reserve) are the most established example: a decentralized oracle network independently verifies custodial balances and pushes that data on-chain, where the token contract can check it directly and pause minting if reported reserves fall below circulating supply. Chainlink markets this specifically as "Secure Mint": the reserve check sits inside the mint function itself, so the contract simply refuses to mint past what's backed. That turns a manually reviewed attestation into a system with an automated circuit breaker.
For real estate or private credit, where the underlying asset doesn't have a real-time price feed the way a treasury bill does, full real-time proof of reserve isn't achievable, and platforms that claim otherwise are overselling it. What you can build instead is a published valuation methodology, an independent appraiser or administrator, and a defined cadence for updating the on-chain NAV. Being explicit about what's actually verifiable on-chain builds more trust than pretending an illiquid asset has a live price feed it doesn't have.
## Redemption: The Feature Everyone Designs Last
Issuance gets the design attention. Redemption, turning the token back into cash or the underlying asset, usually gets bolted on afterward, and it's the part that determines whether holders trust the platform during stress.
The core design question is whether redemption is synchronous or queued. A tokenized money market fund backed by highly liquid treasuries can support near-instant redemption: burn the token, wire the cash, inside the settlement window of the underlying instrument. A tokenized real estate fund can't. Redemption has to queue against actual liquidity events: a property sale, a refinancing, a matching secondary buyer. The platform needs to be honest about that timeline instead of implying instant liquidity it can't deliver.
Getting this wrong cuts both ways. Overpromise liquidity the underlying asset can't support, and you end up with a run you can't honor. Underdeliver on a genuinely liquid asset and you're forcing unnecessary queuing on holders who didn't need it. The redemption mechanism should be sized to the actual liquidity profile of what's backing the token, decided at the architecture stage, not patched in after the first redemption request exposes the gap.
---
The chain constrains which compliance primitives are available natively. The token standard determines how deeply identity checks are embedded versus bolted on. The redemption design only works if the reserve verification underneath it is trustworthy enough for holders to believe the queue is real rather than a stall tactic. None of these decisions get made in isolation on a platform that actually survives contact with a regulator or a market downturn.
The tooling already exists: ERC-3643, SEP-8, Chainlink's Proof of Reserve. None of it is exotic anymore. What's still genuinely hard is choosing the right combination for the asset in front of you, and saying no to the shortcuts that look fine until the first redemption request or the first regulator inquiry arrives.
---
Rumble Fish has built tokenization infrastructure across Stellar, XRPL, and EVM chains, and spent enough time in the gap between "the token works" and "the token is defensible" to have opinions about it. If you're scoping an RWA tokenization platform and want to talk through the compliance and custody architecture before you commit to a chain or a standard, [get in touch](https://rumblefish.dev/contact).
Stellar vs Ethereum: Choosing the Right Blockchain for Payment InfrastructureEthereum and Stellar are both enormous networks with real production deployments in payments. However, they were designed around different assumptions about what "payment" means, and those assumptions surface everywhere once you start building. This is a practical comparison based on what it actually takes to ship a payment product on each. Let's dive in!
### What Each Network Was Designed For
Ethereum launched in 2015 as a general-purpose programmable blockchain. Payments are possible on Ethereum, but they were never the primary design goal. The network was built to support arbitrary computation, and payments are one application among many. That design philosophy has consequences that run through the entire stack. Stellar launched in 2014 with a narrower mandate: fast, cheap, cross-border value transfer. The native asset model, the built-in order book, the Stellar Consensus Protocol - all of it reflects the assumption that the primary use case is moving money between parties, including parties on different rails and in different currencies. Soroban, Stellar's smart contract platform, arrived later and extended that foundation without replacing it.
This distinction shapes what you get for free and what you have to build yourself. On Ethereum, you're adapting a general-purpose machine to payments. On Stellar, payments are the default path, and you extend from there.
### Transaction Costs and Finality
The fee difference between Ethereum mainnet and Stellar is not marginal. A simple ETH transfer on mainnet costs somewhere between $0.50 and $5 depending on network conditions, and during congestion it has gone above $50. An ERC-20 transfer costs more than a native transfer because it executes contract code. For any payment product where volume is high or average transaction size is modest, Ethereum mainnet fees are a structural problem, not an occasional inconvenience.
Stellar's base fee is 100 stroops, or 0.00001 XLM. At current prices, that's a fraction of a cent. The network uses fee bumping for prioritization rather than a gas auction, so costs are predictable rather than volatile. For a product processing thousands of transactions per day, the fee difference between the two networks compounds into a real infrastructure cost advantage for Stellar.
Finality follows a similar pattern. Ethereum achieves probabilistic finality: a transaction is considered settled after enough blocks have been added on top of it, which in practice means waiting several minutes for high-confidence confirmation. Stellar's consensus protocol achieves deterministic finality in 3 to 5 seconds. A transaction either made it into a closed ledger or it didn't. There is no "probably settled" state to manage. For payment applications with compliance requirements around settlement timing, that distinction simplifies a significant amount of downstream logic.
Layer 2 networks on Ethereum (Arbitrum, Optimism, Base) close the fee gap considerably. Fees on L2s are typically under a cent, and finality on the L2 itself is fast. But L2 finality and Ethereum mainnet finality are different things, and products with strict settlement requirements need to think carefully about which one they actually need. The L2 ecosystem also adds operational complexity: bridge risk, liquidity fragmentation across chains, and a developer environment that varies between rollups.
### The Asset Model and What It Saves You
One of Stellar's less-discussed advantages for blockchain payment infrastructure is its native asset model. Any account on Stellar can issue an asset, a stablecoin, tokenized fiat, a loyalty instrument, and those assets are first-class citizens on the network. The built-in decentralized exchange means that paths between assets exist automatically: a sender can pay in one currency and a recipient can receive in another, with conversion handled inside the transaction itself. This is not a DeFi protocol layered on top of the base layer; it is the base layer.
On Ethereum, building equivalent functionality requires smart contracts. A stablecoin is an ERC-20 contract. A swap between two stablecoins goes through a DEX or custom contract logic. Each additional layer adds gas cost, audit surface, and failure modes. For complex payment routing across currencies, the contract code required on Ethereum is substantially more involved than the equivalent path payment on Stellar.
Soroban extends this further. With Soroban smart contracts, you can add programmable payment logic - conditional releases, escrow, multi-party settlement - directly on top of Stellar's native asset model. A Soroban contract interacts with native Stellar assets without replacing them. You get programmability and the built-in payment primitives, which is a different architecture from Ethereum, where the asset model and the execution environment are the same thing.
### Compliance and Institutional Considerations
Payment products in regulated environments have requirements beyond raw technical performance. KYC, AML, transaction monitoring, the ability to freeze assets in response to legal orders: these are table stakes for anything handling real money in most jurisdictions.
Stellar has compliance controls at the protocol level. Regulated assets can require authorization before an account can hold or transact them. An issuer can freeze a specific account's holdings or globally freeze an asset. These controls are part of the asset model, not implemented via contract code. For an institution that needs to demonstrate asset control to regulators or auditors, the fact that these are protocol primitives rather than custom contract logic reduces implementation risk and simplifies the audit. Ethereum supports equivalent functionality through smart contract design. A well-written ERC-20 can include pause functions, blocklists, and administrative controls. The difference is that on Ethereum, you're implementing and auditing those controls yourself, while on Stellar, they're part of the protocol specification. The failure mode on Ethereum is a smart contract bug. The failure mode on Stellar is a misconfigured flag. Both are manageable, but they require different expertise and carry different audit costs.
### Where Ethereum Has the Advantage
This is not a case where one network is better for all payment use cases.
* The Ethereum developer ecosystem is larger by an order of magnitude. Tooling is more mature, auditing firms have deeper Ethereum experience, and the pool of engineers who can be hired is bigger. For a team building from scratch without existing blockchain expertise, Ethereum has a shorter path to production.
* DeFi liquidity lives predominantly on Ethereum and its L2s. If your payment product needs to interact with lending markets, AMMs, or yield protocols, the depth of what's available on Arbitrum or Optimism is not matched on Stellar. Soroban-based DeFi is growing, but it's early. For blockchains for DeFi with complex composability requirements, Ethereum remains the stronger environment.
* Token distribution also favors Ethereum. USDC and USDT have large liquidity pools on Ethereum. If your users already hold stablecoins there, moving them to a Stellar-based product requires a bridging step that adds friction. For consumer-facing products where users arrive with existing balances, that friction is real.
### How to Make the Call
The right choice depends on what your payment product actually does, and a few questions tend to clarify it quickly.
**What's the expected transaction volume and average transaction size?**
* High volume, small transactions: Stellar's fee model is a structural cost advantage that compounds at scale.
* Low volume, large transactions: Ethereum mainnet fees are manageable, and the ecosystem benefits may outweigh them.
**Do you need programmable logic beyond basic transfers?**
* Soroban handles most payment-adjacent use cases now. If your logic requires deep integration with Ethereum DeFi protocols, that tips the balance toward Ethereum L2.
**Do you have regulatory requirements around asset control?**
* Stellar's protocol-level compliance features reduce implementation risk in ways that matter to compliance teams and reduce audit scope.
**Where do your users and liquidity already live?**
* Building a new corridor from scratch: Stellar is a strong default. Plugging into an existing Ethereum-native ecosystem: the switching cost probably doesn't justify the move.
At Rumble Fish, the payment projects that have gone smoothest on Stellar share a common profile: high transaction volumes, multi-currency requirements, and institutional compliance needs. Projects where Ethereum made more sense were those where DeFi composability was central, or where the team was already deep in the Ethereum stack and rebuilding on a new network would have cost more than it saved.
For most payment applications, the comparison between Ethereum and Stellar is not about which network is technically superior in the abstract. It's about which one matches the shape of your problem. If you're working through that decision and want a second opinion from a team that has made it in production, [we're happy to talk](https://www.rumblefish.dev/contact/).
Check a piece of expert knowledge
RWA Tokenization Platform Development: The Decisions That Determine Whether It WorksEvery RWA tokenization platform development project starts with the same pitch: take an illiquid asset - real estate, private credit, treasury bills, invoices - and represent ownership as a token that can be split, traded, and settled on-chain. The pitch is simple. The engineering is not, and the part that trips up most teams has nothing to do with smart contracts.
Minting a token is the easy ten percent. The hard ninety percent is everything the token has to represent honestly: who's legally allowed to hold it, what happens when a regulator asks you to freeze a wallet, how the token's value stays pinned to an asset that lives entirely off-chain, and what happens the day someone wants their money back instead of their token. Get any of these wrong, and you're looking at a compliance incident or a broken peg.
This is a walkthrough of the decisions that actually shape an RWA tokenization platform, based on the tradeoffs we've navigated building them.
## Token Standard: Why ERC-20 Is the Wrong Default
The instinct on Ethereum is to reach for ERC-20. It's the standard every wallet, exchange, and DeFi protocol already understands, and for a purely fungible asset with no transfer restrictions, it would be fine. Real-world assets rarely fit that description.
A tokenized security has to enforce who can hold it: accredited investor status, jurisdictional restrictions, lock-up periods, sanctions screening, all checked at transfer time, not just at issuance. Plain ERC-20 has no hook for that. Every restriction ends up bolted on as an off-chain process the smart contract knows nothing about, so the contract will happily execute a transfer your compliance team would have blocked.
[ERC-3643 (T-REX)](https://eips.ethereum.org/EIPS/eip-3643) builds identity and transfer restrictions into the token standard itself. Every holder address links to an on-chain identity claim, verified against a registry of eligible investors, and every transfer runs through a compliance module before it settles. The restriction lives in the same place as the token logic instead of in a separate system that has to stay in sync with it.
The tradeoff is complexity. An ERC-3643 deployment involves an identity registry, a claims topic registry, trusted issuers, and a compliance contract, versus a single contract for plain ERC-20. For a platform that will actually be regulated, that complexity is the feature. We've watched teams try to ship the simple version first and bolt compliance on later. It doesn't retrofit cleanly, because the whole point of the standard is enforcing restrictions at the transfer layer itself, where a bolted-on contract was never designed to check them.
## Chain Selection: Settlement Cost Is a Business Requirement
For a security token settling a handful of times a day, Ethereum mainnet gas costs are a rounding error. For a tokenized payments rail or a platform issuing fractional shares to retail users making frequent small trades, they're the business model.
Stellar, through Soroban, runs typical token transfers for fractions of a cent with finality landing in roughly three to five seconds. That fee profile matters directly for platforms built around frequent, small-value transfers: tokenized remittances, fractional real estate with active secondary trading, stablecoin-denominated payment rails. Stellar also ships with [SEP-8 (Regulated Assets)](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md), a protocol-level mechanism for authorization-required and authorization-revocable assets. That gives you transfer-restriction primitives at the account level, without building an entire compliance layer from scratch the way you would on EVM chains.
XRPL offers a comparable cost and speed profile, plus native freeze and authorization flags on issued currencies, no smart contract required for the basic compliance primitives. That's attractive for simpler asset structures where you need the standard set of freeze and authorize controls and nothing more elaborate.
Ethereum and its L2s remain the default when a platform needs the deepest liquidity and DeFi composability, where the tokenized asset has to plug into lending markets, DEXs, or custody infrastructure already built for the EVM. You pay for that ecosystem depth in gas costs and settlement latency, even on an L2.
The right answer depends on which cost and composability profile matches how the asset will actually be used. A tokenized treasury bill that settles a few times a week and needs to sit as collateral in existing DeFi protocols belongs on Ethereum or an L2. A tokenized real estate platform doing frequent fractional trades among retail holders fits Stellar's fee structure far better.
## Identity and Compliance: On-Chain Claims, Off-Chain Verification
The compliance layer splits into two problems that get conflated more often than they should: verifying who someone is, and enforcing what they're allowed to do once you know.
Identity verification (KYC documents, accredited investor attestations, sanctions screening) doesn't belong on-chain. It involves personally identifiable information, it changes over time, and it needs to integrate with providers like Sumsub or Persona that were never built with blockchain in mind. That stays off-chain.
What goes on-chain is the claim itself. A trusted issuer, your KYC provider or a licensed verification partner, signs an attestation that a wallet address belongs to a verified, eligible holder, and that signed claim gets registered against the identity contract. The smart contract checks that claim without ever touching the documents behind it. This is the model both ERC-3643's identity registry and Stellar's SEP-8 authorization flags are built around: sensitive data stays off-chain, the yes/no answer sits on-chain where the transfer logic can actually use it.
The failure mode we've seen most often is teams trying to keep the on-chain and off-chain systems perfectly synchronized in real time. Don't. Design for eventual consistency instead: a claim gets issued or revoked, propagation to the chain happens within a defined window, and the transfer logic checks the claim's current state at the moment of transfer. A revoked claim should make the next transfer fail immediately, even if the revocation happened five minutes ago and the wallet hasn't tried to move funds since.
## Custody and the Peg: Proving the Token Is Worth What It Says
A tokenized asset is a claim on something that lives off-chain: a bank account, a title deed, a basket of treasuries. The token is only as trustworthy as the mechanism proving that claim is real, and this is where a lot of platforms are quietly weaker than they look.
The minimum viable version is a proof-of-reserve attestation: a custodian or auditor periodically confirms the off-chain asset backing matches the on-chain supply, published as a signed message or a Merkle root anchored on-chain. That's better than nothing, but it's a snapshot. The gap between attestations is exactly where problems hide.
A stronger design reports backing data through an oracle network on a schedule, rather than relying entirely on periodic manual attestation. [Chainlink's Proof of Reserve feeds](https://chain.link/proof-of-reserve) are the most established example: a decentralized oracle network independently verifies custodial balances and pushes that data on-chain, where the token contract can check it directly and pause minting if reported reserves fall below circulating supply. Chainlink markets this specifically as "Secure Mint": the reserve check sits inside the mint function itself, so the contract simply refuses to mint past what's backed. That turns a manually reviewed attestation into a system with an automated circuit breaker.
For real estate or private credit, where the underlying asset doesn't have a real-time price feed the way a treasury bill does, full real-time proof of reserve isn't achievable, and platforms that claim otherwise are overselling it. What you can build instead is a published valuation methodology, an independent appraiser or administrator, and a defined cadence for updating the on-chain NAV. Being explicit about what's actually verifiable on-chain builds more trust than pretending an illiquid asset has a live price feed it doesn't have.
## Redemption: The Feature Everyone Designs Last
Issuance gets the design attention. Redemption, turning the token back into cash or the underlying asset, usually gets bolted on afterward, and it's the part that determines whether holders trust the platform during stress.
The core design question is whether redemption is synchronous or queued. A tokenized money market fund backed by highly liquid treasuries can support near-instant redemption: burn the token, wire the cash, inside the settlement window of the underlying instrument. A tokenized real estate fund can't. Redemption has to queue against actual liquidity events: a property sale, a refinancing, a matching secondary buyer. The platform needs to be honest about that timeline instead of implying instant liquidity it can't deliver.
Getting this wrong cuts both ways. Overpromise liquidity the underlying asset can't support, and you end up with a run you can't honor. Underdeliver on a genuinely liquid asset and you're forcing unnecessary queuing on holders who didn't need it. The redemption mechanism should be sized to the actual liquidity profile of what's backing the token, decided at the architecture stage, not patched in after the first redemption request exposes the gap.
---
The chain constrains which compliance primitives are available natively. The token standard determines how deeply identity checks are embedded versus bolted on. The redemption design only works if the reserve verification underneath it is trustworthy enough for holders to believe the queue is real rather than a stall tactic. None of these decisions get made in isolation on a platform that actually survives contact with a regulator or a market downturn.
The tooling already exists: ERC-3643, SEP-8, Chainlink's Proof of Reserve. None of it is exotic anymore. What's still genuinely hard is choosing the right combination for the asset in front of you, and saying no to the shortcuts that look fine until the first redemption request or the first regulator inquiry arrives.
---
Rumble Fish has built tokenization infrastructure across Stellar, XRPL, and EVM chains, and spent enough time in the gap between "the token works" and "the token is defensible" to have opinions about it. If you're scoping an RWA tokenization platform and want to talk through the compliance and custody architecture before you commit to a chain or a standard, [get in touch](https://rumblefish.dev/contact).Blockchain
Stellar vs Ethereum: Choosing the Right Blockchain for Payment InfrastructureEthereum and Stellar are both enormous networks with real production deployments in payments. However, they were designed around different assumptions about what "payment" means, and those assumptions surface everywhere once you start building. This is a practical comparison based on what it actually takes to ship a payment product on each. Let's dive in!
### What Each Network Was Designed For
Ethereum launched in 2015 as a general-purpose programmable blockchain. Payments are possible on Ethereum, but they were never the primary design goal. The network was built to support arbitrary computation, and payments are one application among many. That design philosophy has consequences that run through the entire stack. Stellar launched in 2014 with a narrower mandate: fast, cheap, cross-border value transfer. The native asset model, the built-in order book, the Stellar Consensus Protocol - all of it reflects the assumption that the primary use case is moving money between parties, including parties on different rails and in different currencies. Soroban, Stellar's smart contract platform, arrived later and extended that foundation without replacing it.
This distinction shapes what you get for free and what you have to build yourself. On Ethereum, you're adapting a general-purpose machine to payments. On Stellar, payments are the default path, and you extend from there.
### Transaction Costs and Finality
The fee difference between Ethereum mainnet and Stellar is not marginal. A simple ETH transfer on mainnet costs somewhere between $0.50 and $5 depending on network conditions, and during congestion it has gone above $50. An ERC-20 transfer costs more than a native transfer because it executes contract code. For any payment product where volume is high or average transaction size is modest, Ethereum mainnet fees are a structural problem, not an occasional inconvenience.
Stellar's base fee is 100 stroops, or 0.00001 XLM. At current prices, that's a fraction of a cent. The network uses fee bumping for prioritization rather than a gas auction, so costs are predictable rather than volatile. For a product processing thousands of transactions per day, the fee difference between the two networks compounds into a real infrastructure cost advantage for Stellar.
Finality follows a similar pattern. Ethereum achieves probabilistic finality: a transaction is considered settled after enough blocks have been added on top of it, which in practice means waiting several minutes for high-confidence confirmation. Stellar's consensus protocol achieves deterministic finality in 3 to 5 seconds. A transaction either made it into a closed ledger or it didn't. There is no "probably settled" state to manage. For payment applications with compliance requirements around settlement timing, that distinction simplifies a significant amount of downstream logic.
Layer 2 networks on Ethereum (Arbitrum, Optimism, Base) close the fee gap considerably. Fees on L2s are typically under a cent, and finality on the L2 itself is fast. But L2 finality and Ethereum mainnet finality are different things, and products with strict settlement requirements need to think carefully about which one they actually need. The L2 ecosystem also adds operational complexity: bridge risk, liquidity fragmentation across chains, and a developer environment that varies between rollups.
### The Asset Model and What It Saves You
One of Stellar's less-discussed advantages for blockchain payment infrastructure is its native asset model. Any account on Stellar can issue an asset, a stablecoin, tokenized fiat, a loyalty instrument, and those assets are first-class citizens on the network. The built-in decentralized exchange means that paths between assets exist automatically: a sender can pay in one currency and a recipient can receive in another, with conversion handled inside the transaction itself. This is not a DeFi protocol layered on top of the base layer; it is the base layer.
On Ethereum, building equivalent functionality requires smart contracts. A stablecoin is an ERC-20 contract. A swap between two stablecoins goes through a DEX or custom contract logic. Each additional layer adds gas cost, audit surface, and failure modes. For complex payment routing across currencies, the contract code required on Ethereum is substantially more involved than the equivalent path payment on Stellar.
Soroban extends this further. With Soroban smart contracts, you can add programmable payment logic - conditional releases, escrow, multi-party settlement - directly on top of Stellar's native asset model. A Soroban contract interacts with native Stellar assets without replacing them. You get programmability and the built-in payment primitives, which is a different architecture from Ethereum, where the asset model and the execution environment are the same thing.
### Compliance and Institutional Considerations
Payment products in regulated environments have requirements beyond raw technical performance. KYC, AML, transaction monitoring, the ability to freeze assets in response to legal orders: these are table stakes for anything handling real money in most jurisdictions.
Stellar has compliance controls at the protocol level. Regulated assets can require authorization before an account can hold or transact them. An issuer can freeze a specific account's holdings or globally freeze an asset. These controls are part of the asset model, not implemented via contract code. For an institution that needs to demonstrate asset control to regulators or auditors, the fact that these are protocol primitives rather than custom contract logic reduces implementation risk and simplifies the audit. Ethereum supports equivalent functionality through smart contract design. A well-written ERC-20 can include pause functions, blocklists, and administrative controls. The difference is that on Ethereum, you're implementing and auditing those controls yourself, while on Stellar, they're part of the protocol specification. The failure mode on Ethereum is a smart contract bug. The failure mode on Stellar is a misconfigured flag. Both are manageable, but they require different expertise and carry different audit costs.
### Where Ethereum Has the Advantage
This is not a case where one network is better for all payment use cases.
* The Ethereum developer ecosystem is larger by an order of magnitude. Tooling is more mature, auditing firms have deeper Ethereum experience, and the pool of engineers who can be hired is bigger. For a team building from scratch without existing blockchain expertise, Ethereum has a shorter path to production.
* DeFi liquidity lives predominantly on Ethereum and its L2s. If your payment product needs to interact with lending markets, AMMs, or yield protocols, the depth of what's available on Arbitrum or Optimism is not matched on Stellar. Soroban-based DeFi is growing, but it's early. For blockchains for DeFi with complex composability requirements, Ethereum remains the stronger environment.
* Token distribution also favors Ethereum. USDC and USDT have large liquidity pools on Ethereum. If your users already hold stablecoins there, moving them to a Stellar-based product requires a bridging step that adds friction. For consumer-facing products where users arrive with existing balances, that friction is real.
### How to Make the Call
The right choice depends on what your payment product actually does, and a few questions tend to clarify it quickly.
**What's the expected transaction volume and average transaction size?**
* High volume, small transactions: Stellar's fee model is a structural cost advantage that compounds at scale.
* Low volume, large transactions: Ethereum mainnet fees are manageable, and the ecosystem benefits may outweigh them.
**Do you need programmable logic beyond basic transfers?**
* Soroban handles most payment-adjacent use cases now. If your logic requires deep integration with Ethereum DeFi protocols, that tips the balance toward Ethereum L2.
**Do you have regulatory requirements around asset control?**
* Stellar's protocol-level compliance features reduce implementation risk in ways that matter to compliance teams and reduce audit scope.
**Where do your users and liquidity already live?**
* Building a new corridor from scratch: Stellar is a strong default. Plugging into an existing Ethereum-native ecosystem: the switching cost probably doesn't justify the move.
At Rumble Fish, the payment projects that have gone smoothest on Stellar share a common profile: high transaction volumes, multi-currency requirements, and institutional compliance needs. Projects where Ethereum made more sense were those where DeFi composability was central, or where the team was already deep in the Ethereum stack and rebuilding on a new network would have cost more than it saved.
For most payment applications, the comparison between Ethereum and Stellar is not about which network is technically superior in the abstract. It's about which one matches the shape of your problem. If you're working through that decision and want a second opinion from a team that has made it in production, [we're happy to talk](https://www.rumblefish.dev/contact/).Blockchain
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
together!We will answer any questions you may have related to your startup journey!Do you prefer e-mail?
hello@rumblefish.pl
RUMBLEFISH POLAND SP Z O.O.Filipa Eisenberga 11/3 31-523 Kraków, Polska
NIP: 6772425725REGON: 368368380KRS: 0000696628
P: +48 601 265 364E: hello@rumblefish.dev
Copyright © 2026 RumblefishServicesBlockchain Software DevelopmentZero-Knowledge Proof DevelopmentXRPL Blockchain DevelopmentStellar Product DevelopmentSmart Contract DevelopmentDeFi DevelopmentAWS Cloud SolutionsAI Chat Assistant DevelopmentSynthetic Data GenerationFintech Software DevelopmentDedicated Development TeamsWeb developmentMobile developmentIT Services for startupUI/UXRust Web App DevelopmentView all services
CareersJoin Our Team
