AI audits in Web3 — Basic Block podcast #216 with SavantChat

Transcript of the Basic Block podcast, episode #216 “AI Audits in Web3” (February 2026): the Basic Block host and Evgeny Marchenko (CTO of Pessimistic Security) talk with SavantChat founders Igor and Alexandra Gulamov. Original: https://www.youtube.com/watch?v=EudACqKiTMM

Igor Gulamov: Hi.

Host: You're listening to the Basic Block podcast — a podcast about blockchain, and lately a little about AI too. Today's episode is exactly that kind — about applying artificial intelligence to blockchain matters. This is episode number 216, and today our guests are Igor Gulamov and Alexandra Gulamova, founders of the SavantChat project. There isn't much public material about them online, and they aren't the most public figures. However, within the Russian-speaking veteran blockchain community, the reputation of Igor and Alexandra's team is very high — thanks to their contribution to the development of Layer 2 in its embryonic stage, to the development of Zero-Knowledge technologies, and to numerous audits. So when it became known that Igor and Alexandra had created an AI code auditor, it sparked great interest in the audit community: these folks don't do bullshit, they deliver complex products and technologies.

Alexandra Gulamova: Hi. Thank you very much for the invitation.

Igor Gulamov: Hi.

Host: Today we'll be talking about applying artificial intelligence to smart-contract security audits. And to make the episode deeper, I took advantage of the fact that I'm a co-founder of the audit company Pessimistic Security and invited my technical co-founder, Zhenya Marchenko, as an expert.

Evgeny Marchenko: Hi everyone. It's nice to be on Basic Block after a long break.

Host: Zhenya Marchenko has been a practicing smart-contract auditor for more than eight years, and he's also the CTO of Pessimistic Security, where we use SavantChat and other AI security tools in real audits. Before we start, I want to thank our patrons — those who support us on Patreon and Boosty. Huge thanks to everyone who supports us. Also thanks to our sponsors. First is 1inch — a project with 23 million users and around $1 billion in daily volume; by some data, it currently controls about 60% of the swap market. Through it you can profitably swap tokens between Ethereum, Polygon, Arbitrum and other networks, getting the best rate and protection from MEV bots. Swaps within Solana, by the way, already work too. We're also supported by Zerion. The Zerion API is a powerful tool for Web3 developers: with it you can get real-time data on wallets, tokens, DeFi positions and so on across dozens of blockchains, including Ethereum, Solana and others. Everything you might need is in the Zerion API: detailed human-readable transactions, multichain, 99.9% uptime, scalability beyond 1000 requests per second. The Zerion API is used by companies like Uniswap, OpenSea, WalletConnect, Rainbow Wallet and others. We're also supported by Fluence — a cloud platform built on decentralized infrastructure that provides a cheaper, fault-tolerant alternative to traditional cloud solutions like AWS, DigitalOcean and Hetzner. With Fluence you get access to a global network of independent providers, you can quickly spin up virtual servers and deploy workloads worldwide, all while significantly cutting costs and not depending on a single provider. Thank you, Fluence. And our last sponsor is GOSH, the core developer of the Acki Nacki blockchain, built on a new protocol that reaches consensus in two iterations — the fastest theoretically possible. I recommend listening to our recent episode with GOSH's founder: the one with Mitya Goroshevsky turned out quite hype-y and debatable. Huge thanks, GOSH. Well then, let's move to the substance of our podcast — to discussing what Igor and Alexandra do. We usually start our podcast with the question of how you got into blockchain. I think it can be addressed to Igor and Alexandra in turn. Guys, the floor is yours.

Igor Gulamov: I got into blockchain earlier. In general, I followed Bitcoin — maybe a year or two after its release — but I started doing something actually crypto-native in 2017, when Pyotr Korolyov put together BankEx Foundation. There we did various research, including on scaling. I have several publications on Plasma on ethresear.ch. I was at the last plasma call, and around that time I found a critical vulnerability in Plasma Prime. After that, Plasma basically ended. Later that story reassembled itself as optimistic rollups, but that's a different thing, because there data availability is guaranteed by some external protocols. That's how I got into blockchain.

Host: Thanks. Alexandra?

Alexandra Gulamova: I came into blockchain somewhat later. At first I helped Igor a bit with ZeroPool, and also with our other projects, but those weren't related to blockchain. On the blockchain side I helped a bit with ZeroPool, and the project started to grow — it turned out that it required more of my involvement specifically on the non-technical side. So my entry into blockchain was quite active — straight into ZK.

Host: My condolences.

Alexandra Gulamova: Thanks.

Host: When I was preparing for this episode, I listened to the CP0X podcast with Igor that came out recently — a couple of months ago. I strongly recommend it to our listeners who are interested in Igor's path: how exactly, and what bug he found in Plasma, how the Ethereum Foundation handled that situation, more about ZeroPool. If you're interested in that, I recommend listening to that episode — I listened with great interest myself. As for us, we probably won't repeat the same questions, and we'll devote more time to security achieved with the help of AI and destroyed with the help of AI. Except that I'd like to ask a couple of questions of my own that are probably only interesting to me — but I'll still use my official position. Igor, am I right that you studied at the Physics Faculty of Moscow State University and were in the PhD program there?

Igor Gulamov: Yes, that's right.

Host: Did you defend a dissertation or not?

Igor Gulamov: No. Around the time I left for blockchain, I didn't go on to defend a dissertation. My situation is such that I have publications in peer-reviewed international journals, but no dissertation. For most people it's usually the other way around.

Host: I have exactly the same situation — that's why I got curious to ask this question. By the way, don't you think about defending someday? When you have free time.

Igor Gulamov: There won't be any.

Host: Second question. Why do you think it happened that BankEx Foundation gathered such a garden of talent? Essentially, BankEx Foundation alumni made a huge number of the coolest projects — that's Matter Labs, and Tornado Cash, someone went to 1inch, you made ZeroPool, now you're making SavantChat. Why do you think it happened?

Igor Gulamov: I think it's simply that at BankEx Foundation our task was cutting-edge research that, on one hand, is quite complex, and on the other, very new. That is, it requires not academic immersion in the history of the previous ten years, but the ability to effectively solve problems in an entirely new field. That attracts the corresponding people who can do it. There weren't many such offerings in Russia in 2017 — mostly everyone went off to make tokens. Around this, a strong team assembled at BankEx Foundation. And Pyotr has certain talents and achievements in this field too — that's also an important factor.

Host: Another question — this is still kind of a lightning round. I wanted to ask about the ZeroPool project. Again, Igor already told a lot of interesting things in the CP0X podcast, so we probably won't dive very deep into ZeroPool, its history, privacy and so on — I refer you to that wonderful podcast. ZeroPool, for our listeners, is an open-source project, fairly old-school: you made it in 2019–2020, and it didn't become commercial. Nonetheless, if I understand correctly, many teams later used your work in their own privacy efforts. And I'd like to ask this question. I'm sure you still follow the topic of privacy in blockchain. Maybe it's a distortion of my information bubble, but it seems to me that right now privacy in Web3 is probably the second most hyped topic after AI. What, personally, as a technical expert, seems most interesting to you about what's happening in privacy right now? What about FHE, private smart contracts and so on? What of this seems interesting to you?

Igor Gulamov: FHE is a strong technology, but it's not for anonymous transactions. Maybe someone is trying to do anonymous transactions with FHE, but it's not the best tool for that, because there the key is distributed among those who compute anything. In ZK there's none of that. Trusted setups were abandoned in modern protocols long ago. And FHE is much heavier to compute than ZK. In ZK you can now prove a very large number of computations thanks to recursion; FHE still has a bigger complexity multiplier for doing any computation.

Host: And which interesting projects do you think are working in the privacy area right now? The most interesting ones?

Alexandra Gulamova: In terms of privacy, the main interest right now is not so much in the technological plane as in the legal one. Paradoxically, the legal sphere right now affects the privacy market far more than any technology: it's precisely legal that's stopping progress toward privacy. And I'm not saying the regulation should be some specific one — the point is that it should exist at all. The most recent more-or-less tangible thing we have on regulation is a letter from American regulators saying that privacy is high-risk. It was several years ago, and they never really explained what high-risk means: "wait for follow-up updates with comments," which we're still waiting for. So the regulator has complete free will to decide what's good and what's bad. And as soon as transparent regulation appears, my vision is that technologies will immediately start developing very quickly, because ZeroPool has something to show, and other projects have something to show too. I'm sure other stacks have more than enough to show. As soon as transparent regulation appears in this market — again — there will be a lot of technological updates, far more interesting than what's happening now, and they'll come very fast.

Igor Gulamov: The point here isn't so much that we need someone to grant or deny a permit. What's needed is the absence of arbitrariness. What's the problem right now? The problem is that with every privacy project an official can do whatever comes into his head. That is, it's lawlessness.

Alexandra Gulamova: That's exactly why we didn't fully close this area for ourselves, but put it on hold — until some transparent regulation appears in this field.

Host: And do you see any movement? I don't follow this topic very deeply, but periodically in our chat — our podcast's chat — people toss in things: that some Task Force has gathered, they're discussing how, look, we're putting institutionals on the blockchain, so we need to preserve bank secrecy, so we need flexible privacy, and so on. That is, the word "privacy" is coming from the mouths of people in ties speaking behind oak lecterns, and from that I get the sense that there is movement. But judging by what you're saying, it hasn't yet been expressed in concrete acts.

Alexandra Gulamova: Well, yes — as I'm saying, all this started but so far has ended with something more or less tangible only in that letter from the American regulators. In that respect the States still play one of the leading roles in international regulation. And it's clear that, since they have case law, the Tornado Cash story will naturally have a big influence.

Igor Gulamov: I see this story differently — not as these people in suits and ties agreeing on something. Because the most they can agree on is that someone's crony or in-law gets a private bill for it. On anything else in such matters they can't agree. Such things happen — well, it really is practice — like how the Tornado Cash situation will ultimately be resolved. These are processes that relate not to correctness but, in general, to how matters get decided. They don't move evolutionarily — sometimes they behave more revolutionarily. You just need more common sense. Because if there's less of it, you can spend decades debating whether people can use knives.

Host: Let's move on to discussing SavantChat. Let's start, maybe, with a warm-up question: where did the idea to make SavantChat come from? How did it appear?

Alexandra Gulamova: Our team actively followed what was happening in the market, and the development of models in general. Since Igor has quite a lot of experience with complex audits, including ZK projects, we would periodically try things — not from the standpoint of launching a new project, but from the standpoint of what models can actually do. An audit is a certain standard, a pinnacle in terms of technology, the development of complex technologies; and if models can do something in terms of auditing, then it makes sense to apply them to development too. That is, it's a kind of exam for the technology. And about a year ago we noticed that LLMs were reaching the stage where they could already dig something up. We tried playing with it just within an online hackathon. The result surprised us somewhat — and we decided to build a product.

Host: Pleasantly surprised, I take it. Okay. Tell us how SavantChat is built.

Igor Gulamov: It's built as follows. We split the code into semantically correct chunks, then we generate documentation for these code pieces and for the project. We also do RAG over the documentation that was provided. In an audit that can be crawling some GitBook sites, some whitepapers. We establish links between the code pieces and the documentation. Next we throw these pieces into a hypothesis-generator agent. Then an auditor agent further investigates those hypotheses. Then a critic agent filters out the errors, then deduplication happens. There are a lot of finer architectural details there, but broadly speaking — that's the pipeline.

Host: So on the input side, for the user it looks like this: he can drop his code and whatever documentation he has into SavantChat, then SavantChat does what you just described, and on the output it spits out a nice PDF report with a list of findings.

Alexandra Gulamova: Yes, we made it so that the process is as familiar and understandable to the user as possible. Among other things, we took into account the specifics of the Web3 community — fairly introverted, not too eager to interact with people unnecessarily — so that it would all be maximally automated. That's why we have a maximally easy entry to the platform and a maximally easy upload step: you just upload your code — practically any convenient way — and you get a report like the one you usually get after an audit at "human" companies. It's also as close as possible to that format, so that everything is maximally comfortable for the user. What differs a bit from a standard audit is the CI/CD integration process: when you can connect a check for truly ongoing security and check code in small pieces as you prepare a release. There you already get a really fast result — to the point that in 10–15 minutes you can get a bug report even in Telegram.

Host: I'd like to ask about how the pipeline is built. If I understand correctly, first the code, as Igor said, is split into pieces and matched against the documentation. By the way, remind me what RAG stands for?

Igor Gulamov: I can't tell you right off the bat. But I can tell you a lot about how it works.

Host: Tell us in your own words what it is, so we don't get held up right now.

Igor Gulamov: It's the building of a certain system. We take the data, split it into chunks. For each chunk we build an embedding — that's a vector in a multidimensional space, there could be a thousand dimensions. Accordingly, we have these chunks, and we have our generated description for the code pieces — for it we also build an embedding. Then we look in this multidimensional space at which pieces are closest to what we're searching for. After that we take the 100 nearest pieces and do reranking: we throw them into a model that selects, for our query, out of those 100, say, the 10 most relevant pieces — and that is what's fed into the model.

Host: I'll pretend I understood. So you have several models — public ones, I take it — that generate hypotheses, then these hypotheses somehow get filtered, deduplicated, and land in the report. My question is this: does everyone do it this way? That is, are there other approaches to building an AI-auditor architecture?

Alexandra Gulamova: Actually there are several approaches in the market. Some just make a wrapper for a single LLM. This is especially noticeable as soon as a new version of one of the Tier-1 models comes out that works more or less well with code and is suitable for audits: immediately a bunch of new AI auditors appear that offer an almost free price and maximally fast results — but because it's essentially the work of a single prompt. And the result there is correspondingly poor. Another approach is training your own model on top of existing vulnerabilities. We didn't take that path, because people are already good at working with their stereotypes on an established base, and we believe AI is valuable precisely for its fresh look and fresh approach to working with code. Thanks to this we often get results in reports that are maximally unlike what humans find and what human auditors usually consider to be vulnerabilities. And it's not because the human works with code poorly, but because a human has his own base, his own experience, his own stereotypes and, to some degree, certain patterns of thinking — however much we might want to move away from them. Whereas AI gives an entirely different approach to code.

Igor Gulamov: There's our approach, and there's the next-gen approach — that's when the agent can run experiments with working code: deploy something somewhere, poke it. That's what we're working on now for the next release. It will greatly reduce the number of false positives. We already have quite few of them, but still more than in human audits — and this approach will let us radically reduce their number. There were some theses — I don't remember which of the AI researchers said this in the fall — that a good architecture isn't a super-dense model that knows everything in its weights, but a model that knows principles. And if you give it some knowledge as input, it will apply the principles to that knowledge and produce a quality result. Right now, besides the ability to run experiments with code during an audit, we're making a kind of textbook covering all the vulnerabilities that have ever occurred — for neural networks and with the help of neural networks. And, probably even faster than the code-execution feature, we plan to bolt it onto SavantChat. Accordingly, with it, the neural networks, if they see code, will also go through some typical cases — without, of course, sacrificing the ability to come up with something new. It's just that 95% of what exists is still a composition of old things, not something new. This will improve quality for our clients.

Host: You said you're making a reference guide for the AIs about which vulnerabilities have already occurred. If I understand correctly, you've already fine-tuned the model you use on something?

Alexandra Gulamova: No.

Host: So what did you fine-tune on?

Alexandra Gulamova: That's exactly why I said that from the start we went with the approach of not training our own LLM. At the moment we make various combinations of Tier-1 models think over the code. That is, right now our architecture is such that the models see the code for the first time and analyze it from scratch — looking for where there might be vulnerabilities and weak spots. And now this will be supplemented by a vulnerabilities textbook. But the approach where every piece of code is looked at from scratch, as if for the first time, will remain — the textbook just supplements it, the core still stays on this vision. I especially wanted to add to what Igor said: that vulnerabilities are more or less the same. On one hand, that's true — it's absolutely valid for code written by a human. But development is now moving toward vibe-coding, in various forms. And not just vibe-coding written from scratch, but also when very experienced, excellent developers supplement their work with it — on our team this is actively used too. And here AI can already generate vulnerabilities that a human wasn't generating. Accordingly, a different approach is needed too — and this is, again, the strength of the fact that our AI looks at the code from its own point of view.

Igor Gulamov: Speaking of the different models — we use their strengths. For instance, Anthropic's models are decent at using tools, but weaker in STEM, while they're good with creativity. OpenAI's models are bad with creativity, but good with instruction following. Google's models, Gemini, are good with both creativity and STEM, but without special prompt-engineering effort they produce unstable results that are significantly harder to apply. That's why we combine different models for different subtasks. We have creative tasks; we have tasks where, conversely, you need not creativity but to check everything thoroughly; we have tasks of aggregating various results. For different tasks we pick different models, to ensure maximum quality at minimum price. We also use batch requests: requests are made in parallel and at discounts — this lets us increase the amount of inference available to our users for audits. What we do can't just be "vibe-coded" — not in an evening, not in a week, not in a month. Again, if you use any single model, or even two, the result will be worse and the price higher. And we constantly update our tool for new releases and run benchmarks.

Host: Zhenya?

Evgeny Marchenko: Correct me if I understood right: on the input, besides the users' data, you also feed in a huge prepared context of yours — this textbook, for example, that you're making now. A textbook of exploits, hacks, vulnerabilities, broken down into parts — and, probably, some of your instructions, prompts, hints on how to use the agents, how to interact with this codebase?

Igor Gulamov: It's not a codebase, it's principles. We collected the vulnerabilities, we cluster them, we use Tier-1 models to strip all these vulnerabilities of the specific project's context and leave only the description — that is, what has to happen in a project for such a thing to occur. Then we work with this data — and that's how the textbook comes about. That is, artificial intelligence writes it. We're moving away entirely from the paired work of human and AI — that's what it was like this summer. We're moving toward processes where an engineer builds a pipeline in which AI can work on some solution. What's the point? The AI not only does the task but also checks it — via intermediate checking. There are certain criteria, and the AI checks the task against them; if there are problems, it goes back, fixes them and continues until it's solved, and the human only does the final acceptance. Speaking of this base — there's a very large volume of computational work there, because you need to process, with the help of neural networks, all the vulnerabilities ever found in smart contracts. And before that you have to collect them. Artificial intelligence handles this task excellently. We're a small startup — three engineers — and we can afford to do such tasks. Back in the summer we couldn't, because AI is just a colossal amount of raw power that can do a gigantic amount of intellectual work.

Evgeny Marchenko: I have the feeling that for the last five minutes there's been this opposition of human and AI running in the background at different levels. For example, you, SavantChat, mostly rely on AI, and AI thinks differently than humans — so it will look for problems that are different, in a different way. Or the hackers, who used to search everything by hand and think like humans — now that's some AI too, and it searches for different problems. Code is also generated by AI now — again, different problems. And even this database, the textbook you're compiling, mostly consists of human errors and vulnerabilities found by humans, processed by AI. What does this dynamic between human and AI look like at all? How does this balance of forces look now, and how is it maybe changing as AI moves forward?

Alexandra Gulamova: In my view, opposing human and AI is, from the start, not a very productive approach. In my view, it's exclusively about complementing. We're saying exactly that AI complements the human: AI gives a different look at the code. That's why we say AI audits, including SavantChat, are by no means a replacement for a human audit — it's a tool for ongoing development, for preparing for a human audit, for a quick check, and for increasing security specifically during the development process. When we say vibe-coding will produce different vulnerabilities — that's precisely that vibe-coding will produce additional, new vulnerabilities, but the human ones won't go anywhere, because a significant part of development is still written by people. Their vulnerabilities, which they introduce into the code, won't disappear — this just gets added to it. That's why an AI audit is needed, one that complements the human one. And, as you correctly said, these are human vulnerabilities, and the AI complements them by structuring them. Here it's exclusively about the joint work of human and AI. Singularity is not here yet — at least, we can only talk about the interaction of human and AI.

Evgeny Marchenko: I use a couple of tools myself, including SavantChat, for audits. I run it over the whole codebase, take the results, and look at them closer to the end of the manual audit already — once I've figured out the project, but want to look at the code from yet another angle. Because SavantChat really does think differently, it periodically surprises me — but that's good. As an auditor, I enjoy thinking from another angle, looking at already-familiar code: it increases my confidence that I've covered all the possible scenarios. That said, I have almost no real ability to interact. I can supply some inputs, but I'm not a developer — mostly I just hand over the collected materials, and I get the result on the output. I can't say, "hey, think about this," or "I see you made this assumption — I understand you deduced it from the documentation, but this assumption is wrong, think again." This isn't a reproach to SavantChat — all the tools are like this right now — but it's what I, as an auditor, maybe lack: some interactivity. How can dense interaction between humans and AI even be structured?

Igor Gulamov: Right now that doesn't exist yet. It's still more like drafting a technical specification — like giving the AI documentation. Perhaps after fixing errors it's some kind of re-audit already with the fixes, when it works a second time taking all this into account. But on the fly — I'm not sure anything will work out, because on serious production scopes it can be 100,000 requests to the LLM, running over 10 hours and costing $10,000. For SavantChat that's a perfectly normal case.

Alexandra Gulamova: As LLMs develop, this will become more reasonable.

Evgeny Marchenko: Yes. Then maybe — you mentioned CI/CD at the start of the conversation — maybe interactivity could appear somewhere there. Understandably slowly, but developers can give the AI tools some instructions so that they go crazy less, hallucinate less, bother them less over nothing.

Igor Gulamov: Of course. Speaking of CI/CD — that's probably, yes, the closest thing to interactivity. Because people don't need the AI, because of stereotypes and a lack of context, to keep nagging about some nonsense at every commit. And it will do exactly that if there's no properly organized feedback. Right now this can be done by making the corresponding entries in the documentation and adding a dev comment to a code piece about how it actually behaves: then such stereotypes in the AI get corrected, and it won't keep nagging there. Yes, this doesn't work in a ChatGPT format, because ChatGPT is paired work, whereas here the solution implies a huge amount of research — more than GPT-5 Pro does now. And GPT-5 Pro now often does autonomous research on its own. While it does that research, the most it shows the human is its reasoning. But suppose the human, in the middle of that research, saw that the model is digging somewhere off track. If the human saw this at the 30th minute, he won't drop the whole research to correct the chat. Why? Because the model has not just one but dozens of research directions. It's clear that some of them will be not the best, and some better; the main thing is what it later picks for reference and what it throws out as garbage. And with us there's both more parallelism and more interaction — it's a kind of DAG: it has several stages, and it's very wide, up to a hundred thousand requests to different models. In that respect we have less ability to show the user anything meaningful in the process. Again, we deliberately tune the models to propose the craziest solutions, and then we filter them. And sometimes some good crazy solutions may get filtered out too — but since there are many of them, not all get filtered, some make it into the report. And then in the report you can read something useful. Whereas if the human were to dig into all this during the ongoing process — that's too much cognitive load. He'll already have to sort through, maybe, 50–100 issues written by the AI afterward. We're working on this. I think CI/CD is the closest thing to that kind of interactivity. Maybe some mechanisms will appear in the future — for example, so the AI can ask the human something about the points it's not very clear on. We've thought about this, but right now, unfortunately, neural networks, especially the highly creative ones needed to search for issues, are extremely bad at awareness of their own ignorance. They'll sooner make something up. Well, what can you do — that's exactly the property we need when we want them to come up with something.

Evgeny Marchenko: So it turns out to be an interesting complex of problems. On one hand — creativity, on the other — you can't get control and feedback from the human promptly, the same CI/CD; understandable, but there it's one big scan. Can any of this be compensated with traditional tools — static analysis, any other? All of what engineers used to try to invent to automate this problem — that whole arsenal. Can AI use it effectively and improve its results?

Igor Gulamov: When we were choosing what to do — the problems textbook — we also considered essentially vibe-coding some static analyzer, a giant one, similar to Slither but with everything in it. But we decided it's better to make it "fuzzy": describe in words what bad things can happen, and then the neural networks will read that and find something. It's that kind of static analyzer, only we implement it in a somewhat different way, not the way it's usually done. Speaking of tools, I think the most promising thing is formal verification. Even when we talk about training — that's how they now train the neural networks that solve mathematics: they use formal verification. Formal verification was an early model of artificial intelligence, back before neural networks, in the mid-20th century. People thought that if you teach computers to do something with logical statements, intelligence would come out of that. It didn't. Why? Because complexity grows exponentially. It's a very high-dimensional space in which you can go anywhere, but we need to get from the problem statement to the solution. A neural network lays out this path, but there can be errors in this path. And this logical system — the formal verifier, the prover — can prove that there are no errors. And it's done fast: the path is found. Here you do need artificial intelligence, because the system out of the box can only do brute force, and brute force with exponentially growing complexity is a bad idea. But a finished path is checked efficiently. As applied to smart contracts, what does this mean? It means that if you teach AI agents to use formal verification, then instead of the neural network thinking about some hypotheses, digging through the code and sometimes hallucinating (and it will hallucinate, because we use neural networks in maximum-creativity mode) — we instead take the network's creative hypothesis and immediately run it through a formal verifier. As a result there's less inference and more reliability. We ran experiments with this — interesting experiments. We'll work on this and implement it in SavantChat.

Evgeny Marchenko: Speaking of formal verification used this way — is it mandatory to make a complete description of the whole system of contracts in scope, or can you formally verify some individual properties? Well, a childish example: the sum of balances is always equal to the total supply. Can you verify this property in isolation with this math?

Igor Gulamov: Yes, of course you can. The question is how to formulate it correctly. Correctly is not "the sum of balances equals the total supply," but that when balances change, locally the change in the sum of balances equals the change in total supply. Why? Because it's a local story. After that we run through all the places where this happens, verify this local story, and thus make sure everything is fine. A situation where the AI missed something is ruled out here, because we split the code into small chunks and look at each chunk separately. We take a chunk and all its dependencies, but we tell the model that we're investigating precisely this chunk, and the rest is context. And if something happens with balances somewhere there, the model will notice it and build a description for the formal prover for each such individual case. Then all this gets proven, and we get a big statement that the sum of balances is always equal to the total supply. This is exactly about that path. Because throwing the general problem into a formal prover, if there are a bunch of different complex logics there, is complexity. But the model can decompose this story. The model can even later assemble a general statement from these pieces too: it takes them as separate theorems about each individual story, and then the big global statement is trivially composed from them. That's exactly about finding a path for how to solve the problem in this multidimensional space where you can write various mathematical statements.

Evgeny Marchenko: It sounds like a big blue-sky dream: one AI wrote it, another read it, drew up the specifications, verified, proved that it works as intended. And yet my intuition tells me that in the limit it still won't work that way. Or is it actually possible that someday humans could be excluded from this whole cycle entirely, and it will magically all work out well and problem-free?

Igor Gulamov: To set tasks, you need to understand the tasks — understand what it is. I strongly doubt that engineers will be excluded from this story, because a non-engineer probably won't be able to effectively discuss engineering things with artificial intelligence and set tasks correctly. If AGI comes, then of course a lot will change, but that will be an entirely different world, and a lot of things will be happening there. But if we're talking about the period before AGI — before the situation where artificial intelligence can perform any human task — then engineers are definitely needed, because tasks need to be set. And an engineer will set a task better than a non-engineer. Whereas if we're considering a world in which AI can replace any human — that's already an entirely different story, and there the problems are probably no longer with engineers.

Host: There it's already a question of whether it's worth spending time developing AI auditors — or whether you no longer need to. I'd like to ask a more general question. Do you follow how cybersecurity is developing in the AI dimension outside of Web3? Surely there are many times more smart people working there than in Web3, and surely there's something to draw inspiration from there too — some more general approaches. To start even with this: in Web3 we in general have a somewhat distorted perception of what cybersecurity is — with a skew toward audits. Whereas general cybersecurity in Web2 isn't so heavily tied to human audits. Surely AI is being used there more now in other tasks — in monitoring, in pentests and so on. Do you look at that?

Igor Gulamov: It's an interesting direction, we follow it. Still, our profile is more about working with code. Pentests are also interesting and promising. I think AI can now actively engage in both monitoring and pentests. There are many projects that say they work with code — finding inefficient code or some errors. In that I believe less, because I see how SavantChat works with Solidity: there aren't that many problems, the code is often maximally optimized, the errors already maximally fixed — you really need to spend a lot of inference to find something interesting. Naturally, for Web2 these costs are still too expensive, but inference gets cheaper fast, and the number of false positives is also falling. I think we'll get to the point where we can audit both smart-contract code and Web2 projects' code, where we can do formal verification of code in Web2 projects — and it will work. I think we'll get there sooner or later, so that development is efficient and without such problems. But for now, yes — monitoring and pentests are the main directions where artificial intelligence can currently deliver quality results.

Evgeny Marchenko: I want to go back to Web3. In Web2 there are constant zero-days, and it's usually a story about some library: it had a bug, a vulnerability, everyone was using it, and now everyone has a problem — everyone waits for a patch and hopes it won't affect them. Web3 still lives by somewhat different laws, it's structured differently. And yet I saw that you can reproduce most of the hacks — that SavantChat could potentially have prevented the zero-days that happened with us. Could you clarify what's meant by zero-day in Web3, what it means that you reproduce them, and talk in general about how the situation would change if SavantChat were run on every contract?

Alexandra Gulamova: It makes sense here to give a general answer first, before going into technical details. By reproducing a zero-day we mean that we found the root cause — that is, SavantChat found in the code the place where the exploit happened, where the crash itself originated. This shows that if projects like Abracadabra, Bunny had used SavantChat, we could have prevented those loud hacks of the fall. But here you need to keep in mind: we're not claiming that SavantChat reproduces 100% of hacks. It's more valid to say here that AI tools are used not only for security — not only for strengthening security during development — but black-hat hackers use AI tools too. SavantChat specifically reproduces the latest hacks of the fall, which differ very greatly from what came before. On the basis that this differs from what was before, and that SavantChat reproduced it, we can say that hackers too are starting to actively use AI tools for their purposes. And accordingly, it's wrong to say that we reproduce all the zero-days. Naturally, some significant, possibly larger part we do reproduce, but there are nuances here too.

Igor Gulamov: First of all, there's the full exploit path — that's what the hacker did — and there's the root cause: it's the line in which the reentrancy sits, or some arithmetic overflow. But that doesn't mean it will lead to money being stolen — it's just an error in the code. That is, the root cause is the isolated error in the code, and the exploit path is how you can steal the money. We reproduce the root cause. We find the error in the code, and very often we don't go further — or we go further somewhere off track, because SavantChat is a thing for defense, not for attack. We see that a root cause was found — good, that already satisfies us. You could unwind it further to an exploit path, but that's optional; for validation it's probably useful. Now that we're working on bolting on code execution, unwinding it to an exploit path might be useful — to write a better proof-of-concept. Even writing a proof-of-concept for an arithmetic overflow in a protocol is a good idea too. SavantChat found all the root causes, and it found quite a lot of exploit paths. That is, sometimes it writes a directly correct statement of how you can siphon off the money, not just that there's some serious error there. That doesn't mean SavantChat is smarter than people. I think it more likely means that hackers use artificial intelligence to look for problems. Moreover, the wave of hacks has now moved into closed-source smart contracts. Previously we'd take some decompilation — the code looks dirty, unreadable — but artificial intelligence can restore it: it can look at this decompilation, do reverse engineering, and then do fuzz-testing of the bytecode against that reverse engineering to make sure it's the same thing. And then in the already-reverse-engineered smart contract it will look for errors and apply them to the bytecode — and the result is a vulnerability. This is much cheaper than if people were digging through this bytecode, or if they were reverse-engineering every such contract. So if a contract isn't audited and there's at least some meaningful amount of money in it — hundreds of thousands of dollars — then it's under threat, because hackers decompile and study it with their tools. Security through obscurity doesn't save you.

Host: Yes, by the way, we'll give a link to your post — which, as I understand, you wrote yesterday. I read it today, on exactly this topic, very informative. From my side I'd also like to add that indeed a large number of hackers work in an automated way, and have for a long time. I remember cases from at least 2020, when someone would deploy a contract — and it would get hacked within five minutes. A human with eyes simply couldn't have managed to look at all of it and figure out how. Hackers have long worked automatedly. I wanted to ask a question about this latest wave of AI hacks too. It led me to the following thought. There's a suspicion that a large number of the recent hacks of some old protocols are AI-assisted hacks. And I know your position, Igor: that against vibe-hackers our essentially only remedy is the vibe-audit. Because, clearly, if a vibe-hacker can find something a human doesn't see, then we can also defend with something that isn't human. This position is absolutely clear to me and looks rational. But today I had the following thought. Tools are improving too, and the AI is improving too — right now it can do what it couldn't do half a year ago, and so on. Whereas a smart contract — you deployed it once, and that's it, now sit and live with it. And the tools will keep improving. So, suppose we've now developed a smart contract, done a wonderful audit with the help of an AI tool, deployed it, half a year passed — and the AI has developed so much that it can find a bug where, apparently, there wasn't one before. And it turns out, from my point of view, that living has somehow become scary. You can't be sure that, say, you put money into some DeFi protocol and can forget about it for half a year. If before you could live more or less calmly — with an adjustment for our web3 quirks — then now, as AI progresses, it becomes more and more scary. What can you say to that?

Alexandra Gulamova: I'll return again to my point of view that AI complements the human. With some of our clients we have examples where fairly large protocols ran, through SavantChat, code that's already in production, being used, with a great many users — and found vulnerabilities and weak spots there. And that didn't stop them from fixing them. That is, if code has been released, that still doesn't mean we can't improve and fix it. Doing a constant human audit is, naturally, very expensive and slow. All the more so if we're saying hackers use AI more and more. But regularly running your code — even the code already in production — through SavantChat, seeing the vulnerabilities and fixing something — that's a perfectly good solution.

Igor Gulamov: Projects will regularly audit their code — especially when new models come out, and we literally roll them in within a few days. Maybe we'll even reach same-day rollout. Accordingly, you just need to do a re-audit. If these are immutable smart contracts, then the protocol has only one option — migrate to the next version, that's standard. If the contract is upgradeable, then it can be fixed.

Evgeny Marchenko: About what I expected to hear.

Host: And next I had a question... though you've all the more already preempted it with examples. You mentioned examples — so what examples are these?

Alexandra Gulamova: Naturally, I won't name the teams that did this right now, but I know from feedback that folks do this: they run, as I already said, existing code that has live users, of which there are many; they see there are vulnerabilities there — and they just fix them. Accordingly, the protocol becomes more secure.

Host: A question about the AI auditor as a business. You charge your clients for an audit roughly per line. One of the thoughts that immediately comes up — a "pirate" one — is: why not try to audit with a tool like this by simply running through all the code you can see that's listed on a bug bounty, finding bugs there and reporting them? Why don't you do that? Hackers do it, after all — they run through the code, find something, hack away. It seems like it all works in the plus. Why not direct this vector toward the white side?

Alexandra Gulamova: On your first point — that we charge per line. This was done precisely so that the user would have the most familiar and easy path to using the product, because in fact, naturally, it's not charged per line — the computation is more complex, it's more correct to say it's per tokens. But for ease of use, to be more understandable to users, we phrase it as per line of code. As for bug bounties — first, it's worth noting that SavantChat was the first AI auditor to take sixth place on Sherlock back in the summer, competing against humans. But we did this not out of a desire to get an additional source of financing, but to see how the model works, including on such platforms. And the result turned out more than impressive — it was the very first solution to achieve such a result. But before that we ourselves, as a human team, hadn't worked with these platforms. And in the course of this experiment, among other things, we realized that the main part of the work there is not the audit itself, but proving to the jury that this really is a bug, that it can lead to stealing money and so on. SavantChat doesn't do that, and to do it fully you probably need separate people. For us that's not our business, but we cooperate with auditors who want to take part in it; we announced this, and there are examples of collaboration. So if someone wants to get such a tool specifically for white-hat use, they can get in touch with us — we're ready to support that. But we ourselves believe that everyone should mind their own business: if we spread ourselves thin like that, then the result of our main product could sag somewhat, because our focus is precisely on the solution for clients, not for audit platforms.

Igor Gulamov: There were many DeFi hacks related to breaking an invariant — where the smart contract manages the shares of different liquidity providers. There it turns out that you can nudge the invariant off by a few wei, and then, via some gigantic flash loan, make those few wei a significant percentage of some balance — and thus steal the money. And how does SavantChat work? SavantChat will simply find that the invariant can be broken, and then it's however luck has it after that. That is, the way it's built now, it won't dig deep out of the box into what this leads to further on. The broken invariant on its own already lands in the report. This broken invariant will be placed as some kind of "low." But that doesn't mean there's no value in it: because if you fix all the cases where the invariant breaks by a few wei, then the cases where those few wei can be grown into several million dollars simply won't exist. So it's a more defensive tactic. The release we're working on now — related to experiments on the code — will also allow doing deeper research like this. Why might someone else have this while we don't yet? We have a very strict requirement — ease of use of the tool, and its autonomy. Many of our competitors essentially have their team launch and finely tune the AI — we don't have that. Naturally, if a more fragile, more custom pipeline is assembled, where you can hand-tune something to the project's specifics, you can in general get more results. But that's again about what the result is in practice. In principle, yes, you can get more results that way, but for some reason we don't see it. With the solutions that do it this way, something about them sometimes leaks out — but most often it's some marketing about them having secret ways of doing something.

Host: This is exactly relevant to my next question. Very many people are indeed making AI auditors now. Many of those who are a relatively established brand in our Web3 cybersecurity are now trying to pivot into a product of this kind — Munify, Sherlock, lots of them. What's your competitive advantage over these players? What's the secret sauce?

Igor Gulamov: We have Sparta — we have no walls. Yes, we have no secret sauces — we have exclusively a reliable architecture and a confident result.

Alexandra Gulamova: That's exactly why we don't play those marketing games — like "let's make 150 calls so we can tune this for you, and then in a couple of days you'll see the AI's result on the code" (even that exists in the market, and with fairly large players at that), or "we have a secret word with which you'll get the result." No — we're for maximum transparency. We have a complex architecture, we use the strengths of the Tier-1 solutions in the market, and this gives a noticeably better result. Which is confirmed by multiple benchmarks — so even this isn't some marketing claim, it's results in reality. And since AI tools for auditing are something new in the market, and people run benchmarks genuinely out of interest, we learn about many of them after the fact, together with a wide audience — when the results are already published and someone tosses us a link: "here, folks, look, you're benchmarked again." Great.

Igor Gulamov: And when I said that some of our competitors can show better results on a contest — that doesn't mean we find less. It just means we have more wide-research, while someone else has more deep-research. But when it comes to audits, it seems to me wide-research is better. Why? Because if we found something that is at least a medium error — and a broken invariant is still at least a medium, not a low — then it must be fixed. And if it's fixed, then it's no longer so important how it could have been exploited — because it won't be exploited. But yes, someone makes a solution specifically for contests or for bug bounties — there, naturally, you need more deep-research. We're going to do that too, but in the context not of bug bounties but of solving the false-positive problem: such a solution will let us radically reduce an even greater number of them. That's why we're working on this. Speaking of the auditors who each make their own AI — making such a solution is serious work. It's work not for auditors but for builders. Here you need to be a builder who's good at audits, not an auditor who decided to build something.

Alexandra Gulamova: And here we're not talking about some competition or anything like that — we're talking precisely about why, when I mentioned bug-bounty platforms, we believe everyone should do their own business, what their strengths are. We also see that auditors who make their own AI products come and use our tool too — that also says something. Coming back to bug-bounty platforms — again, we cooperate with auditors: everyone does their own side. We provide the AI solution, and the auditor does what he's strong at — applies his experience to achieve some results.

Host: An appeal to white-hat hackers: guys, we'll probably put the SavantChat team's contacts in the show notes for this episode. If you're interested in working with SavantChat in this direction — get in touch with them. A question interesting to me, about the business: did you evaluate the size of the smart-contract market in any way? That is, roughly speaking, Alexandra already said you don't quite charge per line, but let's take this crudest metric: if you count how many lines of smart contracts are written per year in general and how many are deployed, and multiply that roughly by your price tag — does that even give some kind of venture market? An interesting, venture one? If you imagine that everyone, all projects, will use AI auditors — is that even something interesting for you as a startup?

Alexandra Gulamova: It's interesting. And here I'll also immediately correct you on an assumption, because the way LLMs are developing gives us grounds to say that AI auditors — and SavantChat in particular, with its architecture — are by no means limited to the Web3 market only. Our plans — I think the second half of 2026 — include entering the Web2 market too, because things with audits are harder there now: general programming languages are harder to audit for a human, because, naturally, you have to keep much more in your head. SavantChat's approach solves exactly this problem. So if we're talking about the venture potential, the approach here is much broader. Plus there are examples in the market of audit companies and auditors who, with incomparably weaker results than SavantChat's, successfully went down this path and raised money.

Igor Gulamov: We once measured the Lisa agent on CTFBench — and things were just sad there. And they raised, I think, more than 10 million.

Alexandra Gulamova: 12. And here's where it gets interesting in venture terms. Lisa has the weakest results — it raised 12 million. Octane, whose results are also quite modest but still a bit better than Lisa's, raised 6 million. And the solutions that give the strongest results — not only SavantChat, there are also solutions much stronger than Octane — raised nothing.

Igor Gulamov: Well, there's also Almanax, which by the benchmarks people ran is a bit worse than Nethermind and SavantChat.

Alexandra Gulamova: Yes, but better than Octane. And they raised, I think, either one million or three. One million, I believe.

Host: It seems to me you can conclude from this that product quality is a non-essential variable in the venture market.

Alexandra Gulamova: Quite so, quite so. The pattern really was interesting: the stronger the product, the less it raised. Because, say, Lisa, which raised the most, couldn't handle what SavantChat handled back at launch — on its first results, a year ago.

Igor Gulamov: It's a vulnerability the neural networks already know about, because it's a known root cause.

Alexandra Gulamova: Yes. That is, if you ask an ordinary, general AI, it'll tell you about this vulnerability — whereas Lisa, which raised 12 million, doesn't find it.

Host: You really have to process this with your brain. Maybe VCs are indeed evaluating differently now. Maybe they assume that building such a product isn't as hard as selling it. And maybe they see that people sell successfully. I don't know.

Igor Gulamov: Possibly, possibly.

Alexandra Gulamova: I think it's like with any agent here. Because if we're talking about more general AI agents — I don't know, some everyday uses — it can often be some simple wrapper. Stepping away from the security market: building an agent for, say, booking tickets, or an agent for a calendar, is nothing complicated. So I think they look at the audit market the same way and figure that if it's an AI agent, then in any case it's fairly simple to build. But there are nuances.

Igor Gulamov: Again, half a year ago people could train their own neural network on top of, say, some Llama 3. Investors, when they see that people can train their own neural network, are impressed by it. We simply don't do this, because I've read too many cases where new GPT-5 or Gemini come out, and they write: "here, we compared a specialized medical neural network that was trained on a medical dataset half a year ago with this general neural network — and the general one outperformed that medical one that doctors assembled." What does that mean? It means you should take the intelligence from the best solution, top it up with in-context learning, your own specifics, design the context competently — and everything will be fine. And instead of staging a race with Google, it's better to just take what Google can give.

Alexandra Gulamova: Yes. People now often talk about the risks: "aren't you afraid that AIs like Gemini, OpenAI will be so strong that they'll be able to deliver some result on the AI code themselves?" My answer is no, we're not afraid of that; to some degree we perhaps even strive for it, because we use their strengths. For us it means: the stronger each of the models, the stronger our solution in the market and the better the result we can give our users. Because even Tier-1 models retain their peculiarities, their specifics, and, as Igor said at the very beginning, each of them is strong at some one thing. Yes, this changes often, but their own specifics still persist, and we use these strengths in our solution.

Igor Gulamov: I took, for example, the release from Trail of Bits — skills for Claude Code. What can I say? It's a genuinely strong solution. On CTFBench, out of 7 samples, the cause was found in 6. One wasn't found — there's an extra divisor in one place, and in a spot where a human could have written it too. Anthropic's models, as usual, are somewhat weaker with math — as has usually been the case with them. You have to use different models, you have to use complex pipelines. A solution based on a single model — even the one that's currently state of the art for development, even if you give it the ability to write some proof-of-concept (that is, per these skills) — will still fall short anyway. Because the agentic framework matters, but intelligence matters too, and diverse intelligence at that. We take this diverse intelligence and make a pipeline out of it, as a result of which different errors get found — architectural, and business, and cryptography, and math.

Host: It just dawned on me that, using DeFi analogies I understand, you're making not a DEX but a DEX aggregator.

Igor Gulamov: Yes, that's so.

Host: Do you have a fundraise in your plans? If so — how do you plan to approach it? For what?

Alexandra Gulamova: We've just closed a small angel round. The main goal of this round was, for more serious investors, to show proof of trust — that fairly loud names in the crypto market trust our solution. And they trust it not just in words, not just by using our product or writing that they use it after they saw real results — but also in that they're ready to vote for our product literally with money. And right now one of the goals of this angel round is attracting a broader specialist who will be responsible for SavantChat's online presence on various platforms; we're actively working on that now. I, as the only practically non-technical person on the team, am doing this almost full-time, because it's a very acute task that needs to be closed as fast as possible. After that we'll be able to move on to working on a full round with funds, showing our results and this proof-of-trust round. What's a full round needed for? First, there are certain marketing tools, certain plans, for which there's currently no budget — I'd rather not talk about them in more detail yet, but there's an idea of where to move. Probably, among other things, it makes sense to expand support, so that user support is more prompt and dedicated, because right now engineers handle it, which is probably also not quite right. But thank goodness, our solution is built so that support is required extremely rarely — but in any case, as with any solution, it's necessary with users.

Igor Gulamov: It's also important to say here why exactly we raised the round. We have profitable months, but so far it's not stable — not all the months are profitable. The round is needed to build a department that will handle promotion in the broad sense. The audit market, for example, differs from the ZK market in that in the ZK market — at least a couple of years ago — if you make something state of the art, everyone knows about you, they invite you to all the round tables. But in the case of AI audits, it's an entirely different market: marketing plays a big role, and without marketing it's very hard to get any information about your project across to clients. Moreover, quite often clients aren't necessarily founders who look at these things more rationally; often procurement is handled by other people who also think about which simple, understandable signals they can attach to their decision-making when they choose something. And we need to provide these signals, because otherwise, even if we show cool results, they won't buy.

Alexandra Gulamova: And when I mentioned support too — there's interesting feedback. At the very beginning I said that we built the easiest possible onboarding, automatic among other things, because many people in Web3 prefer not to interact with people unnecessarily and to rely on themselves as much as possible even in a service, to understand what it does. But now I often see in discussions that even in the Web3 market people are appearing who value support — when a human sells them something. Previously they'd come, understand themselves that they need it — that's more of an OG approach, there's a lot of it, and we, naturally, oriented and still orient ourselves first of all toward these people. But there's also a huge number of people who value a more traditional approach in business — when you come to them, tell them about it, make possible presentations, get feedback. And whereas OGs would just run away from this and not use the product, there are people for whom this is a mandatory part and an indicator of a certain quality. Naturally, we'll work on that too.

Igor Gulamov: Many of these people came into blockchain in the last two years.

Host: It seems to me, by the way, that even many OG startups have now moved into a phase where procurement goes separately — separate people handle it. Take even the example of 1inch: they've already turned into a fairly solid company where the procurement of services and products happens completely differently. This is, on one hand, a very good sign for our whole industry, and on the other — you know, I sometimes feel like an overgrown dinosaur: I'm used to us solving all questions somehow simply, but here you already need to make a presentation, you need to be more familiar with the PDF. I also thought about this: security in the Web3 world is often partly marketing. Say, some company like Certik enjoys great popularity, despite a reputation for perhaps not the highest quality of service — simply because it's a good, well-known brand among retail. Say, I did an audit with Certik, slapped their logo onto my website, and retail sees a well-known name — "oh, super cool, people took care of security." So here too it turns out that if you're pumping up your security brand, you need to pump it up so that everyone knows about it, not just the founders of some product.

Alexandra Gulamova: And right now we're looking for a person who will be fully responsible for this — to work as much as possible on various platforms. Right now we're developing Twitter more or less, but there's also the same Reddit, and other platforms. Accordingly, a person will come who understands this and will approach it more professionally.

Igor Gulamov: Speaking of the technical team — we don't plan to grow it substantially. We plan more of a vertical scaling — introducing a greater number of AI processes for development. This helps engineers do a larger scope in the same time, substantially larger. Right now we hire into the company only AI-native people — both engineers and non-engineers. The approach is this: a person may be a bit worse at writing marketing articles by hand, but at the same time knows how to build a pipeline in which AI does that work — that's what we need.

Host: Why?

Igor Gulamov: Because it's a bit worse now — but the next generation of the model will come out and be much better. A person who is above all oriented toward working by hand won't be competitive against such an approach. As for development, right now — as I said earlier — we've moved to a format where the developer interacts with several AI agents at once, hands them tasks, and the agents do these tasks anywhere from 15 minutes to a dozen hours. That happens too — especially when processing some data. And in this format it works efficiently: with a small team you can do a great deal.

Host: It seems to me this is very valuable input in general for many participants in the labor market — about how they need to change their approach. I actually thought that indeed, if you want to be competitive in such a soulless capitalist market, you really do need to make marketing a soulless machine too, one that just soullessly grows reach, not aiming at some top-10 people. Thanks, guys. I've asked all the questions I had. I think Zhenya has too. It was very interesting. If you have anything else to announce, to declare, to advertise — the floor is yours.

Alexandra Gulamova: We've also discussed everything — we even made some announcements about what we're working on and what to expect in the next versions. Come, use it, increase the security of your products. Thank you very much for the invitation, it was really great to talk.

Igor Gulamov: Thank you very much. I've already told you about our two main next updates. In general, we're open to meeting, communicating, collaborating with projects, auditors, funds. We'll be raising our next round soon, and I think for funds our solution may be interesting precisely as a product, not as an object for investment. And whoever's up for it.

Host: Thanks again, guys. Thank you, Igor. Thank you, Alexandra. Thank you, Zhenya, for helping me prepare for this episode. And thanks to those who support us. Thanks, first of all, to all our listeners and the users of our chat. Thanks to those who support us on Patreon and on Boosty. And also thanks to our sponsors: it's 1inch — a leading DeFi ecosystem; it's Zerion — an enterprise-grade Web3 API; it's Fluence — a decentralized cloud platform; and it's Acki Nacki — the fastest blockchain possible. Subscribe to us on YouTube, on Telegram — where else are we? We're on all podcast platforms: subscribe to us everywhere, drop into our chat, bbchat — we'll be glad to talk with you there in person. Bye everyone.