Fee administration
Set transaction and AUM fee rates and recipients, freeze either rate permanently, and collect accrued AUM fees for an asset.
Fee administration groups seven controls across two independent mechanisms, and each mechanism collects value in a different way. Transaction fee sets three rates, mint, burn, and transfer, each in basis points, where one basis point equals 0.01% of the operation's value. The token collects that fee automatically: every operation it applies to splits into a net leg and a fee leg the moment it runs, and the fee leg lands directly in the fee recipient's balance. A zero-value operation, an operation that involves the fee recipient, a custodian forced transfer, and an operation whose fee rounds down to zero pass through without a split. AUM fee works differently. It sets a single annual rate that accrues continuously against the token's time-weighted average supply, the average amount outstanding since the last collection, weighted by how long each amount stayed outstanding. Nothing moves until someone runs "Collect AUM fee", which mints the amount accrued so far straight to the recipient. That is why a collect control exists for AUM fee and not for transaction fee: one mechanism pays itself out on every operation, the other only pays out when someone asks it to. This page only changes that configuration. To check the current rates, the recipient, or whether a rate is frozen without touching anything, open the asset's overview and read the "Transaction Fee" or "AUM Fee" tile instead of opening any of these seven controls. The external transaction fee and the transaction fee accounting feature have their own controls on their own feature tiles, and the token features catalog describes both.
Six of the seven controls check the governance role, which is distinct from the custodian role that gates forced transfer and freeze, and the emergency role that gates pause. "Collect AUM fee" checks no role: any account can run it, and the amount and the recipient are fixed by the accrual, so the caller cannot redirect or inflate it. Missing the governance role produces the same shape of message for each of the six: the Console names the specific control and states plainly that you lack the governance role for this token. Visibility is separate from permission, though. None of the seven appear in "Manage Asset" until an operator attaches the corresponding feature, transaction fee or AUM fee, to the asset and its configuration finishes indexing. A newly attached feature can stay invisible for a moment even to an account that holds the governance role. That gap closes on its own once the config catches up. The role only gates these controls, though, not the fees themselves. A rate, a recipient, and a frozen flag are all stored in the fee feature attached to the token, not in the token itself. Each keeps applying exactly as configured even after the governance role moves to someone else or gets revoked entirely; revoking the role stops that person from changing the configuration again, not the configuration already in place.
Two of the seven controls end differently than the rest. Freezing transaction fee rates and freezing the AUM fee rate each set a one-way flag on that fee's feature contract. No function in either fee feature ever sets that flag back, so once someone freezes a fee's rate, rate-setting on that feature instance stops working permanently, for every future governance holder, not just the one who froze it. Only replacing the feature, which a governance holder can do through the Platform API and no Console control offers, starts a fresh instance with a rate that can change again. That reach is narrower than it first appears, though, and it is not the same reach for both fees. Setting the transaction fee recipient and collecting AUM fees both ignore frozen state completely, in the Console's menu and in the contract alike. Setting the AUM fee recipient does not: freezing the AUM rate also blocks its recipient at the contract level, even though the Console's own menu keeps that control selectable regardless. Trust the contract's rule over the menu's appearance there, since a governance holder can select "Set AUM fee recipient" on a frozen AUM fee and still watch the transaction revert. Confirm which lever you actually mean to lock before you freeze anything. No control this page describes, and no other Fee control in the Console, can reopen a frozen rate afterward.
Steps
Select the control
Open "All assets", select the asset, and open "Manage Asset". The menu lists up to seven fee controls, grouped by mechanism: "Set transaction fee rates", "Set transaction fee recipient", and "Freeze transaction fee rates" for the per-operation mechanism; "Set AUM fee rate", "Set AUM fee recipient", "Freeze AUM fee rate", and "Collect AUM fee" for the accrual mechanism.
Pick a rate-setting or recipient-setting control for routine configuration changes; both are reversible for as long as the fee stays unfrozen. Reach for "Freeze transaction fee rates" or "Freeze AUM fee rate" only when the rate is meant to stop changing forever, since neither this page nor any other control in the Console reopens a frozen rate. Use "Collect AUM fee" whenever accrued value needs to reach the recipient now, since nothing collects it automatically the way transaction fee does.
Screen equivalent: the "Manage Asset" menu lists each fee control only once the asset's configuration includes that mechanism's feature. The menu disables rate-setting and rate-freezing after a freeze, and states the missing governance role on any control the signed-in account cannot use. It does not disable "Set AUM fee recipient" after a freeze, even though the contract itself rejects that change.
Enter and review the instruction
For "Set transaction fee rates", enter the mint, burn, and transfer rates as whole basis points, each from 0 to 10000, where 10000 equals 100%. Review all three together in the confirm step before submitting, since one submission updates all three rates at once even if only one of them changed.
For "Set AUM fee rate", enter a single annual rate as whole basis points, again 0 to 10000. This rate accrues against time-weighted average supply rather than applying per operation, so a change here affects value that accrues from this point forward, not fees already accrued under the previous rate. When the old rate is above zero and fees have accrued, changing the rate first settles them: the contract mints that amount to the current recipient, as "Collect AUM fee" does, and "Total collected" can therefore increase. When the accrued amount still rounds down to zero, nothing settles and the carried accrual is charged at the new rate. Submitting the rate that is already set settles nothing.
For "Set transaction fee recipient" or "Set AUM fee recipient", pick the recipient address from the same eligibility-checked picker ordinary transfer uses. That check filters a fee recipient exactly as it filters an ordinary transfer recipient: an address that cannot receive this token does not appear as a choice, and the token checks the recipient again whenever a fee leg moves value to it. If the AUM fee rate is already frozen, expect "Set AUM fee recipient" to revert at wallet verification regardless of address eligibility; the Console's menu does not warn you before you get that far. That eligibility check runs again every time a fee leg actually moves value to the recipient, not only once when you set it. If the recipient later loses eligibility, the next operation that owes a fee to it fails, instead of the fee quietly not arriving.
For "Freeze transaction fee rates" or "Freeze AUM fee rate", there is no rate or recipient to enter. The confirm step's own instruction asks you to type "freeze" before it lets you continue, and only an exact, case-sensitive match unlocks wallet verification.
"Collect AUM fee" has no fields at all. Confirming submits directly to wallet verification, and the amount collected is whatever has accrued since the last collection. Collecting mints that amount as new tokens straight to the recipient, so every holder's proportional share of the asset shrinks by the same amount it always does when supply grows. The collection mint is booked as a fee movement: a transaction fee on the same token does not split it, and an external transaction fee does not charge it, but identity and compliance checks still run. If the recipient has lost eligibility since it was set, the mint fails the same eligibility check an ordinary mint to that address would fail, and the whole collection reverts instead of partially completing.
Submit the transaction
Confirm with wallet verification, the same as any other Console admin change.
Rate and recipient changes revert cleanly if a check fails; nothing about the fee configuration changes before the transaction lands on-chain. Once a rate change lands, it applies to whatever runs after it, not to the rate that was live when someone submitted a transaction. A mint, burn, or transfer already sent but not yet mined still charges whichever rate is live the instant it actually executes. Freezing is different. Its confirm view repeats the same warning in two places: "This action is irreversible. Once frozen, fee rates can never be changed again." The specific control's own description underneath restates the same fact in its own words, "Permanently freeze the transaction fee rates. This action is irreversible." for the transaction-fee control, "Permanently freeze the AUM fee rate. This action cannot be undone." for the AUM-fee control.
Once you confirm a freeze, rate-setting for that fee is gone for good. No unfreeze function exists in either fee feature, so there is nothing left to run on that feature instance even by someone with the governance role. Setting the transaction fee recipient and collecting AUM fees keep working afterward exactly as before, since neither one checks frozen state anywhere. Setting the AUM fee recipient does not: the contract rejects it once the AUM rate is frozen, even on a submission the Console's own menu let you start.
Collecting AUM fees is not reversible either, frozen rate or not. Once a collection mints tokens to the recipient, those tokens exist like any other holding; no control on this page, or anywhere else in the Console, un-mints them.
Six of the seven fee controls require the governance role, and "Collect AUM fee" requires none. Once a rate is frozen, no function anywhere reverses it, so rate-setting for that fee is blocked from that point on, for every governance holder. Setting the transaction fee recipient and collecting AUM fees are unaffected: the Console's permission check for those two controls depends only on the governance role, never on frozen state. Setting the AUM fee recipient does not appear in either lane here. Freezing the AUM rate blocks it too, at the contract level, even though the Console's menu keeps that control selectable regardless.
Troubleshooting
Fee controls are missing from Manage Asset
Signal: none of the seven fee controls appear. Cause: the asset carries neither the transaction fee feature nor the AUM fee feature, or it carries one whose configuration has not finished indexing yet, in which case the Console treats it as not yet configured. Fix: confirm the asset's configured features; if a fee feature was just attached, wait for the configuration to finish indexing and reopen the menu.
A fee control is visible but cannot be selected
Signal: a control shows in the menu, greyed out. Cause: your account lacks the governance role on this specific asset; the Console's disabled message names it directly. "Collect AUM fee" is never disabled for a missing role. Fix: ask an administrator to grant the governance role, scoped to this asset.
Set transaction fee rates or Set AUM fee rate cannot be selected, though the governance role is present
Signal: the menu disables the control. Its message reads: "Fee rates are frozen and cannot be changed." That message names no missing role this time. Cause: someone already froze that fee's rate; freezing removes rate-setting from every governance holder, not just the one who froze it. Fix: nothing to fix. Set a different fee's rate if one remains unfrozen, or use the recipient or collection controls instead, since freezing does not touch those, apart from the AUM fee recipient exception described below.
Freeze confirmation will not continue
Signal: the freeze confirm step stays on "Cancel" and will not advance to wallet verification. Cause: the typed word does not exactly match "freeze"; the check is case-sensitive and ignores only leading and trailing spaces. Fix: retype "freeze" in lowercase, with no other characters.
Setting the transaction fee recipient or collecting AUM fees still works after a freeze
Signal: "Set transaction fee recipient" or "Collect AUM fee" remains selectable and completes normally on a fee whose rate is frozen. Cause: this is normal, not a fault. Freezing blocks only rate-setting for that fee; the Console's permission check for these two controls never depends on frozen state. Fix: nothing to fix; treat freezing as narrower than a full lock on the fee.
Set AUM fee recipient reverts even though the menu allowed it
Signal: "Set AUM fee recipient" is selectable, wallet verification proceeds, and the transaction still reverts. Cause: the AUM fee rate is frozen. The Console's menu checks only the governance role for this control, so it never disables the item for a frozen rate, but the contract rejects a recipient change once frozen, the same as it rejects a rate change. Fix: check the "AUM Fee" tile's status badge before you try; if it reads "Frozen", the recipient cannot change either, and no control on this page reopens that rate.
A mint, burn, or transfer reverts even though rates and roles look fine
Signal: an ordinary mint, burn, or transfer reverts on an asset that carries the transaction fee feature, even though the operation itself would normally succeed. Cause: the transaction fee recipient no longer passes the eligibility check that gates every operation on this token. The fee leg the token creates on every qualifying operation goes through the same check as the operation itself, so an ineligible fee recipient blocks the whole operation, not just its fee. Eligibility can change after the recipient was set, so this can surface long after that change. Fix: restore the recipient's eligibility, or use "Set transaction fee recipient" to point at a currently eligible address instead.
Collect AUM fee reverts instead of minting
Signal: "Collect AUM fee" reverts rather than completing. Cause: the same eligibility check applies to the minted fee amount, and the AUM fee recipient no longer passes it. Fix: use "Set AUM fee recipient" to point at a currently eligible address first, if the rate is not frozen, then retry the collection.
Set fee recipient rejects an address
Signal: the picker does not offer an address for a fee recipient. Cause: the recipient picker only offers addresses eligible to receive this token, the same eligibility check ordinary transfer uses; an address that cannot receive the token cannot receive its fees either. Fix: confirm the intended recipient's identity registration and eligibility for this token before retrying.
Collect AUM fee reports zero collected
Signal: "Collect AUM fee" completes without reverting, but the collected amount is zero and "Total collected" does not change. Cause: no time has passed since the last collection, or the accrued amount rounds down to zero at the current rate and supply. The fee formula weights supply by elapsed time, so a very short gap between collections can legitimately accrue nothing. The accrued amount is the time-weighted average supply since the last collection, multiplied by the annual rate, multiplied by the elapsed time, divided by a year. A short elapsed time or a low rate can round that product down to zero even with a healthy supply. Fix: nothing to fix; wait longer between collections, or check the tile's "Accrued (est.)" figure before collecting to confirm there is a meaningful amount to collect.
No collect control exists for transaction fees
Signal: "Collect AUM fee" has no counterpart among the transaction fee controls. Cause: this is normal. Transaction fee pays itself out inside every mint, burn, and transfer it applies to, splitting the operation into a net leg and a fee leg at the moment it runs, so there is nothing left to collect afterward. Fix: nothing to fix; check the "Transaction Fee" tile's "Total collected" figure and its collection history for a record of fees already paid, instead of looking for a manual collect control.