한

Maroo

A Compliant, Open Sovereign Layer 1 Blockchain for the Korean Won Economy

January 2026

Hashed Open Finance Hashed ShardLab Delight Labs

Table of Contents

  1. Overview
  2. Problem Definition
  3. Related Projects and Comparison
  4. Maroo Design Principles
  5. Platform Architecture
    • 5.1 Core Components
    • 5.2 Network and Consensus
    • 5.3 Execution Environment
    • 5.4 Node Roles
    • 5.5 Identity and Account Model
    • 5.6 Transaction Model and Regulatory Compliance
    • 5.7 Privacy Design
  6. Conclusion
  7. References

Appendix: List of Diagrams

1. Overview

1.1 Vision and Mission

Maroo is a compliant, open sovereign Layer 1 blockchain for the KRW-denominated economy. The Korean digital economy is already thriving across online and mobile platforms. Yet practical on-chain financial infrastructure for everyday use by individuals and businesses remains nonexistent. Today’s major blockchains were never designed to accommodate customer experience, data protection, or regulatory compliance. This creates friction for regulators and consumers, while raising adoption barriers for developers and enterprises looking to build real-world applications.

Maroo’s vision is to build an open, trustworthy, and sustainable blockchain infrastructure for the KRW-denominated economy. We achieve this by designing a blockchain that embraces both regulatory alignment and permissionless innovation. This is a new paradigm where compliance and openness coexist.

1.2 Core Values

Maroo overcomes the limitations of existing blockchains through five core mechanisms.

KRW-Native Blockchain: All gas fees on Maroo are paid in a KRW-pegged stablecoin (hereafter called OKRW). Users and developers can predict and manage costs in a stable, familiar unit. Users need not hold ETH or other volatile tokens. This removes compounded volatility (gas price swings plus token price swings) that plagues other networks. Corporate finance teams can budget infrastructure costs in KRW without holding crypto assets on their balance sheets.

As the Maroo ecosystem grows and transaction volume increases, demand for OKRW naturally rises. This creates a flywheel: blockchain growth and KRW adoption reinforce each other.

Public, but Regulated: Maroo is a permissionless chain. Anyone can create a wallet and send transactions. However, it distinguishes between a Regulated Path and an Open Path based on counterparty identity, transaction size, asset type, and applicable laws. The Regulated Path requires pre-approval and compliance checks; the Open Path operates without such gates. This lets experimental innovation and heavily regulated activities coexist on the same infrastructure.

Programmable Compliance Layer (PCL): Maroo enforces compliance logic at the transaction level. It evaluates factors like amount thresholds, jurisdiction, KYC/KYB/KYA status, sanctions lists, and Travel Rule requirements. A Legal Oracle feeds regulatory parameters into the PCL, which then allows or rejects Regulated Path transactions accordingly.

Verifiable Privacy: Users control what to reveal (counterparties, amounts, asset types) on a per-transaction basis. Regulators access data through Observer Nodes under scope limits defined by law and enforced by the PCL. This design preserves user privacy while enabling legally grounded regulatory oversight.

AI Agent Oriented Design: As AI agents become mainstream economic actors, Maroo provides KYA (Know Your Agent) verification and transaction modules for autonomous agents, while protecting user privacy through clearly defined access permissions and delegation scopes. This ensures both accountability and boundaries for AI-driven economic activity.

2. Problem Definition

Since Bitcoin’s 2008 whitepaper, blockchain and digital assets have expanded dramatically. The stablecoin market alone grew from ~$28 billion in 2020 to ~$300 billion in 2025 (Citi, 2025). Yet real-world adoption remains limited. According to the IMF (2025), approximately 80% of stablecoin transactions consist of arbitrage and rebalancing by bots, serving crypto trading liquidity rather than everyday commerce. For non-USD currencies, the picture is even bleaker: over 90% of fiat-backed stablecoins are pegged to USD (TRM Labs, 2025).

Why has mainstream adoption remained limited? One major reason: the infrastructure that individuals, businesses, and governments need to use stablecoins in daily life simply doesn’t exist yet. Below, we outline the key limitations blockchain must address for digital assets to achieve mainstream adoption.

2.1 The Public Blockchain Gap

Public blockchains function as open financial operating systems. Anyone can create accounts, transfer assets, and deploy smart contracts. Products once exclusive to banks and card companies can now be built and launched by anyone with code. Leveraging open source, interoperability, and composability, entirely new financial and non-financial services have emerged rapidly. The Ethereum/EVM ecosystem has spawned on-chain trading, DeFi lending, derivatives, NFTs, gaming, and real-world asset (RWA) tokenization, all built on this openness.

But from the standpoint of financial infrastructure for everyday KRW transactions, even next-generation blockchains face critical gaps:

The bottom line: existing public chains lack the regulatory and accountability foundations needed for financial infrastructure for everyday use.

2.2 The Traditional Finance Gap

Traditional finance has robust frameworks for regulation, auditing, and consumer protection. However, it struggles with programmable money and global interoperability.

Bank accounts, brokerage accounts, and card networks achieve some compatibility through APIs, but each runs on separate ledgers. Complex cases like cross-border remittances involve high fees, multi-day processing, and multiple intermediaries.

Consider Korea’s card and payment gateway (PG) infrastructure. Korea leads the world in card and mobile payment adoption. But merchants pay for it through fees (0.4% to 3.5% depending on size and channel) and delayed settlement (typically 3 business days). Refund costs add further friction. This structure poorly serves small-ticket, high-frequency, or cross-border transactions. Regulators have introduced fee caps and faster settlement cycles for small merchants, but structural issues remain.

Looking ahead, automated payment actors (i.e., AI agents executing high-frequency, conditional, micro-transactions in real time) will strain this infrastructure further. In automation-heavy scenarios, PG fee structures and settlement delays become serious design constraints.

2.3 The Regulation-Innovation Tradeoff

Today’s choices are binary:

The fundamental tradeoff is exactly what Maroo is built to resolve. Can a single infrastructure satisfy both regulatory requirements and innovation?

2.4 The Privacy-Transparency Dilemma

Blockchains are inherently transparent ledgers. But real-world finance demands privacy for individuals’ assets and spending patterns, confidentiality for corporate trade secrets, and audit access for regulators.

Full transparency exposes everything, creating privacy, competitive, and security risks. Full opacity blocks even legitimate oversight, enabling money laundering, fraud, and consumer harm.

Maroo takes a different approach: tiered transparency. Ordinary users enjoy strong privacy for personal finances. Higher-level entities (institutions, issuers, public bodies) face greater transparency and accountability requirements.

Personal data stays private by default. Disclosure happens only according to objective, pre-agreed criteria encoded in chain governance to specified parties, within specified scope. When these rules run as smart contracts in a trustless manner, the rules are enforced in a consistent, transparent, and verifiable manner.

2.5 The AI Agent Accountability Gap

Maroo is designed for a future where AI agents operate as economic actors. Global tech and fintech players are already deploying agents that search, compare, and purchase on users’ behalf. OpenAI launched Instant Checkout (with Stripe) in September 2025; Google announced the Agent Payments Protocol (AP2) with Mastercard and PayPal; Amazon is testing Buy For Me; Visa and Mastercard are building agent-specific payment rails for 2026 launch. Coinbase and Cloudflare released the x402 protocol, enabling AI agents to pay for APIs and content autonomously using stablecoins.

Traditional assets are merging with on-chain protocols. AI is starting to hold, manage, and transact assets directly. AI as economic actor is rapidly becoming reality, exposing the limits of infrastructure designed for humans alone.

Key requirements for the agent era:

  1. Verify Agent Identity (KYA): Ensure verifiable identity for developers and operators. Beyond traditional KYC, establish agent identity, developer/operator attribution, and delegation relationships. This clarifies legal and financial accountability.

  2. Enforce Scoped Delegation: Limit agent access to the minimum necessary, including user identity, payment methods, and assets. Apply explicit limits on amounts, counterparties, and time windows. Block actions outside scope technically.

  3. Enable Real-Time Revocation: Detect abnormal behavior instantly. Revoke permissions immediately for malicious or compromised agents.

  4. Maintain Audit Trails: Record every agent transaction to enable post-facto verification, dispute resolution, and compliance. Document who acted, on whose behalf, with what authority, and what happened.

Existing blockchain account models (one private key fully controls one account) can’t handle this. Delegating limited permissions to agents, expressing owner-agent relationships on-chain, verifying agent identity, blocking out-of-scope actions, and revoking permissions instantly: none of this exists at the protocol level today.

3. Related Projects and Comparison

Global blockchain players are each tackling “infrastructure that satisfies regulation, privacy, and openness” differently. Since 2024-2025, stablecoin-focused chains, compliance-ready L1s/L2s, and payment-optimized networks have emerged rapidly, all answering the same question: how to overcome the limitations of existing public blockchains.

Approaches fall into three categories:

  1. Protocol-level standardization: Standardize asset types, fee units, settlement rules, and compliance at the protocol layer, rather than leaving each app to implement its own.
  2. Atomic enforcement: Bundle compliance checks with transaction execution; auto-revert if conditions aren’t met.
  3. Hybrid models: Run a separate native token economy while providing payment-optimized features.

3.1 Comparison Framework

Maroo proposes six comparison axes, analyzing the tradeoffs each choice creates.

3.2 Axis-by-Axis Analysis

(1) Chain Architecture & Governance

The first fork: does finality and policy enforcement happen independently, or depend on an external base chain?

Independent L1s emphasize fast finality and predictable settlement. L2s on Ethereum inherit base-layer security but face constraints on consensus rules, upgrades, and compliance parameters.

For national-scale stablecoin infrastructure, diverse stakeholders (regulators, bank consortiums, tech operators) must participate directly in governance. An independent L1 with self-contained governance fits better than an L2 bound by external chain rules.

(2) Network Economics

Second fork: what’s the unit for fees, settlement, and accounting? And how much does the network depend on volatile tokens?

Arc uses USDC for gas, aligning cost awareness with a stable unit. Codex uses ETH, passing volatility to users. Hybrids like Stable and Plasma simplify user paths with stablecoins while maintaining separate token economies for security and governance.

Maroo targets single-unit cost awareness in KRW. Fees should be predictable and not subject to sudden spikes from network congestion.

(3) Compliance & Identity Integration

Codex bundles compliance checks into execution for atomic enforcement (auto-revert on failure). Tempo standardizes policy enforcement at the transfer layer through policy stores and token standards. Arc and Stable lean toward issuer/institutional compliance, but app reusability varies by how primitives are exposed.

Maroo provides a protocol-level compliance module (PCL) that consistently enforces identity and policy checks on the Regulated Path, with a common interface apps can reuse.

(4) Privacy Design

Privacy is shifting from “full anonymity” toward selective disclosure compatible with audits.

Stable includes confidential transfers at the protocol level. Plasma offers selective, auditable confidential payments. Tempo and Arc plan selective privacy with auditability.

Maroo’s goal: selective privacy plus selective disclosure for sensitive flows like payments, with flexibility to adopt emerging privacy tech.

(5) AI/Agent Readiness

When agents join payment systems, the core challenge shifts from automation to control and accountability.

Tempo brings sponsorship, batching, scheduling, and delegation keys close to the transaction layer, delivering automation basics quickly. But most projects stop short of systematizing accountability and identity (KYA).

Maroo standardizes session keys, spending limits, and policy-based approvals for real-world payments, plus KYA (Know Your Agent) verification and auditable evidence to handle accountability on the Regulated Path.

(6) Developer Experience

Payment chains need more than EVM compatibility. Developer experience (DX) determines success.

Codex leverages OP Stack for tool reuse. Arc documents EVM differences clearly so developers know what’s changed. Tempo guides developers through practical pitfalls like “no native token.”

Maroo uses a KRW-first EVM where standard tools work out of the box. Differences (KRW fees, compliance, privacy, agent features) are clearly documented in SDKs. Testnet, explorer, indexing, monitoring, and regulatory observability ship from day one.

3.3 Comparison Summary

Axis Maroo Tempo Arc Codex Plasma Stable
(1) Chain Architecture & Governance Strong Strong Strong Partial Strong Strong
(2) Network Economics StrongOKRW Native StrongStablecoin Gas StrongUSDC Gas WeakETH Gas Partial Partial
(3) Compliance & Identity Integration StrongDual Track + PCL Partial Partial Strong Weak Partial
(4) Privacy Design StrongVerifiable Privacy Partial Partial Weak Partial Partial
(5) AI / Agent Readiness StrongKYA + Agent Verification Strong Partial Weak Weak Weak
(6) Developer Experience StrongKRW-first EVM Partial Strong Partial Partial Partial
Strong Strength Partial Partial Weak Weak

4. Maroo Design Principles

4.1 Design Goals and Principles

Maroo’s goal in one sentence:

A compliant and open Layer 1 blockchain for the KRW-denominated economy

Maroo follows these design principles:

KRW-Native Blockchain

All fees are paid in OKRW (KRW-pegged stablecoin). This eliminates dual-volatility risk and creates a flywheel: more usage drives more OKRW demand.

Principle 1. Single Native Asset

Principle 2. Stable, KRW-Denominated Fees

Principle 3. Ecosystem-Linked Growth

Public, but Regulated

Maroo is permissionless. Anyone can create wallets and send transactions. But it separates traffic into Regulated Path and Open Path.

Principle 4. Permissionless Access

Principle 5. Dual-Track Transactions

Principle 6. Independent Governance

Programmable Compliance Layer (PCL)

Maroo evaluates and enforces compliance logic at the transaction level, covering amounts, jurisdictions, KYC/KYB/KYA status, sanctions lists, and Travel Rule.

Principle 7. Dynamic Regulatory Parameters

Principle 8. Transaction-Level Evaluation

Principle 9. Developer Reusability

Verifiable Privacy

Users control disclosure (sender, receiver, amount, asset type) on a per-transaction basis, balancing privacy with regulatory needs.

Principle 10. Selective Privacy

Principle 11. Verifiable Compliance

Principle 12. Controlled Access

AI Agent Oriented Design

Maroo provides KYA (Know Your Agent) verification, defining accountability and limits for autonomous economic actors.

Principle 13. Agent Identity Verification (KYA)

Principle 14. Delegation and Limits

Principle 15. Sanction Mechanisms

4.2 Layer 1 vs. Layer 2

Whether to build an independent L1 or an L2 atop an existing chain is a foundational architecture decision, affecting governance, regulatory application, and developer experience.

Independent Governance and Compliance

Typical Ethereum L2s delegate data availability and final settlement to Ethereum. Transaction ordering and fee policies often depend on individual sequencer operators. While L2s inherit Ethereum’s security, they face constraints when stakeholders need direct participation in consensus, parameters, and upgrades.

Maroo requires chain-level governance for decisions like: who serves as validators, who updates the Legal Oracle and PCL parameters, and who intervenes (and how) for abnormal transactions. This demands an independent L1 not subordinate to external chain rules.

EVM Compatibility and Developer Experience

Choosing L1 doesn’t mean abandoning EVM benefits. Maroo runs an EVM-compatible execution environment:

Summary: Maroo doesn’t reject Ethereum’s global security model. We chose an independent L1 to enable direct stakeholder participation in consensus and compliance while preserving EVM compatibility for developers.

5. Platform Architecture

5.1 Core Components

Maroo’s platform centers on five core modules: Maroo Core (consensus, execution, OKRW), Identity/Authentication Layer, Compliance Layer, and Privacy Layer, supported by node infrastructure. The diagram below shows how these connect to serve end users, institutions, and AI agents.

%%{init: {"theme": "base"} }%%
flowchart TB
    subgraph Users["End Users & Institutions"]
        U1["Individuals / Merchants"]
        U2["Banks / Financial Institutions"]
        U3["AI Agents"]
    end

    subgraph Access["Access Layer"]
        Apps["Wallets / Apps / Banking Apps"]
        API["SDK / API"]
    end

    subgraph Maroo["Maroo Core"]
        Cons["Consensus & Execution<br/>(BFT + EVM + OKRW)"]
        subgraph Modules["Core Protocol Modules"]
            ID["Identity & Authentication"]
            Compliance["Compliance Layer<br/>(PCL + Legal Oracle)"]
            PRIV["Privacy Layer"]
        end
    end

    subgraph Nodes["Node Roles"]
        Val["Validator Nodes"]
        Full["Full / RPC Nodes"]
        Obs["Observer Nodes"]
    end

    U1 --> Apps
    U2 --> Apps
    U3 --> Apps
    Apps --> API
    API --> Cons
    API --> ID
    API --> Compliance
    API --> PRIV
    Cons --> Val
    Cons --> Full
    Cons --> Obs

    style U1 fill:#64748B,stroke:#64748B,color:#fff
    style U2 fill:#64748B,stroke:#64748B,color:#fff
    style U3 fill:#64748B,stroke:#64748B,color:#fff
    style Apps fill:#64748B,stroke:#64748B,color:#fff
    style API fill:#64748B,stroke:#64748B,color:#fff
    style Cons fill:#0096AA,stroke:#0096AA,color:#fff
    style ID fill:#0096AA,stroke:#0096AA,color:#fff
    style Compliance fill:#FF8C50,stroke:#FF8C50,color:#fff
    style PRIV fill:#0096AA,stroke:#0096AA,color:#fff
    style Val fill:#0096AA,stroke:#0096AA,color:#fff
    style Full fill:#0096AA,stroke:#0096AA,color:#fff
    style Obs fill:#FF8C50,stroke:#FF8C50,color:#fff
ComponentDescription
Maroo CoreBFT consensus, EVM execution, OKRW native currency
Node RolesValidator Nodes, Observer Nodes, Full/RPC Nodes
Identity & AuthenticationStorage and query interface for KYC/KYB/KYA credentials
Compliance LayerDual-track model, PCL, Legal Oracle
Privacy LayerPer-field disclosure controls and cryptographic protections (ZKP)

5.2 Maroo Core

Maroo Core is the foundation: consensus, execution environment, and native currency.

5.2.1 Network and Consensus

Financial infrastructure demands instant finality. Maroo uses a battle-tested BFT consensus algorithm (e.g., Tendermint/CometBFT). The network has no forks. Once transactions finalize, they’re irreversible.

Given national-scale requirements, we assume up to several dozen validators, all deployed onshore in Korea.

Performance Targets:

5.2.2 Execution Environment

Maroo targets EVM compatibility for developer experience. Solidity contracts deploy and run natively. OKRW serves as the gas token, familiar to any EVM developer.

Precompiles / Core Modules

Tool Compatibility

Parallel Execution

5.3 Node Roles

Three node types operate the network:

Validator Nodes

Observer Nodes (Regulatory)

Full/RPC Nodes

5.4 Identity and Account Model

5.4.1 Unverified vs. Verified Accounts

Maroo is permissionless. But accounts split into two types based on verification status: Unverified (Unknown) and Verified (Known).

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR
    subgraph Wallets["Accounts on Maroo"]
        Addr("Wallet Address<br/>(ECDSA / AA)")
        Unknown("Unverified Account<br/>(No KYC/KYB/KYA)")
        KnownInd("Verified Individual<br/>(KYC Level N)")
        KnownCorp("Verified Corporation<br/>(KYB Level N)")
        KnownAgent("AI Agent Account<br/>(Linked to Owner)")
    end

    subgraph IdentityOff["Off-chain Identity Providers"]
        KYCProv("KYC Provider")
        KYBProv("KYB Provider")
        KYAProv("KYA / Agent Provider")
    end

    subgraph IdentityOn["On-chain Identity Layer"]
        IdContract("Identity & Auth<br/>Smart Contract")
    end

    Apps("Apps / Banks /<br/>Public Services")

    Addr -->|"Create Wallet"| Unknown
    Unknown -->|"1. KYC Request"| KYCProv
    KYCProv -->|"2. KYC Verification<br/>(On-chain)"| IdContract
    IdContract -->|"3. Status: KYC Done"| KnownInd
    Unknown -->|"1. KYB Request"| KYBProv
    KYBProv -->|"2. KYB Verification"| IdContract
    IdContract -->|"3. Status: KYB Done"| KnownCorp
    KnownInd -->|"Agent Registration"| KYAProv
    KYAProv -->|"Agent Verification"| IdContract
    IdContract -->|"Owner ↔ Agent Link"| KnownAgent
    Apps -->|"Query Identity/Level"| IdContract
    IdContract -->|"isVerified,<br/>expirationDate etc."| Apps

    style Addr fill:#64748B,stroke:#64748B,color:#fff
    style Unknown fill:#64748B,stroke:#64748B,color:#fff
    style KnownInd fill:#64748B,stroke:#64748B,color:#fff
    style KnownCorp fill:#64748B,stroke:#64748B,color:#fff
    style KnownAgent fill:#64748B,stroke:#64748B,color:#fff
    style KYCProv fill:#FF8C50,stroke:#FF8C50,color:#fff
    style KYBProv fill:#FF8C50,stroke:#FF8C50,color:#fff
    style KYAProv fill:#FF8C50,stroke:#FF8C50,color:#fff
    style IdContract fill:#0096AA,stroke:#0096AA,color:#fff
    style Apps fill:#64748B,stroke:#64748B,color:#fff

Unverified Accounts

Verified Accounts

This model keeps the chain permissionless while letting regulated services require verified accounts.

5.4.2 KYC/KYB/KYA Framework

Verification happens off-chain through authorized providers. On-chain, only Verifiable Credentials are stored: “This address has Level-2 KYC, expires YYYY-MM-DD.” Create, update, and revoke actions require multi-sig or governance approval.

5.4.3 AI Agent Account Model

Maroo’s on-chain agent model draws from proposals like ERC-8004 (AI Agent Registry), adapted for our regulatory and consortium structure. We start simple with an agent registry plus owner address, and expand as standards mature.

Owner Address

Agent Registry

Sanction Mechanisms

5.4.4 On-chain Identity Interface

The identity module exposes an interface like:

Input: (type, address)

Output: (isVerified, expirationDate)

Example: A financial app requires re-verification for transactions over KRW 1M if the account is 6+ months old. The app queries expirationDate before the transaction, prompts re-verification if expired, then creates a Regulated Path transaction. This loosely couples chain-level identity with app-level UX, enabling patterns like Sign-In with Ethereum while meeting compliance requirements.

5.5 Transaction Model and Compliance

5.5.1 Dual-Track Transaction Model

Maroo’s transaction model addresses both regulatory requirements and permissionless innovation through two paths.

%%{init: {"theme": "base", "themeVariables": {"actorBkg": "#64748B", "actorTextColor": "#fff", "actorBorder": "#64748B"}} }%%
sequenceDiagram
    participant U as User
    participant App as Maroo App
    participant PCL as PCL
    participant Chain as Maroo L1
    participant Obs as Observer

    rect rgba(255,140,80,0.15)
        Note over U,Chain: Regulated Path
        U->>App: 1) Payment Request (with Identity)
        App->>PCL: 2) Pre-screening (KYC status, limits)
        PCL-->>App: 3) Approval + Auth ID
        App->>Chain: 4) Tx + Auth ID (Tag: Regulated)
        Chain-->>Obs: 5) Metadata (Regulated Stream)
    end

    rect rgba(100,116,139,0.15)
        Note over U,Chain: Open Path
        U->>App: 1') General Tx Request
        App->>Chain: 2') Tx (Tag: Open)
        Chain-->>Obs: 3') Metadata (Open Stream)
    end

Regulated Path

Open Path

Two key benefits:

(1) Space for Experimentation Startups and developers can experiment freely on the Open Path. As products mature, they migrate to the Regulated Path.

(2) Clear Institutional Standards Banks, securities firms, and public agencies can define policy: “Only Regulated Path transactions count as official records.” Problematic Open Path transactions can be tracked, sanctioned, and recovered through observer infrastructure.

Maroo occupies the middle ground, neither fully permissioned nor fully permissionless. Both layers coexist on one chain.

5.5.2 Programmable Compliance Layer (PCL)

PCL isn’t a monolithic smart contract embedding all rules. It’s a policy engine that reads parameters from a Legal Oracle and enforces them. Example parameters the Legal Oracle might publish:

PCL references these when evaluating Regulated Path transactions. When regulations change, only the Legal Oracle updates; PCL logic stays stable. Separating parameter supply (oracle) from policy evaluation (PCL) lets laws evolve quickly while the chain’s core logic remains reliable.

For developers and operators, Maroo provides:

Developers build compliant apps without parsing raw regulations themselves.

The Legal Oracle brings legal and regulatory changes on-chain, publishing and updating parameters that PCL references.

Example Input Data:

Operating Entities: Designated Legal Oracle administrators (regulators, bank consortiums, legal institutions) participate via multi-sig or governance procedures. New parameters require threshold signatures, preventing unilateral changes by any single party.

PCL always references the latest Legal Oracle parameters. For example, if Travel Rule applies above KRW X, the Legal Oracle publishes this; PCL auto-reverts non-compliant transactions.

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR
    subgraph Gov["Off-chain Oracle Governance"]
        Reg("Regulators")
        FIs("Banks / Financial Institutions")
        Legal("Legal & Compliance Experts")
        Committee("Oracle Committee (Multi-sig)")
    end

    subgraph PolicyData["On-chain Policy Data"]
        Oracle("Legal Oracle Contract")
        Identity("Identity & Auth")
    end

    subgraph Enforcement["On-chain Enforcement & Usage"]
        PCL("Programmable Compliance Layer")
        Apps("Regulated Apps / Banks")
        Obs("Observer Nodes / Dashboard")
    end

    Reg -->|"1) High-level Rules"| Committee
    FIs -->|"2) Risk Limits"| Committee
    Legal -->|"3) Policy Draft / Interpretation"| Committee
    Committee -->|"4) Signed Parameter Update Tx"| Oracle
    Oracle -->|"5) Limits / Lists / Flags"| PCL
    Identity -->|"6) KYC / KYB / KYA Status"| PCL
    Apps -->|"7) Regulated Tx + Proof"| PCL
    PCL -->|"8) Allow / Reject / Tag"| Apps
    PCL -->|"9) Tx Classification / Risk Signal"| Obs
    Obs -->|"10) Supervisory Report"| Reg

    style Reg fill:#64748B,stroke:#64748B,color:#fff
    style FIs fill:#64748B,stroke:#64748B,color:#fff
    style Legal fill:#64748B,stroke:#64748B,color:#fff
    style Committee fill:#FF8C50,stroke:#FF8C50,color:#fff
    style Oracle fill:#FF8C50,stroke:#FF8C50,color:#fff
    style Identity fill:#0096AA,stroke:#0096AA,color:#fff
    style PCL fill:#FF8C50,stroke:#FF8C50,color:#fff
    style Apps fill:#64748B,stroke:#64748B,color:#fff
    style Obs fill:#FF8C50,stroke:#FF8C50,color:#fff

SDK and sample code document Legal Oracle-PCL interactions (parameter formats, versioning, queries), enabling regulators, banks, and developers to build on the same compliance layer.

5.5.4 Incident Response and Recovery

Maroo doesn’t ignore real-world situations requiring post-facto remedy (hacks, phishing, clearly illegal fund flows). But rather than chain-wide rollbacks, we provide protocols for limited state correction under pre-defined procedures.

Possible actions include asset freezing, burning illegal assets, and re-issuance for victim relief, depending on circumstances. These functions activate only with legal basis and proper procedures, not as standing intervention powers. All enforcement is audit-logged to minimize abuse.

Technically, instead of rollbacks that “erase the past,” we prioritize new transactions that limit or invalidate prior state. This practical compromise accommodates real-world legal requirements while preserving blockchain immutability.

5.6 Privacy Design

Maroo brings KRW payment infrastructure on-chain. Core use cases (daily payments, salaries, benefits, P2P transfers, AI agent payments) are highly sensitive. Maroo’s privacy goal isn’t “hide everything.” It’s a tiered visibility model where access level depends on the viewer.

Public by default, selectively private when needed, yet always verifiable that the system is operating correctly.

5.6.1 Privacy by Viewer

Rather than uniform disclosure, Maroo designs for four viewer types: general public / transaction parties / operators / regulators (observers).

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR
    subgraph Pub["General Public"]
        P["Minimal Metadata<br/>(Tx Hash, Block/Time,<br/>Raw/Regulated Tag)"]
    end

    subgraph Party["Transaction Parties / Operators"]
        T["Parties: Own Tx Details<br/>Operators: Delegated/Policy Scope<br/>Partial or Aggregated"]
    end

    subgraph Obs["Observers / Regulators"]
        O["Procedure & Scope Limited<br/>Sensitive Field Access<br/>+ Audit Trail"]
    end

    Pub -->|"Auth/Policy"| Party
    Party -->|"Legal Procedure<br/>+ Scope Limit"| Obs

    style P fill:#64748B,stroke:#64748B,color:#fff
    style T fill:#0096AA,stroke:#0096AA,color:#fff
    style O fill:#FF8C50,stroke:#FF8C50,color:#fff

5.6.2 Controlled Access, Key Management, and Compliance Integration

Regulator access isn’t unlimited. It follows a procedure-based controlled access path. Access may not require user consent, but must always be premised on legal basis, approval procedures, and minimized scope. Requests, approvals, and access are all audit-logged. Multi-party approval (threshold/distributed) plus role separation prevents any single entity from accessing unilaterally.

Privacy features integrate with the PCL. Even protected transactions must verifiably satisfy regulatory requirements while minimizing sensitive data exposure. When needed, controlled access paths allow fact verification, always within scope limits. Even in protected mode, double-spend prevention, balance rules, and policy compliance remain consistently enforced.

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR

    U("User / Service")

    subgraph Core["Maroo Core"]
        C["EVM / Execution"]
        S["Encrypted Storage<br/>(Optional)"]
    end

    D["PCL<br/>(Policy Evaluation)"]

    R("Observer")
    P["Legal Procedure / Policy"]
    K["Controlled Keys<br/>(Threshold/Approval)"]

    U -->|"1) Submit Tx<br/>(Public/Protected)"| D
    D -->|"2) Rule/Policy Verification<br/>(Minimize Sensitive Data)"| C
    C -->|"3) (Optional) Encrypted Commit<br/>(Protected Mode)"| S

    R -->|"4) Access Request<br/>(Case/Period/Target/Field)"| P
    P -->|"5) Approval/Scope Confirm"| K
    K -->|"6) Auth/Decryption Shard"| R
    R -->|"7) Scoped Query"| S

    style U fill:#64748B,stroke:#64748B,color:#fff
    style C fill:#0096AA,stroke:#0096AA,color:#fff
    style S fill:#0096AA,stroke:#0096AA,color:#fff
    style D fill:#FF8C50,stroke:#FF8C50,color:#fff
    style R fill:#FF8C50,stroke:#FF8C50,color:#fff
    style P fill:#FF8C50,stroke:#FF8C50,color:#fff
    style K fill:#FF8C50,stroke:#FF8C50,color:#fff

5.6.3 Privacy Implementation Approaches

Maroo adopts two complementary approaches. They differ in where privacy is enforced, with tradeoffs in security assumptions, institutional onboarding, UX, and throughput.

(A) Gateway-Based Access Control

Control sensitive data access through authenticated gateways. Mask and filter query responses by role and permission. Public data stays open; sensitive fields return at limited resolution per policy. This enables rapid differential visibility. Regulators can access unmasked data under procedure and scope limits.

The network also publishes disclosures for transparency: state roots, aggregate statistics, policy enforcement summaries. This is verifiable minimum information allowing third parties to confirm ledger integrity and operational consistency.

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR

    subgraph External["External (Public Internet)"]
        U["User / Wallet"]
        P["Service Operator"]
        O["Observer"]
    end

    subgraph Gateway["Authenticated Gateway"]
        G["Gateway<br/>(Auth + Policy + Masking)"]
    end

    subgraph Net["Validator Network"]
        S["Sentry / RPC Edge"]
        V["Validator / Consensus"]
        DB["Chain State"]
    end

    subgraph Disclose["Public Disclosure"]
        D["Disclosure<br/>(State Root / Auth / Summary)"]
    end

    U --> G
    P --> G
    O --> G

    G --> S --> V --> DB
    DB --> V --> S --> G

    DB -->|"Publish"| D
    D -->|"Verification/Audit Basis"| External

    style U fill:#64748B,stroke:#64748B,color:#fff
    style P fill:#64748B,stroke:#64748B,color:#fff
    style O fill:#FF8C50,stroke:#FF8C50,color:#fff
    style G fill:#FF8C50,stroke:#FF8C50,color:#fff
    style S fill:#0096AA,stroke:#0096AA,color:#fff
    style V fill:#0096AA,stroke:#0096AA,color:#fff
    style DB fill:#0096AA,stroke:#0096AA,color:#fff
    style D fill:#64748B,stroke:#64748B,color:#fff

Advantages: Fast institutional onboarding with no need for new wallet types, proof generation, or ZK key management. Quick time-to-market with low technical uncertainty.

Risks: High operational dependency creates human-error attack vectors. Query and simulation paths expand the attack surface. Security relies on operations, auditing, and controls.

(B) ZKP-Based Shielded Pool

Provide a Shielded Pool at the protocol level using encrypted notes and zero-knowledge proofs. Users prove legitimate ownership and prevent double-spending without revealing sensitive fields. Regulatory integration happens through selective disclosure and controlled access. Similar approaches include Zcash, Aztec, and Railgun; however, achieving production-grade UX, throughput, and policy integration remains challenging.

%%{init: {"flowchart": {"htmlLabels": true}, "theme": "base"} }%%
flowchart LR

    subgraph Client["Client / Wallet"]
        W["Wallet (Proof Generation)"]
    end

    subgraph Chain["Maroo Core"]
        Bank["Public Balance<br/>(Account-based)"]
        Pool["Shielded Pool<br/>(Notes + Merkle Tree)"]
        Verify["ZK Verification<br/>(On-chain)"]
        Null["Nullifier Set<br/>(Double-spend Prevention)"]
    end

    subgraph Audit["Authorized Audit"]
        Obs["Observer"]
        Keys["Controlled Keys<br/>(Threshold/Approval)"]
    end

    W -->|"Deposit"| Bank -->|"Move to Pool"| Pool
    W -->|"Withdraw: Proof + Nullifier"| Verify -->|"If Valid"| Pool
    Verify --> Null

    Obs -->|"Request (Scoped)"| Keys -->|"Approval"| Obs
    Obs -->|"Read (Scoped, Controlled Access)"| Pool

    style W fill:#64748B,stroke:#64748B,color:#fff
    style Bank fill:#0096AA,stroke:#0096AA,color:#fff
    style Pool fill:#0096AA,stroke:#0096AA,color:#fff
    style Verify fill:#0096AA,stroke:#0096AA,color:#fff
    style Null fill:#0096AA,stroke:#0096AA,color:#fff
    style Obs fill:#FF8C50,stroke:#FF8C50,color:#fff
    style Keys fill:#FF8C50,stroke:#FF8C50,color:#fff

Advantages: Privacy approaches trust-minimization, not relying on access controls alone.

Risks: Cutting-edge and experimental. Proof overhead may constrain throughput and cost. Wallet/SDK proof and note management may burden UX. PoC validation is essential.

5.6.4 Implementation Roadmap

These approaches aren’t mutually exclusive. The question is which scenarios to prioritize under which trust assumptions. PoC priorities:

  1. Is differential visibility UX actually achievable?
  2. Do procedures and controls prevent regulatory access abuse?
  3. Does PCL compliance verification integrate naturally in protected mode?

Details will evolve based on PoC results and legal requirements. Technical specifics (cryptographic stacks, key management, audit procedures, performance benchmarks) will be documented separately.

6. Conclusion

Most economic activity in Korea is already digital. Salaries, taxes, utilities, commerce, investments: all denominated in KRW. Mobile banking and simple payments mean most transactions are already digital.

But for this digital economy to move fully on-chain, it needs what existing public blockchains lack: a compliance framework regulators can trust, a transparency structure that protects privacy while enabling audits, and an accountability architecture suitable for AI agents operating as economic participants.

Maroo is a compliant, open sovereign Layer 1 for the KRW-denominated economy, built to address these needs:

The blockchain transformation of everyday finance isn’t a distant future; it’s happening now. The global stablecoin market is surging. Major nations are building CBDC and tokenized asset infrastructure. AI is emerging as a financial actor. At this inflection point, Korea’s ability to build robust KRW-native blockchain infrastructure will be decisive for digital economy competitiveness.

This litepaper is a first draft outlining the problem and Maroo’s design direction. It’s meant to start conversations with regulators, financial institutions, tech companies, the developer community, startups, and researchers. Maroo aims to propose and build new digital infrastructure for the KRW-denominated economy, together with external researchers and technical contributors, and play a meaningful role in Korea’s path to digital economy leadership.

7. References

Appendix: List of Diagrams

  1. Maroo’s 5 Core Mechanisms Overview
  2. Problem Definition and Maroo’s Solution
  3. 6-Axis Comparison Framework
  4. Maroo Platform Architecture
  5. Node Roles and Data Flow
  6. Unverified vs. Verified Account Model
  7. Regulated Path vs. Open Path
  8. Legal Oracle → PCL → App Flow
  9. Data Visibility by Viewer Type
  10. Privacy Implementation Approaches