MVP Context
The boundaries of the pilot, the selected perimeter of assets and networks, and the proper completion of the MVP without risk to users.
Info
We launched the MVP as real-world operation: we tested user behavior and the resilience of key contours, not “showcase” metrics.
0.1 Period, Market, Pilot Boundaries
We ran the MVP in Russia from October 2024 to May 2025. It was a real, working product in which we tested not individual features, but user behavior and the resilience of key contours in daily operation.
The MVP perimeter included operations within a single application: fiat and crypto assets. We supported the ruble and a set of crypto assets that cover the main user scenarios without a “zoo” of networks and unnecessary complexity: RUB, USDT on the TRC-20 and BEP-20 networks, as well as the native assets of these networks, TRX and BNB.
The main product contours operated within the MVP:
- internal instant transfers within the accounting system
- external blockchain operations on TRC-20 (TRON) and BEP-20 (BNB Chain)
- internal instant exchange
- P2P deals as a full-fledged market scenario
- the early RWA module as a test of interest in a more complex product
We deliberately kept the MVP perimeter compact, but sufficient to obtain a clean signal on the key question: can the product become a daily financial tool and withstand real transactional load as a system, where contours reinforce each other.
Note
The MVP perimeter principle: fewer networks and assets - more “signal purity” on stability, habit formation, and operational manageability.
0.2 Completion of the Pilot and Outcome for Users
The pilot in Russia was completed due to external administrative and political reasons. At the same time, it was critically important for us to complete it properly, in a controlled manner, and safely for users.
We suspended registration and fixed the pilot perimeter, stopped active acquisition, strengthened monitoring and stability, performed a final analytics export and reconciliations of operations, and refined support processes, anti-fraud, and compliance based on identified cases.
All assets were fully transferred to users. The pilot was completed without stuck funds and without uncertainty for clients.
Warning
We explicitly record this as a standard of platform behavior: “perimeter closure” must be as controlled as launch - without loose ends, without suspended statuses, and without risk to the client.
Executive Summary: MVP Results in Numbers
A concise summary of the MVP in measurable metrics: volume, activity, reliability, and the first confirmations that the product contours work as a unified system.
Info
This block contains no “marketing” numbers - only operational metrics of a real pilot and the conclusions that follow from them.
1.1 Executive Summary Table
| Metric | Value |
|---|---|
| Registered users | 42 653 |
| Total transactions | 570 515 |
| TTV (USD equiv.) | $62.1M |
| Average MAU | 12 344 |
| Average DAU | 2 650 |
| DAU/MAU (stickiness) | 19-22% |
| Peak DAU/MAU | up to 32% |
| Platform uptime | 99.95% |
| ARPU (average, $/month) | ~0.01-0.05 |
| Cumulative ARPU for the pilot | $0.11 |
Note
The table is a “snapshot”. Below is an explanation of what exactly these values confirm at the level of habit, trust, and system manageability.
1.2 Detailed Explanation for Each KPI
Registered users - 42 653
This is the number of people who completed registration and gained access to the product. For us, what matters is not “quantity for the sake of quantity”, but the fact that the product, in a real market, was able to acquire a representative sample of users without optimizing for growth. We launched the MVP as an engineering and product test of system maturity and behavior, not as a race for registrations.
Total transactions - 570 515
This is the main marker that the MVP was a working financial contour: hundreds of thousands of operations mean repeat usage and real load on the product, support, processes, and risk control. This is exactly what we wanted to verify: that the system withstands real-world operation and remains manageable.
TTV - $62.1M (USD equiv.)
TTV shows the total volume of operations that passed through the platform in equivalent terms. For a bank and a payment platform, this is a “live turnover” indicator: it demonstrates not interest in words, but that people actually move value through the product and trust it with the movement of money.
Average MAU - 12 344
MAU is the number of unique active users per month. For us, this is a measurement of repeatable value: do people return after the first test, do they integrate the product into regular financial scenarios. MAU
Average DAU - 2 650
DAU is the number of unique active users per day. Daily activity means that the product enters the user’s daily contour: transfers, exchange, status monitoring, support. DAU
DAU/MAU (stickiness) - 19-22%
Stickiness shows how often the average user returns during the month. For a bank, this is a habit indicator: the product becomes a tool, not a one-off entry point. We set the goal of “repeatable value”, and this metric directly answers it.
Peak DAU/MAU - up to 32%
Peak stickiness is important as a signal that during certain periods the product activated a dense usage scenario. For us, this confirms that the contours inside the application create action coupling, rather than a single “entered and left” scenario.
Platform uptime - 99.95%
For a financial product, reliability is the foundation of trust. We built the MVP as a bank-grade contour: an operation must be predictable and manageable. High uptime confirms that operations were disciplined. Uptime
ARPU (average) - ~0.01-0.05 $/month
ARPU shows the average revenue per user per month. In the MVP, this metric was deliberately not a goal: optimizing for short-term revenue distorts product signals. Nevertheless, it provides an important confirmation: the monetary layer is measurable and activatable. ARPU
Cumulative ARPU for the pilot - $0.11
Cumulative ARPU shows the accumulated result over the period. In the context of the MVP, this is not a “goal to earn”, but a marker of economic manageability: we can honestly calculate it on pilot data and scale monetization on top of proven trust.
Tip
Fixing ARPU in the MVP is “readiness for monetization”, not an attempt to squeeze the maximum out of the early stage.
1.3 What We Proved with Facts
Example
Below is not a retelling of the table, but the product conclusions that follow from specific numbers.
-
Repeatable value and user return
An average MAU of 12 344 shows that the product entered regular use rather than remaining a one-off utility. This confirms that the core scenarios are assembled as a system, not as a set of screens. -
Daily contour
An average DAU of 2 650 means that the application has daily reasons to be opened - transfers, statuses, exchange, operation control, and communication. This is critical for turning a wallet into the primary financial interface. -
Bank “stickiness” as an effect of contour coupling
DAU/MAU of 19-22% and a peak up to 32% confirm that the contours reinforce each other: the user does not “do one operation and leave”, but lives inside a connected set of functions. -
Trust in transaction execution
570 515 transactions is a scale at which any status gaps, UX errors, or “gray zones” become visible and destructive. The volume of operations shows that the execution contour was predictable for the user. -
Reliability sufficient for a financial scenario
An uptime of 99.95% confirms that the infrastructure and operations withstood real conditions. This is not a “nice-to-have metric”, but a foundation for transferring habits and turnover into new markets. -
Transactionality, not “clicks”
TTV of $62.1M demonstrates live turnover. For future contours (including Business and Payments), this means that the foundation of the payment product has already been tested by real load. -
An internal payment network inside the product
34.0% of all transactions are internal, with a status of less than 1 second. This forms a habit and a network effect: transfers inside the ecosystem become the default. -
P2P as a stress test of process maturity
We executed 34 839 deals with a dispute rate of 1.8% and a median time-to-close of 17 minutes. This confirms that a complex user contour works in reality and remains manageable. Peer-to-peer -
Exchange as monetization without destroying UX
An exchange volume of $8.1M with a test fee of 0.10-0.25% shows that monetization can be layered on top of transparent “you pay / you receive” flows without breaking trust. -
RWA as an early demand signal for a complex investment contour
1 328 on the interest list and 133 participants in the closed test with $0.32M in test investments - this confirms that even a complex product can attract demand if it is embedded in a clear ecosystem. -
Support capable of scaling through processes and product
24/7, median first response 7.4 min, FCR 72%, CSAT 4.2/5 - this is proof that support can be part of the product, not a growth bottleneck. -
Pilot completion as a maturity indicator
Pilot period - October 2024 - May 2025. Registration was stopped for external reasons, while the completion was managed, and assets were fully transferred to users. This shows the ability to keep the product as a controlled perimeter throughout its entire lifecycle.
MVP Task Execution: What We Tested and What We Obtained
This section documents which MVP hypotheses were tested in real operation, which metrics confirm them, and which practical conclusions can already be transferred to the next market.
Info
The MVP was launched as a validation of repeatable value, predictability, and manageability in daily operation.
We launched the MVP not to “pump the audience”, but to prove three things in a real environment: that the product delivers repeatable value, behaves predictably, and remains manageable even in the places where financial services usually descend into chaos.
Task Execution Matrix
| MVP Task | What We Did | Confirmed By Which Numbers | What This Proves | Practical Conclusion |
|---|---|---|---|---|
| Value and trust in the product as a “bank”, not a wallet | Built clear and verifiable transaction mechanics: transparent statuses, predictable behavior, confirmations before action | Uptime 99.95%, 570 515 transactions, TTV $62.1M, DAU/MAU 19-22% and a peak up to 32% | People trust their money to a system when it “does not surprise them”: everything is explainable, trackable, and repeats the same way | We have a foundation of “bank-grade” reliability and clarity on which contours can be scaled |
| Daily use through instant internal transfers | Made internal transfers “frictionless”: instant status, simple logic, no internal fee | Internal transfers: 34% of operations; status speed <1 sec | Internal transfers become the basic daily scenario and the “glue” between users | This contour can be strengthened as the main driver of regularity and return |
| Managed P2P as a stress test of process maturity | Built a full P2P deal lifecycle and dispute process so that the market is fast and risk is controlled | P2P: $9.1M volume, 34 839 deals; median time-to-close 17 min; dispute rate 1.8% | P2P works not on “manual heroics”, but as a managed system: speed plus a low share of disputes | P2P can be scaled without proportionally inflating support and manual checks |
| Exchange as monetization control without destroying the experience | Built the exchange “to milliseconds”, with a preview of the deal result before confirmation | Exchange: $8.1M volume; effective spread 0.41%; test fee 0.10-0.25% in March-April | Monetization can be enabled carefully without breaking trust if the user sees in advance “what they pay and what they receive” | We know how to monetize contours without the “they tricked me with fees” effect |
| Early demand signal for the complex RWA product | Launched an RWA interest path via a whitelist and closed testing | Waitlist 1 328 → closed test 133 → test investments $0.32M | Even complex investment products show measurable demand at an early stage with the right packaging | RWA can be developed not on belief, but on early demand and controlled validation |
| 24/7 service by a small team as part of the product | Measured and built support as a managed service: a single in-app chat, ticketing, transaction context, operator action control | Support 24/7; median first response 7.4 min; FCR 72%; CSAT 4.2/5 | Service quality is ensured by the system and processes, not by the number of people | This is transferable to the next launch: we already know how to run 24/7 without an “army of support” |
| “Unified bank” as a system, not separate features | Assembled contours so that they connect and reinforce each other in real user behavior | Segmentation: 16% power users use 3+ functions; other segments cover key scenarios (on/off-ramp, P2P/transfers, exchange) | User behavior shows the product as a bundle of modules, not “one successful button” | The “all in one app” strategy is confirmed in practice: the more contours are connected, the higher the system value |
Note
The matrix above фиксирует not a “set of features”, but contours - the parts of the product that withstand load, deliver repeatable behavior, and scale through processes.
Detailed Breakdown by Tasks
Value and Trust: Money Stays in the System Only Where Everything Is Predictable
In a financial product, trust cannot be “drawn by marketing”. It emerges when the user sees the same quality every day: a clear scenario, a transparent result, and no surprises. That is why in the MVP we deliberately focused not on the variety of features, but on discipline in transaction execution and predictable product behavior. This is the “bank-grade standard” that must hold regardless of load and scenario.
The fact that the system sustained the full pilot cycle with an uptime of 99.95% and a large volume of real transactions demonstrates platform maturity, not a one-off “successful launch”.
Tip
Predictability in fintech is when any dispute comes down to verifiable statuses and logic, not to “it worked / it did not”.
Daily Use: Internal Transfers as the Main “Glue” of the System
The strongest daily contour in a bank is fast transfers that become a habit. In our MVP, internal transfers accounted for 34% of operations, and their status was updated in less than 1 second.
This signal is important for two reasons:
- Behavioral: people do not just “try it”, they regularly repeat an action that becomes basic.
- Systemic: internal transfers create a network effect - the product becomes more useful when friends and business contacts use it, not only “me alone”.
Managed P2P: Market Speed Without Losing Control
P2P is one of the most demanding contours: it is simultaneously about money, trust between people, dispute risks, and deal closure speed. That is why we used P2P as a stress test of manageability.
The MVP metrics capture three results at once: the market turned out to be alive in volume and number of deals, the process was fast in time to close, and the risk contour was manageable in dispute share. A volume of $9.1M, 34 839 deals, a median time-to-close of 17 minutes, and a dispute rate of 1.8% is a combination that is practically impossible to achieve without a properly built lifecycle and dispute process.
The practical meaning: we proved that P2P can be scaled as a system, not as a “manual market” held together by support heroics.
Exchange: Monetization and UX That Do Not Break Trust
We deliberately built the exchange so that it works as a “clear deal”, not as “magic with fees”. At the UX level, this means previewing the result before confirmation, so that the user understands the outcome of the operation in advance and does not face surprises.
In terms of actual usage: the exchange delivered a volume of $8.1M with an effective spread of 0.41%. In March-April we enabled a test fee of 0.10-0.25% to check how monetization affects behavior.
The meaning of the result: monetization is possible without destroying the experience if it is embedded into an honest, transparent scenario.
Warning
Any monetization in financial contours must be visible before the action, otherwise it turns into a factor of distrust and accelerates churn.
RWA: Early Validation of Demand for a Complex Contour
RWA is a product more complex than “transfers and exchange”: it requires greater trust, better explanation, and has a longer decision-making cycle. Therefore, in the MVP what mattered to us was not “mass volume”, but an early, measurable signal of demand and willingness to go through the journey.
The RWA funnel turned out to be measurable: 1 328 on the waitlist, 133 in the closed test, $0.32M in test investments.
This proves the main point: with the right packaging and controlled access, interest in RWA appears already in an early version and does not require “magic” - it can be grown systematically.
24/7 Service by a Small Team: Support as a Continuation of the Product
From the start, we measured support as a product contour: first response speed, first-contact resolution, and satisfaction. And we built the system so that the operator does not “look for the truth across chats”, but sees the context for the account and operations and can help safely.
Actual MVP metrics: support 24/7, median first response 7.4 minutes, FCR 72%, CSAT 4.2/5.
The practical meaning: we proved that a round-the-clock service can be sustained by systemic organization and tools, not by the size of the department.
Product as a System: Contour Coupling Instead of a “Set of Features”
The key result of the MVP is that user behavior shows the product works as a single system of scenarios. This is visible in the segmentation: certain groups come for a specific function, and 16% of power users use 3+ functions and demonstrate high frequency.
This is the foundation of a “single bank”: when modules do not compete, but reinforce each other, increasing the value of the entire platform and reducing the likelihood that the user leaves for a “zoo of separate services”.
Funnel and Activation Quality
This section shows how people move from the first touchpoint to core behavior, and what exactly in this funnel confirms the quality of activation.
Info
The funnel captures not “marketing”, but behavioral truth: where the user gets value, where trust appears, and where they become regular.
3.1 Table “Acquisition and Activation Funnel”
| Stage | Count | Conversion to Next Stage |
|---|---|---|
| Visits | 281 031 | 23.7% |
| Registration started | 66 622 | 64.0% |
| Successful registration | 42 653 | 63.0% |
| Passed KYC | 26 879 | 77.6% |
| First deposit/activation | 20 847 | 77.6% |
| 1+ transaction (ever) | 26 044 | 52.9% → core |
| Core users (10+ transactions) | 13 770 | - |
Note
The key indicator of activation quality here is not a single step, but the linkage: from first trust (1+ transaction) to repeatability (core users).
3.2 Breakdown of Each Stage
Visits → registration started
We recorded 281 031 visits, and 66 622 users started registration. This is a strong practical signal: people moved to action, not just “looked around”.
The key product meaning of this step for a new-type bank is simple and clear: we launch transparent banking logic where everything further is measurable and predictable.
We deliberately made the first step as clear as possible so that motivation would not “dissolve” into extra screens and doubts.
Registration started → successful registration
Out of 66 622 users who started registration, 42 653 completed it successfully. Conversion at this stage confirms that the product is not overloaded and does not “break” motivation in the first minutes.
We separately recorded a principled point: the funnel reached a financial action. KYC was passed by 26 879 users, and 26 044 users made 1+ transaction.
This is the “bank-grade” maturity signal: people are willing to go through verification if the product then really delivers clear value and control.
It is important that KYC here did not feel like a “wall”, but was embedded into the logic of trust and access.
KYC → first deposit/activation
20 847 users reached their first deposit or activation, which is 48.9% of registrations.
This step is important because it separates those who are “interested” from those who have already trusted the product with money and started using it for real.
What helped users reach activation faster:
- we built the product around clear scenarios and transparent statuses, where the user understands in advance what will happen after tapping and what the result will be.
Core users (10+ transactions) → repeatability, not a one-time trial
13 770 users became core - they completed 10+ transactions.
And even more important is the linkage inside the funnel: of those who made at least one transaction, 52.9% reached the core level.
For a financial product, this means that “first trust” turns into a habit: speed and predictability of confirmation without commission become the trust anchor and the start of repeatability.
3.3 Table “User Base Segmentation”
| Archetype | Share | Behavior | Primary Function |
|---|---|---|---|
| On/Off-ramp | 34% | deposits/withdrawals, external transfers | external operations |
| P2P/transfers | 28% | frequent small transfers | internal + P2P |
| Exchange/rate | 22% | conversions, market reactions | exchange |
| Power users | 16% | 3+ functions, high frequency | all functions |
Tip
Segments reflect not “audiences by interest”, but real scenarios that form habits and retention inside a single ecosystem.
3.4 Interpretation of Segments as a “Portrait of Real Usage”
This segmentation is important not on its own, but because it shows the real structure of user behavior and confirms that the product is used systemically, not “pointwise”. This is critical for a bank that solves the fragmentation of financial actions.
That is why we look at segments as proof that the product is assembling into a single system, not into a random set of “useful screens”.
-
On/Off-ramp (34%) - the most massive archetype: users need fast and clear deposits and withdrawals, and this is exactly where the logic of “operations + statuses + control” closes a key practical pain.
Here simplicity and predictability are critical: a person comes to solve the task “deposit or withdraw”, and the product must do this calmly, without surprises. -
P2P/transfers (28%) - a marker of daily behavior: frequent transfers mean that the service “embeds” into the everyday scenario and does not remain a rare tool.
This is a direct marker of repeatability: transfers become a habit, and a habit creates a network effect. -
Exchange/rate (22%) - a separate group that uses the product as a convenient point for conversion and rate control: the exchange works as part of the bank, not as a separate exchange, and does not require going to third-party services.
Here the transparency of the result and speed are important so that the exchange is perceived as a “banking operation”, not as a trading tool. -
Power users (16%) - the most valuable group in terms of product maturity: these users use several functions at once and thereby confirm that the product begins to work as a system, not as a showcase of separate tools.
This segment confirms the key thesis: the more contours are included, the higher the value of the system and the harder it is for the user to “fall apart” into several separate services.
Pilot Dynamics (W1-W35): Stability and Manageability
Weekly dynamics show the transition from launch to regular usage, then to an operational mode and a controlled closure of the pilot perimeter.
Info
The purpose of this block is to see stability and manageability in real-world operation: growth, seasonality, peaks, and a correct wind-down.
4.1 Weekly Pilot Statistics: Registrations and Transactions
| Week | Dates | Registrations | Transactions |
|---|---|---|---|
| W1 | 2024-09-30 - 2024-10-06 | 120 | 760 |
| W2 | 2024-10-07 - 2024-10-13 | 257 | 1 621 |
| W3 | 2024-10-14 - 2024-10-20 | 182 | 1 156 |
| W4 | 2024-10-21 - 2024-10-27 | 419 | 2 769 |
| W5 | 2024-10-28 - 2024-11-03 | 729 | 5 593 |
| W6 | 2024-11-04 - 2024-11-10 | 594 | 4 244 |
| W7 | 2024-11-11 - 2024-11-17 | 1 011 | 8 081 |
| W8 | 2024-11-18 - 2024-11-24 | 896 | 6 663 |
| W9 | 2024-11-25 - 2024-12-01 | 1 035 | 12 789 |
| W10 | 2024-12-02 - 2024-12-08 | 1 392 | 14 710 |
| W11 | 2024-12-09 - 2024-12-15 | 1 096 | 11 501 |
| W12 | 2024-12-16 - 2024-12-22 | 1 574 | 16 948 |
| W13 | 2024-12-23 - 2024-12-29 | 863 | 13 815 |
| W14 | 2024-12-30 - 2025-01-05 | 518 | 7 221 |
| W15 | 2025-01-06 - 2025-01-12 | 1 403 | 18 810 |
| W16 | 2025-01-13 - 2025-01-19 | 1 356 | 17 727 |
| W17 | 2025-01-20 - 2025-01-26 | 1 505 | 23 610 |
| W18 | 2025-01-27 - 2025-02-02 | 2 059 | 25 768 |
| W19 | 2025-02-03 - 2025-02-09 | 1 353 | 21 065 |
| W20 | 2025-02-10 - 2025-02-16 | 1 951 | 29 300 |
| W21 | 2025-02-17 - 2025-02-23 | 1 695 | 26 232 |
| W22 | 2025-02-24 - 2025-03-02 | 2 240 | 33 263 |
| W23 | 2025-03-03 - 2025-03-09 | 1 820 | 29 160 |
| W24 | 2025-03-10 - 2025-03-16 | 2 170 | 39 013 |
| W25 | 2025-03-17 - 2025-03-23 | 2 103 | 33 092 |
| W26 | 2025-03-24 - 2025-03-30 | 1 996 | 23 246 |
| W27 | 2025-03-31 - 2025-04-06 | 2 313 | 37 571 |
| W28 | 2025-04-07 - 2025-04-13 | 1 629 | 24 197 |
| W29 | 2025-04-14 - 2025-04-20 | 1 926 | 33 669 |
| W30 | 2025-04-21 - 2025-04-27 | 2 177 | 12 709 |
| W31 | 2025-04-28 - 2025-05-04 | 2 250 | 34 160 |
| W32 | 2025-05-05 - 2025-05-11 | 21 | 52 |
| W33 | 2025-05-12 - 2025-05-18 | 0 | 0 |
| W34 | 2025-05-19 - 2025-05-25 | 0 | 0 |
| W35 | 2025-05-26 - 2025-06-01 | 0 | 0 |
4.2 How to Read the Dynamics by Pilot Phases
Phase A. Launch and “Building Baseline Operability” (W1-W6)
We started with small volumes and ramped up the load gradually. This is the correct strategy for a fintech product: in the first weeks, it is more important to establish stability of the contours than to accelerate the numbers. Growth from hundreds of registrations and thousands of transactions to already noticeable volumes shows that the system entered real usage without artificial spikes.
What this phase proves
- The platform adequately passes through the first peaks of errors, fixes, and tuning.
- The transactional contour begins to live not on demo scenarios, but on real user actions.
Tip
Phase A is a foundation test: first stability, then scaling.
Phase B. Transition to Regular Usage and the First Signs of a Network Effect (W7-W14)
Starting from W7, we see a transition to a stable flow: registrations reach a level of about 900-1 500 per week, and transactions grow to 12-17 thousand per week. In parallel, the life of the product in calendar periods is noticeable: pre-New Year weeks, then a dip during the holiday week W14. For banking and payment scenarios, such seasonality is natural and expected.
Main product signal
- Transaction growth goes together with registration growth, but does not copy it one-to-one. This is an important sign that users are not just installing the application, but are beginning to perform repeatable operations.
Phase C. Operational Mode and Load Scaling (W15-W29)
During W15-W29, the platform already operates as an industrial-grade product: transactions hold at the level of 17–39 thousand per week, and registrations remain stably high. Within this period there are peaks and dip weeks, but the overall picture is not a random spike, it is a clear operational mode in which the system withstands growth and continues to serve activity.
What this phase proves
- We are capable of operating the product on real traffic for a long period without operational burnout.
- The pilot provides data not over a short distance, but over a long series of weeks, which increases the reliability of the conclusions.
Phase D. Controlled Perimeter Freeze and Pilot Wind-Down (W30-W35)
The final weeks show a key thing: the pilot was manageable. We see an atypical week W30 with a drop in transactions, then a return to high volumes in W31, and then a sharp reduction in activity to almost zero and a halt in registrations.
Here it is important to emphasize the meaning: we did not lose the product, we correctly froze the perimeter and completed the pilot due to external administrative and political reasons, stopping registrations.
What the final phase proves
- We know how not only to launch and scale, but also to properly close the pilot loop: freeze new user inflow, bring operations to a correct state, and complete the cycle in a controlled manner.
- Zero activity in the last weeks is not a demand failure, but a reflection of the decision to stop registrations and complete the pilot for external reasons.
Transactional Activity: Proof of Real Usage
We look at transactions as a behavioral map: which scenarios become habits, where monetization appears, and how the network effect forms.
Note
What matters here is not the “mass of operations,” but the structure and repeatability of scenarios. This is what separates “interest” from a sustainable product.
In the MVP, we look at transactions not as a “number of operations,” but as a map of real behavior: why people come, what they do first, which scenarios become habitual, and where natural monetization already appears. Over the pilot period, users completed 570,515 transactions. This is a long enough distance to separate one-time interest from a sustainable product.
5.1 Transaction Structure by Type
| Type | Count | Share |
|---|---|---|
| Internal (no fee) | 193,975 | 34.0% |
| External (In/Out) | 290,963 | 51.0% |
| Exchange + P2P (fee-based) | 85,577 | 15.0% |
What we mean by a “transaction type” in simple terms
- External (In/Out): deposits and withdrawals. This is the first layer of trust. The user checks that money “goes in” and “goes out” predictably.
- Internal: transfers between users inside the system. This is no longer a test, but a daily scenario: “send quickly and without friction.”
- Exchange + P2P: operations on which fees and platform economics are built. Currency exchange and P2P deals.
What the structure shows
- 51% external operations: a normal and expected early pattern. At the start of any financial platform, people first test reliability: deposit, withdraw, make sure everything is transparent and works. This is the trust-building phase.
- 34% internal transfers: a key signal that the product is perceived not as a one-off on/off ramp, but as a payment network that people return to and use regularly to transfer value to each other.
- 15% Exchange + P2P: an important balance. Even in the MVP, users were already actively entering scenarios that later become the basis of monetization.
Which loop forms the behavioral core
The core is the chain:
external in/out (trust) → internal transfers (habit) → exchange/P2P (scenario depth and economics).
This sequence is exactly what makes the product sustainable. People did not just “try it and forget it.” They started using the system as an everyday financial tool.
5.2 Distribution of Transactions by Amount (USD-equivalent)
| Range | Count | Share |
|---|---|---|
| < $100 | 348,014 | 61.0% |
| 1,000 | 205,385 | 36.0% |
| > $1,000 | 17,116 | 3.0% |
What scenarios this distribution reflects
- 61% of operations under $100: this is “life inside the product.” Small transfers, regular actions, repeatable scenarios. For fintech, this is stronger than isolated large tickets. This is how habit and daily value are formed.
- 36% in the 1,000 range: confirmation that the platform is used not only for micro-scenarios, but also for meaningful operations, where the user is already sensitive to reliability and predictability of execution.
- 3% above $1,000: a small share of large transactions is expected for an MVP. This is the level where trust grows gradually. What matters is the very presence of this segment. It means the platform was tested even in more “adult” scenarios.
What this says about trust and the nature of operations
For us, this confirms that the MVP delivered a clean behavioral signal. The product is used not only “to look around,” but to run real transactions of different scales, from everyday to more substantial.
5.3 Assets by Number of Transactions
| Asset | Number of Transactions | Share |
|---|---|---|
| USDT TRC-20 | 262,437 | 46.0% |
| USDT BEP-20 | 79,872 | 14.0% |
| RUB | 148,334 | 26.0% |
| TRX | 51,346 | 9.0% |
| BNB | 28,526 | 5.0% |
Why the chosen asset set in the MVP produced a “clean signal”
We deliberately kept the perimeter simple and practical: fiat for everyday scenarios and core crypto assets for transactions and on/off ramps. As a result, we see a very clear market response:
- USDT (combined across networks) dominates. This is exactly what you expect from pragmatic user behavior where a stable equivalent is needed.
- RUB holds a substantial share. This means users perceived the product as a bridge between familiar money and the crypto contour, not as a “pure crypto app.”
- TRX and BNB remain secondary but visible. This reflects real needs for network fees and operational scenarios of the networks selected for the MVP.
5.4 Transaction Structure and the Network Effect
Tip
An early sign of a “network” is when internal transfers start living their own life and grow not from marketing, but from everyday connections between people.
At an early stage, a high share of external transactions is not a drawback, but a natural phase of any financial platform. The user first “tests reality” through deposits and withdrawals. We passed this phase on real volumes and, at the same time, obtained something that rarely appears at the MVP stage:
internal transfers already accounted for 34% of all transactions.
This means three things:
- Users begin to perceive the product as a payment network, not as a one-off tool.
- An organic network effect starts: the more users inside, the more often a transfer closes via an internal scenario.
- Internal transfers that are fee-free and feel instantaneous create “stickiness.” This is the scenario that retains users and creates a switching barrier, because migrating your “internal contact network” to another product is always harder.
This is why we consider the share of internal transactions one of the strongest MVP signals. In the next launch, as the user base grows and incentives and contours expand, we expect this dynamic to strengthen, up to 50–60% internal transactions within 12–18 months.
Efficiency of Key Modules
We fix which contours in the MVP became habitual scenarios, and how fast and predictable they are under real load.
Info
In the MVP we tested not a “set of features”, but the quality of contours: speed, predictability, repeatability, and manageability under load.
This section contains modules that have provided the most important confirmed signals.. We deliberately focused on ensuring that key scenarios work fast, stably, and in the same way every day, because this is exactly what builds trust and turns the product into a daily tool.
Internal Transfers
Confirmed metrics
- Share of internal operations: 34.0%
- Confirmation and display of transaction status: less than 1 second
In the MVP, internal transfers became not an “additional button” but the core of daily behavior: one third of all operations were performed by users inside the system. This means that the product is perceived as a payment network, not as an “exchange point”.
A status speed of less than 1 second creates a banking sense of finality: the operation looks instantly confirmed and clear. Such an experience directly strengthens the repeatability of the scenario and trust in the system.
Tip
A high share of internal transfers is an early marker of a network effect: users start transferring “inside” because it is faster, simpler, and more predictable.
Exchange
Confirmed metrics
- Exchange volume in USD equivalent: $8.1M
- Effective fee and spread: 0.41%
- Test platform fee: 0.10-0.25%
- Active monetization period: the last ~2 months of the pilot
The exchange delivered real, measurable turnover, meaning users were not just “trying it out” but were regularly converting inside the application. At the same time, the model was built so that the result of the deal was clear in advance: the You pay / You receive preview before confirmation reduces the effect of “hidden conditions” and increases trust in the operation.
The key conclusion here is that monetization can be enabled without destroying UX, as long as the main trust trigger is preserved: a predictable outcome before confirmation. The figures of 0.41% and a test fee of 0.10-0.25% confirm the manageability of this layer on a live product.
Note
What matters here is not “the lowest possible fee”, but the absence of surprises: the user sees the outcome in advance and confirms the deal consciously.
P2P
Confirmed metrics
- P2P volume in USD equivalent: $9.1M
- Number of P2P deals: 34 839
- Maker / Taker: 36% / 64%
- Median deal close time: 17 minutes
- Dispute rate: 1.8%
P2P emerged as an independent active contour, not as an “add-on to the exchange”. It created a separate layer of transactional activity that can be measured, improved, and scaled as a system.
The combination of speed and manageability is visible in two figures: a 17-minute median close time and a 1.8% dispute rate. This is a direct signal that P2P can be run predictably if the deal process is built from the start as a managed lifecycle: fixing terms, escrow, payment confirmation, completion, and result.
It is additionally important that in combination with internal transfers and the exchange, P2P closes the “flexible terms” scenarios, while the other two contours close speed and instant conversion. As a result, a closed loop is formed inside the application, where the user does not need to go to other services.
Warning
P2P always carries increased risks, which is why deal rules, a managed lifecycle, and a predictable dispute process are especially important here, not “manual agreements”.
RWA
Confirmed metrics
- Interest and waitlist: 1 328 users
- Closed test participants: 133
- Test investments in USD equivalent: $0.32M
Even in the MVP, where RWA was an early module, we obtained measurable demand and a transition from interest to action: from the waitlist to a closed test and test investments.
In the MVP, RWA was a test of the core hypothesis: do users perceive a real asset as a clear class inside a banking application alongside fiat and crypto, without “moving it out” into a separate service. The result showed that such a contour is capable of gathering demand already at an early stage with the right packaging and controlled access.
Example
The MVP logic for RWA was simple: first interest, then limited access, then action and measurable volumes.
Retention and “stickiness”
We evaluate not one-time interest, but the repeatability of scenarios and how much the product becomes a habit.
Info
“Stickiness” is when a user returns not because they “have to”, but because inside there is a fast, clear, and repeatable scenario.
We view retention in the MVP through behavior: how often people return, which operations they repeat, and how quickly the product turns into a habitual contour for money. For fintech, this is a key quality indicator: if a scenario becomes regular, marketing shifts from “constant feeding” to scaling.
7.1 Stickiness is formed by 3 core scenarios
In the MVP, it is precisely three contours that start turning the product into a habit, because they either save time, remove errors, or provide predictability of outcome:
- External in/out as a check of trust and the reality of the service
- Internal transfers as a fast everyday scenario between people
- Exchange and P2P as depth of use and natural monetization
These scenarios in the MVP do not compete, but are sequentially assembled into a “cycle”: the user first checks in/out, then starts transferring internally, and after that already uses exchange or P2P as a regular tool.
Tip
When internal transfers become part of everyday actions, the product stops being a “wallet” and turns into a payment environment.
7.2 Signals of a real habit from MVP transactions
We see stickiness through the structure and scale of operations, because they show repeatability.
- Total transactions during the pilot: 570 515
- Internal operations (no commission): 193 975 or 34.0%
- Exchange + P2P operations (commission-based): 85 577 or 15.0%
This structure is important because an internal share of 34.0% means repeatability of social scenarios, and an Exchange + P2P share of 15.0% means that part of the audience goes deeper into the product, where there is already “economics” and regular actions.
7.3 Why small transactions increase retention
The distribution by amounts additionally confirms that the product lives precisely on everyday scenarios:
- 348 014 operations (61.0%) - less than $100
- 205 385 operations (36.0%) - 1 000
- 17 116 operations (3.0%) - > $1 000
A large share of small operations usually means not low trust, but repeatability: people return for small actions more often, and this is exactly what creates “stickiness” stronger than rare large checks.
Note
For the early MVP stage, regular small transactions are more important than rare large ones: they show that the product has become a habit, not an experiment.
7.4 Why the internal network increases retention faster than advertising
Internal transfers form an important effect: people start tying the product to their circle of contacts. This creates a natural barrier to leaving, because switching applications means “moving” not only money, but also payment connections.
To simplify, retention increases as the user base grows according to simple logic:
- the more users inside
- the more often a transfer “closes” internally
- the faster the feeling of “everyone is here” appears
- the lower the motivation to leave and the higher the repeatability
7.5 What has already shown the stickiness effect in MVP
Final conclusion based on MVP behavior:
- there is a mass of repeatable actions (570 515 transactions)
- there is a social contour (34.0% internal transfers)
- there is deepening into scenarios with economics (15.0% Exchange + P2P)
- there are signs of sustainable weekly usage, meaning the product works not as a spike, but as a series
Question
What will further strengthen stickiness if the core is not changed? The answer is expansion of the scenario perimeter around the same three contours: transfers, exchange, P2P, but with more entry points, wider limits, and tighter integration with everyday payments after passing KYC.
Monetization (ARPU)
We fix where the economy has already appeared in the MVP, why it is “healthy”, and how it scales without degrading the product.
Info
Monetization in fintech wins not through aggression, but through predictability, transparency, and repeatability of scenarios. In an MVP, the goal is not to “extract the maximum”, but to prove that the economy emerges naturally.
In the MVP, we deliberately did not build monetization as the number one goal. The goal was different: to prove that the product can live on real traffic, retain users, and generate deals where the fee is perceived as a normal payment for speed, convenience, and risk reduction.
That is why this part is strong precisely because monetization numbers appeared as a side effect of a “working contour”, and not as an artificial add-on.
8.1 Where revenue is already forming in the MVP
Within the MVP, there are two natural sources of revenue that do not require changing the basic product logic:
- Exchange - commission and spread as payment for instant conversion and a predictable deal outcome.
- P2P - commission-based scenarios where users pay for a controlled deal process, fraud reduction, and a normal dispute flow.
This is an important shift relative to the market, where users often have to choose between “cheap” and “clear”. In the MVP, monetization is tied to the place where value is felt immediately: conversion and the deal itself.
8.2 The exchange as a “clear economy”, not hidden conditions
Confirmed MVP metrics for the exchange
- Exchange transaction volume in USD equivalent: $8.1M
- Effective commission and spread: 0.41%
- Platform test commission: 0.10-0.25%
- Period of active monetization: the last ~2 months of the pilot
The strength here is not that “the commission is minimal”, but that the user trust trigger disappears - the unexpected outcome. In the exchange, the user sees the result in advance, and the commission is perceived as part of a transparent deal, not as a surprise.
Tip
In fintech, the most expensive asset is trust. A transparent commission often retains better than a “zero” one, but with unexpected conditions.
8.3 P2P as a layer where users pay for control and safety
Confirmed MVP metrics for P2P
- P2P volume in USD equivalent: $9.1M
- Number of P2P deals: 34 839
- Maker / Taker: 36% / 64%
- Median close time: 17 minutes
- Dispute rate: 1.8%
In P2P, users are willing to pay not “for a button”, but for the fact that the deal goes through as a controlled process: clear rules, predictable closure, disputes are resolved according to regulations, not “however it happens”. That is why P2P and the exchange together provide a sustainable economic foundation: one covers instant conversion, the other covers flexible deal conditions.
8.4 Why this is fair monetization
Fair monetization in the MVP is based on two principles:
- The fee is charged where the user receives instant, measurable value.
- The commission is not masked and does not appear post factum as an “add-on”, but is built into a clear deal outcome.
This logic is especially important in the context of the market problems we described: hidden commissions, unpredictability of outcomes, manual processes, and “gray zones” in P2P. We build monetization so that it looks like a payment for clarity, safety, and speed.
8.5 ARPU in the MVP: why the early stage is still strong
ARPU at the MVP stage will inevitably be modest, because:
- some users in the MVP remain on basic in/out scenarios
- a significant part of monetization is activated closer to the end, after trust has been accumulated
- many expansion capabilities in the full product are unlocked after KYC and through subscriptions
But the strength of the MVP lies elsewhere: even under these conditions, we have already obtained measurable volumes of 8.1M</span> in the exchange and <span style="color:#6FEABE; font-weight:bold;">9.1M in P2P, meaning we have proven the existence of scenarios where the economy turns on naturally.
Note
It is important to understand: this is not a “monetization peak”, but proof that the funnel is already leading to paying behavior without changing the basic architecture.
8.6 What scales ARPU further without breaking the product
Further ARPU growth is built not on increasing the commission, but on expanding the number of users who reach commission-based scenarios and repeat them regularly:
- growth in the share of users who use the exchange as a regular operation
- growth in P2P activity due to denser liquidity and trust
- connecting subscriptions, which manage rights and limits across the entire product (core and modules) and shift monetization into a predictable recurring format
This is how a healthy model emerges: ARPU grows together with the “depth” of usage, not due to pressure on the user.
Question
What is the most important thing in this scheme? Preserve trust. Revenue growth is built on the fact that the commission is perceived as payment for convenience and safety, not as a “tax for usage”.
Service and support: part of the product, not a “separate department”
Support in the MVP is a built-in service contour: answers, actions, documents, and secure confirmations in one place.
Note
We treat support as a product function: it does not “explain”, it helps to do and fix the result.
In classic banking, support most often lives separately: the user comes with a question, gets instructions, then does everything on their own, makes mistakes, and comes back again. In DARCA, support is embedded as an operational layer inside the application: it not only answers, but also guides the user along the path to a result, while staying within security boundaries.
9.1 A single in-app chat as a “gateway” to actions and knowledge
Support in the MVP is a single chat inside the application that unites:
- answers and explanations of functions
- hints and correct steps specifically for the user’s context
- documents and statements that can be requested and received in the chat
- deep-links and buttons that take the user directly to the required screen, so they do not have to search manually
The key principle: if a user asks “how to send”, they are not given a wall of text. They are shown a short logic, and then given a transition button to the required screen, already in the correct context.
Tip
Support turns into a “navigator”: every answer ends with an action or a document, not “read the instructions”.
9.2 Two layers: the AI layer and the operator as “quality control”
In the MVP, support is built in two layers to simultaneously provide speed and preserve quality:
- AI layer - responds instantly, explains functions, helps walk through scenarios, clarifies context, and suggests the correct next step.
- operator - connects for complex cases, disputed situations, checks, and cases where human control is needed.
At the same time, the operator does not work “blindly”: they receive from the AI a short summary of the dialogue, a hint on the solution, and relevant links to internal scenarios. This increases processing speed and reduces load without losing quality.
Info
AI here is not a replacement for people, but an accelerator: fewer queues, less manual routine, higher service predictability.
9.3 Support can “do”, but does not violate security
We divide actions into two classes:
- non-critical actions - what an operator can perform at the user’s request (for example, send a document, prepare a statement, help with settings, show a status).
- critical actions - everything that affects money, confirmations, signatures, and access rights.
Critical actions are never done “by the operator’s hands”. Even if support guides the user to the required solution, the final action is performed only by the user through a button in the application and is confirmed using their authorization methods.
This eliminates the classic banking problem: “support asked for a code and everything was stolen”. With us, support does not ask for secrets and does not handle money manually.
Warning
Any call “from DARCA” is considered fraud. We do not call and do not accept calls, and all critical actions require user confirmation in the application.
9.4 Support in popular messengers, but with secure architecture
In addition to the in-app chat, support can be available in popular messengers (Telegram/WhatsApp/WeChat/iMessage, etc.), but with a key limitation:
- messengers are used as a communication channel
- any critical actions are performed only in the application through user confirmation
That is, even if the user communicates with support outside the application, they never confirm money or signatures in the messenger. The messenger ends the dialogue with a link or a button that takes the user into the application to the required screen.
9.5 Why this strengthens the product and reduces the cost of service
This approach solves several market problems at once:
- low quality of support - the user gets a fast path to a result, not “waiting and instructions”
- fragmentation - support, documents, actions, and learning are inside a single contour
- hidden waste of time - fewer errors, fewer repeated requests, less manual navigation
And at the same time, it reduces our operational costs: the AI handles typical requests, the operator becomes a “control point” and works faster thanks to hints and summaries.
Example
The user writes: “how to top up USDT?” Support answers briefly step by step, then provides a button “Open the USDT top-up screen” and shows exactly where to look for the network and address.
9.6 Support as a source of product improvement
Support in DARCA is also an improvement tool:
- AI generates summaries of dialogues
- a separate quality control layer identifies frequent requests, recurring errors, and UX weak spots
- the knowledge base is updated faster because questions are structured automatically
That means support not only serves users, but also turns into a continuous data flow about what users actually need and where the product should become simpler.
Risks, challenges, and lessons of the pilot
In the MVP, real risk points surfaced, and we addressed them not with “promises”, but with processes, engineering mechanisms, and operational manageability.
Warning
Here we record only what actually manifested in the MVP, and what we have already embedded as permanent mechanics, so that scaling proceeds through risk reduction, not through their accumulation.
10.1 Table “Risks / Challenges / What we did / Lesson”
| Risk / challenge | What manifested in the MVP | What we did in the pilot | Lesson embedded into the platform |
|---|---|---|---|
| Risk of a fraud attack on P2P, attempts “through disputes” and pressure on sellers | Disputes always exist, the question is scale and manageability. In the MVP, the dispute share was 1.8% across 34 839 deals and a P2P volume of $9.1M | We configured trade rules, arbitration, control points, signal collection for suspicious patterns, and a conflict resolution procedure | P2P scales not by liquidity, but by process maturity. Trust is sustained by predictable deal closure |
| Problems of complex exchange cases and external networks, disputed transactions | In on-chain contours, “edge” cases are possible: network delays, incorrect expectations about fees, address or network errors | We refined statuses, outcome previews, warnings, educational hints, and the linkage of support with transaction context | Statuses and transparency reduce not only errors, but also the load on support. UX in transactions is part of antifraud |
| Drop in support quality as requests grew | There were spikes in requests, typical for a live product with transactions | We relieved the load not by hiring a “massive department”, but through manageability: triage, knowledge base, templates, and process discipline | Support is a continuation of the product. If processes and tools are correct, service maintains quality under growth without linear cost growth |
| Risk of UX errors: networks, addresses, statuses, “I did not understand what happened” | User errors in fintech are costly: in money, time, and reputation | We strengthened the “clarity contour”: “You pay / You receive” preview, on-chain statuses, clear confirmation logic, a unified linkage with support | Trust is not a promise. Trust is a product mechanic where the user sees that everything is transparent and manageable |
| Risk of “silent” systemic integration errors (unnoticed failures, retries) | In integrations, local failures and delays are possible. The higher the volumes, the higher the cost of a single unnoticed problem | We added monitoring, retries, alerts, and operational discipline | Resilience is more important than “development speed”. Observability and discipline make the system scalable |
| Risk of a sharp external perimeter restriction | Registration was closed for external administrative-political reasons, and pilot activity quickly dropped to zero | We correctly fixed the perimeter and completed the pilot in a managed way, without “suspended” funds and statuses | Product maturity is the ability not only to launch, but also to correctly complete the cycle without destroying trust |
10.2 Extended commentary: what exactly we found in the real pilot
KYC and growth: why KYC is manageability, not a “barrier”
We see that KYC restrictions and onboarding stages are often perceived by the market as a “growth brake”. In the pilot, we got the opposite: KYC affects not only legality, but also the quality of the audience and the risk profile of transactions.
We record this in our conclusions as a principle: growth should be not with “any users”, but with users whom we can support in a high-quality, safe, and predictable way. This is especially important for P2P and external networks.
Info
KYC in our logic is a quality filter of the flow that reduces the cost of antifraud, support, and disputes as scaling progresses.
Integrations and operations: why resilience is more important than “development speed”
Any bank lives in integrations: networks, providers, external contours. In the MVP, we saw local failures and delays and did exactly what distinguishes a product team from a “we made a demo” team: we added monitoring, retries, alerts, and operational discipline.
This reduces the risk of “silent errors” and makes the system scalable: the higher the volumes, the higher the cost of a single unnoticed problem. We addressed this at the level of engineering culture.
Support: how not to bloat the headcount while maintaining quality
In the pilot, there were spikes in requests, which is normal when a product is live and users actively perform transactions. We relieved the load not by hiring a “massive department”, but through manageability: triage, knowledge base, templates, and process discipline.
The result: support in the MVP operated 24/7 with measurable quality, which we already showed in support KPIs.
The main lesson: support is a continuation of the product. If processes and tools are correct, service maintains quality under growth without linear cost growth.
P2P: the main stress test of trust and product maturity
P2P is the zone of maximum risk: human factor, fraud attempts, conflicts. In the MVP, we achieved a real P2P volume of $9.1M and 34 839 deals, and the dispute share was 1.8%.
For us, the key metric is not an “ideal zero dispute rate”, but the presence of a managed process: rules, arbitration, control points, and predictable deal closure. This is what retains trust and allows scaling P2P as a module, not as a “dangerous feature”.
Correct pilot completion: maturity is the ability not only to launch
A strong fintech team is defined not by the fact that it “knows how to launch”, but by the fact that it knows how to operate a product in reality and complete a pilot correctly, without destroying user trust.
We went through the full pilot cycle:
- the product worked under real transactional load,
- we fixed risks and closed them with processes and improvements,
- in the end, we correctly fixed the perimeter and completed the pilot for external administrative-political reasons.
From the weekly statistics, a managed completion is visible: W32 - already almost zero activity, then W33-W35 - zeros, which reflects the stop of registration and the closure of the pilot perimeter.
This is an important signal of maturity: we know how not only to “accelerate growth”, but also to manage the product as infrastructure - with discipline and responsibility.
Portability of results and reference points for the next launch
We fix what exactly from the MVP transfers into the next launch without reinvention, and what reference points define scaling across product, risks, and economics.
Info
The most valuable part of the MVP is not the numbers themselves, but the portable mechanics: what has already proven viability on real traffic and will scale without changing the core.
In this pilot, we obtained something rare for an early stage: not only growth, but also behavior validation, operational resilience, and clear economics in scenarios where the user is willing to pay for value. This means the next launch is built not “from scratch”, but on the basis of already proven contours.
11.1 What transfers directly: proven MVP contours
1) Transaction and status core
- Proven ability to withstand real load: a total of 570 515 transactions.
- Instant internal finality: status updates under 1 second for internal operations.
- Clear statuses in on-chain scenarios and predictable product behavior in real operations.
2) Monetization as a “natural part of value”
- Exchange: volume $8.1M, effective fee and spread 0.41%, test platform fee 0.10-0.25%.
- P2P: volume $9.1M, 34 839 deals, median closure 17 minutes, dispute rate 1.8%. This transfers as a model: revenue appears where value is transparent and measurable.
3) P2P manageability
- P2P showed that disputed cases do not “break” the product if there are processes, control points, and arbitration.
- The metrics provide a basis for improving liquidity, ratings, and risk rules without rebuilding the architecture.
4) Service as a product layer
- Support proved its effectiveness as an embedded contour: fast responses, contextual transitions (deep-links), documents, and regulation of critical actions via user confirmation.
- This layer scales together with the product, reducing the cost of errors and repeat requests.
Note
What transfers is not the “sum of the numbers”, but the architecture: core + trust contours + economic contours + support contours.
11.2 Portability table: what is proven, what we strengthen, what we add
| Block | What is proven in the MVP | What we strengthen in the next launch | What we add as the next layer |
|---|---|---|---|
| Core | High transactional activity (570 515), fast statuses, stable operations | Observability, monitoring, alerts, peak stress tests | Tighter linkage with KYC logic and subscriptions |
| Exchange | Turnover $8.1M, working fee economics | Improving UX of outcome previews, expanding available directions | Deeper integration with limits and subscriptions |
| P2P | Turnover $9.1M, 34 839 deals, dispute manageability | Ratings, limits, risk filters, education, alerts | Copy-trading, advanced behavior analytics, “training account” |
| Support | Ability to accompany a transactional product and maintain quality | AI layer, summaries, quality control, document automation | Scaling channels (in-app + messengers) without moving critical actions outside |
| RWA (early layer) | Demand confirmed: waitlist 1 328, closed test 133, volume $0.32M | Strict admission procedures, documentation, risk control | Expanding RWA classes and linkage with P2P |
11.3 Reference points for the next launch: what exactly we must confirm
The next launch must confirm three key things that turn a “successful MVP” into a scalable platform.
1) Repeatability and growth of “depth”
- growth in the share of users who reach exchange and P2P
- growth in the share of internal operations as a sign of a “social contour”
- preservation of clarity of statuses and deal outcomes as load grows
2) Risk manageability at scale
- maintaining the P2P dispute rate within a controlled range as liquidity grows
- strengthening the “contours of trust”: KYC, ratings, limits, behavioral signals
- increasing support efficiency without linear team growth
3) Economics as a consequence of value
- ARPU grows not from “raising fees”, but from the growth in the share of users in commission-based scenarios
- subscriptions become a mechanism for managing rights and limits across the product (core and modules), creating predictable revenue without degrading UX
Tip
The next launch is not about “adding more features”, but about densifying working scenarios and making them scalable in terms of risks and economics.
11.4 Why the pilot results scale
The pilot provided a foundation that transfers into any next perimeter because it is not tied to “luck” or a single traffic channel:
- the core proved stability on real traffic
- P2P proved manageability and the presence of metrics that can be influenced
- the exchange proved the presence of a ready-made economy
- support proved that service can be built as a product, not as a department
- early RWA showed demand under controlled admission
11.5 What is important not to repeat: the pilot limitation as a lesson
Registration in the pilot was closed due to external administrative and political reasons. The weekly statistics show a managed завершение: W32 - almost zero activity, then W33-W35 - zeros.
This lesson transfers as a principle: the next launch must be built with a pre-thought-out regional framework and control scenarios for switching the perimeter, so that the product does not depend on a single development corridor.
Question
What is the strongest reference point for the next launch? The fact that the core, P2P, exchange, support, and early RWA have already shown viability. The next launch is the scaling of proven contours, not a bet on the unknown.
Why we are not “from zero” and what is already built
The MVP completed the key early-stage work: it proved product viability, risk manageability, and the presence of an economy in real usage.
Info
This is not a story of “we came up with a concept”. This is a story of “we have already tested the core on real transactions, built processes, and know what we are scaling next”.
The MVP was built not as a demonstration, but as a test of what usually breaks fintech in the real world: status speed, trust in deals, disputed cases, support load, transparency of outcomes, and the first signs of an economy. As a result, we obtained a foundation that transfers into the next launch without reinvention.
12.1 What has already been proven by facts
In the pilot, we obtained measurable results that are characteristic not of a “prototype”, but of a working contour:
- Total number of transactions: 570 515
- Internal statuses are confirmed and displayed: less than 1 second
- Exchange volume: $8.1M
- Effective fee and spread (exchange): 0.41%
- Test platform fee: 0.10-0.25%
- P2P volume: $9.1M
- P2P deals: 34 839
- Median time to close a P2P deal: 17 minutes
- Dispute rate: 1.8%
- RWA (early interest and test): waitlist 1 328, closed test 133, test investments $0.32M
Note
These numbers are important not as “pretty”. They show that there are already repeatable scenarios, manageable processes, and an economy in places where the user is ready to pay for value.
12.2 What is already built as a system, not as “features”
1) Core as infrastructure
The core proved its ability to work on real traffic: speed, statuses, behavior under load. This is a foundation that transfers directly.
2) Trust contour in deals
P2P and the exchange showed that trust can be built not with “words”, but with mechanics: outcome previews, regulations, statuses, support as a navigator, and arbitration.
3) Risk manageability contour
In the pilot, inevitable risks and challenges manifested: disputes, complex on-chain cases, peaks in requests, operational nuances. We closed them with processes, monitoring, and regulations, not with manual “heroics”.
4) Service contour as a product
Support in the MVP is not a “separate department”, but a built-in layer: answers, context, deep-links, documents, and secure confirmations. This reduces errors, increases retention, and lowers operating costs at scale.
Tip
The difference between “from zero” and “already built” in fintech is simple: do you have contours that withstand reality. In the MVP, these contours have already passed the test.
12.3 Why this is not just a pilot, but preparation for scaling
Most early-stage projects have only one of the following: an idea, an interface, or a first audience. Here, a combination has formed that usually appears later:
- product scenarios are confirmed by real operations
- risks manifested early and were closed systematically
- the economy began to work where value is clear and measurable
- early interest in RWA is confirmed without mass “acceleration” and without reputational risk
12.4 What develops next without changing the core
The next launch is not a “restart from zero”, but an expansion of the proven foundation:
- expansion of core scenarios after KYC and connection of fiat contours and cards
- growth of P2P liquidity and maturity: ratings, limits, alerts, training, copy-trading
- strengthening subscriptions as a mechanism for managing rights and limits across the product (core and modules)
- development of RWA as a layer that can become a major growth driver under strict risk management
Question
What is the main point of this conclusion? The MVP confirmed that DARCA is being built as a platform with portable infrastructure, not as a set of hypotheses. The next launch is based on already working contours, not on hope.