Workspace Index › Dev Notes › Priced in fiat, settled in tokens — the quote is a product promise
#52PoC
Priced in fiat, settled in tokens — the quote is a product promise
A five-dollar checkout paid in a volatile token needs a quote TTL, a re-quote flow and a policy for who absorbs the drift. That is product design wearing an exchange-rate costume — not an oracle problem.
Build a checkout that locks a token amount for a fixed fiat price for thirty seconds, expires visibly into a re-quote, and tabulates the three drift policies — merchant absorbs, buyer absorbs, band with re-quote — against a simulated price feed.
Why
Users think in their currency; chains settle in theirs. Between the price shown and the payment settling, the rate moves — so every fiat-priced crypto checkout is silently running a tiny FX desk, whether its designers noticed or not. Ignore it and either the merchant leaks margin on every dip or the buyer gets surprise-charged on every spike; both discoveries arrive as support tickets.
The deliberate version has three knobs: how long a quote is honored (TTL), what happens at expiry (re-quote UX, not a silent failure), and who eats movement inside the window. None of these is an oracle question — the oracle only tells you the rate; the product decides what to promise about it. Stablecoin settlement makes the window narrow, not zero, and the structure identical.
How it works
One checkout, a scripted price feed, three drift policies, and the ledger of who paid for movement.
PoC
A checkout against anvil: item priced 5 USD, paid in a mock token whose USD price a script walks ±3% per minute. Quote endpoint returns { tokenAmount, quoteId, expiresAt(+30s) }; payment submits quoteId; the server accepts, re-quotes, or rejects per policy. Run the same 100 purchases with prices replayed under each policy: (A) honor expired quotes — measure merchant loss; (B) reject at settlement if moved — measure buyer failures; (C) 30s TTL with visible countdown and one-click re-quote — measure both. Print the three-row table.
What it proves
The quote is a short-dated option the product writes for free, and TTL is its expiry. Policy A prices the option at the merchant's expense, B at the buyer's UX, C bounds both — which is why every serious crypto checkout (and every FX-touching commerce API) converges on C. The interesting output is not the code but the table: drift cost as a product decision made visible.
변동성 있는 토큰으로 결제하는 5달러짜리 체크아웃에는 견적 TTL, 재견적 플로우, 그리고 변동분을 누가 흡수하는지의 정책이 필요합니다. 오라클 문제가 아니라 환율 의상을 입은 제품 설계입니다.
고정된 법정화폐 가격에 대한 토큰 수량을 30초간 잠그고, 만료를 눈에 보이게 재견적으로 잇는 체크아웃을 만듭니다. 그리고 세 가지 변동 정책 — 상인 흡수, 구매자 흡수, 밴드 + 재견적 — 을 시뮬레이션 가격 피드에 대고 표로 만듭니다.
왜
사용자는 자기 통화로 생각하고, 체인은 자기 통화로 정산합니다. 표시된 가격과 결제 체결 사이에 환율이 움직입니다 — 그래서 법정화폐로 가격을 매기는 모든 크립토 체크아웃은, 설계자가 알았든 몰랐든, 조용히 작은 FX 데스크를 운영 중입니다. 무시하면 하락 때마다 상인이 마진을 흘리거나 급등 때마다 구매자가 기습 청구를 당하고 — 두 발견 모두 CS 티켓으로 도착합니다.
의도된 버전에는 손잡이 셋이 있습니다: 견적을 존중하는 시간(TTL), 만료 시의 처리(조용한 실패가 아니라 재견적 UX), 그리고 창 안의 움직임을 누가 먹는가. 어느 것도 오라클 질문이 아닙니다 — 오라클은 환율을 알려줄 뿐, 무엇을 약속할지는 제품이 결정합니다. 스테이블코인 정산은 창을 좁힐 뿐 0 으로 만들지 않고, 구조는 동일합니다.
동작 방식
체크아웃 하나, 스크립트로 움직이는 가격 피드, 세 가지 변동 정책, 그리고 움직임의 값을 누가 냈는지의 장부.
PoC
anvil 대상 체크아웃: 5 USD 상품을, 스크립트가 분당 ±3% 로 걷게 만든 목 토큰으로 결제. 견적 엔드포인트는 { tokenAmount, quoteId, expiresAt(+30초) } 를 반환하고, 결제는 quoteId 를 제출하며, 서버는 정책에 따라 수락·재견적·거절합니다. 같은 구매 100건을 가격 리플레이로 정책별 실행: (A) 만료 견적도 존중 — 상인 손실 측정; (B) 움직였으면 정산 시 거절 — 구매자 실패 측정; (C) 30초 TTL + 보이는 카운트다운 + 원클릭 재견적 — 둘 다 측정. 세 줄짜리 표를 출력합니다.
무엇을 증명하나
견적은 제품이 공짜로 써 주는 단기 옵션이고 TTL 이 그 만기입니다. 정책 A 는 그 옵션 값을 상인이, B 는 구매자 UX 가 치르고, C 는 둘 다 한정합니다 — 진지한 크립토 체크아웃(그리고 FX 를 만지는 모든 커머스 API)이 C 로 수렴하는 이유입니다. 흥미로운 산출물은 코드가 아니라 표입니다: 제품 결정으로서의 변동 비용을 눈에 보이게 만든 것.