Proposal: Native Terra↔︎Ethereum Bridge


Love it or hate it, Ethereum indisputably remains the digital assets hub where most of the DeFi activity takes place. Despite the strong decentralization ethos that characterizes the platform, Ethereum lacks a properly decentralized algorithmic stablecoin that’s proven to work at scale and is instead mostly relying on centralized solutions. For this reason, Ethereum protocols and its user base could represent a huge source of demand for Terra stablecoins. Furthermore, once Terra stablecoins are on Ethereum it becomes much easier for them to get on secondary venues such as layer-2s.

You can already find wrapped UST on Ethereum, but it’s controlled by a centralized custodian and hence makes the entire decentralization aspect vain.

Instead, we want for the trust assumptions of using UST on Ethereum to be the same as when on Terra; i.e. the bridge should be entirely controlled by Terra validators. This requires the implementation of a native Terra↔︎Ethereum bridge at the node’s software level.

To clarify, this doesn’t take away from Terra’s own protocols such as Anchor and Mirror. It makes perfect sense to have core DeFi protocols within Terra itself, but what we really care about is demand for stablecoins and that can come from any platform. In fact we’ll be implementing IBC to bridge to other chains that are compatible with the standard, but this solution can’t be applied to Ethereum for obvious reasons.


On a high level, there would be a contract on Ethereum controlled by a multisig that can mint and burn ERC20s that represent Terra’s stablecoins. The multisig is made up of the current Terra validator set and it’s weighted according to their stake.

Bridging UST on Ethereum would be as straightforward as making an ad-hoc transaction on Terra specifying the Ethereum destination address, the amount of UST that one wants to bridge and the allocated fee paid to process the transfer (as it requires gas for making the contract call on Ethereum). The transaction is then processed and if valid the UST is withheld on Terra side and an Ethereum tx is signed by Terra validators instructing the bridge contract to mint UST and allocate it to the specified address. For the other direction of the bridge, the user calls a function on the bridge contract while depositing UST which is burned on Ethereum and then released back on Terra to the communicated address.
I used UST as example but the process would be the same with any other Terra stablecoin, of course.

While all of this would be rather complex to build from scratch, luckily there already are working implementations of bridges between Ethereum and CosmosSDK-based chains, such as the Gravity bridge. One would only have to start from those and do the necessary tweaking to get the desired result.


Ethereum lacks a properly decentralized and capital efficient stablecoin and UST would offer just that. Given the massive Ethereum userbase and money flow, the bridge could represent a black hole of demand for Terra stablecoins. In order for it to make sense, the bridge should have the same securities guarantees as the platform that issues the stablecoins, and this requires implementing the bridge at the VM level.
Implementing a native bridge isn’t trivial but there already are working designs of bridges between Ethereum and Cosmos zones that can be forked and used as starting point.

1 Like

An ongoing project is Wormhole, a Terra <> Ethereum <> Solana 3-way bridge. The Eth <> Sol connection is already live (despite bad UX design) and Terra will be connected later. Although I’m not sure how decentralized/trustless Wormhole is.

Not only Wormhole isn’t properly decentralized, but most importantly it can’t give you the same security guarantees since it’s controlled by a separate network. A native bridge would be by definition controlled by Terra, and hence there is no difference from using UST on Terra or Ethereum; so much so that the ERC20 wouldn’t even be considered a “wrapping” in the traditional sense. The trust assumptions wouldn’t change because you are on Ethereum and this is extremely important for a decentralized stablecoin to make sense


While i believe we need a bridge that is more decentralized than shuttle, im not sure how important it is for the bridge’s consensus to map to the Terra validator set. The Terra<>Ethereum bridge involves two chains to begin with, and supposing this bridge will be scaled to multiple chains (why not?), then it will inherit the state consensus rules of each component blockchain. In that case, I’m not sure why relying on the consensus rules of Axelar, or wormhole (PoA, but over 30 solana validators) makes the bridge inferior to a bridge that is weighted by the voting power of Terra validatos, assuming that the stakes of said networks are sufficiently large.

I think the fact that they don’t have a stake in Terra directly is quite important. As I’ve mentioned, by using another network the trust assumptions are different and to be more specific they are less clear. With a native bridge the security only relies on Ethereum and on the protocol that produced the actual stablecoin and has the best interest for it, Terra. This is the same thing that happens when two chains decide to communicate with IBC but made a lot more convenient.
It comes down to the fact that there are arbitrarily many wrappings that you could have through other networks but only one by Terra. And that is UST, the others not quite.