Add holder-share-summation invariant test asserting set_holder_share total stays within 10000 bps per offering

[Jagadeeshftw]

Summary

Add holder-share-summation invariant test asserting set_holder_share total stays within 10000 bps per offering

Why this matters

set_holder_share and meta_set_holder_share enforce share_bps <= 10_000 per holder but do not enforce that the sum of all holder shares for an offering stays within 10000. An issuer could allocate >100% by accident, over-paying on claim. Add either an aggregate guard or a documented test asserting the invariant assumed by off-chain coordinators.

Scope

Implement the requested behavior across src/lib.rs. The solution must preserve existing compatibility, authorization, and production safeguards.

Priority

High

Acceptance criteria

• The requested behavior is implemented across src/lib.rs with a clear, reviewable contract.
• Security, authorization, validation, and data-integrity requirements in the repository context are enforced and covered by tests.
• Failure, retry, timeout, concurrency, and boundary behavior is explicit and produces safe, diagnosable outcomes where applicable.
• Regression coverage includes empty, invalid, duplicate, and boundary inputs relevant to this flow.
• Existing API, storage, and deployment compatibility is preserved unless a migration is explicitly documented.

Validation

Include focused tests for:

• happy paths;
• invalid input and authorization boundaries;
• concurrency, retries, or failure recovery;
• backward compatibility;
• relevant integration or contract behavior.

The implementation must pass the repository’s existing build, lint, test, and formatting checks (use cargo test --all where applicable).

Non-goals

• Typo-only, formatting-only, or documentation-only changes.
• Unrelated refactors or dependency upgrades.
• Weakening security, authorization, CI, or production safeguards.
• Changing public behavior outside this issue’s scope.

Contributor application

Before implementation, comment with:

1. relevant experience;
2. a concise implementation approach;
3. expected files or modules affected;
4. an estimate for opening the first PR.

Wait for maintainer assignment before coding.

PR requirements

Use a feature branch and include Closes #.

The PR must:

• address every acceptance criterion;
• link each criterion to code and tests;
• explain security and failure-mode handling;
• include meaningful regression coverage;
• document compatibility or migration considerations;
• pass the repository checks.

Reward-readiness

This is a substantive quality issue. Merge status does not guarantee reward eligibility; final evaluation is determined separately.

Implementation context

Description

set_holder_share and meta_set_holder_share enforce share_bps <= 10_000 per holder but do not enforce that the sum of all holder shares for an offering stays within 10000. An issuer could allocate >100% by accident, over-paying on claim. Add either an aggregate guard or a documented test asserting the invariant assumed by off-chain coordinators.

Requirements and context

• Must be secure, tested, and documented
• Should be efficient and easy to review
• Relevant code: src/lib.rs (set_holder_share, meta_set_holder_share, apply_snapshot_shares, HolderShare)
• If enforced on-chain, must read aggregate; if off-chain, must be a clear README invariant

Suggested execution

• Fork the repo and create a branch
• git checkout -b feat/holder-share-sum-invariant
• Implement changes
  • Decide: persist TotalShareBps(OfferingId) and reject set that exceeds 10000
  • Or document and add a test asserting current accept-all behavior
  • Update README and add unit tests for both branches
• Validate security and correctness assumptions

Test and commit

• Run tests
  • cargo test --all
• Cover edge cases
  • Sum equal to 10000, sum exceeding 10000, removing a holder to free bps
• Include test output and security notes

Example commit message

feat: enforce or test aggregate holder share bps invariant

Guidelines

• Minimum 95 percent test coverage
• Clear documentation
• Timeframe: 96 hours

[kosisochukwu1234]

@kosisochukwu1234 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello, I would love to take on this issue. I'm a software engineer with over 4 years experience. and i'm confident I can resolve this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @kosisochukwu1234 to this issue.

[drips-wave]

Congratulations, @kosisochukwu1234! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @kosisochukwu1234: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊