EVM을 통한 확장

Expanding Through EVM

EVM은 정체성이 아니라 배포 경로다

EVM is distribution, not identity

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

카테고리: EVM은 PayChain의 정체성이 아닙니다. 정체성은 settlement이고, EVM은 그것을 개발자·유동성에 연결하는 distribution layer입니다. 목표는 EVM 호환이 아니라 settlement programmability입니다.

Category: EVM is not PayChain's identity. The identity is settlement; EVM is the distribution layer connecting it to developers and liquidity. The goal is settlement programmability, not EVM compatibility.

1. 좋은 네트워크와 좋은 생태계는 다르다

1. A good network and a good ecosystem are different

네트워크는 안정적·빠름·저렴·안전할 수 있지만, 생태계는 개발자·앱·유동성·도구가 모일 때 만들어집니다. PayChain의 정산 구조가 내부 기능으로만 존재하면 시장은 반응하지 않습니다. 개발자가 쓸 수 있어야 하고, 지갑·SDK·API·dashboard·indexer·webhook·MCP 인터페이스로 제품 경험에 드러나야 합니다. 일반 Web3 결제 앱은 온체인 transaction과 오프체인 운영 DB를 따로 관리합니다. PayChain은 이 복잡성을 네트워크 레벨에서 줄여야 합니다.

A network can be stable, fast, cheap, secure. But an ecosystem forms when developers, apps, liquidity, and tools gather. If PayChain's settlement structure exists only as internal features, the market does not respond. It must surface as product through wallets, SDKs, APIs, dashboards, indexers, webhooks, and MCP interfaces. A typical Web3 payment app manages onchain transactions and an off-chain operating DB separately. PayChain must reduce that complexity at the network level.

2. EVM은 개발자 시장이다

2. EVM is a developer market

“EVM compatible”은 차별점이 아니라 기본 조건입니다. EVM은 adoption cost를 낮춥니다(지갑·SDK·라이브러리·explorer·custody·stablecoin 유동성). 그러나 PayChain은 범용 dApp 체인이 아닙니다. 금융 상태가 중요한 시장(가맹점 결제·B2B payout·escrow·treasury·API/agent 결제·대사)을 겨냥합니다. 일반 EVM 체인은 “무엇이든 만들 수 있는 환경”을, PayChain은 “금융 상태를 가진 애플리케이션을 만들 수 있는 환경”을 제공합니다.

“EVM compatible” is a baseline, not a differentiator. EVM lowers adoption cost (wallets, SDKs, libraries, explorers, custody, stablecoin liquidity). But PayChain is not a general dApp chain. It targets markets where financial state matters (merchant payment, B2B payout, escrow, treasury, API/agent payment, reconciliation). A general EVM chain offers “an environment to build anything”; PayChain offers “an environment to build applications with financial state.”

3. OP Stack과 모듈형 확장 전략

3. OP Stack and a modular expansion strategy

EVM 확장은 모든 것을 Ethereum mainnet에서 처리한다는 뜻이 아닙니다. OP Stack 같은 모듈형 흐름은 표준·유동성·보안·tooling을 재사용하며 목적별 execution environment를 만듭니다. 다만 PayChain의 핵심 메시지가 “우리는 또 다른 L2다”가 되어서는 안 됩니다. 핵심은 L2가 아니라 settlement layer이고, EVM·L2 스택은 그 레이어를 쉽게 배포·연결하는 방법입니다.

EVM expansion does not mean processing everything on Ethereum mainnet. Modular flows like OP Stack reuse standards, liquidity, security, and tooling to build purpose-specific execution environments. But PayChain's core message must not become “we are just another L2.” The core is a settlement layer, and EVM/L2 stacks are ways to deploy and connect that layer.

4. Developer First와 Settlement Programmability

4. Developer First and Settlement Programmability

소프트웨어 시대의 금융 네트워크는 개발자가 확장합니다(Stripe·Twilio·AWS가 인프라를 API로 만든 것처럼). 개발자는 RPC endpoint가 아니라 명확한 API·SDK·indexer·dashboard·webhook·MCP 인터페이스를 기대합니다. Settlement programmability는 결제·정산·환불·분쟁·증빙·감사를 프로그래머블 객체와 상태로 다루는 것입니다. 결제가 token-transfer event가 아니라 Receipt로 구조화되고 상태머신을 따라 이동합니다. 이것이 Stripe식 추상화를 정산에 적용한 것입니다.

Financial networks in the software era grow via developers (as Stripe, Twilio, and AWS turned infrastructure into APIs). Developers expect clear APIs, SDKs, indexers, dashboards, webhooks, and MCP interfaces, not just an RPC endpoint. Settlement programmability means handling payment, settlement, refund, dispute, evidence, and audit as programmable objects and states. Payment becomes a Receipt that moves along the state machine, not a token-transfer event. This is Stripe-style abstraction applied to settlement.

5. TVL보다 Execution Volume

5. Execution Volume over TVL

PayChain은 자산을 오래 묶어두는 네트워크가 아니라, 자산이 금융적으로 의미 있게 이동·정산·실행되도록 만드는 네트워크입니다. 핵심 지표는 TVL보다 Execution Volume입니다. 몇 개의 Receipt가 생성·정산되었는가, 얼마의 payout·escrow·API/agent 실행이 발생했는가입니다. Stablecoin abstraction은 결제 자산과 정산 자산을 분리하되 금융 사건의 맥락을 유지합니다(settlement-aware liquidity routing). 이때 PCI는 결제 토큰이 아니라 settlement coordination·liquidity bond·execution fuel로 이동합니다.

PayChain is not a network for locking assets long-term but for making assets move, settle, and execute meaningfully. The core metric is Execution Volume over TVL. How many Receipts created/settled, how much payout, escrow, and API/agent execution occurred. Stablecoin abstraction separates pay-asset from settle-asset while preserving the financial event's context (settlement-aware liquidity routing). Here PCI moves from a payment token to settlement coordination, liquidity bond, and execution fuel.

Limits

OP Stack 기반 L2가 동작하며, 풀 운영 구성은 진화 중입니다.
PayChain은 범용 dApp 체인이 아니며 포지셔닝은 정산에 특화됩니다.
SDK/MCP 표면은 진화 중입니다. 추상 메서드명은 예시입니다.

The OP Stack-based L2 is operational; the full production configuration is evolving.
PayChain is not a general dApp chain; positioning stays settlement-specific.
SDK/MCP surfaces evolve. Abstracted method names are illustrative.

Risks

“또 다른 L2”: 차별점을 지우는 약한 포지셔닝.
인프라=정체성 혼동: 체인 스택 선택을 제품 정체성으로 착각.
TVL 연출: 실행을 가능하게 하는 대신 자산만 묶어둠.

“Just another L2”: weak positioning that erases differentiation.
Infra-as-identity: confusing chain stack choice with product identity.
TVL theater: locking assets instead of enabling execution.

다음: Part 5 — 금융 실행의 미래

Next: Part 5 — The Future of Financial Execution

정산 가능한 네트워크 위에서 무엇이 가능해질까요? Part 5는 PayFi, Financial API Layer로서의 PX402, agentic finance, escrow+evaluator, 그리고 PCI coordination/bond 경제를 다룹니다.

What becomes possible on a settle-able network? Part 5 covers PayFi, PX402 as a Financial API Layer, agentic finance, escrow + evaluator, and the PCI coordination/bond economy.