There has been a bit of chaos on the 1Hive discord today, as it was discovered that somehow a bunch of $ALVIN, the token that was launched on Shenanigan’s Dripp Farm platform, had been unexpectedly minted and sold.
Shenanigans lead developer, youngkidwarrior, had proposed the project on the 1hive forum and had collaborated with the Buzz swarm to launch the token, which would eventually be redeemable for an Agave themed plushie IRL.
The launch didn’t go smoothly, requiring multiple fixes, deployments, and migrations. The account that youngkidwarrior used to deploy the current version of the contracts had been initialized with sensitive admin privileges, which were never revoked. His account has apparently been compromised and used to mint tokens and sell the tokens on the Dripp platform, effectively draining all the liquidity that was in the $ALVIN market on Honeyswap.
While neither 1Hive collectively, nor the Buzz swarm specifically was responsible for the development of the Dripp Farm platform, $ALVIN is a token that was created for and promoted to the 1Hive community, and so this issue reflects poorly on 1Hive and we should see what we can do to help rectify the situation, and we should carefully consider how best to minimize the risk of similar issues occurring in the future.
At the end of the day the market cap of Alvin was relatively low (~50k) and the total liquidity even lower (~10k), and the actual utility of Alvin was as a collectible of cultural significance to the 1Hive community that could optionally be redeemed for a plushie. It’s totally possible for the 1Hive essentially fork the Alvin token based on the balances of the token just before the minting happened, and treat those tokens as the canonical Alvin tokens for the purpose of redemption. Additionally, if we funded a proposal for 10k dai in Honey we could establish the same level of liquidity and price for the new tokens as well. Of course we would also need to find a competent developer or two to execute on the rescue plans as well.
There may be other approaches worth considering and a case to be made for doing nothing and moving on, but I personally would be supportive of some sort of proposal to save Alvin from the dripp-ocalypse.
Another topic that event has raised is how this happened in the first place, and how can we better avoid finding ourselves here in the future…
1Hive is a very decentralized community, its one of the things that sets us apart and makes us unique. There isn’t a core team to blame when something goes wrong, and lots of cool stuff happens simply because people feel empowered to take initiative and do cool stuff… but the 1Hive brand is a common resource that we all share and it’s imperative that we work together to maintain it.
When something like what happened with $ALVIN happens it hurts the 1Hive brand. When we promote something that doesn’t live up to our communities quality standards, it has ripple effects across the community and impacts other projects we have collectively invested time and resources into.
How can we ensure the integrity of the 1Hive brand, while at the same time ensuring that anyone can take initiative and help build? I think this is a big open question, but will throw out some possible ideas…
- We could use Celeste to maintain a list of 1Hive endorsed projects, with requirements for inclusion being a set of best practices. This way people can work on projects, get excited about them, and even promote them, but it is clear to everyone that there is no endorsement from 1Hive unless they make it into the list.
- We could establish norms for how we communicate, especially among members and organization (like buzz) that are considered reputable and trusted by the community. And individually we can evaluate the reputation of different
We have a bug bounty program that covers smart contract vulnerabilities, but we currently do not have a formal process for managing which contracts are eligible for the bug bounty program.
I think we should create a process for developers working on 1hive related code to have the bug bounty swarm review their code and approve them for eligibility for the bug bounty. This would help ensure a formal code review happens for launched code, and can help provide a strong signal to community members that code has more experienced eyes on it.