State the pool share trustline two-reserve exception on the Lumens and Accounts pages - #2844
Open
kaankacar wants to merge 2 commits into
Open
State the pool share trustline two-reserve exception on the Lumens and Accounts pages#2844kaankacar wants to merge 2 commits into
kaankacar wants to merge 2 commits into
Conversation
…d Accounts pages A pool share trustline counts as two subentries and needs two base reserves. The Liquidity Pools page says so, but the general Lumens and Accounts pages grouped pool shares with ordinary trustlines, so a reader sizing a minimum balance from those pages undercounts by one reserve. CAP-0038 specifies the rule, and stellar-core implements it in computeMultiplier (SponsorshipUtils.cpp) and calculateDelta (AccountSubEntriesCountIsValid.cpp), which also confirms the entry counts twice toward the 1,000 subentry cap.
A claimable balance with one claimant costs one base reserve, which is
0.5 XLM, not 1 XLM. The claimable-balances guide states the rule ('each
claimant in that entry increases the source account's minimum balance by
one base reserve') and stellar-core computeMultiplier returns
claimants.size() for a CLAIMABLE_BALANCE entry. The example total is
therefore 3 XLM.
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the Stellar “Lumens” and “Accounts” fundamentals docs to explicitly call out that pool share trustlines count as two subentries (and therefore require two base reserves) and adds a direct link to the Liquidity Pools page’s Trustlines section for details.
Changes:
- Split the Accounts “subentries” list to distinguish traditional-asset trustlines (1 subentry) vs pool-share trustlines (2 subentries).
- Add a pool-share trustline reserve/subentry exception note on both the Accounts and Lumens pages, linking to Liquidity Pools → Trustlines.
Recommendation: MERGE-READY — the change is accurate and complete; only minor wording clarity nits noted in review comments.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| docs/learn/fundamentals/stellar-data-structures/accounts.mdx | Clarifies subentry counting for pool-share trustlines and links to Liquidity Pools for more detail. |
| docs/learn/fundamentals/lumens.mdx | Adds the pool-share trustline two-subentry/two-reserve exception to the minimum-balance explanation with a cross-link. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| ## Minimum balance | ||
|
|
||
| Stellar accounts must maintain a minimum balance to exist, which is calculated using the base reserve. An account must always maintain a minimum balance of two base reserves (currently 1 XLM). Every subentry after that requires an additional base reserve (currently 0.5 XLM) and increases the account’s minimum balance. Subentries include trustlines (for both traditional assets and pool shares), offers, signers, and data entries. An account cannot have more than 1,000 subentries. | ||
| Stellar accounts must maintain a minimum balance to exist, which is calculated using the base reserve. An account must always maintain a minimum balance of two base reserves (currently 1 XLM). Every subentry after that requires an additional base reserve (currently 0.5 XLM) and increases the account’s minimum balance. Subentries include trustlines (for both traditional assets and pool shares), offers, signers, and data entries. A pool share trustline is the one exception: it counts as two subentries, so it requires two base reserves (currently 1 XLM) instead of one. Learn more in the [Liquidity Pools section](./liquidity-on-stellar-sdex-liquidity-pools.mdx#trustlines). An account cannot have more than 1,000 subentries. |
| - Additional signers | ||
| - Data entries (includes data made with the `manageData` operation, not smart contract ledger entries) | ||
|
|
||
| A pool share trustline is the one exception to the rule above: it counts as two subentries, so it requires two base reserves (currently 1 XLM) and it counts twice toward the 1,000 subentry limit. Learn more in the [Liquidity Pools section](../liquidity-on-stellar-sdex-liquidity-pools.mdx#trustlines). |
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (2)
Previously missed (1) — in code that hasn't changed since the last review.
docs/learn/fundamentals/lumens.mdx:30
- The pool-share trustline note explains the reserve multiplier, but it doesn’t mention that pool-share trustlines also count as two subentries toward the 1,000-subentry cap (the paragraph immediately states the cap). Adding that detail here avoids leaving a subtle inconsistency on this page.
docs/learn/fundamentals/stellar-data-structures/accounts.mdx:52
- This sentence calls pool share trustlines “the one exception to the rule above,” but the preceding bullets already define pool share trustlines as two subentries each, and the “each subentry increases… by one base reserve” rule still holds. Rephrasing to state the fact directly avoids the impression that the rule is being contradicted.
A pool share trustline is the one exception to the rule above: it counts as two subentries, so it requires two base reserves (currently 1 XLM) and it counts twice toward the 1,000 subentry limit. Learn more in the [Liquidity Pools section](../liquidity-on-stellar-sdex-liquidity-pools.mdx#trustlines).
Contributor
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.
🤖 Automated triage bot, acting for @kaankacar.
Closes #2842.
The Lumens and Accounts pages listed pool share trustlines with ordinary trustlines as one subentry each. A pool share trustline counts as two subentries and needs two base reserves. This adds the exception to both pages and links the Liquidity Pools section.
Verification:
computeMultiplier(SponsorshipUtils.cpp) returns 2 for aASSET_TYPE_POOL_SHAREtrustline and 1 for other trustlines.calculateDelta(invariant/AccountSubEntriesCountIsValid.cpp) adds 2 tonumSubEntriesfor a pool share trustline, so the entry also counts twice toward the 1,000 subentry cap.#trustlinesanchor is the only Trustlines heading on the Liquidity Pools page.Second commit: an arithmetic defect in the same section
The minimum balance example on the Lumens page charged 1 XLM for a claimable balance with one claimant, and totalled 3.5 XLM. One claimant costs one base reserve, which is 0.5 XLM, so the total is 3 XLM. Sources:
computeMultiplierreturnsclaimants.size()for aCLAIMABLE_BALANCEentry.I found this while verifying #2842 and no open issue covers it. It sits three lines below the new text, so leaving it would ship a wrong number beside a reserve correction. Happy to split it into its own PR if you prefer.
🤖 Generated with Claude Code