A chain designed around Korean rules, not retrofitted after the fact
Maroo is being built as a public blockchain for a specific financial context: South Korea’s. The project’s core argument is straightforward. Korean residents receive wages, pay taxes, spend, save and invest in Korean won, and those activities are ultimately priced and settled in won. Finance may be global in theory, but the medium of exchange used in ordinary life is still local currency.
The article argues that financial systems are shaped by rules and institutions that differ across jurisdictions even when they draw on shared international references. Anti-money laundering requirements are one example. The piece notes that international guidance is around $1,000, yet implementation varies by country: more than $3,000 in the United States, while South Korea recently removed the KRW 1 million floor so sender and recipient information now has to travel with transactions regardless of amount.
Maroo’s premise is that onchain finance works the same way. Technology can move across borders, but the financial system using that technology still depends on local regulation and local custom. In that setting, the ability to understand domestic rules and encode them into infrastructure becomes an advantage rather than a limitation.
Maroo is led by Hashed Open Finance, a subsidiary created by Hashed for stablecoin commercialization, real-world asset tokenization and security token issuance. Hashed was founded in 2017 and is described in the article as a major blockchain investment and accelerator group in South Korea. Its technical partners are ShardLab and Delight Labs. According to the article, ShardLab worked with Thailand’s financial group SCBX on stablecoin payment infrastructure in Southeast Asia, while Delight Labs has operated nodes and mainnets since 2018. All three builders have teams in Seoul. Hashed Open Finance handles licensed domestic business as an independent entity, and ShardLab and Delight Labs support the effort from their Seoul offices. The project says it plans to discuss regulatory alignment with government bodies and financial institutions, while also expanding applications with academia and startup communities.
The result is a chain intended to reflect Korean institutional and regulatory traits directly at the infrastructure layer.
OKRW as the base unit of the network
Maroo uses the won-denominated stablecoin OKRW as the network’s basic unit. The reasoning is tied to how the Korean economy already functions. Wages, taxes, utility payments and investment activities in the real economy are already in won, and much of that economy is already digital. What remains disconnected, in Maroo’s telling, is the gap between a real digital economy organized around KRW and an onchain ecosystem that is mostly structured around the U.S. dollar.
Maroo says it is trying to move the daily unit of account onchain rather than break it apart. One immediate effect, it argues, is a more predictable cost structure. Gas rises when networks become congested on any chain, including Maroo. But if gas is priced in a volatile asset, congestion can drive more demand for that asset, pushing up the asset price and making the same transaction more expensive through two channels at once.
Because Maroo’s base asset is tied to won, the project argues that higher usage by itself does not alter the value of KRW. Once token price volatility is removed from the equation, congestion is left as the main variable affecting gas, and congestion can be estimated from transaction volume.
The article does not claim costs disappear. Higher traffic still raises gas burdens, and service operators still face expenses such as server costs and gas sponsorship. Those costs fall on operators running onchain services rather than end users. The point, Maroo says, is that operators are dealing with variables linked to their own transaction flow instead of market prices they cannot control.
Issuance is separated from ordinary execution rights
For financial institutions distributing OKRW, the article says two questions are fundamental: who has the right to issue money, and who can control transactions in an emergency. On issuance, Maroo says ordinary execution rights and minting authority are kept strictly separate.
The design is built around three principles. First, issuance control is governance-based, meaning authority is decided through protocol-layer consensus and governance rather than by a single company. Second, issuance is embedded in chain logic. The minting function is a precompile at the protocol level, not a smart contract, so changing the rule requires changing chain logic rather than swapping out a contract. Third, issuance and circulation are technically separated. Circulation uses ERC-20 for compatibility, while issuance runs through a distinct system account with mint volumes and credit records verified and managed separately.
The article says the structure borrows from the central bank principle of separating issuance from circulation. Protocol rules protect the issuance side, while standardized rails support circulation and compatibility.
Emergency control without rolling back the whole chain
On abnormal transactions, Maroo says emergency powers are not meant to be a standing right that operators can use at will. They would be activated only after the fact, with legal grounds and agreed procedures in place first. The project acknowledges real events such as hacks and clearly illegal fund flows.
Its answer is not to roll back the entire blockchain. Instead, it proposes narrowly scoped state corrections under predefined procedures. Tools such as asset freezes, recovery and reissuance for victims are still being evaluated, and the trigger conditions and procedures remain under discussion.
The article frames this as a key reason Maroo is building an independent mainnet. If the network is going to define who responds to abnormal transactions under Korean financial realities, and how, then control over base-layer rules has to remain in-house at the protocol level.
Compliance is moved from fragmented applications to shared infrastructure
Maroo argues that in today’s Korean financial environment, many rules are scattered across fragmented company-level codebases. Once regulation changes, the operational burden becomes immediate. The article gives a simple example: if a travel rule threshold changes by even KRW 1, many operators would need to reconfigure and redeploy systems, and regulators would still have to check consistency one by one.
Maroo’s answer is to move those rules out of the service layer and into infrastructure. Compliance requirements are encoded into the chain itself rather than into each application separately. If a statutory limit changes, one onchain parameter can be updated and every service on the network can follow the new financial rule at the same time.
The article reduces a won-based onchain transaction to three parts: regulatory parameters configured onchain, an engine deciding whether the transaction is allowed, and records exposed according to permission levels.
Legal Oracle as a shared regulatory reference
Maroo introduces what it calls a Legal Oracle, a shared reference layer through which regulators can set practical supervisory data such as transaction limits. Those data points are intended to become the common reference for the whole network.
Updates would be made by an Oracle committee that includes supervisory authorities designing and enforcing rules, financial institutions and legal bodies. The design is meant to prevent any single institution from changing parameters on its own. A change takes effect only after the required quorum is reached, and every step is logged transparently.
A programmable compliance layer built from components and templates
Those regulatory values feed into Maroo’s programmable compliance layer, or PCL. The PCL does not hard-code one fixed rulebook. Instead, it offers building blocks that institutions can combine into their own policy sets. Transfer blocking and threshold checks can exist as separate components, then be linked through AND and OR logic into compound policies.
Maroo also says it offers templates so practitioners can fill in values without writing separate code. Since the values inside those blocks are supplied by the oracle, a regulatory change would not require rewriting the codebase or forcing a hard fork.
The article uses the travel rule as an example. An operator can plug the legal threshold and a 24-hour reset period into a template. Verified users are excluded from that limit, while unverified users are rejected once they cross the threshold. If the legal amount changes, only that value changes.
Transactions are screened before execution
Timing is presented as the center of compliance checks. Maroo says every transaction is filtered through the PCL before execution, and anything that violates preset policy is blocked in the mempool stage. That makes the response infrastructural rather than forensic. The transaction does not execute first and get reviewed later; it fails before execution.
When a transaction is rejected, the network returns a structured reason code that tells operators and users why compliance checks failed.
Checks work on two levels. The first covers network-wide policies that apply to everyone, including sanctions screening and limits for unverified accounts. The second adds contract-specific policies. Assets requiring special handling, such as security tokens, can have verification logic attached directly by the contract owner. A transaction that fails either layer does not get onchain.
Maroo also routes transactions through two different paths because small transfers and institution-level settlements do not require the same intensity of review.
Open path and regulated path
The open path is governed only by network-wide policies. It covers conditions every transaction must satisfy, such as whether the counterparty is sanctioned. Transactions can be sent without prior approval, but they are labeled as open-flow transactions and remain under continuing monitoring.
The regulated path adds contract-level policy on top of the common rules. What matters here is who defines those conditions. The chain does not impose one standard for every case. Instead, the application operating the service defines its own verification standards according to its own regulatory environment, including what credentials are required and what limits apply. A transaction is valid only after passing those checks and obtaining proof of approval before execution.
The article says the split has practical value for financial institutions. A bank, for example, could decide under its internal guidelines that only transactions on the regulated path count as formal settlement records. If problematic activity appears on the open path, Maroo’s analytics tools could support fast post-transaction tracing and serve as a basis for a recovery-like response.
Privacy is role-based, not fully public or fully hidden
Maroo argues that adoption becomes difficult if corporate settlement records are exposed to competitors or if personal spending histories are visible to everyone. At the same time, complete privacy would make compliance systems unworkable and would leave regulators unable to inspect records when needed. The issue, the article says, is not whether data are all public or all hidden, but who is authorized to see what and to what extent.
The answer is a permission-based, layered access model. Ordinary users can see their own histories. The two parties to a transaction can see records between them. Operators and regulators receive access according to their roles and responsibilities.
Technically, Maroo uses a shielded pool based on zero-knowledge proofs, or ZKPs. It does not hide every part of a transaction. Instead, specific fields can be selectively concealed. Users can prove lawful ownership and prevent double spending through encrypted records and proof values without disclosing the amount or the recipient. The network can still verify validity, while the details are shared only between the parties or fully revealed if chosen.
Institutional access follows a separate process. Decryption through an Auditor Key is allowed only when pre-agreed legal and governance conditions have been met, and only within the approved range. In Maroo’s design, private transactions do not become invisible to oversight, and every access event must be transparently logged with the grounds for that access.
The article notes that this model is still at the proof-of-concept stage. Maroo is evaluating whether layered access harms usability, whether institutional permission controls work as intended, and whether the privacy mode conflicts with the compliance layer. The design may still change.
When the transacting party is no longer a human
Maroo says financial rules have so far taken people and legal entities as the starting point. Identity checks and payments alike assumed a natural person or a company stood behind each step. The article argues that this assumption is now being shaken as agents begin to act as transacting parties in their own right.
It points to examples already visible in the market: OpenAI and Stripe enabling payments inside ChatGPT, Amazon testing delegated purchasing, and Visa and Mastercard building settlement rails for agents.
In Maroo’s view, infrastructure built around human counterparties is not yet ready for that shift, which is why the chain is extending its facilities to agents now. The problem on conventional blockchains is account structure. Whoever holds the private key controls the entire account. Handing a key to an agent means handing over full authority. Splitting control too far leaves the agent unable to operate independently. Control and autonomy become opposites.
The result is a traceability gap. If an agent causes trouble, the ledger may show only an anonymous address, with no clear link to the operator behind it or the delegation relationship that enabled it.
Maroo’s answer is a registry. Every agent is tied from creation to a verified personal or corporate account. The delegation relationship is written into a dedicated onchain registration area, where the agent address, owner identity, authorization scope and spending limit are stored as one set of data.
This is what Maroo calls KYA, or Know Your Agent. The article says KYA is not a one-time identity check but a continuing control framework that asks three questions: whether the person or entity that registered the agent has been verified, how much authority the owner delegated, and whether each real transaction stays within that scope. The first two are written in the registry. The last is checked transaction by transaction by the compliance layer.
Maroo says this registry is not a proprietary format. It implements the still-discussed agent identity standard ERC-8004 and bakes that registry into the chain at genesis. Because it follows a standard, agent tools built on other chains can run on Maroo as they are, while identities registered on Maroo can be read in any environment that supports the same standard. The difference, Maroo says, lies in how it connects the registry to the compliance layer so ownership and authorization data are used directly in transaction approval.
Limits, whitelists and owner-level aggregation for agent payments
To explain how the model works, the article compares agents with company cards issued to employees. In that setup, the card has a named user, a spending cap and legal responsibility that still sits with the company. Maroo wants infrastructure that does the same thing for agents.
Single-transaction limit blocks and restricted-address blocks already exist in the system, the article says. What changes is the source of the value those blocks reference. For human-controlled accounts, the limit comes from verification tiers. For agents, it comes from the authorization scope stored in the registry. If an 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 starts with fund separation. The owner transfers usable assets from the owner wallet into the agent account, and the agent can act only within that balance. Policies are then set through the registry. If the single-transaction cap is KRW 1 million, anything above that threshold is stopped immediately.
Whitelists can also define in advance where assets are allowed to go. If approved recipient addresses are registered, transfers can move only to those destinations. If the list is empty, unrestricted transfer logic applies.
Maroo says a single agent limit is not enough, because an owner could otherwise open many accounts to get around it. The system therefore adds an owner-level aggregate limit. Even if one agent stays within its own settings, the infrastructure rejects the transaction once total usage exceeds the threshold allocated to that owner’s verification tier.
Two gates and machine-readable rejection codes
The article says limit-setting matters only if the system keeps watching those limits in real time. Maroo therefore puts one gate before execution and another onchain after that.
- Before the wallet signs, policy checks run first. An over-limit payment is caught here. The way it is rejected matters. The system does not simply respond with a generic failure. It returns a structured reason code showing what blocked the transaction and what range of values would let it pass. The article says the format is built for software, not for human reading, so an agent can read the code, adjust the amount and retry on its own without waiting for a person to inspect logs.
- If the first gate is bypassed, the compliance engine checks the same policy again onchain. A transaction that fails at this stage never reaches the ledger. Once approved, the gas cost and the amount translated into won are recorded, and costs are aggregated per transaction automatically, removing the need for separate end-of-month reconciliation.
The core of the structure is that the compliance layer looks at the real responsible party rather than the outward form of the transaction. Even if an agent bundles multiple payments into one or routes activity through another contract, the infrastructure is designed to locate the owner behind it and apply the owner-level policy. Splitting activity across accounts, in the project’s telling, does not defeat the rules.
Ownership transfers also trigger protections. Once a transfer is proposed, the agent can be frozen for up to 24 hours until the other side accepts. During that period, no transfer and no policy change is allowed, closing off the chance of moving assets during handover.
The article adds that technical standards for agents are still early. Different groups are pushing their own frameworks, though many start from the same idea of first defining the relationship between owner and agent. Maroo treats registry-based owner binding as the first building block. For now, policy execution remains offchain. The project says it has already designed policy shapes according to chain rules and plans to move execution onchain once standards mature and onchain norms become clear. Reputation systems and more detailed verification procedures would be layered in later.
Built for a policy window before Korean rules fully land
The article closes by identifying two policy tracks that define Maroo’s timing. One is still unresolved: who has the authority to issue a won-backed stablecoin anchoring the network. The other has a clearer schedule: revised security token legislation under the Electronic Securities Act is set to take effect in February 2027.
Maroo treats these as different kinds of policy questions. Stablecoin issuance rights and issuer eligibility remain open. Security token legislation, by contrast, has a visible timetable. Even so, the article says both tracks ultimately converge in the authorities’ roadmap because tokenized securities will need a settlement asset, and that settlement question links the two debates.
The practical task, then, is to separate decisions that only institutions and lawmakers can make from technical preparation that can begin now. Some policy values cannot be fixed until legislation is complete. Infrastructure choices, however, can be designed before then. The article says waiting until every rule is finalized makes it difficult to capture an early market position. What is needed instead is to move in step with the policy clock, including implementing decrees, while testing the parts that can already be built.
Maroo says it is not preparing for one predetermined regulatory outcome. It is preparing an infrastructure framework capable of absorbing different regulatory scenarios. How verification conditions are split into modules, how verification tiers map to limits, and how much information becomes available during audit can all be implemented at the infrastructure level before the final legal text is settled.
Once issuance rights and detailed verification requirements are published, the project says those conclusions can be translated into parameters and then into code. Until that point, the real thing to test is whether regulatory requirements can be systematized inside Maroo’s structure. The article’s final point is that the value of preparing infrastructure before the framework takes effect lies in the current window. Once the framework is in force, that window is gone.