Powering 0Gate ramps
How 0Pools sits beneath 0Gate without becoming the public integration surface for most developers.
0Gate is the hosted user-facing ramp. 0Pools is the shared liquidity spine that can sit underneath ramp, checkout, internal execution, and approved partner flows. Most developers integrate 0Gate, not 0Pools.
Relationship
Why this matters
Before a shared pool layer, each ramp product could end up with its own liquidity logic. That creates inconsistent pricing, inconsistent reconciliation, and duplicated capital.
With 0Pools underneath, 0Gate can remain a simple hosted product contract:
| 0Gate developer sees | 0Pools handles behind the product boundary |
|---|---|
| Session, client secret, widget, webhook. | Shared pool quote and liquidity infrastructure. |
| Hosted KYC/payment/ramp state. | Inventory, route, balance, and settlement mechanics. |
gate_session.completed webhook. | Private liquidity settlement path. |
When to stay on 0Gate
Use 0Gate when:
- The user can interact with a hosted widget or redirect.
- 0Bit should own the user-facing ramp journey.
- You want session/webhook integration, not quote/transact infrastructure.
- Your product does not need to own native liquidity UI.
When 0Pools is appropriate
Use 0Pools only after approval when:
- Your product must present its own customer UX.
- You own the compliance/support model.
- You need direct quote/transact/status/balance controls.
- The account has approved pool entitlements.
Example
| Scenario | Product |
|---|---|
| "Let my users buy crypto inside a hosted flow." | 0Gate |
| "Let my approved treasury backend quote and execute EUR/USDT natively." | 0Pools |
| "Let my checkout product accept stablecoin payments." | 0Base, with approved liquidity dependency where applicable |
Developer warning
Do not call 0Pools just because a 0Gate flow uses liquidity behind the scenes. 0Gate sessions and webhooks are the public product contract for hosted ramps.
Before and after ramp infrastructure
| Before shared liquidity | With 0Gate plus 0Pools underneath |
|---|---|
| Each ramp surface can drift into separate rate logic, source logic, and reconciliation. | 0Gate can use a shared liquidity spine while keeping a stable hosted ramp contract. |
| A pricing or settlement change may require updates across multiple product flows. | Liquidity infrastructure can evolve behind the hosted 0Gate session model. |
| Finance joins ramp records and liquidity records manually. | Session, transaction, quote/status, and report ids can be designed to reconcile. |
| Partners are tempted to integrate internal liquidity APIs for hosted use cases. | Most partners stay on 0Gate; approved headless partners use 0Pools deliberately. |
Choosing the right layer
The decision is product-level, not technical curiosity. 0Pools is more powerful because it is headless, but that also means the partner must build the customer journey, status model, support flow, and reconciliation logic correctly.
Integration examples
| Partner goal | Recommended product | Reason |
|---|---|---|
| Add buy crypto to a wallet quickly. | 0Gate | Hosted flow reduces UX, payment, and compliance burden. |
| Co-brand a ramp but keep 0Bit-hosted flow. | 0Gate | Session and widget remain the contract. |
| Build native stablecoin conversion inside a licensed wallet. | 0Pools | Partner owns UX and needs quote/transact/status. |
| Let merchants accept stablecoin payments. | 0Base | Checkout/payment object is the primary product. |
| Investigate route or source internals. | Neither public product | Internal liquidity operations are not partner APIs. |
What a 0Gate developer should know about 0Pools
0Gate developers do not need to call 0Pools. They should understand that 0Pools is part of why 0Bit can centralize liquidity, quote behavior, and reconciliation across products. The public integration work remains:
- create a 0Gate session server-side
- mount the widget or redirect
- process signed webhooks
- reconcile the partner order against 0Gate transaction status
That keeps most ramp integrations simpler while still letting 0Bit improve the liquidity network underneath.
Use 0Gate or 0Pools
Most developers should start with 0Gate when they want a hosted ramp experience. 0Pools is for approved partners that need to own the product surface and backend lifecycle.
| Requirement | Prefer 0Gate | Prefer 0Pools |
|---|---|---|
| Hosted UX | Yes. | No. |
| Minimal backend work | Yes. | No. |
| Native wallet/neobank UI | No. | Yes. |
| Own quote acceptance UX | No. | Yes. |
| Own ledger and reconciliation | Maybe limited. | Yes. |
| Server-side execution and webhooks | Abstracted. | Required. |
Migration path
0Gate developer note
A 0Gate integration should not need to model 0Pools internals. It should understand that quotes, settlement, and reconciliation are backed by pool infrastructure, but the public integration surface remains 0Gate unless the partner is approved for 0Pools.
Implementation depth
This page is about explaining how 0Pools supports 0Gate without replacing it. For developers, the durable boundary is simple: your product should depend on the product boundary between hosted 0Gate flows and headless 0Pools flows; it should not depend on the internal routing and liquidity path 0Gate may use behind its own contract. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.
Product scenario
A fintech wants crypto buy/sell in its app. If it can use hosted KYC and checkout screens, it integrates 0Gate. If it must own the whole UX and compliance model, it may be approved for 0Pools.
Before and after in practice
| Before 0Pools | With 0Pools |
|---|---|
| Teams jump directly to liquidity APIs and accidentally rebuild hosted ramp responsibilities. | Teams choose the product layer that matches UX, compliance, and operational responsibility. |
| Product teams infer liquidity behavior from provider-specific screens or manual notes. | Product teams branch on 0Pools objects: pool, quote, trade, balance, webhook, and ledger. |
| Support asks engineering to reconstruct state from logs. | Support starts from request id, quote id, trade id, event id, and ledger id. |
System flow
Records to keep
| Record | Why it matters | Example |
|---|---|---|
product_layer | Which surface the partner uses. | 0Gate |
ux_model | Hosted or native. | hosted |
compliance_model | Who owns customer flow. | 0Bit-hosted |
fallback_layer | When to consider 0Pools. | native headless |
A useful implementation stores these records before adding optional analytics. Analytics can be rebuilt from durable state; missing ids usually cannot be reconstructed after a customer-impacting failure.
Example product record
{
"product_area": "powering-0gate-ramps",
"partner_reference": "partner_order_123",
"pool_id": "EUR-USDT",
"quote_id": "pq_test_123",
"transact_id": "pt_test_456",
"status": "reserved",
"request_id": "req_01HZY0POOLS",
"reconciliation_state": "open"
}This record is intentionally partner-facing. It references 0Pools objects and your own product ids, but it does not include private liquidity routes, treasury balances, raw provider payloads, or customer secrets.
Failure modes and recovery
| Failure mode | Product response |
|---|---|
| Using 0Pools for simple embed | Use 0Gate to avoid owning unnecessary complexity. |
| Using 0Gate but expecting raw liquidity control | Use product-level controls and sessions. |
| Mixed ledger logic | Keep each product contract separate. |
| Wrong support playbook | Route issues to the product layer that created the state. |
Use-case patterns
| Pattern | How 0Pools helps |
|---|---|
| Hosted ramp | 0Gate is the default. |
| Native regulated app | 0Pools may fit after approval. |
| Migration planning | Move from hosted to headless only when operationally ready. |
Developer checklist
- Read runtime discovery and capabilities before rendering enabled actions.
- Create firm quotes only when the user is ready to accept the terms.
- Execute from your server with an idempotency key.
- Treat webhooks and status reads as the source of truth for settlement state.
- Reconcile by durable ids first, then by amount and timestamp.
- Do not branch product behavior on provider names, route names, reserve balances, or treasury assumptions.