Cowrie Research

meaningful-share-mint-guarantee-and-capitalization-table-fairness

10 min read

Meaningful-Share Mint Guarantee and Capitalization-Table Fairness

  • Name: meaningful-share mint guarantee and capitalization-table fairness
  • Category: vault reference / bootstrap-fairness checklist / zero-share-deposit prevention note / share-accounting companion
  • Summary: Share systems should not be satisfied merely because mint math is internally consistent. The stronger invariant is that a nonzero honest contribution must either receive a meaningful ownership claim or be rejected. This note exists for the positive-design question behind first-deposit inflation, zero-share victimization, and some low-supply replay bugs: how a vault should preserve capitalization-table fairness when the denominator is tiny, unsolicited assets can move totalAssets, and rounding can quietly turn a real deposit into a donation to someone else’s shares.
  • Why this note exists:
    • first-deposit-inflation preserves the negative family clearly, but the reusable design target deserves its own control-surface note.
    • Teams often remember revert on zero shares as a patch, then forget the broader invariant: how much ownership should this deposit be entitled to under adversarial low-supply state, and who was allowed to author that state?
    • The useful review shape is not just can this deposit mint zero shares? but what exactly guarantees capitalization-table fairness before later users are asked to fund it?

The core design rule

A nonzero honest deposit must not be allowed to fund a capitalization table it is not meaningfully allowed to join.

That rule is stronger than shares > 0, because tiny-but-economically-fraudulent share outputs can still preserve the same theft shape. Healthy systems keep four facts separate:

  • low-supply state exists
  • the protocol published one share-pricing answer for that state
  • a user was allowed to transfer assets under that answer
  • the resulting ownership outcome was considered fair enough to keep

The four fairness questions healthy share systems should keep separate

  1. Did the user transfer real value in?

    • This is the asset-movement fact: tokens or underlying value entered the vault.
    • It does not yet prove the user joined the ownership structure fairly.

  2. Did the protocol publish one capitalization answer for that moment?

    • previewDeposit, convertToShares, bootstrap mint logic, or runtime low-supply math may produce a canonical-looking share quote.
    • That is already a stronger claim than assets arrived: the protocol has authored one ownership answer.

  3. Did the user receive a meaningful ownership claim under that answer?

    • This is the fairness question. shares > 0 is not always enough if floor rounding leaves the user with dust that is economically equivalent to donating assets to existing holders.
    • The meaningful threshold depends on asset decimals, expected deposit sizes, minimum position policies, and downstream rights attached to the share.

  4. May downstream systems now trust that ownership answer as money-good?

    • Redemption, collateral admission, reward entitlement, and routing systems may later honor the resulting shares as ordinary authority.
    • That is stronger again, and should not be automatic just because one local mint path succeeded.

Three promotions reviewers should not collapse

  1. A low-supply share price exists

    • The vault can print a number.
    • That is not yet a fairness guarantee.

  2. This low-supply share price is canonical enough to mint against

    • The protocol decided one depositor may now pay in under that capitalization table.
    • This is where many systems already over-trust attacker-authored state.

  3. The resulting share allocation is fair enough to keep and reuse elsewhere

    • The protocol accepted the ownership outcome as legitimate for redemptions, rewards, transferability, and collateral.
    • This is the strongest claim and should usually have the strictest boundary.

What sound design looks like

  • The protocol defines fairness as an execution-time invariant, not a UI expectation. The real question is whether the deposit joins the capitalization table on acceptable terms at the exact state transition that moves assets.
  • A vault has an explicit minimum economic ownership rule. If minted shares would be zero or economically meaningless, the transaction reverts instead of quietly socializing the deposit to existing holders.
  • The threshold is calibrated to the actual system, not to algebraic convenience. Asset decimals, share decimals, expected minimum deposits, and downstream uses of the share all inform what counts as meaningful ownership.
  • Bootstrap and low-supply states are made expensive to dominate. Virtual offsets, dead shares, seeded minimum liquidity, or explicit warmup phases ensure one attacker cannot cheaply define the ownership terms later users must inherit.
  • Share-pricing answers are not allowed to become canonical merely because raw balance changed. Donations, reward syncs, rebases, rescue transfers, and strategy-side gains either pass through explicit recognition logic or remain excluded from mint fairness.
  • If the system revisits low supply later, it does not silently reuse launch semantics. Recovery, reseeding, or recapitalization routes should establish fresh fairness conditions before ordinary users are asked to deposit again.
  • Downstream consumers trust the result later than the local mint path does. Even after a vault decides a deposit was fair enough to mint, collateral admission and same-thesis leverage rails may still deserve slower or narrower trust.

Useful positive design shapes

1. Hard zero-share rejection

  • Revert whenever assets > 0 would mint 0 shares.
  • This is the minimum acceptable floor, not the full design.
  • It prevents the purest donation-by-deposit outcome but does not alone solve dust-share victimization.

2. Minimum meaningful-share thresholds

  • Require minted shares to exceed a protocol-defined floor tied to economic significance, not merely integer nonzeroness.
  • This is especially important when share decimals or asset decimals make 1 share unit economically negligible.
  • The right question is would this depositor actually become an owner in a meaningful sense?

3. Permanent anti-domination seed state

  • Use dead shares, virtual offsets, or nonredeemable seed liquidity that survives runtime adversity.
  • The goal is not only to stop zero-share outputs, but to make it expensive for one dust actor to dictate everyone else’s future entry price.

4. Donation-neutral mint accounting

  • Keep managed assets used for mint fairness separate from raw token balance whenever the design can support it.
  • If unsolicited assets do count, prove they still cannot make the next honest depositor fund someone else’s shares unfairly.

5. Low-supply degraded mode

  • If supply falls back toward dust, pause or restrict ordinary deposits until the capitalization table is safe again.
  • Healthy systems treat low supply again as a fairness-risk state, not as ordinary operation with smaller numbers.

Design questions worth asking first

  • What exact invariant defines a fair deposit in this vault: nonzero shares, minimum ownership percentage, minimum share count, or some stronger user-value threshold?
  • Can a first depositor or residual dust holder cheaply author the share price the next user must accept?
  • Which raw-balance or reward-recognition paths can change mint pricing without minting proportional shares?
  • Is fairness checked only in previews, or enforced at the execution edge where assets actually move?
  • If a deposit would mint dust shares rather than zero, what makes that economically acceptable?
  • Can the vault revisit low-supply states later through burns, migrations, emergency exits, claims, or debt socialization?
  • After a deposit passes the local fairness check, which downstream systems immediately trust the resulting shares as ordinary money-good authority?

Red flags that usually mean fairness is underspecified

  • We revert on zero shares, so bootstrap is solved
  • The first real user can always just deposit more
  • Shares are technically nonzero when the output is economically meaningless
  • previewDeposit looked fine even though direct transfers or sync paths can move state before execution
  • totalAssets reads raw balance and the team assumes direct transfers are harmless
  • The vault is old, so bootstrap fairness no longer matters
  • Collateral admission is separate when the same unfairly minted shares are still later trusted downstream

Failure-prevention checklist

  • Enforce a fairness rule at execution time: nonzero deposits must mint zero-reverting or economically meaningful shares under current state.
  • Define what meaningful means for this vault and test it against realistic asset decimals, share decimals, and minimum expected user sizes.
  • Add permanent anti-domination structure: virtual offsets, dead shares, nonredeemable seed liquidity, or equivalent supply-floor design.
  • Keep unsolicited donations, reward syncs, and rescued balances from silently rewriting mint fairness unless that effect is explicitly intended and bounded.
  • Re-test fairness after every path that can thin supply or reshape capitalization: claims, burns, migrations, bad-debt handling, recapitalization, emergency exits, and admin recovery flows.
  • Treat low-supply runtime as a special operating mode with stricter deposit, preview, and collateral-admission policy.
  • Keep preview functions and execution paths aligned under adversarial pre-sends and same-block state changes.
  • Delay downstream trust when appropriate: shares minted under fresh or low-supply conditions should not automatically become unrestricted collateral or recursive leverage input.
  • Monitor for assets high / supply tiny states and for deposits landing near minimum-share thresholds; those are production signals that fairness is becoming attacker-shapable.
  • Document the operator response for fairness failure: pause deposits, quarantine donations, reseed, or force explicit recapitalization.

Audit prompts

  • Starting from the smallest reachable supply state, what is the smallest honest deposit that would still mint economically meaningful ownership?
  • Which functions can move totalAssets or equivalent mint numerator without creating matching shares?
  • Does the contract treat shares > 0 as sufficient, or is there a stronger fairness threshold?
  • Can a direct transfer, reward sync, rebase, or strategy update make previewDeposit stale relative to deposit execution in the same user flow?
  • What exact seed, virtual offset, or dead-share amount is required to make domination uneconomic for the relevant asset?
  • If supply later returns to dust, what prevents ordinary users from becoming the recapitalization path for an attacker-authored table?
  • Are there any governance, admin, or migration paths that can remove the permanent anti-domination floor?
  • Once shares are minted under low-supply conditions, where else in the protocol are they immediately honored: redemption, rewards, collateral, liquidation, transfer-time entitlement, or routing?
  • In the worst reachable state, how much value can one honest depositor lose while still technically receiving > 0 shares?

Lessons that should already be standard

  • Shares minted is not the same thing as fair ownership received.
  • Zero-share reverts are necessary but not always sufficient; dust-share victimization can preserve the same theft shape.
  • Bootstrap fairness is an execution invariant, not a frontend warning.
  • A capitalization table can be mathematically consistent and still economically fraudulent.
  • Whoever controls the low-supply denominator often controls whether later users are joining the vault or funding someone else’s position.
  • Donation neutrality and fairness are the same security conversation once raw balances influence mint pricing.
  • Low-supply fairness is not only a launch issue. Recovery, migration, and depletion events can reopen it long after deployment.
  • If the protocol cannot explain what amount of ownership a depositor is guaranteed to receive, it probably has not specified the real invariant tightly enough.

How to use this note with the exploit corpus

High-signal cases

  • GoGoPool ggAVAX is the clean first depositor + donation + reward sync reminder that a later honest depositor can be forced to fund a table they do not meaningfully join.
  • OpenZeppelin’s ERC-4626 inflation-attack writeup remains the canonical worked example of the same fairness failure in its purest form.
  • Yearn yETH is the stronger lifecycle reminder that once low-supply replay exists, fairness is not just a launch problem.
  • ResupplyFi is the useful contrast where unfair low-supply share economics later graduate into broader collateral failure.

Internal linkages

Control surface

Graph View

Backlinks