Phase 3 Proposal Discussion

As Phase 2 is coming to a close, I’d like to open up the discussion for the governance proposal to transition to Phase 3 of the mainnet activation.

This proposal looks to enable transparent and shielded transfers for governance-enabled IBC assets, establish gas costs for non-native assets, and set initial rate and mint limits for each asset. Selecting the right set of assets, alongside these foundational initial parameters, is important to not only ensuring a smooth launch, but also robust user participation.

After some discussion from our previous forum post, I’d like to kick-off the discussion by proposing the following initial set of non-native assets for Phase 3 support:

Asset Selection

  1. ATOM (Cosmos Hub)
  2. OSMO (Osmosis)
  3. TIA (Celestia)
  4. INJ (Injective)
  5. stATOM (Stride Liquid-Staked ATOM)
  6. stOSMO (Stride Liquid-Staked OSMO)
  7. stTIA (Stride Liquid-Staked TIA)

These selections prioritize interoperability, ecosystem relevance, liquidity, and ease of integration to ensure Namada’s Phase 3 launch is impactful and well-supported.

One additional note: there are some inherent constraints on which assets can be supported from day one, so this proposal reflects our best attempt to select a feasible set at launch. However, this initial selection criteria isn’t set in stone. Once the protocol is fully live and governance is able to weigh in more broadly, we expect the list of supported assets to expand significantly—and for that process to be driven by the community’s priorities rather than just the considerations we’re using here.

Gas Costs and Rate/Mint Limits

The proposed gas costs aim to balance usability, scalability, and fairness in the system. However, given the dynamic nature of market conditions, gas values will require periodic updates on an ongoing basis. By introducing uniform Rate Limits (~$1M per epoch) and Mint Limits (~$5M), we aim to reduce cognitive load for governance and simplify initial implementation. Rate Limits cap the maximum transaction volume per epoch to mitigate risks of abuse (ex: flooding the MASP with high-volume transactions, while ensuring a manageable pace of adoption). Mint Limits restrict the total amount of any asset that can be introduced into the MASP, helping to control supply and safeguard against unauthorized minting. Additionally, enabling gas payments in non-native tokens allows the network to function smoothly during the initial phases since NAM transfers won’t be enabled until Phase 5.

We think it’s important for NAM to be the most cost-efficient option on Namada, supporting its role as the native asset. The minimum transaction cost in the system is set as 0.05 NAM. This structure aims to keep NAM transactions very affordable. By positioning NAM as the cheapest option we hope to encourage its use as the primary means of gas payment.

For most of the whitelisted non-native assets above, the minimum gas payment that the current protocol can support is 0.05 units, which is about $0.20 - $0.30 for ATOM, stATOM, TIA, and stTIA. We propose bringing the cost of gas for all of the non-native assets in line with this approximate range. Thus, we propose setting parameters such that the minimum cost of gas for a Namada tx in each of the non-native assets is:

  • 0.05 (ATOM, TIA, stATOM, stTIA)
  • 0.5 (OSMO, stOSMO)
  • 0.01 INJ

Particularly, the relevant parameters will set a cost per unit of gas for each non-native asset.

Here’s a link to the initial draft of the Phase 3 WASM proposal code (it is not compiling just yet). Please note that the estimated inputs are based on current market prices and are subject to slight adjustment in the finalized proposal.

Looking forward to hearing everyone’s feedback and suggestions!

17 Likes

TLDR of the above post about initial non-native token parameters:

  • Proposed initial set of whitelisted non-native assets: ATOM, OSMO, TIA, INJ, stATOM, stOSMO, stTIA
  • Non-native token gas payment such that the minimum tx cost in a non-native asset will be in the approximate $0.20 - $0.30 range (whereas it is 0.05 NAM for native asset)
  • Global mint limit of ~$5M of a given non-native asset allowed into Namada
  • Throughput limit of ~$1M of a given non-native asset to flow into/out of Namada per epoch
7 Likes

Ill be thinking about this a little bit but I just want to point out that 0.05NAM is what we are using in Namadillo as a default fee and it’s an overestimation by 2/5x.
Btw, is there a reason why we want to incentive LS tokens?

1 Like

@Fraccaman Incentivizing the LS tokens is advantageous because there are really not other opportunities for rewards on these tokens anywhere else in the ecosystem. We don’t have to compete with other rewards opportunities here and any holders of these tokens looking to farm rewards with them should put them in the MASP.

For the standard tokens like ATOM, etc, holders need to decide whether they want to stake or seek out the incentives in the MASP for example.

P.S. I don’t think you’re being entirely correct here on the NAM fee. The minimum fee for any tx paid in NAM, whether from the CLI or a front-end, is currently 0.05 NAM in all situations due to the gas_scale = 50000.

1 Like

So start preparing relayers then? =)

Question. Why Injective? I mean what was the criteria for picking those? Who is the TA here? Why not Axelar then?

I would highly assume that the main chunk of inejctive / osmo users are the same people. There are a number of cool chains on Cosmos. i.e. orai or gravity bridge.There are also privacy and/or privacy orientated chains, chains, such as nym, secret, etc

Sorry. Just trying to grasp the logic for myself here.

EDIT: i found the discuss, missed it, my bad

1 Like

@brentstone ls tokens makes sense, for the gas fees I guess my bad

1 Like

This looks good to me, however I think if we are looking to add sTIA it may also make sense to include the other popular staked token milkTIA? It currently has about 2x the amount of TIA staked in it than sTIA.

Since milkTIA is native to a different chain from stTIA, stATOM, and stOSMO, it might make it a bit tricky to set up the additional open IBC channels. However, we can always consider adding milkTIA in future proposals.

I’d like to suggest reserving the first open IBC client for Penumbra. Both Namada and Penumbra have shielded pools, and connecting them could really enhance privacy for users on both platforms.

1 Like