NEW - Proposal: Hyperlane Integration on Terra Classic — Multichain Connectivity with Ethereum, BSC, and Solana

General
1

Proposal: Hyperlane Integration on Terra Classic — Multichain Connectivity with Ethereum, BSC, and Solana

Summary

This proposal seeks approval to deploy the Hyperlane protocol on the Terra Classic (LUNC) blockchain, enabling decentralized cross-chain bridges with Ethereum (ETH), Binance Smart Chain (BSC), and Solana (SOL).

The project also includes the customization of a Hyperlane Warp UI, fully compatible with CW20 tokens from the Terra Classic ecosystem.

Deployment will begin immediately after this proposal is approved, and payment will only be made after full deployment and verification in production.

Motivation

Currently, official bridges such as Wormhole have discontinued infrastructure support for Terra Classic.
As a result, native coins (LUNC and USTC) and CW20 tokens have lost the ability to move across blockchains.

This left Terra Classic isolated within its own liquidity bubble, restricted to local DEXs and unable to access wider global markets.

Hyperlane offers a modular, decentralized, and community-controlled interoperability protocol.
Its infrastructure — validators, relayers, and configuration — is fully owned by the community, eliminating any dependency on third-party providers.

Why Hyperlane

Hyperlane enables secure cross-chain communication, token transfers, and smart contract calls between blockchains — all without intermediaries.

Hyperlane is already connected to 130+ major chains and has processed over $10B+ in bridged assets,
securely validating over 10,000 cross-chain asset transfer messages daily.
This makes Hyperlane a proven, reliable, and industry-recognized interoperability solution.

Key Benefits

  • Fully decentralized infrastructure operated by the community
  • Integration with Ethereum, BSC, and Solana
  • Expanded global liquidity for CW20 tokens
  • Support for native assets like LUNC and USTC, and CW20 tokens such as Juris, Sele, Terra, WESO, and Cookie

Access to Global Liquidity

With Hyperlane, CW20 tokens can be wrapped and listed on major DEXs:

Network Potential DEXs
Ethereum Uniswap, Curve, Balancer
BSC PancakeSwap, Thena, Biswap
Solana Jupiter, Raydium, Orca

This integration will allow Terra Classic assets to reach global markets, breaking the liquidity bubble currently limited to the network’s internal DEXs.

Validators and Participation

A quorum of four validators has already been formed to validate the Hyperlane deployment voluntarily, without any monthly compensation.
These validators are:

  • Vegas Node
  • StrathCole
  • Highstakes.ch
  • LUNA Classic DAO

This quorum provides the minimum validator requirement to start the decentralized bridge operation.
If any validator becomes inactive, the community may vote to replace them, ensuring continuous and reliable operation.

KYC and Security

To deploy wrapped versions of LUNC and USTC on Ethereum, BSC, and Solana, the project will undergo KYC verification through SolidProof — a well-known blockchain audit and verification provider.

Additionally, multi-signature accounts will be established for bridge contract management, ensuring decentralization and transparency.

The proposed multisig signatories are:

  • The proposer (Igor Veras)
  • The four validators listed above
  • Two developers from the L1 core team

This configuration ensures that all critical actions involving bridge management and wrapped assets are transparent, secure, and community-aligned.

:warning: Note: Since the KYC process may take additional time, a separate payment proposal will be submitted only after the KYC verification is completed.
For Layer 2 (L2) deployments, KYC is not mandatory, but it is being performed to reinforce community trust and avoid future discussions about the legitimacy and safety of wrapped LUNC and USTC assets.

Technical Overview

Implementation includes the following steps:

  1. Deploy core Hyperlane contracts — Mailbox, Interchain Gas Paymaster (IGP), ValidatorAnnounce, and ISMs
  2. Configure four independent validators (already established)
  3. Set up relayers to handle cross-chain message delivery
  4. Create bridge contracts for CW20 ↔ ERC20 / BEP20 / SPL token transfers
  5. Develop and customize the Warp UI for Terra Classic integration
  6. Publish complete documentation covering installation, validator configuration, and warp creation

Even with full documentation, Warp creation and customization require advanced technical knowledge and should be managed by experienced developers.

Minimum Infrastructure Requirements

Based on Hyperlane’s official documentation:

  • 2 vCPUs
  • 2–4 GB RAM
  • 4 GB Storage

Each validator must maintain a KMS (Key Management Service) for private key protection.

Warp UI Customization

A custom fork of the official Hyperlane Warp UI will be developed to support Terra Classic:

  • Accurate CW20 token balance tracking (via Cosmos SDK)
  • Automatic approval using transfer_from
  • Smooth visual integration between Terra Classic and other networks
  • A modern, open-source, and transparent interface accessible to all users

Full documentation will be provided, enabling other developers to:

  • Deploy their own Warp UIs
  • Maintain or extend existing ones

Future Network Expansions

The initial deployment will include Ethereum, BSC, and Solana.
Future proposals may extend bridge connectivity to other networks supported by Hyperlane, including:

Arbitrum, Avalanche, Polygon, Celo, Gnosis Chain, Moonbeam, Optimism, Fantom, Harmony, and Aurora.

Budget

Item Description Amount (USD)
Hyperlane Infrastructure Full deployment of contracts, validators, and relayers $9,000
Warp UI (Fork) CW20 integration, customization, and documentation $3,000

:light_bulb: Total Initial Cost: $12,000

Timeline

Phase Description Duration Status
Research & Testing Over 3 months of local development and testing :white_check_mark: Completed
Deployment Contracts, validators, and relayers setup 30 days :hourglass_not_done: Pending
Warp UI Interface integration and customization Parallel to deployment :hourglass_not_done: Pending

Payment Conditions

Payment will only occur after full production deployment and public verification by the community.
A separate payment proposal will be created after KYC completion.

Risks and Responsibility

  • Hyperlane is an open-source, community-maintained protocol
  • The proposer acts as the developer and deployer, not the protocol owner
  • Bugs or vulnerabilities in Hyperlane’s core code are outside the proposer’s control
  • Deployment will strictly follow official documentation and recommended best practices

Expected Impact

  • Restores interoperability lost after Wormhole discontinuation
  • Establishes a community-owned decentralized bridge
  • Expands Terra Classic’s liquidity reach into major DeFi ecosystems
  • Increases visibility and adoption of LUNC, USTC, and CW20 tokens
  • Strengthens innovation, resilience, and autonomy of the Terra Classic network

Conclusion

The Hyperlane integration marks a key milestone toward restoring interoperability and liquidity for Terra Classic.
With a community-operated infrastructure, the network gains true independence and sustainability.

A modest $12,000 budget and a 30-day deployment will position Terra Classic back into the global multichain ecosystem, fully controlled by its community.

Author

Igor Veras / Technical Team
Timeline: 30 days
Total Budget: $12,000
Payment: Upon production deployment and community verification
KYC: Solidproof (In progress)

2 Likes
2

Thank you for your continued support and dedication to this chain and for creating and putting forward ideas that collectively make this ecosystem stronger and resilient. Also for taking the steps to fulfill the KYC process making it transparent and trustworthy for all participants involved. :handshake: we support this initiative due to 2 key reasons.

1-Restores interoperability

2-Expands Liquidity and Market Access

3

Lunaclassic doesn’t have a central development team. Luckily, we have Frag. What are the criteria for choosing multisignature signers, and why can’t validators who want to sign blocks do so? There’s already a multisignature wallet; I don’t know why that was included in the proposal, especially since names are kept anonymous. Furthermore, if problems arise, no central team will be recognized, leaving you without support, just like what happened with Wormhole.

1 Like
4

Is it a wallet and not a smart contract? What is the function of that wallet? It seems quite strange to me.

5

Good afternoon, and thank you for your questions.
First, I’d like to clarify that Hyperlane bridges are very different from “wormholes.” The main distinction is that the entire infrastructure now belongs to the community and is fully decentralized.

The multisignature wallet will be used only for the wrapped tokens on BSC, Ethereum, and Solana — in other words, it will serve to deploy LUNC and USTC on those blockchains. If, at some point, changes are needed due to the IGP or ISM, it’s important to have multiple people able to perform those updates. Including Frag is perfectly fine.

I only requested two L1 developers, since they are responsible for maintaining the blockchain, and we also have Strathcole involved.
The selected validators are those who will be running Hyperlane, and I’ll provide full support for the installation.

The goal is to make the blockchain more secure and not dependent on a single person.

6

There’s nothing strange about it.
Have you ever deployed a contract on a blockchain before? If not, you should know that to deploy a contract, you need an admin account, and if any change is required in the future, only the creator of the contract can make it.

These multisignature wallets are only for Ethereum, BSC, and Solana — meaning there would be three multisig accounts, used only if LUNC or USTC are added to the bridge.

In the case of CW20 tokens, the token owner is the one responsible for deploying it — not me, and not those multisignature wallets.

7

If we follow feedback from Raider and Strath re USTD prop, multi-sigs are not safe for our blockchain and are not decentralizing enough. Especially for a “chain owned protocol”.

Therefore I expect a NO from them on this

8

I believe you misread the proposal Strathcole is one of the validators.

9

At this point, I agree with him, but these are different things. To have a warp of LUNC or USTC, it’s necessary to deploy on the destination network — in this case, the BSC network. It involves creating a synthetic token, meaning the account that created it cannot withdraw the funds; only the recipient can.

As for having a multisig account, it’s because if I die or if any modification to the warp is needed — such as adding or removing validators or adjusting gas prices — others would still be able to make those changes. That’s what this is about.

10

I agree that having a multisig for contract admin - not only to provide redundancy but also to ensure any change is approved by multiple people, is very good practice. This is not the same scenario that was the cause of the Hexxagon team’s concern with the USTD proposal.

1 Like
11

A multisig to manage the contract? A multisig is a wallet, not a contract. If you want to reduce risk, multisig members should have the least possible relationship. In fact, the members of the community multisig haven’t even been elected by the governance. We’re talking about decentralization, security, or the possibility that if something happens, four friends could drain the funds. In any case, it’s illegal. You can’t move decentralized funds, and governance doesn’t apply here. You have to file a request with the SEC. Besides, you shouldn’t change any parameters in a Bridge. But show me a single blockchain that has implemented this Bridge and has a multisig. Stop trying to have control and power, thank you.

12

It seems that what’s being requested here is that four people who have daily conversations, and some who directly manipulate others, should have the power to do something illegal. Obviously, there’s no need to authorize a multi-signature account to drain funds, much less to have signatories whom most people don’t trust, and without KYC. NWV.

13

Show me an example of a blockchain that has created a multisig for this, thank you.

14

Look at the admin account of the Terra contract — it’s a multisig, and no matter what you say, they have a high score on Certik. That’s what security means, and unfortunately, you don’t know what you’re talking about.

1 Like
15

Even worse — draining funds? You don’t even understand how the protocol works or the reason for creating a synthetic contract on another blockchain. It’s that simple — you can think whatever you want, that’s your right, but learn how the technology works before calling others scammers.

1 Like
16

Chill Morty, all is good frendo!

I would remind you that this is @igorveras1 ‘s proposal. I (nor Hexxagon) are in no way associated with it.

I clarified my general view of using multisigs as contract admins based on @LunaRocket ‘s comment and I stand by that view, although of course you are free to disagree. There are numerous examples of bridge protocols that use multisigs as contract admins (e.g. Wormhole, Across Protocol, Gnosis Chain to name just a few).

As for Hyperlane, as I understand, it uses a “mix and match” modular security model and I suggest you @mortadelo converse directly with @igorveras1 on this topic if you are interested in the precise details of how he intends to implement it.

I have never tried to have it, or wanted it. Thank you.

17

After careful evaluation, we choose not to support this #LUNC proposal. We are in favor of the Hyperlane integration, but we are concerned that the multi-signature signatories are designated by the proposer instead of being elected through an open community vote.

18

I would like to express my deep gratitude to the entire community and to all the validators who participated in the vote — both those who voted yes and those who voted no. Democracy is one of the most important pillars of our ecosystem, and each vote reflects the vision and responsibility that every member has for the future of our blockchain.

If there were votes against the proposal, I understand that this is part of the democratic process, and I recognize that in some areas I may not have been clear enough. I’ve learned from this, and in future proposals I will make sure to communicate every detail more clearly so that everyone can vote with full confidence. I hold no hard feelings — on the contrary, I appreciate the care each validator took in analyzing the proposal thoughtfully.

Now we move forward together to a new level. With this implementation, we are opening the door to significantly increased liquidity, new integrations, and greater opportunities for our entire ecosystem. This is just the beginning of a new phase for our blockchain.

Thank you all for your trust, responsibility, and collaboration. I will continue working with transparency, dedication, and complete commitment to the community.

2 Likes