Yes, that is correct. I think the only part that might need to change is the flat 100M to each app. It might make more sense to do what the community member suggested above where instead of a flat 100M subsidy per app we take a tiered approach to subsidies and give larger subsidies to larger apps. This should allow us to fine-tune the subsidies to be based on anticipated userbase and spending demand.
4 Likes
Thanks ChrisâŚI agree with the tiered approach for number of AMP given based on some metric of estimated size or other appropriate criteriaâŚwas just using the 100M as an example based on your previous comment of a possible 50M-150M rangeâŚI think this approach makes a lot of sense for all involved and eliminates the uncertainty as new apps come online.
1 Like
I donât know that I follow the issue you are raising. I think locking in an APY would probably be trickier to implement and likely require more active management to try to get the pools to align well enough - just fixing a subsidy allows for the market forces to play out naturally and probably get to the same place you are suggesting.
Just to clarify (which, admittedly it was not clear in my initial post), I would propose a quasi-variable subsidy - that any daily subsidy for a given pool be reduced (token for token) by the corresponding day open-market purchase rewards distributed to that pool in connection with successful network transactions. For instance, if there is sufficient volume/open market rewards for a given pool on a given day (i.e., in excess of the subsidy), no subsidy would be distributed that day. I believe this is the way the current subsidy operates, but cannot confirm for sure.
As to the fact that higher volume apps would have higher APY, I think that is a feature, not a risk. Subsidy aside, if there is a higher transaction volume app it will result in a greater amount of rewards for that pool, but it will also necessitate greater collateral needs. Collateral from lower volume apps will both need (to secure the pool) and want (to collect the increase in rewards) to migrate to higher volume apps, until it stop being economically appealing to do so (lower volume app APY will increase and higher volume app APY will decrease from migration).
2 Likes
Is the assumption is that as the userbase grows, the subsidies will increase. How would the user base of wallets be determined, this will presumably be different for wallets and Exchanges like Gemini. Also what ratio of subsidy to userbase if any, is being considered.
1 Like
Itâs more focused on getting the appropriate amount of Amp staked for small and large apps through incentives. If the subsidy for a smaller app is 1/3 the subsidy of a large exchange sized app, more stakers will stake the larger exhange collateral pool even as itâs still integrating the Flexa SDK and getting ready to launch. This should allow collateral pools to be closer to the right size at spending launch.
I would caution against committing subsidy tokens before they even launch. Any app should have some skin in the game and provide a small staking pool through their proof of concept stage. Once it is shown to be viable is the time to solicit people to stake so they can grow capacity. Seems like the potential for some really bad outcomes if people stake before an app even goes live.
3 Likes
Great points. Will get that fine tuned if the vote passes. It shouldnât be terribly difficult to turn it on slightly before with enough time to get stakers incentivized to move their Amp, but not too long before go-live date.
1 Like
This seems like an ideal situation to drive immediate growth with the Flexa SDK. Offering developers an incentive of immediate spending capacity is really helpful.
In the proposal, you hinted that the amount of AMP from the treasury would be dependent upon the size of the apps user base. How do you plan to account for user growth in applications as well as the growth of Flexa SDK adoption in the long term?
Also, for developers interested in using the Flexa SDK, how long is the response time for for those who inquire directly from Flexaâs site? I know developers that have been waiting for over a year to hear back from the team for the SDK.
2 Likes
Namiâs Q1 was the first thing that came to my mind and went unanswered. To help the Network Development Fund last longer, I agree it would be appropriate to build-in a first year of rewards support along with the Developer Grant. It would give the Developer confidence that it would be there without requiring another vote or additional allocation in the future and these tokens could be held-back until the Developer has a go-live date. Give them a tier based on number of users similar to what you are contemplating now. I will vote for an additional 1B out of Network Development Fund, but hope future contracts have the first year of reward subsidy built-in along with their Grant.
1 Like
It is true that the Developer Grant fund is much larger and can be used to extend the Network Development fund. Something along those lines is probably a great longer term solution. There is another (partial) solution that weâre working on so the developers know there will always be Amp to support their app at launch.
2 Likes
Update: Vote goes live this Friday. Voting will be open for one week. Please remember to cast your vote only at vote.amptoken.org or Snapshot
2 Likes