Whitepaper

1. Abstract

UnyKorn is a purpose-built Layer 1 blockchain designed for institutional-grade trade finance, multi-custody asset management, and regulatory-compliant transaction processing. Unlike general-purpose chains optimized for throughput alone, UnyKorn integrates trade finance primitives (UCP 600, Letters of Credit, Bills of Lading) directly into its consensus layer, enabling atomic settlement of real-world trade instruments without reliance on off-chain oracles or intermediary settlement layers.

The current production stack comprises 17 Rust crates across a 4-tier architecture (UnyKorn L1 Runtime, Genesis Protocol, FTH Document Intelligence, and LPS-1 Literary Protocol), with 5 Solidity smart contracts and ~130 TypeScript source files. Forward-looking design includes native bridge connectivity to the XRP Ledger via XLS-38d sidechain protocols, institutional custody through Fireblocks MPC and BitGo multi-signature infrastructure, and stablecoin settlement through Circle USDC and CCTP cross-chain transfer protocols.

This whitepaper specifies the complete technical architecture, consensus design, economic model, and governance framework of the UnyKorn network.

2. Introduction & Problem Statement

Global trade finance represents a $10 trillion annual market dominated by paper-based processes, manual reconciliation, and fragmented settlement infrastructure. Existing blockchain solutions either optimize for retail DeFi use cases (high speed, low compliance) or enterprise permissioned ledgers (high compliance, limited interoperability). Neither addresses the core institutional requirement: programmable settlement of regulated trade instruments with verifiable custody chains and multi-jurisdictional compliance.

2.1 Current Limitations

• Settlement Latency: Traditional trade finance settlement involves 5-30 day cycles through SWIFT intermediaries and correspondent banking networks. Even “fast” blockchain settlement lacks the document verification layer required for trade instrument finality.
• Custody Fragmentation: Institutional assets are held across multiple custody providers with incompatible key management, audit trails, and compliance frameworks. No existing L1 provides unified multi-custody orchestration at the consensus level.
• Compliance Gap: Public chains lack native KYC/AML policy enforcement. Private chains lack interoperability. Both require off-chain compliance layers that introduce trust assumptions and settlement risk.
• Bridge Risk: Cross-chain bridges remain the primary attack vector in blockchain infrastructure. Custodial bridges introduce counterparty risk; trustless bridges introduce smart contract risk.

2.2 UnyKorn's Approach

UnyKorn addresses these limitations by embedding trade finance, custody orchestration, and compliance enforcement directly into the blockchain's state machine. Rather than building compliance as an application layer concern, UnyKorn treats regulatory policy as a consensus-level primitive — transactions that fail policy quorum validation are rejected at the mempool level, before block inclusion.

3. Architecture Overview

The UnyKorn production system is structured as a 4-tier stack comprising 17 Rust crates, 5 Solidity contracts, and ~130 TypeScript source files. Each tier enforces strict dependency boundaries — lower tiers never depend on higher tiers — and communication occurs exclusively through well-defined interfaces. The forward architecture extends to 5+ layers with additional domain, funding, and application modules.

3.1 Design Principles

• Zero unsafe Rust: The entire codebase compiles with no unsafe blocks. Memory safety is enforced by the Rust borrow checker at compile time.
• Trait-driven extensibility: All cross-layer interfaces are defined as Rust traits with async support, enabling implementation swapping without recompilation of dependent crates.
• Deterministic builds: Cargo workspace with pinned dependencies ensures identical binary output across build environments.
• Test coverage: 398+ integration and unit tests across the Rust stack (49 L1 runtime + 349 Genesis Protocol), plus 58 LPS-1 contract/pipeline tests. Each crate maintains its own test suite independent of other crates.

4. Consensus Mechanism

UnyKorn employs a Proof-of-Stake consensus with a hierarchical 6-class validator structure. Unlike flat PoS systems where all validators are equivalent, UnyKorn's validator classes encode institutional roles directly into the consensus process.

4.1 Validator Classes

4.2 Block Production

Block production follows a weighted round-robin schedule where validator selection probability scales with both stake weight and class multiplier. Target block time is 3,000ms with throughput of 10,000 transactions per block. Block finality is achieved after 2/3+ weighted stake confirmation, with an average finality window of 2 blocks (6 seconds).

4.3 Policy Quorum

The Policy Quorum mechanism requires 2-of-3 compliance validators to approve transactions involving regulated instruments (trade finance documents, custody transfers, cross-border settlements). This operates as a pre-consensus filter — transactions failing policy quorum are rejected from the mempool before block proposal.

5. 4-Tier Stack Design (Production)

The production stack is organized into four tiers, each encapsulating a specific domain of functionality with clear API boundaries. Additional domain, funding, and application layers are in active development.

5.1 T1 — UnyKorn L1 Runtime (Rust, 4 core crates)

The L1 runtime (Popeye-Tars-Mars-Tev) implements the blockchain runtime with strict trust boundaries. POPEYE handles P2P networking via libp2p gossipsub — it does NOT mutate state. TEV provides the cryptographic gate with Ed25519 signature verification in 96-byte transport format — it is stateless. MARS is the deterministic state machine and execution engine — it does NOT touch networking or disk. TAR handles persistent storage with crash-safe writes and atomic commits — it does NOT validate data. NODE is the binary entrypoint with TOML configuration and 3-node devnet orchestration. Block time: 3s. Chain ID: "unykorn-mainnet". Trust model: "If MARS says no, the network doesn't matter."

5.2 T2 — Genesis Protocol (Rust, 13 crates)

The Genesis Protocol (FTHTrading/AI) is a deterministic evolutionary economics engine with 349 passing tests, 1,820 experiment worlds, and 910,000 total epochs. Key crates include genesis-dna (cryptographic genome), metabolism (ATP energy ledger), genesis-anchor (dual-chain anchoring with SHA-256 state chain + BLAKE3 genome chain), genesis-multiverse (parallel world instantiation), and genesis-experiment (statistical reporting). Deterministic seed: 20260222. DOI: 10.5281/zenodo.18729652.

5.3 T3 — FTH Document Intelligence (TypeScript, ~130 files)

FTH DOCS (FTHTrading/DOCS) is an 8-layer sovereign document infrastructure: Core Engine (32 files), Signing Gateway (4 files), SDC (7 files), SCA with Telnyx SMS/Voice (6 files), Cloudflare Zero Trust Perimeter (5 files), IPFS/Kubo Ledger & Storage (4 files), Operations (10 files), and 3-tier Governance (5 files). Crypto: SHA-256 fingerprinting, AES-256-GCM encryption, PBKDF2 key derivation. 10 system invariants including "No unsigned document crosses any trust boundary."

5.4 T4 — LPS-1 Literary Protocol (Solidity + JavaScript)

The LPS-1 Reference Implementation (FTHTrading/LPS-1) provides 5 Solidity contracts: LiteraryAnchor (on-chain Merkle root anchoring), PublishingKernel V2 (state machine: DRAFT → COMPILED → HASHED → MERKLE_BUILT → PINNED → ANCHORED → PUBLISHED), RoyaltyRouter (per-edition revenue distribution), and AuthorIdentity (ECDSA secp256k1 verification with 48-hour timelock). The deterministic pipeline produces 4 Merkle trees (manuscriptRoot, artifactRoot, imageRoot, promptRoot) combined into a single editionRoot. 58 tests, Level 3 conformance.

5.5 Forward Architecture — Funding & Application Layers

Active development extends the stack with multi-rail payment orchestration (XRPL bridge via XLS-38d, Fireblocks MPC custody, BitGo multi-signature HSM, Circle USDC/CCTP), UCP 600 trade finance settlement, JSON-RPC / MCP server APIs, compliance policy enforcement at the consensus level, and AI-driven transaction composition. These modules build on the production foundation established by the L1 Runtime, Genesis Protocol, and LPS-1 anchoring contracts.

6. Trade Finance Engine

UnyKorn's trade finance engine implements the core instruments of international trade: Letters of Credit (UCP 600), Bills of Lading, Certificates of Origin, Insurance Certificates, and Inspection Reports. Each instrument is represented as a first-class on-chain object with its own lifecycle state machine.

6.1 Letter of Credit Lifecycle

The LC lifecycle implements the following state transitions: Draft → Issued → Advised → Amended → Confirmed → Presented → Examined → Accepted → Paid → Closed. Each transition requires cryptographic signatures from the appropriate parties (issuing bank, advising bank, beneficiary) and passes through the policy quorum for compliance validation.

6.2 Document Verification

Trade documents are hashed and anchored on-chain with BLAKE3 content hashes. Full document content is stored off-chain in IPFS or institutional document management systems, with on-chain references providing tamper-evident verification. Document presentation follows UCP 600 Article 14 examination standards implemented as deterministic rule evaluation.

7. XRPL Bridge Integration

The UnyKorn-XRPL bridge implements the XLS-38d sidechain specification, enabling bidirectional asset transfer between UnyKorn and the XRP Ledger. The bridge supports native XRP, XRPL-issued currencies, and cross-chain escrow operations.

7.1 Bridge Architecture

The bridge operates through a network of Infrastructure-class validators running both UnyKorn and XRPL nodes. Bridge transactions follow a commit-verify-finalize pattern: assets are locked in an XRPL escrow condition, the lock proof is verified by UnyKorn bridge validators, and corresponding assets are minted on UnyKorn upon consensus confirmation.

7.2 Supported Operations

• XRP Transfer: Native XRP lock/unlock through cryptographic escrow conditions
• Issued Currency Bridge: Trust line-based issued currency transfer with configurable issuer policies
• DEX Integration: Direct order placement on XRPL's built-in decentralized exchange from UnyKorn transactions
• Escrow Automation: Time-locked and condition-locked escrow creation for trade finance settlement

7.3 Security Model

Bridge security relies on economic incentives (Infrastructure validators stake a minimum 100,000 UNY), multi-party verification (3-of-5 bridge validator threshold), and automatic circuit breakers that halt bridge operations if anomalous transfer patterns are detected.

8. Multi-Custody Funding Rails

The Funding Engine provides a unified interface for institutional custody and payment operations across four integrated providers, orchestrated through the FundingRouter.

8.1 Fireblocks Integration

Fireblocks MPC (Multi-Party Computation) custody provides keyless signing infrastructure for institutional asset management. UnyKorn integrates through Fireblocks' JWT-authenticated REST API, supporting vault management, transaction signing, policy engine integration, and webhook-driven status updates. The MPC architecture eliminates single points of key compromise while maintaining institutional-grade audit trails.

8.2 BitGo Integration

BitGo multi-signature custody provides HSM-backed key management with configurable m-of-n signing policies. UnyKorn integrates BitGo's wallet management, transaction building, and webhook notification systems. BitGo's regulated custody (BitGo Trust, BitGo New York Trust) provides the regulatory infrastructure required for institutional deployment.

8.3 Circle Integration

Circle's USDC and EURC stablecoin infrastructure provides fiat-pegged settlement rails. UnyKorn integrates Circle Mint (direct USDC minting/redemption), Circle Payments (fiat on/off ramps), and CCTP (Cross-Chain Transfer Protocol) for trustless cross-chain USDC transfers. This enables institutions to settle trade finance instruments in price-stable assets without volatility exposure.

8.4 Orchestration

The FundingRouter selects optimal execution paths based on asset type, destination chain, settlement speed requirements, and cost parameters. The FundingLedger maintains a unified double-entry accounting record across all rails, enabling real-time position reporting and regulatory audit compliance.

9. Compliance Framework

Compliance in UnyKorn is not an afterthought — it is a consensus-level primitive. The compliance framework operates at three layers:

9.1 Identity Layer (DID)

All network participants maintain on-chain Decentralized Identifiers (DIDs) linked to off-chain Verifiable Credentials (VCs). KYC providers issue VCs that are cryptographically verified on-chain without exposing personal data. The DID system supports institutional hierarchies — a single institution can have multiple operator DIDs with role-based permissions.

9.2 Policy Engine

The configurable policy engine evaluates transactions against jurisdiction-specific rule sets. Rules are expressed as deterministic predicates evaluated against transaction metadata and participant credentials. Example policies: maximum transaction value thresholds, geographic restrictions, sanctions list screening, and beneficial ownership verification requirements.

9.3 Audit Trail

Every transaction, policy evaluation, and validator action is immutably recorded with full provenance metadata. The audit trail supports regulatory examination requirements across jurisdictions including SEC, FinCEN, FCA, MAS, and HKMA regulatory frameworks. Export formats include JSON, CSV, and regulatory-specific reporting standards.

10. Tokenomics & Validator Economics

10.1 UNY Token

UNY is the native network token used for transaction fees, validator staking, governance voting, and bridge collateral. Total supply is fixed at genesis with no inflationary emission schedule. Transaction fees are partially burned (50%) and partially distributed to validators (50%), creating deflationary pressure proportional to network utilization.

10.2 Validator Rewards

Validators earn rewards from three sources: block production rewards (diminishing schedule over 10 years), transaction fee distribution (50% of all fees, weighted by class and stake), and bridge operation fees (fixed basis-point fee on all cross-chain transfers). Slashing penalties apply for downtime (progressive reduction starting at 1%), equivocation (immediate 10% slash), and policy quorum violation (5% slash plus class demotion review).

10.3 Fee Structure

Transaction fees are calculated using a base fee plus gas model where gas represents computational complexity. Base fees adjust dynamically based on block utilization (EIP-1559 style). Priority fees enable expedited inclusion for time-sensitive trade settlement.

11. AI & MCP Agentic System

UnyKorn integrates AI capabilities at the application layer through two primary interfaces: the MCP (Model Context Protocol) server and the RAG (Retrieval-Augmented Generation) knowledge system.

11.1 MCP Server

The MCP server exposes UnyKorn's full API surface as structured tools callable by AI agents. This enables autonomous agents to query network state, compose transactions, evaluate compliance policies, and monitor bridge operations through natural language interaction. The MCP server implements the Model Context Protocol specification with full tool discovery, parameter validation, and execution sandboxing.

11.2 RAG Knowledge System

The RAG system indexes the complete UnyKorn codebase, documentation, transaction history, and network metrics into a vector store. AI queries are augmented with relevant context before response generation, ensuring factual accuracy for technical support, compliance queries, and operational monitoring. The system supports both real-time network queries and historical analysis.

11.3 Agentic Workflows

AI agents can execute multi-step workflows: monitoring bridge health, automatically escalating anomalies to compliance validators, generating regulatory reports, and providing real-time trade finance status updates. All agentic actions are logged with full audit trails and require appropriate authorization levels.

12. Security Model

12.1 Cryptographic Foundation

All signing operations use Ed25519 (Curve25519 twisted Edwards curve) providing 128-bit security. Transaction hashing uses SHA-256 for compatibility with XRPL, while state hashing uses BLAKE3 for performance (3x faster than SHA-256 on modern hardware). Key derivation follows BIP-32 hierarchical deterministic paths.

12.2 Network Security

P2P communication is encrypted with Noise Protocol Framework (IK pattern). Node identity is bound to Ed25519 keypairs. Eclipse attack resistance is provided by mandatory validator connectivity requirements (each validator must maintain connections to at least 70% of the validator set). Sybil resistance is economic — validator class requirements establish minimum cost-of-attack thresholds.

12.3 Bridge Security

Cross-chain bridge operations employ multi-party threshold signing (3-of-5 bridge validators), rate limiting (configurable per-epoch transfer caps), and automatic circuit breakers. The bridge operates on a pessimistic security model — any single bridge validator can halt operations by withholding signature.

13. Network Topology & Node Classes

The UnyKorn network supports multiple node types optimized for different operational roles:

14. Governance Framework

On-chain governance follows a weighted voting system where vote power is determined by validator class, stake amount, and network participation history. Proposals follow a lifecycle: Draft → Discussion (7 days) → Voting (14 days) → Execution (timelock) → Active.

Governance scope includes: network parameter adjustments, validator class requirements, policy quorum rule changes, bridge operator approvals, module activation/deactivation, and treasury spending proposals. Constitutional parameters (maximum supply, consensus algorithm, minimum validator count) require supermajority (80%+ weighted) approval.

15. Roadmap

16. .x Sovereign Soulbound Identity Protocol

The .x naming system provides non-transferable, protocol-native identity tokens minted directly on the UnyKorn L1 runtime. Unlike tradable NFTs, .x identifiers are soulbound — permanently bound to the originating Ed25519 wallet and cannot be transferred, listed on secondary markets, or reassigned. This design ensures that protocol citizenship is earned, not purchased.

16.1 Identity Architecture

Each .x identity is composed of: (1) a human-readable namespace (e.g., kevan.x), (2) a SHA-256 document hash derived from sha256(wallet + namespace + timestamp + tier + memberID + network), (3) an IPFS/Kubo content identifier for off-chain metadata backup, (4) a hash-chain anchor recording the minting transaction on TAR ledger, and (5) an Ed25519 public key binding that cryptographically locks the identity to the owner's wallet.

The soulbound invariant is enforced at the TEV validation gate: any transaction where sender ≠ original_wallet is rejected. Base metadata is immutable post-mint. Upgradeable overlays are achievable only through governance consensus. Member IDs are sequential starting at 1000, formatted as UNY-X-XXXX.

16.1.1 Runtime Pipeline

Identity and asset layers inherit security from runtime finality. Every .x mint and every artifact commit traverses the full L1 pipeline:

  ┌──────────────────┐     ┌──────────────────┐     ┌──────────────────┐
  │  Untrusted Input │─────│  POPEYE           │─────│  TEV              │
  │  (User request)  │     │  Block Producer   │     │  Validation Gate  │
  │                  │     │  libp2p gossipsub │     │  Ed25519 verify   │
  │                  │     │  Peer discovery   │     │  Soulbound check  │
  └──────────────────┘     └──────────────────┘     │  sender == owner  │
                                                     └────────┬─────────┘
                                                              │
                           ┌──────────────────┐     ┌────────▼─────────┐
                           │  MARS             │─────│  IPFS / Kubo     │
                           │  Execution Engine │     │  Content Anchor  │
                           │  State transition │     │  CID generation  │
                           │  Deterministic    │     │  Off-chain backup│
                           └────────┬─────────┘     └──────────────────┘
                                    │
                           ┌────────▼─────────┐
                           │  TAR              │
                           │  Finality Layer   │
                           │  Atomic commit    │
                           │  Hash-chain ledger│
                           │  SHA-256 anchor   │
                           └──────────────────┘
              

Identity and asset layers inherit security from runtime finality. No .x identity or artifact exists outside this pipeline. The TEV gate enforces soulbound invariants at the cryptographic level — if sender ≠ original_wallet, the transaction is rejected before reaching MARS execution.

16.2 Asset Classification

16.3 Rarity Tier System (Tradable NFTs)

AI Studio artifacts are classified into five rarity tiers determined by cryptographically emergent randomness — the SHA-256 hash of each artifact determines its tier via modular arithmetic. This makes rarity provably random, tamper-proof, and not user-selectable. Supply is capped per season.

16.3.1 Season-Based Release Structure

Artifacts are released in seasons to prevent supply dilution and maintain collector value. Each season has a fixed mint cap and thematic identity:

16.4 Marketplace Integration

Tradable NFTs (AI Studio artifacts) generate OpenSea and Rarible-compatible metadata conforming to the ERC-721 metadata standard. Each artifact includes: name, description, IPFS image URI, trait attributes (Rarity Tier, Max Supply, Style, .x Identifier, Anchor Height, Protocol, Fingerprint, Storage, Pipeline), seller_fee_basis_points for royalty enforcement, and fee_recipient for creator payments.

All artifacts are named sequentially starting at 1000 (e.g., art-1042.x) and anchored via the full POPEYE → TEV → IPFS/Kubo → MARS → TAR pipeline before marketplace listing. The on-chain SHA-256 hash serves as tamper-proof provenance verification.