DALP transaction fee accounting: off-chain reconciliation

Explains how DALP records per-operation fee obligations for off-chain invoicing without collecting tokens on-chain. Covers rates, exemptions, reconciliation, and audit events.

Transaction Fee Accounting records a fee obligation when a token is minted, burned, transferred, or redeemed, but it does not withhold or move tokens on-chain. DALP keeps the token movement unchanged, increments the accrued fee total, and emits events that an operator can use for invoicing, reporting, or off-chain settlement.

Use this feature when the platform needs a reliable on-chain fee trail but wants settlement to happen later through an operating process. Use Transaction Fee instead when the token contract should collect the fee during the token operation.

Rendering diagram...

What the feature does

Transaction Fee Accounting is an explanation page for architecture and operations readers. It describes why the feature exists, what evidence it emits, and where the off-chain operating responsibility starts.

The feature stores three fee rates in basis points:

Mint fee rate for mint operations.
Burn fee rate for burn operations and redemption operations.
Transfer fee rate for holder-to-holder transfers.

For each tracked operation, DALP calculates the fee from the operation amount and the relevant rate. The calculation rounds down. If the operation amount is zero, the calculated fee is zero, either side of the token movement is fee-exempt, or either side is the configured fee recipient, no accounting fee is recorded.

Interface

Unlike Transaction Fee, Transaction Fee Accounting tracks obligations without moving or withholding tokens.

Capability	Who can call	Inputs	On-chain effect	Emits	Notes
Record fee on operation	Automatic hook	Triggered on mint, burn, transfer, redemption	Increments accrued counter; no token movement	`FeeAccrued`	Does not rewrite amounts
Reconcile accrued fees	`GOVERNANCE_ROLE`	None	Resets accrued counter; closes accounting period	`FeesReconciled`	Off-chain settlement trigger
Set fee rates	`GOVERNANCE_ROLE`	Mint, burn, and transfer rates in bps	Updates fee rate configuration	`FeeRatesUpdated`	Redemptions use the burn fee rate; blocked after freeze
Set fee recipient	`GOVERNANCE_ROLE`	Non-zero recipient address	Redirects future reconciliation target	`FeeRecipientUpdated`	Blocked after freeze
Set fee exemption	`GOVERNANCE_ROLE`	Account address + exempt flag	Marks address as exempt from tracking	`FeeExemptionSet`	Available from the dapp capability card and API
Freeze fee rates	`GOVERNANCE_ROLE`	None	Permanently locks rates and recipient changes	`FeeRatesFrozen`	Irreversible

Business impact

Holders: Token balances and operation amounts are not rewritten by this feature. Fees are tracked as obligations, not collected from the transfer path.
Issuer or platform operator: Accrued fees must be reconciled and settled through an off-chain process such as invoicing, ledger posting, or reporting.
Economics: The platform can batch settlement periodically instead of collecting value on every token operation.
Audit teams: FeeAccrued and FeesReconciled events create an on-chain trail for each accounting period, while the actual payment or settlement record remains outside the token contract.

Risks and abuse cases

Reconciliation drift: If reconcileFees() is not called on schedule, accrued fee obligations continue to build in accounting records. Platforms should define a reconciliation cadence and owner.
Exemption scope creep: setFeeExemption() can exclude a holder, system address, or the zero address from fee tracking. Exempting the zero address excludes mint-side or burn-side accounting because mint and burn operations use the zero address on one side of the token movement.
No on-chain enforcement: Fee obligations are advisory. Off-chain systems must act on emitted events to collect or settle the obligation.
Recipient self-noise: Operations involving the configured fee recipient are not tracked, so settlement and treasury movements do not create new fee obligations against themselves.

Controls and guardrails

Role	Actions	Recommended guardrail
`GOVERNANCE_ROLE`	`setFeeRates()` - set mint, burn, and transfer rates	Document changes and freeze rates when they should no longer move
`GOVERNANCE_ROLE`	`reconcileFees()` - mark accrued fees as reconciled for a period	Run on a scheduled off-chain cadence
`GOVERNANCE_ROLE`	`setFeeExemption(address, exempt)` - exempt a holder, system address, or the zero address for mint/burn accounting paths	Audit the exemption list and keep exemptions narrow
`GOVERNANCE_ROLE`	`setFeeRecipient()` - change the recipient recorded in reconciliation events	Use a non-zero operational recipient address
`GOVERNANCE_ROLE`	`freezeFeeRates()` - permanently lock rates and recipient changes	Treat as irreversible

Failure modes and edge cases

Accounting without collection: Recorded obligations that are never settled create audit discrepancies. Establish a settlement process before enabling the feature on production assets.
Concurrent fee events: Fee accruals add to the current accrued total. Reconciliation resets the accrued total to zero and emits the reconciled amount for the closed period, so reporting jobs should treat FeeAccrued and FeesReconciled as period events.
Rate changes mid-period: If fee rates change during a billing period, events reflect the rate at the time of each transaction. Off-chain systems must handle rate history in reconciliation logic.
High event volume: High-frequency tokens produce large event logs. Ensure the indexer, reporting job, or subgraph can handle the expected volume.
Nothing to reconcile: Reconciliation requires a non-zero accrued amount. If no tracked fees have accrued, the reconciliation call is rejected.

Auditability and operational signals

FeeAccrued(payer, from, to, feeType, operationAmount, feeBps, feeAmount, timestamp) - emitted per tracked operation. Use feeAmount for the accrued obligation and feeType to distinguish mint, burn, transfer, and redemption operations.
FeesReconciled(caller, recipient, amount, periodEnd) - emitted when accrued fees are reconciled. The event records the recipient and reconciled amount for the closed period.
FeeRatesUpdated(sender, oldRates, newRates) - emitted when fee rates change.
FeeRecipientUpdated(sender, oldRecipient, newRecipient) - emitted when the recipient changes.
FeeRatesFrozen(sender) - emitted when rate and recipient changes are permanently locked.
FeeExemptionSet(sender, account, exempt) - emitted when exemption status changes.

Dependencies

No external ERC-20 required.
No other token feature required.
Off-chain reconciliation infrastructure required, such as an indexer, invoicing process, ledger job, or reporting system.

Compatibility and ordering notes

supportsRewriting = false - the feature does not modify transfer amounts. It can run without changing the token operation path.
Mutually exclusive with Transaction Fee in asset templates and token creation requests. Use Transaction Fee for on-chain collection, or Transaction Fee Accounting for off-chain settlement records.
Compatible with other token features that do not require fee collection in the token operation itself.

Change impact

Enable after launch: Historical transactions before activation are not retroactively tracked.
Disable: In-progress uncollected obligations remain in off-chain records. Reconcile before disabling.
Rate change: Effective immediately. Off-chain systems must preserve enough rate history to reconcile the period correctly.
Freeze: Permanently blocks future rate and recipient changes for this feature.

Transaction Fee Accounting