What building Axelar's ecosystem taught me about partnerships

When you're building partnerships around infrastructure, almost anyone can look relevant.

Developers need the technology. Applications need distribution. Other platforms want integrations. Investors can introduce all of them. You can fill a calendar quickly without becoming much clearer about what will get used.

At Axelar, I helped build the early commercial and partnership motion and later led DeFi. That work included the value proposition, protocol relationships, governance proposals and launch coordination. It changed how I think about building an ecosystem from an early stage.

I start by asking what a user should be able to do when the work is finished. Then I work backwards through the parties required to make that possible.

A useful partnership has dependencies

Consider bringing an asset into a new blockchain ecosystem. The bridge is one part of the work. Users also need places to access the asset, enough liquidity to use it, applications that support it, and confidence in how the system operates.

Those pieces involve different organisations and different decisions. Getting one of them to agree does not make the rest inevitable.

The Frax proposal I authored in June 2023 is a concrete example. It connected an axlUSDC and FRAX liquidity pool on Arbitrum with governance integration, matched incentives and support across Axelar's product suite. The proposed matching budget ran for four voting cycles, with scope to assess the relationship over time.

The detail matters. We were proposing a way for several participants to make a specific pool useful. Each commitment had a job to do.

That experience is why I question partner pipelines organised entirely around company size or brand recognition. An early partner's value also depends on which missing part of the customer experience it can supply.

Sequence the work around the next constraint

I would sketch the full adoption path before deciding which partnership to pursue first.

Who has the user? Who owns the interface? Who has to approve the integration? Who does the implementation? Who benefits enough to keep supporting it after launch?

Then I would identify the dependency that is most likely to stop the whole thing.

Sometimes that is distribution. Sometimes it is a technical integration. Sometimes the product works, but no participant has a strong enough economic reason to promote it. The next partnership should address that constraint.

This changes the commercial conversation. Instead of a broad discussion about collaboration, you can explain the specific result you want, what each side contributes, and what would make the effort worth continuing.

It also gives you a reason to decline a partnership. If a deal adds maintenance and meetings without improving the adoption path, its logo may be more valuable than its contribution.

Launch needs an owner across organisations

The July 2024 Lido bridge deployment update illustrates another part of the work. It described deployment, verification, audits and a governance timeline, and named me as an Axelar contact for BNB Chain launch and GTM support.

The engineering, governance and commercial work had different owners. Progress depended on those owners understanding what was ready and what still needed to happen.

This is a substantial part of early GTM leadership. Someone has to maintain a shared picture of the outcome across organisations that don't report to each other. A signed agreement doesn't do that on its own.

I would track agreement, deployment and ongoing usage separately. They answer different questions, and the gap between them tells you where to spend your time.

The same questions apply to AI infrastructure

For an AI startup, a model integration, cloud partnership or marketplace listing can be useful. I would still ask how it changes adoption for a particular customer.

Does it reduce the work needed to deploy? Does it reach a buyer who already has a reason to act? Does it make the product easier to purchase? Who is responsible when the customer's first workflow doesn't work?

A partner with a large customer base may contribute very little if its sales team has no incentive to introduce you. A smaller implementation partner may be extremely valuable if it can get the right customers into production.

I also want to know what remains when an incentive ends. A subsidy can help start a relationship. Continuing support needs a reason that survives the subsidy.

Axelar's story continued after my time there. In December 2025, Circle announced an agreement concerning Interop Labs' team and proprietary intellectual property. Axelar's network, Foundation and token were outside that transaction. My contribution was to the earlier ecosystem and commercial work.

The lesson I bring forward is practical: choose an initial use case, identify the parties needed to deliver it, and give each relationship a measurable responsibility. That is how I would start building an ecosystem today.