AUM fee
How operators configure the aum-fee token feature for periodic management-fee accrual against assets under management.
The aum-fee token feature accrues a periodic management fee against the asset's outstanding supply, paid to a configured recipient wallet. Use it for fund management fees, real-estate property-management fees, and other instrument types where a percentage-of-AUM fee accrues over time.
For the architecture reference, see AUM fee.
When it attaches
Fund, ETF, money-market-fund, private-equity-fund, and real-estate templates attach aum-fee. See the system templates catalog.
What you configure
In the Asset Designer details step, the wizard surfaces:
| Parameter | Description |
|---|---|
feeBps | Annualised fee rate in basis points. 200 means 2.00% per year. |
recipient | Wallet that receives the accrued fee. Typically a treasury wallet under the fund manager's or property manager's control. |
The fee rate is applied per the platform's published accrual frequency. Most operating models accrue daily and settle to the recipient on a longer schedule (monthly, quarterly).
What you operate
After deployment:
- Inspect accrued AUM fees on the asset detail workspace's aum-fee tab. The tab shows the running accrual since the last collection.
- Collect accrued fees through the platform's fee-collection flow. The collection transfers accrued tokens from the asset to the recipient wallet.
- Distribute the cash settlement outside DALP. The recipient wallet holds the accrued asset units; converting those units to cash for the manager runs through your normal treasury workflow.
Operating considerations
- The fee accrues against outstanding supply, not against NAV. A fund's NAV-based fee is computed against
feeBps × outstanding supply × period, where the platform exposes the outstanding supply directly. - Burns reduce the AUM base immediately. A redemption that burns supply lowers the accrual base for subsequent ticks.
- The recipient is restricted-mutable. Updating the recipient runs through the governance-update path and applies to future accruals only; already-accrued-but-uncollected amounts continue to settle to the previous recipient.
- The fee feature does not enforce that the recipient is part of the same operating organisation. Configure the recipient correctly during asset creation to avoid accruing fees to the wrong wallet.
Troubleshooting
| What you see | What to check |
|---|---|
| Accrual stays at zero | Confirm the asset has outstanding supply and the configured feeBps is non-zero. |
| Fee recipient wallet shows no incoming tokens | Confirm the fee-collection flow has run since deployment. Accrual is on chain; collection is an explicit operator action. |
| Wrong fee rate accrued | Confirm feeBps matches the operating-team approval. Restricted-mutable updates apply forward; past accruals at the previous rate remain unchanged. |