blockworks.co
As a retired navy veteran, I’ve always been a fan of history.
History has been known to serve up some great quotes that deliver a certain panache to the situation. On Dec. 22, 1944, General McAuliffe, who led the US forces dug in at Bastogne during the Battle of the Bulge, delivered the following reply to a German request for surrender — “Nuts!”
Perhaps more widely known is the message by Jim Lovell aboard the Apollo 13 spacecraft, delivered to mission control on Apr. 14, 1970: “Houston, we have a problem.”
But more recently, I’ve come to love the post of a certain developer for the memecoin Slerf, who on March 18, 2024 captured the X-verse’s attention by tweeting — “oh f***” — after realizing there was a $10 million problem.
A lone voice piping up in the X-verse, the initial tweet was followed up with an announcement: “Guys I f***** up. I burned the LP and the tokens that were set aside for the airdrop. Mint authority is already revoked so I can not mint them. There is nothing I can do to fix this. I am so f****** sorry.”
The statement is so full of remorse, self-awareness and apology, I have developed a sympathetic reaction to this luckless developer. And fortunately for Slerf, what should have been a finishing blow to this team (and I use the term team lightly) has turned into a chance for the crypto community to come together. Because this is a memecoin, the next day $SLERF did what memecoins do: rally and rally hard to a market cap of over $400 million with trading volumes on Solana that exceeded $3 billion in two days.
Amidst all of this memecoin mania, there is a teachable moment.
If you are part of a high performing organization, then chances are you value learning as a team, especially from mistakes. Even better, learn from mistakes that others have made. That’s next level performance for you.
It all comes down to risk management, which is definitely not unique to the crypto universe. Specifically, once identified, a risk can be removed, mitigated or accepted. Let’s see how this plays out.
Our developer at Slerf made a few follow-up posts that add insight to what happened — essentially, he thought his initial operation to burn a portion of the LP tokens with a third-party tool failed, and proceeded to then accidentally burn the remainder of the LP tokens on hand.
This didn’t have to happen. There were inherent risks in this operation that could have been successfully mitigated with structured risk planning.
Lessons from Slerf for your organization
First, think of your software and infrastructure as a layer of security protocols.
A high performing organization with a top notch chief information security officer (CISO) will create an environment where critical infrastructure operates internally within a firewall to be able to maximize protection against intrusion.
But this CISO will also be highly concerned about self-inflicted casualties. Examples of policies that could be enforced to preclude own team errors: allowlisting of addresses for asset movements, enforcement of four eyes authentication for critical operations, and controlling the tech stack to ensure third party applications are not downloaded or added as extensions to browsers like wallet vendors or IP access controls.
The first approach is to remove the risk. In the narrative of the Slerf mishap, any one of those above items would have prevented the execution of a mistaken token burn.
Third-party tools for token burns are a provider of convenience, not an essential. And professional asset managers do not take movement of funds lightly. They will ensure that any significant opportunity to interact with funds are appropriately derisked with strong policies that fit into planned-out risk management strategies.
A robust treasury management tool will eliminate single point failures, giving the organization the ability to apply four eyes principles to authentication as needed for all movements.
The second approach is to mitigate the risks. Sometimes, we can’t remove all the risk to critical operations, but our needs dictate moving forward: One example of how to do so is to make tools accessible through a single workstation and a single address loaded into the third party wallet tool, another is to maintain four eyes protection even with third party controlled addresses.
Read more from our opinion section: Slerf investor or not, no one deserves to lose money in crypto
And finally, create standing operating procedures. For example, require that any burn operation performed with a third-party tool must have another operator present to verify transactions as created before submitting.
The most important element, however, is preparation. Identifying critical operations, assessing the risks involved and planning how to mitigate the risks are steps that should take place before moving forward to execution.
But ultimately, it comes down to Slerf and what appears to be a one-person developer team, eager to deliver a new meme token to a meme crazed fanbase. Whether planned or by default, this developer acknowledged the risks involved and said “I got this,” and moved forward without removing or mitigating the operational risks.
But one should never forget about personal risk management.
I shudder when reading the last of the above tweets/posts: “I’ve been up for 3 days preparing this and fumbled at the finish line.” Many mishaps in the military often point to sleep deprivation as a root cause. If we take the statement at face value, the developer was in no state to be operating protocols that put $10 million worth of assets at risk, no matter how edgy the dev thought the caffeine-infused energy drink of choice made him/her.
Personal risk management includes managing your routine to afford adequate rest, exercise and nutrition to the best of your ability, so that you are in peak performance mode when entering a critical phase of operations. Contrary to popular belief, teams should not code themselves to exhaustion. Everyone does have a point at which sloppiness, mistakes and decreased efficiency take over.
I would bet you it happens well before three days of working nonstop.