The Dependency Loop: Why Network Teams Integrate Infrastructure & Tools on Testnets, Not Mainnets

Key takeaways for ecosystem leads & product managers at EVM chains:

1. Work with your tech team to get tooling recommendations
2. Map your infrastructure gaps before talking to potential partners
3. Expect blue-chip protocols to have a list of required vendors for deployment
4. Target high-value partners once your core infrastructure and tooling are in place to avoid onboarding and deployment delays
5. Integrate during testnet to remove dependencies, improve team velocity, and ensure security

For network teams, infrastructure and tooling integration isn’t just a box to tick as they build and scale their chains. More often than not, it’s a prerequisite for key DeFi protocols and partners to even onboard to new chains. 

Missing one infrastructure provider or tool can add months to your timeline and delay strategic partnerships on your network. Retroactively integrating with infrastructure providers while your partners wait adds however long it takes to evaluate, integrate, and test that service provider. Imagine having multiple partners with similar dependencies.

Yet the decision of which infrastructure to integrate, when to integrate it, and how to select vendors under budget constraints remains one of the most challenging aspects of bringing a new chain to market. 

We sat down with Renna Ba, the head of ecosystem at Morph, Steve Yoon, a project manager at Stable, and Eddie Ye, a product owner at Interval to understand what it takes to assemble the right infrastructure while navigating high-stakes decisions.

How delayed infrastructure and tooling integrations create dependency loops

For network teams building payment chains, the underlying infrastructure typically entails several layers built on top of each other:

1. The foundational layer includes the network infrastructure, such as RPCs, oracles, bridging, custody providers, account abstraction, KYC, and other core components. 
2. The second layer is DeFi, which means bringing liquidity onchain by onboarding key protocols and enabling the stablecoin infrastructure. 
3. Once the first two layers are in place, teams have a strong foundation and value for the third layer – payment partners and financial institutions. 

Without the core layers in place, network teams are blocked and cannot even start building strong partnerships with financial providers. As a major dependency, the first infrastructure layer is a prerequisite for onboarding DeFi teams and bringing liquidity onchain.

Renna Ba, the head of ecosystem at Morph, has been assembling these layers as the team builds the new settlement chain for global payments. Working closely with different stakeholders throughout the process, she shares valuable insights into the key role infrastructure plays:  

“If you don't have your core infrastructure on the chain level up, you can't really launch stablecoins. You can't really build DeFi. And so, all of this becomes a dependency loop where the first thing you need to do is deep dive into your chain infrastructure and identify the gaps.”

This interdependency means that network teams need to proactively build the foundation that makes strategic partnerships possible.

Testnet vs. mainnet: when’s the right time to integrate? 

The timing of the integrations is also a major consideration that network teams need to take into account when talking to different vendors and planning roadmaps. Generally, they need to decide whether to integrate the infrastructure and tools during the testnet phase or wait for the mainnet launch. 

This decision depends on networks’ business objectives, the maturity and size of the chain, and internal development requirements. However, most of the teams decide to integrate the tools and infrastructure before launching their mainnets for several important reasons: 

1. Onboarding blue-chip protocols and partners

When launching a new ecosystem chain, onboarding DeFi protocols and partners is one of the most important tasks of ecosystem leads, product owners, and project managers. However, it’s typically dependent on the underlying infrastructure. 

All major Web3 teams have established internal processes, frameworks, and tools, which become a prerequisite for their deployment to new chains. They may even have a list of requirements for tooling and infrastructure providers when deploying to new chains.

So, network teams need to meet these requirements to onboard the key partners and ensure their fast, smooth deployment onchain. Here’s why Renna advises doing this step during the testnet phase:

“Ideally, you're in the testnet phase, you're focusing on infrastructure, and you have a clear goal of where you want to be, working closely with your tech team. Once the infrastructure is set, you can target the key partners. Otherwise, if you’re trying to onboard a project and they have a hard service dependency, you're extending your entire process by however long it takes to integrate that service provider versus just a month that it takes for the project to onboard.”

2. Minimizing risks with a proactive security setup 

Integrating critical tools and infrastructure during the testnet phase also enables internal network teams and key partners to test their deployments before the mainnet launches. This way, they can uncover any unexpected behavior, especially when deploying to chains with non-standardized EVM implementations.

For instance, chains with custom changes to the EVM may have different gas opcodes, which cause contract deployments to behave differently. With the right tools and infrastructure, teams can catch these before deploying to mainnets, thus minimizing the risks of potential exploits.

Therefore, having the right tools can help kickstart the activity on a chain while minimizing technical and financial risks. Integrating them during the testnet phase is crucial for proper planning, enabling teams to validate assumptions, identify vulnerabilities, and avoid unexpected problems once live on mainnet. This way, network and partner teams can reach a mainnet launch with fully operational setups already running even before day one.

3. Increasing the development velocity of internal teams

If your team is building application-specific chains and developing their own smart contracts, they can also benefit from having the tools and infrastructure enabled during the testnet phase. Aside from removing potential security risks, proper tooling can accelerate the development velocity of your internal team and reduce your overall time to market.

For instance, Eddie Ye, a product manager at Interval, an application-specific L1 built on the Cosmos stack with EVM compatibility, mentions the importance of tooling for internal team velocity. Since the team is building Interval as a data marketplace, they’re exploring tooling and infrastructure solutions that suit their development lifecycle. As they build the logic at the application-level, they will need simulations and advanced testing infrastructure to validate solutions internally.

Additionally, Eddie expects to see the rise of application-specific chains, even L1s, in the future since they allow teams to introduce highly customized solutions. With that in mind, Eddie advises teams to make opinionated decisions early on, understanding their unique business goals and narrowing the focus. 

“If you try to build a system to be extensible for future use cases and enable all kinds of integrations down the line, you risk having an architecture that’s too broad. Nowadays, I think L1 appchains are being sprung up because there's a specific use case that they can address. The appchain thesis may actually be the way forward, at least in the next year, two, or three. So, try to niche down and even consider possible trade-offs early on.”

How do network teams actually choose vendors?

Given that the infrastructure and tooling become a hard dependency for teams to deploy to new chains, you need to move fast when selecting providers. Additionally, since the integration is usually done during the testnet phase, you may have a strict deadline for making the right decision that not only meets the set requirements but also fits your budget. 

Here’s how leading ecosystem leads, product managers, and product owners decide on their infrastructure and tooling partners:

• Internal team alignment: Both Renna at Morph and Eddie at Interval reveal the importance of understanding what your development team is building, what the vision for the chain is, and how you can help realize it. So, make sure to work closely with your tech team first, get their recommendations, and consider internal requirements. 
• Partner requests: What all of the teams building a public ecosystem chain have in common is their focus on onboarding key DeFi partners. This means working closely with the projects and often receiving a list of specific vendors to integrate.
  
  Steve Yoon, a product manager at Stable, mentions that “most blue-chip players in the crypto market want Transaction Simulator and Virtual TestNets”, which was one of the infrastructure prerequisites for teams building on the chain. Similarly, Renna received a list of required vendors on Morph.
• Ecosystem development: If you’re building a public blockchain and plan to grow a developer ecosystem, you also need to consider which tools are critical for achieving this goal. As Steve mentions: "If you're trying to create a better ecosystem for developers, some testnets are really crowded, and you might have a hard time even just sending a transaction.”
  
  Exploring challenges such as this one that developers face in everyday workflows can help you navigate the selection of tools and infrastructure solutions that solve real problems and help you build a stronger ecosystem.
• Commercial considerations: Once you have the list of vendors from your team and partners, you need to explore the commercial offers to understand what works best for your budget and timeline. So, make sure to consider long-term options and explore ways to expand without going over budget. As Steve also mentions, having modular integration and pricing options enables them to add features as needed and expand as they go.
• Technical evaluation: After gathering the vendor offers and dependencies from your team and partners, the final step is running a technical evaluation to see whether the integration is possible. While some teams do this internally, it’s usually the infrastructure partner who runs this check as one of the key steps in the integration process. 

Integrate a tooling and infrastructure partner that grows with you

Deciding which tools and infrastructure to integrate and at what time requires you to consider all of these factors. As the leaders behind the scenes at Stable, Morph, and Interval illustrate, the final choice enables you to support your strategic partners, empower your internal development team, and build a strong developer ecosystem.

With Tenderly, you have a partner who aims to facilitate your journey and offer the right kind of support for your chain’s size, specific goals, and requirements. Schedule a call to explore how Tenderly can assist you with scaling your chain operations.