1. The Won as Korea’s Financial Grammar
Daily life in Korea ultimately revolves around the won. Salaries are paid, taxes are settled, goods are bought, and investments are made within that single unit of account. Finance may be described as borderless, but the working medium of exchange in ordinary life remains the won.
National rules and institutions also shape financial systems. Consumers rarely notice it, but the transaction structures behind their financial activity are the product of negotiated, agreed-upon rules.
Anti-money-laundering standards are one example. International recommendations set a threshold of roughly $1,000, but how transactions are handled differs by country. The United States regulates transactions above $3,000, a more permissive line than the recommendation. Korea recently removed even its 1 million won floor, building a framework that requires originator and beneficiary information to travel with every transaction regardless of size.
Financial rules share a common reference point in those international recommendations. The grammar of transactions that actually operates beneath them, however, takes a different shape in each country according to its financial environment and institutional context. In practice, implementation must reflect the particular circumstances of each jurisdiction.
Blockchain-based financial innovation is no exception. Technology crosses borders, but the financial system in which it executes still runs on local regulation and local convention.
Expertise in a single local financial grammar therefore becomes a core competitive strength rather than a limitation, because few parties can read a local market’s specific context accurately and encode it at the level of infrastructure.
2. Maroo, Born in Korea
Maroo is the chain built in Korea to meet that need.
The project is led by Hashed Open Finance, a subsidiary of Hashed established to commercialize stablecoins, real-world asset tokenization, and security token issuance. Hashed, founded in 2017, is a leading Korean blockchain investment firm and accelerator, and it is building Maroo through Hashed Open Finance, drawing on its close experience with Korea’s evolving market.
ShardLab and Delight Labs joined as partners to add technical depth and operational experience. ShardLab contributes hands-on experience designing and operating stablecoin payment infrastructure in Southeast Asia in partnership with the Thai financial group SCBX, while Delight Labs adds chain operations expertise built since 2018, running multiple nodes and mainnets.
Maroo is being built on that combination of deep insight into the Korean market and proven operating experience.
Going forward, the project plans to verify regulatory alignment through discussions with government authorities and financial institutions, and to widen the range of applications together with academia and the startup ecosystem.
In sum, all three organizations building Maroo have working teams in Seoul. Hashed Open Finance leads the project as a separate entity dedicated to domestic regulated business, and ShardLab and Delight Labs each support it from their own Seoul offices. Korean institutions, academia, and startups are set to join in support.
Maroo is designed to reflect the institutional and regulatory characteristics of the Korean market directly in its infrastructure.
3. The Maroo Chain Runs on the Won
Daily life in Korea runs on the won. Salaries arrive in won, and that money pays the maintenance fee, buys the groceries, and funds the savings account. Wages, taxes, utility bills, and investments all already operate in won across the whole of the real economy, and most of that activity is already handled digitally.
The real digital economy and the existing blockchain ecosystem nevertheless operate apart from each other. Most on-chain environments are structured around the dollar, which puts a clear distance between them and the won-denominated routine Koreans experience every day.
Against that backdrop, Maroo sets OKRW, a won stablecoin, as the network’s base unit. The intent is to carry Korea’s everyday unit of account onto the chain without breaking it.
The primary advantage of this is predictability in the cost structure. Gas fees rise on any network once it becomes congested, and Maroo is no exception. A chain that charges gas in an asset whose value is not fixed adds another layer to that.
Rising network usage increases demand for the asset, demand pushes the asset’s price up, and the cost of the same transaction can rise further. Congestion and asset price amplify each other.
Maroo’s base asset is the won. Higher usage does not, by itself, move the value of the won. This removes token-price volatility from the equation, leaving congestion as the main variable affecting gas costs, and it is the kind of variable that can be forecast by looking at transaction volume.
Costs do not disappear, of course. Heavy traffic increases the gas burden, and on top of that come the operating costs that attach to running a service, such as server resources and sponsored gas fees.
Those costs fall on the party operating a service on Maroo rather than on the end user, and that is where predictability matters: cost is determined by the operator’s own transaction volume, a variable it can plan for, rather than by a market price it cannot control.
A financial institution that will be a primary distributor of the won stablecoin on Maroo will expect more than predictable costs. It will raise two fundamental questions about the won itself: who holds the authority to issue the currency, and who holds the authority to control transactions in an emergency.
3.1. Who Holds the Authority to Issue Currency?
Just as the power to issue currency is granted only to specific bodies in the real world, the authority to issue OKRW on Maroo is strictly isolated from ordinary execution permissions. That isolation is designed around three core principles.
Governance-based issuance control: issuance authority is managed under protocol-level consensus procedures and governance control rather than at the discretion of any single company.
Issuance built into chain logic: the issuance function is embedded as a precompile in the chain itself rather than as a smart contract, so that changing the rules requires modifying chain logic rather than simply swapping out a contract.
Technical separation of issuance and circulation: circulation follows the ERC-20 standard to ensure compatibility, while issuance routes through a separate system account so that issued volume and receipt records are verified and managed independently.
Maroo’s issuance structure therefore draws on the same principle of separating issuance authority from circulation found in central-bank systems.
The protocol controls the issuance rules to secure safety, while circulation is left to standardized infrastructure to secure general compatibility. It is a two-track structure that pursues stability and scalability at the same time.
3.2. Who Holds Transaction Control in an Emergency?
Emergency transaction control is not a standing power the operator can exercise at will. It activates only after the fact, and only once a legal basis and an agreed procedure are in place.
Maroo recognizes the need to address real-world incidents, such as hacks or clearly illicit fund flows. Instead of rolling back the entire chain, it corrects state within a limited scope according to procedures defined in advance.
Asset freezing, clawback, and reissuance for the relief of victims are currently under review as instruments, and the specific triggering conditions and procedures are still under discussion.
This is also the decisive reason Maroo built its own separate mainnet. Defining who responds to anomalous transactions and how, in a way suited to Korea’s financial realities, requires the authority to control the network’s foundational rules independently. In the same way a nation safeguards its monetary sovereignty, Maroo chose to secure this authority at the protocol level.
4. The Rules Governing Won Transactions
With an independent mainnet and a won stablecoin in place as the foundation, the next step is to design the rules that govern how assets move on top of it.
In Korea’s current financial environment, those rules are scattered across the code of each firm’s fragmented individual services. The cost of that fragmentation shows itself in full whenever regulation changes. If a threshold such as the travel rule floor is adjusted by even one won, numerous operators must absorb the inefficiency of reconfiguring and redeploying their systems.
Supervisors, for their part, expend enormous administrative effort checking the consistency of each service one by one. Regulatory response has become a core operational task in its own right.
Maroo moves the location of these rules from the service layer to the infrastructure layer, encoding compliance requirements directly at the chain layer rather than into the logic of individual applications. When a statutory limit changes, updating a parameter within the chain is enough, because every service on the network then follows the new financial grammar at the same time.
With that in place, consider how a won transaction is actually processed on-chain. Regulatory parameters are configured on the chain, an engine determines whether a transaction is permissible, and records are made visible according to permission level.
4.1. How Regulation Is Reflected
Maroo proposes a shared reference layer called the Legal Oracle. Regulators set practical regulatory data such as transaction limits themselves, providing a common regulatory reference for the network.
Data is updated through an Oracle Committee whose members include the supervisory authorities that design and enforce regulation, financial institutions, and legal bodies. This structure allows the bodies that design the rules to reflect network rules in the ledger directly.
The core of the design lies in blocking unilateral parameter changes by any single institution. A change takes effect only after approval by a defined quorum, and the entire history is recorded transparently.
Data supplied this way is applied to live transactions through the Programmable Compliance Layer (PCL). Rather than writing the rules itself, the PCL provides Lego-block-like components that institutions can assemble into their own compliance policies.
Individual conditions such as blocking a transfer or setting a limit are built into single blocks, and those blocks are woven together with AND and OR logic to complete composite policies.
Maroo provides a set of templates as a guide, so that practitioners can design compliance efficiently by filling in only the values they need rather than writing new code.
Because the oracle supplies the values that go into each block, a change in the regulatory environment can be met immediately without code modifications or a hard fork.
Travel rule compliance serves as an example. An operator simply enters the statutory threshold and 24-hour reset period into the relevant oracle template.
Users who have completed verification are excluded from this limit calculation, while unverified users have their transactions rejected the moment they exceed the threshold. When the amount set by law changes, only that single value needs to be updated.
4.2. When and How the Rules Apply
Timing is the core of compliance verification. Every transaction on Maroo passes through the PCL (Programmable Compliance Layer) filter before execution, and transactions that violate policy set in advance are blocked at the mempool stage.
This is an infrastructure-level response that prevents the transaction from being executed in the first place rather than tracing it after the fact. When a transaction is rejected, a structured reason code is returned, conveying clearly to operators and users why the compliance check failed.
The verification system divides into two levels by scope of application. The first is global policy, which applies across the entire network and covers the common rules that apply to every participant, including sanctions screening and limits on unverified accounts. The second is specific policy at the level of an individual contract.
Where an asset requires particular handling, as with security tokens (STOs), the contract owner attaches verification logic directly. The two checks work as an integrated whole, and a transaction that fails to satisfy the conditions cannot be recorded on the blockchain.
Maroo also introduces dual-track routing matched to the nature of the transaction, since small transfers and institution-level settlement call for different levels of verification.
The Open Path is subject only to network-wide policy, covering conditions every transaction must clear without exception, such as whether a counterparty is subject to sanctions. Transactions are sent immediately without prior approval, but they are tagged as open flow and become subject to continuous monitoring.
The Regulated Path adds contract-level policy on top of that. What matters here is who sets those conditions. The chain does not hand them down uniformly; the application operating the service defines the verification standards that will apply to it.
The operator determines which credentials to require and what limits to apply based on its regulatory environment. A transaction is valid only once it has cleared these conditions before execution and obtained proof of approval.
The difference between the two paths comes down to the number of verification stages a transaction must pass. The Open Path applies only the common grammar, while the Regulated Path adds the operator’s own standards on top of it.
This separation into tracks offers practical value to financial institutions. A bank can recognize only Regulated Path transactions as official settlement records under its internal guidelines.
If an inappropriate transaction is detected on the Open Path, it can be traced quickly after the fact in conjunction with Maroo’s analytics infrastructure, and those findings can serve as the basis for measures equivalent to asset recovery.
4.3. Who Can See the Record
On-chain migration is difficult if a company’s settlement records are exposed to competitors and an individual’s spending history is open to anyone. Confidentiality of financial data is a requirement rather than an option.
Turning all data fully private is not an option either. The verification system covered above needs access to transaction information in order to work properly, and supervisors need to be able to inspect it when necessary.
The point is not full disclosure or full concealment of information, but who is granted access and to what extent.
Maroo resolves this with permission-based, tiered access. Ordinary users see their own transaction history, and the parties to a transaction see records of transactions between them. Operators and regulators are granted information access matched to their respective roles and scope of responsibility.
Technically, this is implemented as a shielded pool based on zero-knowledge proofs (ZKP). Rather than concealing the transaction in full, it selectively masks specific data fields. Using encrypted records and proof values, a user can demonstrate legitimate ownership and the prevention of double spending without revealing the transaction amount or the recipient.
The network verifies whether the transaction is valid while the details are shared only between the parties, and full disclosure remains possible at their option.
Institutional access follows a separate procedure. Data is decrypted within an approved scope through an Auditor Key only where pre-agreed legal and governance requirements are met. Private transactions therefore do not sit in a supervisory blind spot, and the record of who accessed what, and on what grounds, is required to remain on file transparently.
This model is currently at the proof-of-concept (PoC) stage. Maroo is examining closely whether the tiered access structure degrades the user experience, whether institutional permission controls work effectively, and whether the privacy mode and the compliance layer mesh without conflict, so the detailed technical design may change later.
5. When the Transacting Party Is Not a Person
The financial rules we have used to date have always operated from the human being as their starting point. From identity verification through to payment, an individual or a legal entity stood at every step.
That basic premise of financial infrastructure is now being shaken, as agents gradually enter finance as transacting parties in place of people. Concrete moves are already visible: OpenAI’s work with Stripe on payments inside ChatGPT, Amazon’s experiments with delegated purchasing, and the agent settlement infrastructure being built by Visa and Mastercard.
Existing financial infrastructure, built around humans, is not equipped to fully accommodate this paradigm shift. That is also why Maroo is extending into new infrastructure for agents at this point.
5.1. Whose Agent Is This?
Consider a company issuing a corporate card to an employee. The card carries the user’s name, a limit is set on it, and ultimate responsibility for every payment rests with the company. The card, as an instrument, holds the actual user, the authority to act, and legal responsibility as a single unit.
The basic account structure of a blockchain does not permit that connection, because whoever holds the private key monopolizes full control of the account. Delegating a key to an agent creates the risk of handing over complete authority, while separating control makes autonomous operation by the agent impossible, creating a trade-off between control and agent autonomy.
As a result, when an agent causes an incident, the on-chain ledger records only an anonymous address, with no way to identify the operator behind it or the delegation relationship.
Maroo closes this gap through a Registry.
Every agent is bound from the moment of creation to an individual or corporate account that has completed identity verification. This delegation relationship is recorded explicitly in the registry, a dedicated area within the chain, where the agent address, owner identity, scope of delegated authority, and spending limit are inscribed as a single data set.
This is what Maroo defines as KYA (Know Your Agent). KYA is not a one-time identity check. .Instead, it is an ongoing control framework built on three elements: whether the person or entity that registered the agent has completed verification, what scope of authority that owner delegated, and whether that scope is observed at the moment of the actual transaction.
The first two are recorded in the registry, and the last is verified by the compliance layer on every transaction.
Notably, this registry is not a Maroo-specific format. Maroo implements ERC-8004, the standard under discussion for agent identity, and built it into the chain at genesis. It is a single registry the network has held from the start rather than a contract deployed by some application.
Because it follows the standard as written, agent tooling built on other chains runs on Maroo without modification, and conversely the identity of an agent registered on Maroo can be read in any environment that supports the standard.
The point of divergence is the connection to the compliance layer. A standard registry records only whose agent it is; using that record for transaction approval is a separate matter.
Maroo integrates registry records with its compliance layer, allowing ownership and delegated-authority data to inform transaction authorization.
The structure is the same as a company issuing a corporate card to an employee. The card has a designated owner, a set amount that can be spent at once and defined places where it can be used, and those conditions are checked at every payment. Recognizing an agent as a formal transacting party means the infrastructure handles these three things on the owner’s behalf.
Global standards for agent transaction approval remain at an early stage, however, and are not yet established. Maroo is therefore designed to adopt a flexible architecture as it builds a footing in the early market.
5.2. How Much to Delegate
The reasoning behind putting a limit on a corporate card is clear. It is not that the employee is not trusted, but that one mistake should not bring the company down. Software changes the scale at which mistakes can propagate. A person causes an incident only by pressing the wrong payment button, while badly written code repeats the same mistake dozens of times per second.
The block that imposes a per-transaction cap and the block that screens out specific addresses already exist. What changes is only the source of the value each block references. For a human account, the limit is determined by the verification tier, while for an agent, the delegated scope recorded in the registry becomes that value.
If the owner sets a KRW 1 million limit in the registry, the compliance layer reads that value on every transaction and rejects anything above it.
The model begins with segregated funds.
When the owner deposits available assets from their own wallet into the agent’s account, the agent can act only within that balance. Policy settings then follow through the registry. If the limit is specified as 1 million won, any single transaction exceeding it is blocked immediately.
Whitelisting is the mechanism that defines in advance the paths along which assets flow. Registering specific recipient addresses restricts transfers to approved destinations only, and unrestricted transfer logic applies only when the list is empty.
The limits on individual agents are not the whole of it. To block the practice of creating countless accounts to circumvent a limit, the system places a higher guardrail called the owner-level aggregate limit.
Even when an individual agent stays within its configured range, the infrastructure rejects the transaction as soon as total volume exceeds the threshold assigned to the owner by verification tier.
5.3. What Happens When the Scope Is Exceeded
Monitoring limits in real time matters as much as setting them, because a single point of inspection leaves no way to stop a transaction once that point is breached. Maroo places two safeguards around each transaction, one before and one after.
The wallet checks policy before it signs the transaction. A transfer above the limit is caught here. What matters is the manner of rejection. Rather than simply answering that it cannot be done, the wallet returns a structured reason code stating what blocked the transaction and what value would let it through. The key point is that this is a format software can interpret rather than a notice written for a person to read. The agent reads the code, adjusts the amount, and retries on its own, with no need for an operator to step in and dig through logs.
Even if the first check is bypassed, the compliance engine verifies the same policy again on-chain. A transaction that fails to pass this stage is never recorded on the blockchain at all. Once a transaction is approved, the gas fee and the won-converted amount remain in the record, so all costs are aggregated automatically on a per-transaction basis without a separate month-end reconciliation.
The core of this structure is that the compliance layer looks at the party actually responsible rather than the outward form of the transaction. Even if an agent bundles several transactions into one or routes around through another contract, the infrastructure finds the owner behind it and applies the policy attached to that owner. This is why multiplying accounts to split a limit does not work.
A safeguard is triggered when agent ownership is transferred. Once a transfer is requested, the agent is frozen for up to 24 hours until the counterparty accepts. Transfers and policy changes are impossible during this period, which shuts off any attempt to quietly withdraw assets immediately before ownership changes hands.
Technical standards for handling agents are still at an early stage. Several camps are putting forward their own frameworks, but most share a common starting point in defining the relationship between owner and agent.
Maroo’s decision to make registry-based owner binding its first building block reflects the same judgment, drawing a line between what can be fixed now and what can only be settled once the standards mature.
Policy enforcement at the current stage therefore takes place off-chain. Maroo has designed the form of its policies in advance to fit the chain’s grammar, and plans to move policy enforcement on-chain once standards mature and on-chain standards are established. Reputation systems and detailed verification procedures will be layered on in sequence at that point.
6. What to Verify Now
Maroo is the chain that has interpreted Korea’s institutional context and particularities most deeply at the level of infrastructure. What can be realized on that solid foundation runs through every area of finance that touches the real economy.
The largest inflection point now in front of us rests on two major axes: the discussion over who is authorized to issue the won stablecoin that will anchor the network, and the legislation of security tokens (STOs), which is moving toward a fixed schedule.
The two are entirely different in character. For the won stablecoin, the discussion over issuance eligibility and issuing parties is still underway, making it a policy question that remains unresolved. Security tokens, by contrast, have a clear direction in the amended Electronic Securities Act taking effect in February 2027.
The issuance discussion and the STO timeline appear separate, but the authorities’ roadmap sets the point at which the two axes combine as its final goal, because the question of what tokenized securities will be settled in ultimately converges the two discussions on a single point.
In this situation, the core of a practical response is to separate what must be decided institutionally from what can be prepared technically now. There are policy values that can be set only once legislation is finalized, and there is infrastructure that can be designed before the legislation arrives.
Choosing infrastructure only after the rules are settled makes it difficult to secure the time needed to establish an early position in the market. What is required is a strategy that keeps pace with the policy clock, including the promulgation of enforcement decrees, while separating and addressing in advance the areas that can be verified ahead of it.
What Maroo has prepared is not a particular institutional conclusion but an infrastructure framework capable of accommodating any regulatory scenario. The system governing how verification conditions are broken into units, how verification tiers connect to limits, and how far information is opened when an audit is requested can be implemented at the infrastructure level before legislation is finalized.
Once issuance eligibility and specific verification requirements are announced, Maroo is ready to take those conclusions as parameter values and translate them into code immediately.
What needs to be verified now, before policy conclusions arrive, is a demonstration of how regulatory requirements can be systematized on Maroo’s structure. Demonstrating in advance a structure that can absorb whatever conclusion emerges is the same process as building the technical capacity to respond nimbly to policy uncertainty.
The only advantage of preparing infrastructure before the regulatory framework is finalized is this present window of time, one that disappears entirely once the framework takes effect and can never be recovered afterward.
Disclaimer
This report has been prepared based on materials believed to be reliable. However, we do not expressly or impliedly warrant the accuracy, completeness, and suitability of the information. We disclaim any liability for any losses arising from the use of this report or its contents. The conclusions and recommendations in this report are based on information available at the time of preparation and are subject to change without notice. All projects, estimates, forecasts, objectives, opinions, and views expressed in this report are subject to change without notice and may differ from or be contrary to the opinions of others or other organizations.
This document is for informational purposes only and should not be considered legal, business, investment, or tax advice. Any references to securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or an offer to provide investment advisory services. This material is not directed at investors or potential investors.
Terms of Usage
Tiger Research allows the fair use of its reports. ‘Fair use’ is a principle that broadly permits the use of specific content for public interest purposes, as long as it doesn’t harm the commercial value of the material. If the use aligns with the purpose of fair use, the reports can be utilized without prior permission. However, when citing Tiger Research’s reports, it is mandatory to 1) clearly state ‘Tiger Research’ as the source, 2) include the Tiger Research logo. If the material is to be restructured and published, separate negotiations are required. Unauthorized use of the reports may result in legal action.
