I’ve been hearing rumors about Sanctum implementing a fee switch/revenue-sharing with CLOUD but haven’t seen anything official. I’m unsure whether the team is seriously considering this, hence I decided to create this proposal
TLDR: A reg-compliant way to add revenue-sharing to CLOUD. Feel free to skip the “Thesis” and go straight to “Proposal” if you’re pressed for time
---------- THESIS ----------
If there’s one thing this cycle has proven, it’s that governance tokens (even if they have additional minor “utility”) are not valued highly by the market
A project can add all the non-monetary utility/features in the world to its token but that will only have a minimal impact on the value the market attaches to the token. It’s unlikely any of those features will be real game-changers that the market attaches a premium to.
IMHO, projects generally like to keep tokens as governance-only because then they can double-dip, right? They can collect the revenues and also benefit from their token allocations while most of their token holders underperform Solana or Bitcoin over higher timeframes
This isn’t PPP, this is PVP and that’s not what Sanctum stands for, unlike most other projects
Proposals that involve providing yield, etc. through token supply also don’t get valued very highly by the market. Players now are smart enough to know that that inflation-driven yield isn’t desirable. Such tokens rarely outperform the L1’s native token.
The best way by far, to really add value to a token is to add revenue-sharing
The question then becomes how does a project do this without running into regulatory hassles
We already have at least one example of a project that has done this in a compliant manner - Phemex (a CEX) with its token PT. I propose a similar model.
--------- PROPOSAL ---------
Allocate a fixed percentage of Sanctum’s revenue, in perpetuity, to CLOUD stakers. Perhaps somewhere between 25-50%. Let’s assume 50% for the sake of this example. Exclude INF pool fees since those go toward INF yield.
An automated algo that runs daily/weekly, checks previous days revenues and purchases CLOUD worth 50% of that revenue
The algo then distributes that CLOUD in yield to those who have single-side staked CLOUD on Sanctum. This gets automatically re-staked, though people can always choose to withdraw. Examples like JUP show us that many/most stakers choose to leave their yield staked, rather than withdraw & sell it
IMO, the cycle for the above should be daily, at most weekly. Longer cycles could potentially encourage buyers/sellers to try to time the market based on distribution dates and this would add unnecessary price volatility
All stats for the above should be displayed publicly on the staking page
The details of staking lock period, etc can be worked out, but I recommend no longer than a 30-day lock - ideally the lock period should be exactly the same as the frequency of CLOUD distribution. This way, when someone unstakes, he immediately stops earning the yield generated from revenue-sharing so it works out
— Advantages of this proposal —
This completely avoids inflation-driven yield and frees up existing supply for growing the pie
Considering how uncommon it is for projects to share revenue with their token holders, it’s likely the market will then attach a premium to CLOUD for doing this in a transparent manner
It’s likely the revenue loss to the project will be made up by the additional price appreciation this would cause, so this isn’t necessarily a negative for the team or project treasury
IANAL, but I believe this also circumvents regulatory hassles in directly sharing revenue/fees with token holders
Since the model is fully automated and runs daily/weekly, the community doesn’t need to keep asking “wen wen wen”. Plus it’s trustless.
We have seen how well Cloud is performing since TGE. Therefore, I can see why you would say the utility of the token may not have major impact and the DAO mechanism similar to Jup structure would make thar difference. I do like that idea of stake cloud for voting power and yields will be automatically re stake. Additionally, LST operators would also need to have certain amount of cloud to launch with Sanctum. I think this DAO approach is heatlhy for the protocol and its growth.
Hey @Shishir, thanks for bringing this proposal up…
One thing to note is whether adding a rev. share utility into CLOUD brings up the “security” question in to play. One aspect that you missed to outline are the disadvantages of carrying “rev. share” into CLOUD:
Disadvantages:
1. CLOUD litigated as security:
With regards to a change like this, it needs to be carefully laid out with legal aid in order to ensure that CLOUD does not become a target in terms of it being a security (expectation of future profits).
However, I do believe there is precedence laid out by UNI ( ) in their Recent charge against the SEC despite their proposed fee switch, so over time this might not be an issue (not legal advice)
Uni Fee Switch Governance Proposal:
Additional Information:
2. Rev. Share lack of success in Projects:
I do know that a few other projects have been rev. sharing their protocol fees towards govt. Tokens (GMX, Molten, many of the perp dexs on ETH). One limiting factor is how big of a revenue share that CLOUD could retain.
Seeing that the product is the infinity pool, the one large elephant in the room is whether the fees accrued within the $INF pool would be sufficient for a mechanism like this to be worth developing for CLOUD.
Though the idea is a welcoming addition to the utility basket for CLOUD (ASR, LVT, Profiles Governance), I would agree to vote FOR the development of a Revenue sharing Model into CLOUD.
Tho the important factor is whether the rev. fee share would be worth to be utilised as a burning mechanism or distributed directly to CLOUD stakers.
With regards to a change like this, it needs to be carefully laid out with legal aid in order to ensure that CLOUD does not become a target in terms of it being a security (expectation of future profits).
my understanding is that the “is it a securitiy” qn won’t be an issue since revenues/profits aren’t directly being distributed to token stakers
also legally, the token buyback is a separate action from the later distribution of said tokens.
but yes, IANAL and def Sanctum would need to get prof legal advice on this entire thing
Also, there’s already at least one project using the same model - a CEX called Phemex
#2
Seeing that the product is the infinity pool, the one large elephant in the room is whether the fees accrued within the $INF pool would be sufficient for a mechanism like this to be worth developing for CLOUD
To be clear, I thought the $INF LST pool fees are separate from the revenue generated from all other LST pools + swap fees, withdrawal fees, etc.
My proposal is for the latter, i.e. all the fees from LSTs other than $INF. Sorry if I misunderstood something
Tho the important factor is whether the rev. fee share would be worth to be utilised as a burning mechanism or distributed directly to CLOUD stakers.
IMO, Supply burns address only the supply part of the economic equation. They don’t create demand, which is a bigger issue with the vast majority of tokens
revenue sharing thru such a proposal can create a lot of demand
Obv both demand & supply pressures are important but I think creating demand through non-inflationary financial incentives is better than just reducing supply through burning tokens
A daily buy-back and redistribution of CLOUD tokens could lead to buying and selling manipulations around the payout schedule. One way to address could be via TWAP or so as to prevent large swings in the token price.
The proposal focuses on short-term rewards for stakers but doesn’t address how to maintain this long-term. We can consider creating a reserve fund to ensure there are always sufficient revenues available for distributions, even in low-revenue periods.
One way to make this more appealing to larger stakers is to introduce tiered benefits. Higher-tier stakers could get additional perks like governance privileges, more yield, or exclusive access to certain Sanctum content. This helps differentiate rewards and incentivizes holding more CLOUD.
A daily buy-back and redistribution of CLOUD tokens could lead to buying and selling manipulations around the payout schedule. One way to address could be via TWAP or so as to prevent large swings in the token price
yes I def meant a TWAP but somehow completely forgot to specify this. Thanks!
#2
The proposal focuses on short-term rewards for stakers but doesn’t address how to maintain this long-term. We can consider creating a reserve fund to ensure there are always sufficient revenues available for distributions, even in low-revenue periods
personally i think it’s okay if the rewards go up and down in tandem with revenue, but we can do w/e the community thinks is best. Something to note: a reserve fund would add additional complexity - this may or may not be a big deal, IDK
#3
One way to make this more appealing to larger stakers is to introduce tiered benefits. Higher-tier stakers could get additional perks like governance privileges, more yield, or exclusive access to certain Sanctum content. This helps differentiate rewards and incentivizes holding more CLOUD
tbh, i think pure linear is best as far as the financial incentives go. Just like token price doesn’t care whether one person bought 10 mn tokens or 10 ppl bought 1mn tokens each, neither should revenue sharing for stakers
rev share needs to be carefully thought about for the legal/security reasons
but in general they usually fall down as the rewards aren’t great for the the average holder
personally, feel more comfortable if any profit/fees or whatever it is deemed, go into the value of INF as additons to the reward pool, also to link to the two intrinsically together
I like this idea a lot, especially its trustless nature. My only consideration would be, given that the token & project are very new and in its infancy this can be perceived as deincentivising the team, removing income they should get.
I do think if this proposal is implemented the revenue to cloud token holders should be staggered so that initially the team gets the majority then over time it is fully given to cloud token holders.
Interested to hear dev thoughts, if you can discuss this element of the protocol on the public forum
Income and Revenue are separate things, revenue is what is brought into the PROJECT from fees while income from revenue usually doesn’t go to founders or DEVs unless a portion of the revenue goes to the development/operations fund. The team received 350M $CLOUD for themselves, with vesting, which equals $93M even when jeets are jeeting every single day, it was worth twice that at ATH and will be worth 10x that eventually. The project also raised $6m for operations before TGE and sold another 100M $CLOUD in the public sale. These guys have 1 job, make Sanctum a success for 3 years, and then they’re set for life. After 3 years when their tokens are all unlocked then an income can be talked about if rev sharing isn’t established by then but with revenue sharing they would be the largest benefactors because they own 35% of the supply.
My point is that the revenue isn’t supposed to be a bank account for anyone, it’s the project funds, that’s the whole point of a DAO owned and controlled project. So revenue sharing if implemented would in no way affect the income of the team, it would affect the project revenue allocations and to be legal it would have to also be in the best interest of $CLOUD holders which means all operational cost, rainy day fund, liquidity, etc would all have to be taken care of before any sharing happened, the sharing would only be excess revenue just like stock dividends.
I’d actually advocate fro the burn mechanism over traditional rev. share, as I think burns create demand, in fact more demand than rev. share would.
The token market is seen as very high risk, and therefore most low-yield products don’t see a lot of traction unless they build on top of stables or majors. I’d even argue that most staking activity we see comes from people who would hold the token regardless of the staking system. It’s therefore not about the yield, but the token.
Furthermore, rev. share can actually create negative pressure on a token as whale can churn the earned $CLOUD into USD, creating continual downward pressure on the token. (btw this is one reason why stocks that do share buybacks typically outperform dividend stocks YoY).
The biggest “demand creator” in any market is positive price action. Investors and traders who see continual positive performance from an asset are more likely to buy in. However, this mean you need initial buyers/demand to jumpstart the cycle. Burns do this, as it creates a perpetual source of demand, that being the protocol itself. This $CLOUD is then taken off-market permanently, absorbing sell pressure and creating a stronger chart, especially in slower market periods.
Burning is also less of a regulatory hurdle from my limited understanding, but I’d leave the details of that discussion to the more knowledgable.
This concern of negative pressure doesn’t apply because as my proposal states, revenue would be used to first buy back CLOUD and then those would be distributed. Even if everyone sold ALL the distributed tokens (which itself is highly unlikely) the net effect on price would be nil - worst case.
From my proposal →
2. An automated algo that runs daily/weekly, checks previous days revenues and purchases CLOUD worth 50% of that revenue
And I disagree that burns create demand - the reason why should be self-evident
Plus it’s trustless.
