Hey, was reading through the RWA tokenization contracts and noticed the dividend distribution isn't actually snapshot-based despite the field being there for it. Both RwaToken::claim_dividend and the standalone dividend-distributor contract record a snapshot_ledger on DividendDistribution/DistributionRound when a round is created, but neither ever reads it back. The pro-rata share is computed from get_balance(&env, &investor) (or invoke_token_balance in the standalone contract) at claim time, i.e. the investor's current live balance, not their balance at snapshot_ledger.
Practically that means an investor who buys (compliant, whitelisted) tokens after a dividend round opens but before claiming can pull a larger pro-rata share than they were actually entitled to at snapshot time, and an investor who sold their tokens after the round opened but before claiming gets zero (claim_dividend panics on balance == 0) even if they held the full position at snapshot. Since both contracts independently hit the same pattern, seemed worth flagging as a design gap rather than a one-off typo.
Is snapshotting balances (a stored balance-at-snapshot per holder, captured at distribute_dividend/create_distribution time) planned before this goes past testnet, or is unrestricted post-snapshot trading intentionally allowed for now?
Solid compliance layering otherwise, the KYC hook/investor registry/holding-limit stack composing cleanly through do_compliance_checks made the contract easy to reason about.
I deal with a similar "which balance actually backs this payout, live or historical" question building payout logic for a cross-chain vault on Chainlink CCIP (https://github.com/aegonmyy/meridian). Happy to compare notes if useful.
Hey, was reading through the RWA tokenization contracts and noticed the dividend distribution isn't actually snapshot-based despite the field being there for it. Both
RwaToken::claim_dividendand the standalonedividend-distributorcontract record asnapshot_ledgeronDividendDistribution/DistributionRoundwhen a round is created, but neither ever reads it back. The pro-rata share is computed fromget_balance(&env, &investor)(orinvoke_token_balancein the standalone contract) at claim time, i.e. the investor's current live balance, not their balance atsnapshot_ledger.Practically that means an investor who buys (compliant, whitelisted) tokens after a dividend round opens but before claiming can pull a larger pro-rata share than they were actually entitled to at snapshot time, and an investor who sold their tokens after the round opened but before claiming gets zero (
claim_dividendpanics onbalance == 0) even if they held the full position at snapshot. Since both contracts independently hit the same pattern, seemed worth flagging as a design gap rather than a one-off typo.Is snapshotting balances (a stored balance-at-snapshot per holder, captured at
distribute_dividend/create_distributiontime) planned before this goes past testnet, or is unrestricted post-snapshot trading intentionally allowed for now?Solid compliance layering otherwise, the KYC hook/investor registry/holding-limit stack composing cleanly through
do_compliance_checksmade the contract easy to reason about.I deal with a similar "which balance actually backs this payout, live or historical" question building payout logic for a cross-chain vault on Chainlink CCIP (https://github.com/aegonmyy/meridian). Happy to compare notes if useful.