We’re back with Episode 4 of The Bot Pod! This week, Mike and Fede tackle one of the most requested features in Hummingbot: backtesting. They explain why backtesting should be used as a parameter research tool rather than a prediction engine, demo the new backtesting capabilities in Hummingbot 2.14, and show how PMM Mister’s position hold feature prevents selling at a loss.
The episode also includes a candid discussion about this week’s DeFi hacks (Drift, KelpDAO) and how to keep your DeFi assets safe. Sometimes the best trade is no trade.
Watch the full episode: YouTube
Get started with Condor: Condor
Episode Highlights
17:00 Backtesting Philosophy
Fede doesn’t hold back on this one:
“You will never be able to have a backtest that works exactly as real life.”
Why? A few reasons. First, there’s queue priority—you never know where your order sits relative to everyone else’s. Second, there’s path dependency: if just one fill happens differently in real trading versus your backtest, everything after that diverges completely. And exchanges don’t tell you who placed orders when, so you’re always guessing.
24:00 PMM Mister Deep Dive
Mike and Fede walk through the PMM Mister strategy parameters, and there are a lot of them. The key insight is how they all work together.
Mike works through the math live to make sure he understands:
“So if I’m placing 1% buy orders and max executors is 20, the most I’ll ever have on the book is 20%?”
Fede confirms: “Good student!”
35:00 Running the Backtest
The actual demo is quick—half a day of backtesting runs in about 34 seconds. But there’s a crucial detail: you need one-second candles for market making strategies. Fede explains that he often gets 30+ fills in a single minute, so one-minute candles would completely miss that activity.
54:00 2% vs 10% Portfolio Allocation
To show why backtesting matters, Fede changes just one parameter: portfolio allocation from 2% to 10%. The difference is dramatic.
With 10% allocation, position builds way faster—the bot hits $300 in inventory almost immediately instead of gradually. But then something interesting happens: trading stops completely. The bot hit its max position while underwater, and because profit protection is on, it won’t sell at a loss. So it just... waits.
“If the market never recovers from this point,” Fede says, “this bot will be stopped forever.”
76:00 Trading Bots vs Trading Agents
A viewer asks about AI latency, which leads to an important clarification. In Condor, trading bots and trading agents are different things.
Bots are deterministic—pure code, no LLM involved. They run on one-second ticks or faster, and backtesting works perfectly for them. Agents, on the other hand, use LLMs to make decisions. They’re slower by design, running every minute or so.
“When you’re doing HFT, you probably don’t want the LLM involved in every single tick. That’ll slow things down.”
Full Transcript
Intro & Market Discussion
Mike: Welcome everyone to another episode of The Bot Pod, a weekly podcast where Fede and I demo the latest features in the Hummingbot open source framework. We are the maintainers of Hummingbot, and our goal is really just to democratize the world of algo trading and market making by providing free technology that’s available to anyone in the world.
I’m coming at you from Sunnyvale, California, and Fede is in Mar del Plata, Argentina. Feel free to leave your questions in the comments and we’ll try to surface the best ones.
Today’s a special episode because we’re excited to present backtesting in the new framework that we have. We just launched this new agentic harness called Condor that allows you to use AI in your crypto trading.
Backtesting is an area that we’ve always wanted to support. Having Hummingbot integrate directly to the exchanges, you can fetch data from exchanges, use it for backtesting, and have a good understanding of what it’s like to run your strategy before you actually deploy live. However, because there’s a lot of complexity with backtesting—you have to have a framework that’s fast, that can do a good job of simulating reality, but you also have to fit it into the type of strategy that you want to simulate—for that reason it’s taken us a long time to actually create a backtesting framework that’s really usable and flexible enough where people can use it for all of those strategies.
But I think we’re pretty close to having that, and I’m excited for Fede to show off what he’s built. But before we get into it, it’s been a rough week in crypto markets. I think there’s been a couple hacks recently with Drift and with KelpDAO. Fede, how are you feeling about what’s going on in crypto markets this week?
Fede: Yeah, hacks usually happen every few months, so it is very sad that it happens, but it is part of the game. Personally, I usually do mostly LP, so it’s more difficult to hack. I also do some lending—that’s probably the most risky part. But I think that is not good because you want to have trust on the protocol. I can give you some yield, but...
Mike: Yeah, the lending thing’s hard because I think a lot of people just aren’t really aware of all the different risks that exist in all these protocols and in the underlying assets. Because I think in this case, it wasn’t really Aave’s issue—it was like this staking token that people could lend into Aave and borrow other assets.
Because this staking token was hacked due to some bridge hack—this is KelpDAO—the people in Aave were stuck with bad debt, basically. So I would say yeah, the good thing is none of our assets or the foundation assets were hit. But I should tell you, I did actually move all of the foundation positions back into the wallet. So now we’re just holding USDC in wallet.
Fede: Doing nothing instead of earning interest on the lending protocol.
Mike: Yeah, doing nothing instead of earning interest. I think that specifically, I usually never like those risk-taking coins because I think those mechanisms... you can get, by the way, you stake ETH, but then you go to rsETH and then you can lend that for ETH again into Aave and do the cycle again. So it’s obvious that those types of mechanisms—at the end, someone has to pay.
In this case, I feel bad for the folks who were just lending USDC or USDT, but they weren’t aware that because of the way these Aave pools work—there’s like 20 assets in the pool, so anyone can lend or borrow any asset—I think rsETH was one of the assets of the pool that could be lent, but it’s probably not really the one that most people are borrowing or lending, which is USDC or USDT. But what happens in these pools is you basically bear the risk of the worst asset that’s in the pool.
Fede: Yeah.
Mike: That’s why actually I pulled our money away from lending protocols because I was looking at the list and I’m like, I don’t even know what some of these tokens are. I don’t want to be exposed to some random USDX stablecoin out there.
In the old days when the yields were higher—when I first got into DeFi, the lending protocol yields were like 10% or 15% per year.
Fede: In Anchor. Anchor was—
Mike: Oh yeah, Anchor had 20% back then.
Fede: At that moment I was lending most of my USD there, and when the market went to $0.96, I withdrew and sold everything.
Mike: Really? Okay, that’s good.
Fede: Yeah, because it was at that price for a little bit of time and I was like, okay, this is a stablecoin and people are getting afraid of this. If one gets afraid and starts selling, there’ll be an escape event. So I just said, okay, I will take the loss and I will go out.
Mike: Yeah, that’s also why I pulled our money out—because other people are pulling money out, you don’t know if that can cascade into something else in the future. So better safe than sorry. Happy to earn 0% yield right now for the time being.
Anyway, let’s get into it. I see some questions from the audience about backtesting. I think a lot of people are interested in backtesting.
What is Backtesting?
Mike: Maybe why don’t I just give a brief overview of what backtesting is, why it’s important, and how we enable that in Hummingbot.
You guys probably know that Hummingbot integrates to many exchanges, and one of the main reasons people use Hummingbot is to standardize trade execution across lots of exchanges. For example, you can run an HFT market making strategy on Binance or OKX or HyperLiquid. But many people probably didn’t know that you can also use Hummingbot to fetch real-time and historical data from the same exchanges using the same exchange connectors.
Starting a few years ago, we incorporated the concept of candles where you can now fetch historical data from the exchange. And now you can also use Hummingbot to take the data and apply a backtesting algorithm—basically a simulation against that historical data—so that you can know how your strategy works.
It takes some configuration in the framework because ideally you want to run the same code that you’ve developed for your strategy using the backtest and using it for testing against production data. So you want to use historical data, but you also want to be able to take that same code without any modification and run it on live data as well.
That’s why there’s been many different options. We have tried to build a user interface for it, but you can also do this using the command line, using the API directly, which gives you the full power of all the different configuration parameters.
So that’s just a preface to give you a brief overview of how backtesting works. Basically, we are using the exchange integration directly to fetch historical data from the exchange, have an engine that will calculate performance of a strategy given that historical timeframe, and then a UI to help you visualize and understand that backtesting performance.
What Fede will show today is basically the full end-to-end process of taking an HFT market making strategy, backtesting it, but then also deploying it live and comparing the live results to the backtesting results.
Fede: Yeah. One thing that I would like to add—you got me thinking with the lending stuff—I think that the first one that demonstrates their mechanism is not safe for someone to deploy, because if they pull, there are tokens that are unsafe. I think there should be one lending protocol that comes up with a more institutional or solid process. And that will probably take time—hopefully Kamino gets better.
Mike: There have been attempts at this over the years. There are other protocols like Morpho that I think is more customized and more institutional. But I would say it’s not so much that Aave isn’t safe—it’s more just like the structure of these lending protocols are such that as a borrower, you have to pick and choose your pools very carefully because you’re exposed to every single asset in the pool.
Funny enough, this should be my area of expertise because when I was working in finance 20 years ago, I was creating credit derivatives like CDOs, and these CDOs work the exact same way. Basically you’re exposed to the entire portfolio of risks, and so the worst risk in the portfolio is the one you’re exposed to. But I’m glad I’m not doing that anymore because there’s a lot of risk there. I’m glad I’m doing HFT now with you because HFT is honestly more fun. When you’re making money, when you’re losing money, you’re not as exposed to these kinds of black swan events that might happen.
Spot-Perpetual Arbitrage Analysis
Fede: Yeah, actually a funny thing about HFT—I was doing some research. Can I share my screen now?
Mike: Yeah, go ahead.
Fede: I was doing some analysis and I think that there might be an interesting strategy that we can create between spot and perps. This, for example, is the token CUT. So what I did was—first of all, I was looking at this token here and it was like, okay, it went up a lot. That’s why it has a lot of volatility. But if you check the one-second candles, for example, in this one second, each candle is one second. So this is the movement of one second—it’s like moving 0.14% per second. It’s quite huge, the movement that it has.
But it also carries a lot of risk because you’re holding this... I don’t know what they do actually. “Delivering deep liquidity and native yield.” But this Katana is not the one for Polygon.
Mike: No, I’ve never heard of this network before.
Fede: I don’t know if Polygon got divided into Katana. I don’t remember. But then it’s also like this perpetual, right? And this also moving 0.16% per second. So I was wondering, okay, is there an arbitrage that can be produced here?
So I spot my pair—and here I can see the perpetual and the spot. We can see that mostly the perpetual price will be lower than the spot one because if not, you can just short perps and buy spot, right?
If it’s the other way around, it’s simpler to make money because you can just short. But the thing here is what type of strategy can we come up with that can do market making in one while hedging exposure? What I did is—the spread is very high. So if the price stays in a certain horizon of time and you can hedge the exposure of the price while you’re doing market making...
I’m thinking more like a strategy where you can say, okay, I will allocate in spot a maximum of, let’s say, one thousand dollars, and in perps I will hedge up to $600. So you can start doing market making and hedging a portion of the assets that you are acquiring. But some of the assets that you’re going to acquire are going to be reversed. So all that yield should compensate the difference between the spot and the perps, plus the funding rate.
This was like very last night. I couldn’t almost sleep thinking how I can improve this graph to incorporate the funding rate plus this thing. But it is nice to see—for example, you can be quoting selling here and buying here or the opposite to reduce the spread.
Mike: So in this chart, is it the top line that’s the spot?
Fede: The spot is this one—the top one, the one that is higher.
Mike: Okay.
Fede: Actually I should also add a legend here. The thing is sometimes they are together. But having a legend would be good. Usually spot has less volume than perps.
Mike: Yep.
Fede: But the thing is that they’re moving very together. So this is like probably a real HFT thing that we can do.
Mike: Yeah, there’s probably some strategy you can do. If the spot is higher by a certain amount and funding rate is positive—because you want to probably go long spot and short perp. Usually, yeah.
Fede: But that’s a scenario where spot is higher. In this case, like short pays long. So you’re rewarded by going long. The thing is that you can’t really short in spots—that’s the problem. You need to have certain assets.
Mike: Yeah. You probably have to have it be something like PMM where you want to acquire some position, and that position allows you to short.
Fede: Yeah. When you go down. But yeah, there probably is something here.
Condor Update Command
Fede: But that’s one thing. The other thing that I want to show about Condor—first of all, if you’re not updating for a long time, just update via git pull. But if not, I added a new command that is update. And if you run the update right now, it’ll say you are up to date with the main branch. But if there is a new change on the main branch of Condor, you can just use this command update and you will update your whole Condor system.
So that’s really cool because right now you don’t need to worry about terminating the terminal, all that stuff. You can just run /update in Condor.
Mike: Yeah, that’s good. We’re making changes to Condor pretty much every few days, so it’ll be useful for you guys who are using Condor just to run the update command to help you update to the latest version.
Backtesting Philosophy
Fede: Now I want to talk a little bit about backtesting.
Mike: Okay, go ahead.
Fede: So for backtesting, I’m very skeptical about people that say, “Oh no, this backtest is the best backtester that you can have and it will be perfect.” That’s all bullshit for me because you will never be able to have a backtesting that in real life works exactly as the backtest. You will never be able to match the same behavior unless you’re more like a taker strategy. You will never be able to simulate that.
Why? Because first of all, the order book is FIFO—First In, First Out. So if I put an order and you put an order behind me, my order has priority. There is a kind of priority here. It’s impossible to know. Let’s say that you put $100 in five orders, then I put two orders, and then another guy puts three orders, and then the book was removed $50. You never know if the $50 that were removed are behind me or before me. It’s impossible to really know where you are in the queue because the exchange will never tell you the order or who is the participant doing this change.
So that’s the first thing that is impossible to replicate the real world—the queue position.
And secondly, let me show you one market that we trade—this one, USDT/BRL, for example. See that in the first level, we have $600K and $28K of orders here. Doing a backtesting here—it’s like no sense because how can I, and see what is the volume that is actually being traded? If you run a backtest here, this will never be true because there will be a lot of people before you and your order gets filled.
So that’s the first point that I want to transmit about backtesting. It’s impossible to simulate a backtesting that is like the real thing. That’s why I’m very pro of using the backtesting as a proxy. How? The backtesting should help you understand the sensitivity that each of your configuration parameters has.
Let me give an example. I have this parameter that tells me how much portfolio allocation I will put around the mid price from the portfolio that the bot has. Okay, I want to understand what happens if I move it to 10%, to 5%, to 2%, and that will explain me how my bot will behave if I move this parameter.
So for me, with backtesting, you’re not trying to say, “Okay, this is perfect.” You’re just trying to say, “Okay, what would happen if I use this parameter? What would happen if I use this other parameter?” And the flow is more like: use the backtesting as a research tool, then deploy a bot with that, and understand what is the difference between what you backtested and what is the actual result.
Mike: Okay, got it. So let me just paraphrase what I think I heard you say: don’t treat backtesting as a prediction for exactly what will happen when you deploy it live. Instead, because these strategies typically have 10 or 20 different things you can change—different parameters—you should use backtesting to gauge the sensitivity of one parameter versus another. It’s assessing it on a relative basis instead of on an absolute basis.
Fede: Exactly. It is more like on a relative basis and also to discover how your strategy works, how it behaves, all that stuff. And also making sure that your strategy is doing what you’re expecting. That’s the other thing.
And another thing—for example, backtesting market making strategies is, for me, impossible to have a real simulation. Let’s say that your strategy puts orders around mid price, right? And when one order gets filled, usually you have a few options. You can have a time that will block the replacement, you have a distance that will block the replacement. You can have different mechanisms to block a replacement.
But actually, the market maker will always place orders around the mid price with a different shift or with a different spread based on volatility. But the shift will be based on the inventory that you have, or the shift will be based on the prediction you have for the market, and the spread can be modified by the volatility.
So basically you’re going to place two orders, and based on the fill, you will say, okay, this order will be able to be replaced when this condition is met. Perfect. If the real bot and the backtesting at some point have one fill that is different—one order fill that is different between the backtesting and the real—the following path is completely random because one will wait and the other one will continue replacing.
So at that point, the coincidence is broken. The backtesting to simulate reality is as fragile as one order mismatch. Because after there is another fill, the path is completely different.
Mike: Path dependency is what you’re trying to say.
Fede: Path dependency here. So that’s why what I mentioned—thinking about having the same result of a backtesting in a real bot is absurd. My recommendation is treat it 100% as parameter research.
Mike: Yeah, I think Raj also agrees. He said in a comment, “Yeah, he likes backtesting to see how the model will behave, how it skews mid price, how wide is the spreads.” But yeah, he doesn’t trust backtest P&L. Raj, I think that’s actually also the approach we recommend as well. So it’s good to see that you’re already taking that approach.
Backtesting Engine Demo
Fede: So well, now let me show you what the backtest looks like. For that, I will start in Hummingbot. The good thing is that yesterday I backtested 11 days. But the good thing is that the way the backtesting works is that we use the same controller code that you run in production. So the backtesting actually loops and executes the method that the controller has to take the decisions.
And the abstraction that we have is that the controllers of these strategies create executors. So these executors are like standardized execute actions in exchange. So it’s very easy for us to simulate that specific executor’s behavior. So that brings us like extensibility in terms of how we can test or backtest different types of strategies. We can backtest directional strategies, we can backtest market making strategies.
And the addition of this last month was the usage of the position hold. Because before we didn’t have position hold. Now we have, and in order to backtest it, we had to update the backtesting engine for that.
Let me revert because I was doing this... let me use the one that is in main. I added a script here that is backtest_pmm_mister. It is just a CLI. And basically...
Mike: Yeah, I should mention, these backend improvements were done in the latest release, 2.14. So that was just released a couple days ago, on Tuesday. And if you look at the scripts folder in 2.14, you’ll see these three demo backtesting scripts in the scripts folder. And so this will help you get a feel for how to backtest using the API.
Fede: This is using Hummingbot.
Mike: Oh, sorry. Yeah, using Hummingbot. And then it’s also improved the backtesting endpoints of the API, so that now we can also use it in Condor. So overall, 2.14 actually adds a lot of key backtesting improvements, which is why we’re discussing it today.
PMM Mister Strategy Parameters
Fede: Yeah. To not enter into too much details about the strategy because it’s complex—this PMM strategy has a lot of parameters. Basically we have this method that we can build a config. That is called at first. And then we have initializing the backtesting engine, run the backtesting with a trade cost—while here it’s hardcoded, it should be using the trade cost. We are not passing the trade cost, but while it’s hardcoded here, you can change it or you can add it here.
And then we have this backtesting result that gets the backtesting figure. Then it writes in an HTML figure—this is a Plotly figure—and then we are going to render it in the browser.
Mike: Yeah, I was just noticing how short that file is. Does that mean the backtesting engine is kind of generic across all strategies and doesn’t really need to know much about how this particular strategy is designed?
Fede: Exactly. It’s completely generic because remember that the only output of a controller is an execute action. So you can just abstract that for all the different strategies that you want to backtest.
Mike: Got it.
Fede: So, here this is a dictionary that we’re using. As you can see, we’re using PMM Mister. The controller type is generic. The connector name is the connector that we pick. The trade pair, the total amount quotes. Then the leverage. This portfolio_allocation is basically how much—let’s say that we have here $1,000. The 2% would be, okay, you can put the 2% of the $1,000 around the mid price at a time.
Mike: Okay.
Fede: So this will put $20 around the mid price.
Then we have what is the target portfolio—50% in base asset. So it will try to acquire a target of 50%. The min_base_percentage is how minimum I will keep the level of the base asset in inventory. So as it’s 30%, and this starts with zero position, it will try to acquire the base asset at minimum 30%.
What that means is that it will not sell—it will not place sell executors until it reaches 30% of position. So at the beginning, it will be like an onloading phase where the executor is going to be buying, buying.
Mike: Are you assuming that you’re starting with zero base? You’re starting with quote?
Fede: Yeah. It is assuming starting with zero. You can also put initial balances here, but I recommend assuming it starts with zero.
Mike: And just to clarify—so the portfolio allocation is 0.02, so does that mean you’ll be setting 2% of your overall total amount quotes in orders?
Fede: Yeah, around the mid price.
Mike: Is that typical? Because 2% seems pretty low as a percentage. Is that typical?
Fede: Yeah. But see this value that is max_active_executors_by_level. This means, let’s say that I have—let’s keep it simple—I have two levels. Only one sell and one buy. This will have 2% around mid price. Let’s say that the buy level gets filled. It will place a take profit, right? But if the price continues going down, it will be waiting until it hits the take profit up to this activization_time—you told me this word does not exist in English, but I will need to change it—but it will wait 1,660 seconds until it considers that part of the inventory.
Why? Because we are giving it the chance to hit the take profit. So if it didn’t hit the take profit, it will wait up to 1,660 seconds. But we want to still place more orders. We don’t want to wait all the time because if not, the bot will be stuck.
So this max_active_executors_by_level tells you that you’ll have at maximum 20 times the first level to replace.
Mike: Okay.
Fede: So it will place the 2% again, 2% again, 2% again, in another buy executor. But what happens here is—in order to place another executor for the same level, it has to pass the cooldown_time that is 30 seconds.
So we need to wait 30 seconds to replace another one. And also it will need to pass the price_distance_tolerance. That is, I will not be able to place another one if there is a minimum distance of 0.02% or 0.002%.
Mike: Okay.
Fede: So with this and this, we are able to restrict the amount of replacements that will happen while I am trading with a reactive level. This gives you a lot of flexibility in terms of how aggressive you want to be.
Mike: Okay, got it. Let me put in some numbers so I make sure I understand how this works. So is it like, let’s say you start with a thousand dollars and you have 0.02 portfolio allocation. So it means that you’re basically putting like 1% above the mid price per side, right?
Fede: Per side, yeah.
Mike: So let’s say basically it’s like a $10 buy order, a $10 sell order.
Fede: At first, no. At first, no. Because if it’s zero inventory, it will not be able to place sell.
Mike: Okay, fair enough.
Fede: It will try to only place buy orders because it is trying to get up to the minimum base percentage.
Mike: And then, the way this works is that because the max executors, max active executors by level is like how many times can I replace my buy order, for example. If it gets filled, I place another buy order. I don’t want to do that forever. So I can do that a maximum of 20 times, assuming the market’s continuing going down. Is that right?
Fede: Perfect what you said.
Mike: Okay, gotcha. That means if I’m placing a 1% buy order, the max I’ll ever have on the book is 20%, on the buy side.
Fede: Yeah. Go student.
Mike: Okay, okay. Nowadays—don’t worry, I’m going to pass all this into AI afterwards and have it write down a real transcript because yeah, it’s... but I know what you mean. I actually understand now why backtesting is so important because you have all these different interlocking kind of parameters that work together.
So it gives you a lot of flexibility into how to design your market making strategy, how much inventory risk you want to take, how quickly you move up to your inventory percentage, how much deviance you have. But all these things can be changeable. So how do you know what the right configuration is?
Fede: Yeah. That’s a really important thing that I think we should be doing. For me, this is a place where you do, okay, let’s try this parameter in 5, 10, or let’s say 5, 15, and 30. Let’s try having a grid search with very big values to understand what is the P&L, what is the volume generated, what is the number of position holds, all that stuff.
Do some analysis and then I will continue doing search. My goal would be to see if we can do an auto research with Claude.
Mike: Right?
Fede: If we can summarize how is the output of the backtesting into something that Claude can understand and he can be searching parameters. That would be cool.
Mike: That should be doable actually. I think all you really need for auto research is some type of definable objective and things you can change. And we have that already. And I think there’s also—I would bet it changes a lot depending on the token that you’re trading.
Fede: That changes a lot.
Mike: Yeah. So there’s many different variables here that you can play with.
Running the Backtest
Fede: Yeah, that’s true. But now what I want to show is what it looks like in backtesting, and I want to show what happens if I do a change on one parameter so we can visualize what is the position hold or how the position hold is actually working, right?
So let’s say that we keep this one like 2% portfolio allocation. The way to run it is backtest pmm_mister <number of days>. Let’s put just like 0.5 days.
It’s important for doing backtesting on PMM Mister, for example, or a PMM controller—it doesn’t make sense at all to do it in one-minute candles. Because personally, when I run market making bots, I have multiple fills in the same minute—like sometimes more than 30 fills.
Mike: Yeah.
Fede: So if not, the backtesting will only be able to take one fill in that minute. So one-second candles is crucial.
The only exchange that we support here that provides candles in one second is Binance Spot. So you probably need to buy a server in a region where Binance is allowed because the data is public, and you can either run the backtesting on the server or you can use the Hummingbot API.
But another thing that you can do is to use Tailscale. That lets you connect up to 100 devices for free in your private network. So what you can do with Tailscale is you can use it—let’s say you have a server in Tokyo—you can use it to forward your request through Tokyo. So that’s when it comes useful.
Mike: Okay. Can you just explain quickly why do you think it doesn’t make sense to do backtesting if you have one-minute candles?
Fede: Yeah, because that will depend a lot on the type of strategy. If you are doing, for example, a directional strategy that is taker—yeah, it would be okay to do it in one-minute candles. It’s just to evaluate the signal if the resolution is in that order. But if it is a market making strategy where you have multiple fills in the same minute, the backtesting will not be able to see in the same candle where it goes up and down.
So it’s impossible to know how many fills you have. The only way that you have to evaluate if there were multiple fills is if you are using the one-second candles, because you have each candle to evaluate that move.
Also, this engine is also—I would say it is also possible to backtest directly with trades, which I think will be the next step if you want to go deeper—to backtest directly with trades. For now, I will just recommend one-second candles because there is—here’s the point of flexibility—lower than one-second resolution for me would be considered overfitting. You would not be able to get a higher result or a better result in a lower resolution than that.
That for me is not enough. Comparing one second with trades would be mostly not enough. And I can tell you this by looking at the market. Let’s say for example that we go here to BTC/USDT, let’s see in one second—this is probably the biggest market on Binance. Let’s see. No, today was USDC/USDT, but the second biggest market that has 1 billion of trading volume is BTC/USDT.
And this is the one-second candles, guys. So this movement in the second was 0.001%. So the last minute the move was 0.07%. So going to a lower value than this is—I don’t think that makes sense. I think that would be more considered like overfitting. And the effect that I mentioned about the order book priority just breaks everything. So for me, as I mentioned, use it as a proxy, not as ground truth.
Understanding the Backtest Results
Fede: So well, let’s run backtesting with this. It says the time that took to process half a day was 34 seconds. I want to do some benchmarks—like what happens if I increase the time to, let’s say, one day, two days. Maybe there is an exponential decrease and maybe it will be better to partition and chunk the backtesting. That’s more to understand the behavior. But overall it is quite good. 34 seconds, 35 seconds for the candles—that is the result that we have.
And here it also created this chart. Let me see if I can zoom in. That’s not good. It also created these charts that is the Plotly chart that it generates.
There are three panes. The first pane shows the candles and the executors that it created. The second pane shows the P&L and the volume traded. The volume is this one from here that has this axis here. And also has different P&Ls. We have the executors realized P&L, the position realized P&L, the position unrealized, and obviously the difference of those two and the total P&L.
So the yellow line is the total P&L. The purple is position P&L. See that the P&L... and here the last pane is the position. See that as soon as we are adding more position, the P&L that is the purple one starts moving a lot.
Here, for example, we could take some actions to, okay, let’s reduce the position because we get some profits. So those are the things that you can probably improve. But see that we accumulated almost $300 in position. We generated... the interesting thing is to say, okay, the difference between the yellow line and the purple line—
Mike: The yellow line is—so the purple line is the unrealized?
Fede: The yellow is total P&L, and the purple is the position unrealized P&L. So the difference between the two of them is the position realized plus the executor’s P&L. Here you can see how much this distance—if the executors are taking profit, it will be increasing.
Mike: Got it. Okay. Got it. Because the executors are basically what you’ve already realized and the position is unrealized if you’re accumulating it.
Fede: Yeah.
Mike: And then I also see a position realized P&L.
Fede: Yeah. That’s when you are selling and moving that sell executor to position hold—so you’re actually reducing the position. See for example, here, see in this case that we have $370 in position, here we have $340, so basically $30 were reduced from the position.
Mike: Got it.
Fede: There is a parameter that I added that is called profit protection. That will only let you create sell executors if your position hold is positive. So for holding a position on the sell side, you can only be in profit. That’s a good one to protect the P&L.
Mike: Okay. And this Plotly chart—when you ran the script, this appeared in a browser, right?
Fede: Yeah.
Understanding Position Hold
Mike: And now let me show you these—it is interesting that this is where we can see the actual backtesting mechanics. See that here, for example, these that are white are executors that we placed and were refreshed by the early stop.
Fede: Basically the orders we placed that were not filled. Is that correct?
Mike: Yeah. Orders that we placed that were not filled.
Fede: So see that it placed the order here. The market never reached out to this point. So it never considered it filled.
The ones that are green are the ones that we placed and at some point the take profit was hit.
The ones that are blue—usually this happens in a downtrend—are the ones that we filled, but the market went down, so I never recovered to hit the take profit. So we started accumulating position. So this moves to the position hold.
See that at this point we are—here we are saying, okay, this will go to the position hold. And here the position hold moves from 69 to 79. We said that we are going to put 2% of the inventory, so that’s normal—that’s $10.
Mike: Yeah, I see.
Fede: And I think we had a minimum base percentage at 0.3, so it’s trying to get up to $300 of position.
Mike: That’s another interesting thing because as you see here, there are never sell orders like these white things. Let’s say that we are analyzing these white that are not refreshed. All these white orders are below the price.
Fede: You see this, right?
Mike: What that means is that we are not placing sell orders. Why? And the answer is that we are still below the 30%.
But let’s see a place where we are above. So here we started being above... let’s cut from here to here.
Fede: See that here—up to this point, we were not placing sell orders. And here we turned to above 300. So here we should be starting to place orders. Let’s see if that happens. Let’s zoom into this part.
See that here we have the first white thing. It should be—it should start here, actually. So let’s see if there is something here. These are greens—green executors or green lines that go from up to down. It’s because those are sells that are taking profit.
So here we have the first—and here. Okay, here we also have—let me see more here. Let’s say it should—we should see it starting here. Okay, perfect. It’s perfect. See this? Here we have 298 position. And here we move to 300. See that when we moved to 300, we have the first sell executor, which is this one.
Mike: So it’s... and here we have the first sell that was not filled. So that is how the position is actually accumulated.
Q&A: Take Profit vs Hanging Orders
Mike: Let’s try to answer a question from the comments while we’re doing this. Raj asks, “Why do you use take profit and stop loss for market making strategies?” So what he does is he matches the buys and sells to try to figure out the spread.
Fede: Yeah, actually the approach that I think he’s taking is similar to the hanging orders approach that was in the original Hummingbot.
Mike: Yeah.
Fede: No, actually it is the same thing as well. It’s not the same thing that you are doing—it’s very similar to what you’re doing. I am not using stop loss. I’m only using take profit.
And you can think—imagine that you’re placing two orders to capture the spread. If one order gets filled and you are going to leave the other order in the market—right, so that’s your approach.
My approach is: I have these two orders, and if this one gets filled, I can place the take profit here or I can place the take profit above. So my approach is more flexible because once my order is filled, I can decide what is the spread that I want to capture.
Like almost—no, at no time do you get—let’s say you put a spread of 0.02%—almost never will the two orders be executed at the same time. And the thing is that once one gets executed, then at certain seconds the other one is executed.
So my approach is: instead of taking the other pair of the order—the take profit of this one or to make the spread—I have a configurable spread that I want to capture that might be lower than that spread or might be higher, depending on the situation that I am.
Plus if you think about it, let’s say that you want to build inventory, but you also want to take profit from the spread. You can also only put buy orders, and when they are filled, then you can create a take profit to be the other layer. But if you put the two of them and you wanted to buy and your sell order was filled, then you’re in a worse scenario than where you started.
So with this scenario, you can enforce, okay, I will enforce the buy order first before the sell order, because I want to build inventory. So with this approach, you can also position from one side to the other. Those are the reasons why I like this approach more—of placing the orders.
Mike: Yeah. The way I would try to explain this is I think we made an improvement to this overall market making strategy when we went from the V1 strategies to the V2 strategies. And one thing that gives you is you can handle take profit and stop loss at the individual order level.
So you can replace an order level, configure exactly how you want to take profit and stop loss on that filled order. But you can also control things at the portfolio level. This is when it’s like you’re only placing 1% of your order in orders, how often do you replace that level? How often do you build inventory overall?
So there’s an individual order level in terms of how you handle fills, and then there’s a portfolio level in terms of how do you handle your overall inventory you’re building and reducing. So if you think about it at these two levels, I think the new approach gives you more flexibility now to handle different things.
And I think actually that’s why backtesting is important—because how you handle orders at an individual level does affect as well how you treat things at the portfolio level. So being able to tune parameters that affect both—for example, some of the parameters in PMM Mister are affecting individual orders and how you handle them. Other ones are affecting how much inventory you want to build, how often you cool down before you replace executor levels, those kinds of things. So again, you can just try lots of different things and see what the effect is from a backtesting approach.
Flexibility of Position Management
Fede: Yeah, and also I would like to add—let’s say let’s follow this example. Let’s say that here we build inventory that we want to have between 30% to 40% of the inventory. So let’s say that here we reach up to 300 and 70—no, it is... let’s say that we want to have between 300 and 200.
So here we are allowed to place buy and sell orders, but then we ended up having $300 of inventory. Now my bot should not acquire more inventory, right?
Mike: Okay.
Fede: So in that case, but I don’t want to stop the execution and I have positive P&L on the bot. So in that case, I can still place sell executors that when they get filled, I place a buy order.
So if the market goes down again, I am just making profits. But if it’s going up, I’m selling and helping the position—so I’m reducing the overall position and taking profit of the position generally. So this approach gives you flexibility of, okay, I want to generate yield from the mark outs, plus I can manage the position by holding at the end.
Comparing Portfolio Allocation Settings
Mike: Can you maybe run the backtest again, but maybe we change like min base percentage at 10%? Maybe just so it’s 10% to 30%—you can see.
Fede: No, I would like to put portfolio allocation into 10%. But before that, let me show you another thing that is important here that I didn’t mention. But see that there is a shadow here that shows how many active executors at a time.
So you see that we put 20 and we are never using 20. We are using a maximum seven executors at a time. So this is another thing that you can see—if this parameter is actually used or not. This was max active executors by level. We put 20 and it was never filled.
Let me show you what happens if I put, for the same strategy, 10% of portfolio allocation. Keep this in mind.
Mike: Okay.
Fede: For the comment—yeah, for the unmatched orders, the take profit is like the other leg. Imagine that instead of placing the two orders and being random which one you fill first, you can place the order that you want of the two of them, or you can place the two of them, but each can have a specific take profit that you can configure at the level that you want.
At the same time, you can also—there is another strategy, another market making one that just has orders. So you can do without take profit, just with order executors. But yeah, see this example.
What we have here—I put the portfolio allocation at 10%. So when there is position hold, see, position on hold is increasing much more faster than before. Before, around here we got up to 30%... let me see if I can put them side to side.
Mike: And the difference is now you’re placing 10% of your total inventory in orders. So it’s 5% on each side per level. Is that...
Fede: Yeah, exactly.
Mike: See that? This one was the first one. We build inventory progressively. And this one is the new one—see that we are building inventory very fast. We are at $300 here already.
Mike: All right. What happens here? Can you tell me, Mike, what happens in this part?
Fede: We are not trading.
Mike: Yeah, you’re not trading because—so I think I know why actually. So I think it’s because before you were buying because you were still within the minimum base percentage and max base percentage. At that point there, you hit the max base percentage, so you’re not—
Fede: Yeah, the 0.7.
Mike: Yeah. But you’re also not selling, I think, because you have that profit protection.
Fede: True.
Mike: So you don’t want to sell what you accumulated for lower than you bought it for.
Fede: Exactly. That’s exactly the reason why it stopped trading here. Because as we exposed a lot of money, the market went down. So if the market never recovers from this point, this bot will be stopped forever.
So here you can understand how the portfolio allocation will affect the trading activity—the continuity of your trading activity. See that here, it stopped trading because the unrealized of the position is negative and we have the cap of the position. So it’s not able to start selling.
See that here—what happens is that once the position becomes profitable—that here. Okay, I need to use this one. Sorry. See that here the position becomes profitable.
See here it’s negative. Here it’s profitable. So here when it’s profitable, see that it starts placing sell executors again.
And the ones that are purple are the executors that ended up in position hold. So you see that here we start having a lot of these purple ones. They are reducing the position now. So they’re using the position that we created.
Mike: It’s selling those at a profit then, because...
Fede: It’s selling the profits. See that here it says position realized P&L $1.80. So it actually made a profit from the position itself. And the position that we still hold has $2 profit, $3 profit.
Mike: Okay. Nice. Nice.
Fede: Here we are selling more and see that now the position realized is $3.40. But unfortunately here we are buying a lot again. You see, all these blues are going to cost very much money.
Mike: Yeah.
Fede: But yeah, here you can see how—and this is normal for a market maker, right? When the market goes down, you accumulate position. When the market goes up, you free up that position.
So well here, there is a lot of party—see, this movement is a complete party.
Executor Abstraction and Generic Backtesting
Mike: Yeah. And I think actually this kind of illustrates some of the reasons why I think users should want to use this more advanced version of the PMM strategy instead of the V1 version. Because the V1 version just places orders. And so it doesn’t really factor in the breakeven price or the cost of how much you incurred to accumulate that inventory.
Whereas here, because you’re tracking the position, you can basically say, okay, you know what the breakeven price was. And so you can have a parameter that says, don’t sell at a loss. And you can prevent—I think one of the biggest risks of the original strategies was you are always buying high and selling low and not taking into account the breakeven price of your positions.
Fede: Yeah, that’s exactly what the profit protection does. And if you think about it, it’s very similar to Grid because if the market goes down, you’re going to accumulate exposure. But it will only sell in profits. That’s similar.
Mike: Yeah.
Mike: Actually, I have one question. I was thinking this earlier. I think other people in the audience may have the same question. You mentioned earlier that this works because we’re using this concept of an executor to standardize what happens when you trade. Does this backtesting work on every strategy or every executor, or are there limitations?
Fede: There are limitations. You can only backtest the strategies that are using position executor, DCA executor, or grid executor. The rest of the executors are not covered. Some for obvious reasons—like the arbitrage executor and the cross-exchange market making executor will never be backtestable with this framework because for that you need order book data. So it’s not possible.
Mike: Okay, yeah. In the future, we probably will add the order executor.
Fede: Yeah.
Mike: But maybe within that executor mix, so let’s say I have a strategy that uses order executors—does that, like, can it be any strategy, like a generic controller can also now do backtesting?
Fede: Yeah.
Mike: Or do I have to use a certain framework? Oh, wow. Okay. Great. Okay, that’s a change from before, right?
Fede: Yeah, that’s a change from before. There is still some knowledge that has to be added to the design of the controller because the update process data—we only run once at the beginning. This is to optimize the metrics calculation.
Now I will show you, like for example, the Bollinger one. Let me see Bollinger—that is to optimize the parameter calculation. And then the method that we’ll run time over time will be the method of determine_execute_actions.
So you have to keep in mind that the logic of the indicators or the data that you are going to use should be in the update_process_data. And the method will be executed only once. And all the logic that computes, okay, my executor is this, my data is this—all that stuff, that should be in the determine_execute_actions. Like calculations probably—I need to add an explanation better of that.
But see that here, I’ve backtested a Bollinger controller. Unfortunately it lost money—that was $6. But it’s just a random Bollinger trade. See there?
Mike: Can you share the Plotly for that as well?
Fede: Sorry, I’m showing it but on the other screen. See that this controller does not have position hold because the Bollinger—the directional trading—these versions didn’t include position hold. But probably we can add a version of directional trading with position hold.
Condor UI for Backtesting
Fede: And this is the other visualization that you can run inside Hummingbot. I’m trying to move this, but right now I feel more confident with Plotly for the charts. But there is already an implementation of this in Condor.
And see that here, this is a new thing—the bot trade interface. Let’s say that now I put USDT/USDT. The trading interface now shows the latest executors that you deployed and the position hold. If you have position hold, that is nice because it takes the real position that you are holding. You can also change the timeframes here, all that stuff.
We also have this bots page that has the controllers where you can see the controller code if you want, and you can also create a new config for this controller. Here’s the PMM Mister—the one that we’ve been talking about is here.
Then we also have the configs that we have loaded. So see that here I have this config. I can copy and clone into a new one if you want to create a variation of it. Like this.
The archives is not yet there. I’ll work on it probably next week to visualize the previous bot executions, but I still need to improve it. Here we have all the executors, but I need to improve the visualization.
And here we have the backtest—also here. As you can see, this is a backtesting of Bollinger V1. Here you can see the config that was backtested. Here you can see the actual candles.
Mike: Is this backtesting the same backtesting that we just did in Hummingbot?
Fede: Yeah. The engine is the same. The chart is not, but I’m trying to improve it to have a very similar experience.
Mike: Yeah, I have a tip actually. So you may want to check out a library called Apex Charts. Because you’re using JavaScript for Condor, right?
Fede: Yeah.
Mike: So yeah, because when I created the reporting dashboard last night for using the old Datadog data, I just asked Claude to find a lightweight chart library that allows you to zoom and pan. And so it recommended Apex Charts.
Fede: Okay, I would check it out.
Mike: For that one.
Fede: I would check it out. But for now, I have this. And for—I think that if there is one like PMM Mister—because sometimes it takes a little bit too long to load. I need to improve loading a lot of stuff.
This is PMM Mister. See, it is much more buggy.
Mike: Yeah, I can check out the front end actually. It is probably something—it probably has to do with some type of Ajax JavaScript thing that you’re doing. Because I think you’re trying to load it dynamically each tab, right? When you click on it.
Fede: No. Yeah, yeah. That’s because the number of data that comes is a lot because you’re receiving a lot of executors, so you cannot load everything in memory. Imagine that you have 100 backtestings run—it will explode directly. So you need to do it dynamically. But as it’s a lot of data, see that it is slow.
But this backtest is for—
Mike: Yep.
Fede: But it’s almost the same data that I show in Plotly. That here we have. But this backtest, as I mentioned, is in one minute. That’s what I think is—it’s not true. They are not. I will not be confident on this. But yeah.
Mike: Yeah, basically.
Multi-Server Deployment
Mike: Let me answer a couple questions from the audience while we’re doing this. So just, I would say, in summary—this is a new interface in Condor, this backtest page. But yeah, I recommend if you’re interested in checking out—try out this backtesting interface, but also as we showed earlier, try the backtest scripts directly that are using Hummingbot because that way you can get a low-level understanding of how the backtesting works.
In addition to just running it in the UI, Tiger Trade asks, “Can I run executors on different locations like Binance Tokyo?” And yeah. Fede, do you want to take this one?
Fede: Yeah. In that case you will need to have a Hummingbot API server in Tokyo, and you will need to have a Hummingbot API server in Singapore, and each API can run executors. So that would be the way that you can do it.
But from a single—but from a bot running from a bot, it will not be possible because a bot just runs on one machine.
Mike: Yeah. Also, I think it’s important—the concept of executors is a software-level abstraction. So it’s basically the way to standardize the trading activity that happens on spot and perpetual exchanges. So you can basically apply an order executor on different types of exchanges and have it deliver the same result back to you.
That’s why we can backtest using candles, because we’re taking advantage of this abstraction. However, these executors are being run by a certain server, right? The server is the Hummingbot API that you’re deploying on AWS Tokyo or in AWS Singapore to run it.
So that’s why I would say the way that I recommend starting off is just load Condor locally. So you have an understanding of having API running locally, have Condor running locally. And then once you’re comfortable with that, then you can deploy the API on a server and still connect. You can still use your Condor locally, for example, to control that server that’s running in Tokyo.
Co-location and Latency
Mike: Another question—let’s see. Yeah, so Tiger as a follow-up asks, “Is it possible to run an abstraction in the bot and send RPC commands to Bybit for execution?”
I think that’s actually what’s happening. Maybe I’m not understanding what your question is, but I think that’s actually what’s happening because the API is talking directly to Bybit or Binance. That’s why people run Hummingbot because it’s an open source framework that integrates directly to the exchange with no intermediary in the middle.
So when you run an executor, you’re basically telling the server to connect to the Binance API via WebSocket and place orders and cancel orders and do everything directly with the exchange.
So you’re anchored to that machine because Binance is going to track rate limits from a certain IP address. So you know that one server is going to be communicating with Binance and you may have two different bots on two different servers that are both talking to Binance consuming rate limits separately.
So there is some kind of—there is always, you’re always anchored to one machine from a Binance perspective, because you’re sending direct instructions to that server. But there’s nothing that prevents you from using one version of Condor and controlling five different servers, each of which are running different bots.
Fede: Yeah.
Mike: But yeah, but I would say if you need co-location, you need to run the servers in Singapore, Tokyo—
Fede: That’s the definition. Yeah. You’ll need to deploy a Hummingbot API on each of these servers and then run the bots that you want, basically.
Mike: Yeah. But actually that is exactly what market makers are doing. What we know of market makers that are running Hummingbot co-located on servers close to the exchange or even in some cases on the exchange infrastructure itself. And that’s why we designed Hummingbot API—it’s basically a piece of software that you deploy on a server. And so you should always run it as close to the exchange as possible.
AI Model Latency Discussion
Mike: Okay, all right. So yeah. And one follow-up—the decision-making latency. I think what he is referring to is some type of speed measurement—how fast Hummingbot is actually communicating with the exchange. I think that’s what they’re referring to.
So yeah, I would say—
Fede: That, I think for that is everything is possible. You need to just use the framework that we have to implement it. We have a layer of MQTT that will be able to communicate the different bots. So off the shelf you will not have that feature, so you need to build it.
But what you can have is one Hummingbot instance in Singapore, one Hummingbot instance in Tokyo, and all of them can be communicating the messages through MQTT. So each one can be measuring the latency. You can have a central report and then have another one that distributes the orders. But you need to build it. You need to build that connection. It’s part of your development.
Mike: That’s right. And actually, I’ll try to find an article because remember Victoria, one of our community members, did use Hummingbot to analyze speed between AWS Tokyo and Singapore. She did a lot of measurements in terms of how fast Hummingbot is. And so yeah, I’ll try to post that in a comment.
As Fede is showing the rest of the backtesting in terms of what that looks like—but overall, I would say, I think she found Hummingbot API is pretty fast. But there are some interesting differences between, let’s say, Osaka and Tokyo or Singapore in terms of where you deploy the server.
Fede: Yeah. Yeah.
Mike: The last thing that I want to show is this routine page new that we have that basically—we will be able here to run the routines from this page. As you can see, I just ran this one. I will write again, but basically I’m trading for a guy—a Brazilian guy that trades on these markets.
So I just said, okay, I want to know if there is—because right now we have zero fees on BTC, so I just wanted to know, okay, what is the market of BTC regarding comparing USDT and BRL. So it’s 1% of the market.
And the other thing that I wanted to know is if I quote the BRL in USD, what is the actual price discrepancy? If there are crosses—is there natural arbitrage opportunities to rebalance my BTC and BRL. And also counting that I have negative fees.
So well, this is the power of the routines—simple entities that you can receive data. That’s cool.
Mike: Yeah.
Fede: And also we have the top movers. These are private, so you are not going to see this, but as you can see, I can get the text, I can get the table. And with that, I think that is all for today.
Mike: Okay.
Distinguishing Trading Bots vs Trading Agents
Mike: Yeah, I do want to cover one more question from Tiger. I think this is actually an important point to bring out. Yeah, they ask regarding decision-making latency—he is really referring to the AI model latency, how long it takes to get information to the agent or to the LLM, get it back, and how routines and tools speed this up.
So I think this is something that I think we should cover maybe next week or the following week. Because one thing to clarify is there’s two different things you can do with Condor. You can do trading—you can run trading bots, and you can run trading agents.
Currently the way we’ve designed it, only the agents are injecting the LLM in the middle and using it to make decisions or anything else. When you’re doing trading and you’re doing trading bots, you’re actually just doing things the traditional way—you’re creating more like HFT deterministic algorithms and everything. So backtesting, everything else—that stuff is not using the LLM in the middle.
And it’s designed on purpose actually, because our view is that when you’re doing HFT, you probably don’t want the LLM involved in every single tick. That’ll slow things down. Instead, you probably want the agent at a higher level, like deciding which bots to start or stop and all that kind of stuff.
So that’s why for now, the backtesting—we encourage you to just do things the old-fashioned way. Create it, backtest it, run it in Condor. And that is not using the LLM.
However, once you build a routine and then you go to the agents tab and you build an agent, that’s when you’ll be using the LLM to help you make decisions. And you’ll notice that’s actually why it’s slower—every tick might take 60 seconds, because you want to give the LLM time to process and make a decision.
But when you’re doing HFT, your tick is probably one second or lower because you’re constantly sending orders to the exchange.
Fede: Yeah. Perfect. I think that was a really good session today.
Mike: Yeah, it was.
Fede: The agent can oversee—the agent can oversee the bot and modify, but it will not be in real time. You are going to execute the tick of the agent every X amount of time.
Mike: Right.
Fede: Probably in the future we are going to create some real-time agents. But for now, the current agent that we are offering is more like ones that you can execute every minute or X amount of minutes. So that will probably be the current state.
We’re going to go step by step for the real-time agents. We probably want to code probably with open source models. Maybe we can release a Hummingbot model or Condor model on Hugging Face.
Mike: Yeah. Yeah.
Fede: Fine-tuning models.
Mike: I’m currently watching a series on Hugging Face. The other day they were showing the new thing that will come is the RL for Agents.
Fede: Oh, wow.
Mike: Instead of doing DPO or RLHF—I don’t know the exact name—but it’s like how you do fine-tuning with LoRA, QLoRA, all that stuff. It is fine-tuning the agent. It’s not fine-tuning the model—it’s fine-tuning the agent.
So I think that there’s a lot of power there. I will be probably playing around with that. But I think that for our case, it’s perfect. That is probably what we want to do for our case.
Fede: Yeah, I agree actually. And I think for us, we’re just going to keep on building. Every week we’ll just come out here and demo the new things that we’ve launched every week. So I think that as we continue doing this, in a few months, I do think we’re going to have some pretty intelligent agents that are doing auto research and backtesting and forward testing at the same time. And at that point it’s going to get pretty crazy.
Mike: Yeah.
Wrap-up
Fede: Alright everybody, thanks again for joining. I’ll put on some more closing music. Do you know how many people we have today?
Mike: 18 people watching right now on Discord—or on YouTube. So yeah, I think we’re starting to get a bit more participation every week in the live streams. But yeah, I’m hoping that we can get up to even more once the hackathon kicks off and we’re doing workshops and showing people what—
Fede: Yeah.
Mike: So yeah, anyway, we’ll see you guys next week. Same time, same place. And yeah, we’ll try to get this posted on our Substack in the next few hours.
Fede: Yeah.
Mike: Alright guys.
Fede: Okay.
Mike: See you later. And we will talk to you later.
Fede: I like that music. Okay, bye. Bye.
