Vampire Attack: Update
Great feedback
Our community was incredibly responsive to the experience and in particular the gamification element of the Vampire Attack, despite some issues we encountered at deployment.
One of our community members also created a tutorial how to participate through a medium article.
We would like to thank you for such great feedback and take the time to highlight areas of improvement from the initial deployment below, including changes:
- Countdown
Based on our experience, we would recommend other teams not to do this. We initially committed for public usage at 20:00 CET, and some lead time to review internally any final changes and bug fixes. We have been testing the Vampire Attack on a fork of mainnet, however, on mainnet production there are always unforeseen bugs such as timing and querying of prices. We, therefore, had to move the public usage time from 20:00 CET to 00:15.
2. Documentation
Our docs were made public for users to inspect fully the functionality of the contracts. We are currently awaiting API keys from docsearch to enable indexing of our docs and allow quick searching. You will also find documentation regarding our core product, staking, token, token vesting, subgraph, and guides.
3. Loading screen
To provide a fully immersive gamified DeFi experience, we replaced the black screen loader with a more fitting one, bringing back the retro gaming vibes.
4. Cooldown period dHedge
Some users were not aware of the cooldown of particular tokens enforced by dHedge, see here external implementation if purchased directly through their UI. However, if purchased on a secondary exchange, such a cooldown does not apply hence buy and stake is functioning for this cabin. In return, we have now implemented a cooldown directly on our UI for the applicable tokens in favour of a better user experience:
5. NFT URI
NFT URIs were pointing initially to a URI that was rewarding a different NFT than the one that was displayed on the UI. We were referring to an old URI, however, this gave some great vibes from 1990s games where you didn’t always get what you’d expected, which added a more fun element to the whole gaming experience :)
6. Buy and Stake: MEV
By submitting a TX themselves, one user was hit by a MEV bot, which resulted in a loss of $25k*(6.5 ETH). In response, we disabled buy and stake directly through our UI until we could further inspect directly what the issue was. We came to the conclusion, that it was due to the user themselves however, we reimbursed the lost funds.
7. Buy and Stake: Slippage
Some users were purchasing low liquidity tokens with high slippage, despite of the slippage being visible in big red text. To reduce users getting rekt by slippage, we disabled buy and stake. Buy and stake will be going live again soon, with additional warnings regarding slippage: including $ value of entering token and exit token that will be staked.
8. Staking duration
We mentioned in previous articles and Discord the migration flow, and that indexes will be migrated at a later point. If you’re unfamiliar with the migration, we recommend reading our previous blog and docs. We have now implemented an additional tool tip on our UI to inform users of this time lock.
9. Etherscan verified Contracts
We had issues for verifying the contracts and had to manually verify some of the contracts . During a period of 12 hours, some contracts weren’t verified, and we prioritized fixing the front end bugs that occurred from production usage.
10. Multisig Controls
We would like to shed some light on the multisig set-up for the liquidity migration. This route is known to be safer upon first deployment prior to transferring ownership to the governance module. As the governance module is not currently live, following a multisig approach rather than an EOA is safer as multiple entities are required to approve the TX prior to submitting. By following this approach, a correct execution of the migration is capable, and pay the gas costs for the migration.
LEGAL DISCLAIMER
This article is neither an offer of nor marketing material for financial instruments or financial services. Enso Finance is not regulated under any financial market laws in any jurisdiction. It is only the developer and provider of the ENSO platform and protocol. Due to its decentralized nature, the ENSO platform and protocol is neither controlled nor operated by Enso Finance. Enso Finance is neither providing financial services nor offering financial instruments. Any liability is excluded to the extent permitted by applicable law.
