Igor Gulamov on cp0x #21 — the Plasma bug, ZeroPool and SavantChat
cp0x podcast #21 ("Pepperoni Show"), December 2025 — Igor Gulamov on the Plasma bug, the story of ZeroPool and SavantChat, the state of ZK, and the future of AI and auditing. Original: https://www.youtube.com/watch?v=2B2Sj2vh450
Host: Hi everyone, this is cp0x podcast #21. Our guest today is Igor Gulamov — technical co-founder of SavantChat and technical co-founder of ZeroPool Network. Hi, Igor.
Igor Gulamov: Hi.
Host: And my co-host is helping me run the podcast today. Hey!
Host 2: Hey there.
Host: Igor, I tried to dig up some information about you online — honestly, there isn't much. I found only a few talks and a couple of small pages. Please, tell us about yourself. What did you do before crypto? How did you get into it?
Igor Gulamov: Before crypto I was a PhD student, and I also had a small project distributing installs — there were contracts with some antivirus companies, and we distributed them. And in science — high-energy physics.
Host: Which university, if it's not a secret?
Igor Gulamov: MSU (Moscow State University).
Host: The physics faculty?
Igor Gulamov: Yes.
Host: Interesting. And how did you go from the physics faculty into crypto? For some reason there are a lot of physicists in the crypto space.
Igor Gulamov: Yes, because group theory matters in cryptography, especially with elliptic curves — you can't do anything there without group theory. It's very useful in SNARKs too. So there are a lot of physicists here building cool things. I got into crypto in 2017. Back then Petya Korolev was assembling the BANKEX Foundation team and drew in a lot of people who later built well-known large projects. Many people passed through BANKEX Foundation back then.
Host: I didn't know, actually, that this scene was put together by Petya Korolev. We've heard about BANKEX a few times on recent podcasts, and you, apparently, came from there too.
Igor Gulamov: BANKEX Foundation played a big role. It was a separate division — not BANKEX itself; it differed a lot in terms of the people there. Alumni from it include, for example, Matter Labs and Tornado Cash. I also worked at BANKEX Foundation, wrote the first smart contracts in Solidity, and then worked on Plasma. I found a vulnerability in Plasma. I was on the very last Plasma Call. But we'll come back to that.
Host: Tell us about BANKEX Foundation, then. How did it all happen? How did Petya Korolev know you, and what was the offer? So you paused physics and went to look at this interesting thing?
Igor Gulamov: We once studied together at SUNC MSU (Moscow State University's Kolmogorov school), in the same class, and kept in touch. So I found out Petya was assembling a team, talked to him, and what he was doing seemed interesting. Back then I was thinking about where to go — crypto or AI. I decided on crypto.
Host: Any regrets now?
Igor Gulamov: No, no regrets. Because for many years, to work effectively in AI, you had to be a big corporation and build some kind of corporate recommendation system that shows a banner 5% better than the competition. That's boring, so no regrets at all.
Host: And at BANKEX you had a super-strong team, and you mostly did research?
Igor Gulamov: Yes, we did research on Ethereum scaling. We also supported BANKEX on the Solidity development side and went around to hackathons — with good results. In fact, at a hackathon in Singapore in the winter of 2018–2019, I presented an architectural bug I'd found in Plasma Prime. It affected every plasma of that architecture. And Plasma Prime had been announced on the main stage a few months earlier, in 2018.
Host: Then tell our more advanced listeners about this bug — what it was. I think we've touched on this topic on some podcast before, but without the details: it was just mentioned that someone from the Russian-speaking community found a bug, and after that plasma collapsed. Apparently that was you, and you're the right person to ask about this bug.
Igor Gulamov: Okay. Plasma — any plasma — is an optimistic structure. What does "optimistic" mean? It means anyone can send cryptographic commitments there, as many as they like, but then there's a game you can win if everything follows the protocol's rules. And if someone breaks the rules, they get penalized. And I discovered that you can do splits there — create additional branches — which is very bad for the protocol. There's an analysis on ethresear.ch; it's very old, but it's there, you can read it.
Host: Can you say in a couple of words what exactly breaks?
Igor Gulamov: Okay. The whole point is in the game theory. For every incorrect action there was a way to penalize whoever did it, and that incentivized the protocol to work correctly. Not just to penalize, but also to find the correct consensus. And I discovered that you can do splits there — that after a single given state you can consider both one state and another to be valid. This is very bad, because then someone could keep a state private, not show it to everyone, and then suddenly present an alternative chain branch that is also long, also has value, and you can't prove that it's any worse than the correct one.
Host: To translate for a less advanced user: you can make a branch with a different state — say, more money. And which state is the correct one — the one everyone considers correct. And in that other one, presumably, you've got more money.
Igor Gulamov: Yes, you can do it like this: sell your assets in one branch, and then say that this is wrong and everything should be reverted.
Host: Okay, so you found this. What happened next? Did you immediately write and publish an article, or did you tell someone first?
Igor Gulamov: I discussed it on ethresear.ch with Vitalik, then at a meetup in Singapore, then on that very last Plasma Call.
Host: And what did Vitalik say? Did he agree, just by checking that everything in the proof was valid?
Igor Gulamov: Yes, the proof isn't complicated. The structure itself is fairly cumbersome in terms of game theory, but if you find a hole in it, that hole has a fairly small description. It's not a case where many improbable factors have to line up. It's a fairly simple set of actions you need to perform to exploit it. Finding it wasn't easy, but verifying it is easy. I didn't set out to do bug hunting; I was working more toward building such a protocol. But the very structure of the protocol tells you what? That plasma operators or users can do whatever they want, because it's an optimistic protocol. And the job of whoever designs the protocol is to come up with a game theory that, regardless of what the malicious participants do, finds consensus, finds the truth, and penalizes the villain. It's a game like that. And I found a way for the villain to win this game. So it wasn't security research as such — the very process of producing such protocols is a game where good must always beat evil. And if it doesn't work out that way, you can't release such a protocol, because it's flawed.
Host: In principle, all the optimistic stuff runs on similar games — the same Optimism, Arbitrum, and so on.
Igor Gulamov: Yes, but unlike plasma, the data there is stored somewhere else. The main difference between optimistic rollups and plasma is that rollups have an L1 that stores the data and guarantees it's available, that nobody hides it. Because in that vulnerability the main problem was exactly that a hidden branch appears, one that nobody knows about for a while, and then it becomes the true one.
Host 2: Can I jump in here? I got confused. So the problem isn't even that two different states turn out to be valid, but specifically the length of these branches?
Igor Gulamov: If the branches are available, public, then in consensus you can always say: "Here, I found two branches, here's the Merkle proof for one, here's the Merkle proof for the other, they're both valid — that shouldn't be possible." So the branch with, say, the lower nonce or some hash should be penalized. If we delegate data storage and availability to L1, we can always do this, because the data is available. But plasma didn't have that. Plasma is a protocol in which it's assumed the operator might suddenly hide everything, and the game has to be designed to handle that scenario properly.
Host: Okay, that's probably enough technical detail. Tell us what happened next. You came to the Plasma Call, showed the sequence of actions that lets the attacker win. And then? Everyone dispersed? There were companies that had raised money to build plasmas, there were various implementations.
Igor Gulamov: That's not how it works. First of all, there were other plasmas, but they all had problems. And the plasma where I found bugs was considered the solution to those problems — but it turned out not to be. Naturally, nobody dispersed, everyone went off to do more research. Then it turned out that plasmas don't work out. And most plasmas didn't happen not because they're strictly impossible, but because they're inconvenient. The reason is roughly the same as why people usually make transactions with some USDT on TRON or on Binance rather than with Bitcoin. Because on TRON and with USDT it's convenient. So people went off to do more research, then Karl built Optimism, and they're doing fine.
Host: And how did your own path continue after that? Was this moment some kind of finest hour for you?
Igor Gulamov: I didn't build a personal brand on it, didn't publicize it. I felt it was the beginning of crypto winter, everyone was already having a hard time. It was a problem for everyone who was part of the crypto community — those 15 transactions per second on Ethereum and even fewer on Bitcoin. We were thinking about how to fix it. Publicizing it would have been useless for the technology: it would have signaled to people that scaling doesn't work. Naturally, I didn't do that — why would I? And the fact that people then went on to rebuild things — that was actually a long, hard road. We only saw hundreds of transactions per second and more a couple of years later.
Host: But you're effectively the only one here who could have made a direct profit, and instead you become a victim for the common good. And you take the biggest loss in this game.
Igor Gulamov: Well, how to put it? I made a commitment to the research community that the bug exists. We worked on fixing bugs and building something better than what existed. It was a story more about technology than about money or broad recognition. And narrow recognition — especially in the community of those times — worked like this: code is law. To decide something at the highest level, you didn't need social trust, you just needed to find, show, and describe the bug. It was all completely different from how it is now.
Host: Since you brought that up — tell us what's changed since then.
Igor Gulamov: Narratives. People for whom the main thing in blockchain is to make money. Marketing that pushes engineers aside. Literally last week an influencer told me there are dozens of people like me — in a bad sense. I understand that "dozens" is the front page of CoinMarketCap. But back then it was different. And that what I do is useless. It happens.
Host: And why did she suddenly decide to tell you that?
Igor Gulamov: It's scandals and intrigue. If I say her Twitter handle, she'll get another 10–20 followers from me. If I don't, let them come to my Twitter and follow me.
Host: Let's get back to plasma along the timeline. You were doing research, like the others on the team. And from the outside, by the way, it wasn't obvious plasma was dying. Apparently you didn't think it would die either — you thought some working implementation would be found. What happened next? As I understand it, some were looking for an implementation — what were you busy with? You said you weren't a bug hunter back then — you were trying to build your own plasma. When it became clear it wasn't working out, what happened in your career next?
Igor Gulamov: My story with plasma is connected to BANKEX Foundation. And literally a month later BANKEX Foundation ended — there was a good story there with the funds, specifically with the local BANKEX Foundation. After that I went to work on SNARKs, because SNARKs were developing. One direction was scaling related to SNARKs, and another was privacy. I saw a certain demand for what I can do with SNARKs on the privacy side. And for about a year I worked on introducing SNARKs and privacy into Waves. We made a precompile for SNARKs. And only later, within ZeroPool, much later, we built smart contracts that use SNARKs and can perform anonymous transactions. But I'm getting way ahead of myself — that's no longer 2019–2020, that was after 2021. In Waves there were the first, fairly rough prototypes of how to do anonymous transactions. There was a prototype of confidential transactions — that's when the transaction graph is public but the balances themselves are hidden. There are two levels of privacy: the first is to hide only the amounts, the second is to hide who transferred to whom as well.
Host: As far as I know, we still don't have anything like that on EVM. And I just remembered — I recently heard a workshop where someone said they were about to do this level of anonymity, where only the amounts are hidden. I forget who.
Igor Gulamov: That was done, for example, in Aztec: only the balances were hidden, not the transaction graph. That's much easier than hiding the graph too. Nowadays it's completely trivial. You could even use FHE, though FHE, in my opinion, is overkill — a heavier technology meant for something else. But you could use it fully now. You could also use plain cryptography for this. There are various ways. The problem isn't technical. It can all be done now — you could even deploy it on mainnet. Other protocols, whether they exist or no longer do, run into the main problem — a regulatory one. Regulators don't like anonymous transactions; it's not that they're hard to make. They were hard to make earlier. When we were starting ZeroPool, in late 2019 to 2020, it was hard: the mass solution for SNARKs was Circom, which ran on a Node.js server, and the Rust stack, Fawkes-Crypto, was still not the clearest back then. The first protocol could take more than five minutes to prove something on a mobile phone, and that wasn't in a browser but in an actual app. It was slow. And if you used the very first JavaScript implementation, it just turned your phone into a hand-warmer for winter. You couldn't use that in a production client. And you need it on the client, because if you delegate the proving to a server in the cloud, you lose privacy.
Host: Let me jump in — I want to go back on the timeline. Do I understand correctly that afterward you worked at Waves and implemented SNARKs there? And you got it all done, the implementation of anonymous transactions with hidden amounts existed, but it wasn't shipped to production because of regulatory concerns. And at some point you decided: that's it, I'm leaving Waves and going to do my own thing. More or less like that?
Igor Gulamov: Not quite. At first I did it only in Waves, but then I saw demand from various blockchains — from Ethereum, from Near Protocol. And I decided to do it within a separate company, because the technology, SNARKs, is the same everywhere. The main task is to attach these SNARKs: you need to write precompiles, because the elliptic-curve math has to be efficient and run close to the metal. If you write elliptic-curve pairings directly in Solidity, the block won't fit and it'll be way too expensive in gas — not cheap on gas even if you run it in precompiled contracts. So here's how it went: in Boston in 2019, our team built the first ZeroPool prototype. It was on Circom, ran on the client with heavy lag — took several minutes to prove, but it worked. We made the first transaction on it on Ethereum, most likely earlier than Tornado — with a fully hidden transaction graph. After that, part of the team left for 1inch. And I, together with Alexandra, continued building ZeroPool.
Host: Can you say who left for 1inch back then?
Igor Gulamov: Nikita Kozlov, Artem Vorobyov, Kirill Kuznetsov.
Host: Got it, I know those names.
Igor Gulamov: Yep.
Host: And you, together with Alexandra, went to build ZeroPool. Tell us how that comes about? "That's it, I'm doing my own thing, raising a round." It's a big step to leave employment for your own venture.
Igor Gulamov: I'm an entrepreneur. Over my whole life I've worked as an employee for maybe a year in total. For me the big challenge was going into employment at all — at BANKEX Foundation. And big thanks to Petya for organizing that structure so it wasn't difficult: there was no corporate bullshit and all that. You could just plug in, and nothing got in the way.
Host: So the work at Waves and your other things — was that all contract work? Or how?
Igor Gulamov: Yes, it was contract work. I was something like a freelancer, working as a contractor, not on staff, doing only open source. I had a principle that all the code I write must be open source under an MIT or Apache 2.0 license. I still do that to this day. The only thing I don't do that for is coin-salad, because it's dangerous: if you open-source it, it could harm a lot of people, and I don't want that.
Host: Okay, then let's move on to ZeroPool. What is it? We've already learned it has precompiles and SNARKs. Correct me if I'm wrong anywhere, because honestly I never really touched ZeroPool. What happened in ZeroPool and what was going on in your life at the time?
Igor Gulamov: ZeroPool is a privacy engine, that is, a ZK circuit, a zero-knowledge program that can prove anonymous transactions. It's Zcash-style: there's a set of transactions, and we prove that we're spending something from that set and that it hasn't been spent before. All similar protocols are built on such proofs. We started developing our own SNARK API in Rust, because there was no API. There are lots of solutions now, but back then there were only Circom and ZoKrates — they were very heavy and ran only on powerful servers. We built ours in Rust and got it to work in the browser on a mobile phone — not even on a desktop.
Host: Let's stop here. ZeroPool — what is it, actually? What kind of entity is it: an application, a blockchain, a service?
Igor Gulamov: It's an anonymous-transaction technology. It consists of several components. A smart contract — one per chain. Precompiles — those have to be developed separately, because they existed only on Ethereum, nowhere else. And a SNARK — that's the same for everyone. The SNARK is where the main value is, because it had to be written in Rust almost from scratch. There was no ready way to take a circuit and compile a program out of it that everyone could use. We did all this, and cooperated with Polkadot, Near, Waves, and Ethereum. Ethereum had precompiles; in Waves we made them, in Near we made them. Now, if something on Near is zero-knowledge and proves something, our code is used in the verifier. On Polkadot we implemented privacy. It's a lower-level structure than the smart contracts in the ecosystem.
Host: Let's touch on your structure. How many people were working on ZeroPool at that moment? What was your relationship with the foundations — contract-based, or did you do open source and they gave grants?
Igor Gulamov: We did open source, and they gave grants.
Host: How big was the team?
Igor Gulamov: At different times, 4–6 people, no more.
Host: How many of them were engineers?
Igor Gulamov: Everyone except one person was an engineer. Alexandra carried the non-engineering side the whole time. It was a fairly large scope: grants, plus the difficult work with the people and organizations that would have been happy to drag us into some story we didn't want to get involved in. Because anonymous transactions are a technology with all kinds of uses, and we didn't want to be associated with some of those uses in any way.
Host: Got it. So Alexandra protected you from all the drama and, effectively, prison, where they kept trying to drag you.
Igor Gulamov: Yes, and thanks to her work I can now say things on this podcast without restrictions on my life. Unfortunately, not everyone is in that position.
Host: It's fitting to recall Tornado Cash — Alexey Pertsev, I believe, is now under house arrest, and Roman Storm, as far as I know, is still awaiting a court decision. On my part — all my support to the guys. I hope they beat this situation and come out of it as free people, without obligations to stay in certain places.
Igor Gulamov: Yes, I fully and completely support the guys. The main misfortune is that regulators have already done enormous damage: years of life, health, and progress were spent fighting bureaucrats instead of making wonderful and interesting things. And Tornado Cash lost the most from it, because the attack was aimed at them. But if you look at the most successful anonymous protocol — Aztec Network — I still can't just take it and anonymously transfer funds from one address to another through it. They have some testnet or other; maybe they're doing interesting things less publicly. But because of the situation regulators have put the industry in, you can't develop this technology broadly right now. And that affects everyone.
Host: Here I can't help mentioning: Aztec Network literally just wrapped up a sale yesterday, relative to the recording. I don't know when this recording will air. And it's already, as far as I know, a completely different product compared to what Aztec used to do. I even remember that implementation where the transfer amounts really were hidden. Since we've moved to Aztec — can you tell us what's there now, what's left of the privacy and the ZK, if you're up to date?
Igor Gulamov: I'm not very deeply up to date on their latest protocol, but as far as I know, they use their own DSL, Noir, to make private smart contracts. So the focus is not so much on transactions as on things in general that can be made anonymous with zero-knowledge.
Host: So it's anonymity at the smart-contract level. We probably won't go deeper. Back to ZeroPool. When you were creating it, was the initial idea to make it a commercially profitable product? Or was it pure research that you were just interested in — a kind of umbrella over activity on different blockchains?
Igor Gulamov: I was interested in doing it — and I still am. Naturally, we wanted to make a product initially, but then came documents and precedents that made it hard to build a product with lots of users out of it. We even started taking investment for the pools — although in 2021 there were times when several people a week wanted to invest. But we understood that for regulatory reasons we could make it not a product but a technology — forced to be open and available to everyone. So ZeroPool was funded on a grant basis rather than an investment basis. Because a grant is an obligation to make a technology everyone can use.
Host: Got it. So ZeroPool ran into regulatory reality, and that kept it from growing into a product, leaving it at the stage of open-source code that can be used in various blockchains. More or less like that?
Igor Gulamov: Yes, that's absolutely right.
Host: Before we move on to your current product and the AI topic, I wanted to ask about ZK. You're clearly an expert — I'd say you're in the top 15 of ZK experts in blockchain. Give us, please, an expert overview: what's happening with ZK in crypto right now? And maybe touch on why it's taking so long to introduce ZK precompiles in Ethereum, which, as I understand it, would make everything much easier. But first — a general overview of ZK as of now.
Igor Gulamov: ZK is developing very rapidly, the protocols are alive. Again, speaking of ZeroPool: it's not sunset, ZeroPool is alive, we support the technology, and people use it — there are projects using our code. In general, ZK is now much more performant than a few years ago. A year ago a way appeared to prove FRI much faster. A few years ago there was a breakthrough — using short fields with extensions instead of long fields. ZK is developing as a technology. The problem is what? The loudest thing is the narrative, and the narrative is some prediction markets or NFT trading. You don't need ZK for that. If you use optimistic-stack technologies, you can build tens of thousands of transactions — you don't need ZK for that. ZK lets you build genuinely heavy protocols. A year ago we had a research project, there was a talk about it: you can make a rollup that uses technologies similar to Filecoin, but with refinements. Some technologies are like storage, but with data stored not through replication but through Reed–Solomon codes, whose consistency you can also prove with SNARKs. As a result, the rollup can cryptographically prove that the network stores the data, and put its blocks into that data pool. It could be a very large pool — as big as Filecoin's, or bigger. So, in principle, you could make not just a data store but some kind of Web3 YouTube, where the storage-reliability guarantee for every video would be as strong as an Ethereum transaction. It's just that there's no product demand for it right now. That's probably the main problem. But the technology is powerful, it lets you do really cool things. One of the barriers is the difficulty of development. But I actually believe AI can help here too. For a long time the problem was that everyone made a custom DSL that almost nobody could program in. Matter Labs had its own DSL; StarkWare, pouring in enormous resources, did manage to teach people to program in Cairo — that was a far from easy adoption story. Aztec faces the same thing now: I don't know how many Noir programmers there are these days. And AI can help in that, at a certain stage of its development, it'll turn out to be able to learn exotic programming languages more easily than people can — and then that problem goes away. One of the current approaches is the ZKVM: instead of teaching people to program in custom languages, they program in Rust and prove it through a ZKVM. That's all well and good, but a ZKVM is very bad at proving ZK-native cryptography without special extensions. And that's a problem, because we need signatures, we need SNARK proofs. Yes, a number of ZKVMs have tools for this, but they aren't very convenient. Convenient tools that a good developer could just pick up and write, say, some recursion or a MapReduce on SNARK, don't exist right now. I think it's all ahead of us. Some of it will be helped by advances in cryptography, some by AI, some by advances in protocols.
Host: Can you name some protocols or people worth following in ZK, whom you think are at the cutting edge of the technology?
Igor Gulamov: It's worth following the Polygon Miden team — there's Daniel there; Polygon in general; and Jordi — the one who created Circom. He went off to a separate company, I can't recall the name right now.
Host: I hope we'll find their Twitters or GitHubs and put them in the show notes, because I, for one, don't know any of these guys. Well, let's move closer to your current product. AI is evolving. Where did that evolution catch you? How did you realize something had changed? And how did your gradual transformation from ZK toward AI happen?
Igor Gulamov: I've been following technology for a long time. Back in the early 2010s I read Kurzweil and Vinge, and I understand where it's all heading. I started following really closely when the first image generators began coming out — the early ones, with dog faces all over the place. That was before 2022, around 2020–2021. And when GPT-3 came out.
Host: Let me jump in here. I'm curious how information reaches people like you who are deep in the field. Do you learn from articles published somewhere? From Twitter, from some media?
Igor Gulamov: Mostly Reddit. Reddit, Twitter.
Host: So it comes through Reddit and Twitter?
Igor Gulamov: Yes. Plus, since I work with models, GitHub, naturally. But I don't train foundation models, so I get new information from their developers on general terms. Maybe I know some faster channels where information accumulates earlier, so news about a DeepSeek release might reach me a few minutes after publication. But I don't have private channels. I also had some audit tasks — I did audits of smart contracts and SNARKs.
Host: Individually, or within some company?
Igor Gulamov: Individually. It was a side activity. My main focus was, of course, zero-knowledge, but since those are technologies requiring strong competence in smart contracts, game theory, and cryptography, people needed audits — they'd come to me, and I'd take it on. Why? Because I consider audits the second-best way, after hackathons, to understand what cool technologies are emerging in the industry: new protocols with interesting things come to audits.
Host: Since you keep mentioning hackathons — let's dwell on them. As a participant, how do you learn about new technologies? By seeing someone's prizes, or others' ideas at the awards ceremony?
Igor Gulamov: A hackathon is when you show up and the whole premise is to take the newest technologies and make a prototype of something out of them. Naturally, if you work with these technologies rather than just read about them, you get a much deeper understanding.
Host: So it helps to actually try, hands-on, a technology you've only just read about somewhere.
Igor Gulamov: Yes, exactly.
Host: Back to audits: you had audit tasks, and at some point — what?
Igor Gulamov: I have quite a lot of experience. I didn't build a personal brand specifically as an auditor, because I'm more interested in building, but it was a fairly active side activity. And I had several interesting audit tasks that, starting from the release of GPT-4, I fed to neural networks. And they didn't solve them. Everything changed in February 2025, when DeepSeek came out. DeepSeek, with minimal hints, solved one simple little task. It was an ERC-20 token implementation that used data caching on transfer. The point was: on a self-transfer the balance doubled, because it first wrote the balance to memory decreased by the delta, and then overwrote it increased by the delta — that's how. And DeepSeek learned to find such simple mathematical bugs — with hints, but it learned. And I realized we needed to make an AI solution for smart-contract audits, because that's the future — and it can already do it. There were other projects, but they used OpenAI's neural networks, which have very little creativity. That's fine for a range of tasks, but bad for finding vulnerability vectors. Products based on those networks can, for example, cross-check documentation against code, but they can't creatively find an interesting vector. So we started building SavantChat — from the very beginning based on all kinds of neural networks that we laid into a single pipeline. We have a hypothesis-generation block, where through prompt engineering, temperature, and a number of factors we get the network to work in the most creative mode possible. Then there's a sub-agent — a hypothesis filter — that weeds out hallucinations and false hypotheses. Then comes deduplication: if we found something identical or similar, we remove the duplicates, keep only the valuable data in the report, and send the report to the team that had the smart contract scanned.
Host: In general it's clear, but let's dive in a bit. Prompts and prompt design — I think almost everyone has heard of those, but temperature — few have. Can you tell us what it is and why it matters? And also: how many models do you have under the hood, how does everything get distributed among them, and what other settings besides the prompt do you change there?
Igor Gulamov: Temperature is one of the parameters of using a model. At low temperature everything is as predictable as possible; at high temperature it's less predictable, the model produces more creative output, but it can also hallucinate, break down entirely, and loop. So high temperature is a way to make the model think differently: more creatively and less stably.
Host: To some people that even resembles humans a bit, no?
Igor Gulamov: A bit, yes. At very high temperature the model can have artifacts: it can find a word it liked and then write it a thousand times. So in some ways it's like people.
Host: A question that comes up for many listeners: where in our clients can you actually turn this temperature dial?
Igor Gulamov: You can, for example, in Google's AI Studio (Gemini) — it's a more engineering-oriented chat where you can adjust the system prompt, temperature, reasoning length, and so on. If you want a chat as a product, better not to go there, but to feel the API as it is — the way it's used in apps and agents — it's ideal. OpenAI is moving away from temperature, but since they have the most creative models and people use them for that, there aren't really any problems. The Chinese models all support temperature — DeepSeek, Moonshot. By the way, it's a very interesting phenomenon that China — the freest state when it comes to freedom of AI technology — has done so much for it. Speaking of SavantChat's components: we have hypothesis generation, which uses models that are good with creativity, like Gemini, at maximum temperature. Another important point is working with documentation. SavantChat now extracts documentation from HTML, GitBook, Markdown, PDF — including images. From the documentation we build a RAG database, and relevant chunks go to the model so it generates hypotheses better and understands better what's going on. Because a very common cause of poor results is that the model doesn't understand what's happening, makes a wrong hypothesis, and the result comes out suboptimal.
Host: Let's slow down; I'll try to formulate it, and you tell me whether it's right. Essentially SavantChat is, in a sense, a team of auditors that needs different people with different skills. One part has to brainstorm and throw out ideas for how to break the project or smart contract. And the other, on the contrary, has to be much more grounded — carefully study the documentation, check whether it's even possible per the documentation, and work through the ideas the first part came up with: what cases are possible and what would happen.
Igor Gulamov: More or less, yes. We give the documentation to the brainstorming model too — maybe a bit less, but enough that it doesn't make things up. Because without documentation the model very often starts fantasizing. We also make architectural documents from the code using models: the models look at the code, study which paths the data takes, how the branches work, what user scenarios there might be. That also goes along with the documentation — not just the protocol's documentation, but the documentation we generate. Then the filtering is done by low-temperature models, which can steadily, step by step, check the entire chain of reasoning of the creative model and find errors in it. Then we remove duplicates and form the report.
Host: My question here: the models you use — are they specially trained on smart contracts, or are they public versions? I'm interested in the training aspect. And if it's a local model, what happens in it?
Igor Gulamov: We use public, commercial models. The whole AI industry in software development uses public models.
Host 2: Why?
Igor Gulamov: Because the model producers themselves train them on writing code, and Google also on writing scientific papers. What we use them for is an adjacent direction. Cursor trained its own model, Composer — it wasn't a state-of-the-art release, and after that Gemini 3 and Claude Opus 4.5 came out, so now it's completely not state-of-the-art. But we're a small startup, not a giant. We can't train foundation models that would be that effective — and, most likely, the volume of audits isn't large enough for it to make much sense to fine-tune a foundation model on them. We use in-context learning: we collect vulnerability databases — that all exists — but the most interesting value comes when the models work not from a database, but spend a lot of reasoning and come up with something new. It's very similar to Google's Deep Research. Google had a solution for scientific papers in the spring, and now there's a solution for finding bugs — but not for smart contracts, something more general. It's less expensive in terms of the amount of quality inference and is aimed at ordinary code rather than blockchain. But overall the direction is similar. We spend really thousands, tens of thousands of requests, in a hundred threads: at every interesting point in the code an AI agent is launched to investigate that spot for vulnerabilities. So we do a lot of things: prompt engineering, RAG, optimization, selecting models and pipelines. These are complex, branching pipelines — a directed cyclic graph up to 10 steps deep, where one model passes its output to another, and this data is processed with different tasks to reach a result. To effectively filter some result, you also have to do a number of preliminary steps with it, remove artifacts. For example, the model that generates a hypothesis might write emotionally: that this is a critical that will doom everyone. Before handing it to the critic, you need to pass the text through a simpler model and scrub all that, so the critic isn't biased.
Host: Funny. So there used to be the human factor, and now we can talk about the hallucinating factor of AI.
Igor Gulamov: Yes, you can make a special section in the report for hallucinations — so all the artifacts pour in there, and then you just have a pile of these documents. There are a number of ways to optimize all this. In the end, our reports reproduce the root cause of all the vulnerabilities that occurred this fall. "Reproducing the root cause" doesn't mean we reproduced the full exploit — that happens too, but not always. It means we found the place in the smart contract where the error is, and the model said what kind of error it is: for example, an invariant breaks there, or you can assign yourself more than the smart contract allows, or break some state somehow. Then, if a hacker works with that, they can make an exploit to steal a lot of funds. But SavantChat is an auditor: it highlighted the root cause, wrote that an invariant is broken there, and the development team, having received this report, should fix it themselves. Here's one of our recent cases: in one of the audits that the Lido protocol did in SavantChat, the fix rate across 99 issues reached 50%. That's not the true-positive/false-positive rate, it's specifically the fix rate — meaning what was found was interesting enough to base changes on.
Host 2: Here's a question I find interesting. When a human auditor looks for vulnerabilities, they think within a familiar pipeline, and it's fairly hard to step outside it. Sometimes fundamentally new vectors are found, but mostly it's all fairly standard. When you create SavantChat, even though you leave a lot of room for creativity through all these parameters, you still, one way or another, reproduce the familiar human workflow. And I'm curious: does SavantChat find vectors and vulnerabilities that were previously atypical — such that you could add a whole new classification? And if not — is there an expectation that there's some class of vectors, unimaginable to our imagination now, that only a machine could come up with?
Igor Gulamov: That's a very good question. DeepSeek surprised me half a year ago. There's an almost academic example of an attack on a casino smart contract — predictable randomness. It's a smart contract where you call a "play" function, and the randomness is computed, say, from the block hash rather than from an external oracle. Such a contract is usually broken like this: the randomness is reproduced separately, on the attacker's smart contract. The attacker calls the casino contract through their contract: that contract checks the randomness, and if it's favorable, passes the request through — plays; if not, does nothing. That's the standard attack. And half a year ago SavantChat came up with: take a flash loan, play. If you lost, you can't return the flash loan, and the whole transaction gets reverted.
Host 2: That's cool.
Igor Gulamov: And you don't need to deploy an extra contract. That was many updates ago, with a network that's very weak by today's standards. So machines aren't people. If you consider the set of errors that human auditors miss, then SavantChat is the best auditor in the world, because we find all the latest root causes that were in hacks and that people missed. But if SavantChat competes with a human head-to-head, it'll be worse — a human will find even more. It's just that what's hard for people to find isn't always hard for AI to find — some of those vulnerabilities are actually easy for AI to find.
Host 2: Interesting, thanks for the answer. I want to sail further into this. We stew in our DeFi or Web3 sandbox, and vulnerabilities here are cool, but they don't have a big impact on the world. But there are fundamental things — some encryption protocol used by the whole world. You can audit not just in Web3 but everywhere. What are your expectations, as someone who directly uses this toolset and understands the potential? What might await us in the coming years?
Igor Gulamov: The coming years will be interesting. As for cryptography — it's still an open problem: whether P equals NP. If it suddenly does, there'll be no cryptography. But most likely it doesn't. Neural networks let you design new products and complex things much faster, and it'll keep getting better and faster. And there's a positive feedback effect here, because they help, among others, the people building new neural networks. It's not necessary for the singularity to have already happened for neural networks to accelerate the production of smarter neural networks. They can simply help researchers write papers, find more value in already-written papers, help engineers ship better-optimized code, and design efficient ASICs for inference.
Host: You're describing not the most extreme cases. But will there be something that breaks nearly everything, with AI to blame, the way people constantly talk about quantum computing with respect to Bitcoin? Do you think AI will bring something into our everyday world that changes everything?
Igor Gulamov: I think that within several years there will be a technological singularity, and before that there will be AGI that's smarter than all people, because it'll be more capable than humans in every specialty. And not on synthetic benchmarks, but on real tasks.
Host: That's super interesting — I had a question about AGI. So you're really sure AGI is fairly close? Tell us how you see it. And will LLMs be what gets us to AGI, or will the path be different? It's all guesswork, of course, but maybe grounded in our current knowledge to some extent.
Igor Gulamov: I'm not a foundation-model researcher, so my opinion here isn't valuable enough to answer confidently. But it seems to me it's not necessarily strictly an LLM. There are, for example, diffusion models that can also write code, work fast, and show a high level. I think reinforcement learning is definitely important, and that requires other architectures — possibly based on current ones. What's the concept? Right now there are several startups successfully combining AI in the current sense (LLMs) with what the mid-20th-century cyberneticists considered AI — formal provers. The cyberneticists of the 20th century had an approach not through neural networks but through an engine that can work with statements of formal logic — and supposedly intelligence comes out of that. But if you try to do everything possible with statements of formal logic, it's exponentially hard. It's like winning chess by brute force, and without a fitness function to boot. It's unclear whether it makes sense to go in that direction: it's like sitting a computer down to play chess without explaining to it that capturing the queen is good, capturing a pawn is probably good too, but the queen is better — and making it win by brute force. But what are these formal-logic engines strong at? At the fact that if there's already a path from problem statement to solution, they verify its correctness very quickly. And a neural network can build that path. As a result, if we have a mathematical theorem written in a formal-logic language like Lean, and the neural network built a proof, then we send it to the formal prover and get a rigorous answer, without any hallucinations: whether the network succeeded or not. Thanks to this, in all tasks that reduce to formal statements, neural networks will be able to work the same way they work in chess and go. That is, in math — in everything written in formal formulas — machines will be able to beat people, like in go.
Host 2: I'd like to object — with the example of AlphaGo. We need a basis and rules. But when we add a superstructure of some hypotheses, it hinders the AI. When they loaded an opening encyclopedia into AlphaGo and all the biases humanity had accumulated, it showed expectedly high but predictable results. And when later they gave it a lot of compute and allowed it to act only on the basis of axioms — the rules and the goal, without hardcoding that capturing the queen is good (and maybe capturing the queen isn't good) — then it started making moves that produced a wow effect, that were unimaginable.
Igor Gulamov: It seems to me that's just a newer architecture, a newer training method. It's not that the old model was trained on human data and the new one wasn't. In my view, it's possible that a model trained on human data, if it were made to play against itself, would also achieve something. It just turned out to be immaterial for that version of AlphaZero that played against itself. Speaking of math: there's a hard problem — translating all these theorems into a formal language. But you can proceed iteratively. People hallucinate too, they can misread a theorem's conditions, but here consistency matters. The model first takes a school math textbook, translates all the theorems into a formal language, and proves them. If it understood something wrong, it'll be inconsistent — the proof won't go through. And if it can't prove it, you need to try again to understand what was actually written in the text. And so on, until you have a fully consistent, contradiction-free picture, and then you can move on to harder problems — iteratively, until all of human mathematics is formalized and proven, including open problems.
Host 2: I see a certain connection between program code and human mathematics — the consistency of arithmetic and of theories we consider proven. It's like conditionally reliable code and its consistency, coherence, and freedom from bugs. And really, so far it's just that many mathematician-auditors have checked that it all truly works this way, but there are no guarantees, and we might be in for a big surprise. Do I understand right?
Igor Gulamov: Well, yes, of course. You could formulate a formal theorem that in some popular protocol you can't obtain a lot of value through some cheating method, formalize that somehow, and then the model would prove it like a theorem — that it can't be done. And if it suddenly can, it'll prove how.
Host 2: I don't know if this is interesting or not — I'm further from science than you are. I'm curious what points of danger you see. "P equals NP" is clear — that immediately breaks factorization and cryptography. What other points of tension come to mind — points that, if struck and if they turn out to be fragile, could bring a lot down?
Igor Gulamov: I think that over the next year or two you should worry more about the practical threat vector. Right now there are small neural networks that are practically foundation-level: you can take a distilled, quantized version of DeepSeek, and it'll run at the level of half-a-year-old state-of-the-art on an ordinary gaming machine. And such a network would have enough capability to, say, find and steal crypto on that machine, or some bank funds, and rent a few more powerful servers. Renting a really powerful server that fits a modern state-of-the-art at the level of GPT-5 is on the order of 500 dollars — not per week, but per day. That's also a fair amount, but affordable. Foundation models can already do quite a lot, and in half a year to a year they'll be able to strategically plan an attack. This is a fairly dangerous scenario: if there appears some mobile component of a worm that can think a little on gaming machines with graphics cards, deploy a more powerful system for itself, come up with something serious — new viruses, delivery methods — then rent industrial GPUs and servers on resources like AWS. Plus it can write lots of completely dumb worms, with no intelligence aboard, but varied, hammering at different vulnerabilities. So a full-blown epidemic could occur.
Host: Here I jump in, because I start thinking: we do have such a player — the proverbial North Korean hacker, who has enough money to develop such a network. To me it looks like their main goal is extracting funds. And with the backing of an entire, sizable state, funds will definitely be directed this way. The question is: how do we defend against this? And should we? And can we at all?
Igor Gulamov: A fairly large review and research just came out from Anthropic. They made an AI agent that attacks smart contracts — not finding the root cause, like our solution, which is good for audits, but actually carrying out attacks. And it reproduced about half of the recent hacks — actually reproduced them, meaning it managed to take money off the contract. I think the only way not to become a victim of a vibe-hacker is to do vibe-auditing yourself. If DeFi protocols scan their smart contracts with AI solutions, then their neural networks, even if not the very same ones, will be similar to the ones the attackers will have. Which means they'll most likely find the same vectors that other AI products will use to exploit protocols.
Host: Here I realized I want to clarify two things at once. First — to underscore again what SavantChat's function is now. You already mentioned it, but let's crystallize it. I'll say it, and you correct me if it's wrong. Right now SavantChat doesn't replace audits — you said yourself that a human finds more when searching. SavantChat just finds cases that are hard for a human to reach. So right now it's most effective in combination with a human audit. More or less like that?
Igor Gulamov: Yes, that's correct. But another important direction has appeared where SavantChat is more effective than a human. If the attacker is not a human but a neural network, then SavantChat will defend against it better than a human auditor. Why? Because the mindset is the same.
Host: Yes, that's exactly where I was heading. And the second part, which we'll now move to, is your opinion on the recent Balancer and Yearn hacks. But if we believe these attacks are already being carried out with AI aimed at stealing funds — and you just confirmed it — do I understand correctly that, in your view, the main solution is to sic a conditionally white AI on it, so it defends and finds these bugs faster? And if that's the main solution, how do you win this race — whoever simply has more compute?
Igor Gulamov: Auditing is easier than attacking. Why? Because an audit highlights the fragile spots, but doesn't necessarily give instructions on how to steal money. For example, there's a smart contract with an invariant, and it's been proven that everything is fine for the invariant. An auditor might find that there's a way to shift this invariant by a few wei. Great — needs fixing. But can you scale those few wei up to a few million? Everyone thought you couldn't. And this fall we looked at Abracadabra, Bunni, Balancer, Yearn — it turned out you can. So if an invariant is broken, it needs fixing. An AI audit will find all such spots, and if you patch them, then the attacking AI will have nothing to grab onto.
Host: And here we've arrived at the topic that prompted me to do this interview sooner — such cases have become more frequent. By the way, it's funny: one of the co-hosts I invited was Sasha Suleznev, who runs "Bazovy Vlog," and he said you gave the go-ahead to come to them too. And thanks to these hacks, we beat them to it. But here's the question. There's a hypothesis — nobody but the hackers themselves knows the truth — that one group is behind these four hacks. Your answer — yes or no? And if no, are they links in the same chain in terms of approach?
Igor Gulamov: In terms of approach they're definitely links in the same chain, because all these hacks exploit one thing: an invariant was broken slightly, and then, thanks to that small breach, it was scaled up to very large sums. Hackers read reviews of previous hacks, study them, exchange data among themselves — as in any community, they undoubtedly learn from each other. But the hacks happening lately all reproduce very well in SavantChat. I believe in my product, it really is good, but such 100% reproducibility might indicate that hackers are also using AI. Not necessarily a fully autonomous agent — they might have a scanner that highlights all the fragile spots, and then the hackers just work with them. If it were a fully autonomous story, all the hacks would have happened at once. But if people are working, just with the help of AI, then you get exactly this kind of timeline — roughly one hack a month. By the way, we reproduced the Yearn vulnerability literally a few hours ago. We didn't have Vyper support until recently, but we added it — and reproduced it.
Host: Cool, because with Yearn, as I recall, for quite a while there was no proper understanding of how it worked. For a long time there was no clear postmortem — even, maybe, in closed channels — where the root cause would be clear. And the question hung for a long time: how was it even broken? It's clear something got shifted somewhere, but nobody understood where the cause was. Isn't that so?
Igor Gulamov: Yes, that's how it was.
Host: It was on Vyper, right?
Igor Gulamov: Yes.
Host: Then my next question. Hackers learn from each other, but why don't projects, having seen a couple of similar cases already, try to defend against them? Why don't they run their protocols — not necessarily in SavantChat, but with some tools of their own — against this new reality for them? Especially large protocols like Yearn and Balancer.
Igor Gulamov: From what I see, there's a great deal of distrust toward AI, for various reasons. Not the founders, of course, but the people working on the processes. Often people fear that AI will replace them. If not that, then a psychological defense often kicks in: that AI is useless. And besides, this topic genuinely requires study. If you google "AI audit smart contract," you'll get pure noise. Why? Because to make something resembling an AI audit, it's enough to write a prompt in Cursor — it'll take the GPT-5 model and make an absolutely primitive thing, comparable to what we had on weak models half a year ago. It'll even work, find some simple things. But you can make a million such products: anyone can spend 20 dollars, and they'll all be in Google's results. And there are no public benchmarks to build from. There are independent benchmarks on Twitter sometimes, but you have to search for those too.
Host: A question that came up here. Isn't there a case where a company that wants to use SavantChat is afraid: it'll set a task, SavantChat will find something, and since it uses public models, the bug will leak before they manage to fix it? How is this resolved — that I set a task, a vulnerability is found, and it needs not to leak, given that public models are used?
Igor Gulamov: Yes, this is a really good question — people using SavantChat ask it too. Here's the thing. SavantChat makes tens of thousands of requests with different chunks of code, with different assumptions. For example, for some tasks — a verification pipeline for checking that in some code chunks where there's no critical vulnerability, there is one. So there's a lot of garbage. If you cut in halfway, you'll get a chunk of code shredded as if in a paper shredder. In theory you could reconstruct the audited project's source from that, but it's not easy. And often what's being audited is open source, or something that will become open source soon, so there's practically no risk. Besides, we use neural networks like Gemini and ChatGPT. Our users already store their code on GitHub, with Microsoft, and OpenAI runs its inference at Microsoft too. I don't think there are any risks here. Yes, there might seem to be a risk that we find an exploit and it leaks somewhere. But we have a defensive solution: it won't develop the story up to an exploit that lets you steal a lot of money. It stops at "here, for a real reason, is a dangerous spot in the code." So there'll be a description that something bad can be done here, but without additional deep research and without maximizing the extractable sum. That's ideal for an audit, but for a hacker it would require a lot of additional work. And finding the signal in a pile of noise is hard. We have a separate AI agent for that, and it has the full picture of the flow — of all these thousands of requests: what goes where, from where, and why. Whereas someone intercepting this, first, has only one model, while we use several; and these are just disconnected prompts where it's unclear how one follows from another. The task of finding something in this data is harder than the one we solve. I'm not saying it's impossible — it is possible. But for a person who has this technology, it's easier to just go and hack for a bunch of millions directly.
Host: Within SavantChat, that's clear. But I realized it highlights a more global problem. There's information you wouldn't want to share, but you want to ask an AI about it, and you're in a position where, on one hand, you could use an offline version, which is probably worse-trained, but you'd like to use the full range of capabilities. Could you attach some ZK here? But then it's unclear what happens with the model. How do you personally resolve this dilemma — when there's closed information you don't want to share, but you want an answer to it based on something well-trained? And can you nicely attach ZK here so it works well for everyone?
Igor Gulamov: All such solutions constrain inference, make it several times, tens of times, more expensive. For that reason they don't fit. A hacker will use the best neural network for an attack, and to defend against that you also need to use the best one. And so the data doesn't leak, I already said: what's available to the network providers is like a smart contract that was printed on a sheet of paper and run through a shredder. And as for the vulnerability hypotheses — there are ten thousand of them, of which ten are real. And SavantChat finds them using a ton of extra context and pipeline data. Whereas a country that wanted to spy on this doesn't have the full data — not nearly all of it — and it's extremely hard to extract anything useful. Besides, we work with neural networks that, by agreement, don't use this data at all. So in that regard everything is safe. It's unlikely Google would write a solution that, out of the garbage of tens of thousands of requests, can find the 10 real vulnerabilities, and then also hype something off it. And even if Google did make such a thing, it would cost more than everything it could hype.
Host: All right, I've heard it. Let's move to more down-to-earth things. You've already named some numbers, but maybe you'll share more. The models, you said, aren't super expensive, but they're still expensive to use. For an ordinary user who does DeFi, running a contract where they're putting money would probably come out a bit pricey — whether they use the models themselves or SavantChat. I'd like to hear about SavantChat: roughly how much does using these LLMs cost you? And how much would it cost an ordinary user — a retail user or a company? From that number we can understand your target audience, whom the product is built for.
Igor Gulamov: We collect lots of discounts to make inference as cheap as possible, and we end up with a margin of around 50%. And if users were to make their own solution, it could well turn out more expensive than SavantChat — even counting just inference, not pipeline optimization — because the user wouldn't be able to assemble pipelines with that many discounts and use complex pipelines with reasoning transfer, with some batch inference. Developing something like SavantChat is hard and slow — it can't be done in a week of evenings, even with prompt engineering and Cursor. It's a more complex solution. Users can use Cursor and other things, but to achieve what SavantChat does, you'd have to feed that Cursor something like 10 thousand different prompts, and then somehow deal with all that data.
Host: Let's move to pricing. How much? I know that until New Year's you have a promo — you give 100 free dollars to try running SavantChat on some code. Is that right?
Igor Gulamov: Yes, we give new users a promo: a welcome balance of 75 dollars, and sometimes we run promotions.
Host: What's enough for these 100 dollars? How big a piece of code can you run?
Igor Gulamov: Using our Pro agent, it'll be 200 lines of code by cloc — without comments and blank lines. That's some simple token or a piece of a protocol with some functionality. It's more of an introductory thing: enough to run something small, a few screens, but not enough for a large protocol. If we talk about the Medium tier, it costs 12 cents per line: Pro is 50 cents per line, Medium is 12 cents, i.e. four times cheaper than Pro; and Lite is 7 cents per line, i.e. seven times cheaper than Pro. Lite has less Deep Research depth, fewer verification iterations — it may miss something, and it can miss even more than Medium. But an average DeFi protocol will already fit on Lite. How much is that? About 2000 lines of code, counting the promo plus the welcome balance. And 2000 lines is already a lot.
Host: I wanted to ask: is this a DeFi user's use case or not? A lot of DeFi people listen to us. Some protocol shows up on a mainnet, deployed recently, no public audits, and I'm thinking whether to put money in. How much is it your case for a person to take the contract, drop it into SavantChat, and decide based on that whether to put money in?
Igor Gulamov: Speaking of the DeFi-user use case — "so as not to put money into protocols with problems" — the technology isn't ready yet. Our false-positive rate, even if sometimes below 50%, is still well above 10%. There are false positives that look serious and dangerous. For a development team that's fine, for auditors that's fine — they'll just discard it, prove why it's not so, and cover the true positives, of which there are also plenty. But for a non-engineer unfamiliar with the protocol, just running the contract to be sure it's fine is not fine. Besides, if we consider fighting scams: say there's a DAO preparing a rug pull. AI won't protect against that, because AI doesn't know who's sitting in the DAO. AI will see that it's a smart contract forked from the best contracts in large protocols with billion-dollar TVL, and it'll say it's safe. But sitting in that DAO will be 20 scammer bots that'll pull off a rug. AI can help if newbies or script kiddies assemble something with holes — there AI helps. But it won't help against a scam, because a scam is broader than that.
Host 2: Let me ask something not far from here. It's obvious to us and to the listeners that your motivation in creating products — whether ZeroPool or SavantChat — is incredibly product-driven: you're just interested, you follow your interest, some public good, without thinking about what the audit market is like now, its capacity, whether it's even needed. Correct me if I'm wrong, but I get the sense that you're driven by the idea and the product, not by calculations. And I'm curious: in what case would you be really pleased, get a real kick? That SavantChat became an industry standard? Or that it found a critical in some mainstream protocol? What would the ideal SavantChat be for you?
Igor Gulamov: I'm an engineer, for me the main thing is the technology. But we have a second co-founder who handles business — Alexandra. When we work on ZeroPool, she's not very public about it — that's related to the specifics of anonymous-transaction technology. But thanks to her work the technology is available, and we have no restrictions. As for SavantChat, Alexandra develops its business concept, to attract users and so that we have commercial and product success, not just technological success.
Host: And what, for you as an engineer, is a success story with SavantChat?
Igor Gulamov: To make the best AI auditor in the world. The idea of SavantChat is checking code for problems. Ideally it shouldn't be work: for any code you should produce a detailed report of what's wrong with it — without complicated conditions and as complete as possible. And not just for smart contracts, but for ordinary code too. We're moving in that direction: we're adding Vyper support, as we discussed with Yearn as an example, and adding Solana and Near support — so not just Solidity.
Host: Interesting.
Host 2: Have you had ideas to take a step toward the mass market? There's a product like VirusTotal that gives you a result by the hash of an executable file. It'd be great in the future to see, say, on Etherscan or another explorer, when you open a contract's code, a badge that you audited it — so it's more publicly visible.
Igor Gulamov: Look. Suppose we made a thing that can tell whether there are exploits or not, and decided to turn it into a VirusTotal. What are the problems here? Suppose we have a user who wants to put money into this AMM, and we tell them: this AMM is riddled with holes, don't invest. But how do we know this user is honest? Maybe it's a hacker scouting for which AMM to hack. So we can't tell them that. It's a dual-use product by its very nature.
Host: Yes, a dilemma, got it. Right. I also wanted to ask — what's going on with your funding? As I understand it, SavantChat isn't on the same model as ZeroPool, but on a more business-oriented one — it's a smaller startup. Is that right? If so, have you had, do you have, or will you have rounds? What do you think about it?
Igor Gulamov: We just closed a small angel/pre-seed. There'll be a seed round, also on a SAFE. After that there'll be a priced round. I hope SavantChat grows to that. We have a small team with a small burn rate, and the product itself makes money. We're more focused on making the highest quality. Thanks to AI, even a small team can work very productively. And since we build products on top of AI, we know fairly well how to properly do development and other business processes, involving AI in them as much as possible. We changed half the team — we did a reorganization in the spring, because part of the team couldn't work effectively with AI, and for us that's the top priority. Now all the team members can work with it effectively. There's a historical example: when electric motors appeared, some factories replaced their steam engines with electric ones. In steam factories each machine tool didn't have its own motor — there was one huge engine and a shaft from which all the tools drew power. Later those factories went bankrupt, because the factories where each tool had its own small electric motor won. So building business processes around new technologies wins. And in the SavantChat team we're implementing new development business processes around AI.
Host 2: When you said that to build an analog of SavantChat a user would need to make roughly 10 thousand requests in Cursor — wasn't that a bit of a spoiler that you did in fact saddle up…
Igor Gulamov: No, no. I meant a user can manually do an audit in Cursor and get something resembling SavantChat, but they'd have to do a colossal amount of work. Whereas SavantChat does it all automatically — and it uses the highest-quality neural network and finds ways to get inference at a discount. Thanks to that we provide more inference. We don't lower the price, because it's already almost 100 times cheaper than a human audit, but we give more inference. Why? Because more inference means more findings.
Host 2: Got it. I thought you'd let slip that you got the agents to campaign for you.
Igor Gulamov: We got the agents to program. To program, specifically. I didn't count how many requests that is in Cursor. Actually, good pipelines require a small number of long, detailed requests, after which the agent works for half an hour. You can run them in parallel by the dozen, and then look at the results one by one.
Host: And just like that, we've ended up in the future everyone was so afraid of — where a person launches the work, steps away for half an hour, and comes back to check up on the AI.
Igor Gulamov: A person launches one agent, then a second, then a third, and then looks at what the first came back with, and so on. It's not about "write a prompt, hit Enter, and go get coffee." It's about a business process built around an AI agent — so there's a full pipeline with result checking and quality control.
Host: I'm also curious: are you profitable yet or not? Let's do one question at a time, I won't pile on several at once. Has the company reached break-even yet?
Igor Gulamov: Over the last few months we hit break-even a few times. But the market is, obviously, fairly stochastic. We haven't reached sustainable break-even yet, but in some months we have it.
Host: Then the second question: where do you want to direct the money from the round? What's the round for?
Igor Gulamov: First and foremost — marketing. We have only one non-technical person, and the business doesn't live very efficiently under such conditions. We need more traction. Right now we're in a position to help DeFi defend against hackers very strongly, because we find all the root-cause vulnerabilities and have little noise. But not everyone knows about us — again, there's a lot of marketing noise. There are big companies, and people can just pick a more famous brand. A lot of work needs doing, including on Google results. There was SEO, there was SMO, and now there'll be — I don't know, we need a new word — optimization in generative neural networks. So that when people ask GPT-5 which is the best AI audit, GPT-5 answers that this one is the best. That needs work: a marketer spending money on creating and publishing content. Investment will go toward that, among other things.
Host: Let's try to wrap this up. In SavantChat's traction the Lido protocol already came up, which said more than 50% of SavantChat's findings were fixed. Any other names, reviews? From big names — DeFi or not, any.
Igor Gulamov: 1inch, Pessimistic, Gearbox, Oxorio. I'm naming those who tweeted, so I can talk about it — that's public information, not under NDA. There are several more large projects I can't talk about yet, because they haven't tweeted.
Host: So they often use an NDA about the very fact of using it?
Igor Gulamov: Of course, it's a standard procedure in information security. If they tweet about us, then I talk about them.
Host: In the context of the round, you didn't mention expanding the engineering team. Are you basically satisfied with its size?
Igor Gulamov: I think you need balance. The productivity of an engineering team can be scaled vertically — by spending on AI compute. Yes, we can do more via AI. In Cursor I burn more than a thousand dollars a month in inference — that's not small. We have three engineers. Maybe more effective AI-augmented engineers will burn not a thousand dollars but two or three — that's inference for development, of course. And still, we want to keep balance. Right now we have a skew toward engineers. We need more people whose work is aimed at increasing sales — engineers' work toward sales is very rigid. When I see that we've reached some balance on that side, I'll be able to hire another engineer. For now our open slots are for non-engineers.
Host: My last question about SavantChat: where did the name come from?
Igor Gulamov: "Savant syndrome" is when general intelligence is low, but there are individual islands of genius. Why did I name it that? Because that's the impression I had from working with neural networks on information security in February 2025: they were very dumb, but sometimes brought something useful, and sometimes surprised me.
Host: Funny. So it's a nod to "I'm still dumb, but sometimes I produce something great."
Igor Gulamov: Yes. Though I'm afraid in a year it'll be outdated and we'll have to rename. Well, let's move toward wrapping up.
Host: I'd like a general overview of the AI world. Maybe you'll say which models solve which tasks better?
Igor Gulamov: Yes, of course. If it's about science and math — that's Gemini. If it's about more humanities-oriented creativity, or programming that doesn't require really heavy math and cryptography — that's Claude. If it's programming with lots of constraints, where you can wrap everything in ready-made tests — that's GPT-5 Codex. If you need to research data online with low creativity but good quality — that's GPT. If you need wide research, when there's a lot of data and a lot of requests but you need to check something very simple against them — that's Manus. That's probably the main lineup.
Host: And who holds context best, in your view?
Igor Gulamov: Right now everyone holds context, but Gemini and Claude are good with large contexts, and GPT-5 is overall good too — maybe a bit worse, but just a bit. In general, with a large context everyone's quality drops not super significantly, but noticeably. That's why in SavantChat we don't push a full 200 thousand tokens of context — we push less. Possibly this is also related to the fact that our architecture is a data-processing pipeline. For agents it usually looks like a chat with a history, but our structure is atypical: instead of a history — data. And at each stage, via prompt engineering, we try to give the model an original narrative, without reference to what it was reasoning about earlier. We give it the result and a prompt so the model understands what we need from it — and it works that way. Usually up to 100 thousand tokens of context is enough. And where problems begin, they begin for everyone, and for our purposes it's better not to reach that volume. Context matters if you need to do simple things, when the model immediately finds something and draws simple conclusions. If the model is given a piece of code it has to think about for 64 thousand tokens — that's already enough, that's already not simple. And if you dump a lot of distracting stuff on it, the quality will drop. Oh, I remembered a couple more points people bring up. For example, that we're a "wrapper over ChatGPT" and therefore there's little to us. But we're less of a wrapper over ChatGPT than Cursor is. Is Cursor an independent product, or are we?
Host: Funny. Can you tell people anything else — what frequent questions or misconceptions about the product would you like to address publicly?
Igor Gulamov: For example, that we need to train our own models: collect audit reports and fine-tune a foundation model on them so it learns to audit. Actually, general-purpose models have already read all the public audit reports. And if you train your own model, it'll be not smart. Even if you fine-tune some open-source state-of-the-art, it'll still be worse than commercial state-of-the-art. And auditing is exactly the activity where intelligence matters most, and you can sacrifice a lot for the maximum possible intelligence. So in-context learning is useful, a database is useful, tools are useful. We're currently working on combining LLMs with formal verification.
Host 2: Why?
Igor Gulamov: Because state-of-the-art models have gotten to the point of working properly with formal-verification languages. We take a smart contract, take the Certora Prover, and ask the model to come up with ways to attack this smart contract for vulnerabilities, and with the Certora Prover we check that these ways aren't violated. That's the research we're doing now. It's not in production yet — there are separate pieces you could assemble into a product. How does it work? The model sees the smart contract, but it doesn't need to dig deep: it can describe at a high level what shouldn't happen — but that high level is expressed in some prover's formal-verification language. After that a formal prover is launched and finds an anomaly. And if it doesn't find one — that means everything is fine. It seems to me that combining formal verification and neural networks is the future. It's what will come as soon as next year.
Host: Even next year? Wow.
Igor Gulamov: Yes, because we now see a lot of releases that take all the gold at the International Mathematical Olympiad entirely by combining LLMs with formal verification.
Host: Cool. Another question: right now, when you go to the SavantChat site, registration asks for an email, and you can't log in with a wallet. Why is that — given that we work in Web3? Will it ever be changed to the approach more familiar to many?
Igor Gulamov: What's more, we have KYC. We could do wallet-based verification, but we'll keep KYC. Why? Because hackers could use SavantChat, and we don't want them to. So we'll make conditions uncomfortable for them.
Host: I think with KYC — I don't know who your AML provider is — it's fairly easy these days: the market for documents for various AML platforms is well developed.
Igor Gulamov: Obviously KYC isn't a silver bullet, and we by no means think it is. But we make many different ways to make SavantChat uninteresting for a hacker. It's just one of the barriers, one that needs strengthening. Why? Because we don't want hackers auditing anything.
Host: Got it, I honestly didn't even think about that. I thought it was the typical approach because your business is more B2B, and B2B prefers not to log in with a wallet but to have a contact. I didn't think at all that it's a barrier against black hats. Well, it's been interesting. Let's slowly start wrapping up. I want to ask from the general questions. You say AGI isn't that far off. How do you see the world of crypto, say, three years from now — what will happen thanks to AI developing so strongly, and how much will crypto change?
Igor Gulamov: First let me recall the context of the previous question: we're crypto-anarchists, we're against bureaucracy, but because of the existence of black hats we're forced to take some unpopular steps. As for how crypto will change in the next three years… Many talk about the post-truth era. Post-truth is when the artifacts that used to be proof of something in court, in jurisprudence — signed papers, audio recordings, video recordings — will cease to be so. Because you'll be able to hand a robot a pen and it'll sign anything; you'll be able to render any sound, any video — and such that even experts and expert neural networks can't tell it from the original. And the only thing that will remain a source of truth is the blockchain. There was a recent scandal with the Chinese robots marching: some people, including reputable ones, doubted it was all real and not a render. And how did the company respond? It filmed those robots from a drone, flying farther away. But those who doubted didn't doubt any less — because if you can film this robot march from several points, you can film it from a drone too.
Host: Right.
Igor Gulamov: How can this be solved? If the supply chain happens on the blockchain, then with ZK — possibly even ZKML, this is exactly a case where ZKML can help — the company simply proves that it buys materials for building robots, that it sells robots, and that it has a lot of them. Meanwhile the company doesn't disclose its detailed business information: it's all encrypted and under a SNARK. But the SNARK proves that this is a company capable of producing 10 robots a day. And the company can attach this proof to the video of the robots — and it's fine, even if the video is rendered, as it most likely will be. Because why spend on a camera operator if you don't have to?
Host: If it's cheaper to render it. So, in your view — let me try to sum up quickly — the significance of the blockchain will only grow thanks to the strengthening of AI, because it'll become nearly the only source of truth in the future, owing to AI's enhanced capabilities. Right?
Igor Gulamov: Yes.
Host: And for the last question, which I find super interesting: please share some literature you recommend or have read yourself. Even better, fiction — it's more interesting how ideas are born, how imagination takes flight. Maybe favorite authors or a specific book.
Igor Gulamov: "Harry Potter and the Methods of Rationality."
Host: That's a fairly popular answer among many, I think. Nice. I think we've covered everything quite fully. Thank you so much, Igor, for being on the podcast. If my co-host has anything to ask, and Igor anything to add — welcome.
Igor Gulamov: Yes, it was a great conversation.
Host 2: I think we've covered it all in full.
Igor Gulamov: Thanks, it was very interesting to answer these questions.
Host: Thank you so much, Igor, for agreeing to give your time. It was very informative. Bye everyone.
Igor Gulamov: Thanks.
Host 2: It was interesting.
Igor Gulamov: Bye everyone.