Alvin and the Dripp-ocalypse

🐝 Community
#1

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.

Saving Alvin

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.

Decentralized Brand Management

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…

  1. 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.
  2. 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

Bug Bounty Eligibility, and Improving Community Code Review Processes

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.

27 Likes
Alvin plushie update
Alvin plushies... Down to the wire
Water💧 Shared Liquidity Proposal
1 Hive Monthly Recap - May 2021
On AUTOMATION as an approach
1 Hive Monthly Recap - August 2021
#2

A bug bounty swam and an authoritative list of Celeste endorsed projects list sounds like the way to go on both fronts.

I think the discussion should be open, free from enforced norms, but that a dev will have to go through the hurtles necessary before they can expect any kind of 1Hive tweets, retweets by 1Hive community leaders, or anything in an official capacity.

When launches don’t go well I see that as symptomatic of a foreboding ailment, that potents instability for an organization’s future and a red flag as a low chance of a project achieving longevity.

3 Likes
#3

It’s named shenanigans.

They need to pay for their mistake and own it so it doesn’t look any worse for agave.

2 Likes
#4

Agree completely with your analysis. I am just doing a mind dump of questions that I have which I hope someone from the community of devs can reply to:

  1. I assume after having gone through some of these hiccups with Alvin, AGAVE (this is in my time here which is very short) and others which I may not know of, i would assume that by now we would have some processes in place that would avoid some of these issues form re-occuring.
  2. Could we not use like a minimum accepted process in the blockchain dev space to ensure that the holes in the cheese are not aligned and allow for exploits that could be avoided if we had more eyes and testing of the SCs?
  3. Should we look into starting a process now prior to the release of HoneyFarms to ensure that we can address any avoidable issues?

In terms of recommendations:

  1. I have pushed for this in another DAO but did not get anywhere - but will try here as well - why not form like a peer review group and have a defined process that each 1Hive or associated or endorsed project has to go through? Obviously this will cost but I assume to keep up our brand name - we could spend some from the common pool to pay for such a peer group to be set up so that prior to the launch of each project the peers go through the process and critical parts of the code to ensure they do not see any obvious vulnerabilities.
  2. Also I would really push for a training academy for interested devs at all levels to gain and improve skills in relation to reviewing code and testing code. I may be naive to think this way but I assume there is a different skill set required to dev and test. So if we can establish a swarm that can provide review and testing as a service we could offer this as an alternate to full audits which may not be possible for small scale projects. This could even be a viable income stream for the swarm and a marketing channel for 1Hive.

I am not technical enough to understand the nuances of developing code but I think establishing process and following it will most certainly avoid at least the simple/obvious exploits/issues.

3 Likes
#5

Thanks for this post Luke.

After a crazy day, I can’t help, but just feel my shortcomings on this project deeper then ever. I think it was a great idea that failed due to rushed, disorganized execution. I can’t quite say sorry to the entire decentralized 1hive community,

But I am sorry. Sorry for the stress. Sorry for the money lost. And sorry for any damage I caused to 1hive and the buzz swarm. I hope my continued action shows that I still care.

On the topic of what to do next.

I think there are a few things plausible that can be done independent of one another.

  1. First off, the fork

A fork sounds great at first glance and sounds like the right thing to do. Today I started work on the snapshot of both tokens, set for the block before the minting exploit. It should be good to return the token back to it’s previous state. The Liquidity will have to come from somewhere. Shenanigan is still small, especially with the current market. There is no way we could fund both liquidity pools with $PRTCLE or from our treasury and I appreciate 1hive taking this project seriously enough to consider refunding the pool.

To remedy the issue some, I think Shenanigan would accept paying the devs that do work on the fork. Obviously I will be giving my time to this where I can. Dripp is still a project I believe in and want the best for.

  1. 1st edition ALVIN

For the trouble I have caused, I will be sending special 1st edition ALVIN plushies and NFTs to anyone who held over 1 ALVIN at the snapshot. The entire point was to do this for the plushies. Giving the early token holders who had saved a whole token something special feels right. I’ll be sending an announcement with a link to a form for those that want to opt in to the first ed.
plushie. Those that don’t want the plushie will still receive the NFT.

  1. DRIPP V2

Dripp was a great idea, with a failed execution. Dripp V2 is still happening.

Dripp V1 was a 2 week hackathon project. It’s not an understatement to syy it was not finished at launch. When V2 launches, ALVIN holders will receive an airdrop of community tokens for being early adopters. The mechanisms and distribution numbers are still in early phases so nothing can be said, except there will be a reimbursement. We hope that a full fledged, audited, project can help regain the trust we have lost here at 1hive. Again, it was only our intention to do right, and unfortunately we caused more harm than good here. I can shoulder most of the blame since I’m the only one who had hands on the project.

On the topic of a process for regulating projects,

I think it’s a great idea. I hate being the guinea pig, but it seems like I was just that. The decentralized world is a jungle we are all trying to navigate.

I can add my help (if it is wanted here). While tensions are high, and some might be angry… I am a competent developer. All hands on deck if you ask me! I think its the least I can do while devs are so hard to come by in the space. I also think I feel most the drive here as it would have been a completely different experience for me to have a dev swarm to talk to and hash ideas/problems with. Its not easy to build alone.

Overall, I can only apologize and keep building for it. The sting is fresh, but it’s not going to stop me, Shenanigan, or 1hive. Let’s recover and come back stronger.

2 Likes
#6

Thank you Luke for making this post, long awaited on the 1hive Forum.

I am personally quite disappointed; Communication has never been very smooth, little bugs here and there were a constant partner of the whole project since the beginning, and being someone who can only try to help on the communication side, I think that the holders should be protected in any way possible because entrusting the project with their own money.

The negative impact that this can/will have on 1Hive and Agave is hard to quantify, so that’s just a straight loss for our beloved ecosystem.

Generally speaking I think any way Luke and other 1hive devs will judge correct to proceed, that will be my preference.
Anyway, not here to bring negativity. Yesterday @YoungKidWarrior proposed to make a call to fix the situation avoiding the hundreds of messages.

Please, if this is happening, we absolutely need to inform the community. The “church” call could give a very broad audience the possibility to be at speed. This, in my humble opinion, is absolutely due to our community.

6 Likes
#7

Since she can’t afford the liquidity and 1hive looks to be fronting the bill maybe a 5% particle to 1hive dependency from source cred is a fair compromise.

6 Likes
#8

Isn´t it a bit late now to make an announcement?
Now it should be an announcement with the solution that will take place imo.
I think making an announcement with what happened as a waste of time. I am not saying that the issue shouldn´t be introduced in the first lines of the announcement, but making all the text about it isn´t the thing to do.

#9

I think the morphosis swarm has been working on providing the said training. (Gabi’s running a rather under-attended, under-appreciated course for teaching Solidity and development on Ethereum. Perhaps, we could market these courses via BuzzDAO?)

3 Likes
#10

Thanks for opening this forum discussion, Luke!

With regard to the current situation, I think it’s a mix of two things-

  • Issues with the contracts(that’s on Shenanigan)
  • We didn’t audit the contracts or see if it has been tested or if it’s complete before launch.

On the contracts from Shenanigan-

I won’t exactly throw full “blame” here, but I think they were rushed due to the less time for development before agave was launched. However, at the same time as developers, it’s their responsibility to ensure that the developed application does not cause harm to the community or the eco-system. For which, maybe I think there’s some need of transparency with respect to if a project is ready, before launching or marketing them. (Perhaps, if they had communicated this to us beforehand, maybe some devs from the community could have agreed to help them out, or we could have delayed the Agve launch by a week or so)

On the Auditing-

As a community, 1hive has a great reputation on xDAI and it would be really bad if things were miscommunicated as “1hive-screwed-up”, when it’s actually “some X project associated with 1hive screwed up”.

Maintaining a list of endorsed projects on Celeste would be great. Perhaps, we could decide on some QA and testing before anything is officially deployed. (something like- A test-period launch of everything on RInkeby for at least 15 days, or something where anyone from the community can catch errors and report them. We could also host security audit bounties before major launches. Making unit tests/code coverage reports and Setting up some form of CI, that runs automated tests on all code, on every push, before launch).

Since we don’t have a core-dev team, perhaps we can use some form of community reputation for devs to have a swarm or some members of a swarm, that can review the code as some form of auditors?

2 Likes
#12

TBH I am incredibly frustrated with the situation, and I can’t say im surprised this happened. From the interactions I have had with you in public and private, you have had a remarkably cavalier attitude towards the 1Hive and Agave reputation

After incorrectly deploying the ALVIN token three times AND screwed up the drip contract losing people’s rewards, I asked you to slow down. You were not even testing things before pushing them into production, let alone getting someone competent to review all your work. Being a longtime 1hive member and an Agave seed, I asked you to slow down, and you point-blank refused. You told me to “chill”, “no one lost money”, and continued on your merry way.

Now here we are. Financial damage you cannot compensate and significant reputational damage.

With all due respect, I strongly disagree with this! Deploying stuff without testing multiple times, unnecessary admin controls over the contracts and losing the admin keys!!! I would rather you stepped down from working on anything associated with Agave or 1hive in an official capacity.

7 Likes
#13

an announcement was already made.

I am talking about informing the community of an eventual call in which decision will be made. It is fair to suppose that many people will want to check this one, and we can show how 1Hive handles these sort of situations by opening a clear and open conversation between team and community.

2 Likes
#14

I remember when we started the collaboration and I asked YKW for examples of NFTs he’d minted he showed me the NFT for Unisocks.

We need to save Alvin, but YKW needs to not be in it.

The whole thing is shady.

That too many Alvin were minted, by 20%, is shady.
That there was potential to mint more coins in the contract is shady.
That the private key to mint was posted on Github is beyond belief.

We still don’t know who did the minting.

:neutral_face:

5 Likes
#16

Thanks for writing this, this is kind of what i was talking to you yesterday on the alvin channel and glad we were aligned.

I think that those are some stuffs that i would love to see, a checklist of task needs to be done before launching a 1hive project like:

  • A forum post with contracts data/repos
  • Community testing phase
  • Coordinate with the bug bounty members an internal audit
  • Deployments on working days unless is broadly coordinated to be a weekend.
3 Likes
#17

I’ve seen we’re sort of afraid to establish certain norms because it “damages the independence/decentralization” of the swarms and the community in general, but when the decisions made by some affect positively or negatively (just as in this case), the level of dependence between all of us is evident and it isn’t wrong if you ask me, we just can’t keep trying to act like it’s not there.

With this I don’t mean that we have to tell everyone how to work, each group should work as they feel more comfortable; but it would be good to reach a certain level of consensus about how swarms interact with the outside world and with other swarms.

Luigy said yesterday on discord “What’s the degree of freedom for a swarm?” and I think that’s an interesting and perhaps underestimated topic. Another example I have in mind is for instance, the Pollen DAO has been indirectly setting certain community standards and moderation, and I don’t think that’s bad, but isn’t supposed to be Fauna’s job? Shouldn’t Fauna have taken the reins of the situation about small but constant situations in our community?

Speaking of the Alvin issue in particular, I quite agree with the proposed solution right now, adding this Monstrosity’s comment.

1 Like
#18

Thank you green for communicating this. Many I don’t know the full story and it’s good that you shared your contribution. Btw for those who don’t know Buzz also said slow down and before launch you may have noticed they backed away from the project. I think we did everything we could. The only other thing we could have done is flat out post formalizing our stance. The problem is because this is a decentralized project you had half the people supporting the project and half not so those that didn’t support the project just took a step back as this played out.

What Agave did:

  1. we made sure this project was not on our landing page. We did not want to affiliate agave with the Alvin project.
  2. We separated the discord channel saying no Alvin discussion in agave discord
  3. I personally requested several to not shill Alvin in tg.

What we could have done:
I think we could have publicly made it more visible announcement this was our stance. Our hesitation is we knew some liked the project even some within agave so as a decentralized project you let some do what they want. You don’t want to blast a project others are invested in you sometimes just have to let them play out.

As Luke stated it’s difficult to know how far you publicly denounce a project. Endorsing is one thing denouncing is a bit different.

4 Likes
#19

People now need to do additional research to understand that you had nothing to do with agave and your mistake is not reflected in the work of the agave team - and the project is about to launch.

Your apologies ought to have financial responsibilities and public accountability associated with them. So that you take ownership over the security lapse of your private key, and the inclusion of the minting permissions in a fixed supply token.

It is generous and necessary for 1hive to cover for you now to preserve integrity in narrative for the upcoming projects, and is not an indicator of demand for dripp v2.

The damage of a rug pull burn in defi is an area effect warning flag. The security lapse of your private keys and the inclusion of the mint function is a textbook rug pull, and you or your social group are the most likely actors under suspicion, given the exploit.

To potential / uninformed investors in agave and honeyswap farms - this is an indicator of a lack of security and competence, which increases the risk of supporting these projects - right before their launch.

By not covering these costs and owning these mistakes yourself, you are forcing 1hive to benevolently indicate by its actions that you were a casualty of inexperience in a decentralized community and that the ecosystem is mature enough to where it can make good on failures (that are not even canonical).

The issue here is the cost of repaying the liquidity for the exploit and the public responsibility of the mistake - in a way that does not allow any fallback onto 1hive or agave.

Your shoulders ought to handle those responsibilities.

So if 1hive wants to have successful launches - covering your liquidity damages is putting out a PR fire and signaling that your work is not reflective of the security of the other projects in the ecosystem.

My opinion is that resolving these issues ought to be your focus, if you want to regain trust for v2.

5 Likes
#20

Oh… I see… the announcement was made in their own server?

#21

I think asking for Shenanigan to give 1hive 5% of the max supply is a bit over the top. I don’t think Cred is the way to do this.

#22

I actually take problems with the “wash your hands approach”.

I was endorsed by Buzzdao to build, however I never got any resources from them. I couldn’t even get them to write a proposal.

It’s entirely my fault the key was compromised. It’s not entirely my fault that we are here

1 Like