CLOUD As The Engine of Sanctum

[n8tr0n]

I’m so confused. Why is there not more discussion about CLOUD as a core sanctum product? It is already inherantly a product by way of it being a protocol token. So why is the discussion about band-aids (no offense @JamesHanley, love you brother) and not about giving CLOUD a solid foundation by nurturing it and boosting it’s value by way of utility and use-case? IMO there is nothing that needs to be fixed or ripped off. CLOUD needs nurturing and equal bandwith.

Sanctum already delivers two groundbreaking products: Infinity, the universal LST liquidity layer, and Gateway, Solana’s transaction aggregator that protects users and boosts validator health. CLOUD could be the engine behind the ecosystem. Here are just a few ideas:

1. CLOUD as the “Liquidity Energy Source” (more details)

• Position CLOUD not as governance only, but as the fuel that powers all Sanctum products.

• For example: INF LP fees or Gateway rebates could be routed partially through CLOUD. You need to hold or stake CLOUD to maximize yield, rebates, or access perks.

• This turns CLOUD into a power-up token, not just a vote.

2. CLOUD as an “Eco-Layer” (Staking, Access, Rewards)

• Create a CLOUD Staking Hub where stakers unlock cross-Sanctum benefits:

  • Boosted APY on INF

  • Priority routing on Gateway (lower fees, faster execution)

  • Airdrop access for new LST launches

• This effectively makes CLOUD the membership key to Sanctum’s ecosystem.

3. CLOUD as the “Treasury Product”

• The Community Reserve could be structured as its own financial product, backed and grown by CLOUD.

• Example: Treasury yield, insurance pools, or protocol revenue flows are tokenized back into CLOUD stakers.

• This frames CLOUD itself as a yield-bearing product that complements INF (liquidity) and Gateway (infrastructure).

CLOUD needs to move from being a side governance tool to being the connective tissue that powers, enhances, or amplifies INF + Gateway. That’s when it becomes a core product.

Product C1 details: CLOUD As The Engine of Sanctum - #4 by n8tr0n

Product C2 details: CLOUD As The Engine of Sanctum - #5 by n8tr0n

Product C3 details: CLOUD As The Engine of Sanctum - #6 by n8tr0n

[JamesHanley]

Thanks for kicking this off, N8. No offense taken! Keen to see more if you could flesh this out into a bigger / more detailed proposal

[n8tr0n]

Thank you James! You ask and you shall receive . I hope to get as much feedback and ideas from the community and yourself as possible. We have some super brains in this community.

These 3 features are what I could think of. I’m sure there are more that could strengthen the flywheel and boost CLOUD as the fuel of the Sanctum ecosystem.

[n8tr0n]

Since this idea is pretty loaded already, I’m going to ellaborate seperately on each of the 3 features I mentioned. And yes, I do use GPT to organize my ideas and thoughts, and make me sound better at this than I actually am.

CLOUD as the Liquidity Energy Source (C1)

Goal

Make CLOUD the fuel that powers every Sanctum product, so holding/staking CLOUD directly improves user economics across Infinity (INF) and Gateway and creates persistent buy + lock demand for CLOUD.

Core Idea

Route a portion of protocol value back through CLOUD via three levers:

1. Fee Router: A share of protocol fees is programmatically used to buy CLOUD and either burn it or convert to non-transferable “Fuel Credits” for stakers.

2. Fuel Vault (CLOUD Staking): Stake/lock CLOUD to receive Fuel Credits that can be spent on fee rebates, priority routing, and yield boosts.

3. Booster Multipliers: Longer locks and higher stake tiers amplify benefits across INF + Gateway.

Mechanics

A) Fee Router (on-chain policy)

• Sources:

  • INF: swap/LP/exit fees, rebalancing spreads

  • Gateway: routing fees, SLA premiums, paid lanes/APIs

  • (Optional) Validator partner rebates (MEV-aware lanes)

• Split (initial, adjustable by DAO):

  • 40% weekly TWAP buyback & burn (pure sink)

  • 40% to Fuel Credits for CLOUD stakers (utility sink)

  • 20% to Growth Pool (market-making, listings, partner incentives)

Rationale: combine a hard sink (burn) with a soft sink (credits that require staking/locking), plus budget to accelerate integrations.

B) Fuel Vault (stake/lock to earn utility)

Stake CLOUD to accrue Fuel Credits (non-transferable, epoch-based; expire in 90 days to spur usage). Credits can be spent for:

• Gateway: fee rebates (up to X%/epoch), priority routing windows, higher TX caps, premium telemetry/API endpoints.

• INF: APY boosters (capped), lower exit/spread fees, early access to new baskets/vaults.

• Partner Apps: opt-in credit acceptance (e.g., reduced fees on integrated dApps using Gateway lanes).

Tiers (example, adjustable):

• Bronze: 5k CLOUD staked → base credits

• Silver: 25k CLOUD → 2× credit rate, modest INF/APY boost cap

• Gold: 100k CLOUD → 3× credit rate, max rebate caps, early access allowlists

• Diamond: 250k+ CLOUD (or 180-day lock) → 4× credit rate, top priority bursts, partner perks

Lock Multipliers: 30/90/180-day locks = 1.2× / 1.5× / 2.0× credit rate.

Credits ≠ dividends; they’re utility that reduces costs or increases performance, avoiding direct revenue-sharing risk while still creating real value.

C) Validator & Integrator Track (optional module)

• Validators & integrators can stake CLOUD to qualify for routing weight boosts (performance-gated, capped) and access premium Gateway features.

• Poor performance or misconduct removes boosts (no pay-to-win).

• Creates natural demand from infra participants without compromising fairness.

Example Token Flow (illustrative)

• Weekly protocol fees = $500k equivalent.

• Router executes TWAP:

  • $200k → buy CLOUD → burn

  • $200k → buy CLOUD → convert to Fuel Credits for stakers

  • $100k → Growth Pool

Benefits to the Ecosystem

• Continuous buy pressure + supply reduction

• Credits only usable by CLOUD stakers/lockers → persistent stake/lock demand

• Growth funds to widen integrations → more fees → a stronger flywheel

KPIs to Track

• % of CLOUD staked/locked (target: +15–25% in first 90 days)

• Net weekly buyback & burn (tokens removed)

• Fuel Credit issuance vs usage (utilization > 60%)

• Gateway paid adoption (MAU of premium endpoints, priority lanes)

• INF retention & boosted APY uptake

• Revenue mix (share routed through CLOUD)

Risk & Mitigation

• Regulatory optics: prefer credits/discounts/priority over direct rev share. Keep burns/credits policy DAO-tunable.

• Whale domination: cap per-wallet rebates and priority windows; diminishing returns on very large stakes.

• Under-utilized credits: introduce expiry, transferable within the same wallet cluster (optional), and seasonal promos to encourage spend.

• Liquidity shocks from buybacks: use TWAP + circuit breakers.

[n8tr0n]

CLOUD as the Eco-Layer (C2)

Goal

Make CLOUD the membership key to the Sanctum ecosystem. Instead of being a passive governance token, CLOUD staking unlocks tangible, ecosystem-wide perks, from boosted APY on Infinity to cheaper/faster routing on Gateway, and access to new products before the rest of the market.

Core Idea

Turn CLOUD into a cross-product passport: staking CLOUD grants tiered benefits that directly improve the user’s experience across Sanctum. The more you stake/lock, the more perks you unlock.

This ensures that holding CLOUD = belonging to the core Sanctum club.

Mechanics

A) CLOUD Staking Hub

• Single, unified dashboard where users can stake or lock CLOUD.

• Shows benefits unlocked (real-time across INF, Gateway, future Sanctum products).

• Integrates Fuel Vault credits (from Product 3A) but expands to cover membership perks.

B) Benefits Framework

1. Infinity (INF – liquidity layer)

• Boosted APY: Stakers earn a small percentage boost on yield-bearing LST LPs (capped per tier).

• Reduced exit fees: Lower cost when moving in/out of pools.

• Priority access: Early entry to new LST pools before general launch.

2. Gateway (transaction router)

• Fee rebates: Extra % reduction beyond Fuel Credits baseline.

• Priority routing: Stakers get lower latency and faster fill probability.

• Quota extensions: Higher caps on transactions or API calls for heavy users.

3. New products & partner integrations

• Airdrops / token launches: CLOUD stakers are first in line for Sanctum-verified drops.

• Beta access: Early testing of new infra tools or LST baskets.

• Partner perks: Sanctum ecosystem partners can whitelist CLOUD stakers for reduced fees, cross-protocol boosts, or gated access.

C) Tiered Membership (illustrative design)

• Bronze (5k CLOUD): modest APY boost, reduced INF exit fees, base Gateway rebate.

• Silver (25k CLOUD): +2× boosts, access to pre-launch LST pools, larger Gateway rebates.

• Gold (100k CLOUD): +3× boosts, priority routing, premium Gateway features, early beta invites.

• Diamond (250k+ CLOUD or 180-day lock): max boosts, whitelist access to strategic partner perks, Sanctum “council tier” recognition.

Locking amplifies benefits: 30/90/180-day locks → 1.2× / 1.5× / 2.0× tier multiplier.

Example User Flow

1. User stakes 50k CLOUD in the Hub.

2. They unlock Silver tier perks:

   • 5% APY boost on INF LPs,

   • 20% reduced Gateway fees,

   • guaranteed allowlist spot for the next LST launch.

3. After locking for 90 days, their multiplier bumps them into Gold-equivalent perks without additional tokens.

This drives long-term lock demand while creating practical reasons to hold CLOUD beyond speculation.

Benefits to the Ecosystem

• User retention: Stakers have reasons to stay within Sanctum products (higher APY, cheaper fees, early access).

• Demand flywheel: More stakers → stronger ecosystem stickiness → higher usage of INF + Gateway → more protocol fees → more routed through CLOUD.

• Community cohesion: CLOUD becomes a social identity layer—the token that unites product users under one badge.

KPIs to Track

• % of total CLOUD staked in the Hub (target: >25% within 6 months).

• % of users per tier (Bronze/Silver/Gold/Diamond).

• Boosted APY uptake across INF pools.

• Gateway rebate utilization rate.

• Partner integrations using CLOUD-gated perks.

Risk & Mitigation

• Dilution of perks: cap APY boosts and fee rebates per tier; adjust thresholds dynamically.

• Complexity / UX friction: launch with 2–3 simple tiers and a unified dashboard; expand later.

• Short-term farming: use lock multipliers (30/90/180 days) to strongly reward long-term staking.

• Partner dependency: anchor value in INF + Gateway first; keep partner perks additive, not core.

• Governance capture: apply diminishing returns beyond thresholds; require lockups for Diamond tier.

[n8tr0n]

CLOUD as the Treasury Product (C3)

Goal

Transform CLOUD into a yield-bearing product by linking it directly to Sanctum’s community reserve, treasury flows, and protocol revenue. While Infinity handles liquidity and Gateway handles infrastructure, CLOUD becomes the financial layer that captures value from the entire ecosystem.

Core Idea

The Community Reserve and future revenue streams can be structured as a Treasury Product. CLOUD stakers participate directly in that growth.

Instead of being a passive token, CLOUD becomes a claim on ecosystem prosperity—backed not by hype, but by real protocol economics.

Mechanics

A) Treasury-Backed Staking

• CLOUD stakers receive a portion of returns generated from Sanctum’s reserves, protocol fees, and partnerships.

• Treasury allocations can be split transparently between:

  • Protocol growth (team reserve)

  • Community growth (stakers)

B) Revenue Streams Routed into CLOUD

1. INF LP fees – small % of Infinity pool fees streamed back into CLOUD stakers.

2. Gateway routing fees – transaction rebates partially recycled into the Treasury Product.

3. Treasury yield strategies – community reserve deployed in low-risk DeFi to generate returns for CLOUD stakers.

4. Partner incentives – projects paying Sanctum for access/liquidity could direct a portion into the CLOUD treasury.

C) Insurance Pool Integration

• Part of the treasury could be earmarked as a safety net, protecting users during unexpected events.

• CLOUD stakers benefit not only from yields but also from the confidence of a backstopped ecosystem.

Example User Flow

1. User stakes 20k CLOUD.

2. Quarterly, a % of Sanctum’s protocol revenue (e.g. 5% of INF + Gateway fees) is distributed back to stakers.

3. Returns are claimable in CLOUD (buybacks from market) or SOL/LSTs (direct yield).

4. Over time, this creates continuous demand for CLOUD as more tokens are bought to fuel rewards.

Benefits to the Ecosystem

• Direct alignment: CLOUD holders are no longer just passive spectators—they share in Sanctum’s financial success.

• Demand pressure: Buybacks and revenue routing create consistent buy-side support for CLOUD.

• Sticky staking: Long-term staking for treasury yield locks supply out of circulation.

• Investor confidence: The Treasury Product makes CLOUD comparable to a yield-bearing instrument, boosting attractiveness to both retail and institutional players.

KPIs to Track

• % of protocol revenue routed into Treasury Product.

• Total yield distributed to CLOUD stakers.

• % of total CLOUD locked in Treasury Product contracts.

• Buyback volume generated by treasury flows.

Risk & Mitigation

• Regulatory classification: avoid framing as “dividends.” Use buybacks, credits, or staking boosts instead of direct profit-sharing.

• Treasury depletion: enforce conservative allocation caps; prioritize safety over high-yield farming.

• Revenue volatility: smooth distributions with rolling averages (e.g. 30-day TWAP of fees) to avoid boom/bust payouts.

• Insurance underfunding: segment treasury pools (yield vs. safety) to ensure reserves are never drained.

• Whale capture: apply diminishing yield returns beyond thresholds; introduce staking multipliers for longer locks rather than sheer size.

• Execution risk: start with a small % of fees routed to CLOUD; expand gradually as systems prove stable.

[DoubleU]

I totally agree with 1.
I have already proposed something similar in the past in a post about utility.
Thank you for raising this up, it’s a very important topic and it’s definitely the way to go(the utility route).
Aave has nice utility for it’s token and we could learn things from them.

Boosted apy on INF might be difficult to implement but would be cool.

[DoubleU]

CLOUD potential Utility

This post’s goal is to discuss and propose possible utility options for cloud What Drives CLOUD’s Value Today? A. Speculation Some treat CLOUD as a proxy investment in Sanctum. Since there’s no direct way to invest in the protocol, CLOUD becomes the next best thing. There’s also speculation that revenue sharing or deeper value accrual might be introduced one day. B. ASR Rewards (Active Staking Rewards) Staking CLOUD gives very high ASR, which has led to: Borrowing CLOUD just to stake and …

Check this one too.
Basically some ideas I proposed back in May on this topic.

[andrewsaul]

Lot’s of work here, and fuel for discussion. I LOVE how this is product focused (but of course I do )

I can’t add anything more to the options detailed than you’ve put up. Others smarter than I can offer better advice re mechanics.

What I will offer is some higher level thoughts based on what i think a successful organisation is and isn’t.

I agree: CLOUD is a product. You can’t treat it any other way. And as a product it needs to contribute to Sanctum’s success. If it can’t: It should be abandoned.

At a high level a successful organisation is focused, always, on what winning is for them. That can change over time, and normally has to, but what is important is that that ‘winning’ is the focus of everything they do.
For Sanctum, in my opinion, that right now should be growth. Growth being defined as: users + revenue. You can’t just grow revenue (onboard 2 whales and you’d increase protocol rev 30% but that’s incredibly risky and never ever works) nor can you just give tokens away to juice user numbers (metrics explode… then crater. See: ZK Sync, Berachain, LayerZero, Zeta Markets, Polkadot etc, etc, etc…).
What you need is to grow the amount of revenue generating users. Not necessarily grow profits at this stage, but not lose too much money either.

So in that case what you need is for CLOUD to equal to: Users + Revenue.
You can’t just hold and stake CLOUD and expect rev share: That doesn’t generate any revenue. Any revenue attributed to CLOUD should come as a result of revenue generating activity. I like all the suggestions that direct revenue back into CLOUD but only base the pass through of that revenue to CLOUD stakers/holders on product usage.

Governance is very important I think. If you can make users sticky for reasons that aren’t purely financial you start to build a proper moat. Many providers are going to enter the Solana LST space. It’s inevitable and a lot of them will have deeper pockets than Sanctum and that will take significant usage away from Sanctum at those times when their incentive schemes are running.

However if those giveaways are not linked back to building long term retention we’ll see the same boom → bust we do with all incentive schemes. A CLOUD product that is able to provide some amount of non-financial retention is a powerful user + revenue driver.

There’s a few well designed memecoin/NFT communities who’ve been able to build and retain large engaged communities who provide a lot of value with revenue flows and through long periods of down-only price action. It can be done and has been.

[n8tr0n]

Love this perspective You’ve nailed the key point: CLOUD has to equal users + revenue, not just “rewards for holding.” Any value attributed back to holders should be tied to real usage of INF, Gateway, or future products, otherwise it’s just inflation.

I also agree 100% that governance + non-financial stickiness is underrated. If CLOUD can build that “moat” where people stay engaged because of identity, access, and community, then financial upside becomes additive rather than the only glue. That’s what separates the boom → bust incentive cycles from sustainable growth.

[psolite]

I support this, we need to give CLOUD utility but not all at once.

Creating a working group for this, might be a good idea

[amensch]

Isnt it the Team’s responsibility to come up with a utility? We learned from Jupiter’s exercise, Working Groups arent always a good solution

[n8tr0n]

@psolite @amensch I agree we can’t roll out all CLOUD utility at once, it has to be staged. A working group could help, but I think it would need to be restructured from what we saw with Jupiter. Maybe a hybrid approach makes sense: the core Sanctum team leads + manages the product directly, and a small community group helps refine ideas and test mechanics. That way it’s focused, accountable, and still gets the benefit of wider input.

[n8tr0n]

Thank you brothah! Good to see we are thinking the same way. Let’s make it happen!

[psolite]

We are just making suggestions the team still have the final say.

[psolite]

That is still a good idea, lets wait for the team responses. They might have other plans.

[Riceracc00n]

n8 the gr8 delivering once again!

i enjoyed reading your idea filled post

Gives a great reason to buy and hold cloud, whether it be in your wallet or staked, instead of forcing people to only stake to receive any perks

[n8tr0n]

Utility and perks, hand-in-hand.

[andrewsaul]

I think it’s too easy to write off Jupiter’s working groups as failures. A lot of good stuff did come out of them. It just wasn’t ALL good and there was a fair bit of farming towards the end.

Crypto is over represented by poorer parts of the world (people who are time rich, money poor) so any incentive scheme that doesn’t require actual money up front (e.g., trading) is flooded with these people so you’re bound to see some amount of leakage of incentives to low to no value users in anything you do.

I don’t think you can ever stop this, but you can definitely control for it.

Linking rewards to stake amounts and delaying payments will dissuade most of the low value users here. You just need to be firm and not put up with the endless begging and complaining this will initially result in.

[TDegen]

Fully agree @andrewsaul
I’ve seen my plentiful fair share of the kind of extraction you mentioned and I definitely want to throw in my own “please consider all avenues that these sort of ideas can possibly be exploited, and get rid of them”.

Great ideas and great stuff here @n8tr0n, love seeing your ideas and your work.
Regardless of which idea / what may be considered in A,B,C, I think this comment is extremely important to consider.

@n8tr0n

I also agree 100% that governance + non-financial stickiness is underrated. If CLOUD can build that “moat” where people stay engaged because of identity, access, and community, then financial upside becomes additive rather than the only glue. That’s what separates the boom → bust incentive cycles from sustainable growth.

I’ve always maintained the idea of a “human touch” when it comes to crypto - That markets and prices and everything that moves often boil down to the human aspect of it, that decisions are made by a human behind a screen.

Unfortunately, I’m forced to face reality every day as I hear of this AI or that bot running this or that, and I realize that a vast majority of financial/crypto decisions really don’t have a basis in human emotion / human interaction any longer. To that end, even though I myself may be wholly driven to stay connected / interact / be engaged because I love the community aspect, to expect to be able to grow an entire product based on trying to appeal to humanity unfortunately feels unfeasible, especially true in web3 where everything is about profit… I think there simply aren’t enough humans and/or humans that are driven by emotions-rather-than-money to power these ideas in the way you want to.

So if we’re to make CLOUD work in these other routes of yield-bearing DeFi, as much as I hate to say it, it definitely requires financials and numbers more than my fluffy emotions –
to that end, I’d like to consider picking and pulling from your different product propositions.
I personally don’t believe the team/project should be using any treasury for these - While there is a level of responsibility the team may feel about CLOUD price/value, I think treasury should be for powering/financing higher level decisions like new hires, company expansions/acquisitions, etc., whereas community is more about expanding the “human touch” / expanding CLOUD’s emotional influence.
So – for example, leveraging Solana’s strongest communities [see: cult] and up and coming projects…
Leaning towards Product 3B and push partnerships with Mad Lads / integration with Backpack, or offer perks for the BONK ecosystem or the JUP community.
along with
Product 3C utilizing community reserve in place of treasury and partnering/utilizing DefiTuna.

Apologies for rambling, had limited time to collect my thoughts.

Looking forward to how this discussion will progress!

Meow