Paycrest

• Name: Paycrest
• URL: https://paycrest.io/
• Category: stablecoin-fiat routing stack / Gateway-escrow and provider-routing architecture
• Tags: ethereum-ecosystem
• Summary: Paycrest is still worth keeping as a product note because the Gateway-contract escrow flow, sender/provider API split, public rate and market endpoints, and provision-node architecture are specific enough to analyze on their own. The broader operator boundary around the sole aggregator, KYB/KYB-gated access, dashboard-issued credentials, and webhook/order-state truth now lives in paycrest.
• What it does:
  • Lets sender applications create offramp and onramp orders through a Sender API or directly through Gateway smart contracts
  • Routes orders to liquidity providers that run their own provision nodes, set their own rates, and connect their own local PSP accounts
  • Uses onchain escrow so stablecoins are locked until local-fiat delivery is confirmed or automatically refunded if fulfillment fails
  • Supports both stablecoin → fiat and fiat → stablecoin flows through the same order-creation surface, with public quote endpoints, account verification, and status tracking
  • Exposes provider-facing operational docs for self-hosted Docker deployments, PSP credential wiring, provision-node reporting, and alternative hosted node setup through Blockops
  • Publishes first-party docs covering architecture, participants, transaction lifecycle, supported currencies and tokens, contract addresses, and OpenAPI specs
  • Targets wallets, fintechs, exchanges, DeFi protocols, payroll flows, treasury operations, and cross-border payment products rather than end-user consumer-only flows
• Key claims:
  • The docs introduction calls Paycrest a decentralized payment routing protocol for stablecoin-fiat payments in emerging markets and says orders complete with onchain escrow without Paycrest custodying user funds
  • The site and docs both describe the core architecture as Gateway smart contracts, an aggregator coordination layer, and provider-run settlement tools or provision nodes tied to local PSP rails
  • The quickstart shows both offramp and onramp creation through POST /v2/sender/orders, which is strong evidence that Paycrest exposes a real bidirectional integration surface rather than only marketing copy
  • The llms.txt indexes a substantial first-party docs surface spanning authentication, rates, supported currencies and tokens, sender and provider order endpoints, architecture, compliance, participant roles, provider setup, smart-contract interaction, and OpenAPI artifacts
  • The provider setup guide shows providers can self-host Dockerized provision nodes, use Paycrest-issued aggregator credentials plus PSP-issued credentials, and optionally use Blockops for low-touch hosting
  • The decentralization-path section says the protocol is currently federated around a single Paycrest-run aggregator and frames future decentralization as a staged roadmap rather than something already achieved, which is why the separate company note matters
• Whitepaper: No canonical standalone Paycrest whitepaper or litepaper surfaced in this pass. The clearest current source of truth is the official docs corpus, llms.txt, API/OpenAPI materials, and the main site; see ../whitepapers/paycrest-primary-sources-2026-04-30.md and the newer company-layer companion capture in ../whitepapers/paycrest-company-primary-sources-2026-08-09.md.
• Sources:
  • https://paycrest.io/
  • https://docs.paycrest.io/
  • https://docs.paycrest.io/llms.txt
  • https://docs.paycrest.io/introduction.md
  • https://docs.paycrest.io/quickstart.md
  • https://docs.paycrest.io/implementation-guides/provider-setup-guide.md
  • https://docs.paycrest.io/concepts/architecture.md
  • https://docs.paycrest.io/openapi-v2.yaml

Internal linkages

• Company / operator boundary: paycrest.
• Best upward product reads: bridge-xyz and coinflow where the sharper comparison is hosted payout orchestration, merchant admission, and webhook-backed settlement truth rather than a preserved project alias.

Protocol / company boundary

• Keep this note on the product and architecture surface: Gateway escrow, sender and provider APIs, public market and quote endpoints, provision-node workflow, and the transaction lifecycle between sender, aggregator, and provider.
• Use paycrest for the named-operator layer around the sole aggregator, API access, KYB/KYB gating, dashboard-issued credentials, webhook and order-state publication, fee capture, and the broader legal shell around Paycrest Protocol and Noblocks.
• That split matters because how does the routing stack work? and who currently controls the live coordination and admission surface? are related but not identical questions.

Control surface

• At the product layer, authority sits in the Gateway order model, aggregator-mediated route selection, provision-node expectations, quote exposure, timeout and refund behavior, and the public API and smart-contract integration shape developers actually build against.

• The escrow contracts narrow one risk, but they do not remove the current dependency on the aggregator-mediated workflow. For the stronger operator and legal boundary around that workflow, read paycrest.

• Read Paycrest as a routing architecture with a still-important company-run coordination shell, not as a settled decentralization endpoint.

• Last reviewed: 2026-08-09 UTC