On-chain transfers can also be intercepted in accordance with financial regulations, with Maroo using a “legal oracle” to adjust compliance parameters.
Written by: Ryan Yoon, Ekko an, Tiger Research
Compiled by: AididiaoJP, Foresight News
The Won: Pricing Baseline of South Korea’s Financial System
The salary payouts, tax payments, consumption, and investments of residents in South Korea are ultimately denominated and settled in won. Finance may know no borders, but the medium of exchange actually used by ordinary people remains the won.
National rules and systems shape the financial system. Consumers may not realize it, but behind every transaction structure lie negotiated and agreed-upon rules. Anti-money laundering is a prime example. While international AML thresholds suggest around $1,000, implementation varies by country: the United States sets it above $3,000, which is more lenient than the recommendation; South Korea recently removed the 1 million won floor, meaning payer and payee information must accompany transactions regardless of amount.
While financial rules share common international benchmarks, the actual transaction rules that operate in practice take different shapes due to each country’s financial environment and institutional framework. Implementation must adapt to the specific circumstances of each jurisdiction.
The same applies to on-chain financial innovation. Technology can cross borders, but the financial systems executing that technology still rely on local regulations and local practices. Therefore, understanding a local financial baseline rule and encoding it into infrastructure becomes a core competitive advantage, not a limitation. Few participants accurately understand local market contexts and successfully embed them into infrastructure.
Maroo: Born in South Korea
Maroo is a public chain built in South Korea precisely to address this need.
The project is led by Hashed Open Finance. It is a subsidiary established by Hashed for stablecoin commercialization, real-world asset tokenization, and security token issuance. Founded in 2017, Hashed is a leading blockchain investment and acceleration organization in South Korea. Advancing Maroo through Hashed Open Finance leverages close-range experience with changes in the South Korean market.
Technical partners include ShardLab and Delight Labs. ShardLab previously collaborated with Thai financial group SCBX to design and operate stablecoin payment infrastructure in Southeast Asia; Delight Labs has been engaged in chain operations since 2018, managing multiple nodes and mainnets.
Moving forward, the project plans to discuss regulatory alignment with the government and financial institutions, while collaborating with academia and the startup ecosystem to broaden applications.
All three founding teams have offices in Seoul. Hashed Open Finance operates as an independent entity handling domestic licensed businesses, while ShardLab and Delight Labs provide support from their Seoul offices. Korean institutions, academic bodies, and startups are expected to join.
Maroo’s design directly encodes the institutional and regulatory characteristics of the South Korean market into its infrastructure.
This Chain Operates in Won
Daily economic activities for South Korean residents unfold in won: salaries are deposited, followed by management fee payments, daily purchases, and savings. Wages, taxes, utilities, and investments—the entire real economy already operates entirely in won, most of which have already been digitized.
Yet the real digital economy remains separated from existing on-chain ecosystems. Most on-chain environments are dollar-denominated, creating a clear disconnect from the won accounting used daily by South Korean residents.
Maroo therefore designates the won stablecoin OKRW as the network’s base unit, aiming to bring everyday accounting denominations on-chain rather than fragmenting them.
The primary benefit is predictable cost structure. During any network congestion, Gas fees rise, and Maroo is no exception. If Gas were paid in assets with volatile prices, an additional problem would arise: increased usage drives up demand and price for that asset, making the same transaction more expensive, causing congestion and coin price to amplify each other.
Maroo’s base asset is the won. Increased usage does not inherently change the value of the won. With coin price volatility removed, the only major variable affecting Gas is congestion, which can be estimated based on transaction volume.
Costs do not disappear. During high traffic, Gas burdens increase, along with operational costs like servers and Gas sponsorship. These costs fall on on-chain service operators, not end users. Predictability lies in the fact that costs are determined by the operator’s own transaction volume—a planning-friendly variable, rather than uncontrollable market prices.
Financial institutions acting as primary distributors of OKRW require more than just predictable costs. They also raise two fundamental questions regarding the won itself: who holds the authority to issue currency, and who controls transactions in emergencies?
Who Has the Authority to Issue Currency?
In the real world, issuance rights are granted only to specific entities. On Maroo, OKRW’s issuance rights are also strictly isolated from normal execution permissions and designed according to three principles:
Governance-based issuance control: Issuance authority is decided through protocol-level consensus and governance, not unilateral corporate decision-making.Issuance encoded in chain logic: Issuance functions are on-chain precompiles, not smart contracts. Changing rules requires modifying chain logic, not just swapping contracts.Separation of issuance and circulation technology: Circulation uses ERC-20 for compatibility; issuance runs through an independent system account, with issuance volumes and credit records verified and managed separately.
This structure draws from the central banking principle of separating «issuance rights from circulation». The protocol governs issuance rules for security, while circulation relies on standardized facilities for compatibility, with both simultaneously pursuing stability and expansion.
Who Controls Transactions in Emergencies?
Emergency transaction controls are not standing powers that operators can invoke at will. They are triggered post-event and require prior legal basis and established procedures.
Maroo acknowledges the need to handle real-world incidents like hacking and overtly illicit fund flows. It does not roll back the entire chain but corrects states within limited scopes according to pre-established procedures.
Tools such as asset freezing, recovery, and reissuance for victims remain under evaluation, with trigger conditions and procedures still under discussion.
This is also a key reason for Maroo building its own independent mainnet. To define «who handles abnormal transactions and how» according to South Korea’s financial reality, one must be able to independently control the network’s underlying rules. Just as a nation guards monetary sovereignty, Maroo chooses to place this power at the protocol layer.
How Won Transaction Rules Are Encoded On-Chain
In South Korea’s current financial environment, these rules are scattered across the code of fragmented services offered by various companies. As soon as regulations change, the costs become immediately apparent. Even a 1 won adjustment to the Travel Rule threshold forces numerous operators to reconfigure and redeploy systems; regulators must then verify compliance item by item, making regulatory response itself a core operational burden.
Maroo shifts rules from the service layer to the infrastructure layer, encoding compliance requirements directly into the chain rather than into individual apps. When statutory limits change, adjusting a single chain parameter allows all online services to simultaneously align with new financial rules.
A typical on-chain won transaction roughly involves: configuring on-chain regulatory parameters, an engine evaluating whether the transaction is permitted, and records being accessible according to permissions.
How Regulation Is Reflected
Maroo introduces a shared reference layer called the Legal Oracle. Regulatory bodies set practical regulatory data such as transaction limits themselves, providing a unified regulatory benchmark for the network.
Data is updated by the Oracle Committee, comprising competent authorities that design and enforce regulation, financial institutions, and legal bodies. This allows rulemakers to directly map network rules onto the ledger.
The core design prevents any single institution from unilaterally modifying parameters. Changes require meeting a stipulated quorum to take effect, ensuring full transparency and audit trails.
This data applies to live transactions via the Programmable Compliance Layer (PCL). The PCL does not hardcode rules itself but provides Lego-like components that institutions can assemble into custom compliance policies. Conditions like blocking transfers or setting limits are packaged as individual blocks, then woven into composite policies using AND/OR logic.
Maroo also provides templates where practitioners only need to input values without writing additional code. Values within blocks are supplied by oracles, so when the regulatory environment changes, neither code updates nor hard forks are required.
The Travel Rule serves as an example. Operators input the statutory threshold and 24-hour reset cycle into the corresponding template. Verified users are excluded from this limit; unverified users face immediate transaction rejection once the threshold is crossed. If legal amount limits change, only that single value needs updating.
When and How Rules Take Effect
Timing is central to compliance verification. Every transaction on Maroo passes through PCL filtering before execution, with those violating preset policies intercepted during the mempool stage.
This is infrastructure-level response: transactions are prevented from executing altogether rather than subject to post-hoc tracing. Upon rejection, structured reason codes are returned, clearly informing operators and users why the compliance check failed.
Verification operates in two layers. The first is network-wide policy, covering universal rules for all participants, including sanctions screening and unverified account limits. The second is contract-specific policy. Assets requiring special handling, such as security tokens (STOs), have verification logic directly attached by contract owners. Integrated as one, transactions failing conditions cannot make it on-chain.
Maroo also implements dual-track routing based on transaction nature, as micro-transfers and institutional settlements require different verification intensities.
The open path is constrained only by network-wide policy, covering mandatory conditions for every transaction, such as counterparty sanctions screening. Transactions can be broadcast without prior approval but are flagged as open flows for continuous monitoring.
The regulated path adds contract-level policy on top of this. The key question is who sets the conditions: the chain does not mandate uniform standards; instead, operating service apps define their own verification criteria. Operators decide which credentials are needed and what limits apply based on their local regulatory environment. Transactions must pass checks and obtain approval proofs before execution to be valid.
The difference between the two paths lies in the number of verification tiers. The open path uses only shared rules, while the regulated path layers on the operator’s own standards.
This split-path approach offers practical value for financial institutions. Banks can follow internal guidelines to recognize only transactions on the regulated path as formal settlement records. If improper transactions are detected on the open path, they can be quickly traced post-event using Maroo’s analytics facilities, serving as grounds for quasi-asset recovery measures.
Who Can See Records
If corporate settlement records are exposed to competitors, or personal spending flows are visible to anyone, pushing adoption on-chain becomes extremely difficult. Financial data confidentiality is a requirement, not an option.
Yet total opacity also fails. The aforementioned verification system requires transaction data to function, and regulators must also be able to inspect when necessary.
The question is neither full disclosure nor complete hiding, but who is authorized to access what, and to what extent.
Maroo resolves this through permission-based tiered access. Ordinary users view their own statements, while transacting parties see records between them. Operators and regulators receive corresponding information based on roles and responsibilities.
Technically, it employs zero-knowledge proof (ZKP) based shield pools. Rather than concealing entire transactions, specific fields are selectively masked. Users can leverage encrypted records and proof values to demonstrate lawful ownership and prevent double-spending, all while keeping amounts and payees hidden.
The network validates transaction validity, with details shared only among involved parties, though full disclosure remains an optional choice.
Institutional access follows a separate procedure. Decryption via the Auditor Key occurs strictly within approved scopes, only when pre-agreed legal and governance conditions are met. Private transactions thus avoid regulatory blind spots; every access event—who accessed what and under what authorization—must be transparently logged.
This model is currently in the proof-of-concept (PoC) phase. Maroo is carefully assessing whether tiered access degrades user experience, if institutional permission controls prove effective, and whether privacy modes conflict with the compliance layer. Detailed designs may be adjusted later.
When Counterparties Are No Longer Humans
To date, financial rules have started from humans. From identity verification to payments, natural persons or legal entities stand at every step.
This premise is being shaken: agents are gradually replacing humans as counterparties. Concrete moves are already visible: OpenAI and Stripe processing payments within ChatGPT, Amazon piloting delegated procurement, Visa and Mastercard building agent settlement infrastructure.
Financial infrastructure built around humans cannot yet fully accommodate this paradigm shift. This is why Maroo is extending its facilities to agents at this moment.
Whose Agents Are These?
Companies issue corporate cards to employees: cards display the user’s name, feature spending limits, and place ultimate liability for each payment on the company. The card binds the actual user, authority to act, and legal responsibility into a single unit.
Blockchain’s basic account structure cannot achieve this linkage. Whoever holds the private key monopolizes full account control. Handing keys to an agent equals surrendering complete authority; splitting control leaves the agent unable to operate autonomously. Control and autonomy become opposites.
The result: when an agent encounters issues, the on-chain ledger only records an anonymous address, obscuring both the behind-the-scenes operator and the delegation relationship.
Maroo fills this gap using a registry.
Every agent is bound from creation to a personally or corporately verified account. Delegation relationships are explicitly recorded in a dedicated on-chain registration zone: agent address, owner identity, authorization scope, and spending limits are written as a single dataset.
This is what Maroo defines as KYA (Know Your Agent). KYA is not a one-time identity check but a continuous control framework examining three things: whether the registering person or entity is verified; how much authority the owner delegated; and whether the agent stays within that scope during actual transactions.
The first two are recorded in the registry, while the final item is verified by the compliance layer for every transaction.
This registry is not a Maroo-private format. Maroo implements the proposed agent identity standard ERC-8004 and embedded it on-chain at genesis. It is the network’s sole registry held from the start, not a contract deployed later by a specific application.
Built to standard, agent tools from other chains can run natively on Maroo; conversely, agent identities registered on Maroo can be read by any environment supporting this standard.
The divergence point lies in connecting to the compliance layer. Standard registries merely record «whose agent this is»; using this record for transaction approval is another matter entirely. Maroo bridges registry records with the compliance layer, feeding ownership and authorization data directly into transaction approvals.
The structure mirrors a company issuing cards to employees: the card designates an owner, caps spending limits and acceptable merchants, and verifies each payment. Treating agents as formal counterparties means the infrastructure performs these three tasks on behalf of the owner.
Global standards for agent transaction approval are still nascent and undetermined. Maroo is therefore designed with a flexible architecture, aiming to secure its position in early markets first.
How Much to Delegate?
Corporate card limits exist not out of distrust toward employees, but because a single error should not collapse a company. Software amplifies the scale of mistakes. A human might press a wrong payment button once; flawed code can repeat the same error dozens of times per second.
Single-transaction limit blocks and address-masking blocks already exist. The only change is the source of the values referenced by these blocks. Human account limits are dictated by verification tiers; agents draw authorization scopes from the registry.
If an owner sets a 1 million won limit in the registry, the compliance layer reads this value for every transaction and rejects any that exceed it.
The model begins with fund segregation. Owners transfer available assets from their wallets to the agent account, restricting agent actions to this balance alone. Policies are then configured via the registry. Setting a 1 million won limit instantly blocks any single transaction surpassing it.
Whitelists predetermine where assets can flow. Once specific receiving addresses are registered, transfers are restricted to approved destinations; unrestricted transfer logic only triggers when the list is empty.
Limits on individual agents are not comprehensive. To prevent opening countless accounts to circumvent caps, the system establishes aggregate limits at the owner level. Even if a single agent stays within its configuration, the infrastructure will reject requests once the total exceeds the threshold allocated to that owner based on verification tiers.
What Happens When Out of Scope?
Setting limits and monitoring them in real time are equally critical. Checking only once allows breaches to slip past. Maroo places checkpoints both before and after every transaction.
1) Policy checks occur before wallet signing. Over-limit transfers are caught here. The rejection method is crucial: rather than just saying «no», it returns structured reason codes explaining what blocked the transaction and what values would allow it. This is a machine-readable format, not a human notification. Agents parse the codes, adjust amounts, and retry autonomously without waiting for humans to scour logs.
2) If bypassed initially, the compliance engine re-verifies the same policy on-chain. Transactions failing this checkpoint never make it on-chain. Once approved, Gas fees and won-equivalent amounts remain in the records, automatically aggregating costs per transaction without requiring separate month-end reconciliation.
The core of this structure is that the compliance layer targets actual responsible parties, not transaction appearances. Even if an agents bundles multiple transactions or routes through another contract, the infrastructure will still trace back to the underlying owner and apply the policies tied to that owner. Thus, splitting accounts and distributing limits proves ineffective.
Ownership transfers trigger protective measures. Upon submission of a transfer request, the agent freezes for up to 24 hours until accepted by the counterparty. During this window, no transfers or policy modifications occur, preventing stealthy asset extraction prior to handover.
Agent-related technical standards remain premature. Various factions push their own frameworks, but most share a common starting point: defining the owner-agent relationship first. Maroo treats registry-based owner binding as its foundational block, weighing what can be firmly defined now versus what must wait for mature standards.
Consequently, policy execution currently operates off-chain. Maroo has pre-designed policy structures aligned with chain rules, planning to migrate execution on-chain once standards mature and establish protocol-level norms. Reputation systems and finer-grained verification procedures will be layered on subsequently.
What Should Be Validated Now
Maroo is the chain offering the deepest reading of South Korea’s institutional context and specifics at the infrastructure layer. Anything landing on this foundation will traverse every financial sector touching the real economy.
The two greatest near-term inflection points revolve around two axes: debates continue over who holds the authority to issue networks-anchored won stablecoins, while legislation for security tokens (STOs) is moving toward a fixed timeline.
Their nature differs fundamentally. Issuance qualifications and entities for won stablecoins remain under deliberation, constituting unresolved policy questions. Security tokens, however, have a clear trajectory: the revised Securities and Exchange Act will take effect in February 2027.
While issuance discussions and STO timelines appear separate, the authority’s roadmap sets their convergence point as the ultimate goal—determining the settlement mechanism for tokenized securities will ultimately funnel both discussions into a single conclusion.
The core of pragmatic response lies in decoupling matters requiring institutional decree from items that can be technically prepared today. Some policy values must await legislative enactment, while certain infrastructure can be architected beforehand.
Waiting for rules to finalize before selecting infrastructure makes capturing early-market positions nearly impossible. The approach requires synchronizing with the policy clock—including promulgation of enforcement decrees—while isolating and building components ready for advance validation.
Maroo prepares not for a specific institutional conclusion, but for an infrastructure framework capable of accommodating any regulatory scenario. How verification conditions decompose into modules, how verification tiers interface with limits, and how far information opens during audits—all can be implemented at the infrastructure layer prior to legislative finalization.
Once issuance qualifications and specific verification requirements are published, Maroo can treat these conclusions as parameters and instantly compile them into code.
Prior to policy conclusions, what needs validation now is how regulatory demands are systematically integrated into Maroo’s architecture. Pre-demonstrating a structure capable of absorbing outcomes regardless of direction essentially builds rapid-response technical capabilities ahead of policy uncertainty.
Preparing infrastructure before the regulatory framework lands offers only one advantage: this narrow window. Once the framework takes effect, this window slams shut permanently.