rustydotwtf/pda-dynamic

Source References: Use Doppler deployments as the contract source of truth for deployed addresses and revisions.

Dynamic Price Discovery Auction

Suggested profile

• Asset tier: high/ultra-high-value assets
• Curve posture: maximally capital-efficient sale behavior
• Governance: OpenZeppelin Governor: disabled
• Migration: V4 migration path
• Beneficiaries: custom fee beneficiary setup
• Allocations: 3-6+ addresses
• Market posture: best for serious launches, project coins, and protocol tokens; better fit for teams willing to experiment

When to use

• You are launching a high-value asset and want active price adjustment through the sale
• You need epoch rebalancing, gamma tuning, tick accumulator logic, or slug placement behavior
• You are debugging why the auction rebalanced, exited early, or entered insufficient-proceeds mode

Prerequisites

• Understand token0 < token1 ordering and tick direction
• Know the sale asset and numeraire for the target pool
• Set a pricing stance up front:
  • Start above expected fair value
  • Set endingTick to encode the lowest acceptable sale price floor
  • Prefer 6h-24h auction windows over multi-day durations
• Have access to Foundry (forge, cast) and a compatible RPC endpoint

Core workflow

1. Decode the initialization config (startingTick, endingTick, gamma, epochLength, numTokensToSell, proceeds bounds).
2. Confirm epoch state (lastEpoch, tickAccumulator, totalTokensSold, totalProceeds).
3. Evaluate rebalance mode for the current epoch:
   • Max adjustment (no/low sales)
   • Relative adjustment (behind schedule)
   • Oversold adjustment (ahead of schedule)
4. Verify liquidity placement across slug classes:
   • Lower slug (refund support)
   • Upper slug (current epoch sales)
   • Price discovery slugs (future epochs)
5. Determine exit path:
   • Early exit (maximumProceeds reached)
   • Success at end time (minimumProceeds reached)
   • Insufficient proceeds (refund path)
6. Configure V4 migration path and verify migrator wiring for post-auction liquidity handoff.
7. Confirm beneficiary fee setup and allocation recipients (3-6+ addresses for the standard high-value profile).

Price behavior and objective

• The auction can move down in price when bidding interest is insufficient (Dutch-style behavior).
• The auction can move up in price when demand is stronger than expected or oversubscribed.
• Target objective: sell the fewest tokens at the best achievable price, maximizing capital efficiency.

Quick facts

| Item | Value | |---|---| | Main contract | src/initializers/Doppler.sol | | Precision constant | WAD = 1e18 | | Rebalance trigger | beforeSwap when entering a new epoch | | Max price discovery slugs | 15 | | Exit model | Proceeds-driven (not far-tick-driven) | | Recommended duration | 6h-24h |

Failure modes

• Tick misinterpretation from wrong token ordering
• Incorrect epoch assumptions when lastEpoch has not advanced
• Invalid parameter tuning (gamma too aggressive, epoch too short)
• Setting starting price too low for discovery or setting endingTick below the acceptable price floor
• Misreading insufficient-proceeds behavior as a hard failure

Verification hooks

• Auction state: see ../verification/references/CAST.md
• Math conversions: see ../verification/references/VIEM.md
• Event-driven analysis: see ../verification/references/EXPLORERS.md

References

• FLOW.md
• PARAMETERS.md
• FORMULAS.md
• GOTCHAS.md
• Source: doppler/src/initializers/Doppler.sol, doppler/docs/Doppler.md

Related skills

• pda-multicurve
• liquidity-migration
• fee-architecture
• verification
• uniswap-fundamentals