PayChain Medium Series · 5 Parts

Part 1 of 5

결제와 정산 사이의 잃어버린 계층

Missing Layer Between Payment and Settlement

결제는 해결되었지만, 금융 신뢰는 아직 해결되지 않았다

Why payments were solved, but financial trust was not

Pay Protocol · PCI Network · PayChain · June 2026 · ~12 min read

Money · Payment · Settlement · Execution · Coordination: 비어 있는 정산 계층

Money · Payment · Settlement · Execution · Coordination: the empty settlement layer

누구를 위한 글인가

Who this is for

맞습니다: 결제 이후 정산·감사·네트워크 정체성이 필요한 PG·은행·커머스·Web3 팀, PayChain을 금융 인프라로 평가하려는 파트너. 맞지 않습니다: 순수 TPS·가스 비교만 찾는 독자, 완성된 permissionless rollup을 전제로 하는 독자.

Good fit: PG, bank, commerce, and Web3 teams needing post-payment settlement, audit, and network identity; partners evaluating PayChain as financial infrastructure. Not a fit: readers wanting only TPS/gas benchmarks, or assuming a finished permissionless rollup.

1. 첫 질문은 “얼마나 빠른가”가 아니다

1. The first question is not “how fast”

블록체인 산업은 지난 10년 동안 트랜잭션을 최적화했습니다. 더 높은 TPS, 더 낮은 수수료, 더 짧은 finality. 그러나 실제 금융 인프라를 운영하는 기관과 파트너가 새 네트워크를 검토할 때 먼저 묻는 질문은 다릅니다. “이 거래는 감사 가능한가?”, “환불이 발생하면 어떻게 추적되는가?”, “장애가 나면 어느 상태에서 복구하는가?”, “정산이 실패하면 누가 책임지는가?”

For a decade the blockchain industry optimized transactions: higher TPS, lower fees, shorter finality. But institutions and partners who actually run financial infrastructure ask different questions first: “Is this auditable?”, “How is a refund traced?”, “From what state can we recover after an incident?”, “If settlement fails, who is responsible?”

금융 네트워크의 경쟁력은 정상 상황이 아니라 예외 상황에서 드러납니다. 결제가 성공했을 때보다 실패했을 때, 정산이 맞았을 때보다 틀어졌을 때, 환불·분쟁·수수료 조정·장부 불일치·감사 요청이 동시에 몰릴 때가 더 중요합니다. 그래서 이 시리즈의 첫 질문은 “PayChain은 무엇인가”가 아니라 “왜 결제만으로는 금융 네트워크가 충분하지 않은가”입니다.

A financial network proves itself in exceptions, not the happy path: a failed payment matters more than a successful one, broken settlement more than settlement that reconciles, and the moment when refunds, disputes, fee adjustments, ledger mismatches, and audits arrive at once. So the first question of this series is not “what is PayChain?” but “why is payment alone not enough for a financial network?”

2. 성공한 금융사는 제품이 아니라 네트워크를 만들었다

2. The best financial firms built networks, not products

Visa는 FY2025 기준 14.2조 달러 규모의 결제와 2,575억 건의 거래를 처리합니다. Stripe 위에서 2025년 발생한 비즈니스 거래량은 1.9조 달러로 전 세계 GDP의 약 1.6%에 해당합니다. 이들의 해자는 “돈을 빠르게 옮기는 기능”이 아니라, 승인·리스크·수수료·정산·환불·분쟁·대사·회계·감사라는 복잡한 금융 운영을 신뢰 구조 뒤로 추상화한 데 있습니다.

Visa processes $14.2T in payments and 257.5B transactions (FY2025). Total business volume on Stripe in 2025 was $1.9T, about 1.6% of global GDP. Their moat is not “moving money fast” but abstracting complex financial operations (authorization, risk, fees, settlement, refund, dispute, reconciliation, accounting, audit) behind a trust structure.

PayChain이 겨냥하는 곳이 바로 이 지점입니다. Stripe처럼 payment acceptance layer를 다시 만들거나 Circle처럼 stablecoin money layer를 발행하려는 것이 아닙니다. PayChain은 결제 이후의 금융 상태(settlement·proof·auditability·reconciliation·recovery)를 네트워크 레벨에서 다룹니다. Stripe가 payments를 API로 만들었다면, PayChain은 settlement를 금융 네트워크의 기본 구조로 만들고자 합니다.

This is exactly where PayChain aims. It does not rebuild a payment acceptance layer like Stripe or issue a money layer like Circle. PayChain handles the financial state after payment at the network level. If Stripe turned payments into an API, PayChain seeks to make settlement the base structure of a financial network.

3. 블록체인은 트랜잭션을 기록하지만, 금융은 상태를 관리한다

3. Blockchains record transactions; finance manages state

Stablecoin은 돈을 인터넷 네이티브하게 만들었습니다(현재 시장 약 3,125억 달러). 그러나 돈이 더 빨리 움직일수록 결제 이후의 운영 문제는 더 중요해집니다. 하나의 결제는 “성공/실패”로 끝나지 않습니다. 승인·미정산, 배치·미지급, 부분 환불, 분쟁, 수수료 조정, 감사 재구성. 이 모든 것은 단순 event가 아니라 state transition입니다. Transaction hash는 자산 이동의 증거일 수는 있어도, 금융 행위 전체의 설명서는 아닙니다.

Stablecoins made money internet-native (a ~$312.5B market today). But the faster money moves, the more post-payment operations matter. A single payment is not “success/failure.” It can be authorized-not-settled, batched-not-paid, partially refunded, disputed, fee-adjusted, or under audit reconstruction. These are state transitions, not events. A transaction hash can evidence asset movement, but it is not a full description of the financial act.

그래서 PayChain은 “더 많은 트랜잭션을 처리하는 체인”보다 “트랜잭션 이후의 금융 상태를 설명할 수 있는 네트워크”에 가깝습니다. 핵심은 TPS가 아니라 Receipt·Batch·Anchor·Witness 같은 구조입니다.

So PayChain is closer to “a network that can explain financial state after a transaction” than “a chain that processes more transactions.” The core is not TPS but structures like Receipt, Batch, Anchor, and Witness.

4. 결제와 정산 사이의 Missing Layer

4. The Missing Layer between payment and settlement

금융 스택을 다시 보면 빈 계층이 보입니다. Circle은 money layer, Stripe는 payment layer, Visa·Mastercard는 글로벌 네트워크입니다. 그러나 stablecoin 시대에는 결제 이후의 settlement layer가 비어 있습니다. PayChain의 핵심은 “돈이 움직였다”가 아니라 “그 움직임이 신뢰 가능한 금융 상태로 확정되었다”에 있습니다.

Look at the stack again and a layer is empty. Circle is the money layer, Stripe the payment layer, Visa/Mastercard the global networks. But in the stablecoin era the post-payment settlement layer is missing. PayChain's core is not “money moved” but “that movement was confirmed into a trustworthy financial state.”

5. Receipt · Batch · Anchor · Witness는 기능이 아니라 신뢰의 구성 요소다

5. Receipt · Batch · Anchor · Witness are components of trust, not features

Receipt는 금융 행위의 의미를 담는 기본 단위입니다. 같은 100달러 전송도 구매·정산·급여·에스크로 해제·환불일 수 있습니다. Batch는 개별 Receipt를 운영 가능한 정산 단위로 묶습니다. 운영 단위는 곧 책임 단위입니다. Anchor는 민감 데이터를 공개하지 않으면서 특정 시점의 상태가 존재했고 변조되지 않았음을 증명합니다. Witness는 그 증거를 외부 검증 가능성으로 확장합니다.

Receipt is the base unit carrying the meaning of a financial act. The same $100 transfer can be a purchase, settlement, payroll, escrow release, or refund. Batch groups Receipts into an operable settlement unit, and an operating unit is a responsibility unit. Anchor proves a state existed at a point in time and was not altered, without exposing sensitive data. Witness extends that evidence into external verifiability.

이 네 가지가 함께 작동할 때 PayChain은 transaction network를 넘어 settlement network가 됩니다. 이것이 금융기관이 요구하는 auditability·recoverability·reconciliation·operational reliability의 기반입니다.

When these four work together, PayChain moves beyond a transaction network to a settlement network, the basis for the auditability, recoverability, reconciliation, and operational reliability institutions require.

6. Trust before scale: 그리고 코드와 맞는 주장만

6. Trust before scale: and only claims that match the code

신뢰할 수 없는 시스템이 빠르게 확장되면 문제도 빠르게 확장됩니다. PayChain의 안정성은 기술적 안정성(검증된 스택·graceful recovery)과 금융적 안정성(상태 일관성·감사 기록·정산 증빙·환불/분쟁 추적·대사)을 함께 의미합니다. 그리고 그 주장은 슬로건이 아니라 repo에서 도는 게이트로 증명합니다.

If an untrustworthy system scales, its problems scale. PayChain's reliability means technical stability (proven stack, graceful recovery) and financial stability (state consistency, auditable records, settlement evidence, refund/dispute traceability, reconciliation), proven by gates that run in the repo, not by slogans.

Mechanics: 어떻게 동작하는가 (요약)

Mechanics: how it works (summary)

• 결제 의도 → POST /api/receipts (멱등 requestId / Idempotency-Key)
• 결정론 배치 → Batcher → payloadHash · witness
• L1 anchor → anchor 대상 네트워크 설정 (paychain · pci)
• 공개 정체성 → /api/public/chain-head, chain-blocks?witness=1
• 활성화 스냅샷 → /api/public/network-activation-status (외부 RPC 호출 없음)

• Payment intent → POST /api/receipts (idempotent requestId / Idempotency-Key)
• Deterministic batching → Batcher → payloadHash and witness
• L1 anchor → anchor target configuration (paychain, pci)
• Public identity → /api/public/chain-head, chain-blocks?witness=1
• Activation snapshot → /api/public/network-activation-status (no external RPC)

다음: Part 2 — 프로토콜에서 체인으로

Next: Part 2 — From Protocol to Chain

Part 2에서는 왜 transaction hash가 금융 기록으로 충분하지 않은지, 왜 PayChain이 Receipt를 기본 단위로 두는지, 그리고 Settlement State Machine(Authorized→…→Settled/Refunded/Disputed)을 다룹니다.

Part 2 covers why a transaction hash is not enough as a financial record, why PayChain makes the Receipt its base unit, and the Settlement State Machine (Authorized → … → Settled / Refunded / Disputed).

기술 레퍼런스: 개발자 가이드·API 레퍼런스 · 공개 Ledger: network-activation-status

Technical reference: Developer guide & API reference · Public ledger: network-activation-status