© Кагиров Абдул-Хаким Ахмадович, 2026. Все права защищены. Watermark · © Kagirov A-Kh. A. · 2026 · ALL RIGHTS RESERVED · Universal Copyright Convention, Geneva 1952

ТЕХНИЧЕСКАЯ АРХИТЕКТУРА

Платформа «Ноев Ковчег» · Software Architecture Document (SAD)

Документ № NK-ARCH-001/2026 Дата: 1 мая 2026 г. Тип документа: Software Architecture Document (SAD), уровень C4 + детализация подсистем Применимое право: Закон РА HO-159-N + Регламенты ЦБ РА 7/01–7/05; Закон РА «О защите персональных данных»; стандарты ISO/IEC 27001, IFRS

Автор и правообладатель: Кагиров Абдул-Хаким Ахмадович (Аслан Каа) www.aslankaa.com · aslankaa@yandex.ru / aslankaa@yandex.ru · +7 (969) 795-55-55 / +7 (925) 203-77-77 Telegram @aslan_kaa · Instagram @aslan_kaa · VK id453725994 · Facebook aslan.kaa · X @aslanofff

EXECUTIVE SUMMARY

Техническая архитектура Платформы «Ноев Ковчег» построена по принципу defense-in-depth с гибридной облачной топологией (primary EU-Frankfurt + secondary Yerevan + edge в диаспоральных хабах), permissioned DLT с регуляторной нодой Центрального банка РА, multi-signature кастоди на HSM уровня FIPS 140-2 Level 3, и полным мэппингом всех архитектурных решений на статьи Закона HO-159-N и Регламентов ЦБ РА.

Ключевые архитектурные решения:

1. DLT-слой: Polygon PoS (EVM-совместимый, низкие gas costs, зрелое сообщество, регуляторные ноды поддерживаются);
2. Гибридное облако: primary AWS Frankfurt + secondary Hetzner Yerevan + Cloudflare edge;
3. Кастоди: Multi-sig 3-of-5 (CEO + CTO + CFO + CCO + Independent Trustee) с HSM AWS CloudHSM или Thales Luna;
4. Mobile-first: PWA для Фазы 1, опциональные нативные приложения для Фазы 2;
5. Регуляторный доступ: ЦБ РА получает read-only ноду с полным доступом к составу пула в режиме реального времени;
6. Безопасность: ISO/IEC 27001 + GDPR + Закон РА «О защите персональных данных» + минимум 2 независимых аудита смарт-контрактов;
7. Observability: Prometheus + Grafana + Loki + Tempo с SLO 99.9% read / 99.5% write availability.

1. C4-ДИАГРАММЫ АРХИТЕКТУРЫ

1.1 Уровень 1 — System Context

                        ┌───────────────────────┐
                        │  ПЛАТФОРМА             │
                        │  «НОЕВ КОВЧЕГ»         │
                        │  (CASP-оператор +      │
                        │   эмитент токенов)     │
                        └─────────┬─────────────┘
                                  │
   ┌───────┬───────┬──────────────┼──────────────┬───────┬───────┐
   ▼       ▼       ▼              ▼              ▼       ▼       ▼
┌──────┐ ┌──────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ ┌──────┐ ┌──────────┐
│Собст-│ │Инвес-│ │Государ-  │ │ЦБ РА     │ │Страхо- │ │Оце- │ │Распреде- │
│венник│ │тор   │ │ство РА   │ │(надзор + │ │вщик    │ │нщик │ │лённый    │
│ (физ │ │ (3   │ │(Минфин,  │ │ regula-  │ │(армян- │ │(ли- │ │реестр    │
│ /юр) │ │ типа)│ │ Казна-   │ │ tory     │ │ ский)  │ │цен- │ │(Polygon) │
│      │ │      │ │ чейство) │ │ node)    │ │        │ │ зир.│ │          │
└──────┘ └──────┘ └──────────┘ └──────────┘ └────────┘ └──────┘ └──────────┘
   │       │           │            │           │         │           │
   │ KYC,  │ Покупка   │ Получает   │Подаёт     │Страхует │Оценива- │  On-chain
   │ депо- │ траншей,  │ деньги,    │whitepaper,│активы и │ет ак-   │  состояние
   │ зит   │ покупка   │ финанси-   │отчёты по  │CFA, вы- │тивы пе- │  пула,
   │ актива│ ART       │ рует       │соответ-   │плачивает│ред      │  токенов,
   │       │           │ нац.про-   │ствию      │при стра-│включе-  │  транзакций
   │       │           │ екты       │HO-159-N   │ховых    │нием в   │
   │       │           │            │           │случаях  │пул      │

1.2 Уровень 2 — Container Diagram

                          ┌────────────────────────────────────┐
                          │     ПЛАТФОРМА «НОЕВ КОВЧЕГ»         │
                          │           (внутри границы)          │
                          └────────────────────────────────────┘

User-facing                  Application                  Data &
Containers                   Services                     Storage
─────────────                ────────────                 ────────────
┌─────────────┐              ┌─────────────┐              ┌──────────────┐
│ Web App     │ ◄──HTTPS────►│ API Gateway │ ◄──gRPC─────►│ PostgreSQL   │
│ (PWA, RU/   │              │ (Kong /     │              │ (registry,   │
│  EN/HY)     │              │  Tyk)       │              │  metadata)   │
└─────────────┘              └─────┬───────┘              └──────────────┘
                                   │
┌─────────────┐                    │                      ┌──────────────┐
│ Mobile App  │                    ├─►Identity Service◄──►│ KYC Vault    │
│ (PWA + Phase│                    │  (Auth0/Keycloak +   │ (encrypted   │
│  2 native)  │                    │  Armenian nID)       │  isolated)   │
└─────────────┘                    │                      └──────────────┘
                                   │
┌─────────────┐                    │                      ┌──────────────┐
│ Admin Panel │                    ├─►Pool Service       ►│ Asset Registry│
│ (CASP оп-   │                    │  (CRUD пула,         │ (PostgreSQL  │
│  ераторов)  │                    │  переоценки)         │  + IPFS docs)│
└─────────────┘                    │                      └──────────────┘
                                   │
┌─────────────┐                    │                      ┌──────────────┐
│ Investor    │                    ├─►Order Service      ►│ Tx Ledger    │
│ Dashboard   │                    │  (issuance, tra-     │ (ClickHouse  │
│             │                    │  ding, redemption)   │  for analyt.)│
└─────────────┘                    │                      └──────────────┘
                                   │
┌─────────────┐                    │                      ┌──────────────┐
│ Regulator   │                    ├─►Smart Contract      ►│ DLT Layer   │
│ Portal      │ ◄══════════════════│  Bridge              │ (Polygon PoS │
│ (CB RA)     │   Read-only        │  (gas mgmt, oracle   │  + private   │
│             │   node access      │   adapter)           │  RPC)        │
└─────────────┘                    │                      └──────────────┘
                                   │
                                   ├─►Insurance Bridge   ─►External APIs
                                   │  (CCI, VPI, FM)       (Insurer)
                                   │
                                   ├─►Payment Service    ─►External APIs
                                   │  (AMD/EUR/USD,        (Bank-partner)
                                   │   crypto on-ramp)
                                   │
                                   ├─►Notification Svc   ─►External
                                   │  (email, Telegram,    (SendGrid,
                                   │   SMS, push)          Twilio, FCM)
                                   │
                                   └─►Audit Log Service ──►Immutable
                                      (all actions)        (S3 + IPFS hash)

1.3 Уровень 3 — Component Diagrams (3 ключевые подсистемы)

1.3.1 Smart Contract Bridge (компоненты)

Smart Contract Bridge
├── Transaction Builder
│   ├── CFA1 mint/burn requests
│   ├── Senior tranche operations
│   └── Junior ART operations
├── Gas Manager
│   ├── Gas price oracle
│   ├── EIP-1559 optimization
│   └── Reserve gas wallets
├── Oracle Adapter
│   ├── Pool NAV oracle (off-chain → on-chain)
│   ├── Asset valuation oracle
│   └── Insurance status oracle
├── Multi-sig Coordinator
│   ├── Signature aggregator
│   ├── Approval workflow (3-of-5)
│   └── Time-locked operations
└── Event Listener
    ├── On-chain event subscription
    ├── Event normalization
    └── Downstream notifications

1.3.2 Pool Service (компоненты)

Pool Service
├── Asset Onboarding
│   ├── Document verification (Кадастр РА API)
│   ├── Encumbrance registration
│   └── Title insurance integration
├── Valuation Engine
│   ├── Quarterly valuation orchestrator
│   ├── Appraiser selection (rotation)
│   ├── Multi-source price aggregation
│   └── IFRS 13 compliance check
├── NAV Calculator
│   ├── Pool NAV computation (real-time)
│   ├── Per-token NAV (Junior ART)
│   └── Historical NAV series
├── Owner Coupon Manager
│   ├── Monthly coupon scheduler
│   ├── Drachma payment integration
│   └── Tax compensation calculator
├── Pool Health Monitor
│   ├── Concentration limits checker
│   ├── Geographic diversification
│   └── Anomaly detection
└── Insurance Coordinator
    ├── CCI status tracking
    ├── VPI activation logic
    └── Claim coordination

1.3.3 Payment Service (компоненты)

Payment Service
├── Fiat On-Ramp / Off-Ramp
│   ├── Bank-partner integration (RA bank)
│   ├── SWIFT settlements
│   ├── AMD/EUR/USD FX execution
│   └── PSD2-style strong customer auth
├── Crypto Settlement
│   ├── USDC, USDT, BTC, ETH acceptance
│   ├── Conversion via licensed counterparty
│   └── On-chain finality verification
├── Coupon Distribution
│   ├── Senior tranche quarterly coupons (escrow → holders)
│   ├── Owner monthly coupons (Платформа → собственник AMD)
│   └── End-of-cycle bonus distribution
├── Redemption Processor
│   ├── Senior tranche maturity buyback
│   ├── Junior ART NAV-based redemption
│   └── Quarterly limit enforcement (25%)
└── Reconciliation Engine
    ├── Daily reconciliation (banks ↔ ledger)
    ├── On-chain ↔ off-chain sync
    └── Discrepancy alerting

1.4 Уровень 4 — Code-level mapping для критичных частей

Реализация конкретных функций на уровне кода будет описана в технических спецификациях отдельных компонентов на стадии разработки. На уровне SAD достаточно описать критические code-paths, требующие особого внимания при реализации:

2. ВЫБОР DLT-СЛОЯ

2.1 Сравнительная матрица

2.2 Рекомендация

Polygon PoS выбран как основная DLT-платформа Фазы 1 на основании следующих факторов:

1. EVM-совместимость даёт доступ к крупнейшей экосистеме wallet, custody, audit инструментов;
2. Низкие gas costs позволяют делать частые операции (купоны, переоценки) экономически целесообразными;
3. Активное сообщество разработки и аудита смарт-контрактов — снижение технических рисков;
4. Совместимость с регуляторными нодами через middleware (Tenderly, Blockscout, internal indexer);
5. MiCA-готовность — Polygon Labs ведёт активный диалог с ESMA и MiCA-регуляторами ЕС;
6. Bridge к Ethereum L1 — возможность миграции в будущем без потери ликвидности.

2.3 Альтернатива и план миграции

В случае возникновения регуляторных проблем с Polygon PoS, план миграции: - Альтернатива 1: Polygon zkEVM (полная Ethereum-совместимость с zk-доказательствами); - Альтернатива 2: Hyperledger Besu в private deployment (полностью permissioned EVM-сеть для критичных операций); - Альтернатива 3: Avalanche Subnet (custom permissioned с EVM).

Архитектура сделана DLT-agnostic на уровне Smart Contract Bridge — миграция возможна без переписывания application layer.

2.4 Регуляторная нода ЦБ РА

ЦБ РА получает специализированную ноду с: - Read-only доступом ко всем транзакциям, состоянию пула, NAV; - API для запросов — состав пула в любой момент времени, история переоценок, AML-флаги; - Push-уведомлениями о существенных событиях (новый выпуск, выкуп, изменение NAV >10%); - Технической поддержкой 24/7 со стороны Платформы.

Архитектура ноды:

[ЦБ РА datacenter] → VPN → [Polygon RPC node, hosted by Платформа]
                                    │
                                    ↓
                              [Reader-only API:
                                  - GraphQL queries
                                  - Webhook subscriptions
                                  - CSV/JSON exports]

3. СПЕЦИФИКАЦИЯ СМАРТ-КОНТРАКТОВ

3.1 CFA1Token

Назначение: Soulbound utility-токен, представляющий долю собственника недвижимости в пуле.

Тип: ERC-5192 (Minimal Soulbound NFT, EIP-final) на базе ERC-721-стиля идентификатора. Стандарт ERC-5192 закрепляет non-transferable семантику через флаг locked(tokenId) и встроен в аудиторские чеклисты OpenZeppelin Contracts v5.x. Соулбундность через revert в _beforeTokenTransfer явно не используется — стандартный путь упрощает Trail of Bits / OpenZeppelin audit.

Связь с собственником: актив привязан к собственнику криптографически (CFA1 = адрес собственника + cadastreReference + assetValueAMD) и не может торговаться даже через прокси / wrapping — обёрточные ERC-20 поверх CFA1 не выпускаются регуляторной политикой Платформы.

Состояние: - mapping(uint256 => address) ownerOf — собственник CFA1 - mapping(uint256 => uint256) assetValueAMD — оценочная стоимость актива в драмах - mapping(uint256 => uint256) pledgeStartTimestamp — момент пледжирования - mapping(uint256 => uint256) pledgeEndTimestamp — момент возврата (плановый) - mapping(uint256 => bytes32) cadastreReference — ссылка на запись в Кадастре РА - mapping(uint256 => uint256) lastCouponPaid — последний выплаченный купон - mapping(uint256 => bool) isInsured — наличие страховки

Функции (только администратор Pool Escrow): - mint(address owner, uint256 valueAMD, bytes32 cadastreRef, uint256 cycleDuration) — создаёт CFA1 - burn(uint256 tokenId) — уничтожает CFA1 при возврате актива и снятии обременения - recordCouponPayment(uint256 tokenId, uint256 amount) — фиксирует выплату купона

Ограничения: - transferFrom() — DISABLED (soulbound) - safeTransferFrom() — DISABLED - Только Pool Escrow contract может вызывать mint/burn

Upgradability: UUPS proxy (Universal Upgradeable Proxy Standard) с time-lock 7 дней + multi-sig 3-of-5.

3.2 SeniorTrancheBond

Назначение: Старший долговой токен (security wrapper) с купонными выплатами и графиком погашения.

Тип: ERC-3643 (T-REX) — security token standard со встроенным compliance-уровнем (whitelist, transfer restrictions, freeze, identity binding через OnchainID). Решение в пользу T-REX (а не ERC-1400) обосновано: 1. T-REX — production-проверенный стандарт (Tokeny Solutions), MiCA-aligned, используемый в EU regulated tokenization. 2. ERC-1400 остаётся draft, не утверждённым Ethereum Foundation; аудиторы менее уверены в нём. 3. T-REX встраивает OnchainID — это снимает identity/KYC binding на уровне токена и упрощает Travel Rule maintenance.

Состояние: - mapping(address => uint256) balanceOf — балансы держателей - mapping(address => bool) whitelisted — список allowed инвесторов (KYC-passed) - uint256 totalSupply — выпущенное количество (70 000) - uint256 nominalValueEUR — номинал (€1 000) - uint256 couponBPS — купон в базисных пунктах (550 = 5.5%) - uint256 issueDate — дата выпуска - uint256 maturityDate — дата погашения (issueDate + 7 лет) - uint256[] couponPaymentDates — даты квартальных купонов (28 дат) - mapping(address => uint256) lastClaimedCoupon — индекс последнего полученного купона

Функции: - issueToWhitelistedHolder(address holder, uint256 amount) — выпуск whitelisted инвестору - transfer(address to, uint256 amount) — только между whitelisted адресами - claimCoupon(uint256 paymentIndex) — клейм купона держателем - claimMaturity() — клейм тела долга после maturity - executeBudgetGuarantee(bytes calldata proof) — активация бюджетной гарантии Минфина РА (только трасти)

Compliance hooks: - beforeTransfer() — проверка whitelist, отсутствие санкций - afterTransfer() — emit event для регуляторной ноды

Upgradability: UUPS proxy с time-lock 14 дней (более длительный из-за security-критичности).

3.3 JuniorTrancheART

Назначение: Младший asset-referenced token, привязанный к NAV пула.

Тип: ERC-20 fixed-supply (300 000, immutable post-issuance) + external NAVOracle contract. Rebase-подход явно отвергнут. Причины: - rebase меняет supply каждого холдера и создаёт UX-катастрофу с custody-провайдерами, налоговыми отчётами (ФНС РФ, EU-юрисдикции диаспоры), DeFi-интеграциями. - В production-практике 2026 ни один regulated ART/stablecoin-оператор не использует rebase (Maple Finance, Centrifuge, Ondo — все price-oracle). - Audit trail и manipulation risk легче контролируются на уровне внешнего NAVOracle (см. §3.7) без вмешательства в supply.

Состояние: - mapping(address => uint256) balanceOf - uint256 totalSupply (300 000 на старте) - uint256 nominalValueEUR (€100 первоначально) - address oracleAdapter — адрес OracleAdapter contract - uint256 lastNAVUpdate — timestamp последнего обновления NAV - uint256 currentNAVPerToken — текущий NAV per token - uint256 redemptionLimitQuarterlyBPS — квартальный лимит выкупа (2500 = 25%) - mapping(uint256 => uint256) quarterlyRedemptions — учёт выкупов по кварталам

Функции: - issueAtNAV(address holder, uint256 amount) — выпуск на основе текущего NAV - redeem(uint256 amount) — выкуп держателем по NAV (с лагом 30 дней, лимит проверяется) - forceRedeem(uint256 amount) — выкуп эмитентом (с уведомлением 90 дней) - updateNAV(uint256 newNAVPerToken) — обновление NAV (только Oracle Adapter) - getCurrentNAV() — публичный getter

Защита от manipulation: - NAV обновляется не чаще 1 раза в день; - Изменение NAV >10% за один update требует подтверждения 3 независимых оракулов; - Time-weighted average используется для крупных выкупов (>€100 000).

Upgradability: UUPS proxy с time-lock 14 дней.

3.4 PoolEscrow

Назначение: Кастоди пула CFA1 с multi-sig 3-of-5.

Тип: Multi-signature wallet с ролевой моделью.

Состав подписантов (2 internal + 3 external): 1. CEO Платформы (internal) — операционный signer. 2. CTO Платформы (internal) — технический signer. 3. Партнёр армянской юрфирмы (external) — независимый legal trustee, регулируемая адвокатская фирма из топ-5 РА. 4. EU-based custody trustee (external) — институциональный escrow agent в EU-юрисдикции (Люксембург / Лихтенштейн). 5. ЦБ РА nominee — отдельный read-only ключ, не входит в signing-threshold (иначе создаётся conflict с надзорной функцией; ЦБ остаётся supervisor, не co-issuer).

Геогр. распределение: 2 ключа Yerevan + 1 EU + 1 RA-юрфирма (отдельный офис) + 1 read-only. Это снимает риск state-pressure-concentration и совпадает с industry standard (Coinbase Custody, BitGo).

Состояние: - address[5] signers — 5 обязательных подписантов (4 signing + 1 read-only nominee) - uint256 threshold — 3 (3-of-5 среди signing keys) - mapping(bytes32 => uint8) approvals — счётчик подписей по operationHash - mapping(uint256 => address) cfaInPool — CFA1, находящиеся в пуле - address insuranceBridge - address poolService — application layer, может предлагать операции (но не исполнять)

Функции: - proposeOperation(bytes32 opHash, OperationType opType, bytes calldata data) — предложение операции - approveOperation(bytes32 opHash) — одобрение signer’ом - executeOperation(bytes32 opHash) — исполнение при достижении threshold - addCFA1(uint256 tokenId) — включение CFA1 в пул (требует multi-sig) - removeCFA1(uint256 tokenId) — извлечение CFA1 при возврате (требует multi-sig) - triggerInsurance(InsuranceType type, uint256 amount) — обращение к страховщику

Time-lock: 24 часа для крупных операций (стоимость >€1M); мгновенное исполнение для рутинных.

3.5 InsuranceBridge

Назначение: Мост между смарт-контрактами и страховщиками (CCI, VPI, Force-Majeure).

Тип: Адаптер с off-chain интеграцией.

Функции: - submitClaim(InsuranceType type, uint256 amount, bytes calldata evidence) — подача страхового требования - recordPayout(bytes32 claimId, uint256 amount, bytes calldata signature) — фиксация выплаты страховщиком - checkCoverageActive(uint256 tokenId) — проверка активного покрытия

Особенности: Off-chain верификация события силами страховщика; on-chain запись финального результата для прозрачности.

3.6 GovernanceContract

Назначение: Голосование держателей по существенным решениям.

Тип: OpenZeppelin Governor + Bravo расширения.

Функции: - propose(targets[], values[], calldatas[], description) — создание proposal - castVote(proposalId, support) — голосование - execute(proposalId, ...) — исполнение прошедшего proposal

Voting power: - Senior tranche holders: 1 token = 1 vote (по вопросам, относящимся к Senior); - Junior tranche holders: 1 token = 1 vote (по вопросам, относящимся к Junior); - Cross-tranche вопросы: weighted (€-equivalent).

Quorum: 30% от общего количества выпущенных токенов соответствующей категории.

3.7 OracleAdapter (NAV Oracle, P3 patent)

Назначение: Получение независимых оценок NAV и иных off-chain данных. Это самое чувствительное звено архитектуры — single point of failure для manipulation, поэтому стек формализован.

Тип: Hybrid pipeline на базе Chainlink Functions (aggregator) + EIP-712 signed attestations.

Источники данных (минимум 3 лицензированных оценщика РА): 1. Ameriabank Property Valuation Department — банковский оценщик с регулируемой методологией. 2. Оценщик, аффилированный с государственным Кадастром РА — доступ к первичным cadastre data. 3. Independent member of RA Self-Regulated Organization of Appraisers — независимая ротация (не та же фирма >2 кварталов подряд).

При spread > 5% между оценщиками — auto-request 4-го мнения; при spread > 10% — manual review через multi-sig 3-of-5.

Off-chain attestation flow:

Licensed appraiser → формирует {timestamp, navPerToken, evidence_hash, cadastreRefs[]}
   └─ EIP-712 typed-data signature
        └─ Upload report + supporting docs → IPFS (CID stored)
             └─ Sign hash via reputation contract (стейк AMD под slashing
                за false attestations верифицируется через регулятор)

On-chain aggregation:

Chainlink Functions (off-chain compute):
   └─ Median of 3 attestations + outlier rejection
        └─ commitNAV(median, attestations[]) в NAVOracle contract
             └─ **Time-lock 48 hours** для всех NAV updates
                  (любой holder может оспорить через GovernanceContract)
                  └─ После 48h: JuniorTrancheART.updateNAV(median)
                       └─ Time-weighted average over 7-day window
                          для крупных redemptions (>€100k)

Функции контракта: - requestNAVUpdate() — инициирует quarterly cycle - submitAttestation(bytes32 requestId, uint256 nav, bytes32 ipfsCID, bytes signature) — приём EIP-712 от оценщика - aggregateAndCommit() — median + outlier rejection + commit с 48h time-lock - disputeNAV(uint256 commitId, bytes evidence) — диспут в течение 48h окна - executeCommittedNAV(uint256 commitId) — финальный commit в JuniorTrancheART после lock

Защита: - Минимум 3 независимых оценщика РА (rotation policy). - Median-based агрегация (защита от outliers). - EIP-712 криптоподписи верифицируются on-chain. - IPFS-evidence для каждой attestation (cryptographic audit trail). - Reputation contract со slashing (AMD-стейк оценщика). - 48-hour time-lock на любое NAV update (dispute window). - Multi-sig 3-of-5 override для emergency NAV с публичным justification.

Audit trail для регулятора: ЦБ РА получает доступ ко всем updateNAV events on-chain + IPFS-attestations + reputation state. Каждое обновление сопровождается публичным cryptographic proof (EIP-712 signatures от 3 оценщиков + median computation log).

Fallback при oracle downtime: - Last known NAV держится 7 дней. - После 7 дней — auto-pause redemptions (защита от stale-price arbitrage). - Multi-sig 3-of-5 может force-commit emergency NAV.

3.8 Аудит смарт-контрактов

Все смарт-контракты подлежат двум независимым аудитам в параллель + pre-audit consulting + bug bounty:

Tech-budget Year-1 (полная сумма, не только аудит): $2.56M — см. §3.9.

3.9 Year-1 Tech Budget (детализация)

Year-2 steady-state tech OpEx (после Series A): $1.8–2.2M/год — расширение команды до 15 FTE, recurring audits, insurance renewal, cloud scale, bug-bounty pool growth.

4. ИНФРАСТРУКТУРА И ОБЛАКО

4.1 Гибридная архитектура

                     [Cloudflare Edge — global CDN + DDoS]
                               │
                ┌──────────────┴──────────────┐
                │                             │
                ▼                             ▼
   ┌────────────────────────┐    ┌────────────────────────┐
   │  PRIMARY               │    │  SECONDARY              │
   │  AWS Frankfurt (eu-     │    │  Hetzner Yerevan       │
   │  central-1)            │◄══►│  (или Cloud4Y Yerevan) │
   │                        │ DR │                        │
   │  - Application layer   │ ↔  │  - DR replica          │
   │  - Web/Mobile API      │    │  - Узел регулятора     │
   │  - Business logic      │    │  - Данные резидентов РА│
   │  - Smart contract      │    │                        │
   │    bridge              │    │                        │
   │  - DLT RPC nodes       │    │                        │
   │  - Database primary    │    │                        │

   └────────────────────────┘    └────────────────────────┘
                │                             │
                └──────────┬──────────────────┘
                           │
                           ▼
                ┌──────────────────────┐
                │  EDGE PRESENCE        │
                │  Cloudflare Workers:   │
                │  - Moscow (RU diaspora)│
                │  - Los Angeles         │
                │  - Paris               │
                │  - Beirut              │
                │  - Berlin              │
                └──────────────────────┘

4.2 Логика data residency

4.3 BCP / DR (Business Continuity / Disaster Recovery)

4.4 Stack технологий

5. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ

5.1 Compliance мэппинг

5.2 Многоуровневая защита

Слой 1: Edge (Cloudflare WAF, DDoS protection, bot mitigation)
   ↓
Слой 2: API Gateway (rate limiting, input validation, auth)
   ↓
Слой 3: Application (RBAC, OAuth 2.0, JWT, signed requests)
   ↓
Слой 4: Service mesh (mTLS между микросервисами)
   ↓
Слой 5: Data layer (encryption at rest, столбцовое шифрование PII)
   ↓
Слой 6: Network (private subnets, security groups, NACLs)
   ↓
Слой 7: Audit (immutable logs, SIEM мониторинг)

5.3 Управление приватными ключами

HSM-стек, фазированный подход:

Hot / Warm / Cold ratio (по industry standard Coinbase Custody / BitGo): - Cold (HSM-protected, multi-sig 3-of-5, offline, geographically distributed) — 90% TVL, time-lock 24h. - Warm (HSM-protected, multi-sig 3-of-5, online) — 8% TVL, quarterly coupons, redemptions. - Hot (Fireblocks MPC, automated) — 2% TVL, ≤€500k per tx limit, daily operations.

Multi-sig: 3-of-5 (2 internal + 3 external — см. §3.4).

Key Ceremony: при первичном создании ключей — формальная процедура с участием независимых наблюдателей, видеозаписью, актом подписания, аудитируемым кворумом.

DR-копии ключей: Shamir’s Secret Sharing (3-of-5) с офлайн-хранением в географически распределённых сейфах (Yerevan + EU + RA-юрфирма).

Rotation policy: квартальная ротация операционных ключей; критичные multi-sig — по необходимости с формальной процедурой.

5.3a Custody-архитектура (гибридная модель)

CASP-лицензия по Регл. 7/01 ЦБ РА требует «техническую возможность исполнения обязательств». Полностью аутсорсить custody нельзя, полностью building-it-yourself слишком долго. Принят гибрид:

MPC vs naive multi-sig: Phase 2 (после Audit 2) — миграция с naive multi-sig на TSS (Threshold Signature Scheme) через Fireblocks MPC: threshold не публикуется on-chain (privacy), поддержка BLS-aggregation, контракт видит одну подпись (backward-compatible).

Custody insurance — Lloyd’s of London: - Coverage: $25M crime + custody через Marsh Crypto (Phase 1). - Premium estimate: ~$200k/год (0.5–1.2% от $25M coverage, tier по Phase 1 TVL). - Phase 2 при TVL >$50M: расширение до $100M Lloyd’s coverage = $500k–$1.2M/год premium. - Reinsurance layer для coverage >$100M в Phase 3.

5.4 Penetration testing и Bug Bounty

• Penetration testing: дважды в год (smart contracts отдельно от инфраструктуры);
• Bug Bounty: программа на HackerOne с reward’ами от $500 (низкая) до $50 000 (критическая);
• Continuous security scanning: Snyk, Dependabot для зависимостей; SonarQube для code quality.

5.5 KYC / AML

Stack — конкретный выбор vendor по слоям:

SSI / DID — Polygon ID v2 (P4 patent realization):

ZK-proof архитектура: пользователь проходит KYC один раз с CASP-партнёром (например, Sumsub-issuing), получает credential, и предъявляет zero-knowledge proof Платформе «Ноев Ковчег» без раскрытия PII. Polygon ID v2 интегрирован с Sumsub и Quadrata. Это реализация P4 patent (KYC + DTA mapping) — не концепция, а deployable код.

GDPR + immutable blockchain (Right to be Forgotten, GDPR Art. 17):

• On-chain: только hash KYC credentials (no PII).
• Off-chain: Hashicorp Vault + isolated PostgreSQL в Yerevan (резиденты РА) или Frankfurt (нерезиденты), encryption AES-256-GCM per-column.
• Right to erasure: удаление off-chain записи + revocation of credential через Polygon ID (credential становится invalid). On-chain hash остаётся (immutable), но без off-chain записи он бесполезен — это GDPR-compliant и AML-compliant одновременно.
• Retention: 7 лет после прекращения отношений (AML РА + EU AMLD). После — full purge.

6. DEVOPS / SRE

6.1 CI/CD pipeline

Developer commit → Git (GitLab self-hosted)
                                    ↓
                              Pre-commit hooks
                              (linting, formatting,
                               unit tests, security scan)
                                    ↓
                              CI Pipeline (GitLab CI):
                              - build
                              - tests (unit, integration, e2e)
                              - smart contract tests
                              - security scans (SAST, DAST, deps)
                              - container build + scan
                              - infra plan (terraform plan)
                                    ↓
                              Code review (2 approvers required
                              для main branch)
                                    ↓
                              CD Pipeline:
                              - staging deploy (auto)
                              - integration tests на staging
                              - manual approval для production
                              - canary deploy (10% → 50% → 100%)
                              - smoke tests
                              - rollback on alert

6.2 Observability

6.3 SLO targets

6.4 Incident Response Playbook (outline)

1. Detection — automated alerting via Prometheus + custom monitors
2. Triage — on-call engineer assesses severity (P1/P2/P3)
3. Mitigation — immediate actions to restore service
4. Communication — internal Slack/Telegram channel + customer-facing status page
5. Resolution — root cause analysis, fix
6. Post-mortem — blameless post-mortem within 48 hours of resolution
7. Action items — tracked in issue tracker, reviewed weekly

Severity matrix: - P1: Полная недоступность Web/Mobile App ИЛИ компрометация безопасности ИЛИ потеря клиентских средств. Ответ < 15 мин. Все hands on deck. - P2: Деградация UX или частичная недоступность. Ответ < 1 час. - P3: Минимальное влияние; устраняется в течение рабочего дня.

7. MOBILE-АРХИТЕКТУРА

7.1 Phase 1: PWA

Преимущества PWA для Фазы 1: - Не требует прохождения review в App Store / Google Play (быстрый запуск); - Работает на iOS, Android, desktop через любой современный браузер; - Автоматическое обновление без необходимости user action; - Кросс-платформенный единый код.

Технологии: - React + Next.js; - Workbox для offline support; - Web Push для уведомлений; - IndexedDB для local cache; - WebAuthn для биометрической авторизации (Face ID, Touch ID, Windows Hello, армянский nID если поддерживается); - Web Crypto API для подписей.

Ограничения PWA: - На iOS — ограничения Web Push (требует iOS 16.4+); - Меньшая интеграция с системой (нет native share sheet, ограниченный доступ к камере); - Branding в menu bar / dock — менее заметный, чем нативное приложение.

7.2 Phase 2: Нативные приложения

Стратегия: - React Native — основная кодовая база (overlap с PWA для логики); - Native bridges для: биометрии, push-уведомлений, deeplinks, share sheet, secure enclave; - Распространение через App Store и Google Play.

Целевые версии: - iOS 14.0+ - Android 8.0+ (API 26+)

7.3 Offline KYC capture

Для пилотного периода (диаспора часто без стабильного интернета): - Возможность offline-сбора документов (фото паспорта, селфи); - Queue для синхронизации при появлении интернета; - Локальное шифрование данных в IndexedDB / Keychain.

8. АРХИТЕКТУРА ДАННЫХ

8.1 Логические домены

8.2 Шифрование

8.3 Privacy-preserving аналитика

Для соблюдения GDPR и Закона РА «О защите ПД»: - Аналитика использует pseudonymized данные (replace user ID with hashes); - Data minimization — собирается только строго необходимое; - Retention policy — KYC данные удаляются через 7 лет после прекращения отношений (требование AML); - Right to erasure (GDPR Art. 17) — учтено для нерезидентов; для резидентов РА — в рамках Закона о ПД.

9. ЮР-МАППИНГ АРХИТЕКТУРНЫХ РЕШЕНИЙ

9.1 Соответствие архитектуры законодательству РА

9.2 Соответствие международным стандартам

10. ДОРОЖНАЯ КАРТА ВНЕДРЕНИЯ (M0–M12 ДО MAINNET GA)

Кумулятивный Year-1 tech budget: $2.56M (см. §3.9). Time-to-mainnet GA — 12 месяцев с момента закрытия seed funding.

10А. TECHNICAL RISK MATRIX

15 ключевых технических рисков с оценкой Severity (1–5) × Probability (1–5) и митигацией. Score = S × P. Приоритет внимания — Top-3.

Top-3 риска (Score = 15+): 1. Smart contract vulnerability — митигируется dual-audit + formal verification + bug bounty. 2. NAV oracle manipulation — митигируется 3+ оценщика + median + slashing + 48h time-lock. 3. Insurance bridge inconsistency — митигируется EIP-712 + 7-day dispute window.

Общий технологический риск — middle-low при условии адекватного финансирования ($2.56M Y1). Архитектурный риск — low. Главный остающийся риск — execution risk (найм команды) и regulatory engagement (одобрение read-only ноды ЦБ РА до mainnet).

11. ЗАКЛЮЧЕНИЕ

Техническая архитектура Платформы «Ноев Ковчег» построена на:

1. Зрелых индустриальных компонентах — никакой экзотики, только проверенные решения;
2. Defense-in-depth — многоуровневая защита от технических, операционных и регуляторных рисков;
3. Регуляторной готовности — каждое решение мэппится на соответствующую норму HO-159-N или Регламента ЦБ РА;
4. Прозрачности — для регулятора (через ноду) и для держателей токенов (через публичный распределённый реестр);
5. Масштабируемости — Фаза 1 архитектура поддерживает рост до Фазы 2 без принципиальных переделок;
6. DLT-agnosticism — возможность миграции на иную DLT-платформу без переписывания application layer.

Архитектура готова к независимому тех-due-diligence со стороны Минфина РА, Центрального банка РА, ЕБРР, Всемирного банка, IFC и иных институциональных инвесторов.

Подпись: _______________________ Кагиров А.-Х. А. (Аслан Каа), правообладатель и инициатор Дата: «» ______ 2026 г.

© Кагиров Абдул-Хаким Ахмадович, 2026. Документ NK-ARCH-001/2026. Все права защищены в соответствии с Всемирной конвенцией об авторском праве (Женева, 1952) и Бернской конвенцией (1886). Воспроизведение и распространение запрещены без письменного согласия правообладателя.