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
Soroban Scan Is Live: The Soroban Block Explorer Built for the Whole Ecosystem
By Agnieszka DoboszEarlier this year, Rumble Fish received a $131,200 grant from the Stellar Community Fund to build a Soroban-first block explorer. Today, that tool is publicly available at [sorobanscan.rumblefish.dev](https://sorobanscan.rumblefish.dev).
The grant announcement covered what we were going to build and why. This one covers what we actually shipped, what we learned building it, and what we want from the community now that it's live.
## What Soroban Scan Does
If you've tried to debug Soroban transactions using existing tools, you know the problem. Events show up as raw XDR. Contract invocations are unreadable without manually decoding binary data. Account history is incomplete or absent for anything Soroban-specific. For anyone who isn't fluent in the Stellar protocol's binary formats, existing explorers offer very little. Soroban Scan is built around the assumption that block explorers should be readable by developers, users, and anyone curious about what's happening on-chain, not just protocol engineers who know how to interpret XDR.
Transaction pages show Soroban invocations with decoded function names, arguments, and return values. If a transaction called a swap function with specific token amounts, you see the function name and the amounts, not a hex string. Contract pages list all invocations of a given contract with the same human-readable decoding applied across the board. Function signatures are extracted from the WASM bytecode at deployment time, which is what makes decoding possible without a separate ABI file.
Event tabs decode CAP-67 contract events into structured tables: topics and data fields presented as typed values, not opaque base64 blobs. For DeFi activity like swaps, transfers, and liquidity changes, the Event Interpreter layer generates plain-language summaries. Account pages surface Soroban-specific history: which contracts an account has interacted with, what those interactions did, and the full event trail. Global search covers transaction hashes, account IDs, and contract IDs.
## How We Got Here
The build followed the three-tranche structure in our SCF submission. Tranche 1 was the data pipeline: Galexie running on ECS Fargate, writing LedgerCloseMeta XDR files to S3 every five to six seconds, a Rust Lambda firing on each file to parse and write to our database, and the CloudWatch monitoring stack. By the end of Tranche 1, we were ingesting live mainnet data reliably.
Tranche 2 brought the frontend and the full API surface: all REST endpoints, the React SPA with transaction, ledger, account, contract, and search pages, and the Event Interpreter that generates human-readable summaries for known DeFi protocol interactions. The staging environment at this point was showing live mainnet data with Soroban events decoded.
Tranche 3 was production hardening: load testing to p95 under 200ms at 1 million requests/month equivalent load, a security audit against OWASP Top 10, full API documentation, CI/CD via GitHub Actions, and a seven-day post-launch monitoring report. The architecture is AWS-first (Lambda, ECS Fargate, API Gateway, CloudFront), with a ClickHouse database on Hetzner that turned a projected 7 TB PostgreSQL dataset into roughly 900 MB.
One thing that was genuinely harder than the architecture docs suggested: the historical backfill. Soroban has been on mainnet since late 2023, which meant indexing roughly two years of history before going live. We ended up running the backfill on local machines writing to a local ClickHouse instance, then migrating the result to production, because the event-driven pipeline optimised for continuous ingestion is simply the wrong shape for a one-time bulk operation across millions of ledgers.
## What We Need From You
Soroban Scan is live and stable, but no block explorer gets to call itself finished at launch. The DeFi protocol coverage in the Event Interpreter is real but limited. We're pattern-matching against Soroswap, Aquarius, and Phoenix today, and every Soroban project that builds something new is a new case to handle. Contract decoding works for contracts that embed their WASM, but the ecosystem is growing, and there will be edge cases we haven't seen.
To use Soroban Scan as a Soroban debugger: paste any transaction hash from a smart contract invocation into the search and open the detail page. The decoded function arguments, return values, and event trail are on one page. If something looks wrong, or if a transaction you'd expect to be readable isn't, that's exactly the kind of feedback we need.
Useful things to tell us: contracts or protocols where events aren't decoding correctly; transactions where the human-readable summary is wrong or missing; search edge cases where a transaction hash, account ID, or contract ID returns something unexpected; anything about the UI that makes it harder to understand what a transaction actually did.
[GitHub issues are open.](https://github.com/rumblefishdev/soroban-block-explorer/issues/new) We're also in the Stellar Discord and Telegram. If you're building on Soroban and want your contracts well-represented in the explorer, reach out directly.
The tool is free and indexed from Soroban genesis.
Try it out here → [sorobanscan.rumblefish.dev](https://sorobanscan.rumblefish.dev).
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).
Check a piece of expert knowledge
Soroban Scan Is Live: The Soroban Block Explorer Built for the Whole EcosystemBy Agnieszka DoboszBlockchain
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
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
