External Project / Revenue
Funds WSOL, stablecoins, partner tokens, treasury assets, or other SPL-token revenue.
Distribution Funding
How external value enters the share system
External projects, ecosystem partners, and treasury sources can fund the share system by depositing WSOL or other SPL tokens into the universal revenue pool PDA. Once funded, those assets enter the visible revenue inventory and may later become claimable through the normal stake-and-claim path.
Funding Flow
External value flow diagram
This flow shows how outside assets move into the protocol. Revenue enters through one universal revenue-pool PDA, becomes visible to the distribution layer, and only then reaches staked shareholders through the claim path.
Revenue Pool PDA
Receives all external funding through one universal on-chain intake address.
Distribution System
Indexes funded assets and exposes them to the claim path under protocol rules.
Claim-Ready Holders
Can claim funded assets only when staked shares and claim conditions are satisfied.
Important distinction
Revenue entering the pool makes assets available to the system, but it does not bypass claim-readiness logic. Deposit acceptance is universal, while claim participation still depends on staked shares, current period state, asset visibility, and funded-asset claim conditions.
Universal Revenue Pool Address
One funding target for WSOL and other SPL tokens
This address is loaded directly from current on-chain protocol state for the selected cluster. It is the canonical revenue-pool PDA and acts as the universal intake address for external funding.
Cluster: DevnetLast updated: --Address: Missing
Loading on-chain revenue pool address...
Canonical Funding Target
Missing--
Funding Scope
WSOL + SPL-token deposits
Source of Truth
On-chain config account
Asset Routing
WSOL (SPL) -> Revenue Pool PDA
USDC -> Revenue Pool PDA
USDT -> Revenue Pool PDA
Other SPL tokens -> Revenue Pool PDA
Pre-send checks
- Confirm cluster matches your wallet network.
- Copy address from this panel only.
- Test with a small transfer before large funding.
Funding Playbook
One operational view of funding, asset intake, and claim-readiness constraints
This section organizes the core funding model into one consistent grid. The goal is simple: where funding comes from, what assets are accepted, how to deposit safely, and what conditions still apply before claims.
Why external funding matters
The share system is not limited to internal protocol flows. External projects, ecosystem programs, and treasury sources can inject value directly into the distribution layer.
This creates a transparent receiver model where funded assets are visible on-chain first, then processed by normal claim-readiness and claim logic.
Common funding sources
- External project revenue
- Protocol treasury allocations
- Partner token distributions
- Community incentives or ecosystem grants
Accepted assets
The revenue pool PDA accepts WSOL and SPL-token funding.
WSOL (wrapped SOL)Stablecoins such as USDC or USDTPartner SPL tokensTreasury-funded SPL assetsOther supported SPL tokens
Funding instructions
- 1Copy the universal revenue pool PDA.
- 2Send WSOL or another SPL token to that address.
- 3Wait for on-chain confirmation.
- 4Verify the deposit through the transparency page or a blockchain explorer.
Important rules
- Funding the revenue pool does not automatically create claim readiness.
- Shareholders must still hold staked claim shares.
- Claim availability depends on protocol state, asset visibility, and distribution conditions.
- All revenue deposits remain publicly visible on-chain.
Claim-readiness context
- Deposit events and claim events are different protocol states.
- Staked shares and period timing are still required before claim.
- Funded assets become visible first, then claimable when conditions match.
Funding Safety Warning
Verify the revenue pool PDA before sending assets
Sending SPL tokens to the wrong address may result in permanent loss. Revenue deposits are normal on-chain transfers and follow blockchain finality.
- Verify the exact revenue pool PDA before each transfer.
- For large deposits, consider sending a smaller test amount first.
- Use the transparency page or explorer to confirm the correct target account.
- Universal deposit acceptance does not guarantee immediate claim availability in the interface.
Funding Example
Example: project injects 10,000 USDC
This example shows how one concrete external funding event moves through the system. The deposit becomes visible first. Claims come later, and only for staked shareholders.
Step 01
Project deposits 10,000 USDC
An external project sends 10,000 USDC to the universal revenue pool PDA.
Step 02
Revenue pool balance updates
The deposit becomes visible on-chain and can be inspected through the transparency page or explorer.
Step 03
Distribution system recognizes funded asset
The USDC deposit becomes part of the system’s visible revenue inventory.
Step 04
Claim-ready holders claim later
Only shareholders with staked claim shares and valid claim conditions can participate in the USDC claim path.
Example takeaway
A deposit into the revenue pool is a visible funding event, not an immediate payout event. The 10,000 USDC becomes part of the system’s revenue inventory first, and only later participates in the normal stake-and-claim path for claims.
How funding is verified
- Inspect the revenue pool balance through the transparency page.
- Check the transaction on a Solana explorer.
- Review distribution assets visible in the claim interface.
- Verify funding transactions in protocol activity history.
What universal funding does not mean
Universal funding means any SPL token can be deposited into the system through the same intake address. It does not mean every deposited asset is instantly surfaced, immediately claimable, or treated identically in every interface view.
Deposit acceptance is open. Claim visibility and distribution handling still depend on protocol and interface logic.
Why projects use this flow
Funding the revenue pool allows external projects to distribute assets through a transparent and aligned recipient base. Shareholders form a visible participation set that can be independently inspected.
This avoids opaque reward allocation or random airdrops. All funding transactions remain publicly visible, and distribution logic follows deterministic protocol rules.