Add per developer min stake#606
Merged
greatest0fallt1me merged 4 commits intoJun 29, 2026
Merged
Conversation
feat: per-developer min stake
Contributor
Author
|
Done with this issue. |
- Modularize contract into logical components (admin, errors, types, etc.) - Add multi-token support to developer balances and withdrawals - Fix extensive compilation and test failures across the settlement crate - Transition to a modular test suite for better maintainability and coverage Co-authored-by: gloskull <189399494+gloskull@users.noreply.github.com>
…21205794558348 Fix settlement contract CI failures and implement multi-asset support
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Enforce an admin-configurable per-developer minimum accrued balance so developers must reach a configurable threshold before withdraw_developer_balance settles a claim.
Provide admin APIs to configure and inspect per-developer minimums and ensure the change is auditable and TTL-managed like other persistent entries.
Description
Added a new StorageKey::DeveloperMinBalance(Address) slot and a typed error SettlementError::MinimumBalanceRequired to the settlement contract interface.
Implemented a limits helper module (contracts/settlement/src/limits.rs) with set_developer_min_balance, get_developer_min_balance, and require_developer_min_balance that store values with a TTL and perform an admin auth check and validation.
Enforced the per-developer minimum inside withdraw_developer_balance by calling limits::require_developer_min_balance before token transfer or balance mutation.
Exposed public entrypoints set_minimum_balance(env, caller, developer, min_balance) and get_minimum_balance(env, developer) in the settlement API and documented the visible API change in UPGRADE.md.
Added focused tests covering: below-threshold rejection (test_minimum_balance_blocks_claim_until_threshold_met), at-threshold success (test_minimum_balance_allows_claim_at_threshold), and unauthorized configuration rejection (test_set_minimum_balance_rejects_unauthorized_caller).
Testing
Ran rustfmt/rustfmt on the modified settlement files successfully to keep style consistent for the change.
Attempted cargo test -p callora-settlement --lib and cargo test -p callora-settlement test_minimum_balance --lib, but the test run failed because the crate currently contains pre-existing compile issues outside this change (duplicate get_storage_ttl/spec symbols, missing migration/TTL types and several API/signature mismatches) that prevent executing the new tests; these failures are unrelated to the new minimum-stake logic.
cargo fmt --all could not complete due to existing syntax errors in unrelated contracts/vault/src/test.rs, so the full repo format/test sweep was not possible in this run.
If you want, I can: (1) isolate and run only the new settlement tests after the unrelated compile/test failures are resolved, (2) adjust numeric error discriminant if a different stable code is required, or (3) prepare a follow-up PR to address the unrelated compile issues so the new tests can run end-to-end.
Closes #560