Skip to content

fix(forge-vesting-factory): add TTL extension calls for all persisten…#525

Merged
Austinaminu2 merged 2 commits into
Austinaminu2:mainfrom
Akashi099:fix/499-ttl-extension-vesting-factory
Apr 28, 2026
Merged

fix(forge-vesting-factory): add TTL extension calls for all persisten…#525
Austinaminu2 merged 2 commits into
Austinaminu2:mainfrom
Akashi099:fix/499-ttl-extension-vesting-factory

Conversation

@Akashi099
Copy link
Copy Markdown

…t storage entries

Persistent storage entries on Stellar expire after ~30 days without a TTL bump. Without extend_ttl calls, a beneficiary who does not interact with their schedule for 30 days would find their vesting data expired, causing claim() to return ScheduleNotFound and locking their tokens forever.

Changes:

  • extend_ttl for DataKey::Schedule(id) in create_schedule(), claim(), cancel()
  • extend_ttl for DataKey::Claimed(id) in claim() and cancel()
  • extend_ttl for DataKey::ScheduleCount in create_schedule()
  • extend_ttl for DataKey::VestedAtCancel(id) in cancel()
  • All bumps use (17280, 34560) ledgers to match forge-governor, forge-multisig, forge-stream
  • Document TTL strategy in factory README

Closes #499

Summary

[Provide a clear and concise summary of the changes made in this PR]

Related issue

[Link to the issue, e.g., #123]

Related Issue

[Link to the issue this PR addresses, e.g. Closes #123]

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update

Testing

Tests Performed

[Describe the tests you ran to verify your changes. Include:

  • Unit tests run
  • Integration tests performed
  • Manual testing steps
  • Any specific scenarios tested]

Test Results

[All tests should pass. Include any test output or screenshots if relevant]

Checklist

  • My code follows the project's style guidelines
  • I have run cargo fmt to format the code
  • I have run cargo clippy to lint the code
  • All new and existing tests pass locally
  • I have added necessary documentation (if applicable)
  • I have updated the CHANGELOG.md (if applicable)
  • I have labeled this PR appropriately (e.g., 'good first issue', 'documentation', 'bug')
  • I have requested review from the appropriate maintainers

Additional Notes

[Any additional context, screenshots, or information that reviewers should be aware of]

Soroban Pulse Dev and others added 2 commits April 27, 2026 19:12
…t storage entries

Persistent storage entries on Stellar expire after ~30 days without a TTL
bump. Without extend_ttl calls, a beneficiary who does not interact with
their schedule for 30 days would find their vesting data expired, causing
claim() to return ScheduleNotFound and locking their tokens forever.

Changes:
- extend_ttl for DataKey::Schedule(id) in create_schedule(), claim(), cancel()
- extend_ttl for DataKey::Claimed(id) in claim() and cancel()
- extend_ttl for DataKey::ScheduleCount in create_schedule()
- extend_ttl for DataKey::VestedAtCancel(id) in cancel()
- All bumps use (17280, 34560) ledgers to match forge-governor, forge-multisig, forge-stream
- Document TTL strategy in factory README

Closes Austinaminu2#499
@Austinaminu2 Austinaminu2 merged commit 83f563e into Austinaminu2:main Apr 28, 2026
1 check failed
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.

forge-vesting-factory has no TTL extension calls — all storage entries will expire silently

2 participants