Why We Invested in SphereX: The Missing Piece Of The Puzzle
Fabric Venture’s fundamental belief in investing in SphereX is that building blocks are evolving for Web3 infrastructure in the same way we have seen for SaaS infrastructure and before that for iOS application infrastructure. Components of this include communications, CRM, user management and security. Specifically in security for Web3 our key objective was to learn lessons from how the cybersec solution space evolved in Web2 and apply this to Web3. No better to do this than follow Eyal, Oren and team. The co-founders are two senior ex-8200 cyber experts with extensive experience in leadership, technology and Web2 cyber security.
Most of the smart contract security landscape roughly includes either pre-deployment code auditing solutions (e.g., Certik), or near-real-time monitoring and analytics tools (e.g., Forta). SphereX fills the missing piece of the puzzle: Reverting malicious transactions before approval to the blockchain.
SphereX identifies and prevents exploitation of vulnerabilities in real time, without breaking the composability, interfering with- or delaying legitimate transactions. It will be applied as “on-chain SaaS”, backed by off-chain learning and risk scoring engines and is called by the customer’s smart contract to apply the inline protection and prevention logic. They take care of runtime security assuring continuous and safe operation despite attacks and allow smart contract owners and developers to focus on building their product and user base. SphereX respects decentralized decision-making processes in how to deal with a transaction. Reverted Tx’s trigger the off-chain engine to decide to approve next time or not. This requires integration but ultimately Sphere-X will be a sticky part of contract design.
SphereX can be seen as the analogy from Web2 of a web application firewall. In the early days of firewalls and unified threat management of Web2 we learnt that the low hanging fruit for entry into this subset market was identification but that it was prevention that ultimately differentiated solutions for sustainability and success. Traditional preventative firewalls look at TCP/IP and block IP addresses (eg Checkpoint). Web application firewalls instead look at code signatures. Successful Web2 examples of these are F5, Akamai, and Baracuda.
Critically, we also believe this is not a space that is easily navigated to Web3 by Web2 incumbents either. In dealing with specific attack vectors on an application, in the traditional Web2 world an attacker might find PII, credit card, or other sensitive data. From the point of finding this vulnerability to take advantage of it requires a few steps but in Web3 there is ultimately just 1 step i.e., drain the funds. In addition, this risk is existential in Web3. In the traditional world a solution can take some time to identify legitimate transactions as it takes time to exploit, and it takes time to respond such as taking the network offline. In Web3 a smart contract can be drained irreversibly in one Tx with no early signs. In addition, the management of false negatives is different in Web3 vs Web2. Typically, exception handling in smart contracts has only been about managing a lack of gas but now rejecting transactions on-chain for cybersecurity reasons introduces UX challenges and composability challenges. Managing solutions for this are radically different for Web2 incumbents.
SphereX have already retroactively tested their software against well-known hacks and exploits over the past few years and demonstrated that SphereX Protect would have prevented more than $2 billion in losses. We don’t know many smart contract developers who can afford to not take a call with our friends at SphereX. Don’t hesitate to reach out for an introduction.
