A peg is not payroll cash

A dollar payment is due. Part of the available resources is a stablecoin balance, with an entered market price below one dollar. Selling the market portion produces cash at day zero in this model. The par-redemption portion produces cash on its declared settlement day. Choose the split and see which proceeds arrive in time.

Every mission compares policies using the same starting resources and shared conditions. The public browser engine calculates the results from entered assumptions, without an account or live market feed.

The decision to compare

How much of the balance should wait for assumed par redemption?

• Sell the whole balance. Set par redemption to 0%. Accept the entered market price and market-sale fee, with proceeds available at day zero.
• Wait for the whole balance. Set par redemption to 100%. Assume the declared redemption right and settlement date are available.
• Choose the split. Enter a percentage for par redemption. The remaining tokens are sold at the same entered market price.

Asset identity and cash access

Asset identity, price and usable cash are separate questions in this mission.

Asset identity

An illustrative dollar-pegged stablecoin balance. No issuer, token contract, wallet, exchange or chain has been selected or verified.

Cash access

Two assumed routes: a day-zero market sale, and redemption at USD 1 per token on the declared day. Route fees reduce the proceeds.

What can change

The comparison changes only the redemption percentage. Token balance, cash, price, fees, settlement date and payment deadline stay the same across both plans.

What the result means

The kernel checks the cash ledger over the entered horizon. Later receipts cannot repair an earlier payment deficit.

A calculated reference example

The reference split sends 60% of 100,000 tokens to assumed par redemption. The market sale produces $38,606.00 immediately; par redemption produces $59,940.00 on day 5. With $10,000.00 opening cash and a $100,000.00 payment on day 3, the model records a peak funding deficit of $51,394.00. The later proceeds leave $8,546.00 at the horizon, but cannot fund the earlier deadline retrospectively.

The worked example uses the published default inputs and Go model yieldguard-experiments-1.2.0. The scenario starts on 2026-01-01; that date is an illustrative calendar origin, not a market observation date.

Sources and interpretation limits

Par redemption is an assumption here. Legal entitlement, eligibility checks, issuer access and actual settlement depend on the holder and product. Market depth, blockchain fees, exchange failure and recovery are outside this model.

Primary documentation explains mechanisms and product distinctions. The documentation does not verify these inputs or identify the illustration as a named product.

• Circle: EEA redemption policy
• Circle: native USDC contract directory

• Illustrative user assumptions; no live market data or calibrated forecast.
• Results apply only to the declared mechanisms, horizon and search bounds.
• The market portion is sold at day 0. The other portion assumes an enforceable, available redemption at exactly USD 1 per token on the declared day; neither availability nor the peg is verified.
• No issuer recovery, market depth, exchange failure, blockchain fee, tax or probability model. Redemptions after the horizon remain unavailable within it.

Continue the investigation

Read the related calculation, controls and limits, or compare another mission using its own declared mechanism.

• Fund the fee cap — A lower final fee does not remove the upfront gas reserve.
• Keep what the yield earns — Measure the same assumed yield after entry, gas and exit costs.