# What distinguishes compounding fee bases when fee cascades are percentage-of-percentage?

**Date of Record:** 2026 November 2

**Scope:** Applies to fee structures where multiple percentage fees are stacked (advisory fee on principal, performance fee on gains, transaction fee on trade value, administration fee on assets under management) and each fee's base may or may not include fees already charged. Does not apply to flat-fee structures or single-fee structures.

## Core Distinction

The distinction is between **fee base = principal only** and **fee base = principal + accumulated fees**. Both are legitimate; they produce different totals. A fee structure that does not state its base is ambiguous, and the parties can apply different bases and both be correct.

**Invariant.** The cascade is agreed if and only if for every fee `f_i`, the base `B_i` is explicitly one of `{principal_only, principal_plus_prior_fees, gross_of_all_fees}`, and the same base is used on both sides.

**Violation.** The **Compounding Base Ambiguity**. An advisory fee of 1% and a performance fee of 20%. If the performance fee is 20% of gains net of the advisory fee, it is smaller than 20% of gains gross of the advisory fee. Neither is wrong — the bases differ. On a $100M principal with $10M gains, the difference is $20K on the performance fee alone.

**Asymmetry.** Each fee computation is internally consistent given its base. The total is the sum of two correct figures computed on different bases. The difference is not an error in any computation — it is an error in agreement.

**Recorded elements.** The `fee-cascade-receipt` (each fee's percentage), the `fee-base-signature` (each fee's base, per the taxonomy), and the `cascade-order-receipt` (the order in which fees are applied, which determines which prior fees enter which base) together make the cascade unambiguous.

## What Was Observed

**Signature.** Total fees differing between parties by an amount that scales with the number of fee layers. Each individual fee computation is checked and correct. The discrepancy appears only at the total, and it correlates with the number of stacked percentage fees, not with any single fee.

**Trace.** Principal $100M. Advisory fee 1% → $1M. Gains $10M. Performance fee 20%. If performance fee is on gains gross of advisory: $2M. If net of advisory: 20% × ($10M − $1M × gains_attribution) — the specific attribution rule matters, and both parties apply a "reasonable" rule. Total fees differ by $100K to $200K depending on the base attribution.

**Why monitoring stays green.** Each fee computes without error. The total is a valid sum. The divergence exists only in the base selection, which is not part of any single computation.

## Condition of Validity

The instance must ensure at least one holds before it treats a fee cascade as agreed:

1. **Must state the base per fee.** Every fee in the cascade states its base explicitly, from the taxonomy `{principal_only, principal_plus_prior_fees, gross_of_all_fees}`; "fees are deducted from gains" is not sufficient.
2. **Must state the cascade order.** The order in which fees apply is stated, because it determines which prior fees enter which base.
3. **Must state attribution for partial bases.** Where a fee base is a fraction of gains or a specific attribution, the attribution rule is stated.

## Decision Boundary

- Every fee base explicit, cascade order explicit: agreed.
- Bases explicit, cascade order not: partially agreed; the total is order-dependent and the parties may apply different orders.
- Bases not explicit: not agreed; each party applies its own reasonable interpretation.
- Cascade has only one fee: no ambiguity; base selection is irrelevant to the cascade.

## Operational Effect

The invariant couples the sum of percentage fees to a base selection that is often implicit. The instance's correct posture is to state each fee's base and the cascade order at contract execution, and to compute against the stated bases, not against reasonable defaults.

**Trap.** Compute performance fees net of advisory fees because it is "fairer". Fairer is a judgment. The correct base is the one stated in the contract; absent a stated base, the parties must agree, not apply fair defaults unilaterally.

```python
from dataclasses import dataclass, field
from typing import Dict


class CompoundingBaseError(RuntimeError):
    """Raised when a fee cascade has an unspecified or mismatched fee base."""


VALID_BASES = ("principal_only", "principal_plus_prior_fees", "gross_of_all_fees")


@dataclass(frozen=True)
class FeeCascadeGate:
    instance_bases: Dict[str, str]
    counterparty_bases: Dict[str, str]

    def verify(self) -> bool:
        if set(self.instance_bases.keys()) != set(self.counterparty_bases.keys()):
            raise CompoundingBaseError(
                "fee sets differ between instance and counterparty"
            )
        for fee, base in self.instance_bases.items():
            if base not in VALID_BASES:
                raise CompoundingBaseError(
                    f"fee {fee!r} has invalid base {base!r}: must be one of {VALID_BASES}"
                )
            if self.counterparty_bases[fee] != base:
                raise CompoundingBaseError(
                    f"fee {fee!r} base mismatch instance={base} "
                    f"counterparty={self.counterparty_bases[fee]}"
                )
        return True


def dispatch_fee_mode(gate: FeeCascadeGate) -> str:
    try:
        gate.verify()
    except CompoundingBaseError:
        return "state-bases-before-settlement"
    return "compute-cascade"
```