The Bot Pod Episode 8: Demo Day Highlights + New Condor Features

We’re back with Episode 8 of The Bot Pod! This week, Mike and Fede highlight the top strategies presented at Botcamp Cohort 13’s demo day, share an updated schedule for the Condor Builders Cup, and demo a big new Condor capability: watching your live bots in real time, with controller snapshots saved every five minutes so you can finally see how P&L evolves over time.

Watch the full episode: YouTube
Register for the Condor Builders Cup: botcamp.xyz
Install Condor: condor.hummingbot.org

The hosts open with Botcamp’s 13th cohort, just wrapped: eight strategies demoed, and—both agree—noticeably higher quality than prior cohorts. The reason is AI. Students used Condor to analyze their strategies and build their controllers, iterating far faster than before.

“We made a great choice in the past—framing our system as building blocks. That’s what now lets AI create agentic algo-trading strategies without too much friction.” — Fede

Last week we talked up Hyperliquid moving into TradFi via pre-IPO trading of CRBS and other, but never actually bought HYPE at $42. It’s now ~$58, having touched $62. The lesson: talking isn’t trading. They also dig into the new stock perp markets, where thin liquidity creates fat-finger arbitrage opportunities (Fede spotted a ~2% deviation on Microsoft), but where depth is still too shallow for institutions to size up.

Answering MJ Lee, the hosts say agent backtesting is coming, but for now you can already backtest V2 controllers in Condor’s Bots tab. On a request for TikTok-style shorts: Carlito (community manager) is already chopping these Friday sessions into clips for YouTube, Twitter, LinkedIn, and Reddit—marketing has just never been Hummingbot’s forte.

“We’re a lot better at building stuff than we are at talking about it.” — Mike

The hackathon is being pushed back about a month so Fede can extend the agent framework first—soon agents won’t just launch executors, they’ll manage and reconfigure sets of controllers. New timeline: the build period runs June 19 – July 10 with workshops along the way, followed by judging with sponsors, and a 48-hour live competition the week of August 3rd run with the team’s own capital. Registration is already open.

Wei Hong rebuilt core Hummingbot components to do cross-exchange market making on perpetual connectors—traditionally a spot-only strategy. His version scans perp markets for opportunities to go long on one venue and short on another, capturing both the price spread and the funding-rate difference. He ran it live: long the stable USDT pair on Binance, short on Hyperliquid.

“Conceptually, you’d be in a position where you’re getting paid to enter, and you earn the funding rate along the way.” — Mike

The winning strategy turned market making into a stochastic optimization problem (drawing on an academic paper Mike attributes to Cartea & Penalva). It precomputes a policy, then runs 300-second cycles of placing and liquidating orders rather than recomputing every tick. Raj ran it live on Hyperliquid: 120K+ in volume on a few thousand dollars of capital, with basically flat P&L.

“This strategy is very close to what professional market-making firms—even the algorithmic ones—are running.” — Mike

Responding to a question about adding Hermes support, Mike explains the thesis: general-purpose harnesses (Hermes, Open Claw) are great, but trading is quantitative, not qualitative. A trader needs the agent to not hallucinate, not make mistakes, and run fast. That’s why Condor offloads core logic to deterministic routines (Python files) and uses the LLM sparingly—both for reliability and token efficiency.

“Condor is structured to minimize the tokens used for decision-making, and offload the core logic to routines, which are deterministic Python files.” — Mike

Fede demos his work-in-progress PMM controller with global take-profit / stop-loss and a limit chaser. The key concept is position hold: when a position executor fills but the market doesn’t reverse, instead of dumping it, the position is moved into an “effective position”—a long-run inventory bag the bot manages as a whole. Take-profit only triggers once inventory passes a minimum threshold, and stop-loss only once it hits the target—so the market maker has room to improve its entry price before ever taking a loss.

Condor gets a new Runs tab (likely to replace the older Archive tab) and, more importantly, real-time bot monitoring. Until now you could only see a snapshot of a bot’s current state. Now every running controller is dumped to the database every five minutes, giving you the full progression of realized/unrealized P&L and volume over time.

“Can we make something that actually lets you see the bot in real time while it’s running? That was the goal.” — Fede

The data flows over MQTT (keeping the bot lightweight) and is collected by the Hummingbot API—the same mechanism already used for portfolio history. Beyond the standard metrics, a new get_custom_info method lets you push any custom field from your controller into the snapshot stream.

Fede deploys a single bot (Docker container) running three controllers across three markets in seconds, then shows off live updates: you can change a controller’s config and push it to the running bot without restarting. Controllers define which parameters are updatable—change the connector name and it’ll safely refuse. (Next up: a Markdown view that highlights the editable fields.)

Once there are enough snapshots, Condor charts the combined P&L of every controller you’re running—and lets you toggle individual lines. Run five algorithms and see them as one portfolio, or drill into any single one.

“I’m running five different algorithms, and this is the combined performance. This will be a game-changer for the agents.” — Fede

“Is this bot doing well because it’s consistently profitable, or is it just getting lucky because the market happened to move in its direction?” — Mike

The team is finishing the Hummingbot, Hummingbot API, and Condor changes needed for agents to manage controllers—the reason the Builders Cup moved to June 19. Registration for the Builders Cup is open now at botcamp.xyz. Join us live next Friday on YouTube!

Mike: Welcome everyone to another episode of the Bot Pod podcast. I’m Mike, this is Fede, and we’re the co-maintainers of the Hummingbot open source framework. How are you doing today, Fede?

Fede: Very nice, everything good. We just finalized the Botcamp cohort—another successful journey, so I’m very happy about that. And I’m really happy with the submissions the students made. There were some very high-quality ones; for one month of training, it’s quite impressive. What about you?

Mike: I totally agree. This was the 13th cohort we’ve done for Botcamp. We had eight strategies demoed on demo day yesterday—I’ll show the winner later in the podcast—but the quality felt quite a bit higher than in prior cohorts. I think it’s because people were able to use Condor to analyze their strategies and help build their controllers. We’re finally seeing the power of using AI in quant trading.

Fede: Yeah, the use of AI is improving the submissions a lot, mostly because they can iterate very fast on the analysis. The other thing is that I think we made a great choice in the past—framing our system as building blocks. That’s what now allows AI to create agentic algo-trading strategies without too much friction, because all those building blocks help the AI design strategies better.

Mike: I’ll show off the winning strategy from demo day. But before we get into it, I have to admit a bit of FOMO right now.

Fede: Me too.

Mike: Because just one week ago on this podcast, we were talking about how Hyperliquid is really getting into TradFi—showing you can trade pre-IPO stocks like Cerebras. But you know what we didn’t do? We didn’t actually buy HYPE when it was at $42 last Friday. What’s the price today?

Fede: I think it should be around 57 or 58, something like that.

Mike: Let me check CoinMarketCap. Yeah, it’s at 58 right now, but it actually hit 60 yesterday.

Fede: It hit 62.

Mike: So basically, we talked about it, but we didn’t actually put anything into action.

Mike: What’s interesting, though, is that the volumes in these pre-IPO stocks aren’t actually that high. SpaceX was about the only one with real volume.

Fede: Right, generally the volumes aren’t quite high there. One thing I was researching across the different markets: there are opportunities to place orders to catch fat fingers, because there are deviations—for example, in Microsoft of around 2%. Someone executes a big trade, and since there isn’t much liquidity, there’s an opportunity to do the arbitrage—but you need to have the limit order already in place.

Mike: Are you talking about the Microsoft perps market?

Fede: Yeah, the perp markets. I think that one is deployed by a different provider, not by Trade XYZ. But across these markets, if you check the liquidity, it’s not that huge. The institutionals will probably start providing liquidity, but institutional traders need this kind of deep liquidity to trade—otherwise it’s not an interesting market. If you can’t get out, it’s not that good.

Let’s say for NVIDIA/USDC—I’m looking at NVIDIA/USDC on Trade XYZ. Up to a value of 1732, up to 7.1%, there’s only about 120K. So it’s not that deep. For someone placing a 500K trade, it would move the price a lot. Actually, a dollar above, there’s more—up to 7.5% there’s about a million dollars. But it’s a perpetual market, so a million dollars in perps isn’t that much either.

Mike: This kind of makes sense, though, because right now NVIDIA trades in the spot markets on the NYSE. So if I’m an equities market maker, it’s actually very easy to make a market on this perps market and just hedge in the spot market on NVIDIA. I actually think we should add an equities connector at some point to Hummingbot—like Alpaca or Interactive Brokers—because our users probably want to do the same thing.

Fede: The thing is, if all these stocks start trading in the spot, I think they’ll naturally appear in these exchanges too. Actually, Binance is listing all of this. That’s another interesting thing—I don’t know if you saw, but Binance released prediction markets.

Mike: Really?

Fede: Yeah, they released prediction markets, and they also released SpaceX. They’re catching up. But one interesting thing I saw about Binance is that they have something like 10,000 employees, and Hyperliquid has only 11. So there’s a big bias there.

Mike: Hyperliquid is our type of organization, right? Maybe they’re even better than we are—small number of people, but they try to do a lot. From a regulatory perspective, both Hyperliquid and Binance are doing an end-around on US regulations. I’ve heard there’s a lot of talk in the US about how the CME is lobbying for more restrictive policy against Hyperliquid and Binance, to protect the sanctity of US markets. So that’ll be a really interesting watch.

Mike: But let’s get into it. We already have some questions from the audience. Let’s answer one from MJ Lee: “Are there any plans for Condor agent backtest support, other than deterministic script-based backtests?”

Fede: Yeah, to backtest the agent—I think we can add that. It won’t be so difficult. And nice, because if you’re asking that, it means you’re probably using the agent framework. Based on the output of the cohort, we found it might be smarter to have an agent be in charge of deploying controllers and modifying their config, rather than trading directly. But if you’re doing grid trading, the agent is enough. So yeah, we can add something like that.

Mike: My thought is to initially try backtesting using the backtest tab in the Bots section in Condor. Backtesting was always one of the most requested features in Hummingbot. We originally added it to the dashboard—the GUI for Hummingbot—a couple of years ago, but when we built Condor, we combined those capabilities into Condor. So you should already be able to backtest V2 controllers using Condor. And one of the changes Fede will talk about later is how we’re planning to let agents manage controllers more effectively in the future.

Fede: Yeah, I think that’s the way to go—agents directly. There’s one more question: a user asks, “Guys, why not create short videos, TikTok style?” You want to be a TikToker, right?

Mike: The first thing I’ll say is that marketing has never been our forte at Hummingbot. We’re a lot better at building stuff than we are at talking about it. But we have been creating more shorts and clips. Fede and I record here every Friday, and our community manager, Carlito, takes the videos, chops them into shorts, and publishes them on YouTube, Twitter, LinkedIn, and Reddit. We don’t do TikTok yet, mostly because of bandwidth. If you follow our Twitter handle, @_hummingbot, you’ll see some of those clips. And Deja—thank you for offering to help with marketing. If you have ideas, join the Discord and post them. As I said, we’re builders, not marketers, so we appreciate any help the community can offer.

Mike: So let’s get into it. There are two things we want to do today. First, I want to talk about the upcoming hackathon—we’re revising the schedule—and show off a strategy someone created during the cohort, because it’s a good example of what people can build during the hackathon. Then Fede will demo some new Condor features that make it easier to manage your bots.

We’re revising the hackathon schedule a bit. It was supposed to start today, but based on feedback from the Botcamp students and the strategies they built, we’ve decided to modify the agent framework. Currently, agents in Condor can launch executors, so they can trade. But we’ve found a better role for the agent might be monitoring an existing HFT strategy—and Hummingbot already has a good framework for that, called bots and controllers. So Fede is going to change the agent framework so that, in addition to launching executors directly, the agent can manage a set of controllers and modify them.

We’ll be making those changes over the next couple of weeks so people can use them when the hackathon starts. That’s why we’re delaying the hackathon by about a month. The hackathon period will run from June 19th to July 10th, with a series of workshops to teach you how to build your agent strategy. After that, we’ll have a judging period where we work with our sponsors to select the winning agents, and we’ll prepare those agents to “drive,” so to speak, in a 48-hour live competition the week of August 3rd.

So it’s delayed a bit, but we hope this lets you create more sophisticated agents that manage true bot strategies. Registration is already open, and we’ll have more resources for registered folks before the 19th.

Mike: Let me show you some of the strategies people built during demo day. We had eight different strategies, and honestly, they’re all quite impressive. Some were directional, some market making; some traded on DEXes, others on order-book exchanges. I was really gratified to see how much work the students put in, especially given that the Condor harness is fairly new and they had to overcome bugs and other issues along the way.

Let me start with Wei Hong’s, which was the second-place winner. I thought it was quite impressive because he actually rebuilt a lot of the core components in Hummingbot to do it. What he built was a strategy that does cross-exchange market making, but on perpetual connectors. Traditionally, our cross-exchange market making only handles two spot exchanges, but with perpetuals you can now do the same thing on perps.

He built a strategy that analyzes different perpetual markets and finds opportunities to do cross-exchange market making—taking into account both the funding-rate differences between the two perp exchanges and the prices. When it identifies an opportunity, the strategy enters one long position and one short position, and hopefully captures the spread between the price differences as well as the funding-rate difference. Conceptually, you’d be in a position where you’re actually getting paid to enter, and you earn the funding rate along the way.

Fede: Just as a reference, I created a video about two or three years ago doing funding-rate arbitrage between Hyperliquid and Binance perpetuals. I showed that if you enter both positions at market, you need almost two or three days of funding fees to recover the trading cost. The recommendation was to enter the position progressively, which is what Wei Hong is doing here—taking profits while entering a position he’ll be paid to hold.

Mike: I was also impressed by how he got the strategy working in production. You can see the bot he was running: a long position in the stable USDT pair on Binance, and a short position on Hyperliquid. He was capturing some unrealized and realized P&L, and also taking advantage of the funding-rate differences. Overall, a very impressive example where the student added his own custom executor and custom controller, and the strategy makes sense conceptually. We may even want to have this as a type of executor in Hummingbot later on.

Fede: Yeah, we should.

Mike: This was the number-two strategy. The winning strategy was by Raj, called “Market Making at the Touch.” Let me explain it, since I could hear the audio on this one. Raj took concepts from an academic paper—I believe by Cartea and Penalva—that talks about how to turn market making into a stochastic optimization problem.

The idea is that when you acquire assets, you want to sell them to get back to neutral; if you sell, you want to buy them back; and in the middle, when you’re at a neutral position, you’re placing both orders. What he’s doing is creating 300-second grids and repeating that cycle every 300 seconds—placing orders and then trying to liquidate. Once we post the strategy video and he explains it, it’ll be easier to understand.

There’s quite a bit of academic theory here in terms of how it’s done, and he generated some really impressive visualizations to analyze what’s happening at various points. Essentially, he’s creating a policy that defines how the strategy should act. Because the policy is predefined, it’s easier to just run it instead of doing computations every tick. So this is very much an advanced market-making strategy based on more academic factors.

What also impressed me is that he ran the strategy live on Hyperliquid and generated over 120,000 in volume with basically flat P&L—and with only a few thousand dollars in capital. In my opinion, this strategy is very close to what professional market-making firms, even the algorithmic ones, are running. It was a combination of the academic approach and real results in the wild, and that’s why he got the most votes. It was a very close competition between him and Wei Hong for the top slot, so I’m hopeful Wei Hong can also submit his strategy for the hackathon and win one of the other slots.

Fede: This is really cool because one of them presented a professional-grade market-making strategy using a paper as inspiration, and the other went full operational. One guy with $1.5K traded 120K on spot in four hours—very impressive. And the other was trading perpetual positions of more than $5K into the exchanges. If you’re trading that amount, it’s because you’re confident in your strategy.

Mike: I totally agree. And that’s why we’re doing this hackathon—during the cohort we had about eight submitted strategies, but with the hackathon a lot more people will get the chance to show what they can do with Condor, and we’ll see which strategies actually work in the wild.

To reiterate: the hackathon starts officially on June 19th, and you’ll have a three-to-four-week period to build your agent. Along the way we’ll have workshops, then we’ll judge the strategies with our sponsors, select the winners, and run the five or six winning strategies with our own capital in a sandbox environment for 48 hours to see which generates the most P&L and volume. So, a final call-out: join the hackathon. You can find it at botcamp.xyz, and we’ll have more information over the next couple of weeks.

Mike: Let me answer one more question, from Digita, before we move on to the Condor updates: “You guys should add Hermes agent support. It will greatly boost.” Our community manager, Carlito, has been doing a lot of experimentation with Hermes—using it to schedule the publication of YouTube clips and shorts, and to notify people on Discord about changes.

The reason we’re building Condor, though, is that most current agentic harnesses—whether Open Claw or Hermes—are meant for general-purpose agents. That’s great; I use them quite a lot. But as a quant trader, trading is different from general tasks because it’s quantitative. LLMs are really good at qualitative, subjective, probabilistic tasks. But if you’re doing quant trading, a lot of the time you want the agent to not make mistakes, not hallucinate, and run very quickly.

So with Condor we’re trying to design a harness that uses LLMs, but uses them to accomplish the tasks traders actually need—operating from a first-principles approach. Later on, we could probably make Condor agents more compatible with Hermes or Open Claw, so you can run them in those platforms. But for now, we’re trying to create an interface that’s purely designed for trading. That’s why routines—deterministic scripts—are the initial primitive, and trading agents are the second.

Fede: I agree. I tried Hermes too. It has 89 prebuilt skills and all that. The only really interesting thing is the auto-feedback loop that improves the skills automatically—but that’s something we can easily add to Condor. For our harness, it’s probably not what we’re looking for.

Mike: Everything is new, so it’s a very open landscape—maybe there’s a way to make them more integrated in the future. But right now, when I’m trading, I want something dedicated to trading, not a general tool. Also, from a token-efficiency standpoint, you don’t want to just give API docs to Hermes and have it figure out trading for you, because that would be very expensive. That’s why Condor is structured to minimize the tokens used for decision-making, and to offload the core logic to routines, which are deterministic Python files.

Fede: Yeah, I agree.

Mike: That’s a good segue. In the second half of today’s podcast, Fede’s going to demo the changes he’s been making to Condor to make it better at managing our bots, so you have more visibility into what’s going on. Do you want to take over and show what you’ve built?

Fede: For sure. Let me share my screen. Can you see it?

Mike: Yep.

Fede: I’m currently adding to the PMM Mister controller. The take-profit and stop-loss feature is working quite well right now; I’m just figuring out one issue with the sell side that’s also creating a sell position. Thanks to that bug, I ended up with a position of 4K USD, and when I saw it was about $40 in profit, I just took it. But I’m trying to fix that position-hold bug.

The good thing is that the stop loss works, and it’s actually doing it with a limit chaser. It’s incredible how well the limit chaser works—I was watching it live and it was really nice. You can see how it’s trading.

Let me explain the position bars to everyone. This first bar that’s loading shows the mean position I can have, the target position I’d like to have, and the max position I’d like to have. Based on that, the bot accumulates a portfolio, and depending on its stop-loss value and current position, it decides whether to take the loss or not. There are a lot of conditions that need to be met to actually take the loss.

You see here, “closing position stop loss”—it tries to close the position, and it did. Now we have only 13 cents. There are parameters you can configure: global TP enabled, global SL enabled, the values you pick for them. And the take-profit should only trigger if you’re above the mean-based percentage, because you can be loading inventory. For example, now we have $25 and the global take-profit is $1—but you don’t just take it; you need to fill this inventory bar first.

Mike: Can I ask a question? The global take-profit and stop-loss—how is that different from the take-profit and stop-loss at the position-executor level?

Fede: Each executor has its own take-profit. But when an executor gets filled and the position isn’t reversed—because the market went down—I don’t want to keep that position by itself. I’d like to keep it as part of my big bag of positions. That’s what we call position hold. These executors are the position executors; after a certain amount of time, they’re moved to the “effective position.” Once they’re moved there, we manage our position in the long run.

So in this case, now that we’ve started, we’re still losing money, but it’s okay—I’m running with very aggressive parameters in order to fill the position and trigger these take-profit and stop-loss scenarios, because that’s what I’m testing. Now it’s able to take profit because it’s above the min base percentage. If the market suddenly goes up and the P&L goes above the take-profit, it’ll take profit.

The stop-loss is only activated when the inventory reaches a target base. This is because I still have room to buy more—the market maker has room to buy more—so I don’t want to say “you’re taking the loss right now.” Let the market maker acquire more inventory, and maybe after some time we can improve our entry price and not need to take the loss at all. That’s the point.

Mike: I see.

Fede: I’m trying to fix this on the Hummingbot side to make the PMM Mister work with perp trades, plus this stop-loss feature. And on the Condor side there are quite a lot of improvements I’m finishing. To use this, you’ll need the latest Hummingbot image and the latest Hummingbot API image deployed.

Mike: Sorry—doesn’t the Hummingbot API automatically fetch the Hummingbot image, or does the user have to pull the Docker image?

Fede: I think if you use the update command, it should do it automatically. David, if not, you can review that process later, or just let us know if you have issues. Otherwise, go to where you have Hummingbot API, run git pull, and update your version—but I think it should work directly.

Mike: You mean the update command in Condor—the Telegram condor update command?

Fede: Correct.

Fede: Let me go to Telegram and ask for the web link. This is Condor. As I mentioned before, I added a color-blind mode last week for one of my friends. Now I’ve added this Runs tab, which I’m going to be testing—it lets you delete the bot archive from the Hummingbot API.

Mike: Does the Runs tab replace the Archive tab? Is archive still there after you delete?

Fede: Archive is still there, but I’m pretty sure I’ll remove it, because it’s not working with the efficiency I think we should have. The routines, with their HTMLs, will probably replace it too—but I can’t confirm that yet.

Mike: So the Runs tab shows the bots you’ve run, both archived and non-archived?

Fede: Yeah. Everything you stop gets archived.

Mike: I see “deployed bot” here too. So this page shows all the bots you’ve run, archived and non-archived—that’s why you can probably get rid of the Archive tab, since this page is more complete.

Fede: Right. The one that says “deployed” is because I removed it manually—the record is in the DB, but I removed it from the file system, so it appears as deployed instead of archived. In this tab, I just deployed three random controllers. Let me build the Hummingbot image so we use the latest one.

Fede: The change I introduced to the Hummingbot API is that when you have a controller running, that controller is now dumped to the DB every five minutes by default. I think that’s the right interval. At some point we might go to one minute for real-time control, but every five minutes gives us only about 30 records per hour—otherwise we’d have a ton of records in the database, which probably isn’t worth it. Basically, we now have near-real-time information.

What we’ll have now is the progression of the P&L, the position hold, and everything over time. Right now, in this view, I’m just seeing a snapshot of how the bot is doing—a picture. I can’t see the truth of what actually happened over time. So my point was: can we make something that actually lets you see the bot in real time while it’s running? That was the goal.

The other thing is that the information we collect from the controllers is naturally the realized P&L, the unrealized P&L, the global P&L, and the volume traded. That data is available, but I also exposed a get_custom_info method that you can add to your controller. If you look at the PMM Mister get_custom_info method, everything you put in there will be sent through the MQTT broker.

Mike: Let me paraphrase to make sure I understand. Right now in Hummingbot you see the real-time performance of the bot, but ideally you want to see how the bot has traded over time. So you’re sending a snapshot of the performance summary—plus anything the user puts in custom info—every five minutes. Where is this data being sent?

Fede: The data flows through MQTT, so the bot stays very lightweight—we just send the data over MQTT and collect it with the Hummingbot API, which then has the real-time data. The only new thing here is: it’s good to have the real-time data, but now let’s also save a snapshot every five minutes so we can construct the history later. It’s the same mechanism we already use for the portfolio—as the Hummingbot API runs, we can see a one-week portfolio with snapshots every five minutes. We’re doing the same thing, but for the active bots.

Mike: So right now it’s creating a new Docker instance for the bot, and in that instance it’s running three different strategy controllers—one for each trading pair?

Fede: Yes, exactly. Here’s the bot that’s running—it started about 22 seconds ago. It’s already trading on three different markets. We don’t have a position on every pair yet, but now we have positions in each of them. This view shows the data live. If we enter one specific controller, the historical data isn’t available yet, because we take a snapshot every five minutes, so it’ll take a little while to get the first one.

We can also change the config of the bot from here, save it, and update the running bot in real time. That’s a really cool thing you can do.

Mike: Wow, that’s fun. So it updates on the fly—you don’t need to stop the bot?

Fede: Yeah, it updates on the fly. This is a new feature. Honestly, this form is a bit of a pain compared to the editor we have here, so maybe I’ll just add a Markdown view on the left in this style. What do you think?

Mike: I think so too. It’s more useful, but we’d have to know the types of each field and constrain them. If a user can put in arbitrary items, it’s probably better to have Markdown. The only thing is: are there certain values you can change? For example, if you change the connector name, would it break the context?

Fede: The controller itself has a concept of updatable or not—I’m marking which fields are updatable and which aren’t. So it doesn’t matter if you change the connector name; since it’s not updatable, it won’t let you change it.

Mike: Got it. If you go to Markdown, you might be able to highlight the ones that are updatable—bold them, or gray out the ones that aren’t—so the user knows what they can change.

Fede: Yeah, good idea.

Fede: Now we have the first information here. If we go to Bots, we need at least one more record—we’ll see another line in the next five minutes showing the change. As you can see, we have the realized, unrealized, and total P&L, and the volume on a different scale. Once we have position hold, it’ll also show that.

For reference, I think we pasted on Twitter and in Discord how it looks. I’m currently changing the layouts a bit. Another cool thing is that here we can switch through each controller individually—though right now it’s not letting me switch; there’s something blocking it because I just made a change in the PR that I need to review.

Once we have more than two records, this shows the combined P&L of all the controllers you’re running. That’s really cool, because you can see, “I’m running five different algorithms, and this is the combined performance.” Some can go well, some can go wrong, but the interesting thing is you can see the combined performance.

Mike: Just so I understand—those three controllers are running in the bot below, which is basically the Docker instance managing those three controllers?

Fede: Yes, exactly.

Mike: Should the user be concerned if they see errors, or is that part of normal operation?

Fede: If they see errors, they should look at them to understand what they are. For example, “open order failed” usually happens if you’re using limit-maker orders and the order the bot sends crosses the mid-price—it would match and take while crossing the order book. That can happen if you’re sending an order that’s un-updated, or in my case, sending orders very tight. Another error here is that I tried to set a leverage of 20, and 20 isn’t valid for this pair. So you want to look at these and see if there’s a specific error.

The good thing is that here we have a view of controllers—that’s probably what you care about. But remember those controllers can be deployed in different bots. If I deploy three more controllers, I’ll see another bot with three controllers. The bot is the Docker container; the strategies run under that container. I can deploy another Docker container with three more controllers, and that results in another bot.

I actually broke the visualization—it was showing the full-screen thing, so I’ll probably fix it today. I just pushed it.

Mike: I get the general concept, and it makes a lot of sense, because when you’re trading it’s not just a point in time. You run a bot for a day or a week, so you really need to see how the bot is evolving—how the P&L evolves over time. That gives you a lot of insight: is this bot doing well because it’s consistently profitable, or is it just getting lucky because the market happened to move in its direction?

Fede: Exactly. And this is where I think the agent will be good—almost in real time—at understanding what’s actually happening. For example, this BIL market has most of the realized P&L. Why? It has the most volume and the lowest unrealized. So the agent should say, “Okay, let’s allocate more total quote to BIL instead of the others, because it’s making more realized P&L.” Now that we have two points, you can see it. This combined view is the realized P&L of all the controllers. If I want to see just one, I can isolate it. This is really cool—I think it’ll be a game-changer for the agents.

Mike: I think that’s also why we should use this in the trading competition—being able to see the performance of different bots and how they rank against each other. We basically need the same data to make the competition more interesting.

Fede: I agree. This is what I’m working on right now, and it involves changes on both the Hummingbot side, the Hummingbot API, and Condor—that’s the only downside. But overall it’s really cool.

Mike: Just to wrap up—this is actually why we’re delaying the hackathon by a few weeks. We want to make sure the agent can manage controllers like this, so you can have a set of controllers running and your agent can make changes on your behalf—a more agentic strategy. Hopefully we can finalize all those changes in the next few weeks so that when the hackathon starts on June 19th, you’ll be able to deploy agents that manage this for you. Registration is already open, so if you’re interested, sign up—we’ll be sending emails to the registration list over the next few weeks with more resources and information about how the hackathon works.

Fede: See the difference in how it’s trading now compared to before? Before it was much more aggressive—well, it’s still aggressive now. But notice how fast and easy it was to deploy three bots on three different markets. Even if some of these markets aren’t very competitive, it’s quite interesting how easy it is to do. That’s all for me—I’ll push this, and it should be available very soon.

Mike: Nice. Just to wrap up, thank you all for joining another episode. We’ll be here next Friday again—Fede will actually be in Europe, so it’ll be a little more interesting. Next week we’ll probably cover more changes; we try to cover every change we make to Condor on a weekly basis. And starting June 19th, when the hackathon starts, we’ll use these weekly sessions more as workshops for the folks attending, to guide you in building your agents.

One last thing—I’ve always wanted to do a regular podcast. Part of me wants to be semi-famous, so to speak. We have about 10 viewers on average right now; hopefully we can grow that 20% every week and get to hundreds, if not thousands. So that’s my ulterior motive. Really, thank you everyone for joining and asking questions. We’ll see you next Friday.

Fede: Bye bye.