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`