Copy English

Why

The ordering flip is right and it is the whole point. Ask "where can we use a won stablecoin?" and the answers arrive immediately — retail payments, remittance, games, tourist payments, local currency vouchers — because that question cannot fail. Any transaction can be routed through a token. Ask instead "which transactions in today's finance are uncomfortable enough to be worth changing?" and the question can return nothing, which is exactly what makes it useful. A screen that never rejects is not a screen.

The three-part test in the source is the strongest version of it. Size and count alone select for large volume, not for pain. Adding how large is the existing friction and does a won-denominated token actually reduce it turns a wish list into something that can disqualify, and the closing line is the disqualifier stated plainly: if time and cost do not fall and reconciliation does not improve, it is a can, not a needs.

But the test has to be run, and running it on the source's own four candidates kills or reshapes three of them. That is not a criticism of the list — it is the test working, which is the best thing that can be said about a test.

Corporate cross-border payments have the most friction and the weakest answer to "why won." Business hours, FX, correspondent banks and pre-funded liquidity are real costs, and none of them sit on the domestic leg. The far side wants dollars. A won token improves the half of the journey that is already instant and nearly free in Korea, and the half that hurts is displaced by a dollar stablecoin plus an FX venue, not by a won one. The honest form of this candidate is a two-token design where the won leg is a settlement convenience, not the source of the saving.

Policy funds and subsidies have the clearest answer to "why won" and the least fashionable friction. The currency is not a choice — a government disburses in won, to won-denominated recipients, under audit. And the friction is not speed. It is control and proof: what may this money be spent on, was it, and who can show that later. That is programmability rather than settlement, and it is the one candidate where the money being a token changes what the money is rather than how fast it moves. The catch is that the incumbent is not a bank transfer — Korea already restricts purpose with cards and vouchers, so the bar is a merchant-category rule that works today, and the gain has to be measured against that rather than against nothing.

Agent and machine-to-machine payments cannot be screened by this method at all, and saying so is more useful than fudging it. The friction of a transaction nobody makes is unmeasurable. These are not use cases with hidden pain; they are transactions that do not exist because the approval model makes them impossible, and the correct label is an option, not a candidate. agentic-intent-veto is where the actual hard part lives, and it is not settlement.

Repo, collateral and securities settlement is the largest and the one whose instrument is probably not a stablecoin. The won leg here is genuine — domestic bonds settle in won — and the friction is real, but it needs the central bank and the market infrastructure to move together, which makes it market-structure change rather than something to pilot. And when that moves, the instrument is more likely a deposit token issued by banks under central-bank settlement than an issuer-backed stablecoin. japan-t0-settlement and tokenized-money-banks are the two cards already holding that thread.

One thing the source is right about deserves extending further than it goes. Dollar stablecoin growth carries global dollar demand inside it, so the cases do not transfer. But the method does not transfer either — a US stablecoin is measured against ACH, which is slow and expensive, while a won stablecoin is measured against real-time account transfer that already costs almost nothing. Import the friction estimates along with the use cases and every Korean candidate is scored against the wrong incumbent. That is the trap underneath the trap the source names.

How it works

The screen, with the disqualifier made explicit

The four candidates, scored on the source's own test

The trap underneath the trap

The source warns against importing dollar-stablecoin use cases. The sharper version is that importing the method fails too, because the incumbent differs:

This is why retail payments and tourist payments keep appearing on Korean lists and keep going nowhere: they are scored against the wrong baseline. The candidates that survive here are the ones where the incumbent is weak for a structural reason — a border, an audit requirement, a market infrastructure — not for a technical one.

What this catalogue already holds on the same thread

The one-day version

Pick the policy-fund candidate, since it scores best, and fill four rows for a single real disbursement — time, cost, institutions touched, human confirmations — first as it happens today, then as it would with a token, ramps included. Publish the row that does not move. That row is the finding, and it is worth more than a list of possibilities.

Where it lands in Jayverse

• Token/Bridge: run the four-number test on JYVE itself. Before adding more bridge or relayer features, record today's time, cost, institutions touched, and human confirmations for whatever real transfer JYVE's lock-and-mint replaces; if any row doesn't move, that's a can, not a need.
• Verex: score Stripe onboarding against the same screen. Test whether stablecoin settlement actually cuts time, cost or reconciliation versus the existing card or bank onboarding path before assuming rails reduce friction there.
• Bridge: benchmark against the right incumbent. Anvil devnet targets Sepolia, not a Korean bank account; measure relayer latency and cost against Korea's real-time transfer baseline, not a slow US-style comparison, or every candidate scores better than it is.
• Auditor: adopt the can-vs-needs disqualifier as a gate. Require the four-number test — time, cost, institutions, confirmations — as a standing check before Auditor signs off on any new JYVE or bridge use case pitch.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

스테이블코인으로 할 수 있는 일이 아니라, 스테이블코인이 필요한 일

"원화 스테이블코인을 어디에 쓸 수 있을까"에서 출발하면 어디든 찾아냅니다. "오늘 어떤 거래가 충분히 불편한가"에서 출발하면 목록이 훨씬 짧아집니다 — 그리고 한국에서 이겨야 할 상대는 느린 정산이 아니라 즉시·무료 계좌이체입니다.

하루, 코드 없이. 후보 거래 하나를 골라 오늘의 숫자 넷을 기록합니다 — 지시부터 실제 사용 가능한 자금까지의 경과 시간, 총비용, 돈이 거쳐 가는 기관 수, 사람이 확인하는 횟수. 그다음 스테이블코인 버전의 같은 넷을 정직하게 씁니다 — 양 끝의 온·오프램프를 포함해서. 절감분 대부분이 거기서 사라지기 때문입니다. 한 행이라도 움직이지 않으면, 그 후보는 스테이블코인으로 할 수 있는 일이지 필요한 일이 아닙니다. 출처: 원화 스테이블코인 유즈케이스 발굴 방법에 대한 국내 실무자 메모, 2026-08-27. 거래 규모·기존 금융의 마찰·원화 토큰이 실제로 그 마찰을 줄이는가를 선별 기준으로 제시. 프레이밍이 기여이고, 후보 목록은 시험대입니다.

왜

순서를 뒤집은 것이 맞고, 그게 요점 전부입니다. "원화 스테이블코인을 어디에 쓸 수 있을까"라고 물으면 답이 즉시 옵니다 — 리테일 결제, 해외송금, 게임, 관광객 결제, 지역화폐 — 그 질문은 실패할 수가 없기 때문입니다. 어떤 거래든 토큰으로 태울 수는 있으니까요. 대신 "오늘 금융에서 어떤 거래가 바꿀 값어치가 있을 만큼 불편한가"라고 물으면 아무것도 안 나올 수 있고, 바로 그것이 이 질문을 쓸모 있게 만듭니다. 한 번도 탈락시키지 않는 기준은 기준이 아닙니다.

원문의 3단 시험이 그것의 가장 강한 형태입니다. 금액과 건수만 보면 불편함이 아니라 물량을 고르게 됩니다. 여기에 기존 마찰이 얼마나 큰가 와 원화 표시 토큰이 실제로 그것을 줄이는가 를 더하면, 희망 목록이 탈락시킬 수 있는 것으로 바뀝니다. 그리고 마지막 문장이 그 탈락 조건을 그대로 적어 놓았습니다 — 시간과 비용이 줄지 않고 대사가 나아지지 않으면 '필요한 일'이 아니라 '할 수 있는 일'.

다만 시험은 실제로 돌려야 하고, 원문의 후보 넷에 돌리면 셋이 죽거나 모양이 바뀝니다. 목록에 대한 비판이 아닙니다 — 시험이 작동한 것이고, 시험에 대해 할 수 있는 최고의 말입니다.

기업 해외송금은 마찰이 가장 크고 "왜 원화인가"에 대한 답이 가장 약합니다. 영업시간·환전·중계은행·선예치 유동성은 진짜 비용이고, 그중 어느 것도 국내 구간에 있지 않습니다. 반대편은 달러를 원합니다. 원화 토큰은 한국에서 이미 즉시이고 거의 무료인 절반을 개선하고, 아픈 절반을 대체하는 것은 달러 스테이블코인 + FX 창구이지 원화 토큰이 아닙니다. 이 후보의 정직한 형태는 두 토큰 설계이고, 거기서 원화 구간은 절감의 원천이 아니라 정산의 편의입니다.

정책자금·보조금은 "왜 원화인가"에 대한 답이 가장 분명하고, 마찰은 가장 안 멋있습니다. 통화가 선택이 아닙니다 — 정부가 원화로, 원화 표시 수급자에게, 감사 아래 지급합니다. 그리고 마찰은 속도가 아닙니다. 통제와 증명입니다 — 이 돈은 어디에 쓸 수 있는 돈인가, 실제로 그렇게 쓰였는가, 그것을 나중에 누가 보일 수 있는가. 이건 정산이 아니라 프로그래머빌리티이고, 돈이 토큰이라는 사실이 돈의 이동 속도가 아니라 돈의 정체를 바꾸는 유일한 후보입니다. 함정은 기존 대안이 계좌이체가 아니라는 것 — 한국은 이미 카드와 상품권으로 용도를 제한합니다. 그러니 넘어야 할 기준선은 오늘도 잘 돌아가는 가맹점 업종 제한이고, 이득은 무(無)가 아니라 그것에 대고 재야 합니다.

AI 에이전트·기계 간 거래는 이 방법으로 아예 선별할 수 없고, 그렇다고 말하는 편이 얼버무리는 것보다 유용합니다. 아무도 하지 않는 거래의 마찰은 측정 불가입니다. 이것들은 숨은 고통이 있는 유즈케이스가 아니라, 승인 모델 때문에 불가능해서 존재하지 않는 거래이고, 올바른 이름표는 후보가 아니라 옵션입니다. 진짜 어려운 부분은 agentic-intent-veto 에 있고, 그건 정산이 아닙니다.

Repo·담보·증권결제는 가장 크고, 그 수단이 아마도 스테이블코인이 아닌 후보입니다. 여기서 원화 구간은 진짜입니다 — 국내 채권은 원화로 결제되니까요 — 마찰도 진짜지만, 중앙은행과 시장 인프라가 같이 움직여야 하므로 파일럿할 것이 아니라 시장구조 변화입니다. 그리고 그것이 움직일 때의 수단은 발행사 담보형 스테이블코인보다 중앙은행 결제 아래 은행이 발행하는 예금토큰일 가능성이 큽니다. 그 실을 이미 붙들고 있는 카드가 japan-t0-settlement 와 tokenized-money-banks 입니다.

원문이 옳게 짚은 것 하나는 원문보다 더 멀리 밀 값이 있습니다. 달러 스테이블코인의 성장에는 달러 자체에 대한 글로벌 수요가 들어 있어서 사례가 이전되지 않습니다. 그런데 방법론도 이전되지 않습니다 — 미국 스테이블코인은 느리고 비싼 ACH에 대고 재지만, 원화 스테이블코인은 이미 거의 공짜인 실시간 계좌이체에 대고 재야 합니다. 사례와 함께 마찰 추정치까지 수입하면 모든 국내 후보가 엉뚱한 기준선으로 채점됩니다. 원문이 지적한 함정 아래에 있는 함정입니다.

동작 방식

선별 기준, 탈락 조건을 드러낸 형태

후보 넷, 원문 자신의 기준으로 채점

함정 아래의 함정

원문은 달러 스테이블코인의 사례를 수입하지 말라고 경고합니다. 더 날카로운 형태는 방법론도 수입하면 안 된다는 것입니다. 기존 대안이 다르기 때문입니다:

리테일 결제·관광객 결제가 국내 목록에 계속 등장하고 계속 아무 데도 못 가는 이유가 이것입니다 — 엉뚱한 기준선으로 채점되고 있습니다. 여기서 살아남는 후보는 기존 대안이 기술적 이유가 아니라 구조적 이유로 약한 것들입니다 — 국경, 감사 요건, 시장 인프라.

이 카탈로그가 같은 실 위에 이미 갖고 있는 것

하루짜리 버전

채점이 가장 좋은 정책자금 후보를 골라, 실제 지급 건 하나로 네 행을 채웁니다 — 시간, 비용, 거쳐 가는 기관 수, 사람이 확인하는 횟수 — 먼저 오늘 벌어지는 대로, 그다음 토큰이라면 어떻게 되는지, 램프까지 포함해서. 움직이지 않는 행을 발표하십시오. 그 행이 곧 발견이고, 가능성 목록보다 값어치가 큽니다.

Jayverse에서의 위치

• Token/Bridge: JYVE 자체에 4개 숫자 테스트를 돌린다. 브릿지나 릴레이어 기능을 더 추가하기 전에, JYVE의 lock-and-mint가 대체하는 실제 송금에 대해 오늘 기준 시간, 비용, 거쳐가는 기관 수, 사람의 확인 횟수를 기록한다. 어느 한 행이라도 움직이지 않으면 그건 필요가 아니라 가능일 뿐이다.
• Verex: Stripe 온보딩을 같은 잣대로 평가한다. 스테이블코인 정산이 기존 카드/은행 온보딩 경로 대비 시간, 비용, 대사 작업을 실제로 줄이는지 먼저 검증한 뒤에야 레일이 마찰을 줄인다고 가정한다.
• Bridge: 올바른 비교 대상을 쓴다. Anvil devnet은 한국 은행 계좌가 아니라 Sepolia를 겨냥한다. 릴레이어의 지연과 비용은 느린 미국식 비교가 아니라 한국의 실시간 이체 기준선과 비교해야 한다. 그렇지 않으면 모든 후보가 실제보다 좋아 보인다.
• Auditor: can-vs-needs 판별 기준을 게이트로 삼는다. 새로운 JYVE 또는 브릿지 유스케이스 제안을 승인하기 전에, 4개 숫자 테스트(시간, 비용, 기관, 확인 횟수)를 상시 점검 항목으로 요구한다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑