proxmox/docs/03-deployment/PROVIDER_FACING_PACKAGE_SOURCE_TO_CEX.md

Provider-Facing Package: Source To CEX / OTC Execution

Last Updated: 2026-04-17
Purpose: Strict provider-facing package for Crypto.com OTC, a DCE, or another institutional execution venue. This is written as an onboarding and commercial brief, not an internal architecture memo.

1. Executive Summary

We operate a structured digital-asset corridor with:

• a promoted immediate bucket of Mainnet cWUSDC / cWUSDT
• a much larger same-day corridor feeder set built around Chain 138 cUSDC, cUSDT, and stable LP unwind paths
• a deployer wallet funding posture that should maintain both Mainnet cWUSDC and cWUSDT
• a preferred settlement target of USDC
• a preferred operating model of:

Chain 138 inventory -> canonical bridge -> Mainnet normalization -> provider handoff

The current repo-modeled operator state shows:

• immediate bucket: about $17.78M
• same-day corridor bucket: about $1.381B
• strongest verified direct public normalization sink: about $213.10 via cWUSDC -> USDC
• direct cWUSDT -> USDT path: about $2.18

The practical implication is that we are not seeking a provider to discover our flow. We are seeking a provider to absorb clean normalized settlement flow at institutional scale after bridge and Mainnet normalization.

Funding Posture

The deployer wallet should maintain both:

• cWUSDC for the primary Mainnet USDC normalization rail
• cWUSDT for cUSDT landing, fallback handling, and support-rail normalization into cWUSDC

This means the provider-facing package should describe the Mainnet wrapped funding posture as dual-rail, even though the preferred final settlement asset remains USDC.

2. What We Expect From The Provider

Category	Expectation
Onboarding	Clear KYB / KYC / entity onboarding path
Settlement rail	Accepted deposit assets, chains, address rules, memo/tag rules if any
Execution model	Clear distinction between OTC RFQ, streamed quotes, exchange-book routing, or hybrid handling
Size guidance	Minimum clip, normal clip, escalation threshold, and preferred block workflow
Operational support	Named contacts, escalation path, failed deposit handling, reconciliation contact
Commercial clarity	Clear fee / spread framework and expected relationship model
Reliability	Stable intake process for repeatable USDC-oriented flow

3. What The Provider Should Expect From Us

Category	Commitment
Flow shape	Clean, normalized settlement-oriented flow, primarily USDC
Route discipline	We do not treat public on-chain pools as the final absorber of institutional size
Operational clarity	One default operating path, one packetization policy, one settlement preference
Funding posture	The deployer wallet maintains both cWUSDC and cWUSDT for Mainnet funding and normalization support
Treasury control	Clear control over feeder wallets and corridor assets
Source narrative	Source-of-funds and wallet-control narrative available for onboarding
Escalation discipline	Named operators and reproducible reconciliation process
Volume ramp	Small canaries first, then repeatable production clips, then larger negotiated size

4. Current Flow Presentation

Preferred Flow

Source Asset	Path To Provider
cUSDC	cUSDC -> bridge -> cWUSDC -> USDC -> provider
cUSDT	cUSDT -> bridge -> cWUSDT -> cWUSDC -> USDC -> provider
LP:cUSDT/cUSDC	withdraw -> cUSDT/cUSDC -> bridge -> normalize -> USDC -> provider
cWUSDC	cWUSDC -> USDC -> provider
cWUSDT	cWUSDT -> cWUSDC -> USDC -> provider

Mainnet Funding Requirement

The deployer wallet should be treated as funded across both Mainnet wrapped settlement rails:

• cWUSDC
• cWUSDT

This is not a contradiction of the USDC-first settlement policy. It is the funding requirement that keeps both the primary normalization rail and the cUSDT support rail operational.

Default Settlement Preference

1. USDC
2. USDT only if the provider explicitly prefers it and the route is operationally superior

Current Constraint

Without a provider, the system remains terminally concentrated on a shallow public sink. With a provider, the on-chain Mainnet leg becomes a bounded normalization handshake, not the final execution destination.

5. How We Present Volume

We should present volume in terms of repeatable flow bands, not only maximum theoretical inventory.

Recommended Provider-Facing Framing

Layer	How To Describe It
Immediate inventory	Mainnet normalized-or-near-normalized stable-adjacent assets available for rapid handoff
Same-day corridor inventory	Chain 138 feeder assets that can be bridged and normalized into USDC within the same operational day
Execution target	Repeatable institutional settlement flow rather than one-off retail-sized swaps
Growth profile	Initial controlled packets, then increasing clip size after successful canaries and reconciliation

What Not To Do

• Do not lead with nominal long-tail balances that do not yet have promoted terminal exits
• Do not imply that public DEX depth is the true execution capacity
• Do not promise production volume before the provider rail is fully enabled

6. How We Drive Traffic / Volume

Stage	Objective	Provider Narrative
Stage 1	Prove clean onboarding and settlement	“We can deliver clean USDC packets with low operational friction.”
Stage 2	Prove repeatable canaries	“We can repeat successful flows with consistent routing and reconciliation.”
Stage 3	Increase packet size	“We can move from small clips into desk-appropriate institutional blocks.”
Stage 4	Increase cadence	“We can supply repeatable same-day flow, not one-off opportunistic transactions.”
Stage 5	Expand provider trust	“We can route more of the corridor inventory into the provider because the process is stable.”

Traffic-Driving Rules

1. Standardize flow into one settlement asset.
2. Use predictable packet sizes.
3. Keep reconciliation clean.
4. Minimize failed deposits and exception handling.
5. Start with canaries and graduate by evidence.
6. Expand cadence before claiming unlimited size.

7. First 30-Day Volume Ramp Plan

Days 1–7: Onboarding + Zero-Error Setup

• complete provider onboarding
• confirm accepted asset, chain, and deposit instructions
• validate operator contacts and exception path
• confirm packet policy internally

Days 8–14: Canary Execution

• send smallest operationally meaningful packets
• verify:
  • normalization correctness
  • provider receipt
  • reconciliation speed
  • operator handoff discipline

Days 15–21: Controlled Repetition

• repeat successful clips
• keep the same asset and route shape
• avoid unnecessary route experimentation

Days 22–30: Graduated Ramp

• widen packet sizes only after zero-error repetition
• establish an initial weekly or daily cadence
• document observed provider preferences and execution quality

8. Provider Questions We Should Be Ready To Answer

Question	Prepared Answer Shape
What asset will you settle in?	Primarily USDC
What chain will you deliver on?	Ethereum Mainnet unless another provider-accepted route is cleaner
What is your feeder system?	Chain 138 cUSDC, cUSDT, and stable LP unwind paths, with Mainnet cW* immediate assets
What funding assets do you maintain on Mainnet?	Both cWUSDC and cWUSDT, with USDC as the preferred final settlement target
Why not execute fully on-chain?	Public normalization pools are shallow; we use on-chain only for bounded preparation before institutional execution
What size do you expect?	Start with controlled packets, then graduate based on successful settlement and reconciliation
How do you control source assets?	Treasury-controlled wallets and documented corridor model
How do you manage risk?	Bounded normalization usage, packet limits, settlement preference, and operator-controlled promotion gates

9. What We Should Ask The Provider Directly

1. Which deposit assets do you prefer for repeat institutional flow?
2. Which chain(s) are best operationally for your settlement workflow?
3. At what clip sizes do you prefer OTC desk handling versus exchange-book handling?
4. What packet cadence do you prefer from a new flow source?
5. What is your escalation process for failed or delayed deposits?
6. Do you support pre-negotiated RFQ / desk routing for normalized USDC flow?
7. What reconciliation data will you provide back to our operators?

10. Strict Bottom Line

The correct provider-facing story is not:

we have many assets and many routes

It is:

we control a large same-day corridor feeder system, we normalize into clean settlement assets, and we want a reliable institutional execution partner for repeatable flow