So, and SphereX is protecting us in real time.
And that's what we want to talk about.
So my first question to SphereX is, guys, so tell us what do you do?
Maybe one on a high level, second on more on a...
First of all, thank you very much for having us in the space.
It's a pleasure to be here.
SphereX has been building the first on-chain firewall.
What we do is we integrate into smart contracts and allow the smart contract owner to harden their protection to detect abnormal transactions, and in case the transaction is being found malicious, to actually revert the transaction and prevent the exploit from harming the protocol.
So, if we compare it to, for example, us, that we are running also a linear blockchain, do you support linear blockchain as well, or what kind of blockchain do you support?
So, our solution is integrated into the Solidity level.
So, every blockchain that supports Solidity, we can actually deploy to.
We have added the support for the Nair a few months ago, actually.
We've been in touch with the Consensus team.
We do support every EVM chain out there.
In the long run, we're going to support other non-EVM blockchains, but this is down the road for us.
But, yeah, linear as one of the most, I think, prominent layer twos out there, the integration was really easy, as it is an EVM layer two.
Maybe you can list the blockchains for others, if somebody wants to use...
So, obviously, we have been deployed on Mainit.
We have been deployed on BSC, together with Klip and other prominent customers.
Also, on Polygon, Arbitrum, Avalanche, I need to recall others, but basically, yeah, we've added support to numerous of EVM blockchains.
So, let's talk more deeper about SphereX, because the DeFi space is really prone to hacks because of this immutability, you know.
How does SphereX protect more on a Klip Finance level?
For example, our users are depositing to Klip Finance.
How can they be assured they're safe?
Users deposit to Klip Finance, and then we send these funds to further protocols.
So, can you tell me more about this?
So, basically, SphereX is another layer of protection.
So, obviously, most of the protocols are undergoing some kind of an audit, sometimes multiple audits, but keep getting hacked.
That's because it's not enough to have a person overview the contract code because no person is perfect and everyone makes mistakes, right?
So, what we do is we take a different approach.
We analyze the protocol history, find what is the most used kind of transactions that we can actually extract fingerprints from it, and apply those kind of rules to future transactions.
So, if you send your money to protocols that are protected by SphereX, in this case, Klip, which we've loved their cooperation, their open-mindedness.
So, you can rest assured that Klip is doing the most they can in terms of security and using the most cutting-edge types of security systems for Web3 out there.
So, they're doing the extra mile.
And you can also be sure that things that you've done in the past will be enforced in the future.
We've actually backed this solution in numerous of recent hacks, even.
So, just from this year, we can say that we have been able to prevent if we're integrated with protocols like Euler, the Kerr Viper hack that have affected several protocols.
And also, last year, we've shown that a third web contract that was protected by SphereX has not been affected by the recent third web open Zeppelin hack.
So, with this extra layer of security, you can be as assured as possible that your funds are protected.
I want to have this one clear thing for others as well to understand important things.
So, we have integrated as Klip Finance SphereX, let's say, but then we, as a protocol, we move the funds to PancakeSwap.
But PancakeSwap, so now the funds are at PancakeSwap because we yield farm there, right?
We have, there are liquidity, but PancakeSwap is not using SphereX.
Just to be clear, then the funds are not protected because the funds are not at Klip Finance, but they have been further moved, right?
So, what we say is that Klip won't be an attack vector on your funds.
If PancakeSwap gets attacked, that's one thing.
If someone, because he or she invested through Klip Finance, this is the most secure his funds can be.
So, in this case, Klip Finance will be a very, very, very hard point of entrance for the hacker, for the customer funds.
So, it makes sense, yeah.
Because if, if you do this through Klip Finance, Klip is already protected with SphereX.
There's already some kind of layer of protection.
And then we move to PancakeSwap.
If the PancakeSwap gets hacked, this gets hacked anyway.
But if there's a, if users are using Klip Finance in between, then there's a less.
Basically, a person wants, besides he or she wants to invest, put his capital in PancakeSwap.
He's better putting it through Klip than straight away using PancakeSwap because Klip is better protected than the input wallet in this case.
So, that means the hacker has to go through Klip to exploit PancakeSwap.
That would be extremely hard.
That's, that's what users have to understand because listen, we have competitors who've been hacked exactly this way.
They themselves have not been hacked, but the funds where they sent to other strategies, other protocols, I mean, got hacked.
But of course they don't use SphereX.
We also recommend, you know, to SphereX.
And yeah, you, you, you touched briefly the hacks that recently happened with the bigger protocols like Kyberswap, you know, you mentioned in the past to me, but let's talk it here too.
Because they didn't use SphereX, but your monitoring did detect and would have saved.
So what we do is we sometimes take prominent protocols that we'd like to analyze and we create a fork of the same protocol.
Um, and integrate into this protocol is as, as if, uh, the block and keeps the blockchain running.
Uh, and we analyze every transaction, uh, that the protocol receives and we run the same transactions in our, uh, forked blockchain where the protocol integrated.
And what we can see is that in cases, uh, attacks were introduced to the protocol.
We can show that if the protocol, uh, were to be integrated with SphereX, we could have prevented this attack.
In the case of third web, that was very interesting with, because we've actually, um, deployed and, uh, and, uh, a secure version of, uh, the third web drop, uh, seven to one, uh, contract, uh, to BSS testnet.
And we've, uh, if you're familiar with what happened there, it was, uh, a bad integration between two different, uh, contracts of, uh, open system.
And we showed that since the attack, the, the exploit had to use, uh, a very uncommon, um, pattern of, uh, transactions sent to the, of course, sent to the protocol.
Um, we showed that this, uh, uh, uh, uh, had minimal effect on, uh, the secured version of third web.
We've shared this information on our, uh, on our, uh, Twitter page.
You can actually grab, uh, the addresses and try to exploit, uh, the published, uh, uh, attack.
And you can see that, uh, you won't be able to do the, uh, most awful things on this protocol, uh, when it's integrated with, uh, Spherix.
Also, uh, we send an analysis of, uh, Kyber, uh, which is also something that happened, uh, in recent weeks.
And again, we showed that our system detected the anomaly, our on-chain exploit prevention, uh, detected the anomaly, and, uh, we were able to block the attack.
So let's talk about the specific numbers.
If you could provide how much have you protected users funds or in this monetary, how much you could have protected funds.
Can you bring some numbers?
So, so it's hard for us to, uh, to actually count because, uh, we've backed this decision on, uh, tens of hacked protocols and the numbers just keep, uh, accumulating.
Um, but, uh, I can point you to, uh, Poli, Nomad, Binance Bridge.
Um, those are the big ones.
It accumulates to more than a billion dollars that could have been saved if they were to be integrated with Spherix.
So why are, are then protocols interested in integrating?
Like who are the bigger, the, the bigger protocols?
Look, we have 200,000 TVL.
But what are the bigger protocols with the bigger TVLs that you are already protecting real time?
Um, so because our solution is integrated into the solidity level of protocols, uh, we're, uh, under, uh, we're subject to the, uh, protocol upgrade schedule and, uh, deployment schedule.
So, uh, I can share with you, uh, we have a few customers that are about to be deployed on mainnet and BSC.
Um, but that's gonna take a couple of weeks, uh, for it to come.
So we're gonna hear sooner or later from you.
So I have just last general question is how should, and why should people think about when it comes to Web3 security?
Cause you're from the security space.
Uh, what do you recommend?
So, um, almost everyone in the company is with security background and, um, we were amazed that only one layer of security is being, um, is being, uh, used, uh, in the sense of deploying, uh, protocols and actual, uh, apps, uh, to this, uh, ecosystem.
Um, so what we know from Web2 is you need to, uh, check your code, uh, do, uh, code reviews and also apply, uh, firewalls and check that the system is hard enough and monitor the, uh, your app.
Uh, and we come to Web3 and see that people just rely on audits.
Uh, and after, uh, uh, diving into audits, we saw that a lot of the times, uh, the actual audited version of the code is not the one that was deployed on chain.
So there are actual discrepancies between the two versions and people rely on a PDF, uh, that you can find on the, uh, on the protocol website.
Uh, but they don't make sure that the protocol they're interacting with is the one that has been undergoing, uh, audit.
So people want to understand that they need to have, uh, a measure of, uh, uh, uh, uh, an ability to check that the, uh, the protocol is actually secure.
Uh, and this is one of the things that, uh, Spheres provided everyone, because we're an on-chain solution, everyone can query the protocol, the protection and see that the protocol is secure.
So one take from this, uh, uh, uh, space is that, uh, like everywhere in, uh, Web2, Web3, uh, security is a multi-layered effort.
We provide, uh, I believe one of the strongest layers, uh, a protocol can have for security and don't, don't trust the PDF on, uh, the GitHub page of, uh, the app.
See for itself that, uh, the version deployed is the actual, that is the actual version that was, uh, audited.
So you're telling that basically the, the production, the live smart contracts that are running by the protocols and the, and the version that's been audited are not, is, are not the same as, is, is.
Typically happening more often than it's a really small, small amount of time, because I did hear as well.
There's some protocol got hacked because they changed one line of code that was not audited.
So it's, it's, it's, it's a big thing, right?
You are actually saying, cause look, I, I don't know.
I, I do trust the, the PDF.
I believe others trust it as well, but the, the protocols don't care.
They just deploy newer versions.
I mean, we were, uh, some of us are developers.
We know that, uh, and an audit cycle is something that is very expensive, both in, uh, time and capital.
Um, and just changing one line because you missed something and then, uh, uploading on chain, uh, is something that we've seen, uh, to be very common.
Look, you touched this web to security too.
Cause I look, I have, uh, also experience in, in web to securing, uh, the crypto marketplace.
I would touch briefly too.
I'm sure you know what I'm going to say is for others as well.
There is, uh, multiple levels of security.
One thing is secure your infrastructure, which is applies to web two as well.
You have heard to domain.
There can be attacked through domain, right?
That domain can be hijacked.
Then the, wherever you deploy the servers, whatever it's AWS or whatever else that can be hacked too.
It can be hacked through a third party.
If you're using some, an example, you're using mail service to send out emails.
Then there's a, through the API of, if the email service is compromised, their API, the hacker can read the emails that are coming in and out.
Not, not we at clip finance, but in the past at the previous company, the hacker clicked forgot password for all the users.
And he saw this forgot password email contents.
And that's how he got it.
Any, any other, any other types of exploits?
No, we talked only about smart contract because that's what SphereX does, but just for the sake of wider, wider knowledge, any other types of exploits?
Um, so an interesting notion, uh, I believe is that we see, um, there are two interesting, um, two interesting hacks that happened this year.
Um, one of them is, uh, the curve Viper and the other one is, uh, third web that happens, uh, happened, uh, um, last week.
Um, so in these two cases, it's not the actual protocol owner that was, uh, uh, protocol developers that were in full, right?
Because I could have been a customer of third web doing everything right, taking an audited version, uh, of, uh, third web contracts and deploy them and think, okay, third web is obviously perfect.
Yeah. Quote unquote, um, and do everything right and getting hacked.
So that, uh, someone with a web two background would say, this is the classic, um, supply chain attacks, right?
So both the Viper hack, which the problem, uh, was in the Viper, um, the Viper, uh, compiler.
And also in third web that the problem was in, uh, the combination of two open Zeppelin, uh, contracts that third web, uh, have done it.
Um, those are different types of, uh, hacks, supply chain hacks.
And obviously an audit wouldn't have spotted these because it's not part of the audit because it's not part of the protocol code.
It's, uh, third party code and showing that audits wouldn't have, uh, catch those types of attack.
And spherics have been able to catch those, um, as truly amazing for us as security, um, uh, as people with security background, uh, seeing a very new, very sophisticated types of attack.
And although they're very sophisticated, being able to prevent them as something that we're very happy about.
I, I, I remember that too.
Curve got hacked because they used the Viper language, not solidity and whatever version they used had a bug in the compiler basically.
By the way, there's another type is also more happens a lot less.
If you're using NPM, if you're using some package package manager and some kind of most popular package that every project includes.
Like people build reactive people build web three projects on react JS.
And then you're using probably NPM or similar package manager.
And then some of this, uh, some of the dependency has a, has an exploit and 50% of the web is using that dependency.
So basically 50% of the web is basically exploitable.
And we, um, we think that it's going to, going to happen, uh, more often than before, uh, because contracts are being, uh, are getting more sophisticated.
And it's just the evolution of things to build on top of, uh, previous, uh, previous packages.
And while, uh, contracts are being more, uh, complicated and complex, uh, people will use a ready-made, uh, contracts for those and packages and without being able to actually dive into the code there.
And we will see, I think in the future, uh, more supply chain attacks in this field.
I see a, you call the supply chain.
For example, like open Zeppelin, right?
Again, can something people can miss something.
That's exactly what happened in third web.
Uh, both open Zeppelin and third web missed the part that combining the multicool contract and, uh, the, um, metadex, uh,
um, contract will, uh, is an attack victim.
Hey, so thank you for AMA.
Do we got questions answered about SphereX?
How SphereX is protecting user funds, how even SphereX is still protecting user funds.
Even if the funds are routed through CLIP finance to other protocols, there's still more protection to users.
And look, we talk generally about the security in general, because everybody needs to know how to secure themselves.
Um, I let it here talk our host CLIP finance as well.
I appreciate everyone showing up.
Um, it was a great space.
It's always great to understand, um, a little bit more about security and web three, because as SphereX was mentioning,
there's just so many exploits and we want to keep users safe.
So we appreciate you guys coming out today.
Um, and there'll be a recording of this.
So we'll push it everywhere so people can listen to it.