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

Fee Architecture

When to use

You need to explain where fees are tracked and how payouts are derived
You are debugging fee outcomes across migration and beneficiary paths
You are changing LP fee configuration or hook-driven fee behavior
You are validating multicurve fee decay configuration (startFee, fee, durationSeconds, startingTime)

Identify sale path (static, dynamic, multicurve, or hook-initialized multicurve path)
Identify whether pool is locked (beneficiaries enabled) or migrable

Identify fee surfaces in the flow:
- Swap-time LP fees (pool/hook context)
- Migration-time proceeds accounting in Airlock
- Beneficiary fee tracking in FeesManager / locker modules
Confirm storage location for each fee bucket:
- Airlock fee accounting mappings
- Hook-local storage (for example RehypeDopplerHook fee buckets)
- Locker/initializer collectFees paths for beneficiaries
Validate claim paths for each actor (beneficiary, buyback destination, integrator, or protocol owner).
Reconcile balances before and after claims on-chain.

Fee type	Primary location	Typical claim path
Protocol/integrator accounting	`src/Airlock.sol`	`collectProtocolFees(...)`, `collectIntegratorFees(...)`
Beneficiary fees (initializer/locker)	`src/base/FeesManager.sol`, locker modules	`collectFees(...)`
Rehypothecation hook beneficiary + protocol-owner buckets	`src/dopplerHooks/RehypeDopplerHook.sol`	`collectFees(asset)`, `claimAirlockOwnerFees(asset)`

COLLECTION.md
DISTRIBUTION.md
DYNAMIC-FEES.md
Source: doppler/src/Airlock.sol, doppler/src/base/FeesManager.sol, doppler/src/StreamableFeesLockerV2.sol, doppler/src/dopplerHooks/RehypeDopplerHook.sol