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 system comprises 37 Rust crates organized in a 5-layer architecture spanning core cryptographic primitives through application-layer APIs. It maintains native bridge connectivity to the XRP Ledger via XLS-38d sidechain protocols, integrates institutional custody through Fireblocks MPC and BitGo multi-signature infrastructure, and supports 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 system is structured as a 5-layer Cargo workspace comprising 37 independently testable crates. Each layer enforces strict dependency boundaries: lower layers never depend on higher layers, and cross-layer communication occurs exclusively through well-defined trait interfaces.

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: 166+ integration and unit tests verify all critical paths. 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. 5-Layer Stack Design

Each layer of the UnyKorn stack encapsulates a specific domain of functionality with clear API boundaries.

5.1 L1 — Core Infrastructure

The foundation layer provides cryptographic primitives (Ed25519 signing, SHA-256 hashing, BLAKE3 state hashing), the network's type system (addresses, transactions, blocks, receipts), the module registry for dynamic module loading, the node runtime lifecycle manager, genesis configuration parsing, and the VM/automation engine for programmable transaction execution.

5.2 L2 — Consensus & State

The consensus layer implements the PoS engine with 6-class validator hierarchy, a fee-priority mempool with configurable size limits and eviction policies, the 2-of-3 policy quorum evaluator, the deterministic state machine for transaction application, and the RocksDB-backed persistent ledger with Merkle state roots.

5.3 L3 — Domain Modules

Domain modules implement specific institutional functions: treasury management with multi-signature spending policies, decentralized identity (DID) with W3C Verifiable Credentials, KYC/AML compliance with configurable rule engines, on-chain governance with weighted voting, RWA tokenization with SEC-compliant issuance workflows, carbon credit tracking with verified retirement, energy market settlement with time-of-use pricing, intellectual property registry, notarization services, top-level domain registry, ERC-6551 token-bound accounts for institutional vaults, and credit ledger facilities.

5.4 L4 — Funding & Finance

The funding layer provides unified multi-rail payment orchestration through the FundingRouter, which routes transactions across XRPL (native XRP and issued currencies), Fireblocks (MPC custody with 50+ blockchain support), BitGo (multi-signature HSM custody), and Circle (USDC/EURC minting, redemption, and CCTP cross-chain transfers). The FundingLedger maintains a consistent audit trail across all rails. The trade finance engine implements UCP 600 Letters of Credit with atomic document exchange.

5.5 L5 — Application Layer

The application layer exposes the network through JSON-RPC APIs (compatible with standard blockchain tooling), Prometheus-compatible metrics endpoints, OpenAI function-calling integration for AI-driven transaction composition, an affiliate tracking system, MCP (Model Context Protocol) server for agentic AI access, RAG (Retrieval-Augmented Generation) system for network knowledge queries, and administrative dashboard APIs.

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