The first vote on AIP-2 is now on Snapshot.
You have until 12:30PM UTC, 10th March to Vote.
2 Likes
At this point it’s pretty clear that people misvoted on the previous AIP 
2 Likes
It looks like the vote on AIP-2.1 will pass when the voting concludes in couple of hours with our community favoring the creation of Governance Vault on Fantom.
I will be putting up the 2nd part of the vote (which is to determine the distribution mechanics)
There will be 3 choices presented for voting - which are listed below. I would also like to highlight the efforts level from the development perspective for each option as well, as this will impact when we can launch the Governance Vault and the time required from our development team.
Option1:
- 100% of revenue + GR rewards on Fantom get distributed to Governance Vault stakers on Fantom, similar to how we do it on BNB Chain
- Effort Required: Minimal effort required as the code will be similar to the one on BNB Chain. Will only require some configuration, deployment, and testing.
Option2:
- A fixed portion (20%) of the revenue generated + GR rewards on Fantom get distributed back to Governance Vault stakers on BNB Chain while the rest (80%) are distributed to stakers on Fantom.
- Effort Required: This option will take an additional 1 - 2 weeks of development time (more than option1) to handle the rewards bridging and calculation.
Option3:
- Revenue generated on each chain are combined and distributed based on xALPACA amount on each chain so that the APR% achived in both governance vault are equal (i.e., pro-rata distribution.) A fixed portion of GR rewards on Fantom get distributed back to Governance Vault stakers on BNB Chain (no selling of rewards token; must claim on Fantom)
- Effort Required: This option will take an additional 3 - 4 weeks of development time (more than option1) With the pro-rata distribution, we need to redesign the revenue distribution contracts on BNB Chain as well as Fantom. This option also introduces a new set of operations that need to be automated, e.g. cut-off time, settlement, bridge alpaca according to xAlpaca supply on that week and several background jobs to set up.
6 Likes
Hey all, Squid here.
As HC suggested above, I want to point out that Option#3 will require us to re-do revenue distribution contracts and re-design revenue sharing token flow in order to distribute revenue + emission correctly.
We will need to post the proof of xALPACA total supply & revenue earned in that given week on each chain that Alpaca operates to BNB Chain in order to make required datas available for the calculation of the revenue distribution. You can think this contract as our internal oracle to make the main RevenueSplitter be able to calculate revenue to be distributed on each chain. This means revenue on chains that we are operating will be bridged back to BNB Chain first to do the calculation and then settle and bridge to AlpacaFeeder on each chain.
There will be several background jobs and keepers that we will need to develop, hence it needs 3-4 weeks of development time to make sure every pieces glue together nicely.
3 Likes
I’d like to point out that after this vote, we could have a vote again later down the line to make governance distribution more advanced. That would allow us to do something like implement option 1 now which would require very little time, and then option 2 or 3 later when Alpaca Fantom has more TVL.
If we were to spend an additional month building governance on Fantom when Fantom only has 4% of our platform-wide TVL, it would not be a good use of our resources from a product strategy perspective. We could spend that month working on Automated Vaults or the Institutional Platform instead.
As a result of the relatively low % of TVL on Fantom, the revenue is also nothing substantial and wouldn’t make much of a dent for current ALPACA stakers on BNB Chain.
5 Likes
I was actually thinking the same.
At a dev perspective It seems that every option include the features of the previous one so option #2 requires a working option #1 first while option #3 requires option #1 and #2.
If the contract is upgradable I don’t see any negative in releasing features gradually compared to releasing all of them at the end.
It may also give a good boost to the fantom governance because the initial bonuses would be bigger considering 100% of the grazing range APR would not move offchain.
A big negative in waiting 4 weeks is that we could loose the traction that delta neutral pools could give to the project, also the time in the crypto world runs x10 faster.
The only thing I would avoid is to vote step by step, I would choose the full path now and then proceed with the gradual implementation in case options #2 or #3 win the voting.
The reason is that I can’t decide where to lock for 1 year my tokens if I don’t know what the community will choose later on.
Also, in case option #3 wins, even if we start out with the basic governance vault we should avoid the choice paralysis because we know that in few months the revenue APR in both chains would average out.
1 Like
we share income which is not yet. In governance bsc, profitability falls, new tokens are not added to graze.
While #1 is a lot easier to implement it doesn’t make much sense given the current apy. Without the alpaca emissions there is almost no reason to lock your alpaca, if it’s something similar to BSC’s protocol revenue which is around 8% (how much is now?) it doesn’t seem worthwhile from a stakers perspective.
We haven’t seen anything from grazing ranges yet, so it’s hard to predict/promote the locking for a full year with almost no certainties. Can we get some info on the expected returns per option(excluding grazing)?
Also “A fixed portion of GR rewards on Fantom get distributed back to Governance Vault stakers on BNB Chain”? is really vague, what split are we going to use 20-80?
the beauty of #3 is that it gives us the ease of mind of not having to predict which chain will give us the best roi (or on which chain we’ll gain traction)
This is something I can get behind. Make it clear that it’s temporary and give us a timeline on when we can expect the full product
I agree with Sam on this point. Spending 4 weeks on option #3 now might not be the best ROI for our dev resources.
@Bibendus Re. your point about choosing full path now, maybe one thing we can do the following steps:
1.) vote for the full path now
2.) Regardless of which option wins, we will start with option #1 implementation.
3.) We will then implement the full path (i.e., option#2 or option#3 ) once the Fantom TVL > some threshold (e.g., $100 mil TVL)
One thing I would also like to point out is that for option#3, the pro-rata will only apply to ALPACA portion of the rewards (emission + LYF performance fee)
Grazing Range would not be pro-rata but rather works this way
- BNB Chain GR: all rewards go to BNB Chain stakers
- Fantom GR: 80% of rewards go to Fantom stkers and 20% goes to ALPACA stakerss
1 Like
Since there are still some discussion on this topic, I will put up to voting for AIP2.2 next week.
1 Like
Yep, I agree on going full path and starting with option #1 anyway.
Do you confirm that option #2 includes option #1 and that option #3 includes options #2 and #1?
Very good point.
I think that if we go with option 1 first in all cases, we will see what happens with the standalone vault on Fantom: Higher initial APY% might attract more users to lock their tokens and APY% might balance out on both chains… so then what would be the point to make it more complicated?
Maybe we can add an Option 4, it means running option 1 immediately but the Vault will be slowly moving to Option 3. I just can’t easily agree Option 1.
Yea, both can be seen as option #1 with some extra rebalancing.
Option #2 is just option #1 with a unidirectional conntection(ftm → bsc) and option #3 is option #2 with a connection back from bsc to ftm for redistributing protocol rewards.
The only concern/thought I’m having is that for fantom stakers moving from #1 to #2 is just taking away earnings (a drop of 20%) without any compensation (in the short term)
To summarize what I have heard so far, it seems like the best course of action would be to:
1.) Implement Option#1 now, regardless of the voting outcome.
2.) If Option2 or Option3 wins, we will only start the additional development for those options when the TVL on Fantom is > 15% that of BNB Chain. (This would roughly put Fantom’s TVL at $125 mil. A lower TVL would be an inefficient use of dev’s time)
** Note that depending on when the TVL target on Fantom hits, the development team might not be able to start development of it right away pending on-going work, but it will be scheduled into the next available sprint.
1 Like
Great!
Also what would be the timing for the option #1 release?
1 Like
Tentatively around the end of this month - early April.
1 Like
you do not think that it is not objective to vote without having a single GR user on Fantom?
what do you mean exactly?