diff --git a/tip-4626.md b/tip-4626.md
index cb134e0..2dcfeaa 100644
--- a/tip-4626.md
+++ b/tip-4626.md
@@ -606,6 +606,10 @@ The only functions where the preferred rounding direction would be ambiguous are
 Although the `convertTo` functions should eliminate the need for any use of an TIP-4626 Vault's `decimals` variable, it is still strongly recommended to mirror
 the underlying token's `decimals` if at all possible, to eliminate possible sources of confusion and simplify integration across front-ends and for other off-chain users.
 
+**Share-inflation / first-depositor (donation) attack.** When a Vault is empty or nearly empty, an attacker can mint a tiny number of shares and then transfer assets directly into the Vault, inflating the share price so that subsequent depositors' deposits round down to zero shares and are absorbed by the attacker. The rounding rules above do not by themselves prevent this. Implementations SHOULD mitigate it — for example via the virtual shares/assets offset used by OpenZeppelin's ERC-4626 implementation, or by seeding a non-trivial initial deposit at Vault creation. The attack cost scales with the **Vault asset's** decimals, not the chain's native-coin precision: a 6-decimal asset (e.g. USDT) is simply the cheaper case, on any chain.
+
+**Decimal basis.** TRX and most TIP-20 stablecoins use 6 decimals, while other TIP-20 tokens may differ. Each function's denomination follows from the interface semantics — `deposit`/`withdraw` and the asset side of `convert`/`preview` are in the underlying asset's decimals; `mint`/`redeem` and the share side are in the Vault share's decimals. Vaults SHOULD document their decimal basis, and integrators SHOULD read `decimals()` from both the Vault and the underlying token rather than hardcoding a precision.
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](https://github.com/tronprotocol/tips/blob/master/LICENSE.md).