# AUM Fee

Source: https://docs.settlemint.com/docs/architects/components/token-features/aum-fee
Time-based management fee on DALPAsset. Accrues over time against time-weighted token supply and is collected by minting new tokens to the configured fee recipient.



AUM Fee is a token feature for charging an annual management fee on a DALPAsset. The fee accrues over time from the token's time-weighted supply and is collected by minting new tokens to the configured fee recipient. Existing holders pay through dilution, not through a treasury transfer.

Use it when an asset programme needs a recurring management fee that is visible on-chain, collected on demand, and controlled by token governance.

## System context [#system-context]

<Mermaid
  chart="`
flowchart LR
  Asset[DALPAsset token]
  Supply[Time-weighted supply]
  Config[Annual fee rate and recipient]
  Estimate[Accrued estimate]
  Collector[Collector or operator]
  Feature[AUM Fee feature]
  Recipient[Fee recipient]
  Holders[Existing holders]
  Governance[Token governance]
  Freeze[Freeze configuration]

  Asset -->|mint, burn, redeem hooks| Supply
  Supply --> Feature
  Config --> Feature
  Feature --> Estimate
  Collector -->|collectFee| Feature
  Feature -->|mint fee tokens| Recipient
  Feature -->|dilutes percentage ownership| Holders
  Governance -->|set rate or recipient| Config
  Governance -->|irreversible lock| Freeze
  Freeze --> Config

`"
/>

The feature sits between token supply changes, governance configuration, and fee collection. Mint, burn, and redemption hooks keep the time-weighted supply current. Collection turns the accrued estimate into a new mint to the configured recipient. Governance can change the rate or recipient until the configuration is frozen.

Related pages:

* [Token Features Catalog](/docs/architects/components/token-features)
* [Asset Contracts](/docs/architects/components/asset-contracts)
* [Treasury Distribution](/docs/architects/flows/treasury-distribution)

***

## Interface (capabilities) [#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 annual rate in basis points         | Updates the rate used for future reads | `FeeRateUpdated`      | Blocked after freeze                         |
| Set fee recipient   | `GOVERNANCE_ROLE` | Recipient address                       | Redirects future collections           | `FeeRecipientUpdated` | Blocked after freeze                         |
| Freeze fee config   | `GOVERNANCE_ROLE` | None                                    | Permanently locks rate and recipient   | `FeeRateFrozen`       | Irreversible                                 |

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

***

## How collection works [#how-collection-works]

1. The feature records the token's supply over time. Mint, burn, and redemption hooks update the supply accumulator. Transfers do not change total supply, so they do not update the accumulator.
2. `getAccruedFees()` estimates the fee from the time-weighted average supply, the configured annual basis-point rate, and the elapsed time since the last collection.
3. `collectFee()` resets the accumulator and last collection time. If the accrued amount is greater than zero, DALP mints that amount to the fee recipient and emits `AUMFeeCollected`.
4. The fee mint still uses the token's feature update path. The recipient must satisfy the token's mint compliance rules, or collection can revert.

Example: if the time-weighted average supply is 1,000,000 tokens, the annual rate is 200 basis points, and 30 days have elapsed, the accrued fee is about 1,643.84 tokens: `(1,000,000 * 200 * 30 days) / (10,000 * 365 days)`. The contract applies the same formula with token-unit integers.

If you need clean accounting periods around a rate or recipient change, collect the outstanding fee before changing the configuration. The next estimate uses the current configuration against elapsed time since the last collection.

***

## Accrued estimate read [#accrued-estimate-read]

`GET /api/v2/tokens/{tokenAddress}/aum-fee/accrued-estimate` reads the token's attached AUM Fee feature and returns the current accrued fee estimate. DALP reads `getAccruedFees()` and `getLastCollectionTime()` together, then returns the estimate in token units with the annual rate, last collection time, measurement time, and feature contract address.

The response uses the standard single-resource envelope. `data` is `null` when the token has no attached AUM Fee feature or the attached feature has not been initialised. If the chain read is unavailable, treat the estimate as temporarily unavailable rather than as zero accrued fees.

Use this read when an integration needs the same accrued-fee anchor shown in the token workspace before collecting fees.

***

## Token workspace surface [#token-workspace-surface]

Tokens with the AUM Fee feature show an AUM Fee tile in the asset detail workspace. The tile summarizes the annual rate, fee recipient, last collection time, accrued estimate, total collected amount, and whether the configuration is frozen. Use **View AUM fee details** to open the token's `/aum-fee` detail page.

The detail page separates:

* **Configuration:** annual rate, fee recipient, frozen state, and last collected time.
* **Collection stats:** estimated accrued fees and total collected fees.

If the token does not have the AUM Fee feature attached, the AUM Fee detail page shows an empty state instead of management controls.

Users with the matching token permissions see a **Manage AUM fee** menu on the detail page. Depending on their permissions and the frozen state, the menu can include options to collect accrued fees, set the annual rate, set the fee recipient, and freeze the configuration. Users without any of those permissions do not see the menu.

***

## Business impact [#business-impact]

* **Holders:** Fee accrual is inflationary. Collection mints new tokens to the recipient, reducing existing holders' percentage ownership unless they receive a proportional share of the minted fee tokens.
* **Issuer / recipient:** Fee collection sends newly minted tokens to the configured `feeRecipient`. No treasury drawdown is required.
* **Economics:** Fee accrues continuously based on elapsed time, annual rate, and time-weighted supply. Collection is triggered on demand, not automatically.

***

## Risks and abuse cases [#risks-and-abuse-cases]

* **Uncapped dilution:** If the configuration is not frozen after launch, `GOVERNANCE_ROLE` can raise the annual fee rate. The next estimate and collection use the current rate.
* **Delayed collection:** Accrued fees do not execute until someone triggers collection. Long gaps between collections can produce large single-mint events.
* **Fee recipient manipulation:** Before freeze, `setFeeRecipient()` can redirect future fee mints to another address. Use governance controls and monitoring for recipient changes.

***

## Controls and guardrails [#controls-and-guardrails]

| Role              | Available calls                                   | Recommended guardrail                                                       |
| ----------------- | ------------------------------------------------- | --------------------------------------------------------------------------- |
| `GOVERNANCE_ROLE` | `setFeeBps()`: set annual rate in basis points    | Collect outstanding fees before rate changes when period separation matters |
| `GOVERNANCE_ROLE` | `setFeeRecipient()`: set collection destination   | Use multi-signature governance and alert on recipient changes               |
| `GOVERNANCE_ROLE` | `freezeFeeRate()`: permanently lock configuration | Freeze after launch when rate and recipient are final                       |

***

## Failure modes and edge cases [#failure-modes-and-edge-cases]

* After `collectFee()` resets the last collection time, another estimate or repeat collection in the same block timestamp returns zero accrued fees.
* If total supply is zero across the measurement period, no fee accrues regardless of time.
* If `freezeFeeRate()` is called when `feeBps` is `0`, the feature remains active but does not accrue fees.
* When collection mints a fee, downstream hooks in the same transaction can observe the higher total supply. Place analytics features after AUM Fee when they must record post-fee supply.

***

## Auditability and operational signals [#auditability-and-operational-signals]

* `AUMFeeCollected(collector, recipient, feeAmount, timestamp)`: emitted on each positive collection. Monitor unusually large mint sizes.
* `FeeRateUpdated(sender, oldFeeBps, newFeeBps)`: emitted on rate changes. Alert on post-launch rate changes unless the operating policy permits them.
* `FeeRecipientUpdated(sender, oldRecipient, newRecipient)`: emitted when governance changes the recipient before freeze.
* `FeeRateFrozen(sender)`: emitted once on freeze. Absence of this event after launch is a configuration risk when the rate and recipient are meant to be fixed.

***

## Dependencies [#dependencies]

* No external ERC-20 dependency: the fee is paid in the token itself through minting.
* No treasury contract is required.
* No other feature is required. Analytics features such as Historical Balances should run after AUM Fee in the hook order if they need to observe post-fee supply.

***

## Compatibility and ordering notes [#compatibility-and-ordering-notes]

* Run AUM Fee before Historical Balances and Voting Power in the feature array when analytics hooks must see post-fee supply.
* AUM Fee collection mints from the zero address through the token's feature update path, so the fee recipient must pass the token's mint compliance checks.
* Compatible with Maturity Redemption. AUM Fee can still accrue while the feature remains attached, so collect or remove it according to the asset programme's operating policy.

***

## Change impact [#change-impact]

* Enabling AUM Fee after launch starts accrual from the moment the feature is initialised.
* Disabling AUM Fee leaves accrued but uncollected fees unminted. Collect before removing the feature if the fee should be paid.
* A rate change applies the new rate to the next estimate and collection. Collect first when you need the previous period calculated at the old rate.
* A recipient change sends future collections to the new recipient. Collect first when you need the previous recipient to receive the outstanding amount.
* Freezing the configuration locks the rate and recipient. Collection remains available.

***

## See also [#see-also]

* [Token Features Catalog](/docs/architects/components/token-features): return to the full feature catalog
* [Asset Contracts](/docs/architects/components/asset-contracts): deployment architecture and role model
* [Treasury Distribution](/docs/architects/flows/treasury-distribution): yield and fee distribution flows
