Skip to content

Add is_settlement_expiry_configured FIX#240

Open
Mitch5000 wants to merge 1 commit into
AnchorNet-Org:mainfrom
Mitch5000:Add-is_settlement_expiry_configured-FIXED
Open

Add is_settlement_expiry_configured FIX#240
Mitch5000 wants to merge 1 commit into
AnchorNet-Org:mainfrom
Mitch5000:Add-is_settlement_expiry_configured-FIXED

Conversation

@Mitch5000

Copy link
Copy Markdown

Pull Request Title:
Add settlement expiry configuration status view

Pull Request Body:

Summary:
This PR adds a dedicated view for determining whether the settlement expiry window has ever been explicitly configured.

Previously, settlement_expiry_ledgers() returned 0 both when expiry was never configured and when an admin explicitly set expiry to 0. Since 0 means expiry is disabled, integrators had no way to distinguish between:

Expiry was never configured.
Expiry was explicitly configured to disabled.
This distinction matters for monitoring settlement liquidity risk, because never-configured expiry can indicate that settlement liquidity may become stuck without a reclaim path.

Changes Made:

Added has_settlement_expiry_ledgers(env) in src/storage.rs.

Checks instance storage for DataKey::SettlementExpiryLedgers.
Returns true if the key exists, including when the stored value is 0.
Added public contract view is_settlement_expiry_configured(env) -> bool in src/lib.rs.

Returns false only when settlement expiry has never been configured.
Returns true after any set_settlement_expiry_ledgers call, including set_settlement_expiry_ledgers(0).
Extended regression tests in src/test.rs.

Verifies the default never-configured state returns false.
Verifies explicit set_settlement_expiry_ledgers(0) returns true.
Confirms settlement_expiry_ledgers() still returns 0 in both disabled cases.
Confirms cancel_expired_settlement still rejects with SettlementNotExpired when expiry is disabled.
Confirms is_settlement_expired still returns false when expiry is disabled.
Behavior Before:

settlement_expiry_ledgers() returned 0 when expiry was never configured.
settlement_expiry_ledgers() also returned 0 after an admin explicitly disabled expiry.
There was no way to distinguish those two states.
Behavior After:

settlement_expiry_ledgers() behavior is unchanged.
is_settlement_expiry_configured() returns false before configuration.
is_settlement_expiry_configured() returns true after explicit set_settlement_expiry_ledgers(0).
cancel_expired_settlement behavior is unchanged.
is_settlement_expired behavior is unchanged.
Acceptance Criteria:

is_settlement_expiry_configured() is false before any set_settlement_expiry_ledgers call.
is_settlement_expiry_configured() is true after set_settlement_expiry_ledgers(0).
cancel_expired_settlement behavior is unchanged.
is_settlement_expired behavior is unchanged.
Validation:

Ran git diff --check successfully.

Attempted cargo build.

Build is currently blocked by an existing unrelated contract export issue in the repository:

contract function name is too long: 36, max is 32
src/lib.rs:1043
pub fn list_settlements_by_anchor_and_asset(...)

The newly added function is_settlement_expiry_configured is 31 characters long, which is within Soroban’s 32-character contract function name limit.

Files Modified:

src/storage.rs
src/lib.rs
src/test.rs
Files Created:

None
Security Impact:
This improves observability for integrators and anchors by allowing them to detect whether expiry has never been configured. That helps surface settlement liquidity lockup risk before it becomes an operational or support issue.

Risk:
Low. The change only adds a presence-check accessor and a read-only public view. Existing settlement expiry behavior remains unchanged.

Closes #110

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add is_settlement_expiry_configured() distinguishing an explicit zero window from one never set

1 participant