Transaction fee
How operators configure the transaction-fee token feature for on-chain fee collection on mint, burn, and transfer operations.
The transaction-fee token feature deducts a configured fee from each mint, burn, or transfer operation and credits the fee to a configured recipient wallet. Operators configure rates, verify the recipient, and inspect collection history from the asset workspace.
For the full calculation model, invariants, and audit fields, see Transaction Fee architecture.
The transaction-fee feature is mutually exclusive with transaction-fee-accounting. Pick transaction-fee for on-chain collection; pick the accounting variant when the fee should be recorded but settled off chain.
When it attaches
The mutual-fund template (system-fund) attaches transaction-fee. Convertible-note and some custom templates also use it.
What you configure
In the Asset Designer details step, the wizard surfaces:
| Parameter | Description |
|---|---|
mintFeeBps | Fee on mint operations, in basis points. 100 means 1.00% of the minted amount goes to the recipient. |
burnFeeBps | Fee on burn operations. |
transferFeeBps | Fee on holder-initiated transfers. |
recipient | Wallet that receives the collected fees. |
Any of the fee rates can be set to zero to suppress fee collection on that operation type.
What you operate
After deployment:
- Review configured rates on the asset detail workspace's transaction-fee capability card.
- Check the fee recipient before approving rate or recipient changes. The recipient receives fee balances in the asset's own units.
- Inspect collected fees from the transaction-fee detail view when you need the collection history for reconciliation.
- Distribute the collected balance outside DALP if the operating model converts the asset-unit fee to fiat or another asset.
Operating considerations
- The fee is deducted from the operation amount before the holder receives the net result. A 100-unit mint with a 1% mint fee credits 99 units to the holder and 1 unit to the recipient.
- Per-operation rates are restricted-mutable. Updates apply forward; past operations were charged at the rate active at their time.
- The feature only moves asset units for the rate-driven deduction. Force-transfers and other administrative operations are not regulated transfers under this module.
- The recipient is restricted-mutable. Updating mid-life requires governance approval.
Troubleshooting
| What you see | What to check |
|---|---|
| Holder receives less than expected on mint | Confirm mintFeeBps matches the operating-team approval. A 1% fee on 100 units credits 99 units to the holder. |
| No fee collected on transfer | Confirm transferFeeBps is non-zero. The feature collects only when the rate is non-zero for the operation type. |
| Need accounting-only fee (no on-chain deduction) | Use transaction-fee-accounting instead. The two features are mutually exclusive. |
Read next
- Transaction Fee architecture for the canonical calculation model and audit fields.
- transaction-fee API reference for mutation routes.
- Transaction fee accounting for the accounting-only variant.
- Feature constraints
AUM Fee operator guide
How operators configure, monitor, collect, and freeze AUM Fee on DALP tokens without duplicating the architecture reference.
Transaction fee accounting how-to
How operators configure the transaction-fee-accounting token feature for off-chain settlement of mint, burn, and transfer fees.