'You get torn apart - but that's how you evolve' Brian McCrindle on proteins, pretraining, and pushin' to prod
OTF, Mainframe, IOTA: Brian has contributed to some of Bittensor's best systems. So we sat him down to ask about his lessons along the way.
Brian McCrindle is Bittensor through and through. An early Opentensor Foundation hire, he helped found Macrocosmos with Steffen Cruz, before launching and leading Subnet 25 and, more recently, IOTA.
But Brian is also the Bittensor in another way. He doesn’t push updates to miners - he works on subnets with them, shoulder to shoulder. Whether it’s midnight or first thing in the morning, Brian’s the first to rally the troops, listen to their latest ideas, and take action. Non-stop engineer, community lynchpin, and degen memelord, rolled into one.
It’s not easy. Yet it’s this hands-on experience of both backend incentive design and front-line miner support that gives engineers like Brian the edge. And since April, he’s brought his skills to IOTA, shaping our approach to the subnet from the start. So we sat him down, handed him a coffee, and asked him what he’s learned along the way.
What are the key challenges of being a lead subnet engineer?
Brian: “Running a subnet isn’t trivial. But you can only learn by doing it: seeing it catch fire, witnessing the miners’ behaviour, and understanding why it doesn’t work in practice.
It’s also complex, because it’s not just one skill. From the tech side, you need all the skills of a traditional software engineer. But you also need Bittensor expertise: how do you build that system to incentivize the outcome you care about? And finally, you also need to be a leader, because no subnet exists in isolation - it depends on its community. So how do you motivate people to work on your subnet, stay involved, and believe in what you’re building?
No one’s perfect at all three. So I’d say working as a lead subnet engineer humbles you. You grow as an engineer and as a person.”
Describe the launch of SN25, Protein Folding, and what you learned from the experience.
“When I started at OTF, we were focused entirely on Subnet 1, because it was the only subnet. Steffen Cruz (Macrocrux), who was CTO of Bittensor, asked me to help him form Macrocosmos, and both of us were fascinated by the question of whether we could do science on-chain.
Bittensor had never done science before. Frankly, a lot of people said It can’t be done. And they had good reasons for doubting. A lot of good ideas come from naivety: not knowing the risks is actually helpful to getting started.
It’s easy to forget how far Bittensor has come. In early 2024, we were firmly in the project era. No one was thinking about product, because it was so new; instead, teams were asking, what could Bittensor do? So we just tried. Protein folding was computationally difficult. Bittensor had never proven itself as a DeSci protocol. We thought, let’s give it a go. And we became the catalyst for others.
Very quickly, protein folding became the go-to example of Bittensor’s flexibility. When explaining the protocol, you’d hear people saying, ‘It can do anything from predicting crypto prices to folding proteins!’ It was cool - like, just by pushing the protocol in a new direction, we were able to prove its overall potential. We set out to solve the problem of that incentive, and we did it.
A lot of growth comes from seeing that something is possible; I’m proud we pioneered it on Bittensor. But the first few weeks were so stressful. On testnet, you live in an artificial environment; you experiment; you run what registration might look like, but you don’t know what main will do until you launch. You just need to push to prod, live in the chaos, and learn. You won’t have any idea of how to fix it. You stay up late, talk to the community, and you hate the very things you spent so long building because the incentive’s broken. But you live and breathe in the world you’ve built. And it’s a special moment to live there for the first time, because others join you there. It dawns on you: we can get people to work together on shared goals.”
So how did your relationship with miners and validators develop?
“Bittensor might be deep tech, but people value people. They want your own voice, not a company’s. You can be yourself. At times, SN25 felt like a cult - there was so much belief, so many insider jokes, so much shared struggle. They responded to our honesty and openness, and that helped us be even more honest and open. And yes - Szymon and I, we’re exactly as we are in real life. We hang out together all the time.
It’s not perfect, but our community push us to improve. Being in it is more beneficial than not. A subnet is a living, breathing organism, and you need to be in it with your miners and validators. So if you’re not yourself, you’re going to struggle.”
How does SN25’s design differ from SN9’s?
“It’s like moving country. Or like switching operating system. Or - it’s like going from a first-person shooter to a third-person shooter; your perspective is different, the way you interact is different, but the tools in your hand are the same: the tools of Bittensor.
SN25 was always grounded in something physical. There’s a quantity we care about measuring - energy - and it should be a good indicator of what a solution is. It doesn’t depend on your arbitrary judgement of whether it’s good or bad. We discovered a clean, elegant incentive mapping onto real-world outcomes, and that’s why we could fold more proteins in 6 months than Folding at Home managed in over 20 years.
But on SN9, IOTA, it’s different. While we do have metrics, it’s not grounded in physics or math. Miners are incentivised to do much more work. It’s all about domain knowledge. When designing IOTA, we had to keep asking: what is the optimal metric to generate the commodity we most care about?”
How does your experience on Mainframe inform your work on IOTA, and vice versa?
“SN25 taught me to relentlessly write better code. But the biggest learning was the Bittensor piece: knowing instinctively what will make your life easier on mainnet.
Understanding what we could have done differently on SN25 - which is not trivial knowledge - such as how we could’ve structured data differently, allowed me to inform implementation on IOTA. That helped us avoid mistakes and do the Bittensor aspect right.
For example: how do you organize your miner rewards, and track that reward over time? Most subnets reward via an unordered list of things. You want to track the number of times a miner has done a backwards task, time since we last spoke to them, their score, and so on, but there’s no hierarchy between them.
When I arrived at IOTA these were separated in different locations. I told the team we need to build a miner registry, as we did on Mainframe when we refactored. This self-contained category mandates that anything about miner operation must be in this location, which means miner information is indexed properly and tightly coupled. And that means that adding different metrics is super easy, rather than adding more complexity to a disparate mess. Visibility leads to better performance. You can move quicker. And when things are so complex, being streamlined matters.”
Describe the build-up to IOTA’s launch, and what you learned along the way.
“When I got parachuted into SN9, I found myself in a different world, midway through - learning characters, history, papers.
I learned how difficult it is to build something production-ready - and that it’s impossible to do it by yourself. Even with so many experts on the team, we’re all ill-equipped to do this by ourselves. Machine learning, model training, incentive design: all of us bring something different to the table - you need a combination of builders and researchers to make it happen.
Everyone has a different skill, from deployment to incentive structure to exposing endpoints to miners. So when you have diversity of thought and experience, you each expose one another’s naivety, so that each blind spot is exposed by another of us, and together we can create and launch a well-rounded, successful subnet.”
What do SN9 and SN25 reveal about Bittensor’s strengths and drawbacks?
“Bittensor will always expose what’s wrong. It shows your naivety of how to build a good, robust system, and you need to accept that, at first, you’re going to build the wrong thing. Bittensor exposes the pitfalls of your design faster than any other system. Building in a variety of environments shows you the right path. If you don’t, you might get away with it for a while, but sooner or later the miners will ruthlessly reveal the problems in your design. And if you’re lucky, they’ll do it faster.
Regular web 2 companies can build in peace; we build in public. You’ll never be forced to expose until you’re ready. That’s a relief at first, but there will be hidden fragilities to your system, and the longer you go without finding them the bigger the risk. On Bittensor, red hat or white, you get the reward. You build wooden legs, people chop it. You build metal, they burn through. And it’s like, OK, I need diamond legs.
But here’s the thing. As long as you can parameterize the problem, you can build anything. Be prepared for the problems, be prepared to put out fires on mainnet, and remember that you’re building in public, so if you do something suspect, people will notice and lose faith in you. And because you’re co-creating, your community’s trust is everything.
That’s why I love Bittensor. It proves that, with the right idea, you can build almost anything.”
Where would you like to see SN25 and SN9 in a years’ time?
“For Mainframe, we’re looking for real scientific impact. Produce a dataset and contribute to the research that impacts the world. That’s the goal.
For IOTA, we’re going to train our own model, and we’re aiming for it to be the largest decentralized model ever trained. Once it’s accepted and acknowledged beyond Bittensor, we’ll know we’ve done it.
So scientific breakthroughs and the best decentralized AI model ever. No pressure!”
Finally, what advice would you give to engineers looking to build on Bittensor for the first time?
“Get ready, psychologically and philosophically. Because you’re building for people wo aim to destroy it. I can’t tell you how different that is from regular software engineering. If you’re not ready for that, you don’t realise how significant that is.
It changes you. People who’ve been building for a long time understand the importance of velocity: get it to the end user to get feedback faster. But on Bittensor, velocity is accelerated to the point of warp speed. The iteration cycles are so fast it’s like you're evolving in real time. Yet that’s how the protocol has launched such competitive systems in so short a time.
So: be aggressive. Expose yourself to Bittensor’s ecosystem. You’ll get torn apart - but that’s how you evolve.”
Join our Discord and Telegram communities, and be part of our team.
 | A guest post by
|