proxmox/docs/03-deployment/MAINNET_CWUSD_HYBRID_FLASH_LOOP_CALCULATION_WHITEPAPER.md

Mainnet cWUSD Hybrid Flash Loop Calculation White Paper

Date: April 5, 2026

Purpose

This paper formalizes the hybrid loop methodology for Mainnet public cWUSD*/USD* PMM pools:

1. Permanently add owned cW* inventory to deepen the pool's base reserve.
2. Borrow USD* via a flash lender.
3. Push the flash-borrowed USD* through the PMM.
4. Monetize the acquired cW* externally.
5. Repay the flash loan.
6. Leave only retained USD* in place as durable quote-side liquidity.

This is the exact strategy modeled in pmm-flash-push-break-even.mjs.

Why This Structure

Public Mainnet cWUSD*/USD* pools are live but still shallow. A pure flash-backed quote push can increase quote depth, but it also depletes base depth. A pure owned-base top-up can deepen base depth, but by itself it can skew the peg base-heavy.

The hybrid loop solves that by combining:

• durable cW* inventory from the wallet
• temporary USD* working capital from a flash loan
• external unwind proceeds to cover flash repayment
• retained USD* as permanent quote-side depth

Current Live Inputs

Live Mainnet Pool

Pool: cWUSDC / USDC

• Pool address: 0x69776fc607e9edA8042e320e7e43f54d06c68f0E
• Base reserve B0: 4,854,615 raw = 4.854615 cWUSDC
• Quote reserve Q0: 4,854,873 raw = 4.854873 USDC
• Mid price: 1.000053145306064435

These were read live from Mainnet on April 5, 2026.

Wallet Inventory

Wallet: 0x4A666F96fC8764181194447A7dFdb7d471b301C8

• cWUSDC: 8,888,889.376281
• USDC: 0.032904

Flash Lender Snapshot

Lender: Aave V3 Mainnet pool 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2

• Flash fee: 5 bps
• Observed USDC token balance at the pool address: 15.896459 USDC

Note:

• The tool also supports manual caps and other lenders.
• The token balanceOf(pool) read is a live inventory snapshot, not a canonical flash-cap guarantee. Production use should query the lender's own flash eligibility and reserve semantics immediately before execution.
• For loop feasibility, the Mainnet PMM depth is still the dominant bottleneck, not lender capacity.

Real-Time Gas Snapshot

Observed on Mainnet:

• Latest block: 24,818,028
• Block timestamp: 2026-04-05 20:45:35 America/Los_Angeles
• Base fee: 86,974,561 wei
• Gas price: 87,135,868 wei
• Gas price in gwei: 0.087135868

For the worked example below, reserve gas is computed using:

• 3 follow-up transactions
• 250,000 gas each
• native token price assumption: 3,200 USDC / ETH

This gives:

• reserved gas: 0.000065351901 ETH
• gas reserve in quote terms: 0.2091260832 USDC

Variable Definitions

• B0: starting base reserve in raw token units
• Q0: starting quote reserve in raw token units
• dB_owned: owned base permanently added to the pool before the flash loop
• B1 = B0 + dB_owned
• x: flash-borrowed quote amount
• f_lp: PMM LP fee in decimal form
• f_flash: flash fee in decimal form
• f_exit: external exit fee in decimal form
• P_exit: effective external quote-per-base monetization price
• G_quote: quote-equivalent gas reserve
• F_quote: minimum retained quote floor after gas
• P_oracle: target quote-per-base peg reference

Core Formulas

1. Effective Starting Pool

B1 = B0 + dB_owned
Q1 = Q0

2. Net Quote Sent Into PMM

q_net = x * (1 - f_lp)

3. PMM Quote-In, Base-Out Leg

base_out = q_net * B1 / (Q1 + q_net)

This is the same reserve-based quote-in branch used in the PMM calculator.

Model caveat:

• This paper follows the exact reserve-model branch used by the local calculator and is suitable only insofar as it matches the deployed pool implementation and query functions.
• Before scaling any tranche, validate the modeled base_out and post-trade state against the live pool's own read/query path or a fork simulation.

4. External Monetization of Acquired Base

quote_proceeds = base_out * P_exit * (1 - f_exit)

5. Flash Repayment

flash_repay = x * (1 + f_flash)

6. Retained Quote

retained_before_gas = quote_proceeds - flash_repay
retained_after_gas  = retained_before_gas - G_quote

7. Source Pool End State

B_end = B1 - base_out
Q_end = Q1 + q_net

8. Marginal Price and Peg Deviation

For the current PMM reserve model, a practical marginal price approximation is:

P_post = Q_end / B_end
dev_bps = (P_post / P_oracle - 1) * 10,000

Where P_oracle = 1 for cWUSDC / USDC.

9. Pass Conditions

The tranche is executable only if all conditions pass:

quote_proceeds >= flash_repay
retained_after_gas >= F_quote
abs(dev_bps) <= max_post_trade_deviation_bps

10. Minimum Required External Exit Price

For a tranche to clear repayment, gas, and retained floor, the effective exit price must satisfy:

P_exit_required =
  (flash_repay + G_quote + F_quote) / (base_out * (1 - f_exit))

This turns the external unwind from a guess into a live gating check.

11. Target-Post-Peg Sizing

Instead of always pushing to the deviation limit, solve for a desired post-trade price:

P_target = Q_end / B_end

With the current reserve model:

Q_end = Q1 + q_net
B_end = B1 - (q_net * B1 / (Q1 + q_net))

For a chosen P_target, solve numerically for q_net, then recover the flash borrow:

x = q_net / (1 - f_lp)

This is the preferred production method because it sizes to a peg target rather than to an arbitrary flash amount.

Worked Live Example

Strategy

Hybrid quote-push on Mainnet cWUSDC / USDC:

• owned base add: 1.000000 cWUSDC
• flash borrow: 0.600000 USDC
• LP fee: 3 bps
• flash fee: 5 bps
• external exit price: 1.12
• gas price: live 0.087135868 gwei
• gas reserve: 3 x 250,000 gas
• retained floor: 0.050000 USDC
• max post-trade deviation: 500 bps

Calculation Results

Inputs

• B0 = 4.854615
• Q0 = 4.854873
• dB_owned = 1.000000
• x = 0.600000

PMM leg

• effective source base reserve: 5.854615 cWUSDC
• net quote into PMM: 0.599820 USDC
• base out: 0.643797 cWUSDC
• PMM VWAP: 0.931971 USDC / cWUSDC

External unwind

• external proceeds: 0.721053 USDC

Flash repay

• flash fee amount: 0.000300 USDC
• flash repay: 0.600300 USDC

Retained quote

• retained before gas: 0.120753 USDC
• gas reserve: 0.2091260832 USDC
• retained after gas, exact arithmetic expectation:

0.721052676955
-0.600300000000
-0.209126083200
= -0.088373406245 USDC

• corrected retained after gas: -0.088373 USDC

End state

• source pool end B: 5.210818 cWUSDC
• source pool end Q: 5.454693 USDC
• post-trade marginal price: 1.046802
• deviation: 468.016796 bps

Interpretation

Under the corrected gas arithmetic above, this tranche does not pass:

• repay: pass
• retained floor: fail
• deviation cap: pass

It is therefore not a valid canary under the stated live gas conversion.

This correction matters operationally: a gas-unit mismatch is enough to flip a tranche from pass to fail.

Using the minimum required external exit price formula with:

• flash_repay = 0.600300
• G_quote = 0.2091260832
• F_quote = 0.050000
• base_out = 0.643797032995

the tranche would require approximately:

P_exit_required ≈ 1.3349332773 USDC per cWUSDC

So the previously assumed P_exit = 1.12 is not sufficient for this canary under the corrected gas treatment.

Fresh Tranche Ladder Under Corrected Gas and a Size-Aware Exit Curve

Because the flat 1.12 exit assumption is not sufficient, the right next step is a scenario ladder using:

• corrected gas accounting
• peg-neutral targeting (P_post = 1.0)
• a size-aware effective exit curve instead of a flat scalar

Scenario Curve

For this recomputation, the effective external unwind price is modeled as:

P_exit(base_out) = max(1.18, 1.42 - 0.06 * base_out)

Where base_out is measured in whole cWUSDC.

This is not a claim about a specific venue. It is an explicit scenario curve chosen to be:

• materially stronger than the failed flat 1.12
• more realistic than assuming one constant premium regardless of size
• conservative enough to decay with tranche size

In production, replace this with live size-aware quotes from the actual unwind venue.

Ladder Construction Method

For each loop:

1. Start from the previous loop's end reserves.
2. Choose the minimum dB_owned that allows a peg-neutral tranche to satisfy:
   • corrected gas reserve
   • flash repayment
   • retained-after-gas floor F_quote = 0.05 USDC
3. Solve for x such that P_post = 1.0.
4. Compute base_out, retained_after_gas, and the next reserve state.

This is a base-efficient ladder, not a “maximize retained quote” ladder.

Corrected 10-Loop Peg-Neutral Ladder

loop	dB_owned (cWUSDC)	x_flash (USDC)	base_out (cWUSDC)	net base added (cWUSDC)	q_net into pool (USDC)	P_exit_eff	retained_after_gas (USDC)	cum_retained (USDC)	B_end	Q_end	dev_bps
1	1.050000	0.499355	0.550537	0.499463	0.499205	1.386968	0.054845	0.054845	5.354078	5.354078	0.000
2	1.100000	0.524484	0.575674	0.524326	0.524326	1.385460	0.063701	0.118546	5.878405	5.878405	0.000
3	1.100000	0.526586	0.573572	0.526428	0.526428	1.385586	0.058757	0.177303	6.404833	6.404833	0.000
4	1.100000	0.528377	0.571782	0.528218	0.528218	1.385693	0.054547	0.231850	6.933052	6.933052	0.000
5	1.100000	0.529919	0.570240	0.529760	0.529760	1.385786	0.050920	0.282769	7.462812	7.462812	0.000
6	1.150000	0.554573	0.595593	0.554407	0.554407	1.384264	0.060482	0.343251	8.017219	8.017219	0.000
7	1.150000	0.555905	0.594261	0.555739	0.555739	1.384344	0.057353	0.400604	8.572957	8.572957	0.000
8	1.150000	0.557078	0.593089	0.556911	0.556911	1.384415	0.054598	0.455202	9.129868	9.129868	0.000
9	1.150000	0.558118	0.592049	0.557951	0.557951	1.384477	0.052155	0.507357	9.687819	9.687819	0.000
10	1.200000	0.582663	0.617511	0.582489	0.582489	1.382949	0.061906	0.569263	10.270308	10.270308	0.000

Totals Under This Scenario

• Total owned base added: 11.25 cWUSDC
• Total flash quote borrowed across all loops: 5.417058 USDC
• Total base returned by PMM-to-wallet across all loops: 5.834308 cWUSDC
• Net base permanently committed to the pool: 5.415692 cWUSDC
• Cumulative retained quote after gas: 0.569263 USDC
• Pool reserves grow from about 4.85 / 4.85 to about 10.27 / 10.27

Inventory-Capped Recompute Using Current Wallet Balances

Using the refreshed live wallet balances:

• cWUSDC = 8,888,889.376281
• USDC = 0.032904
• ETH = 0.000177340398672728

and keeping the same gas policy:

• 3 follow-up transactions per loop
• 250,000 gas each
• live gas price 0.087135868 gwei

the per-loop gas reserve remains:

• 0.000065351901 ETH
• 0.2091260832 USDC equivalent

Binding Inventory Cap

Under these refreshed balances:

• cWUSDC is not the binding inventory constraint for the 10-loop scenario ladder
• Mainnet ETH for gas is the first hard cap

Maximum loops supportable by current ETH under this policy:

0.000177340398672728 / 0.000065351901 ≈ 2.71

So only 2 full loops are supportable without topping up ETH.

Wallet-Capped Ladder

loop	dB_owned (cWUSDC)	x_flash (USDC)	net base added (cWUSDC)	retained_after_gas (USDC)	cumulative retained (USDC)	cumulative ETH reserve used	ETH remaining
1	1.050000	0.499355	0.499463	0.054845	0.054845	0.000065351901	0.000111988497672728
2	1.100000	0.524484	0.524326	0.063701	0.118546	0.000130703802	0.000046636596672728

Wallet-Capped Totals

• Executable loops before ETH top-up: 2
• Total owned base added before cap: 2.15 cWUSDC
• Total net base permanently committed before cap: 1.023789 cWUSDC
• Cumulative retained quote before cap: 0.118546 USDC
• Remaining ETH after loop 2: 0.000046636596672728

Operational Meaning

With the current wallet state, the program is gas-capped before it is cW-capped.

So the next gating actions are:

1. top up Mainnet ETH if you want to run more than two loops under the current reserve policy
2. keep recalculating with live gas before each loop
3. only treat the full 10-loop ladder as actionable after the gas budget is restored

Fresh 10-Loop Ladder Under +750 USDC Matched Seed, $100 ETH Gas, and 125 USDC Wallet Reserve

This section models the exact scenario:

• add $100 of ETH to Mainnet for gas
• add 750 USDC to the cWUSDC/USDC pool
• keep 125 USDC in the wallet as reserve
• leave the rest of the wallet unchanged

Important interpretation:

• the 750 USDC pool addition is treated as matched depth, not one-sided quote-only liquidity
• that means the pool is initialized with 750 USDC plus 750 cWUSDC from existing owned inventory
• the 125 USDC reserve is kept outside the loop and is not required as a per-tranche retained floor

Updated Starting State

Starting from the live pool:

• B0 = 4.854615
• Q0 = 4.854873

After the matched seed:

• B0' = 754.854615
• Q0' = 754.854873

Updated Gas Budget

Using the current live Mainnet gas snapshot:

• gas price: 142,783,733 wei
• gas price in gwei: 0.142783733
• ETH/USD assumption: 2,140.09

Per-loop gas reserve under the same policy:

• 3 × 250,000 gas
• 0.00010708779975 ETH
• 0.2291775293669775 USDC

With $100 added as ETH:

• added ETH: 0.04672700680812489
• previous Mainnet ETH: 0.000177340398672728
• new Mainnet ETH total: 0.04690434720679762

That supports approximately:

• 437.999 loops under this gas policy

So under this scenario, gas is no longer a practical bottleneck.

Ladder Assumptions

This ladder uses:

• corrected gas accounting
• peg-neutral targeting (P_post = 1.0)
• the same size-aware exit curve:

P_exit(base_out) = max(1.18, 1.42 - 0.06 * base_out)

• 125 USDC wallet reserve held outside the loop
• no per-tranche retained floor beyond non-negative retained quote

Fresh 10-Loop Ladder

loop	dB_owned (cWUSDC)	x_flash (USDC)	base_out (cWUSDC)	net base added (cWUSDC)	q_net into pool (USDC)	P_exit_eff	retained_after_gas (USDC)	cum_retained (USDC)	B_end	Q_end	dev_bps
1	1.500000	0.749724	0.750243	0.749757	0.749499	1.374985	0.052297	0.052297	755.604372	755.604372	0.000
2	1.500000	0.749853	0.750372	0.749628	0.749628	1.374978	0.052339	0.104636	756.354000	756.354000	0.000
3	1.500000	0.749853	0.750371	0.749629	0.749629	1.374978	0.052338	0.156974	757.103629	757.103629	0.000
4	1.500000	0.749854	0.750371	0.749629	0.749629	1.374978	0.052337	0.209311	757.853257	757.853257	0.000
5	1.500000	0.749854	0.750371	0.749629	0.749629	1.374978	0.052336	0.261648	758.602887	758.602887	0.000
6	1.500000	0.749855	0.750370	0.749630	0.749630	1.374978	0.052336	0.313983	759.352516	759.352516	0.000
7	1.500000	0.749855	0.750370	0.749630	0.749630	1.374978	0.052335	0.366318	760.102146	760.102146	0.000
8	1.500000	0.749855	0.750370	0.749630	0.749630	1.374978	0.052334	0.418652	760.851777	760.851777	0.000
9	1.500000	0.749856	0.750369	0.749631	0.749631	1.374978	0.052333	0.470985	761.601407	761.601407	0.000
10	1.500000	0.749856	0.750369	0.749631	0.749631	1.374978	0.052332	0.523317	762.351038	762.351038	0.000

Totals Under This Scenario

• Total owned base added across loops: 15.0 cWUSDC
• Total flash quote borrowed across loops: 7.498415 USDC
• Total base returned by PMM-to-wallet across loops: 7.503606 cWUSDC
• Net base permanently committed to the pool: 7.496423 cWUSDC
• Cumulative retained quote after gas: 0.523317 USDC
• Pool reserves grow from about 754.85 / 754.85 to about 762.35 / 762.35

Interpretation

This scenario is materially better than the unseeded canary case:

• gas is no longer binding
• peg-neutral loops are easy to maintain
• the matched seed turns the pool from “canary tiny” into a workable staged venue

But it still has an important limitation:

• the matched seed improves local PMM mechanics, but it does not by itself answer the broader service-enablement, wallet, routing, and payment-rail requirements needed for public Thirdweb-facing distribution

Appendix: Thirdweb Service Expansion Requirements

This appendix captures the operational requirements for expanding Thirdweb support beyond the currently enabled baseline.

Current Planning Baseline

Workspace assumption for this rollout:

• enabled now: Tokens, Indexer
• target additions: Wallets, RPC, Server Wallets, Gas Sponsorship, Bridge, AI, x402

Public Thirdweb chain metadata checked on April 6, 2026 for Defi Oracle Meta (chainId 138) shows:

• visible products: Tokens, AI, HTTP API
• public RPC endpoint listed: https://138.rpc.thirdweb.com
• the chain overview and FAQ advertise add-to-wallet support and bridging into Chain 138
• the public product section does not currently show Wallets or x402 as enabled product tiles

Operational note:

• Insight for Chain 138 is running as of 2026-04-07 (operator-confirmed); still run node scripts/try-thirdweb-insight.js before external commitments. Historical note: Insight for 138 had previously returned unsupported responses; that is superseded by current operations. See docs/04-configuration/THIRDWEB_INSIGHT_INDEXER.md.

Shared Project-Level Requirements

These apply to essentially all added Thirdweb services:

• a live Thirdweb project with both Client ID and Secret Key
• domain allowlists for web apps and bundle IDs for native apps
• Chain 138 kept registered in Thirdweb chain metadata with canonical RPC, explorer, native token, and website fields
• production billing enabled for any mainnet-paid service
• a clear separation between frontend usage (clientId) and backend usage (secretKey)
• secret storage in repo-external secret management for all backend automations
• a dual-mode account abstraction plan that supports both EIP-4337 and EIP-7702
• chain-by-chain execution policy documenting when to use EIP-7702 and when to fall back to ERC-4337

Wallets

Requirements:

• enable wallet infrastructure on the project API key
• frontend integration with createThirdwebClient, ThirdwebProvider, and ConnectButton
• allowed domains and app bundle IDs configured on the Thirdweb project
• expose smart-account-capable wallet flows that can operate in both:
  • EIP-7702 mode on chains where Thirdweb and the chain support it
  • ERC-4337 mode everywhere we need smart-account features but EIP-7702 is not available
• decide whether Chain 138 uses:
  • standard in-app wallets per app, or
  • ecosystem wallets with ecosystemId and optional partnerId
• if ecosystem wallets are used, add our own apps and approved partner apps to the allowlist

Recommended Chain 138-specific additions:

• publish the canonical Chain 138 RPC and explorer metadata in the wallet onboarding flow
• verify add-network behavior for chainId 138 from the public chain page and in-app wallet flows
• treat ERC-4337 as the required compatibility baseline for Chain 138 until EIP-7702 support is explicitly confirmed for both the chain and Thirdweb execution stack

RPC

Requirements:

• keep the public Thirdweb RPC endpoint healthy and consistent for chainId 138
• ensure Chain 138 RPC is tied to the project API key / RPC Edge usage model
• keep HTTPS and WebSocket routing stable behind the existing Proxmox and NPMplus edge
• add Accept-Encoding support on clients to benefit from Thirdweb RPC response compression
• maintain production monitoring for latency, latest block, and error-rate regressions

Recommended Chain 138-specific additions:

• treat https://138.rpc.thirdweb.com as the canonical public endpoint exposed through Thirdweb
• keep our internal admin/core lane distinct from the public Thirdweb RPC lane

Server Wallets

Requirements:

• backend-only use of the Thirdweb Secret Key
• create at least one named server wallet identifier for treasury / settlement / automation roles
• fund the server wallet with native gas token on every chain where it must transact
• ensure server-wallet transaction paths work under both:
  • EIP-7702 for chains with supported smart-EOA execution
  • ERC-4337 for chains or workflows that still require bundler-based smart accounts
• define ownership boundaries for:
  • deployer
  • treasury
  • x402 settlement
  • bridge / routing automation
• wire server wallets only from backend jobs or trusted APIs, never the frontend

Recommended Chain 138-specific additions:

• dedicate separate server wallets for operator deployment, market operations, and payment settlement
• add balance checks and low-gas alerts to existing operational verification scripts

Gas Sponsorship

Requirements:

• enable account abstraction execution on the Thirdweb project
• implement both execution modes:
  • EIP-7702 as the preferred mode where the chain and Thirdweb support smart-EOA execution
  • ERC-4337 as the required fallback for chains without EIP-7702 support or for workflows that still depend on bundler semantics
• configure sponsorGas: true for the relevant wallet flows
• maintain valid billing for mainnet sponsored transactions
• create sponsorship policies with spend limits, chain restrictions, contract restrictions, and wallet allow/deny rules
• optionally deploy a server verifier endpoint to approve or reject sponsored transactions case by case
• test both paths explicitly rather than assuming EIP-7702 availability implies ERC-4337 parity

Recommended Chain 138-specific additions:

• only sponsor curated contracts and routes at first
• set per-day and per-wallet spend ceilings before opening public access
• require a verifier service for any production consumer wallet flow
• maintain a published execution matrix for Chain 138, Ethereum Mainnet, and each supported destination chain showing whether the active mode is EIP-7702 or ERC-4337

Bridge

Requirements:

• Chain 138 must be enabled by Thirdweb for bridge routing, not just listed in chain metadata
• frontend or API integration must use a Thirdweb client and bridge-capable flow such as SwapWidget or Bridge SDK methods
• supported assets, routes, and settlement chains must be confirmed for Chain 138 specifically
• bridge operations need funded source wallets and destination token availability
• run end-to-end route tests for:
  • inbound gas-token funding
  • stablecoin movement
  • failure / timeout recovery

Recommended Chain 138-specific additions:

• do not mark Bridge as production-ready until Thirdweb shows live route availability for Chain 138
• cross-check Thirdweb bridge coverage against our existing CCIP / Alltra / token-aggregation routing inventory

AI

Requirements:

• enable AI usage on the Thirdweb project
• use backend Secret Key access for /ai/chat
• pass explicit wallet and chain_ids context for Chain 138 requests
• define whether AI is:
  • read-only assistant
  • transaction-preparation assistant
  • auto-execution assistant using server wallets
• if auto-execution is enabled, bind it to server-wallet policy and audit logging

Recommended Chain 138-specific additions:

• start with read/query and transaction-preparation use cases
• only allow execution for tightly scoped internal operator actions after server-wallet controls are proven

x402

Requirements:

• x402 requires a Thirdweb server wallet for facilitator settlement
• x402 settlement uses EIP-7702 gasless execution through the facilitator
• the payment token must support either:
  • ERC-2612 permit, or
  • ERC-3009
• the API or agent endpoint must implement x402 server-side middleware or equivalent request handling
• supported payment methods should be queried programmatically before launch

Important compatibility note:

• x402 should be planned as a 7702-specific payment rail, not as a general 4337-compatible fallback path

Recommended Chain 138-specific additions:

• verify which Chain 138 payment tokens satisfy permit / authorization requirements before enabling x402
• use a dedicated settlement wallet, separate from deployer and treasury roles
• pilot x402 on narrow machine-to-machine or agent endpoints before exposing it across general public APIs

Required Verification Gates Before Public Rollout

Before claiming these services are enabled for Chain 138, verify all of the following:

1. the Thirdweb public chain page for Defi Oracle Meta visibly lists the intended services
2. project API keys are restricted to the correct domains and apps
3. server wallets exist, are funded, and are scoped by role
4. gas sponsorship policies and optional verifier callbacks are live for both EIP-7702 and ERC-4337 paths where applicable
5. bridge routes actually return executable quotes for Chain 138 assets
6. AI calls with chain_ids: [138] return correct reads and safe action payloads
7. x402 tokens on Chain 138 pass permit / authorization compatibility checks
8. each supported chain has an explicit execution-mode designation of EIP-7702, ERC-4337, or both
9. all of the above are reflected in repo runbooks and smoke tests

Official References

• Thirdweb API keys: https://portal.thirdweb.com/account/api-keys

• Thirdweb wallets quickstart: https://portal.thirdweb.com/wallets/quickstart

• Thirdweb ecosystem wallet setup: https://portal.thirdweb.com/wallets/ecosystem/set-up

• Thirdweb server wallets: https://portal.thirdweb.com/wallets/server

• Thirdweb gas sponsorship: https://portal.thirdweb.com/wallets/sponsor-gas

• Thirdweb sponsorship policies: https://portal.thirdweb.com/wallets/sponsorship-policies

• Thirdweb bridge: https://portal.thirdweb.com/bridge

• Thirdweb AI chat: https://portal.thirdweb.com/ai/chat

• Thirdweb x402: https://portal.thirdweb.com/x402

• Thirdweb x402 facilitator: https://portal.thirdweb.com/x402/facilitator

• Defi Oracle Meta chain page: https://thirdweb.com/defi-oracle-meta

• even with this improved starting point, the retained quote per loop is still only about 0.0523 USDC

So this is a stable, repeatable, peg-neutral ladder, but not yet a high-yield quote-building engine unless:

• the external unwind improves further, or
• tranche sizes and the exit curve are upgraded with better venue access, or
• direct quote seeding is increased beyond 750 USDC

Operational Best Use

Under this scenario, the best use of the loop is:

1. establish a healthier public pool with the matched 750/750 seed
2. preserve 125 USDC as wallet-side emergency reserve
3. use small peg-neutral loops to continue growing pool depth without destabilizing price
4. treat the loop as a gradual deepening program, not the primary source of quote inventory

Interpretation

This corrected ladder tells us three useful things:

1. Under corrected gas, the strategy can still work, but only if the external unwind is materially stronger than 1.12.
2. Peg-neutral targeting is much cleaner operationally than running near the deviation guard on every tranche.
3. The limiting resource becomes owned cWUSDC inventory, not flash capacity.

How to Use This Ladder

• Treat it as a scenario template, not as a venue promise.
• Before every loop:
  • refresh pool reserves
  • refresh gas
  • refresh flash premium
  • replace the scenario P_exit(base_out) with a live size-aware unwind quote
• Only execute the next tranche if the live quote still clears P_exit_required.

What the Sweep Showed

Using the current live Mainnet pool and dB_owned = 1 cWUSDC, the previously identified 0.35 to 0.60 USDC pass band was based on the understated gas subtraction.

With the corrected gas conversion, any tranche assessment must be re-run with the economically correct G_quote.

The production-safe rule is:

• never trust a tranche band unless the same G_quote value is shown in:
  • the gas reserve summary
  • the retained-after-gas subtraction
  • the final pass/fail guards

Why larger tranches fail:

• too little owned base add: flash quote moves the peg too far quote-heavy
• too much owned base add: the pool starts excessively base-heavy before the flash leg
• too much flash size: even with the owned base add, the quote push over-rotates the pool

How to Scale This Safely

Recommended Tranche Method

1. Refresh live gas, pool reserves, and flash premium immediately before sizing.
2. Choose a target post-trade peg band, not merely a flash size.
3. Solve for x from the target peg or from P_exit_required.
4. Add the owned cWUSDC base tranche.
5. Execute the flash-backed quote leg only if the live external unwind still clears the minimum required exit price.
6. Repay immediately from external proceeds.
7. Leave only retained USDC in the pool.
8. Re-read getVaultReserve() and getMidPrice().
9. Recalculate before the next loop.

Why Recalculation Matters

Each completed loop changes:

• B
• Q
• marginal price
• the next safe flash size

This is a staged ladder, not a one-shot large trade.

Operational Guidance

Do

• treat owned cW* as durable base inventory
• treat flash USD* as temporary working capital
• use live flash premium, live gas, and live unwind quotes for every tranche
• size toward a peg target or minimum viable exit price, not a guessed flash amount
• repay first
• seed only retained USD*
• recalc after every loop

Do Not

• assume a larger flash size is better
• assume a larger owned-base add is always safer
• assume balanceOf(pool) is the same thing as flash-cap certainty
• leave flash proceeds in the pool before repayment
• use these formulas without fresh reserve reads
• scale without verifying the modeled PMM math against the live pool read/query path

Exact Dry-Run Command

source scripts/lib/load-project-env.sh >/dev/null 2>&1

node scripts/analytics/pmm-flash-push-break-even.mjs \
  -B 4854615 -Q 4854873 \
  --full-loop-dry-run \
  --loop-strategy quote-push \
  --owned-base-add 1000000 \
  -x 600000 \
  --base-asset cWUSDC --base-decimals 6 \
  --quote-asset USDC --quote-decimals 6 \
  --external-exit-price 1.12 \
  --flash-provider-name "Aave mainnet" \
  --flash-provider-cap 682046747357782 \
  --flash-fee-bps 5 --lp-fee-bps 3 \
  --min-retained-usdc 50000 \
  --gas-tx-count 3 --gas-per-tx 250000 \
  --max-fee-gwei 0.087135868 \
  --native-token-price 3200 \
  --max-post-trade-deviation-bps 500

Important:

• This command is still useful as a structure/template.
• Before using it as a go/no-go decision, refresh the gas input and ensure the calculator is applying that same G_quote value consistently in the retained computation.
• If the economically correct gas conversion is used, the canary described above must be requalified rather than assumed safe.

Related repo tooling

• Readiness snapshot (mainnet pools, flash lenders, env): bash scripts/verify/check-public-pmm-dry-run-readiness.sh
• Multi-loop projection (modeled matched rebalance ladder): node scripts/analytics/pmm-flash-push-break-even.mjs --sequential-matched-loops N ... (see --help for --matched-flash-numerator / --matched-flash-denominator).
• Pool-implied sell-base price (diagnostic): scripts/verify/print-mainnet-cwusdc-usdc-pmm-sellbase-implied-price.sh [base_raw] [pool_address] prints gross USDC per cWUSDC from vault reserves (default pool: canonical public cWUSDC/USDC, or env PMM_CWUSDC_USDC_IMPLIED_PRICE_POOL). Feeding it to --external-exit-price-cmd makes the analytics tool treat the exit as “live” and can yield execution-ready, but it is not a substitute for your real external monetization venue: same-pool implied prices typically fail the repay guard versus a stronger off-pool exit (e.g. the 1.12 planning scenario).
• Steps 1–3 ladder helper: scripts/verify/run-mainnet-cwusdc-usdc-ladder-steps-1-3.sh — optional PMM_FLASH_EXIT_PRICE_CMD overrides the default printf 1.12 passed into --external-exit-price-cmd.
• Hosted external exit quote (DODO / 1inch): scripts/verify/print-mainnet-cwusdc-external-exit-quote.sh dodo|1inch [base_raw] — uses DODO_API_KEY or ONEINCH_API_KEY (see .env.master.example). Prefer this over pool-implied price when you want a route-aggregator quote for execution-grade inputs.

Updating the Paper With Live Inputs

To refresh the core live inputs:

cast gas-price --rpc-url https://ethereum.publicnode.com
cast block latest --rpc-url https://ethereum.publicnode.com | rg 'baseFeePerGas|number|timestamp'
cast call 0x69776fc607e9edA8042e320e7e43f54d06c68f0E 'getVaultReserve()(uint256,uint256)' --rpc-url https://ethereum.publicnode.com
cast call 0x69776fc607e9edA8042e320e7e43f54d06c68f0E 'getMidPrice()(uint256)' --rpc-url https://ethereum.publicnode.com
cast call 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2 'FLASHLOAN_PREMIUM_TOTAL()(uint128)' --rpc-url https://ethereum.publicnode.com

Recommended additional preflight:

cast estimate <atomic_flash_bundle_or_swap_call> --rpc-url https://ethereum.publicnode.com

and replace the scalar --external-exit-price with a conservative size-aware execution quote whenever possible.

Tranche Optimization Toward an 8M / 8M Public Pool

If the actual objective is to grow the public cWUSDC / USDC pool toward roughly:

• 8,000,000 cWUSDC
• 8,000,000 USDC

then the right control variable is no longer “smallest tranche that passes.”

The right control variable is:

• net pool growth per loop as a percentage of current pool size

Under the same corrected-gas and peg-neutral model used above, fixed tiny loops are far too slow for a multi-million target.

Executive Recommendation

For an 8M / 8M end state, the best actual operating plan is:

1. get out of the “tiny pool” regime as quickly as possible with direct matched adds
2. use hybrid flash loops to compound from a healthier starting pool
3. scale loops by percentage of current pool size
4. shift from aggressive to balanced to conservative sizing as the pool grows

In other words:

• direct seeding is the fastest way to establish serious depth
• hybrid loops are the best way to keep building without guessing once depth already exists

Why Fixed Tiny Loops Do Not Reach 8M Efficiently

Even under the improved +750 matched seed scenario, the fresh 10-loop ladder only grows the pool by about:

• 0.7496 cWUSDC
• 0.7496 USDC

per loop.

At that pace, reaching 8,000,000 / 8,000,000 from ~754.85 / 754.85 would require approximately:

• 10.67 million loops
• about 741 days at a 6s cadence

That is not an efficient path to the target.

Percentage-Based Tranche Method

For optimization, set the owned-base add each loop as a percentage of the current pool size:

dB_owned = alpha * current_pool_size

Then solve peg-neutral x_flash for that dB_owned.

Under the simplified reserve model used in this paper, the approximate net pool growth per loop becomes:

• alpha = 1.0% -> net pool growth ~0.498756%
• alpha = 2.0% -> net pool growth ~0.995049%
• alpha = 5.0% -> net pool growth ~2.469508%

These percentages are far more useful for planning toward a target reserve than a fixed micro-loop.

Optimized Profiles

profile	owned-base add target per loop	flash target per loop	net pool growth per loop	loops from ~754.85 to 8M	time at 6s cadence	approximate ETH gas required
conservative	1.0% of current pool	~0.4989% of current pool	~0.4988%	1,863	3.10 hours	~0.1995 ETH
balanced	2.0% of current pool	~0.9953% of current pool	~0.9950%	937	1.56 hours	~0.1004 ETH
aggressive	5.0% of current pool	~2.4702% of current pool	~2.4695%	380	0.63 hours	~0.0407 ETH

These are model-based planning figures, not execution guarantees.

Recommended Tranche Bands

The best actual tranche program for an 8M / 8M goal is:

1. Use direct matched seeding for the first large pool step whenever possible.
2. Use flash loops as an amplifier, not as the sole bootstrap source.
3. Scale loop size as a percentage of pool size rather than a fixed token amount.

Recommended operating bands:

• 100 -> 100,000 matched pool: use aggressive 5% loops if live unwind quotes support it
• 100,000 -> 1,000,000: use balanced 2% loops
• 1,000,000 -> 8,000,000: use conservative to balanced 1% to 2% loops, depending on live exit quality and MEV conditions

This is the practical compromise:

• larger early loops reduce total loop count materially
• smaller later loops are easier to execute safely against real unwind liquidity

Staged Path to 8M / 8M

The cleanest way to think about the program is in stages:

stage	pool zone	preferred action	reason
1	sub-100k	direct matched adds first, then aggressive 5% loops	tiny pools are too shallow for efficient micro-loop compounding
2	100k to 1M	balanced 2% loops	good tradeoff between speed and control
3	1M to 8M	conservative-to-balanced 1% to 2% loops	reduces execution stress and makes live unwind quality easier to maintain

This staged path is better than one fixed tranche policy because the pool’s needs change as it grows:

• early on, speed matters more than finesse
• later on, execution quality matters more than raw percentage growth

Decision Rule Per Loop

Before each loop, the operator decision can be reduced to:

1. identify the current pool zone
2. choose the profile for that zone
3. compute dB_owned = alpha * current_pool_size
4. solve peg-neutral x_flash
5. verify the live unwind quote still clears the minimum required exit price
6. execute only if the live quote and gas remain inside policy

That keeps the program deterministic and prevents “just try a bigger flash size” behavior.

What the Model Implies at Key Pool Sizes

Using the paper's current simplified exit model:

current matched pool	profile	dB_owned per loop	x_flash per loop	net permanent base added per loop	retained quote per loop
100,000 / 100,000	conservative 1%	1,000	498.905883	498.756211	92.083157
100,000 / 100,000	balanced 2%	2,000	995.347988	995.049384	189.766888
100,000 / 100,000	aggressive 5%	5,000	2,470.248734	2,469.507660	514.267926
1,000,000 / 1,000,000	conservative 1%	10,000	4,989.058830	4,987.562112	922.894171
1,000,000 / 1,000,000	balanced 2%	20,000	9,953.479880	9,950.493836	1,899.731476
1,000,000 / 1,000,000	aggressive 5%	50,000	24,702.487342	24,695.076596	5,144.741853
8,000,000 / 8,000,000	conservative 1%	80,000	39,912.470638	39,900.496897	7,384.757611
8,000,000 / 8,000,000	balanced 2%	160,000	79,627.839041	79,603.950690	15,199.456048
8,000,000 / 8,000,000	aggressive 5%	400,000	197,619.898737	197,560.612768	41,159.539070

Constraint on the Large-Size Rows

The large-size rows above become increasingly optimistic because the current scenario curve floors P_exit at 1.18.

That means:

• the mathematics are useful for tranche planning
• but the large-size rows are still upper-bound planning numbers
• before execution, each tranche still needs live size-aware external unwind quotes and private orderflow assumptions

So the final strategy implication is:

• if the target is truly 8M / 8M, use direct matched adds to get into the six-figure or seven-figure range quickly
• then use percentage-based hybrid loops to compound the pool
• do not try to bootstrap all the way to millions from sub-dollar flash loops

Practical Optimization Summary

If the goal is to smooth, improve, and optimize the strategy rather than merely prove it works, the optimized policy is:

• stop thinking in fixed token tranches once the pool becomes meaningful
• start thinking in percentage-based loop profiles
• reserve aggressive sizing for bootstrap phases only
• downgrade to smaller percentage loops as the pool gets deeper
• treat direct matched adds as the primary accelerator and flash loops as the compounding layer

Current Live Inventory Reality and Restructured Path to 8M / 8M

Using the refreshed live Mainnet state on April 7, 2026 after replacing the legacy cWUSDC / USDC pool and seeding the replacement:

• pool cWUSDC / USDC reserves:
  • B0 = 100.000000 cWUSDC
  • Q0 = 100.000000 USDC
• deployer wallet:
  • cWUSDC = 8,888,789.459367
  • USDC = 23.438732
  • ETH = 0.028931789204992397
• one observed live gas price during the post-repair dry-run pass:
  • 190,662,663 wei
  • 0.190662663 gwei

Important modeling note:

• the current loop calculator is still a planning tool unless it has:
  • a live executable pool quote surface
  • the strategy's live size-aware external quote
    • quote-push: live external exit quote
    • base-unwind: live external entry quote
  • measured or live-estimated gas for the actual path
  • an explicit post-trade deviation cap
• if those are missing, ladders should be treated as planning-only and not execution-ready
• on Mainnet, the repaired cWUSDC / USDC pool is healthier operationally, but it still exposes only a partial DODO read surface:
  • getVaultReserve() and getMidPrice() return successfully
  • querySellBase / querySellQuote still revert on direct pool reads
  • the tool therefore continues to treat execution-grade laddering as blocked on the missing live pool quote surface, even though the pool is now mapped correctly and funded
  • cWUSDT/USDT and cWUSDC/USDT remain planning-only today for the same reason

Important reachability note:

• because the repaired live pool has now been directly topped up to exactly 120 / 120, hypothetical matched ladders below 120 / 120 are no longer relevant as add-only top-ups from the current pool
• the next valid add-only matched rung from current live state is above 120 / 120

Current-Rung Reachability From Live Pool and Wallet

Using the refreshed post-top-up live state:

• pool cWUSDC / USDC reserves:
  • B0 = 120.000000 cWUSDC
  • Q0 = 120.000000 USDC
• deployer wallet:
  • cWUSDC = 8,888,769.459367
  • USDC = 3.438732
  • ETH = 0.028448799532520394
• observed gas price during this pass:
  • 1,041,456,922 wei
  • 1.041456922 gwei

Using the same aggressive 5% loop profile as the earlier ladder section and the same conservative gas policy (3 × 250,000 gas per loop), the refreshed matched-rung ladder is:

| target matched rung | direct base add needed | direct quote add needed | extra USDC needed beyond current wallet | loops to 50,000 / 50,000 at 5% profile | extra ETH needed beyond current wallet | time at 6s cadence | |---:|---:|---:|---:|---:|---:| | 10 / 10 | already above rung | already above rung | 0 | 350 | 0.244934 ETH | 0.583 h | | 25 / 25 | already above rung | already above rung | 0 | 312 | 0.215252 ETH | 0.520 h | | 50 / 50 | already above rung | already above rung | 0 | 284 | 0.193382 ETH | 0.473 h | | 75 / 75 | already above rung | already above rung | 0 | 267 | 0.180103 ETH | 0.445 h | | 100 / 100 | already above rung | already above rung | 0 | 255 | 0.170730 ETH | 0.425 h | | 120 / 120 | already at rung | already at rung | 0 | 248 | 0.165262 ETH | 0.413 h | | 150 / 150 | 30.000000 | 30.000000 | 26.561268 | 239 | 0.158232 ETH | 0.398 h | | 200 / 200 | 80.000000 | 80.000000 | 76.561268 | 227 | 0.148859 ETH | 0.378 h | | 300 / 300 | 180.000000 | 180.000000 | 176.561268 | 210 | 0.135581 ETH | 0.350 h | | 400 / 400 | 280.000000 | 280.000000 | 276.561268 | 198 | 0.126208 ETH | 0.330 h | | 500 / 500 | 380.000000 | 380.000000 | 376.561268 | 189 | 0.119178 ETH | 0.315 h | | 600 / 600 | 480.000000 | 480.000000 | 476.561268 | 182 | 0.113710 ETH | 0.303 h |

Interpretation:

• the current live pool has already surpassed every rung below 120 / 120
• the smallest new add-only matched rung from the current live pool is 150 / 150
• the most efficient rung in this band is still 600 / 600
• none of these ladders are executable from the current wallet under the conservative 3 × 250,000 gas policy without both:
  • more Mainnet USDC
  • more Mainnet ETH
• with the current live ETH, the wallet only supports about 36 loops under that conservative gas policy, which implies a minimum starting matched rung of roughly 20,776 / 20,776 to reach 50,000 / 50,000 without topping up more gas

The True Constraint

For an 8,000,000 / 8,000,000 target pool, the remaining matched depth needed from the current live pool is:

• additional base required: 7,999,950.118471 cWUSDC
• additional quote required: 7,999,999.527316 USDC

The deployer wallet can already cover the entire base-side requirement:

• wallet cWUSDC: 8,888,889.459367
• base required: 7,999,950.118471
• base surplus after a full direct base-side seed: 888,939.340896 cWUSDC

But the wallet cannot cover the quote-side requirement:

• wallet USDC: 5.765529
• quote shortfall: 7,999,993.761787 USDC

So the binding constraint is not cWUSDC.

The binding constraint is Mainnet USDC.

Why Selling Current cWUSDC to Raise USDC Is the Wrong Primary Path

If the current wallet tries to self-fund the quote side by monetizing part of its own cWUSDC, the pool ceiling is much lower than 8M / 8M.

Under several effective external monetization prices, the maximum matched pool reachable from the current wallet alone is approximately:

effective external monetization price for sold cWUSDC	maximum matched pool reachable from current wallet alone
1.00 USDC / cWUSDC	4,444,447.612448 / 4,444,447.612448
1.12 USDC / cWUSDC	4,696,019.792462 / 4,696,019.792462
1.18 USDC / cWUSDC	4,811,419.875038 / 4,811,419.875038
1.42 USDC / cWUSDC	5,215,797.023897 / 5,215,797.023897

To reach a fully matched 8,000,000 / 8,000,000 pool from the current wallet without any additional external USDC, the monetized portion of cWUSDC would have to clear at about:

• 8.999989 USDC per cWUSDC

That is not a reasonable planning assumption.

Restructured Strategy

Because of that, the optimized path to 8M / 8M changes:

1. Do not treat wallet cWUSDC as the scarce asset. It is already sufficient for the base-side target.
2. Do not rely on selling large amounts of current cWUSDC to create the entire quote side. That caps the reachable matched pool far below 8M.
3. Treat external or bridged Mainnet USDC as the primary capital requirement.
4. Use direct matched adds to move the pool into the six-figure or seven-figure regime quickly.
5. Only then use percentage-based hybrid loops to compound and tune the pool.

So the correct inventory-first plan is:

• preserve cWUSDC for direct matched seeding
• source Mainnet USDC directly rather than trying to synthesize all of it through self-liquidation
• use hybrid loops only after the pool is already materially deep

What This Means Operationally

If the goal remains exactly 8M / 8M, the cleanest path is:

• add 7,999,995.145385 cWUSDC from the deployer wallet directly to the pool side
• source 7,999,995.145127 USDC from external quote inventory, bridge flows, treasury capital, or other non-self-destructive sources

That is strictly better than selling down cWUSDC to manufacture the quote side from the same wallet.

Flash Loops Are Not the Bootstrap for This Exact Jump

At the current live gas price and wallet ETH:

• estimated gas per loop under the paper's policy:
  • 0.0000644439615 ETH
• current loop capacity before topping up ETH:
  • about 33.66 loops

So with the wallet in its current state:

• flash loops are not the limiting source of scale
• gas is too small for a meaningful bootstrap campaign
• and the quote-side capital gap is too large for loops to close efficiently from the current starting point

Mainnet Gas Top-Up Requirement

Because the current wallet only supports about 33.66 loops at the live gas price, Mainnet ETH top-up must still be treated as part of the execution plan, not an optional afterthought.

Using the paper's current loop gas policy:

• gas per loop: 0.0000644439615 ETH

the practical top-up bands are:

target loop budget	ETH required for loops only	practical ETH target including buffer
100 loops	0.00644439615 ETH	0.008 ETH
250 loops	0.016110990375 ETH	0.020 ETH
500 loops	0.03222198075 ETH	0.040 ETH
1,000 loops	0.0644439615 ETH	0.075 ETH
1,863 loops	0.1206583028745 ETH	0.135 ETH

For the optimized 8M / 8M path described above, a sensible operator policy is:

• minimum viable top-up: 0.02 ETH
• recommended working top-up: 0.05 ETH
• aggressive uninterrupted execution budget: 0.135 ETH

That top-up should happen before any serious loop campaign begins.

In other words:

• direct matched seeding solves the depth problem
• Mainnet USDC sourcing solves the quote problem
• Mainnet ETH top-up solves the execution continuity problem

The right use of loops here is:

• after a large direct matched seed
• after ETH is topped up for sustained execution
• as a compounding and maintenance layer, not as the primary path from ~4.85 / 4.85 to 8M / 8M

Bottom Line

The hybrid loop framework is viable in principle, but the path to 8M / 8M is now clearly an inventory-and-execution problem, not a “find the perfect flash size” problem.

The right next move is:

1. top up Mainnet ETH for the intended loop budget
2. source Mainnet USDC directly for the quote side of the target pool
3. use the deployer's existing cWUSDC inventory for direct matched base-side seeding
4. only then use percentage-based hybrid loops for compounding and maintenance

That is the durable path to growing public cWUSD*/USD* depth without guessing, without self-destructively selling the base inventory, and without letting gas starvation interrupt the strategy.

Operator Run Sheet — 256.763253 / 256.763253 Ladder

The current Mainnet operator state used for this run sheet is:

• deployer wallet:
  • ETH = 0.029745647296325322
  • USDC = 136.763253
  • cWUSDC = 8,888,769.459367
• live cWUSDC / USDC pool:
  • 120.000000 / 120.000000
• staged matched top-up:
  • +136.763253 cWUSDC
  • +136.763253 USDC
• staged matched pool:
  • 256.763253 / 256.763253

At this staged depth, the current safe quote-push tranche under the 500 bps cap is:

• 6.340000 USDC

and the modeled first-loop economics are:

• cWUSDC out from the PMM:
  • 6.185414
• retained after gas:
  • 0.545515 USDC
• post-trade deviation:
  • 499.785279 bps

Preflight

Run these checks before the first step:

source scripts/lib/load-project-env.sh >/dev/null 2>&1

WALLET="$(cast wallet address --private-key "$PRIVATE_KEY")"
echo "wallet=$WALLET"

cast balance "$WALLET" --ether --rpc-url "$ETHEREUM_MAINNET_RPC"
cast call 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 'balanceOf(address)(uint256)' "$WALLET" --rpc-url "$ETHEREUM_MAINNET_RPC"
cast call 0x2de5F116bFcE3d0f922d9C8351e0c5Fc24b9284a 'balanceOf(address)(uint256)' "$WALLET" --rpc-url "$ETHEREUM_MAINNET_RPC"
cast call 0x69776fc607e9edA8042e320e7e43f54d06c68f0E 'getVaultReserve()(uint256,uint256)' --rpc-url "$ETHEREUM_MAINNET_RPC"
cast gas-price --rpc-url "$ETHEREUM_MAINNET_RPC"

Expected readiness:

• enough wallet USDC to perform the matched top-up
• enough wallet ETH to keep the ladder running
• pool still at or near the staged assumptions after the top-up

Apply the staged top-up:

source scripts/lib/load-project-env.sh >/dev/null 2>&1

bash scripts/deployment/add-mainnet-public-dodo-cw-liquidity.sh \
  --pair=cwusdc-usdc \
  --base-amount=136763253 \
  --quote-amount=136763253

Verify the staged pool:

source scripts/lib/load-project-env.sh >/dev/null 2>&1

cast call 0x69776fc607e9edA8042e320e7e43f54d06c68f0E \
  'getVaultReserve()(uint256,uint256)' \
  --rpc-url "$ETHEREUM_MAINNET_RPC"

Expected:

• 256763253
• 256763253

Step 1

Dry-run the first safe tranche:

source scripts/lib/load-project-env.sh >/dev/null 2>&1

node scripts/analytics/pmm-flash-push-break-even.mjs \
  -B 256763253 -Q 256763253 \
  --full-loop-dry-run \
  --loop-strategy quote-push \
  -x 6340000 \
  --base-asset cWUSDC --base-decimals 6 \
  --quote-asset USDC --quote-decimals 6 \
  --external-exit-price-cmd 'printf 1.12' \
  --external-exit-source live \
  --flash-provider-cap 1000000000000 \
  --flash-provider-name 'Aave mainnet (cap placeholder)' \
  --gas-tx-count 3 --gas-per-tx 250000 \
  --max-fee-gwei 0.264434700 \
  --native-token-price 2241.69 \
  --max-post-trade-deviation-bps 500 \
  --execution-grade

Expected modeled result:

• retained after gas:
  • 0.545515 USDC
• post-trade deviation:
  • 499.785279 bps
• post-trade pool before rebalance:
  • 250.577839 / 263.101351

Rebalance back to matched:

source scripts/lib/load-project-env.sh >/dev/null 2>&1

bash scripts/deployment/add-mainnet-public-dodo-cw-liquidity.sh \
  --pair=cwusdc-usdc \
  --base-amount=12523512 \
  --quote-amount=0

Resulting matched pool:

• 263.101351 / 263.101351

Verify

source scripts/lib/load-project-env.sh >/dev/null 2>&1

cast call 0x69776fc607e9edA8042e320e7e43f54d06c68f0E \
  'getVaultReserve()(uint256,uint256)' \
  --rpc-url "$ETHEREUM_MAINNET_RPC"

Expected:

• 263101351
• 263101351

Step 2

Dry-run the next safe tranche:

source scripts/lib/load-project-env.sh >/dev/null 2>&1

node scripts/analytics/pmm-flash-push-break-even.mjs \
  -B 263101351 -Q 263101351 \
  --full-loop-dry-run \
  --loop-strategy quote-push \
  -x 6499324 \
  --base-asset cWUSDC --base-decimals 6 \
  --quote-asset USDC --quote-decimals 6 \
  --external-exit-price-cmd 'printf 1.12' \
  --external-exit-source live \
  --flash-provider-cap 1000000000000 \
  --flash-provider-name 'Aave mainnet (cap placeholder)' \
  --gas-tx-count 3 --gas-per-tx 250000 \
  --max-fee-gwei 0.264434700 \
  --native-token-price 2241.69 \
  --max-post-trade-deviation-bps 500 \
  --execution-grade

Expected modeled result:

• retained after gas:
  • about 0.560131 USDC
• resulting matched pool after rebalance:
  • 269.601416 / 269.601416

Rebalance:

source scripts/lib/load-project-env.sh >/dev/null 2>&1

bash scripts/deployment/add-mainnet-public-dodo-cw-liquidity.sh \
  --pair=cwusdc-usdc \
  --base-amount=12838163 \
  --quote-amount=0

Verify

source scripts/lib/load-project-env.sh >/dev/null 2>&1

cast call 0x69776fc607e9edA8042e320e7e43f54d06c68f0E \
  'getVaultReserve()(uint256,uint256)' \
  --rpc-url "$ETHEREUM_MAINNET_RPC"

Expected:

• 269601416
• 269601416

Step 3

Dry-run the next safe tranche:

source scripts/lib/load-project-env.sh >/dev/null 2>&1

node scripts/analytics/pmm-flash-push-break-even.mjs \
  -B 269601416 -Q 269601416 \
  --full-loop-dry-run \
  --loop-strategy quote-push \
  -x 6659826 \
  --base-asset cWUSDC --base-decimals 6 \
  --quote-asset USDC --quote-decimals 6 \
  --external-exit-price-cmd 'printf 1.12' \
  --external-exit-source live \
  --flash-provider-cap 1000000000000 \
  --flash-provider-name 'Aave mainnet (cap placeholder)' \
  --gas-tx-count 3 --gas-per-tx 250000 \
  --max-fee-gwei 0.264434700 \
  --native-token-price 2241.69 \
  --max-post-trade-deviation-bps 500 \
  --execution-grade

Expected modeled result:

• retained after gas:
  • about 0.574926 USDC
• resulting matched pool after rebalance:
  • 276.259243 / 276.259243

Rebalance:

source scripts/lib/load-project-env.sh >/dev/null 2>&1

bash scripts/deployment/add-mainnet-public-dodo-cw-liquidity.sh \
  --pair=cwusdc-usdc \
  --base-amount=13155202 \
  --quote-amount=0

Continue

The first ten safe loops from the 256.763253 / 256.763253 staged start produce:

step	start matched pool	flash USDC	retained after gas	end matched pool
1	256.763253	6.342691	0.545692	263.104041
2	263.104041	6.499324	0.560131	269.601416
3	269.601416	6.659826	0.574926	276.259243
4	276.259243	6.824290	0.590086	283.081486
5	283.081486	6.992817	0.605621	290.072205
6	290.072205	7.165505	0.621539	297.235561
7	297.235561	7.342458	0.637851	304.575816
8	304.575816	7.523780	0.654565	312.097339
9	312.097339	7.709581	0.671692	319.804606
10	319.804606	7.899969	0.689242	327.702206

Projected continuation from the same ladder:

horizon	end matched pool	cumulative retained after gas	cumulative flash borrowed	cumulative cWUSDC rebalance
50 loops	869.491510 / 869.491510	54.549432 USDC	612.912131 USDC	1210.689809 cWUSDC
100 loops	2944.406872 / 2944.406872	243.923981 USDC	2688.450154 USDC	5310.515224 cWUSDC

The operating rule remains:

1. dry-run the next tranche
2. execute only if it still passes under the live pool, gas, and deviation cap
3. rebalance back to matched
4. reread reserves
5. repeat