State the pool share trustline two-reserve exception on the Lumens and Accounts pages

[kaankacar]

🤖 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:

• CAP-0038 states the pool share trust line counts as two subentries and needs two base reserves.
• stellar-core computeMultiplier (SponsorshipUtils.cpp) returns 2 for a ASSET_TYPE_POOL_SHARE trustline and 1 for other trustlines.
• stellar-core calculateDelta (invariant/AccountSubEntriesCountIsValid.cpp) adds 2 to numSubEntries for a pool share trustline, so the entry also counts twice toward the 1,000 subentry cap.
• The #trustlines anchor is the only Trustlines heading on the Liquidity Pools page.
• No new page, so routes.txt and redirects.conf need no change.

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:

• The Claimable Balances guide says each claimant increases the source account's minimum balance by one base reserve.
• stellar-core computeMultiplier returns claimants.size() for a CLAIMABLE_BALANCE entry.

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

[Copilot]

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.

[Copilot]

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).

[github-actions]

PR Preview: https://developers-pr-2844.previews.kube001.services.stellar-ops.com

[ElliotFriend]

Thanks for this, and thanks especially for the sourcing in the description. I checked the substance before the wording, and it holds up:

• CAP-0038 says it outright: "The pool share trust line should count as two subentries (and therefore require two base reserves)."
• computeMultiplier in SponsorshipUtils.cpp returns 2 for an ASSET_TYPE_POOL_SHARE trustline, and that multiplier is what gets added to numSubEntries, so the "counts twice toward the 1,000 cap" claim checks out as well.
• The claimable balance correction in the second commit is right. One claimant is one base reserve (0.5 XLM), so 3 XLM is the correct total. Our own Claimable Balances guide already said as much, which means the old 3.5 XLM had been contradicting a sibling page. Good catch, and keeping it here was the right call rather than splitting it out, since it sits three lines from the text you were already correcting.

Two wording suggestions inline. Both are about the word "exception", which Copilot also flagged and I think it had the right instinct on. Neither blocks merge.

One note on Copilot's other suggestion, that we drop the derived XLM amounts because the base reserve can drift: I would skip that one. Both pages gloss every figure as "currently 0.5 XLM" or "currently 1 XLM", and this page notes a few lines up that validators can vote to change the base reserve. That "currently" hedge is how we handle drift here, so dropping the gloss on just this one sentence would make it the odd one out.

Separately, and explicitly not for this PR: the same one-per-entry assumption is still stated as fact in the Hubble data dictionary. bronze/accounts.mdx says "Any newly created trustline, offer, signer or data entry will increase the number of subentries by 1", and silver/accounts-snapshot.mdx describes num_subentries the same way. I am filing that as a follow-up so this PR can stay scoped and close #2842 cleanly.

[ElliotFriend]

Agreeing with Copilot here. "The one exception" has no antecedent in this paragraph, because nothing before it establishes that a trustline normally counts as one subentry. The parenthetical "(for both traditional assets and pool shares)" also ends up fighting the sentence that immediately qualifies it.

This version states the counting rule directly, folds the 1,000 cap in ahead of it so that "counts as two" implies two against the cap without repeating the number, and drops the now redundant parenthetical since the following clause names pool shares anyway.

It also picks up the point Copilot raised and then suppressed, that this page states the cap but never said a pool share trustline consumes two of it.

Suggested change

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.

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, offers, signers, and data entries, and an account cannot have more than 1,000 of them. Each counts as one subentry, except a trustline for a pool share, which counts as two and so requires two base reserves (currently 1 XLM). Learn more in the [Liquidity Pools section](./liquidity-on-stellar-sdex-liquidity-pools.mdx#trustlines).

[ElliotFriend]

Copilot's point here is sharper than it reads. The nearest "rule above" is the bullet list, which this PR just edited to say "(two subentries each)", so the sentence announces an exception to a rule that already contains the exception. And read against the lead-in ("each of which increases an account’s minimum balance by one base reserve"), a pool share trustline is not an exception at all. It obeys that rule and simply is two subentries.

Since the bullets now carry the count, this paragraph only needs to carry the consequence:

Suggested change

	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).
	A pool share trustline therefore requires two base reserves (currently 1 XLM) and uses two of the account’s 1,000 subentries. Learn more in the [Liquidity Pools section](../liquidity-on-stellar-sdex-liquidity-pools.mdx#trustlines).

[ElliotFriend]

Filed the Hubble data dictionary follow-up as #2860. It turned out to be worse than I thought: alongside the pool share trustline undercount, both pages have the sponsorship signs inverted in the minimum balance formula, so they currently claim that sponsoring entries for other accounts lowers your own minimum balance. Out of scope here, and this PR is still good to go on the wording above.