TRC-4626: the share-inflation mitigation note agreed in #840 is missing from the published spec

[BlackChar92]

Follow-up to the discussion in #840. There, the first-depositor / share-inflation (donation) attack was raised (@Sunny6889) and the conclusion (@yanghang8612) was to fold a non-normative implementation note — virtual shares/assets offset and initial-seeding as mitigations, plus decimal-basis guidance — into Security Considerations when graduating to Last Call, without changing the interface.

That note doesn't appear in the published tip-4626.md. The current Security Considerations cover malicious implementations, EOA slippage, preview-as-oracle manipulation, and rounding direction, but not the inflation/donation attack or its mitigation (no mention of inflation / donation / virtual shares / first-depositor / empty-vault).

This is worth closing because the rounding-down-to-favor-the-vault rule already in the spec does not by itself prevent the empty-vault donation attack — the mitigation is the virtual-shares offset or seeding, which the spec currently leaves implementers to rediscover (the exact outcome #840 set out to avoid).

Proposed addition to Security Considerations (non-normative, no interface change):

Share-inflation / first-depositor (donation) attack. When a vault is empty or near-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 deposits round down to zero shares and are absorbed by the attacker. Favorable rounding alone does not prevent this. Implementations SHOULD mitigate it, e.g. via a virtual shares/assets offset (as in OpenZeppelin's 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 decimals — a 6-decimal asset (e.g. USDT) is cheaper to attack than an 18-decimal one.

Happy to open a PR with this wording if useful.

[yanghang8612]

@BlackChar92 Good catch, and thanks for tracing it back to #840 rather than just the published text. You're right.

In the April 17 Last Call summary I said I'd fold two non-normative implementation notes into Security Considerations before Last Call — the share-inflation/donation mitigation and a decimal-basis guidance note — and neither actually made it into tip-4626.md. The interface, events, and rounding requirements were carried over from the draft as promised, but those two notes were dropped on the way in. So this is a real gap, not a wording nit.

Your proposed text matches the #840 consensus well: it stays non-normative, doesn't touch the interface, points at the virtual-shares/assets offset (OpenZeppelin) and initial seeding as the mitigations, and correctly frames the cost as scaling with the vault asset's decimals rather than any chain's native-coin precision — i.e. not TRON-specific; a 6-decimal asset like USDT is simply the cheaper case, on any chain. I'm happy to take it essentially as written.

A PR would be very welcome — please go ahead. Two small things for it:

• Since TRC-4626 is Final, please frame the PR as a non-normative clarification (Security Considerations only; no interface, event, or behavior change) so the editorial nature is clear to reviewers.
• If you're up for it, the same [Discussion] TRC-4626: Tokenized Vault Standard #840 summary promised a second note that also never landed: a short decimal-basis reminder for TRON (TRX and most TIP-20 stablecoins use 6 decimals while other tokens may differ; vaults should document their decimal basis, and integrators should read decimals() from both the vault and the underlying rather than hardcoding). Folding both into one PR would close the gap completely, but a separate follow-up is just as fine.

Thanks again.