When people think about creating trustless infrastructure across different blockchains, they often imagine it as a purely technical challenge — pick the right architecture, write the code, run the tests. But the real story is more complex. Behind every successful cross-chain system, there’s something even more crucial than tech: a team dynamic, a work culture, and decision-making processes built to function under pressure, tight deadlines, and limited resources.
In this interview, Vladislav shares an inside look at how cross-chain development teams operate, how they manage security risks when architecture has to balance trade-offs, and why technical expertise alone isn’t enough to succeed in building the future of decentralized infrastructure.
— In cross-chain projects, each network comes with its own architecture, consensus mechanism, and programming languages. How do you structure your team’s work to meet the specific needs of each ecosystem?
— Coordinating developers across multiple ecosystems is one of the hardest parts of cross-chain development. We primarily work with three programming languages: Rust, Solidity, and Go. Each language is closely tied to a particular blockchain environment — Rust for Solana, Polkadot, and Substrate; Solidity for Ethereum and EVM-compatible networks; and Go mainly for infrastructure components and node interactions.
At first, it might sound logical to build a team where every developer knows all three languages. In theory, this would create flexibility. But in practice, that approach causes more harm than good. The broader the stack someone tries to cover, the more intense the context-switching becomes — and that’s always a major productivity drain," he explains. "Jumping between Rust and Solidity or Go is not just switching languages; it's like switching operating systems. You might understand the basics, but the deep nuances that matter for high-quality code get lost.
Instead, Composable Foundation builds its teams around deep specialization. Each engineer focuses on a primary stack they truly master, enabling them to work faster and more effectively without getting bogged down in constant mental overhead. Knowledge-sharing still happens — developers need to understand how adjacent components interact — but when it comes to architecture and coding, they stay anchored in their areas of strength.
This model was critical when our team adapted IBC for three very different blockchain ecosystems. Every network required its own strategy: we used Zero-Knowledge proofs to verify data on Ethereum, modified validator node software on Solana, and developed custom modules for Polkadot through Substrate.
Architectural decisions were always made collaboratively across the teams. But when it came time to actually implement solutions, we trusted our specialists to own their parts of the system fully. That’s how we avoided bottlenecks and kept momentum strong.
— When developers focus on different stacks, how do you make sure the architecture stays consistent and doesn’t break apart into fragmented solutions?
— That’s a crucial part of cross-chain work. Specialization brings speed and expertise, but without careful coordination, it can easily lead to misaligned systems.
To avoid that, I place a strong emphasis on collaborative architecture discussions before any code gets written. The team holds deep-dive sessions to discuss how different components will interface, what data formats they’ll use, and which security guarantees need to be baked in from the start.
Every developer brings insights based on the ecosystem they know best — whether it’s Ethereum, Solana, or Polkadot. We treat those ecosystem-specific constraints as design input, not afterthoughts. This way, the whole system is built around real-world limitations, not idealized assumptions.
Although the team operates in a fast-paced startup environment where detailed documentation can often feel like a luxury, I always make sure that key architectural decisions are documented. We don’t write 50-page design docs for every module. But we absolutely document the important things — how the relayer is structured, how cross-chain messages are handled, and what the security standards are at every stage.
This lightweight but targeted documentation strategy keeps the architecture aligned without slowing down development. It also helps onboard new team members and ensures that different parts of the infrastructure can evolve without breaking the core system.
— Have there been situations in your work where standard engineering processes weren’t enough to solve a problem, and you had to look for alternative solutions?
— One situation stands out clearly for me. It happened right before the launch of one of our major bridges. We hit a critical issue: one of the key components wasn’t functioning reliably, and our usual internal processes — which normally would have caught and resolved it — just weren’t enough this time.
At that point, we had a highly specialized team, with everyone deeply focused on their own areas of expertise. The architecture was solid, and technically, everything was sound. But despite multiple rounds of internal discussions, we couldn’t break through. It wasn’t just a coding issue — it was something deeper that called for a different kind of thinking.
In the end, the solution came from a developer who wasn’t necessarily the strongest coder on the team, but who had strong ties to the wider blockchain community. He reached out to an external contact and brought back an approach we hadn’t thought of internally. We adapted it, integrated it, and it worked — saving us from what could have been a major delay.
That experience reinforced something I deeply believe: technical skill is only one part of what makes a team effective. Curiosity, initiative, and the ability to tap into broader networks are just as critical. As a team lead, I see it as my job to create an environment where those qualities are encouraged and valued. Sometimes the person who doesn’t write the final piece of code is the one who finds the key that unlocks the whole solution.
— How do you structure your processes to minimize risks when introducing changes to infrastructure-level solutions?
— When you're working with trustless infrastructure, you have to assume that even small mistakes can have outsized consequences. You’re dealing with independent blockchains, each with its own consensus mechanisms and architectural quirks. And once you deploy something to a public blockchain, you lose direct control — that's the whole point of trustless systems.
To manage this, we build external control mechanisms into the system itself. That way, we can adjust how modules behave without needing to redeploy code. Every update goes through two stages of testing: Devnet and Testnet. Devnet is our playground — it’s where we can push new features, stress-test assumptions, and debug without worrying about real-world conditions. Then, once we’re confident, we move to Testnet, which is much closer to a live environment — full network load, real validators, real external interactions.
Only after passing both stages does a change go into production. And even then, we make sure we have fallback options. For example, when we implemented new logic in the Solana validator node for rollups, we included a way to disable the module or revert to a previous version just by adjusting configuration settings. That gave us the flexibility to deploy confidently, knowing that we had a rollback path if anything unexpected happened.
For the most critical components — anything that touches transaction verification, cross-chain communication, or system consensus — we always commission independent audits. No matter how good your internal reviews are, having an external perspective is essential, especially when you're dealing with systems where mistakes can cascade across multiple networks.
— There are always times when you have to choose between quality and meeting deadlines. How do you make those decisions?
— That's just part of reality when you're building something complex, especially in a startup environment. Of course, the ideal is to always do things the right way. But sometimes you have to prioritize. For critical modules — anything related to security, consensus, or system integrity — we don’t make compromises. We take the time needed to get it right, even if that means pushing deadlines. You can’t cut corners on foundational infrastructure.
But for secondary tasks — things like non-essential tooling, UI improvements, or auxiliary features — we allow ourselves to be more flexible. Sometimes that means shipping a simpler version first and planning to improve it later. Sometimes it means knowingly taking on a bit of technical debt.
The key is to track that debt actively. We document every temporary solution we put in place and prioritize revisiting it once we have the bandwidth. In my view, managing technical debt is no different from writing tests or maintaining your CI/CD pipelines — if you ignore it, it’s going to come back and create bigger problems later. So we treat it as part of the core process, not as an afterthought.
— Are there any plans to further develop your processes — for example, introducing metrics to assess quality and efficiency?
— Right now, we don’t have a formal set of internal metrics for assessing either the quality of individual processes or the overall resilience of the system. In a startup setting, you’re always making choices about where to put your time and energy: either you focus on the product, or you focus on optimizing the processes behind it. So far, the focus has been firmly on building and refining the product itself.
That said, it’s definitely something we plan to evolve over time. As the project grows and matures — and as we have more resources to allocate — introducing structured metrics will be an important next step. Metrics will help us track how we’re improving over time, spot bottlenecks early, and ensure we’re consistently maintaining the level of stability that infrastructure projects require. It’s not about bureaucracy — it’s about making sure resilience stays a built-in part of how we work.
— As your projects grow more complex, what practices or team values do you think are most important to preserve for the long term?
— One of the biggest things for me is maintaining a culture where initiative and curiosity are treated as seriously as technical ability. Those qualities are what drive us to find creative solutions when standard approaches don’t work, to learn from the broader community, and to share knowledge openly within the team.
Of course, we’ll continue evolving the formal side — we’ll build more structured processes, introduce quality metrics, and strengthen our testing pipelines. But at the same time, I want to make sure we don’t lose the flexibility and open-mindedness that allow us to move fast, adapt quickly, and solve problems in ways that aren't always obvious from the start. Holding onto that culture is just as important as any technical improvement we make.
