docs: add TIP-1042 FeeAMM TIP-403 policy exemptions

[decofe]

Reopen of #3227 with new TIP number. Exempts the FeeAMM address from TIP-403 checks during fee collection while preserving full enforcement on public AMM operations (mint, burn, rebalanceSwap, distributeFees). Also adds a new authorization gate on mint requiring the caller to be authorized on the userToken.

Co-Authored-By: Daniel Robinson 1187252+danrobinson@users.noreply.github.com

Prompted by: dan

[decofe]

TIP-1042 Review

protocolVersion → T5

Frontmatter is missing protocolVersion. Should be T5.

Security / Correctness Issues

1. Exemption scope must be call-site-scoped, not address-wide. The spec correctly describes exempting FeeManager in the fee-collection path only and preserving checks on public AMM ops. But the implementation must be careful: if the exemption is implemented as "skip TIP-403 when msg.sender == FeeManager or to == FeeManager," it could accidentally exempt public-facing functions. The exemption should be gated on the specific internal code path (e.g., a flag or call context), not just address equality.

2. mint authorization check — single-sided mint clarification. The mint function accepts userToken and validatorToken but only transfers validatorToken. The new check treats mint as if the caller were transferring userToken to the pool. This is a good design, but:

   • If there are multiple mint overloads or paths (single-sided, dual-sided), specify which ones get the new check.
   • The check uses isAuthorizedSender(userTokenPolicyId, msg.sender) — this checks whether the caller can send userToken. But the caller isn't actually sending userToken. Make sure the semantic intent ("caller is opting into userToken ecosystem") is clear.

3. Stranded fees edge case is well-documented — validators setting their fee token to a non-whitelisted token will have uncollectable fees. Wallet/validator tooling should surface this. Good that it's called out.

4. Interaction with TIP-1033 (two-hop routing). If two-hop routing goes through an intermediate token, does the fee-collection exemption apply to both hops? The spec should confirm that the FeeManager TIP-403 exemption covers the intermediate transfer as well, since both hops occur within the fee-collection path.

Suggested changes

Add to frontmatter:

protocolVersion: T5