Investments
Info
This section defines the investment rounds and the development phases of DARCA, aligned with the Roadmap and launch modes (partners, own licenses, migration).

Investment Rounds and Development Phases
Consolidated phase matrix: round size, deal instrument, duration, geography and mode, product scope, key outcome, and transition logic to the next phase.
Note
In Phase 1 - launch of Core in the EU via partners with controlled operations. UAE in Block 2 - readiness only, go-live starts from Block 3.
Consolidated Rounds Matrix
| Field | Seed - Phase 1 | Series A - Phase 2 | Series B - Phase 3 | Series C - Phase 4 |
|---|---|---|---|---|
| Round and phase | Seed - Phase 1 | Series A - Phase 2 | Series B - Phase 3 | Series C - Phase 4 |
| Round size | €1.8M | €11M | €30M | €115M |
| Deal instrument | SAFE (Simple Agreement for Future Equity). After agreeing on round terms, DARCA holding company is incorporated in Lithuania, and SAFE is structured under Lithuanian law as a future equity acquisition agreement, typically via subscription/option mechanics. Conversion details - see Section 2 | Priced equity round | Priced equity round | Priced equity round |
| Duration and Roadmap linkage | 24 months = Block 1 (15) + Block 2 (9) | 13 months (Block 3) | 15 months (Block 3) | 24 months (Block 4) |
| Geography and mode | EU - partner-based Core launch (go-live) UAE - readiness (no go-live) US - out of scope | EU - own-license Core go-live + dual-run migration from partners UAE - Core launch via partners (go-live from Block 3) US - out of scope | EU - module rollout in waves on own base UAE - Core transition to own licenses US - out of scope | UAE - full-scope (Core + modules) US - own-license launch RWA - factory in Phase 4 (Block 4) |
| Product scope | Core in EU via partners. Boundary of Phase 1 - no modules | Core in EU on own licenses + managed migration from partners. Core in UAE via partners | Modules in EU in waves. Core UAE on own licenses. Strengthening the Business layer and GTM | UAE full-scope (Core + modules). US own-license launch. RWA factory in Block 4 |
| Key outcome | Proven operational viability of Core in the EU under partner mode and controllability of daily operations. Readiness for transition to EU own licenses (processes, layers, migration requirements) | EU: Core on own licenses and start of controlled migration from partners without product interruption. UAE: Core launch via partners as a second live market | EU: product scaling through waves of modules on own base. UAE: Core moved to own licenses | UAE: full-scope Core + modules as a stable licensed and product layer. US: own-license launch. RWA factory implemented in Phase 4 |
| Enables next phase | Transition to EU own licenses and managed migration from partners (Phase 2) | Module waves in EU and Core transition in UAE to own licenses (Phase 3) | UAE full-scope and US own-license launch (Phase 4) | Scaling the operating model and global expansion, IPO as a scenario upon reaching scale |
flowchart LR
A["Seed SAFE"] --> B["Phase 1 24 months Block 1 (15) + Block 2 (9)"]
B --> C{"KPI gates for Phase 1 achieved"}
C -->|yes| D["Series A"]
C -->|no| E["Extension of Phase 1 focus on achieving KPIs"]
D --> F["Phase 2 13 months Block 3"]
F --> H["Series B"] --> J["Phase 3 15 months Block 3"] --> L["Series C"] --> N["Phase 4 24 months Block 4"]
subgraph GEO["Geography and regulatory mode"]
direction TB
G1["Phase 1 EU - partner Core go-live UAE - readiness (Block 2) US - out of scope"]
G2["Phase 2 EU - own-license Core + dual-run migration UAE - Core go-live via partners (Block 3) US - out of scope"]
G3["Phase 3 EU - modules in waves UAE - Core own-license US - out of scope"]
G4["Phase 4 UAE - full-scope (core + modules) US - own-license launch RWA factory - Block 4"]
end
B -.-> G1
F -.-> G2
J -.-> G3
N -.-> G4

Phasing and Sequencing Logic
Each phase sequentially eliminates key classes of uncertainty, making the next round lower-risk, faster to execute, and more evidence-based.
Info
The sequence is designed to first prove controlled Core operations in production, then transition to own licenses in a key geography, and only after that scale modules, new regions, and the operating model without fragmenting the product.
Phasing Principle
- Each phase delivers a measurable outcome: from Core functionality and controllability to own licenses and regional scaling.
- At the end of every phase, a class of uncertainty is reduced: product, operational, risk-compliance, infrastructure and organizational.
- This logic lowers the cost of capital in the next round: the project becomes more provable, predictable and scalable.
Note
In Phase 1, DARCA launches Core in the EU via partners and brings the operating model to a state of controlled production. UAE in Block 2 - readiness only, go-live begins in Block 3. RWA factory is implemented only in Phase 4 (Block 4).
gantt
title DARCA - Phases and Road-map Blocks (duration-only)
dateFormat YYYY-MM-DD
axisFormat %b %Y
section Phase 1 (Seed) - 24 months
Block 1 (15 months) :p1b1, 2026-03-01, 15M
Block 2 (9 months) :p1b2, after p1b1, 9M
section Phase 2 (Series A) - 13 months
Phase 2 (Block 3) :p2, after p1b2, 13M
section Phase 3 (Series B) - 15 months
Phase 3 (Block 3) :p3, after p2, 15M
section Phase 4 (Series C) - 24 months
Phase 4 (Block 4) :p4, after p3, 24M
section Geography and licensing milestones (aligned to Road-map logic)
ЕС - partner Core go-live (end of Block 1) :milestone, eu_go, after p1b1, 0d
ОАЭ - readiness starts (Block 2) :milestone, uae_ready, after p1b1, 0d
ЕС - own-license + dual-run starts (Phase 2) :milestone, eu_own_start, after p1b2, 0d
ОАЭ - Core go-live via partners (Phase 2) :milestone, uae_go, after p1b2, 0d
ОАЭ - Core own-license execution (Phase 3) :milestone, uae_own_exec, after p2, 0d
ЕС - modules waves start (Phase 3) :milestone, eu_mod_start, after p2, 0d
US licensing window (inside Phase 4) :usLic, after p3, 12M
США - own-license launch (after licensing) :milestone, us_go, after usLic, 0d
RWA factory program (Phase 4) :rwaProg, after p3, 24M
RWA factory - ready (end of Phase 4) :milestone, rwa_ready, after rwaProg, 0d
ОАЭ - full-scope complete (end of Phase 4) :milestone, uae_full, after p4, 0d
Phase 1 - Core launch in the EU via partners, evidence pack, licensing readiness
- Core launch in the EU via partners - fast entry into production operations without waiting for lengthy licensing cycles.
- Controlled operations - confirmation of stable daily Core scenarios and operational control:
- operation statuses and timelines
- documentation and operational case files
- risk/compliance decisioning (allow/step-up/hold/deny)
- in-app support as part of the operational layer
- Evidence pack - a structured proof set of product and operational maturity for the next phase:
- process and control artifacts
- operational logs, SLA performance, and layer resilience
- verifiability of statuses, documentation and case handling correctness
- Readiness for Phase 2 and licensing - Phase 1 builds the base on which an own-license regime is layered, rather than replacing the product or UX.
- UAE in Phase 1 - readiness only: preparation for partner launch and regional requirements without go-live.
Tip
Phase 1 does not expand scope through modules. The focus is Core-only and controlled EU operations, so that Phase 2 becomes migration of a mature product rather than a launch from scratch.
Phase 2 - EU Core own licenses, dual-run migration, UAE go-live via partners
- EU Core own licenses - transition of Core into a licensed regime, reducing dependency on partners in the primary geography.
- Dual-run migration - managed transition from partner mode to own-license without stopping the product:
- uninterrupted user scenarios
- phased layer transfer with quality and risk control
- UAE - transition from readiness to go-live via partners (starting Block 3) as the second active Core market.
Warning
In Phase 2, the main technical and operational priority is migration without product interruption. Any scope expansion must not overload Core or increase operational risk.
Phase 3 - EU modules in waves, UAE Core own-license, Business and GTM scale-up
- Wave-based module launch in the EU - staged by compliance and risk class to ensure scaling does not break Core or fragment UX:
- each wave introduces new operational classes and requires dedicated risk and compliance control
- each wave is formalized through processes, metrics, and control artifacts
- UAE Core transition to own license - reduced partner dependency in UAE after proving the operating model across two markets.
- Business layer and GTM reinforcement - accelerated sales and marketing scale-up becomes justified once Core and operations are stable and EU licensing has removed the primary structural dependency.
Note
Phase 3 delivers “scaling without surprises”: geographic and functional growth occurs only on a stable Core with controlled perimeter expansion.
Phase 4 - UAE full-scope, US own-license launch, RWA factory, scaling the operating model
- UAE full-scope modules - deployment of the full perimeter (core + modules) on a mature compliance and risk framework.
- US own-license launch - launch under a separate licensing regime after confirming the operating model in the EU and UAE and ensuring team readiness for scale.
- RWA factory - a separate complex perimeter, implemented only in Block 4 and not mixed with earlier phases in order to preserve Core focus and risk controllability.
- Scaling the operating model and the team - transition from a compact product team to a scaled “group of functions” across multiple regions and product lines.
Example
Final sequencing logic: Core becomes stable and proven in production - then anchored under own-license in the EU - then expanded through modules in waves - then scaled to UAE full-scope and the US, while preserving a unified perimeter of operations, controls, and documentation.

Unified document fixations
Below are the baseline parameters of Phase 1 and the foundational boundaries that are applied consistently throughout the document.
Info
All subsequent sections rely on these values without changing the wording or the figures.
- Phase 1 lasts 24 months and has a budget of €1.8 million.
- The current Seed round is structured via SAFE. The legal execution of the transaction is completed after agreeing on the round terms and registering the DARCA parent company in Lithuania.
- The financial model of Phase 1 is built without revenue assumptions. Any early inflows are treated as a buffer, not as a condition for plan execution.
- UAE in Block 2 operates in readiness mode. Go-live in the UAE begins in Block 3.
- The base scenario for reaching break-even is 30-36 months from the start of Phase 1.
- The perimeter of Phase 1 is Core-only in the EU via partners. In Phase 1, modules, RWA, and the US are not launched.
Note
The document then details the current Seed round and what is financed within Phase 1, followed by the definition of KPI gates at the end of Phase 1 as the conditions for transition to Phase 2.

Key Seed Parameters
This section defines the parameters of the current Seed round and the Phase 1 framework, which are used throughout the document without changes to wording or figures.
- The Seed round amount - €1.8 million.
- Funding period - Phase 1 = 24 months, including Block 1 = 15 months and Block 2 = 9 months.
- Transaction instrument - SAFE. Legal execution is completed after agreeing on the round terms and registering the DARCA parent company in Lithuania.
- SAFE conversion - into Series A (priced equity round).
- The financial model of Phase 1 is built without revenue assumptions. Any early inflows are treated as a buffer, not as a condition for plan execution.
- UAE in Block 2 operates in readiness mode. Go-live in the UAE begins in Block 3.
- The base scenario for reaching break-even - 30-36 months from the start of Phase 1.
- The perimeter of Phase 1 - Core-only in the EU via partners. In Phase 1, modules, RWA, and the US are not launched.
Note
The following section specifies exactly what the Seed funds in Phase 1 are allocated to, which results must be achieved by the end of Phase 1, and which KPI gates define readiness for transition to Phase 2.

SAFE - structure of terms
Seed uses SAFE, and below is the list of terms and their meaning without specifying numerical values until final agreement.
Info
Numerical values and final wording are fixed in the term sheet and transaction documents.
- Valuation cap - the maximum valuation at which SAFE conversion is calculated in the Series A round. If the Series A valuation exceeds the cap, conversion is calculated based on the cap.
- Discount - a discount to the Series A price applied when converting SAFE into equity/shares.
- MFN (if applicable) - a provision under which the SAFE investor has the right to switch to more favorable terms if a SAFE is issued on better terms within the Seed round.
- Pro-rata (if granted) - the right to participate in the next financing round to maintain ownership after conversion.
- Qualified Financing - the definition of the event considered as Series A that triggers automatic SAFE conversion. Within this document, Series A is defined as a priced equity round with the issuance of equity/shares at a valuation and capital raised in accordance with the transaction criteria.
- M&A/liquidation - the base scenario branch in the event of a company sale or liquidation event prior to Series A. The document defines the principle of SAFE treatment in such events, while the specific mechanism is determined by the terms of the term sheet and transaction documents.

Current state prior to fundraising
Before closing Seed, the team operates in a capital efficiency mode - without premature growth of fixed costs and with a legally clean framework for the subsequent launch in the EU.
- The previous operational structure related to the MVP in Russia has been terminated - legal entities have been closed, and operations in Russia are not conducted.
- The team and founders are located outside Russia.
- Current work is carried out without legal entities and without premature increases in fixed costs, to avoid creating administrative overhead before it becomes necessary for the transaction and licensing.
- The team operates in an economy mode - minimal overhead, no early hiring, and no expenses on non-essential administrative infrastructure prior to the start of commercial operations.
- Project-based revenue is permitted as a supporting buffer for current expenses prior to closing Seed, but it is not a condition for executing Phase 1 and is not included in the Phase 1 financial model.
- DARCA is being launched within a new jurisdictional structure based in Lithuania, without operational dependency on Russia.
- Registration of the DARCA parent company in Lithuania and legal execution of Seed are carried out after agreement on the round terms and preparation of the transaction documents.
Note
This approach preserves flexibility and low burn until Seed closing, and then enables scaling of the operating model strictly by phases and Road-map blocks.

Group and jurisdictional structure after approval of Seed terms
After approval of the Seed terms, a controlled group structure is established: a licensing and management base in Lithuania and scalable engineering hubs in more cost-efficient locations.
- Approval of Seed terms - trigger for registration of the DARCA parent company in Lithuania and execution of the transaction documents.
- SAFE is issued at the parent company level and converts into its equity/shares upon Series A.
- The Lithuanian parent company becomes the group governance perimeter and the base jurisdiction for EU licensing and track record.
- The parent company holds IP ownership and key product rights, and establishes the legal and compliance function as a critical path for the EU.
- Georgia - development subsidiary as the primary engineering hub in Phase 1, enabling expansion of engineering capacity with a controlled cost base.
- Turkey - additional development perimeter, connected later to increase capacity and access to the hiring market without impacting the EU licensing perimeter.
flowchart TB
LT["Parent company - Lithuania (group management + EU licensing + IP ownership)"]
GE["DevCo - Georgia (main engineering hub - Phase 1)"]
TR["DevCo - Turkey (additional hub - later)"]
LT --> GE
LT --> TR
subgraph IPG["IP ownership + delivery governance"]
IP1["IP and key rights are held by the parent company (Lithuania)"]
IP2["DevCos perform development under contracts - results are transferred to the parent company"]
IP3["Unified access and security perimeter (IAM, roles, audit)"]
IP4["Unified release pipeline (review, approvals, release gates)"]
end
LT -. controls .-> IPG
GE -. complies .-> IPG
TR -. complies .-> IPG
Principles of IP Ownership and Development Control
- All key deliverables and exclusive rights are assigned to the parent company in Lithuania.
- Subsidiary development units perform work under contracts, and the results (code, documentation, artifacts) are transferred to and assigned to the parent company.
- A unified access and security perimeter applies to all locations - roles, least privilege, activity audit, and centralized access management.
- A unified release perimeter and change management - code review, approvals, release gates and centralized control of the production environment.
- Unified quality standards and centralized ownership of architecture - common rules for development, testing and release.
- A unified single source of truth principle - central code and documentation repositories and a governed change history.
Note
This structure makes it possible to simultaneously build track record and compliance in the EU and scale engineering capacity without premature growth of fixed costs in the EU.

Phase 1 Goal
Phase 1 concludes with the launch of Core in the EU through a partner perimeter and the transition to managed operations, where quality, risk, and financial integrity are validated through observable artifacts and operational perimeters.
Launch of Core in the EU through a partner perimeter
Go-live in the EU is structured through a set of providers across key layers. During Phase 1 preparation, terms, compatibility and operational capabilities are assessed, with the final selection formalized within the execution of Phase 1.
- Stablecoin/treasury layer - Circle Internet Financial Europe (under evaluation)
- Fiat rails / banking layer - Newrails, Fiat Republic (under evaluation)
- Custody / wallet infrastructure - Fireblocks, BitGo, Copper (under evaluation)
- KYC/KYB - Sumsub, Onfido, Jumio (under evaluation)
Managed Operations of Core
- Operation statuses and timeline - each operation has a managed lifecycle with defined statuses and an event timeline, reducing errors, disputes, and support load, and simplifying quality control.
- Operation dossier and documents - a unified dossier is created for each operation (attributes, participants, fees/rates, confirmations, events) along with linked documents, ensuring provability for support, investigations and reporting.
- Reconciliation and balance integrity control - a financial integrity perimeter for reconciling ledger, accounts, transactions, and providers, preventing discrepancies and enabling managed error correction.
- Risk/compliance decisioning and reason log - a unified allow/step-up/hold/deny decision perimeter with a reason log, ensuring risk policy governance and explainability of operational decisions.
- In-app support with actions - in-app support as part of the product: assistance scenarios through buttons and deep-links, document collection and guiding the user to required actions without calls or external channels.
Evidence pack and readiness for Phase 2
Phase 1 forms an evidence pack - a set of artifacts confirming operational stability, quality and risk governance, and readiness for the next phase:
- operational stability and incident reports
- reconciliation results and financial integrity control
- risk/compliance decisioning logs and quality of management responses (step-up/hold/deny)
- release discipline and changes (approvals, gates, governed change history)
- validated operational support functioning as a product component
Note
The result of Phase 1 - a functioning Core in managed operations and a provable foundation for transition to Phase 2, including preparation for own EU core licenses and dual-run migration without product interruption.

Scope Phase 1 - Core functional perimeter
Phase 1 implements and puts into operation the full Core perimeter for daily fiat+crypto operations in the EU in partner-mode - with transparent statuses, documents, balance control, risk, and support as part of the product.
Info
Phase 1 functionality is implemented within partner-mode and applicable provider requirements - where external rails limit data or speed, the user still sees transparent statuses and the expected execution time within available signals.
Profile, KYC and basic checks
- User profile and basic account settings.
- KYC and basic checks - within the partner regime and provider requirements.
- Policy-driven control of feature eligibility and limits by region and user type.
Ledger and fiat+crypto accounts
- Unified ledger and fiat+crypto accounts within a single perimeter.
- Transparent display of balances and fund movements linked to operations and their statuses.
Internal transfers
- Transfers by phone/email/ID/QR within the ecosystem.
- Recipient identification where technically and compliance permissible.
- Transparent statuses and execution confirmation through the operation timeline.
External fiat transfers
- External transfers via partner fiat rails (IBAN and local rails - where applicable).
- Transparent display of statuses and execution time within the capabilities of the rails and provider signals.
Crypto custody
- Deposits and withdrawals of crypto assets.
- Network selection and network correctness control during sending/receiving.
- Address book and protection perimeters against network/address errors.
- Monitoring of transaction statuses, confirmations, and events.
Exchange (daily exchange)
- You send / you receive preview before confirmation.
- Rate and fees before confirmation.
- Transparent recording of exchange parameters in the operation dossier and documents.
Cards (partner-mode)
- Issuance and management of cards in partner-mode.
- Limits and basic usage rules.
- Basic disputes perimeter and processing of disputed transactions within available procedures.
Core operational perimeter
- Statuses, timeline, and operation dossier as a unified layer of observability and governance.
- Documents and statements for operations, including fee and rate parameters where applicable.
- Action log and explainability - the logic of “why this status” and which events led to it.
Risk/compliance decisioning
- Unified decision perimeter allow/step-up/hold/deny.
- Reason log and decision traceability as operational provability and a basis for improving risk policies.
Support
- In-app chat as the primary support channel, without calls.
- Deep-links and actions in support for non-critical operations and document collection.
- Critical actions are executed through user confirmation within the product.
Regional regimes
- Geofencing and regional policies for feature access.
- Segment-based restrictions by region and user type in accordance with partner and provider requirements.

Phase 1 Plan by Road-map Blocks
Phase 1 is divided into two managed blocks: Block 1 brings Core to production-ready status and delivers EU go-live through the partner perimeter, Block 2 stabilizes operations and forms readiness for Phase 2, while executing UAE readiness in parallel without go-live within Phase 1.
Block 1 (15 months) - build + EU go-live through partners
- Engineering delivery of Core - Core delivery is executed as the main workstream (engineering hub - GE DevCo + current team) and brought to production-ready status for launch in the EU.
- Partner perimeter integrations - integrations across key layers: rails, cards, KYC/KYB, AML/sanctions, custody, on/off-ramp, including operational procedures around providers.
- Production readiness as a standalone delivery before go-live:
- observability, alerts, and monitoring of critical metrics
- runbooks, incident management, and escalations
- reconciliation and discrepancy control as a barrier for financial integrity
- release discipline and change control (approvals, governed releases, rollbacks)
- In parallel in Lithuania a legal and compliance track is launched:
- formation of the legal and compliance function as a critical path for the EU
- preparation of the foundation for partner launch requirements in the EU and for the subsequent transition to the EU own-license regime
Block 2 (9 months) - stabilization + Phase 2 readiness + UAE readiness
- Stabilization - bringing operations to a predictable and less manual state:
- reduction of manual operations and manual workarounds
- increased predictability of statuses, documents, and reconciliation
- improvement of support quality and FCR as a measurable operational outcome
- Evidence pack - formalizing provability of reliability, service quality, risk governance, and operational control through operational artifacts and quality metrics.
- Phase 2 readiness - preparation for transition to EU own-license without product interruption:
- dual-run design - migration architecture and parallel operating modes
- provider portability and switching plan - integration requirements, redundancy, replacement scenarios
- preparation of EU own-license regime requirements within product, processes, and control perimeters
- UAE readiness - preparation for future go-live (starting from Block 3):
- procedures and risk configurations aligned with regional requirements
- preparation of policy-driven restrictions and operational regimes for launch
- Strengthening functions in Lithuania is executed as needed, without premature expansion of HQ and fixed costs.
gantt
title Phase 1 - Block 1 vs Block 2 (start 2026-03-01)
dateFormat YYYY-MM-DD
axisFormat %b %Y
section Block 1 (15 months) - build + EU go-live
Engineering delivery Core (GE DevCo + team) :b1_eng, 2026-03-01, 2027-06-01
Partner integrations (rails, cards, KYC, custody):b1_int, 2026-03-01, 2027-06-01
Production readiness (obs, runbooks, recon) :b1_prod, 2026-03-01, 2027-06-01
Legal/compliance track in Lithuania :b1_lt, 2026-03-01, 2027-06-01
section Block 2 (9 months) - stabilization + readiness
Stabilization (reduce manual ops, predictability):b2_stab, 2027-06-01, 2028-03-01
Evidence pack :b2_evp, 2027-06-01, 2028-03-01
Phase 2 readiness (dual-run, portability plan) :b2_p2, 2027-06-01, 2028-03-01
UAE readiness (no go-live in Phase 1) :b2_uae, 2027-06-01, 2028-03-01
HQ scaling in Lithuania (as needed) :b2_hq, 2027-06-01, 2028-03-01
Note
Block 1 completes EU go-live of Core in partner mode, Block 2 reduces operational risks and secures readiness for Phase 2 through stabilization, evidence pack, and dual-run design.

KPI Gates at the End of Phase 1
Transition to Phase 2 is executed after confirming the scalability of Core in operations - across growth and activity, reliability, support quality, compliance and risk governance, as well as monetization readiness.
KPI Gates (end of Phase 1)
| Direction | KPI | Target Value |
|---|---|---|
| Growth and activity | DAU | 25,000+ |
| Growth and activity | MAU | 70,000+ |
| Growth and activity | Retention D7 | 48%+ |
| Growth and activity | Retention D30 | 32%+ |
| Growth and activity | Turnover | 1M+ per month |
| Reliability | Uptime | 99.7%+ |
| Reliability | Critical incidents | No systemic recurring critical incidents |
| Support and quality | CSAT | 3.9+ / 5 |
| Support and quality | First response | 2-3 minutes or better |
| Support and quality | FCR | 70%+ |
| Compliance and operations | SLA compliance review | Governed SLA without degradation during growth |
| Compliance and operations | Manual review | Manual review corridor with a downward trend |
| Risk | Losses | Governed losses within acceptable limits |
| Risk | Hold/step-up | Confirmed hold/step-up operation and reason logging |
| Monetization readiness | Subscription | Working subscription and confirmed upgrade triggers |
mindmap
root((Phase 1 end KPI gates))
Growth and activity
DAU 25,000+
MAU 70,000+
Retention D7 48%+
Retention D30 32%+
Monthly volume 1M+
Reliability
Uptime 99.7%+
No recurring critical system incidents
Support and quality
CSAT 3.9+/5
First response 2–3 minutes or better
FCR 70%+
Compliance and operations
SLA compliance review manageable without degradation during growth
Manual review corridor with a downward trend
Risk
Losses controlled within acceptable limits
Hold/step-up confirmations validated + reason logging
Monetization readiness
Subscription operational
Upgrade triggers validated
Note
KPI gates reflect metric stability in operations, not a one-time spike. Achieving the gates confirms readiness for Phase 2 - transition to the EU own-license perimeter and design of dual-run migration without product interruption.

Use of Funds - Phase 1 Budget Structure
The Phase 1 budget of €1.8 million is allocated across baskets that reflect the critical tracks for launching Core in the EU in partner-mode - product, integrations and go-live readiness, operational perimeters, security, compliance, support preparation, minimal GTM, and trigger-based reserve.
Info
The cost control logic in Phase 1 is stage-based activation of expenses by Road-map blocks and maintaining a variable model where possible (partner-mode, project-based legal support, no premature HQ expansion).
Phase 1 Budget Baskets (100% = €1.8 million)
| Basket | What it covers | Share | Amount |
|---|---|---|---|
| Product/Engineering delivery (Core) | Core development and reaching production-ready status, including operational perimeter (statuses, dossier, documents, decisioning, support actions) | 45% | €810k |
| Integrations and go-live readiness | Integrations of partner layers (rails, cards, KYC/KYB, AML/sanctions, custody, on/off-ramp) and launch scenarios | 15% | €270k |
| Infrastructure/Operations | Observability, runbooks, incident management, release discipline, reconciliation and discrepancy control | 10% | €180k |
| Security | Pentests and security audits by milestones, access controls, strengthening of infrastructure and processes | 5% | €90k |
| Compliance readiness | Internal owner + external legal agency on a project basis (templates, procedures, policies, partner-mode requirements, Phase 2 foundation) | 8% | €144k |
| Support readiness (from month 12) | Hiring and training support from month 12 for mature operations and stabilization in Block 2 | 7% | €126k |
| Minimal GTM | PLG and lifecycle communications without aggressive paid channels, focus on activation/retention and operational growth stability | 5% | €90k |
| Trigger-based reserve | Reserve for predefined conditions (load, security, compliance, infrastructure) | 5% | €90k |
pie showData
title Phase 1 (€1.8 млн)
"Product/Engineering delivery (Core) - 45% (€810k)" : 45
"Integrations и go-live readiness - 15% (€270k)" : 15
"Infrastructure/Operations - 10% (€180k)" : 10
"Compliance readiness - 8% (€144k)" : 8
"Support readiness (from month 12) - 7% (€126k)" : 7
"Security - 5% (€90k)" : 5
"Minimal GTM - 5% (€90k)" : 5
"Trigger-based reserve - 5% (€90k)" : 5
Stage-based activation of expenses by Road-map blocks
- Block 1 - 65% of the Phase 1 budget - €1.17 million
- primary focus - Engineering delivery, integrations, production readiness, and launch of the legal and compliance track in Lithuania
- Block 2 - 35% of the Phase 1 budget - €0.63 million
- primary focus - stabilization, evidence pack, Phase 2 readiness (dual-run design), UAE readiness, as well as a noticeable activation of support costs (start of hiring and training from month 12)
Cost efficiency and governance drivers
- Engineering hub in Georgia as cost-efficient capacity for the main Phase 1 delivery.
- Staged build-up of HQ in Lithuania - first the legal and compliance core, scaling management as needed.
- Legal templates and procedure packages through an external agency on a project basis, without premature in-house expansion.
- Partner guardrails at the start - focus on variable costs and terms that do not require large fixed minimums at an early stage.
- Stage-based activation of expenses by milestones - in particular, support from month 12 and governed use of the trigger-based reserve.
Note
The Phase 1 reserve is used only upon load triggers or requirements to strengthen reliability, security, compliance, and operational perimeters - it is not a planned expense item by default.

24-Month Runway
The Phase 1 runway of 24 months is secured through perimeter discipline, staged cost activation, and a cost base strategy, as well as leveraging existing MVP groundwork - core logic and internal governance perimeters that are further developed and brought to production-ready level for launching Core in the EU in partner-mode.
Phase 1 perimeter control
- Phase 1 = Core-only in the EU in partner-mode.
- Phase 1 does not include expenses for launching modules, RWA, and the US - these directions are allocated to subsequent phases and are not mixed with the Seed budget.
- The Phase 1 perimeter fixes manageable complexity: load growth increases costs predictably, without a nonlinear “everything at once” effect.
Staged cost activation - milestone-based expense activation
- Expenses are activated sequentially along the trajectory build → go-live → stabilization → readiness.
- Critical operational functions are strengthened as the product transitions to live operations:
- in Block 1 the focus is on Core delivery, integrations and production readiness
- in Block 2 the focus is on stabilization, evidence pack and Phase 2 readiness
- Support readiness is activated from month 12 - hiring and training are structured so that by the stabilization period (Block 2), support operates as a mature operational perimeter without inflating early burn.
Cost base strategy - governed cost structure
- Phase 1 development and delivery are placed in cost-efficient engineering hubs:
- Georgia - primary engineering hub for Phase 1
- Turkey - connected later as additional capacity, without impact on the EU licensing perimeter
- Management, legal and compliance function, and EU launch preparation are concentrated in Lithuania as the base jurisdiction for further EU licensing:
- start as a legal and compliance core and governance function
- expand HQ as needed, without early overhead
- This structure delivers the same Core and readiness outcome with a more efficient cost base than building a full engineering department in the EU during Phase 1, and keeps Phase 1 within the approved budget while preserving delivery quality and EU compliance criticality.
Procurement strategy - project-based closure of high-cost activities
- Legal templates, procedures, and part of compliance work are closed on a project basis through an external agency under the control of an internal owner, without premature in-house expansion.
- Security activities (pentests, milestone-based checks, process strengthening) are activated when they deliver maximum impact for go-live and perimeter changes, rather than as a permanent large staff function in Phase 1.
Partner guardrails - control of variable costs
- Partner-mode at the start is structured around variable costs and governed terms:
- no large fixed minimums at an early stage
- transparent fee rules, SLA, and change management
- costs scale with volume rather than preceding it
Trigger-based reserve - resilience to deviations
- Phase 1 includes a reserve that is used only upon predefined triggers:
- growth in operational and support load
- need to strengthen security and access control
- increase in compliance load and manual review
- infrastructure expansion due to growth in active users and transaction volume
- The decision to spend the reserve follows the principle trigger → assessment → decision → spend, otherwise prioritization and staging of work are adjusted without increasing the fixed cost base.
| Basket | What it covers | Share | Amount |
|---|---|---|---|
| Product/Engineering delivery (Core) | Core development and reaching production-ready status, including operational perimeter (statuses, dossier, documents, decisioning, support actions) | 45% | €810k |
| Integrations and go-live readiness | Integrations of partner layers (rails, cards, KYC/KYB, AML/sanctions, custody, on/off-ramp) and launch scenarios | 15% | €270k |
| Infrastructure/Operations | Observability, runbooks, incident management, release discipline, reconciliation and discrepancy control | 10% | €180k |
| Security | Pentests and security audits by milestones, access controls, strengthening of infrastructure and processes | 5% | €90k |
| Compliance readiness | Internal owner + external legal agency on a project basis (templates, procedures, policies, partner-mode requirements, Phase 2 foundation) | 8% | €144k |
| Support readiness (from month 12) | Hiring and training support from month 12 for mature operations and stabilization in Block 2 | 7% | €126k |
| Minimal GTM | PLG and lifecycle communications without aggressive paid channels, focus on activation/retention and operational growth stability | 5% | €90k |
| Trigger-based reserve | Reserve for predefined conditions (load, security, compliance, infrastructure) | 5% | €90k |
flowchart LR
A["Trigger"] --> B["Impact assessment<br/>- risk/losses<br/>- SLA/service quality<br/>- compliance load<br/>- reliability/infrastructure"]
B --> C{"Decision"}
C -->|Priority higher than planned work| D["Allow reserve spending<br/>- scope<br/>- timeline<br/>- owner<br/>- stop criteria"]
C -->|Priority lower than planned work| E["Do not spend reserve<br/>- reprioritization<br/>- staging and move to roadmap"]
D --> F["Execution and control<br/>- plan vs actual<br/>- impact metrics<br/>- result report"]
E --> F
F --> G{"Trigger resolved?"}
G -->|Yes| H["Close case<br/>update runbooks and limits"]
G -->|No| I["Refine measures<br/>reassessment"]
I --> B
Note
The Phase 1 runway is based on the governed complexity of the Core-only perimeter, staged cost activation, and a group structure where the legal and compliance function and governance are located in the EU, while delivery scales through cost-efficient engineering hubs.

Governance Phase 1 - control of scope, budget, and execution
Phase 1 is managed as an executable plan with control over perimeter, budget, and delivery cadence - to maintain a 24-month runway and reach the end-of-Phase-1 KPI gates without scope creep and uncontrolled burn.
Scope governance
- Changes are allowed only if they do not break the KPI gates of Phase 1 and do not weaken runway controllability.
- Phase 1 “red lines” are fixed:
- Core-only in the EU in partner-mode
- no modules, no RWA, no US
- Critical changes are formalized as a separate management decision:
- owner, timeline, impact on plan and budget, stopping criteria
- the decision is taken before irreversible spending commitments arise
Budget control
- Monthly budget reporting structured by Use of funds baskets:
- plan vs actual
- reasons for deviations
- adjustments through staging and prioritization
- The reserve is spent only upon triggers and recorded as a separate case:
- reason, owner, effect metrics, closing criteria
- reserve decision process - see section “24-Month Runway”
Governance cadence and reporting
- A rolling 90-day work plan (quarterly horizon) is updated at quarterly checkpoints.
- A monthly execution plan fixes the scope of work and expenses for the upcoming month.
- The monthly report includes:
- progress report on completed work and results
- financial report plan vs actual by baskets and key line items, with explanation of deviations
- The level of transparency ensures traceability of expenses from basket to workstream, with supporting primary documents provided upon request within the agreed framework.
KPI gate checkpoints for Phase 1
- Quarterly checkpoints compare actual progress against end-of-Phase-1 KPI gates and record priority adjustments.
- The outcome of checkpoints - an updated 90-day plan and confirmation of readiness in terms of operational stability, service quality, and risk governance.
Note
Governance Phase 1 reduces the risk of scope creep and makes execution and budget spending measurable against the KPI gates that unlock transition to Phase 2.

Team and Hiring in Phase 1
Phase 1 is built on bank-grade delivery of Core, governed operations, and preparation of an evidence pack for transition to Phase 2. The hiring logic is to close responsibility perimeters (money, integrations, risk, compliance, support, data) according to Road-map milestones.
Info
Phase 1 applies a staged build-up: LT functions are strengthened as needed and in critical legal+compliance roles, core delivery scales through the engineering hub. Support is activated from month 12 - hiring and training - before that the focus is on product and go-live.
Current core team
- Max Shaitor - CEO - product, strategy, commercial, partnerships
- Maxim Menkov - CTO - architecture, integrations, reliability, bank-grade delivery
- Artem Lebedev - DevOps/SRE - operations, observability, incidents
- Ilya Gromov - DevSecOps - secure SDLC, controls, release security
- Sergey Volkov - Backend Go - Core services, transactional logic
- Nikita Orlov - Lead Frontend - client-side logic of statuses and money flows
- Anton Bondar - CDO - design of money scenarios, UX system approach
- Anastasia Dyachkova - Head of Support - L1-L3 model, quality and processes
- Viktor Bolotov - Chief Legal Officer - contracts, user documents, IP, legal resilience
flowchart TB
CEO[CEO - Product, Strategy, Partnerships]
CTO[CTO - Architecture, Integrations, Reliability]
CEO --> CTO
subgraph LT["Литва - ManagementCo - Phase 1"]
LEGAL[Legal and Compliance ownership]
AML[AML Compliance Officer - EU]
DPO[DPO Privacy - GDPR]
LC[Legal Counsel - Commercial Fintech]
RC[Regulatory Counsel - EU]
FIN[Finance and Reconciliation ownership]
FC[Financial Controller]
ACC[Accountant]
RISK[Risk and Fraud ownership]
RFE[Risk Fraud Engineer]
GROW[Growth ownership - minimal GTM]
GM[Growth Marketer]
end
subgraph GE["Грузия - GE DevCo - Engineering hub"]
ENG[Engineering delivery ownership]
BE[Backend - Core]
FE[Frontend - Core UX]
MOB[Mobile Engineers x2]
QA[QA Lead and QA Automation]
INT[Integration Engineer]
OPS[Production Ops ownership]
SRE[DevOps SRE]
DSO[DevSecOps]
end
subgraph SUP["Support - from Month 12"]
SL[Support Lead]
AG[Support Agents 24-7 x7]
SOP[Support Ops]
end
subgraph TR["Турция - TR DevCo - later"]
CAP[Additional engineering capacity]
end
CTO --> ENG
CTO --> OPS
CEO --> LEGAL
CEO --> FIN
CEO --> RISK
CEO --> GROW
CEO --> SL
ENG --> BE
ENG --> FE
ENG --> MOB
ENG --> QA
ENG --> INT
OPS --> SRE
OPS --> DSO
LEGAL --> AML
LEGAL --> DPO
LEGAL --> LC
LEGAL --> RC
FIN --> FC
FIN --> ACC
RISK --> RFE
GROW --> GM
SL --> AG
SL --> SOP
GE -.-> TR
What is strengthened in Phase 1 and why
Below are the functions without which it is impossible to simultaneously bring Core to production mode, maintain governance of quality and risk, and prepare the transition to Phase 2.
- Engineering delivery and release discipline
- Mobile engineers - 2 - money flows, confirmations, deep-links, secure on-device storage
- QA - 2 - QA Lead + QA automation, e2e for critical scenarios, regression, release gates
- Integration engineer - 1 - KYC/KYB, sanctions, custody, rails, webhooks, idempotency, reconciliations
- Risk, compliance, and permission perimeter
- AML/Compliance Officer (EU) - 1 - policies and procedures, audit readiness, control of the manual review corridor
- DPO/Privacy (GDPR) - 1 - privacy by design, data procedures and data subject requests
- Risk/Fraud engineer - 1 - rules+signals, hold/step-up, case investigations together with support, reason log
- Finance, reconciliations, and governed operations
- Financial controller - 1 - registers, reconciliation discipline, control of financial perimeter accuracy
- Accountant - 1 - accounting, documents, operational reports, reconciliation support
- Support and operational processes (activation from month 12)
- Support agents 24/7 - 7 - L1/L2, escalations, support of statuses and documents
- Support Ops - processes, knowledge base, support QA, linkage with incident management - as a function under the Head of Support
- Marketing and product growth (minimal Phase 1 perimeter)
- Growth marketer - 1 - activation/retention, lifecycle, subscription and upgrade triggers, experiment analytics
- Performance marketing in Phase 1 is activated only upon confirmed funnels and controlled CAC
Warning
Legal, compliance, risk, and finance in Phase 1 must have in-house owners. External contractors are used as reinforcement - local specifics, templates, audit, pentest - but not as a replacement for ownership.
Hiring phasing for Phase 1
Block 1 - first 15 months - build + EU go-live in partner-mode
- Delivery perimeter:
- Mobile engineers - 2
- QA Lead + QA automation - 2
- Integration engineer - 1
- LT legal+compliance perimeter:
- AML/Compliance Officer (EU) - 1
- DPO/Privacy (GDPR) - 1
- Legal Counsel (commercial/fintech) - 1
- Regulatory Counsel (EU) - 1
- Financial perimeter and reconciliations:
- Financial controller - 1
- Accountant - 1
- Risk/Fraud:
- Risk/Fraud engineer - 1
- Marketing:
- Growth marketer - 1 - lifecycle, subscriptions, retention mechanics without aggressive paid
Block 2 - next 9 months - stabilization + Phase 2 readiness + UAE readiness
- Support:
- start of hiring and training from month 12, ramp-up to a stable 24/7 perimeter by the end of Phase 1
- Operational governance:
- strengthening incident-support processes, reduction of manual operations, increased predictability of reconciliation and statuses
- Phase 2 readiness:
- resources for dual-run design, provider portability, preparation of requirements for the EU own-license regime
External contractors in Phase 1
- External legal agency (Lithuania/EU) - templates and procedure packages, local specifics, review of contracts and user documents
- Security activities - pentests, perimeter audits, process reviews by milestones
- Targeted consultations on licensing and provider requirements - as go-live approaches and Phase 2 preparation progresses
Function placement principle
- GE DevCo - primary engineering hub of Phase 1
- Lithuania - governance, legal+compliance, control of providers and EU requirements
- TR DevCo - connected later as an additional hiring market and capacity, without impact on the EU licensing perimeter

Phase 1 Partner Model
Phase 1 is launched in partner-mode: partners cover licensed and infrastructure perimeters, while DARCA retains control over quality, statuses, reconciliations, and risk, protecting runway and readiness for Phase 2.
Phase 1 is implemented in partner-mode - partners cover licensed and infrastructure perimeters, while DARCA focuses on a bank-grade product, quality and risk control, governed operations and preparation of an evidence pack for transition to Phase 2.
The key principle of Phase 1 - even in a partner launch, DARCA retains ownership over operational governance: statuses, documents, reconciliation, risk decisioning, incidents and provider change management remain within DARCA’s control perimeter.
| Perimeter | What the partner provides (partner-mode) | What DARCA controls |
|---|---|---|
| Fiat rails | Fiat settlement rails and infrastructure perimeters required to launch Core in the EU through partners | Unified in-app statuses and timeline, operation documents, reconciliation and exception handling, service predictability within SLA |
| Cards issuing and processing | Card issuance and processing, network rules, baseline SLA | Card management UX, limits, basic in-app dispute perimeter, event logs, alerts and escalations |
| KYC/KYB and AML/sanctions | KYC/KYB pipeline and screening in accordance with partner-mode requirements | Orchestration of checks, policy triggers, manual review corridor, decision logs and reproducibility, storage of results for the operational perimeter |
| Custody and on/off-ramp | Custody infrastructure, on-chain operations, on/off-ramp perimeters and SLA for incidents | Address book, protection against network/address errors, confirmation statuses, withdrawal limits and policy, hold/step-up, reason log and traceability |
| Data and portability | Access to data and logs under the agreement and applicable requirements | Unified operational log, export and archiving of critical data, data portability requirements and migration scenario, readiness for provider switching |
Info
In Phase 1, provider terms and compatibility across key perimeters are assessed in parallel - without fixing final combinations before agreement on commercial and compliance requirements. For EUR rails and accounts, Circle Internet Financial Europe, Newrails, and Fiat Republic are considered. For custody - Fireblocks, BitGo, Copper. For KYC - Sumsub, Onfido, Jumio.
Commercial guardrails of partner-mode in Phase 1 are aimed at runway protection and unit economics governance:
- no large fixed minimum at the start as a principle of partner selection in Seed
- transparent fee schedule by cost type (payment operations, KYC, cards, custody, FX) to forecast burn and control deviations
- SLA and allocation of responsibilities for incidents, freezes, chargebacks and compliance actions
- guardrails for tariff and term revisions - procedure, notice periods, change management rules
Portability in Phase 1 is defined as both a technical and contractual principle:
- integrations are designed through adapters and separation of business logic and provider layer to reduce vendor lock-in
- data portability and access to critical logs and screening results are ensured as a condition for operational control and migration readiness
- exit scenario and transition period are structured so that provider switching does not result in product interruption

Guardrails against partner lock-in
Partner-mode in Phase 1 is built with predefined portability: portability by design, fallback scenarios, and contractual must-haves reduce dependency risk on a specific provider.
Partner-mode in Phase 1 does not mean dependency on specific providers. The risk of lock-in is mitigated through a combination of portability by design, predefined fallback scenarios and mandatory contractual terms.
Portability by design
- export requirements: operations, statuses, timeline, documents/statements, event logs and screening results within available rights
- data ownership and operational logs remain within DARCA’s perimeter, data must be available for internal analytics, reconciliation, and audit
- regular exports and storage within DARCA so that reconciliations and investigations do not depend on one-off provider requests
- unified object identifiers (operations, checks, incidents) for traceability and migration without loss of linkage
Fallback plan
- predefined switching scenarios for each partner perimeter (rails, cards, KYC, custody) with clear triggers and decision-making order
- temporary regimes during provider replacement:
- tightening of limits on specific operations
- hold for new or anomalous transactions
- step-up checks for critical actions
- geofencing and segmentation by region and user type when required
- the goal of temporary regimes is to preserve security and service predictability during transition without interrupting Core
Contractual must-haves
- SLA for availability and response time, incident escalation, and postmortem practices
- change management: notifications of releases and changes to APIs, rules, tariffs, regression windows and impact control on Core
- right to incident, service quality and dispute case reports, including compliance actions
- termination terms and migration procedure: transfer of data and logs, transition period, and switching support without degradation of critical perimeters
Warning
These guardrails are part of the Phase 1 operating model: without them, partner-mode is not launched, even if the provider covers the required functional perimeter.

Seed Deal Structure without Legal Entities - Process
Seed is structured through a SAFE after agreement on terms: the DARCA management company is registered in Lithuania, the basic corporate package and cap table are established, IP rights and linkage with DevCo are formalized, then the SAFE is issued, the round is closed, and the official Phase 1 operating mode is activated.
At the Seed preparation stage, legal entities are not created in order to avoid premature overhead. The investment follows standard logic: first SAFE terms are agreed, then the DARCA management company in Lithuania is created as a single point of ownership, governance, and future EU perimeter, after which the SAFE is issued and the round is closed.
Info
The trigger for starting the legal process is agreement on Seed terms with the investor. From this moment, the structure into which the investment is formalized is created, and preparation of transaction documents begins.
Step 1 - agreement on SAFE terms with the investor
- a set of SAFE parameters and base scenarios is fixed:
- valuation cap and discount
- conversion terms at Series A (priced round) through the definition of Qualified Financing
- MFN (if applicable) and pro-rata (if granted)
- principal M&A/liquidation fork at the scenario level without legal detailing in the public text
- a term sheet for Seed is formed and agreed as the basis for subsequent documents and structure registration
Step 2 - registration of the DARCA management company in Lithuania
- a management company in Lithuania is created as:
- a consolidation point for group governance and responsibility perimeters
- a future base for EU compliance and licensing history and governance
- the SAFE issuer instrument
- the IP ownership perimeter for key rights and delivery results
Step 3 - registration of GE DevCo as the Phase 1 engineering hub
- a Georgian development subsidiary (GE DevCo) is created as the primary engineering hub of Phase 1
- DevCo provides delivery capacity and hiring/contracting for Phase 1 while maintaining a governed cost base
- TR DevCo is not a condition for Seed closing and is connected later as an additional hiring market and capacity
Step 4 - basic corporate package and cap table
- the basic corporate package of the management company is formalized:
- charter and corporate documents, authorities, and decision-making procedures
- formalization of ownership and governance structure
- the cap table is formed:
- reflection of the SAFE as an instrument that converts into equity/shares at Series A
- fixation of the conversion principle at the structural level without disclosing figures in the public text before final agreement
Step 5 - IP assignments and contractual linkage between the management company (Lithuania) ←> DevCo
- IP ownership is assigned to the management company in Lithuania:
- rights to key delivery results, source code, documentation, and artifacts
- DevCo performs development under contracts and transfers work results and rights to the management company
- delivery governance principles are formalized to reduce risks of distributed development:
- unified access and security policies
- unified release perimeter and change control
- traceability of artifacts and decisions for governance and future evidence pack
Warning
Ownership of critical rights and delivery results is fixed before scaling hiring. External contractors may reinforce specific tasks, but IP ownership and governance linkage remain with the management company in Lithuania.
Step 6 - issuance of SAFE and round closing
- the SAFE is issued by the DARCA management company in Lithuania under agreed terms
- the round is closed in a standard manner:
- signing of transaction documents
- receipt of funds
- confirmation of closing and activation of budget spending according to Use of funds
Step 7 - start of official Phase 1 operating mode after Seed closing
- the official hiring and scaling mode of Phase 1 is activated under the logic of staged build-up:
- strengthening delivery and operational perimeter for EU go-live
- legal and compliance function in Lithuania as a critical path for the EU
- support is activated from month 12 (hiring + training), without premature inflation of fixed costs
- launch of contractual and operational engagement with partners and providers for EU go-live in partner-mode
flowchart LR
A["Seed terms agreement<br/>SAFE term sheet"] --> B["Registration of DARCA management company<br/>in Lithuania"]
B --> C["Registration of GE DevCo<br/>engineering hub Phase 1"]
C --> D["Base corporate package<br/>and cap table"]
D --> E["IP assignments<br/>and contractual linkage<br/>management company (Lithuania) - DevCo"]
E --> F["SAFE issuance<br/>by the management company (Lithuania)"]
F --> G["Seed closing<br/>signing + funds received"]
G --> H["Official Phase 1 mode<br/>start of hiring and execution<br/>Use of funds"]
![]()
Next Phases and Rounds - Step-up Logic
Subsequent rounds scale DARCA through a clear step-up logic: Phase 2 reduces partner dependency via EU own-license and dual-run, Phase 3 expands the product perimeter and strengthens Business and GTM, Phase 4 unlocks full-scope in the UAE and own launch in the US, and moves the RWA factory into a separate block.
Seed (Phase 1) establishes a provable foundation of governed Core operations in the EU in partner-mode and defines KPI gates for transition. Subsequent priced rounds are structured as a qualitative step-up: each stage reduces regulatory and operational risk and increases business model scalability. Equity parameters for Series A/B/C are presented as target benchmarks.
Series A (Phase 2) - 11 million EUR for 18% (target benchmark)
Phase 2 funds the transition from partner-only mode to own-license Core in the EU and prepares the platform for scaling without product interruption.
- EU own-license Core as the base operating regime in the EU.
- Dual-run migration: parallel operation of partner-mode and own-license regime with sequential flow transition without service shutdown.
- UAE go-live through partners (readiness formed in Block 2 of Phase 1, launch begins in Block 3).
- Significant expansion of functions and team under a higher responsibility level:
- legal+compliance, risk/fraud, financial perimeter and operational processes
- partner integrations and provider management at scale
- product function and delivery ownership across multiple jurisdictions
- GTM and growth tied to retention, subscriptions, and governed CAC
Info
The key outcome of Phase 2 is reduced dependency on partners and increased governance: service quality and risk control, predictable cost base, and readiness for scaling without loss of operational discipline.
Series B (Phase 3) - 30 million EUR for 15% (target benchmark)
Phase 3 funds value and monetization expansion through modules in the EU and scaling of the corporate perimeter.
- Launch of modules in the EU in waves - aligned with compliance, risk and operational perimeter readiness.
- Transition of UAE Core to own-license regime.
- Scaling of the Business layer and GTM:
- roles and control perimeters (RBAC/approvals/audit)
- documents, reconciliations, reporting, and integrations
- support and SLA for the corporate perimeter
- expansion of growth channels and partnerships
Series C (Phase 4) - 115 million EUR for 10% (target benchmark)
Phase 4 funds full-scope expansion in the UAE and own launch in the US, as well as scaling the operating model across multiple major markets.
- Full-scope modules in the UAE as the final level of the regional product perimeter.
- US own-license launch as a separate complex licensing and operational launch program.
- RWA factory is launched in Block 4 as a separate perimeter (excluded from earlier phases).
- Scaling of team and operating model:
- compliance, risk, operations, support, and infrastructure
- governance across multiple jurisdictions and product matrix
- systemic GTM at scale
flowchart LR
P1["Phase 1<br/>Seed - 1.8M EUR (SAFE)<br/>EU Core go-live via partners<br/>KPI gates and evidence pack"] --> A["Series A<br/>11M EUR for 18%<br/>target reference"]
A --> P2["Phase 2<br/>EU own-license Core<br/>Dual-run migration from partners<br/>UAE go-live via partners"]
P2 --> B["Series B<br/>30M EUR for 15%<br/>target reference"]
B --> P3["Phase 3<br/>Modules in the EU in waves<br/>UAE core -> own-license<br/>Business and GTM scaling"]
P3 --> C["Series C<br/>115M EUR for 10%<br/>target reference"]
C --> P4["Phase 4<br/>UAE full-scope modules<br/>US own-license launch<br/>RWA factory in Block 4"]
Step-up for Seed investors - how the “quality” of the next round increases
Phase 1 moves the project from build mode to provable operations of Core in the EU and makes key risks measurable and governable. This increases predictability of the next round and reduces the cost of capital.
- Product and operations:
- EU partner go-live and governed operations
- operation statuses, documents, and reconciliation as a baseline perimeter of correctness control
- Support and service quality:
- in-app support as part of the product
- measurable quality metrics (FCR, CSAT, first response time) and escalation discipline
- Risk governance:
- hold and step-up confirmations as standard risk response
- deny where risk is not accepted, with reason log and traceability
- Readiness for Phase 2:
- dual-run migration architecture and regime switching plan
- provider portability and requirements for data, logs, and documents
- Burn governance:
- engineering hub in Georgia as cost-efficient capacity
- staged strengthening of the governance function in Lithuania without early overhead
End-of-Phase-1 KPI gates form the formal basis for transition to Series A and launch of Phase 2.
![]()
Economics and exits - model scalability and IPO as a scenario
DARCA’s economics are built around subscriptions and transparent overage, while further revenue growth is driven by Business and modules by phases. Scalability is achieved through Core reducing cost-to-serve via statuses, documents, reconciliation, and risk decisioning. Exit options include M&A, growth equity with secondary, and IPO as a scenario upon reaching scale and predictable economics.
How DARCA generates revenue
DARCA is monetized through several streams that activate as the product perimeter and geographies expand. In Phase 1, the primary focus is on Core and the partner regime in the EU, followed by adding own licenses, Business and modules.
| Revenue stream | When activated | Trigger and logic |
|---|---|---|
| Subscriptions and limits | Phase 1+ | Tiers and limits are tied to actual usage. The subscription defines a predictable service and volume framework. |
| Overage (limit exceedance) | Phase 1+ | A fee is charged only for exceeding the tier limit. At higher tiers, overage is lower, turning usage growth into either an upgrade or controlled overage. |
| Business (corporate layer) | Phase 3+ | Monetization through seats, integrations, API/webhooks, and SLA. Account and process growth increases ARPA and retention. |
| Module monetization | Phase 3+ | Modules are activated in waves and monetized as add-ons or as privileges of higher tiers. RWA is moved to Phase 4. |
Info
The key principle is to minimize the conflict of “earning on every transaction”. Usage growth converts into a subscription upgrade or overage for limit exceedance, while platform value growth is driven by Business and modules by phases.
Why the economics scale
Model scalability is driven by the combination of two effects: revenue growth per user as usage increases and reduction of cost-to-serve as Core matures.
-
Revenue growth per user
- Subscription upgrades occur based on practical triggers: growth in transaction volume and frequency, approaching limits, and the need for extended capabilities.
- Overage turns limit exceedance into additional marginal revenue and serves as a bridge to tier upgrade.
- Business and modules add a second monetization layer on top of Core and drive ARPA growth through seats, integrations and expanded usage.
-
Cost-to-serve reduction
- Statuses and the transaction timeline reduce uncertainty and decrease the flow of “where is the money” and “why is the status like this” inquiries.
- Transaction dossier and documents reduce manual investigations and accelerate resolution of incidents and disputes.
- Reconciliation and balance accuracy control reduce the cost of errors and manual reconciliations, increasing predictability of the operational perimeter.
- Risk/compliance decisioning (allow, step-up, hold, deny) reduces losses and incident costs, while the reason log makes decisions traceable.
- In-app support with actions accelerates resolution of typical requests and increases FCR, reducing cost per ticket.
flowchart LR
U["Usage growth<br/>frequency and transaction volume"] --> T["Product triggers<br/>approaching limits<br/>growing needs<br/>Business scenarios"]
T --> S["Subscription upgrade<br/>MRR increases"]
T --> O["Overage on limit exceedance<br/>marginal revenue"]
S --> ARPU["ARPU/ARPA growth<br/>predictable revenue"]
O --> ARPU
M["Core maturity<br/>statuses and timeline<br/>dossier and documents<br/>reconciliation<br/>risk decisioning<br/>in-app support"] --> A["Automation and control<br/>fewer manual operations<br/>faster investigations"]
A --> CTS["Lower cost-to-serve<br/>lower cost per ticket<br/>fewer incidents<br/>less manual reconciliation"]
ARPU --> UNI["Stronger unit economics"]
CTS --> UNI
Note
This logic is tied to the Core architecture: the more transactions pass through a unified perimeter of statuses, documents, and controls, the lower the share of manual investigations and the higher the controllability of quality and risk.
Exits
DARCA considers several exit scenarios, including IPO as a scenario upon reaching scale and predictable economics.
-
Strategic acquisition
- attractive to players that require a regulated perimeter, ready Core fiat+crypto, and operational discipline
- value is formed through provable operations, the risk/compliance layer, the Business perimeter, and the modular Core+Modules architecture
-
Growth equity and secondary
- as growth continues and transition to priced rounds occurs, growth equity deals become possible
- secondary can become a mechanism of partial liquidity at the stage of maturity and sustainable economics
-
IPO as a scenario
- considered upon reaching scale, predictable economics and a mature operating model
- based on transparent monetization of subscriptions and overage, expansion of Business and modules, as well as mature reporting, risk and compliance perimeters
flowchart LR
A["Strategic acquisition<br/>Acquisition by a strategic buyer"] --> B["Growth equity<br/>Growth capital"]
B --> C["Secondary<br/>Partial liquidity"]
C --> D["IPO (scenario)<br/>Public market at scale with predictable economics"]
A --- X["Applicability conditions<br/>- mature Core and operational discipline<br/>- risk/compliance and reporting<br/>- Business layer and scalability"]
D --- Y["Public market requirements<br/>- predictable economics<br/>- mature corporate governance<br/>- scalable operating model"]

Risks and mitigations - Phase 1-2 controllability
Phase 1-2 risks are described as manageable perimeters: for each risk, Phase 1 measures, Phase 2 reinforcement, manifestation signals, and the responsible owner are defined.
Phase 1-2 risk register
| Risk | Phase 1 measure | Phase 2 reinforcement | Signal | Owner |
|---|---|---|---|---|
| Partner dependency and lock-in | Guardrails against lock-in (portability by design, export of data and logs, contractual must-haves, fallback modes) | Dual-run migration and transition to own-license mode without product interruption | SLA deterioration, changes in fee rules, growth of provider restrictions, delays in change requests | CTO + Legal + Integration owner |
| Regulatory requirements and timelines | LT legal+compliance perimeter as the critical path, readiness artifacts (policies, procedures, audit trail, record keeping) | EU Core licensing and expansion of compliance ops under own-license | Increase in partner requirements, regulatory inquiries, blocking remarks on procedures | Legal + AML/Compliance Officer (EU) |
| Fraud/AML and screening quality | KYC/KYB and sanctions screening in partner mode, risk decisioning (allow, step-up, hold, deny) + reason log | Expansion of signals and rules, reduction of manual review, strengthening of case management | Growth of alerts and manual review, increase in disputed cases, complaints about false blocks | Risk/Fraud owner + AML/Compliance Officer (EU) |
| Disputes/chargebacks | Basic dispute perimeter of the card program, runbooks and escalations, statuses and documents for transactions | Dedicated dispute ops, automation of typical cases, strengthening of card risk rules | Growth of chargebacks, increase in resolution time, deterioration of CSAT, growth of losses | Support Lead + Risk/Fraud owner |
| Data/reconciliation and status accuracy | Reconciliation and discrepancy control, idempotency, observability, unified status timeline and transaction dossier | Standardization of data controls under own-license and dual-run, strengthening of SLAs with providers | Increase in discrepancies, “stuck” statuses, growth of manual adjustments, balance incidents | Financial Controller + CTO + DevOps/SRE |
| Cost-to-serve and support | Statuses, documents, and in-app support with actions, staged activation of support from month 12, knowledge base and processes | Scaling support ops, automation of typical requests, strengthening of self-serve | Growth of tickets per user, deterioration of FCR/CSAT, increase in resolution time, escalation overload | Support Lead + Product owner |
| Provider concentration | Portability and data ownership, shortlist of alternatives for critical perimeters, fallback procedures | Multisourcing for critical perimeters, contractual framework for replacement and migration | Release dependency on a single provider, deterioration of SLA predictability, growing counterparty influence on economics | CTO + Legal + Integration owner |
| Geography and sanctions | Geofencing and segment restrictions, sanctions screening by UBO/counterparties, transparency of ownership and source of funds | Expansion of procedures under own-license mode, strengthening of counterparty and transaction monitoring | Growth of EDD requests, changes in partner requirements, increase in compliance rejections | AML/Compliance Officer (EU) + Legal |
| Security and access | Secure SDLC, release and privilege control, access audits, incident procedures, project-based pentests | Expansion of security processes and monitoring, mature IAM and regular audits | Critical security findings, access incidents, growth of compromise attempts, violations of release discipline | DevSecOps + DevOps/SRE |
| Operational incidents and release stability | Observability, alerts, runbooks, incident management, change control and postmortems | Scaling SRE/ops, increasing process maturity, change management in dual-run | Repeated critical incidents, uptime degradation, growth of rollbacks, increase in MTTR | DevOps/SRE + CTO |
mindmap
root((Risk registry Phase 1-2))
Partner dependency & lock-in
Portability by design
Export: data, logs, statuses, docs
Data ownership + reconciliation access
Contract must-have
SLA + incident escalation
Change management + notifications
Termination + migration procedure
Fallback modes
Limits / hold / step-up
Temporary stricter checks
Phase 2 усиление
Dual-run migration
Own-license core
Regulatory requirements & timelines
Phase 1 меры
LT legal+compliance core
Policies + procedures
Audit trail + record keeping
Evidence pack readiness
Phase 2 усиление
EU own-license licensing
Expanded compliance ops
Fraud/AML & screening quality
Phase 1 меры
KYC/KYB + sanctions screening
Risk decisioning
allow
step-up
hold
deny
Reason logging
Phase 2 усиление
More signals + rules
Lower manual review corridor
Case management
Disputes / chargebacks
Phase 1 меры
Card program disputes baseline
Runbooks + escalations
Transparent statuses + documents
Phase 2 усиление
Dedicated dispute ops
Automation of typical cases
Stronger card risk rules
Data / reconciliation & status correctness
Phase 1 меры
Reconciliation discipline
Idempotency
Observability
Unified timeline + operation dossier
Phase 2 усиление
Stronger data controls
Provider SLA tightening
Dual-run data standardization
Cost-to-serve & support
Phase 1 меры
Statuses + docs reduce tickets
In-app support with actions
Support readiness from month 12
Knowledge base + processes
Phase 2 усиление
Support ops scaling
Self-serve automation
Provider concentration
Phase 1 меры
Shortlist alternatives per contour
Portability + fallback procedures
Phase 2 усиление
Multi-sourcing critical contours
Contractual migration framework
Geography & sanctions
Phase 1 меры
Geofencing + segmentation
Screening UBO + counterparties
Ownership & source-of-funds transparency
Phase 2 усиление
Own-license compliance procedures
Enhanced monitoring
Security & access control
Phase 1 меры
Secure SDLC
Release controls
Least privilege + access audits
Incident procedures
Project-based pentests
Phase 2 усиление
Mature IAM
Continuous monitoring
Regular audits
Operational incidents & release stability
Phase 1 меры
Observability + alerts
Runbooks
Incident management + postmortems
Change control
Phase 2 усиление
SRE/ops scaling
Dual-run change governance
Info
The risk register is used as a management tool for Phase 1-2: signals are monitored within the operational cycle, and measures are reinforced during transition to own-license and dual-run mode.
Sanctions and geopolitical risk - baseline facts and controls
Baseline facts:
- The founders and key team members are citizens of Ukraine.
- Previous legal entities and operational structure associated with the MVP in Russia have been closed.
- No activities are conducted in Russia.
- The current DARCA launch is built within a new structure based in Lithuania and without operational dependency on Russia.
Controls:
- KYC/KYB and sanctions screening at the level of UBOs, companies and key counterparties - in accordance with partner requirements and the applicable EU regime.
- Transparency of ownership structure and source of funds - as part of compliance readiness perimeters and counterparty operations.
- Geofencing and segment restrictions by countries and user types - in line with partner requirements and the compliance framework.
- Record keeping and audit trail for transactions and risk/compliance decisioning.
- Compliance with partner requirements and applicable EU regulatory regimes - at the level of procedures, controls and reporting.

Сценарии less - base - more
Сценарии описывают, как меняется темп и глубина контроля Phase 1 при разном объеме привлеченного капитала - без изменения утвержденного периметра Phase 1.
Base - ровно €1.8 млн
Base-сценарий выполняет Phase 1 полностью в заявленной рамке:
- EU Core go-live в partner-mode и управляемая эксплуатация Core.
- Достижение KPI-гейтов Phase 1 и формирование readiness к Phase 2 (own-license + dual-run design).
Less - привлекли меньше
Less-сценарий означает старт Phase 1 в reduced burn и более низком темпе, с сохранением критического пути и операционной доказуемости. Недостающий капитал добирается параллельно, при этом выполнение Phase 1 не строится на обещании добора как на обязательном условии.
Неприкосновенно (критический путь):
- EU Core go-live в partner-mode.
- Операционная доказуемость Core: статусы и таймлайн, документы, reconciliation, risk decisioning и журнал причин.
- Базовый контур надежности: observability, runbooks, инцидент-менеджмент и эскалации - на уровне, который не компрометирует KPI-гейты.
Меняется темп и глубина параллельных активностей:
- Найм и расширение функций включаются стадийно - по вехам, с меньшей параллельностью работ.
- Вторичные интеграции и улучшения, не влияющие на go-live, переносятся позже по фазе.
- External legal/security активности применяются точечно по критичным вехам, без расширенных пакетов “на вырост”.
- GTM остается в режиме minimal PLG без ускорения paid-активностей.
More - привлекли больше
More-сценарий конвертирует дополнительный капитал в ускорение и снижение рисков Phase 1 - без расширения утвержденного scope.
Ускоряется без изменения периметра Phase 1:
- QA и релизная дисциплина: больше автоматизации, e2e покрытие критичных money flows, быстрее регресс и меньше риск регрессов.
- Security cadence: пентесты и аудит контуров по более плотному циклу, быстрее закрытие findings.
- Скорость интеграций и надежность контуров: резервирование, наблюдаемость, инцидентные процессы, повышение предсказуемости статусов и reconciliation.
- Углубление dual-run readiness в рамках Phase 1: дизайн миграции, portability, требования к own-license режиму, подготовка планов переключений.

Information package and deal process
This section defines which materials are available immediately, how the legal preparation process is structured after SAFE approval, and the reporting cadence maintained after Seed closing.
Information package
- White Paper and key sections: product, roadmap, compliance, team, business model, functionality, marketing.
- Materials on key scenarios and operations (if available):
- descriptions of money flows and transaction statuses
- examples of documents/statements and the logic of the transaction dossier
- materials on support and escalations (in-app, without calls)
- Brief framework of the group structure post-invest:
- managing company in Lithuania as the governance perimeter and future base for the EU regime
- engineering hub in Georgia
- connection of Turkey later as an additional hiring market and capacity
Info
The information package is intended to validate product logic, the operating model, and consistency of phase plans - without disclosing partner names and contract terms prior to finalization of commercial frameworks.
Legal preparation
- Registration of the DARCA managing company in Lithuania.
- Preparation of the basic corporate package and cap table (minimum required for SAFE issuance).
- IP assignments and contractual linkage between the managing company and DevCo prior to scaling hiring:
- work results and key rights are assigned to the managing company
- DevCo performs delivery under agreements with transfer of rights and results
- Registration of GE DevCo (Phase 1 engineering perimeter).
- TR DevCo is connected later according to the capacity expansion plan (without impact on the EU licensing perimeter).
Deal process
- Agreement on SAFE terms (cap, discount and base conditions).
- Access to the information package and its review.
- Registration of the managing company in Lithuania and preparation of corporate documents.
- Signing of IP assignments and contractual linkage between the managing company and DevCo.
- SAFE issuance by the managing company and Seed closing.
- Transition to the official execution mode of Phase 1 and team expansion according to the approved phasing.
Reporting after Seed closing
- Progress on Phase 1 KPI gates - status by clusters (growth/activity, reliability, support, risk/compliance, monetization readiness).
- Reporting on use of funds - by expense buckets with explanation of deviations and management decisions.
- Control of scope and key changes - what changes, why, and how it impacts runway and KPI gates.
- Management cadence:
- 3-month rolling plan of work and milestones
- monthly plan and report on execution and expenses
- quarterly checkpoints on Phase 1 KPI gates

Final linkage
Seed via SAFE finances Phase 1 as a managed transition toward EU Core partner launch, KPI gates, and Series A readiness, with control over scope, costs, and operational quality.
Info
Phase 1 establishes a measurable outcome: Core in the EU in partner-mode + controlled operations + KPI gates and an evidence pack as the foundation for Series A (own-license Core and dual-run migration).
- What Seed finances - Phase 1 for 24 months (Block 1 = 15, Block 2 = 9) to launch Core in the EU through partners and bring operations to a bank-grade level: statuses and timeline, documents and statements, reconciliation, risk/compliance decisioning, support as part of the product.
- Why the next round becomes fundamentally different - Phase 1 removes key classes of risk (production mode, operational controllability, quality and risk control) and forms readiness for Phase 2: EU own-license Core and dual-run migration without product interruption, plus UAE go-live through partners.
- Why a 24-month runway is realistic - Phase 1 remains within a Core-only scope and is built through management discipline: staged build-up of functions and expenses by milestones (including support activation from month 12), project-based procurement for legal and security, partner guardrails without large fixed minimums, reserve based on predefined triggers and a regular governance cycle.
- Why the group structure supports speed and control - the legal and compliance perimeter and management consolidation in Lithuania create the foundation for EU licensing and presence history, the engineering hub in Georgia provides cost-efficient capacity for Phase 1 delivery, and Turkey is connected later as an additional hiring market without affecting the EU licensing perimeter.
- How the economics scale - subscriptions + overage + Business and modules by phases increase revenue per user, while Core maturity (statuses, documents, automation, risk decisioning) reduces cost-to-serve and incident costs.
- Break-even within 30-36 months is embedded into the phase trajectory and does not depend on early Phase 1 revenue - early revenue is treated as a buffer rather than a condition for plan execution.
- Exits include strategic scenarios, growth equity and secondary, as well as IPO as a scenario upon reaching scale and predictable economics.
Phase 1 transforms DARCA into a measurably operating EU Core with controlled operations and an evidence base, making the transition to Series A a logical continuation of the trajectory rather than an expansion of scope without control.