Stellar
Supply, sinks, a comparative model and concrete proposals (re: Meridian 2026 call and #2051) #2052
Replies: 2 comments 2 replies
|
Thanks for your thoughts. Two comments and a question. First, if Thruput reaches mainnet with XLM as the token, this does not eliminate Stellar/Soroban fees. It just means that if you want to transact for free, then you need to move the assets to Thruput and move some of your XLM over there as well for scheduling priority. Certainly for the foreseeable future most of the on/off ramps would be on Stellar, as would existing applications that don't need a huge amount of on-chain compute or transactions per second. Second, I think something is wrong with your 3.9B XLM/year number for new XLM entering the supply from the foundation. You may be annualizing a one-time event or measuring some kind of investment roll-over or something, because that number seems way too large. My question is why are you so opposed to subletting capacity on Thruput? To me, it seems useful to have a choice. By analogy, I can buy a computer or I can rent one from AWS, and either could make sense depending on my business model. Subletting capacity could be important for financial institutions that want to use Thruput but don't want to hold a lot of XLM on their balance sheet. To continue the analogy, it's like companies today that would rather their data centers be owned by a third party like Cloud Weavers. All else equal, I'd rather give people more flexibility in how they structure their finances. So is there a particular bad scenario that you would want to avoid with capacity leasing? |
|
Thanks for taking the time, this is exactly the kind of pushback I was hoping for. You're right on Thruput, I read too much into the announcement. I took "no per-transaction fees" to mean fees go away, but if it's a separate environment where you bring assets and some XLM for scheduling priority, then Stellar fees and the fee pool stay where they are. That actually makes the picture better for XLM, not worse: Thruput adds a second, holding-based source of demand on top of what exists today. I'll fix that in the post. You're also right about the 3.9B/yr. The raw numbers are from the dashboard API (the mandate dropped ~1.08B XLM between July 21 and Oct 29), but annualizing a 100-day window was sloppy, and I can't tell from the API how much of that is investments, liquidity inventory or roll-overs vs XLM actually reaching the market. The long-run view is more honest: SDF kept just under 30B after the 2019 burn and holds ~14.5B today, so roughly 2.2B/yr on average over ~7 years. That's still ~800x what the fee pool collects per year, so I think the core point holds (distribution matters much more than any protocol sink). On subletting: fair challenge, and honestly you changed my mind. I wrote it as if leasing undermines holding demand, but it doesn't. Someone still has to hold the XLM. And thinking about it more, a lease market might be the cleanest answer to the #2051 question: people who hold XLM earn income from people who need capacity. That's yield from real usage, with no new issuance and no need to touch the mandate or the fee pool. The AWS comparison makes sense to me. What I'd still want to see addressed in the design:
One question back: how often do you expect Thruput to actually be congested? If capacity only matters when demand exceeds supply, then lease prices (and holding demand) would mostly show up during peaks, and I'm curious whether that's enough to support a real market. |
|
First, one thing to note is that leasing transaction capacity is easy (just have people send you transactions to submit), but leasing storage is going to be tricky, because eviction is problematic. Even in small internal hackathons, it has become clear that when compute is abundant, people also tend to want a lot of storage. Thruput's storage is quite expensive to validators because it's all in RAM. So it's an open question how best to make out-of-RAM storage ergonomic. We could directly expose another tier of storage in validators, but it would be way cooler if smart contracts could easily make use of off-chain storage. To answer your questions:
Yes, but it might be hard to keep an SLA if people withdraw their XLM.
The way the Thruput design works, each coin conceptually gives you the right to wait in line to execute a fixed amount of gas. Instead of burning the coin, Thruput sends it to the back of the line once you've used it to schedule a transaction. Coins moved between accounts also get sent to the back of the line. So you could borrow a large amount of XLM to submit a bunch of transactions over an hour, but you can't starve people whose existing coins have been idle for over an hour, as they will get priority over you. No starvation was important to the design given Stellar's mission of equitable access.
SDF would have to move all the XLM over to Thruput and then start leasing capacity. I don't see that happening unless we somehow believe it would further the foundation's mission, which seems unlikely.
There's really no way to predict this, since we just announced and don't yet know exactly what kind of product will be based on Thruput, much less who is going to want to use it. Nonetheless, since transactions are free, if the incremental utility of a transaction is positive, the network might always run at capacity. |
|
Thanks, the back-of-the-line design answers my borrowed-balance concern well. Assuming XLM is Thruput's token, a quick check on the tokenomics: since each coin gives the right to a fixed amount of gas, if there's A XLM on Thruput in total and I hold B of it, is my long-run share of capacity under congestion roughly B/A? If, as you said, the network might always run at capacity, holding XLM becomes the standing price of guaranteed throughput, which is the strongest XLM demand driver in this whole discussion. On leasing: having people send you transactions to submit works, but the lessee then depends on the lessor staying online and continuing to submit. TRON has a model worth borrowing here: staked TRX generates resources that the owner can delegate to another account, which then uses them for its own transactions. The TRX stays with the owner, and the delegation can be locked for a fixed period. A Thruput version would delegate a coin's place in line instead, turning a lease into an enforceable on-chain agreement. It also seems like the cleanest answer to #2051: rewards for locked XLM come from lessees, not from the mandate or the fee pool. On Hyperliquid, which my original draft was modeled on: its main engine, buying back HYPE with trading fees, doesn't fit a network with free transactions. But two parts still carry over:
Plus taking the fee pool (~11M XLM) out of total supply instead of paying it out as rewards. That's the direction I'll update the post toward. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Context
TL;DR
Stellar is growing fast: ~$4.1B in tokenized RWAs (end Q3 2026) and $25.1B in stablecoin transfer volume in Q3 (+121% QoQ). But almost none of that activity reaches XLM. I started with a Hyperliquid-style "fee → buy → burn" design, checked it against the docs and SDF data, and most of it didn't survive. What I found:
Proposals:
1. Supply
Figures as of 2026-10-29 (SDF Dashboard API) unless noted; XLM ≈ $0.17, market cap ≈ $6.0B.
2. Sinks (where XLM leaves circulation today)
3. Demand drivers (growing, but not reaching XLM)
4. My original idea (v1), and why it fails
v1: a 0.001-0.005% surcharge on large RWA transfers and enterprise Soroban calls; 85% to a vault buying XLM on the SDEX; half burned, half paid to stakers; tiered XLM reserves for big issuers. (It was framed around a $10 XLM target; I've dropped any price framing.)
Math (vault = 0.85·f·V; V ≈ $100B/yr, f = 0.5 bp, XLM $0.17):
Flaws:
5. Comparative model (answering #2051)
3.9B XLM/yr distribution; e.g. 1%/yr of circulating ≈ 352M XLM ($60M)Reading: rewards funded by the fee pool or mandate move existing XLM around. Only external revenue sinks reduce supply, and only capacity-by-holding creates structural demand to hold.
6. Benchmark: Hyperliquid's tokenomics, fairly compared
Takeaway: Hyperliquid isn't purely deflationary either. It distributes supply too, but pairs that with fee-funded buybacks large enough to offset much of it. Its main engine (a fee on trading) can't be copied by a settlement layer; its second engine (reserve-income sharing) can.
7. Proposals
P1. Capacity by holding as the core demand driver
What: with Thruput, an institution needing guaranteed throughput must hold XLM. Demand then scales with usage without charging per transaction. Storage locks tie XLM to on-chain state such as RWA contracts, so RWAs being used on-chain (collateral, lending, settlement) rather than just held translates into XLM being locked.
Ask SDF to publish, before mainnet:
P2. Retire the fee pool, don't distribute it
What: keep the ~10.95M XLM locked, stop counting it in total supply, and publish monthly figures. If Thruput removes fees, freeze and retire the pool at its final size.
Why: as rewards it's ~$1.9M once plus ~$0.46M/yr. That's too small to change behavior, and it's the network's only sink. Retiring it is an accounting and transparency change (~0.02% of supply), not a price lever; future validators can always vote changes.
P3. Guardrails if any rewards program goes ahead
P4. Reserve-income sharing with stablecoin issuers (Hyperliquid AQA analog)
What: issuers earn yield on reserves backing coins held on Stellar.
P5. Application revenue → XLM sink (ecosystem pattern)
The protocol shouldn't charge a take-rate, but applications can, as long as fees are prices users already accept:
Example: a 24/7 venue for institutions to:
Permissioned pools can use Stellar's existing authorization and clawback features. Existing projects such as Blend, Soroswap, Aquarius and FxDAO already cover parts of this; the question is whether they, or a new venue, would adopt an XLM-sink policy.
Illustrative only (assumed spreads, not forecasts):
Even the mature case offsets only ~11% of current distribution.
P6. Voluntary issuer give-back (Informational SEP)
What: a standard contract any issuer may use to route part of its own revenue into transparent buy-and-burn. No protocol change, no obligation.
Honest impact: small. BENJI's net expense ratio is 0.20%. Even if all ~$4.1B of RWAs earned that (an upper-end assumption), 10% of fees would be ~$0.8M/yr. Regulated funds can't spend fund assets on a third-party token, so it would come from the manager's own budget.
P7. SDF supply transparency and a tokenomics dashboard
What:
Why: at ~3.9B XLM/yr, distribution is the largest single variable in XLM tokenomics, larger than every sink above combined. The dashboard makes every proposal measurable.
8. What I ruled out
9. Governance path
10. Questions
Sources
All reactions