CLOUD

Cloud (CLOUD): Sanctum’s Governance Token and Solana Liquidity Infrastructure

Cloud is the governance and incentive token associated with Sanctum, a Solana protocol that connects liquid-staked assets through shared liquidity infrastructure. Its practical significance depends on how Sanctum manages LST reserves, token governance, supply decisions, and the still-limited link between protocol activity and token demand.

What Sanctum does

Sanctum is a Solana infrastructure protocol focused on liquid staking, LST liquidity, and related transaction services. Its core liquidity product, Infinity, is designed to let users swap among different liquid-staking tokens and SOL through a shared pool rather than relying on separate liquidity for every trading pair. Sanctum also presents products for institutions, custom liquid-staking solutions, transaction delivery, and infrastructure operations, so CLOUD belongs to a broader protocol and services ecosystem rather than to a standalone staking pool.

The intended users include holders of SOL who want liquid exposure to staking, LST issuers that need deeper liquidity, applications that use LSTs as collateral or settlement assets, and partners seeking branded or white-label staking products. Sanctum’s own materials describe these use cases as part of its infrastructure offering; the existence of a product description does not by itself establish independent adoption or profitability.

How Infinity’s architecture works

Infinity uses an S Controller to manage reserves, LST registrations, liquidity operations, and rebalancing. Each supported asset has a SOL Value Calculator that reads the relevant external liquid-staking protocol’s on-chain state and converts the asset into an intrinsic SOL-denominated value. Users can add an approved LST or SOL and receive INF liquidity-provider tokens, burn INF to withdraw a share of pool assets, or use a swap instruction to exchange one supported LST for another.

This design creates important dependencies. Sanctum must correctly read external staking-program state, maintain reserve accounting, administer whitelisted assets, and keep its pricing and rebalancing programs operating as intended. The documentation also describes pause controls, dynamic fees, and an allocation process that can stake excess SOL or unstake weaker-performing assets to restore reserve targets. Sanctum lists audits from Neodyme, OtterSec, and Sec3 for Infinity, but an audit is evidence of a review process, not a guarantee that the deployed system is free of exploitable risk.

CLOUD’s role

CLOUD was introduced as Sanctum’s governance token and as an incentive for participation in the ecosystem. The original design gave token holders a role in selecting Sanctum Verified Partners, while prospective partners were expected to stake CLOUD to qualify. The token documentation describes CLOUD as a utility and governance asset rather than an ownership claim: it does not represent equity, dividends, protocol revenue, or a right to company assets.

The original token plan set total supply at 1 billion CLOUD, with allocations for launch liquidity, a community reserve, a strategic reserve, team members, investors, and Jupiter’s LFG program. Sanctum’s genesis-accountability post identifies the Solana mint as CLoUDKc4Ane7HeQcPpE3YHnznRxhMimJ4MyaUqyHFzAu and states that mint and freeze authorities were burned, while metadata authority remained with a team-controlled multisig. The block explorer provides the practical reference point for checking the token mint and subsequent transfers.

Governance and supply control

CLOUD governance has been used to decide how community-reserve tokens may be distributed. Sanctum reported that its 276 million-token Community Reserve could only be distributed after a vote by CLOUD holders, and that the project had used active-staking-reward votes and futarchy experiments with MetaDAO. The same update said active staking rewards had been paused by the end of the third quarter of 2025, making the token’s governance function more consequential than its earlier staking-incentive role.

On September 2, 2026, Sanctum published CLOUD-008, a proposal to burn roughly 259 million remaining Community Reserve tokens, reducing the nominal supply from 1 billion to about 741 million. The proposal also announced an intended metadata change from CLOUD to SANC while stating that the mint address and token economics would remain unchanged. The forum discussion clarifies that only the burn was up for a vote; the ticker change was not presented as the voted decision. Until the proposal’s execution is independently confirmed on-chain, it should be treated as a governance proposal rather than a completed supply change.

What the token does not provide

CLOUD’s connection to Sanctum usage is primarily governance, incentives, partner coordination, and community participation. The project’s legal disclaimer expressly says that the token does not confer ownership, revenue rights, dividends, redemption rights, or a claim on the company or its assets. Sanctum’s 2025 update discussed treasury buybacks and future value-accrual questions, but those statements should not be read as a contractual distribution mechanism. Protocol growth and token value therefore remain separate questions unless governance or future product design creates a stronger link.

Practical assessment

For newcomers, the key distinction is between Sanctum infrastructure and CLOUD. Sanctum’s products can be used to provide liquidity, swap supported LSTs, or access staking-related services without every function necessarily requiring CLOUD. CLOUD is instead the governance and coordination layer whose importance depends on the scope of future votes, partner programs, incentive decisions, and any legally compliant value-accrual mechanism that may be introduced. Users should verify the mint address, current metadata, reserve status, and governance outcomes before acting because the project has proposed material changes to the token’s name and supply.

Key takeaways

• Sanctum provides Solana liquid-staking and shared LST-liquidity infrastructure; Infinity is its central multi-asset liquidity primitive.
• Infinity relies on external staking programs, SOL-value calculators, reserve accounting, pricing logic, and administrative controls.
• CLOUD was created for governance, incentives, and partner coordination, not for equity ownership or guaranteed protocol revenue.
• The token’s original supply was 1 billion, with substantial team, investor, strategic, liquidity, and community allocations.
• A September 2, 2026 proposal sought to burn about 259 million Community Reserve tokens; execution should be verified on-chain rather than assumed.
• The proposed SANC metadata change and the proposed supply burn are separate from the underlying Solana mint address.

Risks and open questions

• Infinity depends on the correctness and availability of external liquid-staking protocols, value calculators, reserve accounting, and rebalancing logic.
• Smart-contract, administration, multisig, oracle-like pricing, liquidity, and asset-whitelisting failures could affect withdrawals, swaps, or pool valuations.
• CLOUD’s practical demand may remain limited if governance, partner staking, and incentive programs do not create recurring participation needs.
• The September 2026 Community Reserve burn was presented as a proposal; the final vote and on-chain execution require separate confirmation.
• A token metadata change can create ticker confusion across wallets, explorers, and venues even when the mint address remains unchanged.
• CLOUD does not provide contractual rights to company revenue, dividends, assets, or redemption, so protocol growth does not automatically create token cash flows.