Copy English

Why

A stablecoin card where the user pays in stablecoins is the obvious story and the boring one. The load-bearing move sits one layer up, on the issuer's balance sheet: a card program must fund Visa's daily net settlement before it has collected a cent from cardholders, so it needs short-term working capital every single day. Large issuers get that from banks; a new stablecoin-card program has no bank relationship and no track record, so its funding is either expensive or unavailable. That gap — not consumer checkout — is where the on-chain part earns its keep.

Two things make it worth a PoC rather than a headline. First, the underwriting collateral is behavioral, not asset: the credit limit is set from Visa's real settlement data — the issuer's observed throughput and repayment history — so the thing being lent against is a data stream, not posted BTC or cash. Second, repayment is structural, not promised: incoming receipts pass through a smart-contract waterfall that repays the draw before the issuer keeps the remainder, so 'will they pay it back' stops being a trust question and becomes a code path. Credit Coop reports 3,000+ draws and 9,000+ repayments on-chain with zero defaults — that zero is the waterfall's claim to make, and it's exactly the kind of claim a Jayverse PoC exists to test rather than repeat.

It also lands squarely on the umbrella thesis that settlement rails are infrastructure we USE, not build. Visa is the rail; the novel layer is financing the working capital that rail demands, on-chain, against data. The 'just-in-time settlement funding' variant is the sharpest version — borrow exactly the settlement shortfall at settlement time instead of holding a pre-borrowed buffer — and it is a clean thing to model: the cost you remove is idle borrowed capital, and the risk you take on is latency between the draw and the settlement deadline.

How it works

The daily gap the funding fills

A card program owes Visa on Visa's clock, but collects from cardholders on the cardholder's clock. The mismatch is a daily working-capital hole:

The issuer draws stablecoin at T0 to cover the settlement, and repays from receipts at T+n. On-chain, both the draw and the repayment are transactions, and a contract can allocate the incoming receipts to repayment automatically.

What is actually novel — two things, not the stablecoin

1. Underwriting on a data stream, not collateral. The credit limit is derived from Visa's real settlement data for that program — throughput and repayment history — so a program with no assets but a clean settlement record can still borrow. Karta reportedly started on a small revolving line and, after building an on-chain track record, secured a $125M institutional credit line. The track record is the collateral.
2. Repayment as a waterfall, not a promise. Receipts flow through a smart contract that pays down principal + interest before releasing the remainder to the issuer. 'Zero defaults across 9,000+ repayments' is a property of that structure, not of borrower goodwill.

Just-in-time settlement funding

The sharper variant: instead of pre-borrowing a buffer and paying to hold idle capital, draw exactly the settlement shortfall at settlement time, sized from Visa's daily settlement data. The cost removed is idle-capital carry; the risk added is timing — the draw must clear before the settlement deadline. Visa reports up to ~30% lower funding cost for some programs using settlement data + on-chain history this way.

The Jayverse PoC

Model the loop on a local fork, not the numbers: a mock issuer with a daily settlement obligation, a revolving credit-line contract whose limit is a function of a fed-in 'settlement throughput' series, and a repayment waterfall on incoming receipts. Then test the invariants that actually matter — the credit line can never be drawn past its limit, the waterfall always repays before releasing, and (the just-in-time case) a draw that misses the settlement deadline is the failure mode to surface, not hide. Cross-refs: verex settlement (the receipts side), receipt-is-not-settlement (a payment intent is not a settled balance), and the 'rails we use not build' thesis.

← All Dev Notes · Workspace Index · Top ↑

Copy 한국어

온체인 정산 자금 조달 — 소비자의 결제가 아니라 카드 사업자의 운전자본

Visa의 스테이블코인 카드 성장에서 진짜 흥미로운 부분은 한 층 위에 있습니다 — 소비자가 스테이블코인으로 결제하는 것이 아니라, 카드 사업자가 Visa 일일 정산에 필요한 자금을 온체인에서 빌리고, 그 한도를 자신의 정산 실적으로 심사받고, 결제대금이 들어오면 자동 상환하는 흐름입니다. 그 루프를 모델링합니다.

아직 구현이 아니라 만들 모델입니다. 로컬 포크에서 자금 조달 루프를 재현: (1) 사업자는 카드 결제대금이 들어오기 전에 일일 정산액을 갚아야 한다; (2) 그 간극을 메우려 회전 신용한도에서 스테이블코인을 인출한다; (3) 들어오는 결제대금은 스마트계약 워터폴을 거쳐 원금+이자를 먼저 상환한 뒤 나머지를 사업자가 갖는다; (4) 신용한도는 담보 자산이 아니라 관측된 정산 처리량의 함수다. 그다음 'just-in-time' 변형 — 버퍼를 미리 빌리는 대신 정산 시점에 부족분만 인출 — 을 붙이고 유휴자본 비용을 비교하세요. 실제 구조(Visa × Credit Coop, Rain, Karta)와 수치는 각자의 공지로 확인하세요.

왜

소비자가 스테이블코인으로 결제하는 카드는 뻔하고 지루한 이야기입니다. 무게를 지는 동작은 한 층 위, 사업자의 대차대조표에 있습니다 — 카드 프로그램은 소비자에게서 한 푼도 걷기 전에 Visa 일일 순정산을 먼저 갚아야 하므로 매일 단기 운전자본이 필요합니다. 큰 사업자는 은행에서 조달하지만, 신생 스테이블코인 카드 프로그램은 은행 관계도 실적도 없어 자금이 비싸거나 아예 없습니다. 소비자 결제가 아니라 바로 그 간극이 온체인 부분이 값을 하는 자리입니다.

헤드라인이 아니라 PoC로 삼을 이유는 둘입니다. 첫째, 심사 담보가 자산이 아니라 행동입니다 — 신용한도는 Visa의 실제 정산 데이터(사업자의 관측된 처리량과 상환 이력)로 정해지므로, 빌려주는 근거가 예치된 BTC나 현금이 아니라 데이터 스트림입니다. 둘째, 상환이 약속이 아니라 구조입니다 — 들어오는 결제대금이 스마트계약 워터폴을 거쳐 인출분을 먼저 갚은 뒤 나머지를 사업자가 갖으므로, '갚을까'는 신뢰의 문제가 아니라 코드 경로가 됩니다. Credit Coop은 온체인 인출 3,000건+·상환 9,000건+에 채무불이행 0을 보고합니다 — 그 0은 워터폴이 하는 주장이고, Jayverse PoC가 되풀이하지 말고 검증해야 할 바로 그런 종류의 주장입니다.

또한 '정산 레일은 우리가 짓는 게 아니라 쓰는 인프라'라는 우산 명제에 정확히 얹힙니다. Visa가 레일이고, 새로운 층은 그 레일이 요구하는 운전자본을 데이터를 근거로 온체인에서 조달하는 것입니다. 'just-in-time 정산 자금' 변형이 가장 날카로운 버전 — 미리 빌린 버퍼를 들고 있는 대신 정산 시점에 부족분만 인출 — 이고 모델링하기 깔끔합니다: 제거하는 비용은 유휴 차입자본이고, 떠안는 위험은 인출과 정산 마감 사이의 지연입니다.

동작 방식

자금 조달이 메우는 일일 간극

카드 프로그램은 Visa의 시계로 갚지만, 소비자에게선 소비자의 시계로 걷습니다. 그 어긋남이 매일의 운전자본 구멍입니다:

사업자는 T0에 스테이블코인을 인출해 정산을 메우고, T+n에 결제대금으로 상환합니다. 온체인에서는 인출과 상환 둘 다 트랜잭션이고, 컨트랙트가 들어오는 결제대금을 상환에 자동 배분할 수 있습니다.

진짜 새로운 것 — 스테이블코인이 아니라 둘

1. 담보가 아니라 데이터 스트림으로 심사. 신용한도는 그 프로그램의 Visa 실제 정산 데이터(처리량·상환 이력)에서 나오므로, 자산이 없어도 정산 실적이 깨끗하면 빌릴 수 있습니다. Karta는 소규모 회전한도로 시작해 온체인 실적을 쌓은 뒤 1억2500만 달러 기관 신용한도를 확보했다고 합니다. 실적이 곧 담보입니다.
2. 상환이 약속이 아니라 워터폴. 결제대금이 스마트계약을 거쳐 원금+이자를 먼저 갚은 뒤 나머지를 사업자에게 풉니다. '9,000건+ 상환에 채무불이행 0'은 차입자의 선의가 아니라 그 구조의 속성입니다.

Just-in-time 정산 자금

더 날카로운 변형: 버퍼를 미리 빌려 유휴자본 비용을 물지 말고, Visa 일일 정산 데이터로 크기를 잡아 정산 시점에 부족분만 인출합니다. 제거하는 비용은 유휴자본 보유이고, 더하는 위험은 타이밍 — 인출이 정산 마감 전에 완료돼야 합니다. Visa는 이 방식(정산 데이터+온체인 이력)으로 일부 프로그램의 자금 조달 비용이 최대 ~30% 낮아졌다고 보고합니다.

Jayverse PoC

수치가 아니라 루프를 로컬 포크에서 모델링: 일일 정산 의무를 진 모의 사업자, 주입된 '정산 처리량' 시계열의 함수로 한도가 정해지는 회전 신용한도 컨트랙트, 들어오는 결제대금 위의 상환 워터폴. 그다음 진짜 중요한 불변식을 테스트 — 신용한도를 넘겨 인출될 수 없다, 워터폴은 항상 풀기 전에 먼저 상환한다, 그리고 (just-in-time) 정산 마감을 놓친 인출은 숨길 게 아니라 드러낼 실패 모드다. 교차 참조: verex 정산(결제대금 쪽), receipt-is-not-settlement(결제 의사는 정산된 잔액이 아니다), '레일은 짓는 게 아니라 쓴다' 명제.

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