DARCA MVP Description
Info
This block фиксирует, what exactly we launched in the pilot, under what conditions, and what product signals we received from real usage.
MVP overview
The pilot in Russia became a practical stress test of “fiat + crypto in one application”: we tested habit formation, trust, predictability of critical actions, and operational resilience.
Note
The MVP was launched as a practical stress test of a banking application with a crypto perimeter, to confirm that a new bank format can be built without fragmentation and without the need to assemble infrastructure from multiple services.
We launched the MVP in Russia as a practical verification that a financial product can be simultaneously simple, fast, and predictable in key user actions - top ups, the first operation, transfers, and entry and exit through the market.
In the pilot, we deliberately kept the focus on what creates habit and trust:
- bringing the user to first value quickly (first top up, first operation, first internal transfer)
- making critical actions predictable (statuses, confirmations, a clear result before pressing “confirm”)
- testing the product on a real volume of operations, not in a laboratory mode
Tip
We evaluate the MVP not “by words”, but by how the user goes through the journey: where they speed up, where they make mistakes, where they return, and which actions become regular.
Pilot conditions: period and geography
Geography: Russia.
Period: October 2024 - May 2025.
We use this exact period as the analysis window because this is the entire duration of the pilot, including the full cycle: launch, growth, accumulation of behavioral data, process stabilization, and a proper shutdown.
What was “in the product” within the MVP
The MVP was assembled as a managed set of perimeters that covers daily scenarios and provides a foundation for entry and exit, while preserving the integrity of “everything in one place”.
First, the base asset perimeter: simultaneously fiat and crypto.
- Fiat balances: RUB and USD
- Crypto assets: USDT (TRC-20), TRX, USDT (BEP-20), BNB
On this base, the key user actions and the “habit loop” operated:
- top ups and transactions inside the application
- instant internal transfers without fees as the foundation of the “daily” scenario
- crypto transactions (within the supported networks)
Next, the “entry and exit” perimeter and conversion, so that the user does not hit a gap between fiat and crypto:
- internal instant exchanger (with a preview of the final result before confirmation)
- P2P marketplace as a flexible entry and exit perimeter
And separately, an early test of demand for a new asset class:
- purchase of RWA in the format of a share of real estate as a test of interest and the “investment asset in a wallet” scenario
To ensure the financial product could withstand real-world use, the MVP also incorporated mandatory quality controls:
- in app chat support
- basic KYC procedures and risk control within the pilot
- stability monitoring and operational processes for service quality
Example
It is important that these blocks were tested not separately, but as a single path: assets → action → predictable result → repeatability.
What we deliberately did NOT try to do in the MVP
The MVP was built to provide clean signals, not to imitate an “ideal super app”. Therefore, we deliberately kept the scope in the zone of validating core value, without blurring the picture with unnecessary layers.
Warning
The more “everything at once” in the pilot, the more noise in the data and the harder it is to understand what really affects user behavior.
In the MVP, we did not include:
- an expanded lineup of assets and networks “all at once”
- complex investment products and combined strategies
- full subscription tiers and a deep tariff grid
- heavy corporate automation (ERP integrations, mass corporate roles, complex regulations)
- a showcase of “all possible modules” - in the MVP we left only those modules that are critical for validating demand and behavior
It was this focus that allowed us to obtain clear signals: what really creates value, where barriers arise, and which elements provide sustainable repeatability of usage.
Users and usage scenarios
The MVP was designed around repeatable user routes: fast transfers, exchange, P2P, and early demand for RWA as an “investment asset in a wallet”.
Info
We describe the MVP through behavior and scenarios, because this is how it becomes clear that the product is actually being used, and not just “looked at”.
Who we tested the MVP on: segments where the “pain” is measured by actions
We launched the MVP not “for everyone at once”, but for audiences where value manifests quickly and measurably: through deposits, transactions, repeatability, and the choice of tools (internal transfers, exchange, P2P).
Key segments:
-
Retail users (individuals)
People who need a fast transfer and a clear operation status. This is also the audience that wants “crypto without pain”: top up, buy/exchange, send, or withdraw, without diving into complex processes and without assembling infrastructure from many services. For some users, Peer-to-peer is important as an entry and exit perimeter: flexibility and deal closure speed are critical to them. And separately, those who consciously want to keep fiat and crypto in one place, so as not to split balances and actions. -
Power users (active users)
This is the audience that does not perform 1 or 2 operations “just to try”, but regularly uses the product, combining several functions. They give the most honest maturity signal: if it is convenient for them, the product withstands scaling. -
Business scenarios (as an MVP perimeter)
Within the pilot, we also tested a practical scenario where a business needs to accept payments and work with crypto operations in combination with clear “banking” logic. At the same time, we kept the business perimeter compact, so as not to blur the main focus - validating mass user scenarios.
Tip
This choice of audiences makes it possible to quickly distinguish “interest” from habit: habit manifests in repeatable actions, not in registration.
Personas: which roles we saw in the product and what was critical for them
So that the MVP is perceived as a coherent system, we describe it through personas and their real routes, rather than through a list of functions.
Persona 1 - “I need a fast transfer”
A person wants to send funds to another user quickly and without unnecessary steps. An instant status and the feeling that the transfer works “like a message” are important. In the MVP metrics, this is confirmed by the fact that internal operations were displayed and confirmed in less than 1 second.
Persona 2 - “I want crypto without pain”
A person stores and uses crypto assets, but it is important for them that there are no unnecessary complexities and errors. The key value moment is the predictability of the result: before confirmation, it is visible what you give and what you will receive (You pay / You receive).
Persona 3 - “P2P as entry and exit”
The user buys and sells via P2P and expects fast deal closure and a clear dispute mechanism. The metrics show this: median close time ~17 minutes, dispute rate ~1.8%.
Persona 4 - “I am testing RWA”
The user wants to see a real asset in a clear digital form. In the MVP, we tested demand for RWA in the format of a share of real estate as the “investment asset in a wallet” scenario. This is confirmed by the numbers: waitlist 1 328, closed test 133, test investments ~$0.32M.
Note
These personas are important because they show: the same core covers different motives without breaking UX, which means the product can be scaled without a patchwork architecture.
Repeatable scenarios: how the user actually went through the journey
We looked at the MVP as a set of scenarios that should become regular. Therefore, we фиксировали not the “presence of a feature”, but the route and the result.
Scenario A - “First fast success”
Registration → (if needed) KYC → first deposit/activation → first transaction.
This scenario determines whether the user understood the product in the first minutes. The metrics confirm that the funnel reached actions: out of 42 653 registrations, 26 879 passed KYC, and 26 044 users made “1+ transaction ever”.
Scenario B - “Internal transfer as a daily action”
Recipient selection → amount → confirmation → instant status and receipt.
In the MVP, internal operations became one of the key drivers: the share of internal operations was 34%, confirmation/status in less than 1 second.
Scenario C - “Exchange inside the application”
Pair selection → amount input → result preview (You pay / You receive) → confirmation → execution → status.
A significant volume was recorded in the exchanger: ~$8.1M.
Scenario D - “P2P as an entry and exit perimeter”
Offer selection → terms fixation → Escrow → payment confirmation → completion → result.
In the metrics: P2P volume ~$9.1M, 34 839 deals, median close ~17 minutes, dispute rate ~1.8%.
Scenario E - “RWA as a new asset class”
Familiarization → waitlist → closed test → test purchase → display in the portfolio.
We tested interest, UX clarity, and trust in a “real world” asset.
Example
In each scenario, the same fundamental value was tested: a predictable result and a clear status, which turn a one time operation into regular behavior.
What user behavior showed
The MVP delivered the main thing: users did not just “register”, but reached actions and repeatability. This is visible in the combination of stable MAU/DAU, retention, and substantial transactional volume across different perimeters (internal transfers, exchange, P2P, RWA).
Assets, networks, and payment rails of the MVP
We deliberately limited the set of assets and networks to test the speed, stability, and predictability of operations on real demand without spreading ourselves across “everything at once”.
Info
The MVP was built around the logic of a managed perimeter: fewer assets and networks, but higher quality, simpler risk control, and faster iterations.
In the MVP, we included a set of assets and networks that covers real needs for entry, storage, and transfer, while allowing the product to remain stable, clear, and predictable.
Fiat perimeter: base currencies
In the pilot, fiat balances were available:
- RUB
- USD
This perimeter was critical for validating the core idea: fiat and crypto in one place must work as a single system, not as two separate services between which the user “moves” money.
Note
Having a fiat perimeter in the MVP made it possible to test “entry and exit” and P2P scenarios without the need to go to third party applications and banks, which means we saw faster where exactly friction and errors arise.
Crypto perimeter: MVP assets
In the pilot, the following crypto assets were available:
- USDT (TRC-20)
- TRX
- USDT (BEP-20)
- BNB
The choice was made in favor of the assets that are most practical for mass scenarios: storing a “digital dollar” and fast transfers, as well as sufficient liquidity for exchange and P2P.
Network perimeters: where crypto operations took place
Crypto operations in the MVP were concentrated in the networks:
- TRC-20 (for USDT and TRX)
- BEP-20 (for USDT and BNB)
This choice made it possible to test real user risks that are typical for the market: “wrong network”, “wrong address” errors, expectations of “free inside”, and so on, while at the same time keeping the cost and speed of operations within understandable bounds.
Warning
Limiting networks in the MVP was not “cutting the product”, but a way to ensure quality and risk control at the stage when it is most important to confirm the viability of the core.
Payment and transaction perimeters: what actually worked
So that the user had a coherent system, the key action perimeters worked in the MVP:
1) Internal transactions inside the application
This is the foundation of daily behavior:
- top ups and operations inside the application
- instant internal transfers without fees
This perimeter tested whether we can give the feeling of a “bank messenger”, where money moves as simply as a message.
2) External crypto transactions
Within the supported networks, the user could receive and send crypto, closing the basic wallet scenario and testing the reliability of network sends.
3) Instant exchange perimeter
In the MVP, an internal instant exchanger operated, which solves the problem of unexpected pricing and “hidden results”: the user sees the outcome before confirmation and understands what will happen.
4) P2P perimeter
The P2P marketplace was connected as an entry and exit method and an alternative liquidity perimeter, which tests deal closure speed, stability, and arbitration performance.
5) Early RWA perimeter
To test demand for an “investment asset in a wallet”, the MVP made it possible to purchase RWA in the format of a share of real estate.
Example
In total, these perimeters closed the main MVP test: can the user go through the path “fiat → crypto → exchange → P2P/transfer → back” in one application, without fragmentation and without the need to assemble their own stack from multiple services.
Internal transfers
Internal transfers became the “habit anchor” of the MVP: instant speed and zero fees inside the ecosystem turn the bank into a daily tool, not a one time wallet.
Info
Internal transfers in the MVP are not an “additional feature”, but a core mechanism that creates repeatability, reduces errors, and removes fragmentation between services.
How it worked in the MVP
Inside the application, the user could transfer funds to other users within the ecosystem, getting a clear and fast experience: “sent - received - see the status”.
Key properties of the internal perimeter in the MVP:
- instant confirmation and status display
Internal operations were displayed and confirmed in less than 1 second. - zero fees inside the ecosystem
The user does not think about network fees and is not forced to keep a separate balance “to pay gas” just to send money to another person. - predictable result
The user sees the outcome and the status immediately, without “hanging” states that are typical for external network operations.
Note
It is precisely internal transfers that form the feeling that “the bank works like a messenger”: money moves as simply as a message, and this sharply lowers the barrier to regular usage.
Why this perimeter matters for the market
This mechanism directly addresses market problems that we see among users:
- slow and expensive transfers
Internal operations do not depend on external blockchains and their load, so the speed is predictable. - hidden fees and unpleasant surprises
Inside the ecosystem, there are no fees, which means there is no situation of “sent less than expected” or “not enough for the fee”. - user errors
Internal transfers reduce classic “wrong address” and “wrong network” errors, because the transfer happens inside the system, without manual entry of long details.
What the MVP data showed
Internal transfers became one of the strongest usage perimeters:
- the share of internal operations amounted to 34% of all operations
- confirmation and status display happened in less than 1 second
This is an important signal: users are not just trying internal transfers, but actually incorporating them into daily behavior.
Tip
For scaling, this is critical: the more money moves inside the ecosystem, the higher the retention, the lower the cost of operations, and the stronger the network effect.
Internal instant exchange
The exchanger in the MVP closed the “most painful” part of the crypto experience: conversion between assets without unnecessary steps, without fragmentation, and with a clear outcome before confirmation.
Info
The internal exchanger is a mechanism that turns a “crypto wallet” into a financial instrument: the user can quickly change the balance structure for a task and do it in one place.
How it worked in the MVP
In the MVP, an internal instant exchanger was available, which allows the user to convert assets inside the application, without going to external exchanges and without assembling separate infrastructure.
The key principle of the exchanger in the MVP is predictability of the result. Before confirming the operation, the user sees the outcome:
- what exactly will be debited
- what exactly will be credited
- in which asset the result will be
This reduces one of the main sources of distrust in the market: when a person performs an exchange and the final amount and conditions “surface” after the fact.
Note
The internal exchanger builds a habit for the user: “I do not think where to buy/sell, I do it inside”, which directly reduces fragmentation of financial actions.
Why this perimeter matters for the market
Exchange is not an “additional feature”, but a hub through which many scenarios pass:
- the user needs to convert an asset “into a convenient format” before sending
- the user needs to exit into another asset to reduce risk or lock in a result
- the user needs to quickly move from fiat to crypto and back within a single life scenario
This is exactly where most products run into problems: broken UX, unclear pricing, complexity, and the feeling of “I will be cheated”.
In the MVP, the exchanger reduces these problems through:
- simplicity (without transitioning to third party services)
- speed (instant execution inside)
- transparency (the outcome is visible before confirmation)
Warning
Important: the preview principle of “what will be debited and what will I receive” applies to exchanges and transfers. When paying by card, we cannot ask the user “are you ready” with an additional step, therefore card operations live by a different confirmation logic.
What the MVP data showed
The exchanger in the MVP recorded real transactional volume:
- total volume through the exchanger amounted to ~$8.1M
This confirms that the exchange was not a “checkbox feature”, but a truly used perimeter in daily routes.
Tip
The exchanger strengthens the ecosystem: it links fiat and crypto into a single balance and supports fast user decisions “here and now”, without going to external platforms.
P2P marketplace
P2P in the MVP became an entry and exit perimeter and a trust test: closure speed, escrow performance, and dispute manageability show whether the product can withstand a real market.
Info
P2P in the MVP is not an “exchange for the sake of an exchange”, but a market perimeter that helps the user solve a practical task: buy or sell an asset in a convenient format, while staying within a single ecosystem.
How it worked in the MVP
In the MVP, a P2P marketplace was launched with a clear deal logic, where three things matter: fixing the terms, payment security, and a fast finalization.
The key principle is that the deal must be manageable and predictable:
- deal terms are fixed at the moment the offer is selected
- the asset is reserved via Escrow, so the deal does not depend on “a word of honor”
- if the terms are correctly fulfilled, the deal is closed and the asset is transferred to the buyer
This perimeter reduces the “market chaos” of classic P2P, where the user needs to constantly control the process, chat, verify payment, and risk errors.
Note
In the MVP, P2P was important as a trust test: if the user believes that the deal closes honestly and quickly, they return and start using the perimeter regularly.
Why this perimeter matters for the market
P2P solves several typical market problems that directly affect mass adoption:
- fragmentation
The user does not go to a separate exchange or service - entry and exit take place within a single system. - unpredictability of the result
The deal has a clear status, escrow, and a completion logic. - dispute risks
Disputes do not destroy the product if there is a transparent arbitration perimeter and manageable scenarios. - speed
For the mass user, it is important not “the most profitable”, but “profitable enough and fast”, so that the operation does not turn into stress.
Warning
P2P always increases operational complexity: ratings, arbitration, disputes, risk metrics. In the MVP, we kept the perimeter manageable to test the model on a real market, but without “overheating” the system.
What the MVP data showed
The P2P perimeter in the pilot showed substantial activity and volume:
- total P2P volume amounted to ~$9.1M
- number of deals: 34 839
- median closure time: ~17 minutes
- dispute share: ~1.8%
These numbers are important because they show not only interest, but also the system’s ability to withstand “real” market mechanics.
Tip
P2P strengthens the ecosystem: it creates additional internal liquidity and reduces the user’s dependence on external platforms, while preserving experience control and service quality.
RWA (early module: share of real estate)
RWA in the MVP was included as an early demand test: can we turn a “real world investment asset” into a clear digital instrument inside a wallet.
Info
RWA in the MVP is not an attempt to “build a big market right away”, but a validation of a key thesis: the user is ready to buy a real asset in the form of a digital share if the interface is transparent and the rules are clear.
Why we included RWA in the MVP
We connected RWA at an early stage to test three fundamental things:
- user interest in assets “outside crypto” (not only tokens and coins, but also the “real world”)
- product understanding: can the user quickly explain to themselves what they are buying and why it makes sense
- trust in the mechanics: is a person ready to store and manage such an asset inside a single application
That is why we chose the format of a share of real estate. It is understandable to the market and fits well into portfolio logic: the asset can be part of a strategy, not a “bet on the price of a coin”.
Note
Adding RWA to the MVP made it possible to test not only the product idea, but also how behavior changes: do new types of users appear, does trust and retention grow due to a “long” asset in the portfolio.
How it looked in the MVP
In the MVP, RWA was connected as a limited perimeter focused on testing demand and UX. The user could:
- see the asset as part of the portfolio
- join a waitlist
- participate in a closed test
- make a test purchase
This was an intentionally “managed” mode, in order to collect high quality signals and not turn the MVP into a legally and operationally heavy system at an early stage.
Warning
At the MVP stage, RWA worked as an early validation of interest and mechanics. We deliberately did not unlock the full potential of RWA, so as not to dilute the goal of the pilot and not to complicate the product picture.
What the MVP data showed
RWA showed standalone demand and user readiness for a new class of assets:
- waitlist: 1 328
- closed test: 133
- test investments: ~$0.32M
This is an important signal: even in an early format, without a “full showcase” and without a large scale marketing machine, users showed interest and performed real actions.
Tip
RWA in the MVP became a confirmation that DARCA can be not only a “wallet and transfers”, but also a foundation for long term financial products that increase retention and expand the market.
Support and communications inside the MVP
Support in the MVP was not “informational”, but operational: it resolved user errors, reduced tension around fees, and helped users go through critical actions without losing trust.
Info
In a financial product, support is part of the reliability system: it affects retention in the same way as transaction speed and UX quality.
What was implemented in the MVP
In the pilot, an in-app chat was enabled, which solved two tasks at the same time:
- helped users go through critical actions (transfers, exchange, P2P) without “panic” and errors
- collected signals about where the product breaks in real behavior, so we could quickly fix root causes
Communications were built around a simple principle: if a user made a mistake or did not understand the mechanics, the task of support is not to “read instructions”, but to bring them to a result, while preserving trust in the product.
Note
We did not treat support as an “add on service”. In the MVP, it was a perimeter that maintained quality and allowed the product to scale safely.
Which support topics dominated and why this matters
In the MVP, we saw a typical market pattern: users most often face not “technical bugs”, but errors and expectations formed by old experience.
The most frequent reasons for обращения:
- address errors (sent to the wrong place)
- network errors (chose the wrong network)
- expectation that “everything will be fee free”, because users are used to internal fee free transfers
Users often did not keep funds to pay the network fee for external sends, and support had to explain that “fee free” refers to internal transfers, while external fees are the standard network fee, not a bank fee.
These tickets are important because they show exactly where the market loses trust. And at the same time, where the product can become stronger: reducing errors through interface, warnings, and education, and gradually turning support from a “firefighting team” into a quality improvement tool.
Tip
Each such case is not a “minus”, but material for improvements: if we reduce the frequency of “address/network” errors and fee misunderstandings, the load on support drops and conversion to repeat usage grows.
Why communications inside the MVP were critical
Support in the MVP directly worked against key market problems:
- against low service quality (fast contact and a clear solution)
- against fragmentation (no need to “look for a solution” in chats and forums - everything is in one place)
- against user errors, which in crypto are often irreversible and cost money
That is why in the MVP, support and communications were treated as part of the “reliability core”, not as an option.
Warning
In crypto products, user errors are often irreversible. If the product does not provide support and explanations “in the moment”, it loses trust faster than in classic banking.
Reliability, security, and risk control (public framework)
In the MVP, we maintained a managed level of security and risk: basic KYC procedures, transaction monitoring, and operational discipline, sufficient for real world usage and honest product conclusions.
Info
This section describes the public framework of what worked in the pilot, without disclosing internal rules and antifraud logic, so as not to give hints to malicious actors.
Reliability as a product function, not a “technical detail”
For the MVP, it was fundamentally important that the user experience did not break on “small things” and did not turn into guesswork: where it got stuck, what happened, whether the money would come back. Therefore, we built reliability as part of the core:
- clear statuses of critical operations (transfers, exchange, P2P)
- integrity control of transactions and correctness of credits
- operational monitoring of stability, so that real user flow does not turn into an “experiment”
Note
A pilot is valuable only when the system withstands real world usage. If the product is unstable, all behavior and conversion metrics become unreliable.
Basic security in the MVP: what was included
In the pilot, the basic perimeters were in place that allow a financial product to exist in reality:
- basic KYC procedures within the pilot
- minimally necessary risk control over operations and behavior
- access control at the application level and standard user session protection measures
- logging and resolution of dispute situations in P2P as part of trust control
At the same time, we deliberately did not “overload” the MVP with heavy measures that slow down speed and first impression, because the goal of the pilot was to validate the viability of the core and user journeys.
Warning
Important: we do not publicly disclose specific thresholds, triggers, and internal antifraud rules. This protects the system, not “hides information”.
Risk control: how we kept the system manageable
In the MVP, we applied a managed perimeter approachto simultaneously maintain convenience and avoid a bias towards risk:
- a limited set of assets and networks in the pilot, to reduce the probability of errors and disputed scenarios
- risk limits and checks within the pilot (by the principle: “safe by default”)
- in-app support as a tool to reduce the risk of user errors (address, network, fee expectations)
This is directly related to what we saw in support tickets: most problems are born from human errors and incorrect expectations, which means risk is reduced not only by antifraud, but also by proper UX and communication.
Tip
Where the market usually “treats” risk only with restrictions, in the MVP we treated it simultaneously with the product: through warnings, explanations, error free routes, and support at the moment of action.
How this scales further
The MVP fixed the basic framework, and security expansion is moved into separate product perimeters and modules. This is important because security must not destroy the speed and convenience of the core. It must be configurable and reinforceable as user risks, limits, and scenarios grow.
Pilot completion and user protection
The MVP completion was structured as a managed process: without hanging operations, with a clean final reconciliation and a priority on protecting funds - trust is preserved through actions.
Info
Finishing the pilot is part of the trust mechanism: the market remembers not only the launch, but also how the system closes the cycle.
10.1. Why we stopped registration
New user registration in the MVP was suspended due to external administrative and political reasons, which made it impossible to continue expanding the pilot in the previous format.
Important: this was not related to a “product failure”. The decision was driven by external conditions. Therefore, we structured the MVP completion as a managed process, where the priorities remain unchanged:
- user protection
- transaction correctness
- transparent final reconciliation
Note
In a financial product, predictability is critical: the user must understand what is happening to their funds and statuses, even when the external environment changes.
10.2. How we completed the pilot: controlled wind-down
We completed the pilot not by “abruptly turning off the system”, but in a controlled wind-down mode - when the product continues to operate for existing users, and the team deliberately closes risks, debts, and operational loose ends.
What was done as part of the managed completion:
- We stopped marketing and acquisition, to fix the pilot perimeter and exclude load growth during the completion period.
- We suspended registration, while preserving access and operability for existing users.
- We strengthened monitoring and stability: focus on reliability, bug fixing, and closing technical debt.
- We conducted final reconciliations of operations and analytics exports, to fix the pilot results and ensure accounting correctness.
- We refined support, antifraud, and compliance processes based on real pilot cases.
And the key completion fact: all assets were fully transferred to users - we ensured a correct and safe exit from the pilot without “hanging” funds and uncertainty.
Warning
Reputational damage in fintech is often triggered by a single mistake. That is why during the pilot completion we managed operational risk as strictly as in “live” operations.
10.3. What this ending provides for the next stage
Completing the pilot “without loose ends” fixes:
- a clean base without hanging statuses
- confirmed product conclusions and behavioral data
- strengthened perimeters of reliability and risk control
Tip
This makes it possible to move the product to the next stage - a launch in the EU and in global markets - already with a foundation that has withstood real world usage.