DALP AUM fee: time-based management fee for tokens

Time-based management fee on DALPAsset. Accrues over time based on total supply and is collected by minting new tokens to the fee recipient — an inflationary mechanism.

Purpose: AUM Fee charges a time-based management fee as a percentage of Assets Under Management. Collection is inflationary — it mints new tokens to the configured recipient.

Doc type: Reference
What you'll find here: Business impact, risks, controls, failure modes, auditability, dependencies, and ordering notes
Related:

Interface (capabilities)

This feature exposes the following capabilities. Fee collection is inflationary — it mints new tokens to the configured recipient rather than transferring existing tokens.

Capability	Who can call	Inputs	On-chain effect	Emits	Notes
Collect accrued fee	Anyone	None (uses elapsed time + total supply)	Mints tokens to fee recipient	`AUMFeeCollected`	Permissionless trigger; accrues continuously
Set fee rate	`GOVERNANCE_ROLE`	New rate (basis points)	Updates annual fee rate	`FeeRateUpdated`	Blocked after freeze
Set fee recipient	`GOVERNANCE_ROLE`	Recipient address	Redirects future collections	`FeeRecipientUpdated`	Effective immediately
Freeze fee rate	`GOVERNANCE_ROLE`	None	Permanently locks rate	`FeeRateFrozen`	Irreversible

Accrued fees, current rate, recipient, and freeze status are available as read-only queries.

Business impact

Holders: Fee accrual is inflationary — new tokens are minted, diluting existing holder percentage ownership. NAV per token decreases proportionally over time.
Issuer / recipient: Fee collected as newly minted tokens to configured feeRecipient. No treasury drawdown required.
Economics: Fee accrues continuously based on time elapsed and current total supply. Collection is triggered on demand (not automatic).

Risks & abuse cases

Uncapped dilution: If freezeFeeRate() is not called after launch, GOVERNANCE_ROLE can raise the fee rate at any time, retroactively increasing the accrued fee on next collection.
Delayed collection: Accrued fees do not execute until someone triggers collection. Large time gaps between collections produce large single-mint events, which may alarm holders or analytics systems.
Fee recipient manipulation: setFeeRecipient() can redirect fee flow to any address. No time-lock by default.

Controls & guardrails

Role	Actions	Recommended guardrail
`GOVERNANCE_ROLE`	`setFeeBps()` — set fee rate in basis points	Call `freezeFeeRate()` immediately after launch to lock rate permanently
`GOVERNANCE_ROLE`	`setFeeRecipient()` — set collection destination	Multi-sig controlled; audit recipient changes
`GOVERNANCE_ROLE`	`freezeFeeRate()` — permanently lock fee rate	Call at launch — prevents future rate changes

Failure modes & edge cases

Zero supply: If total supply is zero, no fee accrues regardless of time. Collection produces a zero-mint no-op.
Rate frozen at zero: If freezeFeeRate() is called with feeBps = 0, the feature remains active but never collects. Disable it entirely instead.
Reentrant collection: If collection is called during a lifecycle hook chain, downstream hooks see the inflated supply in the same transaction. Order analytics features after AUM Fee.

Auditability & operational signals

AUMFeeCollected(collector, recipient, feeAmount, timestamp) — emitted on each collection. Monitor for anomalous mint sizes.
FeeRateUpdated(sender, oldFeeBps, newFeeBps) — emitted on rate changes. Alert on any post-launch rate change.
FeeRateFrozen(sender) — emitted once on freeze. Absence of this event after launch is a configuration risk.

Dependencies

No external ERC-20 dependency — fee paid in the token itself (minting).
No treasury contract required.
No other features required, but analytics features (Historical Balances) should run after AUM Fee in the hook order.

Compatibility & ordering notes

Run AUM Fee before Historical Balances and Voting Power in the feature array — analytics hooks must see post-fee supply.
No conflict with compliance modules (AUM Fee does not go through transfer compliance checks — it mints directly).
Compatible with Maturity Redemption: AUM Fee stops having economic impact once transfers are blocked post-maturity, but it continues accruing until collection or feature removal.

Change impact

Enable after launch: Retroactive accrual does not occur — accrual starts from the moment the feature is activated.
Disable: Accrued-but-uncollected fees are lost. Collect before removing the feature.
Rate change: Takes effect immediately on next collection calculation. Freeze rate to prevent future changes.
Recipient change: Effective immediately for all future collections.

AUM Fee