Overhauling the xXTKa staking module to increase confidence and long-term sustainability of xToken Asset Management

How xXTKa currently works:

When users stake their XTK in the xToken Management module they will receive receipt ERC20 tokens, xXTKa proportional the the amount of XTK they staked. As fees generated from xToken Management products are harvested they will be distributed to xXTKa holders by being converted into XTK and subsequently distributed to the staking contract.

To incentivize long term staking participation xXTKa is subject to an unstake fee, currently configured to 1.75%. Exiting the staking module is immediate and the fee levied is split among all users remaining the xXTKa module. However XP-7 discusses making changes the unstake fee and distributing a portion of it to the xToken treasury to be better aligned with protocol growth.

The xXTKa module is being incentivized with XTK distributed to stakers from the Community Vesting Pool, which was allocated 50% of XTK total supply at genesis. The current distribution schedule is 1% of XTK total supply to be distributed as incentives over 3 months starting Monday, July 26, 2021.This alone gives xXTKa ~54% APR currently.

There are no risks, besides contract risk involved with xXTKa. Stakers in xXTKa are not subject to any form of slashing and their XTK isn’t really ‘at stake’. Stakers are receiving rewards, yet not providing any value or serivce to the system. Despite having ~$18M worth of XTK (now down to ~$7.5M) staked at the time of the recent xSNXa exploit which resulted in ~$4.5M in losses to xSNXa holders, xXTKa stakers assumed zero losses. Instead XTK from the dwindling Community Vesting Pool was once again used to compensate the losses of xSNXa holders. This is not a sustainable behavior. On top of that the amount of XTK distributed to exploit victims currently falls far short of full remuneration, All of this is causing potential and current xToken users to re-think using the product. The AUM of xToken has been decreasing since the Aug 29 xSNX exploit and it’s not just due to the market doing poorly in general. The outstanding number of xU3LP positions noticeably went down.

Proposed tweak(s):

To regain trust and confidence in xToken Asset Management products as well as ensuring the long-term sustainability of xToken, I believe an overhaul of the xXTKa module is necessary. My thoughts are as follows:

  1. In return for earning xASSET fees and incentives stakers in the xXTKa module should provide some service or value to the system. To do this I propose we put their XTK ‘at stake’. In the event of a future shortfall, users staking in the xXTKa module would be subject to having their XTK slashed to reimburse the losses incurred by xASSET holders. This slashing percent can be capped as commonly done in various other DeFi protocols such as Aave, and Reflexer for example. Or potentially be able to be entirely slashed such as in dYdX. This method may not necessarily ensure full remuneration for xASSET holders, but at least provides a long-term, sustainable backstop to provide confidence in the product(s). Projects like MakerDAO and Aave also have the last resort ability to mint new tokens in the case that they can’t cover the outstanding shortfall. However I don’t believe this is a viable option for xToken currently, as the project does not yet have a large enough community nor backing of major VC funds that could act as a buyer of last resort like MakerDAO and Aave do.

  2. With the implementation of slashing, stakers should no longer be able to immediately exit xXTKa and a cool-down window will need to be implemented. In the event an exploit happens, stakers should not be able to exit the staking module prior to it being discovered by the team or community and being decided via governance that a slashing will be necessary to reimburse xASSET holders. The exact length of this cool-down window is up for debate, but >1 week would be standard.

  3. Immediately after an exploit the value of XTK and therefore the backstop is likely to decrease dramatically (and has done so each time previously). To counteract this I propose instead of staking pure XTK in the xXTKa module, we introduce the use of LP tokens. An ETH:XTK or stablecoin:XTK LP would significantly dampen the volatility in the value of the backstop, allowing for greater confidence that xASSET users could be reimbursed. This method also has the added benefits of creating a strong liquidity pool for XTK and as such would no longer require a separate allocation of XTK from the community vesting pool for incentivizing that single purpose as has been done in the past. Aave and Reflexer are among the projects that have made use of this method to great success, as seen in the AAVE-ETH Balancer Pool Token and the FLX-ETH Uniswap V2 LP

  4. Seeing as under this proposed system xXTKa holders will be at risk from losses incurred by xASSET holders due to exploits, hacks, oracle issues, etc. a successful governance vote should be required from a threshold amount of xXTKa holders to introduce any new xASSET. It is expected xXTKa holders with their XTK at stake will be more discerning and require higher levels of assurances that the products have been coded and implemented safely and extensive testing and auditing has been carried out prior to launching.

This list is not an all or nothing list and in my view implementing any number of these would go a long way to instilling confidence in xToken Asset Management products for current and potential users. It is also dependent on the launching of the governance/DAO platform first, as such a large overhaul would require buy-in from the community and because the operation of it requires active governance like it points 2 and 4.

I’m also interested in hearing of any other methods that could be implemented to achieve the desired result of increasing confidence in and long-term sustainability of xToken Asset Management products.


I like some of the ideas here, would likely require an entire overhaul and lots of time. I would still prefer to stake my XTK alone to avoid IL but Aave has the choice of both so its possible. The falling AUM has also been worrying me and I don’t mind putting my “stake” at risk in a proof of stake system to benefit the ecosystem especially considering the apr.

The benefits of the current system is simplicity and the fee goes to hodlers. With the introduction of the staking period, would your proposal eliminate the unstake fee?

Some other dudes on xp-7 proposed the current model except where exit fees follow

a curve like this based on time staked.

I think the slashing is not currently economically viable given poor liquidity and marketcap but hopefully in a few weeks this will change “Wen Lending?” comes out and we are on an uptrend. Personally I like collecting exit fees from unstakers so I am still in support of XP-7 in the short term but I think there are a lot of good ideas here that could be combined giving XTK a truly unique form of governance and utility as a token in the future.

1 Like

No, I believe the unstake fee would still be useful in serving it’s function as stated in XP-2 of attracting and rewarding long-term stakers.

This is also why I believe staking LP tokens would be highly beneficial to the ecosystem. There’s only ~$1.2M worth of XTK liquidity on DEXes in the Uniswap V2 and Uniswap V3 pools, yet ~$7.5M worth of XTK in xXTKa providing no value to the system. If that $7.5M was instead required to be deployed as LP tokens before being staked, the liquidity of XTK on DEXes could easily be an order of magnitude deeper.

However I’m aware there are some users who prefer not to LP and potentially incur impermanent loss, so offering both single staking and LP staking would be a good option. Another option would be using a skewed pool, such as a Balancer 70:30 XTK:dampener pool to reduce impermanent loss while adding liquidity.

1 Like

Very high Iq stuff here. Hopefully we get that liquidity with Kyber LM and the upcoming XTK/Weth clr pool because as it stands the true value of XTK is traded on thin liquidity and therefore unknown. I wonder if it is possible to do single sided liquidity on Bancor for XTK as a layer beneath the staking module…

1 Like

@CosmicCollusion could you please summarize your proposals in single sentence bullet points for low IQ folks like me?

Here’s what I’ve understood from your proposals so far:

  • Get a percentage of the exit fees to go to the xToken treasury. What’s your % proposal?
  • In the event of a future hack, draw funds from the staked XTK using a slashing mechanism with a cap. What is your % proposal?
  • Introduce a time-lock mechanism for unstacking of 1 week.

Is my understanding of what you are proposing correct? What other points have I missed? I couldn’t clearly understand if you suggested the exit fee be changed and to what.

I haven’t proposed any change to the exit fee, that’s a separate proposal.

My proposal is:

  1. Introduce slashing to xXTKa, to be used as a backstop in the event of a shortfall due to exploits, hacks, oracle errors, etc.
  2. Introduce a cool-down period for exiting staking, to mitigate stakers being able to avoid slashing.
  3. Use XTK LP tokens instead of only XTK in the xXTKa staking module to dampen volatility of the backstop value.
  4. Require xXTKa stakers to vote on the launching of new xToken Management products.

I have not stated any specific values for any of these as I would like to see some discussion on those values from the community.

1 Like

Nice, thank you for the elaboration.

  1. Introduce slashing to xXTKa, to be used as a backstop in the event of a shortfall due to exploits, hacks, oracle errors, etc.

Adamantly opposed. There is a post in relation to security that has not been acknowledged or responded by the team. I’d like to see a public commitment of the team to security and what concrete steps / changes it will take moving forward. So far I’ve only see random mumblings on discord.

After 3 hacks, we need to know what new policies have been instated. They need to be public policies that everyone can review and check against the open source repositories and operations of the project.

Until that is done, the community has no place taking the burden to a future security breach. If anything, it implies that the current status operandi is good enough and hacks are a product of chance, “product complexity” and natural occurrence (an act of god).

  1. Introduce a cool-down period for exiting staking, to mitigate stakers being able to avoid slashing.

Not very happy with this either, there’s already a withdrawal fee. It’s one or the other imho. Again, it feels like this policy encourages more risky development practices and operations by the team against security as it mitigates slashing.

  1. Require xXTKa stakers to vote on the launching of new xToken Management products.

Yes, yes and yes. the “Launching” stage is a bit too late, I’m assuming you meant to say at the conception / design phase. This goes back to the topic of xToken transitioning into a DAO. Which has been long overdue.

@CosmicCollusion I understand where you are coming from and what your concerns are. We share the same concerns, however I believe we disagree on how to address them. I do not believe patching the protocol with bandaids to be the appropriate mitigation to the risk of getting hacked again. I have a firm position on what the course of action should be to address that problem and I have stated it above and in my relevant post.

It is very good though that you came forward with your proposals as you’ve ignited a debate around how staking can be improved. Many good ideas were proposed on the original XP-4 proposal. These same ideas are refloating now on the discord chat.

I am of the belief that it is these ideas that should be pursued, rehashed and discussed. Their purpose is to improve the overall experience and reward schedule for XTK staking. Ideas and questions like:

  1. Having the staked position be tokenized and/or tradable?
  2. A vesting period for the staking returns?
  3. More aggressive with how much of the supply goes to the staking module?
  4. Is there a defined quota of supply percentage that needs to be given for the next year? What about the quotas of year 2, 3, 4?
  5. Variable APY based on the time locked?

I’m sure there are more proposals and ideas. A DAO of the stakeholders would make sense to exist in order to appropriately debate, refine and finally vote and decide on each one of those ideas and or questions.

Staking is here, governance now is a flip of the switch to allow the staked XTK holders to vote. Platforms and solutions are readily available for that. What is stopping us from making it happen even if it’s not perfect from the start?

While I believe the team did respond in the discord, I do agree it’s not a great look leaving the governance forum un-responded like it is. There may be people that are new to the project or don’t follow the discord close enough that come along and see it and get a bad impression. Simply pasting their discord responses over here would be better than nothing. From what I’ve gleamed there seems to be some kind of personal history/beef between you and some team members, and I don’t think that should get in the way of responding.

Not very happy with this either, there’s already a withdrawal fee. It’s one or the other imho. Again, it feels like this policy encourages more risky development practices and operations by the team against security as it mitigates slashing.

I don’t know how you draw the conclusion this would encourage more risky development practices. Do you mind fleshing out your reasoning here?

In my view the unstake fee and the withdraw period have different purposes not a singular one, so I don’t see why that can’t both be implemented. The unstake fee is there to reward and encourage long-term staking participation. The withdraw cooldown period is there as a necessity of implementing slashing. A slashing mechanism where stakers can easily and quickly withdraw between an incident occuring and a slashing being voted on by governance just wouldn’t work.

Yes, yes and yes. the “Launching” stage is a bit too late, I’m assuming you meant to say at the conception / design phase.

No, I meant the launching phase. Requiring on-chain votes for all the details during conception and design would be overly cumbersome and not very scalable. One on-chain vote per new product launched seems reasonable though. Off-chain snapshot like voting for deciding which products the community is most interested in seeing developed, as well as spinning out work-groups for each product where community members with the interest, skill, and knowledge to contribute and work with the team would also be great.

Thanks for this CC. I fully agree directionally on these changes. Staking should serve some useful service in the ecosystem when possible. At our current market cap, these changes are challenging to implement but I think that we should work towards all four of these suggestions.

For the Lending staking module, we’re already working towards this sort of Aave/Maker-like model where tokens are the backstop for losses on the protocol. We won’t have this live when Lending launches in a few weeks but it is absolutely the goal and intention.

On the staking LP token point, I would definitely support some model similar to Aave where both single-side and LP token staking have access to protocol fees. We’ll have to engage the community on this discussion when the time comes.

On governance, we’re still working on our more long term proposal, but part of the idea is that a committee of elected token holders will have veto power on certain contract changes or additions, so this would be consistent with the ideas you’re proposing.

Very glad we have this conversation on record in the gov forum. Extremely relevant and important long term discussion

Hey CC, thank you for the response,

Starting out, allow me clear the air, there is no personal history/beef, not from my part at least. I used to be in very good terms with leadership and the team, up until I made the security related post. Since then, leadership and team did an 180 and instead of addressing the issues and topics, they engaged in an unfair and unfounded personal slander, libel and pettiness campaign. Which while disappointed me, I can justify given they have much more at stake than I do.

In regards to your particular question:

“I don’t know how you draw the conclusion this would encourage more risky development practices. Do you mind fleshing out your reasoning here?”

Unless I have misunderstood you, you are answering your own question in your original post:

And in your latest reply you mention:

I am only responding to what I understand that you are stating. Which is, the “slashing” mechanism, is there to prevent a run for the bank in case of an “incident”. If that’s not right, please do elaborate further the purpose and what drove you to the slashing suggestion.

That gives us a glimpse of what governance will look like on xToken. If I understand what has been said here is that the committee will be just one division of governance, with veto power. That implies that decision making will happen from the team and the committee will act as a check and balance.

I won’t comment further on this, as it’s off topic to this particular thread and deserves its own post where all the members can express their believes and opinions.

Hey Than - a few notes:

  • Half of the Discord has attested to your unimpeachable bad faith in all things, so it’s logical that you’ve moved your campaign over to the forum. I regret fanning the flames with this response but unfortunately it’s difficult to leave mistruths posted on our gov forum unchallenged
  • Your falling out with the team originates with an instance where we had to ask you to be more careful about your contributions to the Discord because you were consistently providing incorrect information to community members. This was unintentional and not malicious at the time, but as has been noted by several members of our community, your fragile ego and desire to be seen as a very successful technology leader are the primary drivers of your behavior. This conversation on your poor contributions to the Discord was followed shortly thereafter by an instance where you insisted that the fact that you didn’t read our tokenomics proposal but then were answering questions incorrectly about our tokenomics was a reflection on us rather than you.
  • As for your offenses in our community and others, they range from an 1) intolerable level of concern trolling, 2) a “grants grift” where you propose extravagant solutions for simple problems at the expense of grant committees, and 3) encouraging community members to commit suicide.

Based on your previous patterns of behavior, it’s likely that you’ll respond to this by noting that I haven’t responded to the substance of your post. My response to that is that we’ve discussed revamped internal security processes at length in Discord and on Medium. You - one of the least constructive members of our community - do not get to demand a response on bad faith, ego-motivated gov posts. Our community has a right to hear from us on these issues, as they have.

Last point to Than - your inferences on our WIP gov proposal are incomplete at best, but we’ve already established that your concerns w/r/t xToken are motivated by a vindictive ego more than anything.

Finally, @CC, I’m really not sure where this idea that we “leave the governance forum un-responded” comes from. I would encourage you to retract that statement because it’s not true. You posted on a Saturday and I responded on a Monday. And almost all previous posts have been responded to.

I was referencing the “Vulnerabilities and Best Practices” thread Thanpolas started.

If that’s not right, please do elaborate further the purpose and what drove you to the slashing suggestion.

I’m still not following your logic where slashing encourages more risky development practices. If anything it’s the exact opposite and should discourage it as user funds are increasingly at risk. I very much doubt the current team and devs are pleased about what has happened in the past and didn’t want any users to lose funds. Besides coupled with my fourth point of requiring governance votes to activate new products, any issues will hopefully be caught during the voting phase and not have a chance to be activated.

Let me put it this way. I wouldn’t want to put my staked XTK at further risk without the team first publicly and succinctly committing to concrete, verifiable, measures towards better development practices and a security mindset.

MJC mentioned they’ve stated the measures “at length”. I’ve searched all the recent medium posts MJC is alluding to. The most relevant and only one that mentions “measures” is the postmortem post and the only measure going forward was the sunsetting of the xSNX contract.

On discord, MJC mentioned something something about 2 code reviews per PR. So far, and I am referring to the timespan between the recent, 3rd hack of Aug 2021 and today, I have not seen any change on the development practices based on PRs created on the open source repos of xToken[1], [2].

[1] PR 15 of xU3LP, no test cases and only a single code review.
[2] PR 6 of xtoken Management Staking, no tests and no code reviews at all, unless merging by a non-author is considered a review