feat(lp-pool): automated storage TTL extension for active LP pool accounts - #897
Merged
Sadeequ merged 2 commits intoSep 2, 2026
Conversation
…ounts Adds a minimal, self-contained constant-product (x*y=k) two-asset liquidity pool contract (initialize/deposit/withdraw/swap + getters) whose sole purpose is to demonstrate and test issue StellarFlow-Network#768's requirement: active pool reserves and user share records must never drift into Soroban's archived storage state. - bump_pool_ttl / bump_user_ttl are called at the top of swap(), deposit(), and withdraw() — before any pool/user state is read — and extend the relevant persistent entries' TTL out to BUMP_AMOUNT whenever the remaining TTL drops below BUMP_THRESHOLD. Both are no-ops (zero extra cost) when an entry is already healthy. - 14 unit tests cover core AMM mechanics (deposit/withdraw/swap invariants, slippage, insufficient shares/liquidity, zero-amount and not-initialized guards) plus the TTL deliverable itself: entries that would have expired under the sandbox's default 4096-ledger TTL survive and stay usable because the contract proactively bumped them. Closes StellarFlow-Network#768
|
@milah-247 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
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
2 participants
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.
Closes #768
What
There was no LP pool contract in this repo yet, so this adds a minimal, self-contained constant-product (
x*y=k) two-asset pool atcontracts/lp-pool/(initialize/deposit/withdraw/swap+ read-only getters) — just enough surface area to meaningfully implement and test the issue's actual deliverable: active pool reserves and user share records must never drift into Soroban's archived storage state.How
bump_pool_ttl/bump_user_ttlrun at the top ofswap(),deposit(), andwithdraw()— before any pool/user state is read — and callextend_ttlon the relevant persistent entries whenever their remaining TTL drops belowBUMP_THRESHOLD(~30 days), extending out toBUMP_AMOUNT(~60 days). Both are no-ops (zero extra cost) when an entry is already healthy, per the issue's "zero disruption" requirement.Testing
cargo test -p lp-pool: 14/14 passing, covering core AMM correctness (deposit/withdraw/swap invariants, slippage guard, insufficient shares/liquidity, zero-amount and not-initialized guards) and the TTL deliverable itself — persistent entries that would have expired under the sandbox's default 4096-ledger TTL survive and stay fully usable because the contract proactively extends them.cargo build -p lp-pool --target wasm32-unknown-unknown --release: succeeds.Note: this workspace pins
soroban-sdk = "20.0.0"(resolving to 20.5.0/soroban-env-host 20.3.0). That generation's SDK has noget_ttlreader on persistent storage (added later), so the TTL tests prove the extension behaviorally — jumping the ledger to one tick before a never-bumped entry's TTL would expire and asserting the next call still succeeds — rather than by reading the raw counter.