© Kagirov Abdul-Khakim Akhmadovich, 2026. All rights reserved. Watermark · © Kagirov A-Kh. A. · 2026 · ALL RIGHTS RESERVED · Universal Copyright Convention, Geneva 1952

TECHNICAL ARCHITECTURE

Noah’s Ark Platform · Software Architecture Document (SAD)

Document № NK-ARCH-001/2026 Date: 1 May 2026 Document type: Software Architecture Document (SAD), C4 level + subsystem detail Applicable law: RA Law HO-159-N + CBA Regulations 7/01–7/05; RA Law on Personal Data Protection; ISO/IEC 27001, IFRS

Author and rightsholder: Kagirov Abdul-Khakim Akhmadovich (Aslan Kaa) www.aslankaa.com · 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

The technical architecture of the Noah’s Ark Platform is built on a defense-in-depth model with a hybrid cloud topology (primary EU-Frankfurt + secondary Yerevan + edge in diaspora hubs), permissioned DLT with a regulator node for the Central Bank of Armenia, multi-signature custody on HSMs at FIPS 140-2 Level 3, and a full mapping of every architectural decision to articles of HO-159-N and CBA Regulations.

Key architectural decisions:

1. DLT layer: Polygon PoS (EVM-compatible, low gas costs, mature community, regulator nodes supported);
2. Hybrid cloud: primary AWS Frankfurt + secondary Hetzner Yerevan + Cloudflare edge;
3. Custody: Multi-sig 3-of-5 (CEO + CTO + CFO + CCO + Independent Trustee) with AWS CloudHSM or Thales Luna;
4. Mobile-first: PWA for Phase 1, optional native apps for Phase 2;
5. Regulator access: the CBA receives a read-only node with full real-time access to the pool composition;
6. Security: ISO/IEC 27001 + GDPR + RA Law on Personal Data Protection + at least two independent smart-contract audits;
7. Observability: Prometheus + Grafana + Loki + Tempo with SLO 99.9% read / 99.5% write availability.

1. C4 ARCHITECTURE DIAGRAMS

1.1 Level 1 — System Context

                        ┌───────────────────────┐
                        │  NOAH'S ARK PLATFORM   │
                        │  (CASP operator +      │
                        │   token issuer)        │
                        └─────────┬─────────────┘
                                  │
   ┌───────┬───────┬──────────────┼──────────────┬───────┬───────┐
   ▼       ▼       ▼              ▼              ▼       ▼       ▼
┌──────┐ ┌──────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ ┌──────┐ ┌──────────┐
│Owner │ │Inves-│ │ State of │ │ CBA      │ │Insurer │ │Val- │ │Distributed│
│ (nat.│ │ tor  │ │ Armenia  │ │(supervis-│ │(Arme-  │ │uer  │ │ ledger    │
│ /leg)│ │ (3   │ │(MoF,     │ │ion +     │ │ nian)  │ │(li- │ │(Polygon)  │
│      │ │ types│ │Treasury) │ │regulatory│ │        │ │censd)│ │           │
└──────┘ └──────┘ └──────────┘ └──────────┘ └────────┘ └──────┘ └──────────┘
   │       │           │            │           │         │           │
   │ KYC,  │ Buys      │ Receives   │Files      │Insures  │Values   │  On-chain
   │ depo- │ tranches, │ cash,      │whitepaper,│assets & │assets   │  state of
   │ sit   │ buys      │ finances   │HO-159-N   │CFA, pays│before   │  pool,
   │ asset │ ART       │ national   │compliance │on       │pool     │  tokens,
   │       │           │ projects   │reports    │insured  │admis-   │  txs
   │       │           │            │           │events   │sion     │

1.2 Level 2 — Container Diagram

                          ┌────────────────────────────────────┐
                          │      NOAH'S ARK PLATFORM            │
                          │           (inside the trust)        │
                          └────────────────────────────────────┘

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 ops)  │                    │  (CRUD pool,         │ (PostgreSQL  │
│             │                    │  revaluations)       │  + IPFS docs)│
└─────────────┘                    │                      └──────────────┘
                                   │
┌─────────────┐                    │                      ┌──────────────┐
│ Investor    │                    ├─►Order Service      ►│ Tx Ledger    │
│ Dashboard   │                    │  (issuance, tra-     │ (ClickHouse  │
│             │                    │  ding, redemption)   │  for analyt.)│
└─────────────┘                    │                      └──────────────┘
                                   │
┌─────────────┐                    │                      ┌──────────────┐
│ Regulator   │                    ├─►Smart Contract      ►│ DLT Layer   │
│ Portal      │ ◄══════════════════│  Bridge              │ (Polygon PoS │
│ (CBA)       │   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 Level 3 — Component diagrams (3 key subsystems)

1.3.1 Smart Contract Bridge (components)

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 (components)

Pool Service
├── Asset Onboarding
│   ├── Document verification (Armenian Cadastre 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
│   ├── AMD 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 (components)

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 (Platform → owner in 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 Level 4 — Code-level mapping for critical parts

Implementation of specific functions at the code level will be described in component-level technical specifications during development. At the SAD level it suffices to describe the critical code-paths that require special attention:

2. CHOICE OF DLT LAYER

2.1 Comparison matrix

2.2 Recommendation

Polygon PoS has been selected as the Phase 1 DLT platform on the following grounds:

1. EVM compatibility opens access to the largest ecosystem of wallets, custody, and audit tooling;
2. Low gas costs make frequent operations (coupons, revaluations) economically feasible;
3. An active community of smart-contract development and audit — reducing technical risk;
4. Compatibility with regulator nodes via middleware (Tenderly, Blockscout, internal indexer);
5. MiCA readiness — Polygon Labs is in active dialogue with ESMA and EU MiCA regulators;
6. Bridge to Ethereum L1 — possibility of future migration without loss of liquidity.

2.3 Alternative and migration plan

In case of regulatory issues with Polygon PoS, the migration plan: - Alternative 1: Polygon zkEVM (full Ethereum compatibility with zk-proofs); - Alternative 2: Hyperledger Besu in private deployment (fully permissioned EVM network for critical operations); - Alternative 3: Avalanche Subnet (custom permissioned with EVM).

The architecture is made DLT-agnostic at the Smart Contract Bridge level — migration is possible without rewriting the application layer.

2.4 CBA regulator node

The CBA receives a dedicated node with: - Read-only access to all transactions, pool state, NAV; - API for queries — pool composition at any moment in time, revaluation history, AML flags; - Push notifications on material events (new issuance, redemption, NAV change >10%); - 24/7 technical support by the Platform.

Node architecture:

[CBA datacenter] → VPN → [Polygon RPC node, hosted by the Platform]
                                    │
                                    ↓
                              [Reader-only API:
                                  - GraphQL queries
                                  - Webhook subscriptions
                                  - CSV/JSON exports]

3. SMART CONTRACT SPECIFICATION

3.1 CFA1Token

Purpose: A soulbound utility token representing the owner’s share of real estate in the pool.

Type: ERC-5192 (Minimal Soulbound NFT, EIP-final) on top of an ERC-721-style identifier. ERC-5192 enshrines non-transferable semantics through the locked(tokenId) flag and is part of the OpenZeppelin Contracts v5.x audit checklists. The soulbound property via revert in _beforeTokenTransfer is intentionally not used — the standard route simplifies the Trail of Bits / OpenZeppelin audit.

Link to the owner: the asset is cryptographically bound to the owner (CFA1 = owner address + cadastreReference + assetValueAMD) and cannot be traded, even via proxy / wrapping — wrapping ERC-20s on top of CFA1 are forbidden by the Platform’s regulatory policy.

State: - mapping(uint256 => address) ownerOf — owner of the CFA1 - mapping(uint256 => uint256) assetValueAMD — appraised asset value in AMD - mapping(uint256 => uint256) pledgeStartTimestamp — pledge start - mapping(uint256 => uint256) pledgeEndTimestamp — scheduled return moment - mapping(uint256 => bytes32) cadastreReference — reference to the entry in the Armenian Cadastre - mapping(uint256 => uint256) lastCouponPaid — last coupon paid - mapping(uint256 => bool) isInsured — insurance status

Functions (Pool Escrow administrator only): - mint(address owner, uint256 valueAMD, bytes32 cadastreRef, uint256 cycleDuration) — creates a CFA1 - burn(uint256 tokenId) — destroys a CFA1 on asset return and encumbrance release - recordCouponPayment(uint256 tokenId, uint256 amount) — records a coupon payment

Restrictions: - transferFrom() — DISABLED (soulbound) - safeTransferFrom() — DISABLED - Only the Pool Escrow contract may call mint/burn

Upgradability: UUPS proxy (Universal Upgradeable Proxy Standard) with a 7-day time-lock + multi-sig 3-of-5.

3.2 SeniorTrancheBond

Purpose: A senior debt token (security wrapper) with coupon payments and a redemption schedule.

Type: ERC-3643 (T-REX) — a security token standard with built-in compliance (whitelist, transfer restrictions, freeze, identity binding via OnchainID). T-REX (rather than ERC-1400) is preferred because: 1. T-REX is a production-proven standard (Tokeny Solutions), MiCA-aligned, used in EU regulated tokenization. 2. ERC-1400 remains a draft, not approved by the Ethereum Foundation; auditors are less confident in it. 3. T-REX integrates OnchainID, removing identity/KYC binding at the token level and simplifying Travel Rule maintenance.

State: - mapping(address => uint256) balanceOf — holder balances - mapping(address => bool) whitelisted — list of allowed investors (KYC-passed) - uint256 totalSupply — issued supply (70,000) - uint256 nominalValueEUR — nominal value (€1,000) - uint256 couponBPS — coupon in basis points (550 = 5.5%) - uint256 issueDate — issuance date - uint256 maturityDate — maturity date (issueDate + 7 years) - uint256[] couponPaymentDates — quarterly coupon dates (28 dates) - mapping(address => uint256) lastClaimedCoupon — index of the last claimed coupon

Functions: - issueToWhitelistedHolder(address holder, uint256 amount) — issuance to a whitelisted investor - transfer(address to, uint256 amount) — only between whitelisted addresses - claimCoupon(uint256 paymentIndex) — coupon claim by a holder - claimMaturity() — claim of principal at maturity - executeBudgetGuarantee(bytes calldata proof) — activation of the RA Ministry of Finance budgetary guarantee (trustee only)

Compliance hooks: - beforeTransfer() — whitelist check, sanctions absence - afterTransfer() — emit event for the regulator node

Upgradability: UUPS proxy with a 14-day time-lock (longer due to security criticality).

3.3 JuniorTrancheART

Purpose: A junior asset-referenced token linked to the pool NAV.

Type: ERC-20 fixed-supply (300,000, immutable post-issuance) + an external NAVOracle contract. A rebase approach is explicitly rejected because: - rebase changes each holder’s supply and creates a UX disaster with custody providers, tax reporting (Russian FNS, diaspora EU jurisdictions), and DeFi integrations. - In 2026 production practice, no regulated ART/stablecoin operator uses rebase (Maple Finance, Centrifuge, Ondo — all price-oracle). - The audit trail and manipulation risk are easier to control at the level of an external NAVOracle (see §3.7) without interfering with supply.

State: - mapping(address => uint256) balanceOf - uint256 totalSupply (300,000 at launch) - uint256 nominalValueEUR (€100 initially) - address oracleAdapter — OracleAdapter contract address - uint256 lastNAVUpdate — timestamp of the last NAV update - uint256 currentNAVPerToken — current NAV per token - uint256 redemptionLimitQuarterlyBPS — quarterly redemption cap (2500 = 25%) - mapping(uint256 => uint256) quarterlyRedemptions — quarterly redemption ledger

Functions: - issueAtNAV(address holder, uint256 amount) — issuance at the current NAV - redeem(uint256 amount) — holder redemption at NAV (30-day lag, cap-checked) - forceRedeem(uint256 amount) — issuer redemption (90-day notice) - updateNAV(uint256 newNAVPerToken) — NAV update (Oracle Adapter only) - getCurrentNAV() — public getter

Manipulation protection: - NAV updates no more often than once per day; - A NAV change >10% per update requires confirmation by three independent oracles; - Time-weighted average is used for large redemptions (>€100,000).

Upgradability: UUPS proxy with a 14-day time-lock.

3.4 PoolEscrow

Purpose: Custody of the CFA1 pool with multi-sig 3-of-5.

Type: Multi-signature wallet with a role model.

Signers (2 internal + 3 external): 1. Platform CEO (internal) — operational signer. 2. Platform CTO (internal) — technical signer. 3. Partner of an Armenian law firm (external) — independent legal trustee, a regulated top-5 Armenian advocacy firm. 4. EU-based custody trustee (external) — institutional escrow agent in an EU jurisdiction (Luxembourg / Liechtenstein). 5. CBA nominee — separate read-only key, not part of the signing threshold (otherwise it would conflict with the supervisory function; the CBA remains supervisor, not co-issuer).

Geographic distribution: 2 keys in Yerevan + 1 EU + 1 RA law firm (separate office) + 1 read-only. This removes the risk of state-pressure concentration and aligns with industry standard (Coinbase Custody, BitGo).

State: - address[5] signers — 5 mandatory signers (4 signing + 1 read-only nominee) - uint256 threshold — 3 (3-of-5 among signing keys) - mapping(bytes32 => uint8) approvals — signature counter by operationHash - mapping(uint256 => address) cfaInPool — CFA1 currently in the pool - address insuranceBridge - address poolService — application layer, may propose operations (but not execute)

Functions: - proposeOperation(bytes32 opHash, OperationType opType, bytes calldata data) — proposes an operation - approveOperation(bytes32 opHash) — approval by a signer - executeOperation(bytes32 opHash) — execution once the threshold is reached - addCFA1(uint256 tokenId) — adds a CFA1 to the pool (multi-sig required) - removeCFA1(uint256 tokenId) — withdraws a CFA1 on return (multi-sig required) - triggerInsurance(InsuranceType type, uint256 amount) — triggers an insurance claim

Time-lock: 24 hours for large operations (value >€1M); instant for routine.

3.5 InsuranceBridge

Purpose: A bridge between the smart contracts and insurers (CCI, VPI, Force-Majeure).

Type: An adapter with off-chain integration.

Functions: - submitClaim(InsuranceType type, uint256 amount, bytes calldata evidence) — files a claim - recordPayout(bytes32 claimId, uint256 amount, bytes calldata signature) — records insurer payout - checkCoverageActive(uint256 tokenId) — checks active coverage

Notes: Off-chain event verification is carried out by the insurer; the final result is recorded on-chain for transparency.

3.6 GovernanceContract

Purpose: Holder voting on material decisions.

Type: OpenZeppelin Governor + Bravo extensions.

Functions: - propose(targets[], values[], calldatas[], description) — create a proposal - castVote(proposalId, support) — cast a vote - execute(proposalId, ...) — execute a passed proposal

Voting power: - Senior tranche holders: 1 token = 1 vote (on Senior-related questions); - Junior tranche holders: 1 token = 1 vote (on Junior-related questions); - Cross-tranche questions: weighted (€-equivalent).

Quorum: 30% of the outstanding supply in the relevant category.

3.7 OracleAdapter (NAV Oracle, P3 patent)

Purpose: Sourcing independent NAV estimates and other off-chain data. This is the most sensitive link in the architecture — a single point of failure for manipulation — so the stack is formalised.

Type: A hybrid pipeline on Chainlink Functions (aggregator) + EIP-712 signed attestations.

Data sources (at least 3 licensed RA appraisers): 1. Ameriabank Property Valuation Department — a bank appraiser with regulated methodology. 2. An appraiser affiliated with the state Armenian Cadastre — access to primary cadastre data. 3. An independent member of the RA Self-Regulated Organization of Appraisers — independent rotation (not the same firm for more than two consecutive quarters).

If the spread exceeds 5% between appraisers — auto-request a fourth opinion; if it exceeds 10% — manual review via multi-sig 3-of-5.

Off-chain attestation flow:

Licensed appraiser → emits {timestamp, navPerToken, evidence_hash, cadastreRefs[]}
   └─ EIP-712 typed-data signature
        └─ Upload report + supporting docs → IPFS (CID stored)
             └─ Sign hash via reputation contract (AMD stake at risk of
                slashing for false attestations verified through the regulator)

On-chain aggregation:

Chainlink Functions (off-chain compute):
   └─ Median of 3 attestations + outlier rejection
        └─ commitNAV(median, attestations[]) into the NAVOracle contract
             └─ **48-hour time-lock** for all NAV updates
                  (any holder may dispute via GovernanceContract)
                  └─ After 48h: JuniorTrancheART.updateNAV(median)
                       └─ Time-weighted average over a 7-day window
                          for large redemptions (>€100k)

Contract functions: - requestNAVUpdate() — initiates the quarterly cycle - submitAttestation(bytes32 requestId, uint256 nav, bytes32 ipfsCID, bytes signature) — receives an EIP-712 attestation - aggregateAndCommit() — median + outlier rejection + commit with 48h time-lock - disputeNAV(uint256 commitId, bytes evidence) — dispute within the 48h window - executeCommittedNAV(uint256 commitId) — final commit to JuniorTrancheART after the lock

Protections: - At least 3 independent RA appraisers (rotation policy). - Median-based aggregation (outlier protection). - EIP-712 cryptographic signatures verified on-chain. - IPFS evidence per attestation (cryptographic audit trail). - Reputation contract with slashing (appraiser AMD stake). - 48-hour time-lock on every NAV update (dispute window). - Multi-sig 3-of-5 override for emergency NAV with public justification.

Regulator audit trail: the CBA receives access to all updateNAV events on-chain + IPFS attestations + reputation state. Each update carries a public cryptographic proof (EIP-712 signatures from 3 appraisers + median computation log).

Fallback on oracle downtime: - The last known NAV is held for 7 days. - After 7 days — redemptions are auto-paused (protection against stale-price arbitrage). - Multi-sig 3-of-5 may force-commit an emergency NAV.

3.8 Smart-contract audits

All smart contracts are subject to two independent audits in parallel + pre-audit consulting + bug bounty:

Year-1 tech budget (full amount, not only audits): $2.56M — see §3.9.

3.9 Year-1 Tech Budget (breakdown)

Year-2 steady-state tech OpEx (post-Series A): $1.8–2.2M/year — team expansion to 15 FTE, recurring audits, insurance renewal, cloud scale, bug-bounty pool growth.

4. INFRASTRUCTURE AND CLOUD

4.1 Hybrid architecture

                     [Cloudflare Edge — global CDN + DDoS]
                               │
                ┌──────────────┴──────────────┐
                │                             │
                ▼                             ▼
   ┌────────────────────────┐    ┌────────────────────────┐
   │  PRIMARY               │    │  SECONDARY              │
   │  AWS Frankfurt (eu-    │    │  Hetzner Yerevan       │
   │  central-1)            │◄══►│  (or Cloud4Y Yerevan)  │
   │                        │ DR │                        │
   │  - Application layer   │ ↔  │  - DR replica          │
   │  - Web/Mobile API      │    │  - Regulator node      │
   │  - Business logic      │    │  - RA resident data    │
   │  - Smart contract      │    │                        │
   │    bridge              │    │                        │
   │  - DLT RPC nodes       │    │                        │
   │  - Database primary    │    │                        │
   └────────────────────────┘    └────────────────────────┘
                │                             │
                └──────────┬──────────────────┘
                           │
                           ▼
                ┌──────────────────────┐
                │  EDGE PRESENCE        │
                │  Cloudflare Workers:   │
                │  - Moscow (RU diaspora)│
                │  - Los Angeles         │
                │  - Paris               │
                │  - Beirut              │
                │  - Berlin              │
                └──────────────────────┘

4.2 Data residency logic

4.3 BCP / DR (Business Continuity / Disaster Recovery)

4.4 Technology stack

5. INFORMATION SECURITY

5.1 Compliance mapping

5.2 Defense in depth

Layer 1: Edge (Cloudflare WAF, DDoS protection, bot mitigation)
   ↓
Layer 2: API Gateway (rate limiting, input validation, auth)
   ↓
Layer 3: Application (RBAC, OAuth 2.0, JWT, signed requests)
   ↓
Layer 4: Service mesh (mTLS between microservices)
   ↓
Layer 5: Data layer (encryption at rest, columnar PII encryption)
   ↓
Layer 6: Network (private subnets, security groups, NACLs)
   ↓
Layer 7: Audit (immutable logs, SIEM monitoring)

5.3 Private key management

HSM stack, phased approach:

Hot / Warm / Cold ratio (per industry standard Coinbase Custody / BitGo): - Cold (HSM-protected, multi-sig 3-of-5, offline, geographically distributed) — 90% TVL, 24h time-lock. - 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 — see §3.4).

Key Ceremony: at initial key creation — a formal procedure with independent observers, video recording, signing minute, and audited quorum.

DR copies of keys: Shamir’s Secret Sharing (3-of-5) with offline storage in geographically distributed safes (Yerevan + EU + RA law firm).

Rotation policy: quarterly rotation of operational keys; critical multi-sig — as needed under a formal procedure.

5.3a Custody architecture (hybrid model)

The CASP licence under CBA Reg. 7/01 requires “technical capacity to perform obligations”. Custody cannot be fully outsourced; building everything from scratch takes too long. A hybrid model is adopted:

MPC vs naive multi-sig: Phase 2 (after Audit 2) — migration from naive multi-sig to TSS (Threshold Signature Scheme) via Fireblocks MPC: threshold is not published on-chain (privacy), BLS aggregation support, the contract sees a single signature (backward-compatible).

Custody insurance — Lloyd’s of London: - Coverage: $25M crime + custody via Marsh Crypto (Phase 1). - Premium estimate: ~$200k/year (0.5–1.2% of $25M coverage, tier by Phase 1 TVL). - Phase 2 at TVL >$50M: expansion to $100M Lloyd’s coverage = $500k–$1.2M/year premium. - Reinsurance layer for coverage >$100M in Phase 3.

5.4 Penetration testing and Bug Bounty

• Penetration testing: twice a year (smart contracts separately from infrastructure);
• Bug Bounty: HackerOne programme with rewards from $500 (low) to $50,000 (critical);
• Continuous security scanning: Snyk, Dependabot for dependencies; SonarQube for code quality.

5.5 KYC / AML

Stack — concrete vendor selection by layer:

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

ZK-proof architecture: the user passes KYC once with a CASP partner (e.g. Sumsub-issuing), receives a credential, and presents a zero-knowledge proof to the Noah’s Ark Platform without disclosing PII. Polygon ID v2 is integrated with Sumsub and Quadrata. This is the implementation of the P4 patent (KYC + DTA mapping) — not a concept, but deployable code.

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

• On-chain: only KYC credential hashes (no PII).
• Off-chain: Hashicorp Vault + isolated PostgreSQL in Yerevan (RA residents) or Frankfurt (non-residents), encryption AES-256-GCM per column.
• Right to erasure: deletion of the off-chain record + credential revocation via Polygon ID (the credential becomes invalid). The on-chain hash remains (immutable) but is useless without the off-chain record — GDPR-compliant and AML-compliant simultaneously.
• Retention: 7 years after termination of the relationship (RA AML + EU AMLD). Then 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
                              for main branch)
                                    ↓
                              CD Pipeline:
                              - staging deploy (auto)
                              - integration tests on staging
                              - manual approval for 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 the issue tracker, reviewed weekly

Severity matrix: - P1: Full unavailability of Web/Mobile App OR security compromise OR loss of client funds. Response < 15 min. All hands on deck. - P2: Degraded UX or partial unavailability. Response < 1 hour. - P3: Minimal impact; resolved within the business day.

7. MOBILE ARCHITECTURE

7.1 Phase 1: PWA

Advantages of PWA for Phase 1: - No App Store / Google Play review required (fast launch); - Runs on iOS, Android, desktop via any modern browser; - Automatic updates without user action; - Cross-platform single codebase.

Technologies: - React + Next.js; - Workbox for offline support; - Web Push for notifications; - IndexedDB for local cache; - WebAuthn for biometric authorisation (Face ID, Touch ID, Windows Hello, Armenian nID where supported); - Web Crypto API for signatures.

PWA limitations: - On iOS — Web Push restrictions (requires iOS 16.4+); - Less system integration (no native share sheet, limited camera access); - Branding in the menu bar / dock — less prominent than a native app.

7.2 Phase 2: Native applications

Strategy: - React Native — main codebase (overlap with PWA for logic); - Native bridges for: biometrics, push notifications, deeplinks, share sheet, secure enclave; - Distribution via the App Store and Google Play.

Target versions: - iOS 14.0+ - Android 8.0+ (API 26+)

7.3 Offline KYC capture

For the pilot period (the diaspora often lacks stable internet): - Offline collection of documents (passport photo, selfie); - Queue for synchronisation when internet becomes available; - Local data encryption in IndexedDB / Keychain.

8. DATA ARCHITECTURE

8.1 Logical domains

8.2 Encryption

8.3 Privacy-preserving analytics

For GDPR and RA Personal Data Protection compliance: - Analytics uses pseudonymized data (replace user ID with hashes); - Data minimisation — only what is strictly necessary is collected; - Retention policy — KYC data are deleted 7 years after the relationship ends (AML requirement); - Right to erasure (GDPR Art. 17) — implemented for non-residents; for RA residents — within the framework of the Personal Data Protection Law.

9. LEGAL MAPPING OF ARCHITECTURAL DECISIONS

9.1 Compliance of the architecture with RA law

9.2 Compliance with international standards

10. IMPLEMENTATION ROADMAP (M0–M12 TO MAINNET GA)

Cumulative Year-1 tech budget: $2.56M (see §3.9). Time-to-mainnet GA — 12 months from seed funding close.

10A. TECHNICAL RISK MATRIX

Fifteen key technical risks with Severity (1–5) × Probability (1–5) scoring and mitigation. Score = S × P. Top-3 deserve special attention.

Top-3 risks (Score = 15+): 1. Smart contract vulnerability — mitigated by dual-audit + formal verification + bug bounty. 2. NAV oracle manipulation — mitigated by 3+ appraisers + median + slashing + 48h time-lock. 3. Insurance bridge inconsistency — mitigated by EIP-712 + 7-day dispute window.

The overall technology risk is middle-low subject to adequate funding ($2.56M Y1). The architectural risk is low. The principal remaining risks are execution risk (team hiring) and regulatory engagement (CBA read-only node approval before mainnet).

11. CONCLUSION

The technical architecture of the Noah’s Ark Platform is built on:

1. Mature industrial components — no exotica, only proven solutions;
2. Defense in depth — multi-layer protection from technical, operational, and regulatory risks;
3. Regulatory readiness — each decision maps to a specific HO-159-N or CBA Regulation provision;
4. Transparency — to the regulator (via the node) and to token holders (via the public distributed ledger);
5. Scalability — the Phase 1 architecture supports growth into Phase 2 without fundamental rework;
6. DLT-agnosticism — migration to another DLT platform is possible without rewriting the application layer.

The architecture is ready for independent technical due diligence by the RA Ministry of Finance, the Central Bank of Armenia, EBRD, the World Bank, IFC, and other institutional investors.

Signature: _______________________ Kagirov A-Kh. A. (Aslan Kaa), rightsholder and initiator Date: “” ______ 2026

© Kagirov Abdul-Khakim Akhmadovich, 2026. Document NK-ARCH-001/2026. All rights reserved under the Universal Copyright Convention (Geneva, 1952) and the Berne Convention (1886). Reproduction and distribution are prohibited without written consent of the rightsholder.