Description
supply_cap is currently a bps abstraction. Some offerings need a hard share-unit cap (e.g. 10_000 shares). Add max_total_supply_shares: i128 enforced when minting or assigning shares so an upper bound exists independent of BPS allocation.
Requirements and context
- Must be secure, tested, and documented
- Should be efficient and easy to review
- Relevant code:
Revora-Contracts/src/lib.rs
- Must coexist with
supply_cap BPS without conflict
Suggested execution
- Fork the repo and create a branch
git checkout -b feat/max-total-supply-shares- Implement changes
- Add
max_total_supply_shares field to offering config
- Reject
set_holder_share increases that would push total > max
- Document migration default
None
- Validate security and correctness assumptions
Test and commit
- Run tests
- Cover edge cases
- max == 0 must disable issuance entirely until set
- Include test output and security notes
Example commit message
feat: add max_total_supply_shares hard cap independent of bps
Guidelines
- Minimum 95 percent test coverage
- Clear documentation
- Timeframe: 96 hours
Description
supply_capis currently a bps abstraction. Some offerings need a hard share-unit cap (e.g. 10_000 shares). Addmax_total_supply_shares: i128enforced when minting or assigning shares so an upper bound exists independent of BPS allocation.Requirements and context
Revora-Contracts/src/lib.rssupply_capBPS without conflictSuggested execution
git checkout -b feat/max-total-supply-sharesmax_total_supply_sharesfield to offering configset_holder_shareincreases that would push total > maxNoneTest and commit
cargo test --allExample commit message
feat: add max_total_supply_shares hard cap independent of bpsGuidelines