Prioritize Building out a Wormhole Integration

Governance Ops Proposal 🗳️
1

Summary

Namada is redefining what privacy means in a composable, multichain world - retrofitting privacy for assets and applications across the interchain. However, if we’re serious about becoming the default privacy layer for crypto, we can’t stop at IBC.

To truly fulfill Namada’s mission, we must extend our reach and push outside of our ecosystem. That starts with one of the most impactful steps we can take right now: integrating Wormhole.

I propose that we make a Wormhole integration one of our top priorities - unlocking seamless, privacy preserving flows for assets and applications across all major chains such as Solana, Ethereum, Base and Arbitrum.

What is Wormhole

Wormhole is a cross-chain interoperability protocol used by 40+ chains, including Solana and Ethereum. Simply put, Wormhole is a messaging layer that enables bridging solutions for token transfers, generic messages, and arbitrary data. It works by observing events on one chain and relaying verified messages to another, making cross-chain asset movements fairly seamless via minting and wrapping mechanisms. Aside from asset movement, Wormhole also supports advanced use cases like cross-chain governance, remote contract calls, and multichain dapps - making it one of the more versatile interoperability layers in our space.

Why Does It Matter For Namada?

Currently, Namada only supports IBC-compatible chains and their assets. A Wormhole integration would unlock a universe of bridged assets from nearly every major chain. Users shouldn’t have to think twice about if the asset they hold can be used privately–Namada is building a privacy layer for all, and Wormhole brings us one step closer to that universal reach.

Why Wormhole Specifically?

Imo it comes down to three factors: TVL, Chain Support and Security

TVL: As of today (April 28nd, 2025) Wormhole’s Portal bridge is hovering around ~$3B in TVL, which is multiples more than a few of its top competitors combined.

Chain Support: Although there are other solutions that rival its current set of chains, after speaking with emerging chains, it’s clear that Wormhole is becoming the default cross-chain messaging layer for new and emerging L1s/appchains, many of which are prioritizing integrations from day one. Aligning with this standard ensures Namada remains compatible with the next wave of blockspace, without needing to reinvent integrations chain-by-chain.

Security: Since 2022 Wormhole has processed ~$60b in total volume, $1.5b in the last 30 days alone. Wormhole relies on a decentralized guardian set (currently 19 validators) that observe events across chains and sign attestations. A quorum of 13/19 validator signatures is required to validate messages. This model assumes at least 2/3 of guardians are honest, and if >1/3 are compromised, Wormhole halts; if > 2/3 are compromised, it’s over :skull:. Relayers are untrusted and only transmit data.

Let’s take the next step in bringing privacy to everyone. Curious to hear what others think!

Disclosure: Veil has no financial interest in Wormhole and has never held or invested in its native token (“W”). This proposal is based solely on its technical and strategic alignment with Namada’s mission.

Source: https://defillama.com/protocols/Bridge
Source: https://wormholescan.io/

12 Likes
2

To me, the most important focus for Namada right now is to support as many assets as possible, and reach out to holders of those assets to support those who are interested in shielding their assets using Namada’s MASP – growing shared privacy for everyone. Different users may choose to trust different bridges (or not), and that’s fine – it’s not our job, in my view, to make those decisions on behalf of users, but rather to support them in whatever decisions they make, and maximize the ease / minimize the risk of using Namada.

I’m in strong support of this proposal, and Heliax stands ready to provide technical implementation work!

8 Likes
3

Thanks a ton @Veildev for starting this conversation. I strongly support this path forward for Namada as well. It is critically important to integrate with ecosystems beyond Cosmos, and Wormhole does increasingly seem like a strong standard. I think this should be a high priority after Phase 5.

6 Likes
4

How is this even possible, given that Namada doesn’t support CosmWasm? Will this be integrated at the protocol level?

3 Likes
5

Personally I’m excited about the opportunity to expand our ability support and create within the Ethereum ecosystem, as well as others like Solana. If Wormhole is the most promising first step, Knowable is in support of this.

Thanks @Veildev for championing this :flexed_biceps:

4 Likes
6

I have some concerns here, some of them relate to process and some to the subject at hand.

First concerning the subject matter:

I am not sure wormhole is the number one bridge in volume. My understanding is Stargate (Layer0 flagship) did 3.5 B last month, though admittedly hard comparatives are hard to come by (the source linked by @Veildev does not seem to include that bridge at all - ideally we would compare on protocol and not bridge basis). I have heard some voice security concerns on wormhole and would maybe like to see more considered reflections on whether it should be the first messaging protocol to bridge against. I also note in this connection that as I mentioned in the discord a few times, polaris seems to me to bring a lot of what we need, and seeing as we “come from” the same ecosystem, it might be a more obvious candidate for first choice.

Regarding @cwgoes comment,

I feel we need to be more responsible with ensuring safety than what I (maybe mis) read from this. I believe most end-users neither should have nor necessarily have the technical capabilities to make these assessments, and thus safety above all should be a big priority here from protocol side imo. (I might be overinterpreting you here @cwgoes)

For process:

I understand from discord that there is already now a signalling proposal on-chain for this. I think this is rushed.

While I realize we have no formal procedures for governance proposal process yet (I think this may motivate me to finalize and put forward some stuff I shared with some of you a while back), I think we should have longer discussion periods before putting a signaling vote on something of this magnitude. I don’t mean to be super conservative, but I feel this is slightly rushed, particularly given some cautious voices have been raised to this.

preto.

3 Likes
7

I echo @preto’s concerns. I am surprised at Wormhole’s statistics - there are a lot of trust assumptions underneath. Ideally trust-minimized platforms are used such as Union, but those are not fully crystallized and battle-tested yet. I guess we have to use the platforms that are actually functional as a stopgap solution or do you see Wormhole as a permanent integration?

image
image1536Ă—1024 76 KB

(source: https://x.com/0xwannabeintern/status/1916276068970881135)

4 Likes
8

Thanks for the considered responses @preto and @Rigorous. I wanted to share a few thoughts, and I have a few questions.

Thoughts

My statement was brief, to expand a bit on my current position (happy to hear disagreements):

  1. Namada should not support assets or connect to things that are obvious scams (this doesn’t apply to any bridge we might reasonably consider here, but it would have applied e.g. to Terra/USDT, at least given the benefit of hindsight).
  2. Otherwise, Namada should be pretty liberal in connecting to chains and assets – not every user wants to use every asset or chain, but the more users using the MASP, the more privacy for everyone. At the protocol level, we should use IBC rate limits and/or similar circuit breakers (as is already done) to bound the risk should something go wrong.
  3. We should aim to help users understand what trust assumptions they’re making and what risks they’re exposed to. Typically, this would happen at the interface (e.g. Namadillo) level, with warnings, safety tips, “advanced mode”, links to external analyses, etc. The choices are ultimately always up to the user, but we should inform them as best we can (in a neutral fashion).

Would you generally be in agreement with that, or do you have a different take?

That’s fair, and I’m looking forward to seeing what you’ve been cooking up. Wormhole was mentioned before, and didn’t seem to generate any controversy then, but perhaps this was not very visible. On the other hand, from the Heliax side, we have development resources available (not everything can be used to speed up phase 4/5), and we’d like to get started on something – and I don’t think it’s in the community’s interest for us to spin our wheels idling either. Speed matters, especially in the current environment, whether we like it or not. However, I think that these goals should be able to be synthesized with thoughtfully designed process – perhaps a kind of signaling vote that is more specifically “exploratory”, for example – but I’ll hold off on brainstorming there until you share what you’ve been working on! Another process that I imagine would be helpful is a way to surface general community sentiment around immediate priorities (prior to signalling votes) that Heliax or other entities could use as a signal to inform how they focus their time.

I’m also excited about Union, and I think that we’ll definitely want to support different bridges in the future – ultimately, it’s up to what users want to use (and they, in turn, will care about which options are the safest, cheapest, and easiest, I expect).

Questions

Do you have a good data source for this? I looked quickly on DefiLlama but it wasn’t super clear.

Is Polaris a bridge? I thought it was a multichain DEX UI. Do you mean this Polaris, or another one?

3 Likes
9

Thank you. Let me answer some of your questions and expand a bit on my position:

When it comes to the three points you list first, I think my position leans towards being more selective in only integrating bridges we consider trustworthy, and not leaving that choice up to the end user. (of course these things are on a spectrum and not completely binary)

Re process, I understand the want to start and integration and it’s positive there are dev resources available to scan outside of core tasks. With regards to my comments on governance process specifically, I was not expecting from how this thread started that there would very quickly be a governance proposal up for vote. I think we should have procedures that ensures more clarity on “are we discussing a governance proposal about to be put up” or “are we just discussing an idea for the chain etc”, if that makes sense. This is reflective on a few recent proposals that have felt very sudden. I am open to a difference of opinion here, but would be good to have some guidelines as to ensure there is proper time to discuss and consider proposals before they are put to vote. (this is not to any fault of veildev, it’s just I think we need more clear boundaries on this aspect)

Admittedly I do not have a very proper source, this comes from a retweet of the X of the L0 ceo, so can’t say it’s very objective or detailed:

https://twitter.com/0xlamps/status/1918239952854499838

It has frustrated me too that I couldn’t find any good comparative sources on a quick look, but the information above would suggest we may need better comparatives before settling on something. I am perhaps somewhat partial to L0 over wormhole myself, but that should not stop us I guess. However a better comparative analysis between the two biggest players rn, both in terms of volume and security would be good. (I know L0 has in the past made claims to having better security over wh, but that’s a while back and obviously not impartial).

I mean this polaris yes. I may have been a little too quick there. I don’t know if they can offer what we need, but I think the lines between crosschain dexes and bridges are starting to blur a little. You are correct on classification I think, strictly speaking I guess both wormhole and L0 are cross-chain messaging services(?) which I guess is somewhat broader/more general in scope. Could we have a brief rundown of usecases we are looking for here? With what I had assumed, I do think polaris would give a lot of that from the end-user perspective, but probably what we are looking for is something more universal in scope?

3 Likes
10

My only concern with Wormhole is the previous hack, but that could happen to any protocol including Ibc. Other than that I believe it is a solid option. we should also keep an eye on Union and may consider adding it later if it attracts a good number of chains and volume.

4 Likes
11

I think we definitely share the goal of protecting users. I’m not convinced that choosing whether or not to do protocol integrations is a good way to do that, because I think it comes with tradeoff decisions that we simply cannot make on behalf of users because we don’t have the right information, along two axes: heterogeneous user preferences and heterogeneous actions. Let me explain a bit:

  1. Namada will likely have users with highly heterogeneous security and asset preferences – not everyone will want to use every asset, and not everyone will want to use (or trust) every bridge. If we only integrate bridges that we (some elite-ish group of developers or governance participants) consider highly trustworthy in all scenarios, we’re making that decision on behalf of Namada’s users, and for many of them, we’re probably making the wrong decision, since we don’t have particularly good information about who wants to do what (in fact, the best way to collect that information is to integrate something and see what the usage is like). I’m still against integrating anything that we have good reason to believe is misrepresenting security / a scam, as I mentioned above, but I don’t think we can set the bar higher than that without making the wrong decision (with respect to at least some users).
  2. Whether or not a bridge is secure enough for use is not a question just about the bridge itself – it’s also a question about how and for what (especially what amounts) you use it. For example, personally, I wouldn’t trust Wormhole with my life savings, but I’d probably trust it with a few hundred bucks for some payments or shielding assets from elsewhere – if I use it in the latter way and the bridge has an issue, it would be pretty annoying but not catastrophic. Only the users have the information to make these kinds of decisions – there’s no way we can allow one but not the other, at least at the protocol level – we can, for example, have warnings for high-amount transfers in Namadillo or things like this which get closer (and this is part of why I think the interface level is much more useful for user protection, because the interface has more information about what the user is actually doing than the protocol does).

This sounds potentially helpful, do you have a proposal for such guidelines or procedures? That sounds like it should be a separate (but important) discussion.

For sure, I think this would be a great resource to assemble (maybe by someone who has more context on L0 – I personally do not). Starting work on a Wormhole integration definitely does not prevent us from also working on other integrations (such as L0) in the future as well.

As far as I understand, Polaris is just a UI, I think we’d still need to integrate bridges (or messaging services) in order to allow for specific actual asset flows. I could be wrong, though – is it open-source yet? I skimmed the Osmosis GitHub but couldn’t find it.

3 Likes
12

I support namada integrating wormhole as the first external bridge, a fast path to cross-chain liquidity and user adoption.

But the core principles must remain: privacy, decentralization, and security.

Suggestion: ensure transparency around the security model, apply initial limits, and commit to a long-term roadmap toward IBC/zkBridge.

4 Likes
13

image
image902Ă—1230 225 KB

3 Likes
14

Thank you for attempting to completely demolish the value of my comment. This is simply uncalled for.

15

I’m going to leave this thread.

16

meme gave me a chuckle, and i get that process-only pushback without fresh data stalls us. @preto’s critique is valuable—I appreciate it—tho it should land like a guardrail, not a roadblock

pose one clear question, bring the evidence, and help drive to a decision so we don’t drift into bikeshedding

1 Like
17

Agree with connecting with as many assets and chains as possible, so Namada can become the Shielded Hub for everything.

How can risk be contained other than rate limiting? What are the risks for Namada as a whole? Imagine Namada had integration back when Wormhole was hacked and the wrapped tokens became worthless. Just taking Wormhole as an example, could happen with any IBC token.

  • Wormhole assets in Namada may get stuck in Namada because the backing has been drained (Like how tokens in Evmos were stranded / worthless when Nomad Bridge was hacked) - no risk to non-Wormhole users
  • Attacker could acquire worthless tokens for cheap and get outsized MASP rewards
  • Anything else?
3 Likes