Skip to main contentOpenGDP operationalizes stablecoin flows for real-world settlement: payouts, collections, merchant flows, and treasury movement. It is designed for predictable execution and operational semantics institutions expect, so teams can run volume in production.
At scale, payments are inseparable from conversion, liquidity, and execution. OpenGDP includes exchange-grade liquidity and execution primitives inside payment workflows, so pricing, routing, and conversion are first-class parts of the flow, not glue code.
Native Payment Infrastructure
Payments on OpenGDP support operational patterns that map to real finance operations:
- Payouts and collections: high-volume settlement with predictable outcomes
- Merchant flows: settlement semantics designed for platforms and PSPs
- Treasury movement: sweeps, pooling, and rebalancing across accounts
- Remittance and metadata: invoice IDs, payout references, ledger codes, and reconciliation tags
- Batching: bundle high-volume operations for efficiency and predictable processing
When flows cross currencies or corridors, payments invoke built-in liquidity and execution for conversion and routing.
Liquidity
OpenGDP integrates liquidity and execution primitives into the chain for performance, verifiability, and composability across payment workflows. When flows cross currencies and corridors, settlement requires conversion, pricing, routing, and liquidity sourcing.
Execution model
OpenGDP supports an orderbook-style execution model, similar to traditional markets, to provide executable pricing and verifiable settlement behavior.
Why it matters
- High performance: native integration bypasses contract overhead for fast placement, cancellation, and matching
- Executable pricing: visible depth and deterministic matching semantics enable prices that can be executed, not just observed
- Execution modes: common order semantics such as Limit and Market, plus advanced types like FOK and IOC for workflow control
- Standardized interfaces: endpoints and libraries designed for integration with institutional systems and automated liquidity providers
Assets and pairs
Liquidity and execution are defined over asset pairs (base and quote). Pairs can represent:
- Stablecoin conversions (for example USD/EUR)
- Corridor rails and settlement assets used in cross-border flows
- Tokenized instruments that require pricing or conversion as part of settlement
Tokenized assets, including RWAs, can be priced and converted when needed for settlement workflows without treating this as a separate trading venue.
Access methods
Liquidity and execution primitives are accessible from both user-facing applications and programmatic systems:
- Application access: workflows can be surfaced through dedicated applications that handle wallet management and transaction signing with a streamlined user experience
- Programmatic access: composable within the EVM so contracts can invoke pricing, routing, and conversion directly; APIs can also be exposed via the SDK for offchain systems to execute conversions and integrate settlement workflows
Example workflow
Payments can request quotes, source liquidity, and execute conversion as part of a single workflow while preserving deterministic settlement outcomes. The result is a payment rail that behaves like infrastructure institutions can run, not a generic transaction network.