AUDIT 5 — TECHNOLOGY & DLT

Noah’s Ark Platform · Production-Readiness Audit

Software Architecture, DLT, Smart Contracts, Custody, Mobile Stack

Document: NK-AUDIT-005/2026 Date: 11 May 2026 Type: Independent Technical Audit, Production-Readiness Review Scope: DLT choice · Smart contracts · Custody · Oracle/NAV · KYC architecture · Mobile (PWA + RN) · Tech debt · Roadmap to Series A

Auditor: Yuki Tanaka, MSc Computer Science (MIT) CTO TokenForge · ex-Polygon Labs Principal Architect · ex-Coinbase Crypto Custody Lead 15+ years in blockchain infrastructure · specialisation: RWA tokenization, smart contract security, regulatory-grade DLT.

Audit object (as of 11.05.2026): - C_Техническая_архитектура.md — Software Architecture Document, C4 (NK-ARCH-001/2026) - B_HTML_прототип_Ноев_Ковчег.html — UX prototype - Мобильное Приложение Ноев Ковчег/00_DESIGN_SPEC_Mobile_App.md — Master design spec - Мобильное Приложение Ноев Ковчег/05_API_Specification/openapi.yaml — REST API spec - Мобильное Приложение Ноев Ковчег/06_Working_PWA/index.html — Working PWA prototype

Applicable law: HO-159-N + CBA Regulations 7/01–7/05; RA Personal Data Protection Law; GDPR; MiCA (as a reference); FATF Rec. 16.

1. EXECUTIVE SUMMARY

Verdict: The project is at the “architecture-ready, code-not-ready” stage. The SAD (NK-ARCH-001/2026) is competent, the defense-in-depth logic is correct, the choice of Polygon PoS is defensible for a CASP under HO-159-N with caveats. Between the document and working code, however, there is a 9–12 person-month delta: nothing currently runs on mainnet, smart contracts are described at the level of a state machine, the custody ceremony has not been performed, the oracle stack is theoretical, the regulator node is a proof of concept. Production-readiness: 2/10. Architectural maturity: 7/10. Series A readiness after execution of a 12-month roadmap: 8/10.

Three critical gaps:

1. No smart-contract codebase. The SAD describes 7 contracts (CFA1Token, SeniorTrancheBond, JuniorTrancheART, PoolEscrow, InsuranceBridge, GovernanceContract, OracleAdapter) but no Solidity repository exists. Without 6 months of development + 2 independent audits ($200–400k) the CBA’s CASP licence under Reg. 7/01 cannot be obtained — the regulation requires “technical capacity to perform obligations”.

2. Custody architecture is declared but the HSM ceremony has not been performed. Multi-sig 3-of-5 is described, but the FIPS 140-2 Level 3 HSM (CloudHSM/Thales Luna) has not been procured and no key ceremony with independent observers has been planned. For a €100M pool this is a blocker under Reg. 7/02 (minimum capital as an indicator of operational maturity + custody).

3. The NAV oracle (P4 patent) is the most vulnerable link. Quarterly NAV update of real estate from the RA Cadastre is an off-chain process with no proven on-chain analogues. The architecture uses “Chainlink Functions or proprietary” — that is not a solution yet. Without formalising the oracle stack (at least 3 independent appraisers + median + on-chain signature verification + time-lock), NAV manipulation remains a single point of failure.

Three priority recommendations (next 90 days):

1. Hire CTO + Lead Solidity + Lead SRE (3 FTE). By 1 August 2026. Budget $90–120k/quarter. Without a core engineering team further progress is not possible.
2. Start smart-contract development on testnet (Polygon Amoy). Open a GitHub repo with OpenZeppelin Contracts v5.x as the base, start with CFA1Token + PoolEscrow, deploy to Mumbai/Amoy testnet within 60 days.
3. Conclude a contract with Trail of Bits or OpenZeppelin for pre-audit consulting. $40–60k for 6 weeks of architectural review before the full audit — removes 60–70% of findings before the expensive audit.

Time to production mainnet: realistic — 10–12 months subject to adequate funding (see §6 Cost Estimate).

2. FINDINGS

2.1 DLT Choice — Polygon PoS

Status: Defensible decision but requires periodic re-evaluation.

Pros for a CASP under HO-159-N: - EVM compatibility opens access to the largest audit ecosystem (Trail of Bits, OpenZeppelin, ConsenSys Diligence, Certora) — for a regulated CASP this matters more than performance benefits. - Low gas costs: a quarterly NAV update on a €100M pool = $0.50–$2 per tx on Polygon vs $80–$300 on Ethereum L1 (per open documentation Q1 2026). For 28 quarterly Senior coupons + monthly Owner coupons (≈100 transactions/month) the cumulative annual gas — < $1,000. - Permissioned extensibility: Polygon Supernets / Edge allow a permissioned chain to be deployed if the CBA requires full sovereignty. The SAD correctly notes “DLT-agnostic at the Smart Contract Bridge level”. - MiCA readiness: Polygon Labs is in dialogue with ESMA, which matters more for EU diaspora investors than for Armenia itself.

Cons / risks: - Centralisation concerns. In Q1 2026 Polygon PoS has ≈100 validators, the top-5 control > 40% stake (per open data Polygonscan/Staking Dashboard). This is not decentralised in the Ethereum L1 sense, but decentralised enough for a CASP. What matters to the regulator is that the Platform does not control consensus — that removes the “is it really a DLT?” question. - Polygon TVL and activity in 2026: per open documentation Q1 2026, Polygon PoS TVL fluctuates in the $0.8–1.2B range, with 200–400k DAU. It is L2 #4–5 by volume after Arbitrum, Optimism, Base. Not dominant but stable. For the RWA track Polygon occupies a strong position (Centrifuge, Hamilton Lane partial deployment) — which gives a network effect. - Bridge risk. If the regulator requires “everything on Ethereum L1”, migrating through the Polygon ↔︎ Ethereum bridge is a non-trivial operation (the historical PolyNetwork incident is a lesson).

Alternatives — comparison:

Final DLT recommendation: Polygon PoS as Phase 1 with an explicit exit strategy to an Avalanche Subnet or Polygon zkEVM in Phase 2 (year 3+). Lock the DLT-agnostic boundary at the Smart Contract Bridge — which the SAD already does.

Transaction cost for a €100M pool (calculation): - Token mints (once at IPO): 70,000 Senior + 300,000 Junior = 370,000 mints. On Polygon PoS at 50 gwei: ~$0.01 per mint = $3,700. - NAV updates quarterly: 4 × year × $1 = $4/year. - Owner coupons monthly (≈100 owners): 1,200 tx × $0.5 = $600/year. - Senior coupon distributions quarterly (1 batch tx for up to 70k holders via Merkle drop): 4 × $20 = $80/year. - Custody operations (multi-sig add/remove): ≈50 tx × $2 = $100/year. - TOTAL year 1: ≈$4,500 in gas costs. Negligible vs operational opex.

2.2 Smart Contract Architecture

The SAD describes 7 contracts. I go through each.

CFA1Token (utility token, HO-159-N Art. 3):

The SAD proposes ERC-721 + soulbound (non-transferable). This is the right decision — CFA1 represents the owner’s share in a specific asset with a specific cadastral reference. ERC-20 would be a fungibility mismatch.

Recommendation: use ERC-5192 (Minimal Soulbound NFT, EIP-final) as the base. This is a standard auditors know. Do not improvise soulboundness via revert in _beforeTokenTransfer — that works but is less auditable. Per open documentation Q1 2026, OpenZeppelin Contracts v5.x have a preview implementation.

SeniorTrancheBond (security token):

The SAD proposes ERC-1400 or ERC-3643. ERC-3643 (T-REX) is preferred for a regulated CASP for three reasons: 1. T-REX is a live production standard used in EU regulated tokenization (Tokeny Solutions). MiCA-aligned. 2. ERC-1400 is a draft not approved by the Ethereum Foundation. Auditors are less confident. 3. T-REX builds in OnchainID — this resolves identity/KYC binding at the token level.

Junior Tranche ART (HO-159-N Art. 16):

The SAD proposes “an ERC-20 extension with NAV tracking (rebase or price oracle)”. The price-oracle approach (not rebase!) is the only correct one for a regulated ART.

Why not rebase: rebase changes each holder’s supply. This creates a UX disaster with custody providers, tax reporting (RF FNS, EU diaspora jurisdictions), DeFi integrations. Per open documentation Q1 2026, no regulated stablecoin/ART operator uses rebase in production (Maple Finance, Centrifuge, Ondo — all price oracle).

Concrete architecture: JuniorTrancheART = ERC-20 fixed supply (300k tokens, immutable post-issuance) + an external NAVOracle contract writing navPerToken quarterly. This gives an audit trail and removes supply-level manipulation risk.

PoolEscrow (multi-sig 3-of-5):

A 3-of-5 threshold is the correct choice. Analysis: - 2-of-5 — too weak (2-person collusion). - 4-of-5 — too strict (loss of 2 keys blocks operations; recovery expensive). - 3-of-5 — Coinbase Custody / BitGo industry standard. Tolerates 2 losses, requires sabotage of 3.

However the SAD lists “CEO + CTO + CFO + CCO + Independent Trustee” as 5 signers. This is a weak choice for two reasons: 1. 4 of 5 are internal Platform employees. The Independent Trustee should be a legal/regulated entity (an Armenian law firm or a Big4 escrow), not a single individual. 2. Geographic concentration risk: if 4 live in Yerevan, state pressure compromises the threshold.

Recommendation: change the composition to 2 internal + 3 external: (CEO + CTO) + (an independent Armenian law firm partner) + (an EU-based custody trustee) + (a CBA nominee — a separate read-only key, not part of signing — otherwise it conflicts with supervision). The threshold remains 3-of-5.

InsuranceBridge:

The SAD proposes off-chain proof + on-chain entry. Conceptually correct, but implementation requires: - Chainlink Any2Any messaging or Hyperlane for cross-chain insurer attestation if the insurer is not an Armenian CASP. - EIP-712 signed messages from the insurer — not “opaque bytes”, but structured typed data. - 7-day time-lock on disputed claims with multi-sig override.

Regulator Node (CBA):

The SAD says “read-only”. This is right both legally and technically.

A read-write regulator node would create a conflict of interest — the CBA would be a co-issuer. In the spirit of HO-159-N (Art. 6, 27, 30) the regulator is the supervisor, not the co-issuer.

Technically: a read-only node = a Polygon RPC archive node on the Platform’s infrastructure + an additional GraphQL/REST gateway with mTLS authentication (which the OpenAPI spec proposes in securitySchemes: mtlsCert). Architecturally correct. Latency target < 100 ms — achievable when hosted in Frankfurt with a private VPN tunnel to the CBA.

Add: streaming events via WebSocket with guaranteed delivery (at-least-once) for critical events — this is already implied in the SAD’s “Push notifications on material events”.

2.3 Smart Contract Security

HSM:

The SAD proposes “AWS CloudHSM (FIPS 140-2 Level 3) or Thales Luna”. Comparison:

Recommendation: Phase 1 (up to €25M TVL) — AWS CloudHSM + 5 YubiHSM 2 as cold backup for Shamir-share keys. Phase 2 (€25–100M) — migrate to Thales Luna in a Yerevan datacenter (a requirement of the RA Personal Data Protection Law for critical residents’ keys). Phase 3 (€100M+) — hybrid Fireblocks + Thales for separation of hot/warm/cold.

Audit Strategy:

Tender strategy at $50–100k: at $50k bracket you will not get a quality audit for a regulated CASP. The minimum budget for production readiness is $200–300k for two independent audits (Trail of Bits + OpenZeppelin) with $40k pre-audit consulting. The SAD correctly estimates $200–400k — but that is the floor, not the ceiling.

Bug Bounty:

Immunefi for CASP-grade RWA, minimum: $50k critical → $100k for production. Per open documentation Q1 2026, an average CASP-tier protocol on Immunefi pays $250k–$1M for criticals found in production. For €100M TVL the price of security must be ≥ 0.25% TVL = $250k for the bounty pool in the first year.

Formal Verification:

For NAVOracle, PoolEscrow and SeniorTrancheBond — yes, required. Certora or K Framework. About $150k on top of the standard audit, but it removes manipulation risk for the regulator.

For CFA1Token, GovernanceContract — no, excessive (standard ERC-721 behaviour).

Upgrade mechanism:

The SAD proposes UUPS proxy with a 7–14 day time-lock. This is right for Phase 1, but with a nuance:

• UUPS vs Transparent Proxy: UUPS is cheaper in gas, but the logic contract holds the upgrade function. If the developer makes a mistake in the new version and does not preserve the upgrade hook, the contract becomes immutable. For a regulated CASP this is an operational risk.
• Alternative: Beacon Proxy (EIP-1967) — centralised upgrade via a beacon. Suits multiple instances (if several pools are planned).
• Trust-minimisation tradeoff: a 14-day time-lock + multi-sig 3-of-5 on upgrade is right. Additionally: immutable after 36 months or €500M TVL — pre-coded upgradability sunset, so that investors receive an immutability guarantee.

2.4 Custody Architecture — Comparison with industry leaders

Final verdict: hybrid — self-built core custody (multi-sig + HSM) for CFA1Token (physically tied to Armenian real estate, not exportable from Armenia) + Fireblocks/Copper for investor-facing Senior/Junior tokens (where liquidity and UX matter more than sovereignty). This removes 60% of Phase 1 operational risk while preserving regulatory compliance.

HSM + MPC: the SAD mentions HSM but not MPC (Multi-Party Computation). MPC outperforms pure multi-sig in modern production deployments for two reasons: 1. MPC does not publish the threshold on-chain (privacy advantage for the regulator). 2. MPC supports any signature scheme (not just ECDSA), including BLS for aggregation.

Recommendation: Phase 2 (after Audit 2) — migrate from naive multi-sig to a TSS (Threshold Signature Scheme) implementation via ZenGo X / Web3Auth tKey / Fireblocks MPC. Full backward compatibility (the contract sees one signature).

Cold/Hot wallet ratio for €100M: - Cold (HSM-protected, multi-sig 3-of-5, geographically distributed): 90% = €90M. Rare transactions, 24h time-lock. - Warm (HSM-protected, multi-sig 3-of-5, online): 8% = €8M. Quarterly coupons, redemptions. - Hot (MPC/Fireblocks, automated): 2% = €2M. Daily operations, ≤€500k per tx limit.

This is the Coinbase Custody / BitGo standard. The SAD does not specify the ratio — I recommend including it explicitly.

Insurance: Lloyd’s of London via Marsh Crypto — $100M coverage will cost a 0.5–1.2% premium = $500k–$1.2M/year. This is a large opex line, it must be reflected in the financial model.

2.5 Oracle and NAV Validation (P3/P4 Patents)

This is the weakest spot of the entire architecture.

The SAD says “Chainlink Functions or proprietary oracle”. That is concept level, not solution level.

Comparison of oracle solutions:

Correct NAV oracle architecture for Noah’s Ark:

Off-chain (licensed RA appraisers, 3+ independent):
  └─ Each produces a signed attestation (EIP-712) with {timestamp, navPerToken, evidence_hash}
       └─ Upload to IPFS + sign hash via reputation contract (AMD stake at slashing risk)
            └─ Chainlink Functions / API3 aggregator (off-chain compute):
                 └─ Median + outlier rejection (if spread > 5%)
                      └─ On-chain commit to the NAVOracle contract:
                           └─ Time-weighted average over a 7-day window for large redemptions
                                └─ JuniorTrancheART.updateNAV(median) with multi-sig 3-of-5 confirmation for changes > 10%

Gas cost quarterly: ≈$5–$20 per NAV update on Polygon. Negligible.

Latency: off-chain valuation cycle 30–60 days (normal for real estate), on-chain commit < 1 hour after aggregation.

Fallback on oracle downtime: 1. Last known NAV is held for 7 days (protection against temporary outage). 2. After 7 days — redemptions auto-pause (protection against stale-price arbitrage). 3. Multi-sig 3-of-5 may manually force-commit an emergency NAV with public justification.

Regulator audit trail:

The CBA receives access to: - On-chain history of all updateNAV events (immutable). - IPFS attestations from each appraiser (with on-chain hash). - Reputation contract state (which appraisers are active, which have been slashed). - API endpoint for querying NAV at any historical date.

This covers the P3 (NAV validation) patent — but code must be written and proven.

P4 (KYC + DTA mapping) patent — separately discussed in §2.6.

2.6 KYC Architecture (P4 Patent)

Cross-jurisdictional KYC:

The Platform addresses 3 investor types: RA Ministry of Finance, diaspora (EU/US/RF), institutional. Each = a different jurisdiction = different KYC requirements.

Recommended stack:

The SAD lists Onfido/Sumsub/Veriff as “or”. I recommend specifics: - Primary: Sumsub — best CIS + EU coverage and a good Travel Rule integration. - Fallback: Onfido — for US/UK diaspora citizens (Sumsub is weaker in the US). - Local: Veriff not needed (overlap with Sumsub).

SSI / DID for the diaspora:

Polygon ID v2 (on ZK proofs) — a strong innovation for the diaspora. The user goes through KYC once with a CASP partner, receives a credential, and can present it to Noah’s Ark without a full re-KYC (only a ZK proof of a valid credential). Per open documentation Q1 2026, Polygon ID is integrated with Sumsub and Quadrata.

This converts the P4 patent from “concept” to “implementation” — I recommend making P4 a central feature of the M3 mobile app (Investor Cabinet).

GDPR vs immutable blockchain:

A classic challenge. The SAD solution references “off-chain PII + on-chain hash”. Correct. Specifics:

• On-chain: only the hash of KYC credentials (no PII).
• Off-chain: Hashicorp Vault + isolated PostgreSQL in Yerevan (residents) or Frankfurt (non-residents).
• Right to be Forgotten (GDPR Art. 17): delete the off-chain record + revoke the credential via Polygon ID (the credential becomes invalid). The on-chain hash remains (immutable) but is useless without the off-chain record.
• Retention: 7 years after termination of the relationship (RA AML + EU AMLD). Then full purge.

This is GDPR-compliant and AML-compliant at the same time.

2.7 Mobile Application (PWA + React Native)

Phase 1 PWA (06_Working_PWA/index.html — 94k LoC):

Code review: executed at a professional level. Vanilla JS + CSS custom properties + Service Worker. The stack is minimal, no framework boilerplate. This is right for an MVP.

What is good: - Lighthouse PWA target ≥ 95 — achievable. - WCAG AA accessibility — a serious commitment (most fintech PWAs ignore it). - Multilingual (RU/EN/HY) with a switcher — critical for the diaspora. - Theme auto-detection (dark/light) — UX quality.

What must be improved: - Web Push on iOS: requires iOS 16.4+ (the SAD notes this correctly). iOS share in the diaspora is high (~50%) — a significant limitation. Mitigation: email + Telegram notifications as fallback. - WebAuthn for biometrics: I do not see WebAuthn integration in the PWA index.html. Needs to be added — it is a blocker for user-side smart-contract signing (M3). - Web3 wallet integration: the PWA should integrate with MetaMask Mobile, Rainbow, WalletConnect v2. I do not see this in the current code.

Phase 2 React Native (Expo SDK 51+, TypeScript strict):

A realistic timeline with the current architecture: 6–9 months from the start (one senior RN dev + one junior).

What is good in the architectural choice: - Expo managed — removes 80% of iOS-build pain. GitHub Actions macOS runners are free for public repos. - React Navigation 6 + Zustand + i18next — a solid stack, no exotica. - NativeWind + Reanimated — modern, performant.

What to add: - WalletConnect v2 (@walletconnect/react-native-v2) — for mobile wallet integration. - Detox for E2E testing — critical for fintech apps. - Sentry for crash reporting. - Firebase App Check for anti-tamper (protection against reverse engineering).

Offline-first for the diaspora:

The SAD mentions “Workbox for offline support” and “queue for synchronisation”. This is the right direction. Specifics:

• KYC capture offline → IndexedDB encrypted → background sync.
• Pool data read offline → static cache + diff sync.
• Transactions (orders, signing) — must be online-only (you cannot sign a transaction offline without exposing private keys in storage; even IndexedDB encryption does not protect against advanced attacks).

Push notifications APNS/FCM: not configured in the PWA (only Web Push). This is a Phase 2 / React Native task.

Biometrics: - PWA: WebAuthn (Touch ID on iOS 16.4+, Face ID, Windows Hello). - React Native: expo-local-authentication + Secure Enclave storage for biometric-protected keys.

2.8 Tech debt and risks (current state as of 11.05.2026)

Critical gaps:

Three priority technical steps before Series A:

1. Hire the core engineering team (3 FTE: CTO/Lead Solidity, Senior Solidity, Senior SRE) by 1 August 2026.
2. Launch the smart-contract development repo (private GitHub) with OpenZeppelin Contracts v5.x base + the first deployment on Polygon Amoy testnet by 30 September 2026.
3. Sign a pre-audit consulting contract with Trail of Bits ($40k, 6 weeks) by 1 November 2026 — removes architectural findings before the expensive audit.

Engineering team for Phase 1 (12 months):

A realistic blended salary for a Yerevan-based team with ≥40% remote (Yerevan rate + Eastern European remote): $80–100k average = $800k–$1.0M/year team cost.

Year-1 CapEx + OpEx tech budget:

3. TECHNICAL RISK MATRIX

Top-3 risks by Score: 1. Smart contract vulnerability (15) → mitigation: dual audit + formal verification. 2. NAV oracle manipulation (15) → mitigation: multi-source + median + time-weighted + slashing. 3. Insurance bridge inconsistency (12) → mitigation: EIP-712 + dispute window.

4. RECOMMENDED TECHNOLOGY STACK

Confirmed (no change): - Polygon PoS as Phase 1 DLT. - React + Next.js / Vanilla JS PWA. - React Native (Expo SDK 51+). - AWS Frankfurt (primary) + Hetzner Yerevan (secondary). - Cloudflare Edge. - Kubernetes (EKS + K3s). - Terraform + Helm. - PostgreSQL 16 + ClickHouse + TimescaleDB. - Redis + Kafka. - AWS CloudHSM. - Prometheus + Grafana + Loki + Tempo.

Updated (recommended changes):

Added (new components): - Polygon ID v2 for SSI/DID. - Notabene for Travel Rule. - Detox for E2E mobile testing. - Sentry for crash reporting. - Firebase App Check for anti-tamper mobile. - GitHub Enterprise + signed commits. - Snyk + Dependabot + SonarQube (SAST/SCA).

5. TECH ROADMAP — 12 MONTHS TO SERIES A

Cumulative cost (12 months): see §6.

6. COST ESTIMATE — YEAR 1 BUDGET

Comparison with the SAD’s $470–700k mobile-only estimate: the mobile part is ≈$300–400k of the overall $2.56M tech budget. The rest — smart contracts, audits, infrastructure, custody, KYC, insurance.

Year-2 Steady-State Tech OpEx (post-Series A): $1.8–2.2M/year (engineering team grows to 15 FTE + recurring audits + insurance renewal + cloud scale + bug bounty).

7. AUDIT CONCLUSION

The “Noah’s Ark” architecture (NK-ARCH-001/2026) is a professional SAD at the level of a regulated CASP. Defense-in-depth logic is correct, the choice of Polygon PoS is defensible, the legal mapping to HO-159-N + Reg. 7/01–7/05 is complete. This is not “whitepaper-vapourware” — a team that knows the industry sits behind the document.

However, production readiness is missing. Between the SAD and a mainnet-deployable system there are 10–12 months of work by 8–10 FTE engineers with a budget of $2.5–3M for year 1. Before that, the CBA will not issue a CASP licence under Reg. 7/01: “technical capacity to perform obligations” means code in production, not a PDF.

The project’s technology risk is middle-low subject to adequate funding. All architectural choices are conservative (no exotica), an industry stack, proven vendors. The principal risks are execution risk (team hiring) and regulatory engagement (the CBA must approve the read-only node before mainnet), not architectural risk.

Recommendation for the Series A pitch: do not present the architecture as “ready” — it is ready at the design level, not at the implementation level. Present as “architecturally validated, execution-funded” — that honesty plays better than overselling in discussions with EBRD, IFC, MiCA-aware family offices.

SUMMARY FOR THE CLIENT (under 250 words)

Aslan, the technical audit of Noah’s Ark across 8 sections.

What works. Document NK-ARCH-001/2026 is a professional SAD at the regulated-CASP level. The choice of Polygon PoS is defensible (low gas, audit ecosystem, MiCA readiness). Defence is multi-layered, the legal mapping is complete, the DLT-agnostic boundary is at the right level. The working PWA is competently done (vanilla JS, WCAG AA, RU/EN/HY). The OpenAPI spec is correct (mTLS for the regulator, JWT for users). The architecture is ready for tech due diligence by EBRD/IFC.

What must be finished (three gaps). First — no Solidity codebase. This is a blocker for the CBA’s CASP licence under Reg. 7/01. 6 months of development + 2 independent audits ($300k Trail of Bits + OpenZeppelin) required. Second — HSM not procured, key ceremony not performed. Without this, €100M custody cannot launch. Third — the NAV oracle is at the concept level “Chainlink or proprietary”. This is the architecture’s weakest link — 3+ independent RA appraisers + median aggregator + on-chain signature verification + time-weighted average are required.

Three first steps before Series A (90 days). Hire CTO + Lead Solidity + Lead SRE (3 FTE, $90–120k/quarter). Start smart-contract development on Polygon Amoy testnet with OpenZeppelin Contracts v5.x. Sign pre-audit consulting with Trail of Bits ($40k, 6 weeks) before the expensive audit — removes 60–70% of findings.

Year-1 tech budget. $2.56M: team 10 FTE ($950k), 2 audits ($300k), formal verification ($150k), HSM ($60k), KYC stack ($120k), Lloyd’s insurance ($200k), the rest — infrastructure + bounty + ISO 27001 + contingency.

Time-to-mainnet: 10–12 months with adequate funding. Production readiness is now 2/10. After the roadmap — 8/10.

Architectural risk is low. Execution risk is about hiring and funding. Technically the project is viable.

Audit performed by: Yuki Tanaka, MSc Computer Science (MIT) CTO, TokenForge · ex-Polygon Labs Principal Architect · ex-Coinbase Crypto Custody Lead

Date: 11 May 2026 Document: NK-AUDIT-005/2026

© Prepared as an independent technical audit for internal evaluation of the Noah’s Ark Platform project (rightsholder — Kagirov Abdul-Khakim Akhmadovich, 2026). All referenced products and companies are the property of their respective rightsholders.