[trustless://interop.landscape] Aram Kocharyan - TRAIN Protocol
trustless:// at Devconnect Argentina 2025 · 19 Nov 2025 · 24:28
Aram Kocharyan introduces TRAIN Protocol, an intent-based, cross-chain asset bridging protocol that needs no third parties: no oracles, no verifiers and no validators. A user and a solver swap assets across chains using an advanced version of atomic swaps, with verification performed locally and trustlessly. The talk was given on day 2 of trustless:// at Devconnect Argentina 2025.
Speakers
Topics
From trustless:// at Devconnect Argentina 2025, hosted by Account and Chain Abstraction.
Transcript
are continuing the discussion on the same topic of intense. Now please welcome to the stage train protocols Aran Kocharian. Welcome to the stage. Hey everyone. Hello. Um today I'm going to talk about train protocol. But first of all, let me make a bold claim to make you interested in this speech. All existing interup protocols right now are heavily centralized or heavily depend on centralized operators.
And the discussion I want to have today is two questions. How did we end up like this? How did we end up with a situation that almost all interrupt protocols are centralized and everyone is fine with that and how we move forward? For that I I plan to talk about you I I plan to tell you the story our story because we are the one that built a centralized bridge before.
So it's layer swap. I want to tell you how bit by bit, step by step, we end up with trusted centralized bridge and how we can overcome it. Everything started in 2021 when there is L2 boom, arbitrum, looping, zk light and everything else. And we were just three guys sitting together exploring crypto trying to find some problems to solve. And exactly this time my co-founder asked me hey if I have my assets in Coinbase account how I move them to our bit room let's say because at that time Coinbase was not supporting our bit room and it sounds really interesting problem
and this sounded a problem that we could solve. So what we did is we created the first version of layer swap and the main idea of the layer swap was to transfer your funds from Coinbase or from any other centralized exchange to layer 2. And the way we did it is we had a Coinbase account. So as a user you will transfer from your Coinbase account to our Coinbase account. Then we have funds in our Bitum. We transfer from our our Bitum account to your account. So very simple and it worked really well.
At this time every everyone was talking about layer swap. It was really insane. We had growth uh unimaginable. Then what happened we we had a new networks coming the zkync arbitrum optimist and we just kept adding all these networks. So we had this exchange to network basically going from coinbase to zk sync and we also have a network to exchange. So doing the same opposite. So far so good until one of my co-founders, the same guy asked me another question. Wait a minute. So we have accounts in all layer 2s. We have liquidity in all layer twos. Why we are only doing centralized exchange to layer
two? Maybe we should do just layer two to layer two because we already have these accounts. you users can just transfer to our address and then we can do the counterparty transaction in destination chain. You see that new flag. So, so we added this crosschain tab is like new shiny bridge and obviously it was completely trusted. So, we were just a trusted centralized operator. We were receiving the funds in source network in EOA and we were executing funds in destination network and everything was working fine. Users were using it. Uh no one was seeing any problem with us. No one was complaining.
Even the really good protocols that had really good decentralization and really minimized trust assumptions were not working but we were working. We were growing. All of this happened until 2024 when we started asking us question why are we even doing this? What is the reason of building so important infrastructure component in a centralized and in an unresponsible way and it was like kind of a crisis inside company because we were I was complaining about this doesn't make sense we don't need this product it's not important in two or three years it's
not going to be relevant at all and it's so important infrastructure piece we have to do something with And after these discussions, after a lot of fighting with my co-founders, a lot of uh researching, a lot of idea generation, a lot of brainstorming, we finally understood and realized one important thing. We were thinking about interop as a enduser product. We were thinking about this. Hey, okay. So, users want to go from one chain to another chain. So we make it fast and cheap and that was also because I don't know you remember or not but at that time there was this big narrative in
crypto everyone was complaining hey you all are building an infrastructure whatever you are building is not important it's not giving the crypto adoption and we were under that narrative as well. So we realized that in order to build actually actual value in interop you have to realize that interop is not an enduser product interop it's infrastructure it's really important infrastructure uh and by doing this when we changed our perspective about thinking in we started designing okay so how that infra infrastructure should look like. How we
want this infrastructure to actually look like and we just pinned it down to two main attributes. The first one is trustlessness. So the protocol itself when users are moving funds from A to B, users should not trust anyone in this path. They don't they do not they should not trust uh any custodian. They should not send their funds to anyone any multi-IG any contracts. Users should be able to do it without giving away their assets even if they are reputable and working company.
And we we know like not everything goes well with blockchains. Blockchains can get stuck uh they can get hard worked hard for whatever. So users should be able to refund their funds if something went wrong. If the solver is not working, if RPCs are not working or anything is not working, user should be independently able to refund their funds back if the swap is not happening. So that's about The second most important thing is permissionlessness.
During three years of operating layer swap, every week we are talking with a new network. Every week new networks are calling us hey guys can you integrate new network into layer swap and this is a huge pain point for networks in order to have an interrupt solution so they can onboard their users they have to get I don't know they have to get a lucky VC or these big boy guys or they have to pay money for a network integration so permissionlessness is really important thing for a protocol so if there are new networks They will be able to join the protocol from first day and there should be no company no gatekeeper stopping
them doing that. As we defined what is the problem and what we want. Let's step back and see what is the actual problem with interup. Why it's so hard and it's actually really simple to articulate. The the problem is the state problem. So optimist don't know what is starknet. They don't know it. They optim for in optimist universe there is no starknet. For optimist universe there is no solana. So all these networks keep their state and they don't they they don't have any idea about other chains.
And how you would solve this is if you have a third party or any party that can provide a trustless crosschain messaging between one chain to another chain. If we can have a trustless crosschain messaging that problem will be solved, right? Because you will be able to pass data uh data call data or whatever from one chain to another. If you had this, no problem. when you have this the problem is that we don't have it and we couldn't find a solution ourselves. We when we were trying to
solve this problem, we couldn't find any way to implement a generalized crosschain messaging in a trustless manner. Good luck other teams. But what we did is we decided to narrow scope down to asset bridging and swaps only asset bridging and swaps. When we narrow down the problem, we already see in this market how like intent solver systems not specifically intent solver but the uh systems where user is sending funds and someone is giving funds in the destination network. Let's call it intent solver to not confuse with anything else. So how that works? User is committing funds in the source network and solver is ready to give
funds in destination network. In this design we basically have two parties user and solver and we already had a mechanism that is like well invetted maybe 10 years ago atomic swaps. So when you have atomic swaps you don't need any trusted third party. So two parties can exchange assets using atomic swaps. And to give you a quick intro to atomic swaps, atomic swaps are all around HDLC contracts, hashtime lock contracts. The way atomic swaps work is user is generating secret calculating hash of
this secret and locking funds in source chain with two conditions. One condition is if the secret is revealed, funds are going to solver. Second condition is if time block passed let's say 15 minutes or 20 minutes passed user can claim funds back. Once user does this transaction solver to whomever user created the uh contract sees this transaction in source chain and creates counterparty contract in destination chain with similar conditions with same hashlock. The hashlock that user owns the secret with same hashlock but when the secret is revealed funds are going
to user solver does that when user detects this when user sees in destination network hey wait a minute there isn't a contract I can reveal my secret and claim funds user goes to destination network this the does the transaction to reveal the secret and claims the fund once it uh done secret is right now public so solver can take the secret go to source chain and claim their funds back. So far so good but we can already see few problems with the design. The first problem is secret secret dependency.
The user in this design is responsible for handling secret. User is responsible to managing the secret either is in your local storage or in your wallet. But what if the cash is cleared or whatever. So it's a big dependency on a user. So if user lost the lose this, it's going to be a problem. But uh funds are safe. So even if you use the secret, you are just going to wait for time lock and get the funds back. The second problem is right from beginning user is committing one to one with solver right because the user is locking the funds exactly for the sol for the solver. So that's one to one with the solver right from the beginning. And the third problem is user
has to do transaction in destination chain. Imagine like user wants to get some it in optimism and when they go from arbitum to optimis you ask them to do a transaction in optimism. It's not going to work and relayers here are not going to work as well. So I mean maybe you are thinking oh wait a minute so you can give this secret to anyone else so they can execute the transaction for you. No, it's not going to work because secret user can't reveal the secret before the swap. Because if you reveal the secret to some relayer or someone, what if that someone was the solver itself, if you reveal this secret accidentally to the solver, solver will
go to source chain and claim your funds and swap will not happen. So you can't lose control of the secret. Now we know the problems. So we narrow down to solve this problem and introducing pre-HDLC's. It's basically the same atomic swap concept but with a few nuances. So the first step here user is just committing funds. User is not generating secret. User is is not taking the secret. they are just committing funds telling that hey I want to bridge somewhere like telling the destination network telling the destination amount and that's it and user is committing the funds for all solvers there is no single
solver at this stage once all solvers see this transaction in source chain and the solver who is willing to do the swap generates a secret and calculate the hash of this secret and creates the HTL LC contract in destination chain. So now you have user committed in source network and you have a HDLC solver committed in destination network. So now user's job is to observe the destination network. See the hashlo they just see it in in a contract. So see the hashlo copy that hashlo and apply it to your original commitment. Now you are locked with solver one to one. You don't manage
the secret. Secret is managed by the solver. And once you do this commitment, once you finalize your commitment. Now you have two contracts, same hashlock. All the same with atomic swap. So solver, what does the solver do in this situation? They take the secret, they go to source network, release their assets, and they go to destination network, release users assets. Okay. There is a problem because what if user what if solver doesn't release the user's assets right you solver is incentivized to release their assets but it's not in incentivized to release the user's assets in that case we introduce
a reward mechan me reward mechanism for solvers. So whenever solvers lock in destination they lock 10% more of their original amount and this 10% more is refunded when the solver is actually releasing users fund or is reserved for anyone whoever is willing to do grab that 10% they can go and grab that 10%. By doing this we incentivize solvers to uh incentivize solvers to release the user's fund and introducing you the train protocols.
I already told about contracts that contracts are the first most important thing but if we take the contract the protocol itself has very wide usage because let's say let me go back. So in this step when user is reading the destination network to grab the hashlock how they are reading it they are reading it with RPC calls right so we don't try trust RPCs so how can we do it we can have light clients running inside the browser do not trust the RPC but read the state of the chain through light client so you can actually get the hashlock and apply to your source network but train protocol is
combination of all of these So we have contracts, we have solver, we had wallet SDK which have a native integration with Helios like light client. So everything is this is in one package and we call it train protocol. Demo time. So I have a recording of the demo. Someone told me don't do the recording do the actual demo. So I will try the actual demo. if this works. Of course, let me see new tab.
How to exit this mode? Okay, so I go to app.trend.te. Let's try a demo from Starket mainet to base. Let's connect my wallets. I will connect my ready wallet and I will connect my metam mask. So far so good. Okay. So let's see as I describe the flow here. The first step is to commit to all solvers. So I commit my funds to all solvers. Whoever is ready, whoever is willing to do the this swap, they will just uh come right
in. So I'm committing my transaction. This is transaction in stocknet mainet. Once my transaction is confirmed and I hope it will be soon enough. Okay. Okay. It was very fast but once transaction is confirmed one solver automatically detected my transaction and now reserved assets for me in destination network. And is what is happening in this loading? First we verified it by RPC. We get with RPC the hash log and everything was fine while Helios was verifying it by with light client. Once it verified I don't trust here anyone like no one. So I can just go here finalize my swap. This is the step that
I apply my hashlo to my original swap. I finalized my transaction basically applying my hashlock to uh original contract and swaps is going to be completed in in few seconds. So if you think about this, it just takes around it's not fast enough like I don't know like layer swap like our centralized service it takes like three seconds to do this swap. It takes like 10 seconds but the important thing is that I didn't trust anyone here like literally no one no one had a chance to do anything bad with my money. So this is a transaction it's confirmed. I get more fun.
So to recap what we just saw is we saw train protocol which has no intermediaries only user and solver doing an exchange with atomic swaps. Anyone in this design can join to train protocol. What is necessary is only pre-HDLC contract deploy on your network and the running solver. There is no there are no gatekeepers, no companies controlling this. The only everyone can just deploy the contract, run the solver, everyone will be able to join and everyone will be able to swap.
PHDLC contracts are around 200 or 300 lines of code in solidity are very simple contracts. They are nonupgradable. You just deploy them. You just forget about them. And finally, these contracts can be implemented for any VM. We already did implementation for bunch of VM like Solana, Starket, Fuel, and probably Bitcoin. I'm not sure yet. And there is one more thing. Everyone was talking about private bridging.
Train protocol design allows us to have a private bridging with Aztec. So I can do the demo of this as well. If I go to testnet, but I'm not going to do it. I'm just showing that you can try at home. So if you go testnet.train.tech, you will be able to do the demo. I am showing the video because uh the way Aztec works is they are proving each transaction. So like the whole swaps takes like 30 minutes. So I don't want you to wait here but you can go to testnet.train.te and you can go let's say from ethereum to uh oh we don't have ethereum to a so
we have probably from I don't know anyway. So you can go and trade. So I will show you the demo. Okay. Everything is happening as before. But you will see here. So we are going from Ethereum sepia to AAC test net. We're connecting AC wallet. Connecting my damask. Okay. So everything is almost the same.
So first step is again confirming the details. You basically uh commit in Etheadium network telling hey is there anyone who is going to he who wants to reserve any assets for Aztec. So now solvers in Aztec network are trying to fulfill this. So this part is uh speeden up. So it's not like this. So I will just speed it up faster so you can see. Okay. So once one solver commit lock the funds I do the finalize and I just say okay finalize. But you can see here that I have one more step manual private claim.
Let me speed it up as well. Okay. So once the exchange happened but it's not really finalized yet because you want to keep it private. You don't want the solver to send you the funds. So Aztec solver is preserving the funds for you for the key that you only own. So this claim transaction is right now going and privately executing providing the key and claiming funds privately. So not a solver, no one in between knew that you actually received this fund uh received these funds in Aztec network.
That's it. Thank you very much.