Bridging custom EVM chains to Tron liquidity | Andrew Nalichaev interview

Apr 29, 2026

Summarize with AI

In this conversation, Andrew takes a closer look at what it means to connect a custom EVM chain to Tron liquidity. He walks through bridge security, edge-case vulnerabilities, the limits of audits, and the tradeoffs behind LP, lock-and-mint, intent-based, and hybrid models with a focus on what actually breaks in production and why.

If you are working with custom chains, interoperability, or liquidity routing, this is a practitioner-level breakdown of the decisions behind cross-chain infrastructure.

Interview text

Elaborate on the CrossCurve exploit in February 2026. What exactly failed there, and how should incidents like this change how we think about cross-chain bridges?

I think it’s a really brilliant question because we are in partnership with CrossCurve, and we used their solution for some of our customers. Definitely, when the accident happened, we really tried to evaluate how it affected our customers and our partnerships. And after an internal check, we recognized that the good news is that it has no impact on our specific customers.

What actually happened? So, CrossCurve used some external messengers that should send a message from the source chain to the destination chain. What it actually means is that CrossCurve said that they have, and they actually have, the solution called a consensus bridge. That actually means that they use different messengers at once to protect the specific transaction, the process of lock-and-mint, or the process of transferring liquidity across the chains. But in this specific case, they had to pack these two different chains, so they used only the Axelar solution.

And the problem is not in CrossCurve but in the Axelar messaging mechanism. What does it mean in practice? When someone sends a transaction from the destination chain to the source chain, the source chain only checks the transaction ID on the destination chain and compares the numbers, without actually verifying the message from the source chain. Unfortunately, many auditors and researchers didn’t mention this as a vulnerability. Because of it, CrossCurve just used the same solution and the methods approved by external auditors.

Basically, it shows us that sometimes we can’t even fully trust auditors and need to double-check each time. Maybe apply some additional AI checks or whatever. But the good news is that CrossCurve is still in the game. And definitely, there’s bad news about it, but that doesn’t mean it has problems from an architecture standpoint. We can think about it as a reminder of how someone can abuse and attack the bridges. But it still just means that we need to make some double-checks, keep in mind that such attacks can happen, and build the next cross-chain solutions and bridges more securely.

Many bridge failures are described as “edge cases.” Are these incidents really edge cases, or symptoms of deeper architectural issues?

You know, it depends on the case. I can say that the most common architectural problems were solved during the previous bull market, sometime between mid-2020 and 2021. So, the most common cases have already been resolved by now. But some cases are really edge cases. For example, the case of CrossCurve. I think that it’s a real edge case because even after all the checks, even with a good architecture and an absolutely brilliant idea, such weak points still exist.

And definitely, I think that right now we already have the most common architectural solution that can be. We call it a gold standard for the industry, and in general, it’s a common standard, I think. So, we can’t say that there are fully architectural problems with it. We can say that some small bugs or small unusual cases, and what we actually call an edge case, can happen.

I think our main goal right now is to prevent and protect against such edge cases at the architectural level. It’s feasible, for example, to use a hybrid solution, a double check, an additional audit, or maybe a cooldown in some cases. In our company, we really try to implement more and more security checks and protections, and sometimes even prefer to reuse existing solutions rather than create bridges from zero.

And in this case, it’s definitely better to apply the major standard rather than trying to reinvent the wheel.

Tron plays a unique role in stablecoin flows, especially for USDT. Why does Tron-to-EVM routing introduce different risks than EVM-to-EVM bridging?

I think it’s the question that any of our customers, or even anyone who decides to create their own custom chain, asks us. In most cases, it will be EVM-compatible chains, sometimes Layer 2 ZK-rollup or Optimistic rollup. And everyone wants to have a part of the liquidity from the Tron chain because it still plays a big role in stablecoin transfers: someone gets paid, gets a salary, or pays bills using stablecoins on Tron.

Definitely, anyone wants to get access to this liquidity and use it on their own custom chain. Tron and EVM-compatible chains have different types of addresses, different types of smart contracts, and different languages for the smart contracts. And that is why it’s so difficult. If we connect the EVM chain to the EVM chain, the address on the destination chain and the source chain will be the same, and we can use the same smart contract for lock-and-mint, even from the standpoint of the payments for the transaction fees.

So, on an EVM chain, we have the same mechanism for estimating gas fees and transaction costs. In Tron, it’s absolutely different, with an energy concept, with payment in some TRX, etc. It’s a reason why it’s so different and why it’s more complex, rather than just connecting two different EVM-compatible chains.

LP bridges are seen as the most “native-feeling” option. At what point does the liquidity requirement of this model become a structural limitation rather than a temporary hurdle?

You know, honestly, I think that LP bridges are the most classical approach for many chains. It means that you, as someone who wants to pair your chain with an external one, or as the owner of the bridge, don’t need to provide your own liquidity. You can ask the community to provide this liquidity, and in most cases, they will agree to share their liquidity with you.

But you need to provide them with some profit. And you will compete with existing DeFi protocols or other use cases for liquidity. It means your bridge should have a lot of TVL locked and a lot of transactions crossing it. If the transaction volume is really high and you collect a lot of fees, you will be able to share these fees with the liquidity providers.

Otherwise, in a case where you will have fewer transactions, that means that the LP provider has less reason to provide liquidity because they will collect less of the fees. That’s why they can decide to just remove liquidity from your bridge and use it on an external DeFi protocol. In this case, the slippage in this LP transaction, with this bridging using LP, will be higher.

That’s why someone can decide, “Okay, I don’t want to make the transaction on this chain with this bridge, and I prefer another option.” So you have to play with liquidity, and you have to provide more and more reasons to support your bridge solution with the liquidity.

Lock-and-mint bridges remove the need for pool liquidity, but introduce wrapped assets. In your experience, where do these bridges tend to fail first — technically, economically, or socially?

Definitely not from the social standpoint. You know, the best part about the lock-and-mint approach is that you don’t have liquidity at all. In the case of LP bridges, you need to ask someone to provide the liquidity for LPs. In this case, you don’t even need to have your own liquidity.

For the lock-and-mint approach, if someone wants to use some stablecoins or use your chain, they will be able to lock some number of stablecoins, or whatever coin it is, on the source chain, and then mint an equal number on your custom chain or, in general, on the destination chain.

But what’s the problem? The biggest problem with this approach is that it can create a different type of token on the destination chain. So it’s about the fragmentation of the liquidity. For example, you will have one version of the token from Ethereum and another from Arbitrum, or different types of tokens issued by different bridges with a lock-and-mint approach. So it’s about fragmentation.

But it also faces some problems from a technical standpoint because if someone attacks the messenger and sends the wrong message that you have to unlock some amount of tokens on the source chain or issue an additional number of tokens on the destination chain, then they will be able to get the additional liquidity that is not collateralized by the actual tokens on the source chain.

So it’s a big issue, and in most cases, if someone tries to attack such bridges, they combine an economic attack with a technical one, but not a social one.

Intent-based execution promises strong UX and low costs. Where does this model start to break down when volumes increase, or market conditions change?

I do agree that an intent-based approach can be the best approach from the user experience standpoint. But if you create your own chain, it means that you have to provide additional motivation to some bots, algorithms, or even persons to be the solver, because solvers are a key component of the intent-based approach.

For many of our customers, we use 1inch Fusion+. It’s exactly an intent-based approach. But if you want to use the same for your own custom chains, you have to motivate someone to be this solver. For example, if they see less and less transaction volume on your chain and fewer and fewer people who want to make this bridge transfer, they can just try to dictate their expectations to you from the revenue standpoint, and then the user experience becomes worse and worse.

And this low cost can be higher and higher, and the transaction speed can be slower. Maybe you will be the only solver or resolver who will operate with such an approach. So I think it’s the worst part about the intent-based approach.

The hybrid model shifts liquidity outside the destination network. What risks does this actually eliminate, and which risks does it concentrate instead?

When talking about bridges in general, if you create your own custom chain, you want to connect it to the external ecosystem. In most cases, I’m pretty sure you don’t really want to connect a single chain to a single external chain.

But if we use the LP approach or the lock-and-mint approach, it means you need to connect your single chain to many chains, which is really costly and requires a lot of liquidity. In most cases, it is normal to pick one chain as your source chain and connect it to your chain. And in this case, with your destination chain, it can be a lock-and-mint approach.

But this external chain can be connected to many, many, many other external chains in different ways. For example, with the LP approach or with an intent-based approach. If you create your own L2 ZK-rollup and want to access liquidity from the external ecosystem, you can use Arbitrum as a source chain.

Arbitrum can be connected to Tron via an intent-based approach and to Ethereum via an LP approach. And then this last mile will be just a lock-and-mint approach to your chain. So, the hybrid solution allows you to get access to any external liquidity on external chains, but with one intermediate chain that you will use as a source for your own custom chain.

If a team is designing a Tron-to-EVM stablecoin route now, in 2026, what is the first uncomfortable question they should force themselves to answer before choosing an approach?

I think the most uncomfortable question is: how much are you ready to spend on this bridge solution? And how much money are you ready to allocate for some solution? If we are talking about an intent-based approach, it means that from the very beginning, you will need to provide sponsorships or another reason for solvers to remain solvers on your chain. If the traffic across your chain is not the biggest one from day one, you will really need to sponsor their solution. If you stop doing this, in most cases, they can decide to turn off their solution.

Otherwise, if we are talking about a lock-and-mint approach, you will need to pay some money to the existing well-known messengers to connect your chain to their network of messengers. And it is a lot. I mean, you will pay hundreds of thousands of US dollars just to be connected, and it’s a one-time payment.

If we are talking about the LP approach, you can basically provide your own liquidity. And it still means that you can be the only LP provider for this approach, but this liquidity will be locked. Or you will pay someone to lock the liquidity, and it also means that you will have to spend some supply of your own tokens, or, in a best-case scenario, an additional sponsorship for the locked liquidity.

So, for me, the first and most important question is how much you are really willing to spend on it, and how much money and tokens you are willing to allocate to such solutions.

Meet the interviewee

Andrew Nalichaev

Blockchain Expert & DeFi Analyst

Andrew translates decentralized concepts into secure, functional financial tools. He navigates the volatile DeFi landscape to build scalable blockchain infrastructures that address real-world utility, moving past the buzzwords to deliver technical value.

View profile

Andrew’s expertise at work

Contact us

Book a call or fill out the form below and we’ll get back to you once we’ve processed your request.

Name

Company

Phone

Message

Send us a voice message

Attach documents

Upload file

You can attach 1 file up to 2MB. Valid file formats: pdf, jpg, jpeg, png.

By clicking Send, you consent to Innowise processing your personal data per our Privacy Policy to provide you with relevant information. By submitting your phone number, you agree that we may contact you via voice calls, SMS, and messaging apps. Calling, message, and data rates may apply.

You can also send us your request
to contact@innowise.com

What happens next?

Once we’ve received and processed your request, we’ll get back to you to detail your project needs and sign an NDA to ensure confidentiality.

After examining your wants, needs, and expectations, our team will devise a project proposal with the scope of work, team size, time, and cost estimates.

We’ll arrange a meeting with you to discuss the offer and nail down the details.

Finally, we’ll sign a contract and start working on your project right away.