> For the complete documentation index, see [llms.txt](https://defi-handbook.gitbook.io/defi-handbook-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://defi-handbook.gitbook.io/defi-handbook-docs/how-do-you-convert-protocol-fees-into-a-treasury-reporting-asset.md).

# How Do You Convert Protocol Fees Into a Treasury Reporting Asset?

Convert protocol fees by selling the accrued fee tokens for the treasury’s chosen reporting asset, then record the trade and its accounting value separately. For an integration, the hard parts are selecting a safe execution threshold, handling token-specific behavior, and reconciling what arrived onchain with what the books expected.

### What does a treasury conversion need to preserve?

A conversion changes the treasury’s asset mix; it does not determine how much fee revenue the protocol earned. Keep fee accrual, swap execution, and accounting valuation as separate records so a trade’s price impact or delay does not rewrite historical revenue.

Define the reporting asset per chain, such as USDC on a particular network, and use its token address rather than its symbol as the identifier. Store the source token, chain ID, amount, recipient, transaction hash, execution timestamp, and reporting-asset amount received; symbols can collide, and token decimals vary.

Decide whether to batch accrued fees or convert each collection. Batching reduces transaction overhead and can improve route quality, but it leaves the treasury exposed to source-token price movement and may push the trade into a worse liquidity band. A threshold based on both elapsed time and minimum notional is usually more useful than a fixed daily schedule.

### How should you select a route and output threshold?

Choose the route by comparing executable output after gas and any integrator fee, not by comparing displayed spot prices. ParaSwap is relevant when it can compare liquidity sources and return an executable route for the fee token and reporting asset on the same chain; the [how ParaSwap works](https://dailynewscrypto.github.io/how-paraswap-swaps-tokens-from-quote-to-confirmation/) explanation belongs at this point because route construction determines the transaction you will validate and submit.

For a quote, provide the chain, source-token address, destination-token address, exact input amount in base units, and recipient or execution context required by the integration. Treat a quote as a short-lived proposal: refresh it before execution, and reject it if its block context or expiry is stale. Never convert human-readable amounts to integers with floating-point arithmetic.

Set the minimum acceptable output from a fresh quote and an explicit slippage tolerance. For liquid major pairs, an integrator might start around 0.3–1%; thin fee tokens or volatile periods may require more, but a larger tolerance is a larger loss limit, not a better price. If the route’s quoted output is 9,940 USDC for 10,000 units of a fee token and tolerance is 0.5%, the transaction’s minimum output should be about 9,890.3 USDC, rounded down to the token’s base unit.

Compare the expected value of the received asset with an independent accounting price at execution time. If the route implies a material deviation from that reference, pause for review; this catches stale quotes, shallow liquidity, and token-specific transfer effects that a router’s minimum-output check cannot identify.

### How do you build and execute the conversion?

Build an execution path that can be reproduced and audited from the quote inputs, transaction data, and onchain result. In an integration, validate the destination chain, router or spender, recipient, calldata, transaction deadline, and minimum output before signing; only grant allowance to the spender required for that trade, and prefer an exact allowance when operationally practical.

1. **Accrue:** Read the treasury’s fee-token balance and subtract any reserved amount, pending withdrawal, or minimum operating balance.
2. **Quote:** Request an exact-input route for the remaining amount, then calculate the minimum output using your configured tolerance and the reporting asset’s decimals.
3. **Validate:** Check chain, token addresses, recipient, spender, expiry, expected output, and independent price deviation; reject unsupported token behavior or a route outside policy.
4. **Execute:** Submit approval if needed, then the swap; record the transaction hash and wait for the required confirmation policy before marking it complete.
5. **Reconcile:** Read actual source spent and destination received from the finalized transaction, compare them with the accounting entry, and alert on a shortfall or unexpected transfer.

On an L2 such as Arbitrum, include the chain’s native gas asset in the operational reserve; a successful quote does not pay for transaction execution. If the transaction reverts, re-quote rather than resubmitting the same calldata: reserves, allowance state, or quote validity may have changed.

### Which edge cases change the design?

Token behavior can invalidate a route that looks sound by balance alone. Fee-on-transfer tokens deliver less than the nominal input, rebasing tokens can change balances between quote and execution, and pausable or blacklisting tokens can fail after approval; exclude these by default unless the route and accounting logic explicitly support them.

For large balances, split execution only when the improved price outweighs additional gas and monitoring complexity. A route may use multiple liquidity sources or an RFQ such as AugustusRFQ, but the integration should judge the returned transaction against the same recipient, expiry, output floor, and price-deviation policy. KyberSwap is another example of an aggregator category, but the treasury’s decision should rest on the route it can actually execute under its controls.

Keep failed, pending, and completed conversions as distinct states; do not treat a submitted transaction as realized reporting-asset revenue. My practical tip is to run a small conversion on each supported chain and token before enabling automation, then compare the finalized token deltas with the ledger entry format you plan to use.