Implementation

DARCA MVP Implementation

Info

This section documents how the MVP was built as a controlled system: predictable statuses, observability, perimeter discipline, and a safe wind-down of the pilot.

How we organized the MVP implementation

The MVP was built as a “bank-grade from day one” product: predictable operations, a controlled perimeter, and a scalable foundation.

From the very beginning, we built the MVP not as a “demo app”, but as a product to which a user can entrust money. Therefore, already at the pilot stage, we fixed a rule: every operation must be predictable, explainable, and controllable - both for the user and for the team.

Bank-grade from day one

This was expressed in three practical implementation principles:

  • Statuses and finality. The user always understands what is happening now and when an operation is considered completed. We avoided “gray zones” where the user is left with a feeling of uncertainty.
  • Transparent result before confirmation. Where it is critical (for example, exchange), the user sees the outcome even before clicking “confirm”. This reduces errors and conflict situations.
  • Operational controllability. The product was designed so that the team could quickly detect a problem, understand the cause, and fix it - not by “guessing”, but through observability and processes.

Note

In this approach, the MVP becomes not a “raw version”, but a base that can be strengthened and scaled without breaking the foundation.

MVP as a controlled perimeter

To ensure that the pilot produced honest conclusions, we did not try to cover all possible functionality. We assembled a minimally sufficient set of contours that validates the main scenarios: daily usage, exchange, on-ramp/off-ramp, and early interest in RWA - and at the same time allows quality to be kept under control.

A controlled perimeter meant:

  • limited scope: we included only those blocks that provide a measurable signal of value and maturity;
  • a unified UX and status standard across all key scenarios, so that the user does not feel that “each part of the application lives by its own rules”;
  • fast improvement cycles: the pilot allowed us to quickly fix bottlenecks when the real causes of errors and support requests were visible.

At the final stage of the MVP, we further strengthened perimeter discipline: we stopped active acquisition, focused on stability, monitoring, bug fixing, and the final reconciliation of analytics - in order to complete the pilot correctly and safely for users.

MVP architecture at a high level

The MVP was built as a platform: a unified transactional core and modules, plus a separation of internal and on-chain contours with shared UX standards.

The “one core + modules” principle

We built the MVP as a platform, not as a set of features. The foundation is a unified transactional core, onto which modules are “attached”. This approach solves two tasks at once:

  • does not overload the user: there is no need to show “the entire universe of possibilities” at once;
  • accelerates development: new functions are added as separate modules, without rewriting the foundation.

What is included in the core (logically):

  • the user account and profile (including verification statuses);
  • balances and basic accounting rules;
  • the transaction ledger (a single source of truth);
  • the operation lifecycle: created → in processing → completed/error;
  • the mechanics of confirmations before critical actions;
  • a basic observability contour (so the team can see what is happening inside the system).

What belongs to the modules:

  • internal transfers;
  • on-chain deposits and withdrawals;
  • the internal exchange;
  • the P2P marketplace;
  • RWA;
  • support/chat and service components that extend the experience.

Thus, we obtained an architecture where the core is responsible for “bank-grade” reliability, and the modules for rapid functional expansion.

Tip

This is the key to scaling: functional expansion must not break accounting, statuses, and predictability.

Operation execution contours: internal vs on-chain

We divided the entire transactional world into two types of operations.

1) Internal operations (inside our system)
They are executed instantly, finality is determined by our accounting system, and the user sees the result immediately after confirmation. This is the foundation of everyday experience and habitual usage.

2) On-chain operations (on the blockchain)
Finality is determined by the network and confirmations. For part of the time, the operation is in a pending state, and the product’s task is to show this predictably and transparently.

The key point: despite the different nature, the user experience must be unified. Therefore, for both contours we maintained a common standard:

  • a clear confirmation screen;
  • clear statuses;
  • a clear result.

Warning

Different finality must not turn into different UX: otherwise errors, anxiety, and support load increase.

Observability and quality control

We built the MVP from the start so that it would be manageable. In a transactional product, it is not enough “for it to work”. The team must be able to see the state of systems and modules in real time, understand where delays and failures occur, quickly find the root cause, and fix it without risking breaking accounting and statuses.

To do this, we built a basic Observability contour around:

  • operation events and their statuses;
  • queues and stage traversal times;
  • errors at module boundaries (exchange, P2P, on-chain);
  • monitoring of application stability and the API;
  • auditing the actions of support operators (as part of service manageability).

Implementation of key product modules

The MVP modules were implemented “to the point”: fast onboarding, transparent statuses, predictable exchange, managed P2P, and early RWA as a controlled demand test.

Onboarding + basic KYC contour

We built onboarding so that the user quickly reaches the first useful action, rather than “getting stuck” in the registration form. In the MVP this meant two principles:

  • a short path to value: the user must understand what to do next and why it is safe;
  • control without overload: KYC and checks are embedded into the product logic and do not break the user experience.

KYC in the MVP was part of the base model: we used a risk-based approach and transaction monitoring, with the possibility of manual escalation based on risk signals (details of internal policies and providers are not publicly disclosed). This is important: from the pilot we built the product so that it could scale into stricter regulatory environments.

Info

We did not “add compliance later” - it was built into the product logic as a process: monitoring → signals → escalation → decision.

Internal transfers

Internal transfers are the “heart” of the daily experience. We implemented them so that a transfer feels like the simplest action in the application: the user selects a recipient inside the system (without long addresses), selects the asset and amount, confirms, immediately sees the final status, and the recipient sees instant crediting.

Technically, we built the internal transfer as an atomic accounting operation (finality inside the core), and product-wise as a transparent scenario “confirmation → done”. This linkage is critical: instant execution works only when the finality of the status is not in doubt.

On-chain deposits and withdrawals (TRC-20 / BEP-20)

We designed on-chain operations in the MVP so that the user understands two things:

  1. the blockchain lives by confirmation rules;
  2. the application must explain these rules through clear statuses.

Therefore, the implementation was built around:

  • explicit network selection (to minimize “wrong network / wrong standard” errors);
  • transparent confirmation status (pending → confirmed → completed);
  • input control: address format checks and network matching where possible;
  • observability: every operation has a clear identifier and a status trail.

We did not try to “hide” the on-chain nature. We made it understandable - and thus reduced anxiety and errors.

Internal exchange

We implemented the exchange in the MVP as a banking action: fast, predictable, and with the result shown before confirmation.

Key implementation elements:

  • quote → result preview → confirmation → execution → final status;
  • the user always sees You pay / You receive before pressing “confirm”;
  • the quote has a short validity period (TTL): if the price changes, the user is shown the updated result and must confirm again;
  • if the change goes beyond acceptable bounds, the operation is not carried out “silently” - it is canceled or repriced, and the user is offered an updated quote.

This is how we achieved the main goal: the exchange stopped being a “black box” and became a transparent scenario where the user understands the result in advance.

Example

If the quote changes, the user does not get a post-factum “surprise”: they see the update and confirm again.

P2P marketplace

We implemented P2P as a managed transaction with statuses and party protection - not as “a chat and figure it out”.

The implementation logic included:

  • a clear transaction lifecycle: creation → fixing terms → escrow mode → party confirmations → completion;
  • timings and statuses so that a transaction does not turn into endless messaging;
  • the ability to open a dispute and an arbitration procedure (decisions based on rules and facts, not “who is louder”);
  • integration with the risk contour: behavior monitoring, signals, and escalations.

The key principle: P2P is not “about trusting a person”, but about trusting the process.

RWA (early module)

We deliberately implemented RWA in the MVP as an early, controlled module to test demand and UX without premature expansion.

The implementation was built through:

  • a showcase and clear presentation;
  • a waitlist and a closed test (access control);
  • the scenario “confirmation → display in portfolio”;
  • careful limitation of complex investment details in the MVP, so as not to overload the user.

Our goal was practical: to prove that RWA can be perceived by the user as a clear asset inside the application, and that interest in this module is measurable.

Support as Part of the Product

Support in the MVP is built into the product: in-app chat, clear action boundaries, and a helpdesk contour that operates on facts and statuses.

In-app chat as the primary channel

In the MVP we immediately made support built into the product - inside the application. This is not “convenience for the sake of convenience”, but a fundamental requirement for a financial service: when a user has a question about an operation, they should resolve it in the same place where that operation was performed - not search for email, not call, not re-explain the context.

The in-app chat gave us three key advantages:

  • context: the operator (and the system) sees the profile, statuses, and case history within permitted access;
  • speed: the user gets help in the moment and does not lose the scenario thread;
  • manageability: all requests are фиксed, classified, and turned into product improvements.

We built the chat so that support does not explain “where to click”, but helps the user go through the scenario to the result: understand the status, perform the step, close the case.

Tip

In a financial product, support is a continuation of UX: it should help complete the scenario, not just “answer”.

Boundaries of support actions

To keep the service both fast and safe, we clearly separated what support can do on its own and what must be confirmed by the user.

Support could do (non-critical actions):

  • request documents and clarifications;
  • accompany verification and escalations;
  • help understand transaction, exchange, and P2P statuses;
  • accompany disputes and record facts for the case;
  • provide instructions and the next step based on the real operation status.

Support did not perform “on behalf of the user” (critical actions):

  • any actions that change the financial outcome without direct user confirmation;
  • transaction confirmations;
  • any “dangerous” actions that can be used in social engineering.

The principle was simple: if an action is critical - the decision is fixed in the application through user confirmation. This allows maintaining a high level of service while simultaneously reducing the risks of fraudulent pressure on support.

Helpdesk/admin contour (tools, without unnecessary details)

For support to be effective, chat alone is not enough. Tools are needed that connect a request with real operations and statuses.

Therefore, in the MVP we implemented a helpdesk and admin contour that allowed:

  • handling requests as cases (queues, statuses, priorities);
  • seeing the “full picture” of the user within access limits;
  • finding related operations (internal, on-chain, exchange, P2P);
  • accompanying P2P disputes and arbitration by process;
  • leaving internal comments and tags;
  • auditing operator actions (who did what and why).

As a result, support operated not on “guesses”, but on facts: operation status, scenario point, next step. This is what ensures 24/7 quality: when the process and tools are built, the service scales with a reasonably sized team, not with the number of people “on the phone”.

Risk Control and Security

The risk contour and product safeguards were built in from the MVP stage: monitoring and escalations plus security through UX.

Risk-oriented monitoring

From the start, we assumed that a transactional product cannot be scaled if risk control is “bolted on later”. Therefore, in the MVP we immediately laid down a basic risk contour: monitoring → signals → escalation → decision.

In practice, this looked like:

  • operations and user behavior pass through a set of risk checks;
  • when risk signals appear, the case goes into manual escalation;
  • the decision is made by process (not “by feel”) and is recorded in the system.

Important: we do not publicly disclose details of internal policies, providers, and specific rules - this is a standard security measure that reduces the possibility of bypassing controls. But the approach itself is fundamental: risk control in the MVP was a real working process, not a declaration.

Warning

The principle and the process are described publicly, but not the specific rules and providers - this reduces the attack surface of the system.

Product safeguards (security through UX)

We treat security not only as “checks”, but also as an interface mechanism. Most problems in fintech arise from human errors and unclear scenarios. Therefore, we embedded protective mechanisms at the UX level into the MVP:

  • confirmations before critical actions (to eliminate accidental operations);
  • a transparent result before confirmation in exchange scenarios (the user sees in advance what they give and what they receive);
  • clear statuses and finality across all operation types: internal, on-chain, P2P, exchange;
  • prevention of typical errors where possible: network selection, prompts, the logic of “better to stop and ask for confirmation than to allow a fatal error”.

The key idea: when the product explains to the user what is happening and gives them control, anxiety decreases, the number of errors and support requests goes down, and therefore cost-to-serve decreases and trust increases.

Reliability and Operations

The MVP was designed from the start as a 24/7 service: monitoring, an incident process, and controlled change iterations without the risk of breaking accounting.

24/7 mode: how we ensured support and stability

We initially designed the MVP as a service that must operate in 24/7 mode, because financial operations do not “live on a schedule”. This means: even if a failure occurs, the system must remain manageable, and the team must have a clear response process.

In the operational model of the MVP, we relied on three pillars:

  • monitoring and early detection: key components and transactional contours are observable, so that problems are detected by the system rather than by users “by feel”;
  • an incident management process: the priority is to restore stability and preserve accounting correctness, and only then to analyze root causes and release improvements;
  • the product - support - operations service linkage: when support has context and statuses, and the team has observability, problems are resolved faster and with less load on users.

Important: in the MVP we did not strive for an “ideal world without incidents”. We built the system so that any deviations are quickly detected, quickly localized, and do not turn into chaos for the user.

Note

The goal of the operational model is manageability under deviations, not the illusion of “never goes down”.

Change management in the pilot

One of the critical mistakes in pilots is uncontrolled changes for the sake of “new features”. We acted differently: the MVP evolved through controlled iterations, where the priority was always on two things:

  1. stability and predictability (especially in transactions and statuses);
  2. fixing UX bottlenecks that generate errors and support requests.

This is what it looked like in reality:

  • we collected signals from users and support (where the scenario breaks, what is unclear);
  • we captured problems as concrete tasks (screen/step/moment → cause → fix);
  • we released changes in a way that did not break the core and accounting: in small, controlled steps;
  • after changes, we verified that behavior and statuses remained correct.

The meaning of this model is simple: the pilot should not “expand”, but clean itself up - become clearer, more stable, and cheaper to operate.

Controlled Wind-Down of the Pilot

The pilot was completed as a controlled process: perimeter fixation, strengthened controls, and full transfer of assets to users without hang-ups.

Perimeter fixation and controlled wind-down

When external conditions made it impossible to continue expanding the pilot, we did not end the MVP by “switching it off”, but through a controlled process. In implementation, this looked like perimeter discipline and a priority on user safety.

We did the following:

  • fixed the perimeter of the pilot: stopped active recruitment and marketing in order not to increase load and not to expand the risk surface at the moment of completion;
  • shifted the team’s focus to stability: intensified monitoring, bug fixing, technical debt closure, and control of transactional contours;
  • conducted final analytical exports and transaction reconciliations: to correctly lock in the pilot results and ensure accounting integrity;
  • strengthened support / antifraud / compliance processes in the final phase, so that any disputed or risky situations were resolved predictably;
  • and most importantly: all assets were fully transferred to users - the pilot was closed “cleanly”, without stuck funds or uncertainty.

Danger

In a transactional product, winding down a pilot is a test of system maturity: you cannot leave “suspended” assets and unclear statuses.

What this implementation has proven

The MVP proved not the “presence of features”, but the ability to build and sustain a transactional product as a system: a unified UX, 24/7 processes, and readiness to move into the next market.

As a result of the MVP, we proved not the “presence of features”, but the ability to assemble and sustain a working transactional product as a system - with a clear UX, manageable processes, and readiness for scaling.

We built a set of contours that works as a single whole

The MVP showed that key scenarios do not live in isolation. Internal transfers, the exchange, P2P, and the early RWA module reinforce each other and create what we are building: a unified financial center, where the user does not need to “assemble an experience” from different services.

We made complexity predictable

The most important thing in a financial product is not “speed for the sake of speed”, but predictability:

  • the user sees confirmations and statuses;
  • understands where they are in the process;
  • and receives finality that can be trusted.

This directly reduces errors, anxiety, and the load on support.

We proved the manageability of the service 24/7

Support and operational processes were embedded into the product logic: cases were accompanied by context, support actions had clear boundaries, risk control was a process rather than manual chaos. This means the service scales through the quality of the system, not through the number of people.

We confirmed the platform’s readiness for the next market

The main technical conclusion of the MVP: we built a foundation that can be transferred and developed:

  • the transactional core as the “basis of banking behavior”;
  • modules as a way to expand without overloading the user;
  • observability and operational discipline as a base for international scale.

That is why further development is not “to rewrite from scratch”, but to strengthen and expand what has already proven its viability in a real pilot.

Backlinks

  • No backlinks found