AL #66: Is Mamori the First Security Product with Revenue Potential?
AL #66: Is Mamori the First Security Product with Revenue Potential?
Somewhere in between security and MEV.
The first thing I ever worked on in crypto (back in 2018) was a universal bug finder.
At the time, few people working on security tooling were exploring quantitative techniques instead focusing on more traditional security approaches.
I built a simple Monte Carlo Tree Search agent that would explore different actions on a contract looking to optimize an outcome (kind of like a fuzzer with an explicit objective function).
I soon realized that in finding vulnerabilities it’s most important to go from 0 to 1, going 1 to n and exploiting a contract for more money is usually much easier.
Unfortunately most machine learning techniques are not very good at going 0 to 1 without specific tweaks like curiosity learning.
I never really returned to this problem until the recent Mamori announcement.
I ended up exploring formal verification which was much better at “understanding” syntax.
Then debugging as a way to assist humans working with tools.
And finally getting into protocol development directly, focusing on techniques and processes that improve security throughout the different stages of design and development.
While I'm happy with where I am now, I had to dig into what Mamori are doing to see if they have truly cracked this problem.
But before, it’s important to underscore just how difficult it is to create a product company in the security space.
The impossible problem
Smart contract security is one of the biggest and most obvious problems in the whole industry.
It’s also deceptively attractive as a domain where software products could have an impact.
There are so many inputs and tools:
The source code
The byte code
EVM simulation tools
Call graph visualizers
Reusable security tools like formal verification engines
Catalogs of past hacks and transaction sequences
Readable audit reports
and many more.
Yet the two most important security measures (by far) are still what you do in development and hiring an auditor.
Everything else is secondary.
Most tools either suffer from a very large false positive rate or false negative rate (or both).
They also don't require frequent use often being most relevant at the internal auditing stage.
Finally, smart people are constantly working on building open source security tools which are very good and more configurable, transparent which reduces the perceived ROI of introducing new security tooling.
Budgeting is another issue. Most teams already budget from audits and see it as a much larger expense than they would like it to be. Adding something else on top that doesn't remove the auditing step is often seen as challenging and teams would much rather dedicate those resources to development.
My approach was to focus on debugging with the hopes of integrating it more frequently into daily development. I think this is a viable path but would require much more development than I had capacity for at the time.
Mamori’s approach is to tackle accuracy.
Mamori finds attack sequences and then optimizes them
Mamori relies on 2 breakthroughs which are equally important.
First, the system is able to generate valid attack sequences using a range of inputs:
This is the key problem I wasn't able to solve in 2018.
It was somewhat refreshing not to see Large Language Models quoted as the solution here but I wouldn't be surprised if they can be integrated as a complementary test case generation tool.
Once you have an attack sequence that is potentially exploitable, Mamori adds the optimizer.
The combination of these two pieces is the ability to both identify vulnerabilities and then maximize value extraction.
This is why Mamori now dubs itself as a ML-enabled Pathfinder (read: solver).
The link between security tooling and MEV
The optimizer in particular can be repurposed into a general purpose solver.
This is becoming more relevant as the scope of what intent based languages can cover grows.
For example if you are building a Uniswap V4 hook, using a general purpose solver like Mamori could give you a fast path to receiving order flow.
Having a general purpose solver is even more powerful than that and could pave the way for MEV internalization across a range of protocols.
Mamori could offer a service to internalize MEV on behalf of other protocols and take a share of the MEV internalized.
Or it could just be a solver focused on emerging MEV opportunities.
Part of what makes Mamori such a high-potential security tool is that it doesn't have to monetize through security at all.
Just the beginning
The main risk for Mamori is the long-tail of issues and its nascent stage of development.
From the whitepaper and from what I could gather online, the tool has been primarily used to identify vulnerabilities retroactively and making the leap from retroactive to proactive is very challenging.
The careers page indicates that an early stage team is just being built right now.
However, even if it proves difficult to identify attack sequences, there’s an entire business here just based on the general purpose optimizer that could be prompted by humans.
The two-sided optionality is what makes Mamori so interesting.