Mandragora’s open to keep the momentum going with the addition of new and key IBC assets, by making respective testings on Campfire/Housefire testnets, and then coordinate our strong set of IBC relayer operators on mainnet to support those assets there.
Looking forward to @Veildev’s feedback and other community members on this too.
Are we looking this as an initial step when it comes to integrations (shielded actions), or just for having those assets available in case community want them to be part of the SSR at some point in the upcoming future?
I think we need to have clear what would be the potential main purpose of such an additions, whether at this point or in the upcoming future.
Regarding the 1st case, we would need a decent amount of tokens at rest on MASP so as to offer enough data protection for specific use-cases/dApps - this needs a standard framework to gather effectively communities’ feedback in that matter.
I have had on mind and prepared this initial draft a while ago (would be nice to know what you guys think @cwgoes@Gavin@brentstone and community in general):
Bootstrapping data protection on Namada’s MASP to offer shielded payments on other protocol’s use-cases/products.
How to do so without the need to incentivize nor add a specific asset to the SSR (shielded set rewards)? By asking for feedback/proposing on their respective forums/community agoras the idea to use a certain amount of tokens of their treasury/community pool so as to make shielded payments a reality (by this I mean: the more assets at rest, the more data protection it could be offered - this would need to be calculcated in some way - let’s say an avg anual payment for a dVPN app subscription is ~$20-30-40, we need at least the enough amount of tokens at rest to effectively obfuscate these in/outs).
What pros that it has? A portion of their treasury is within Namada’s MASP at rest - providing data protection for their products.
What cons that it has (for now)? We would need a DaoDao-like platform for Namada so as to make easier for a multisig account to control the funds on Namada’s MASP side - as there’s already DaoDao or multisig-like platforms to control the funds on Cosmos based chains.
I’m perhaps missing something, so let’s see if we can make it clearer and stronger together if the community sees this framework a viable and feasible one.
Agreed that we should begin identifying purposes beyond simple shielding, @Daniel. In the meantime, people (like me, selfishly ) may want simple shielding. It could be worth making a batch of tokens based on IBC transfer volume.
With IBC Eureka Ethereum is now connected to IBC, therefore sounds like ETH and other major Ethereum assets should be top of the list to incentivize on the MASP?
Other IBC tokens that should be considered: Story IP, Berachain (?), Injective INJ
With IBC Eureka Ethereum is now connected to IBC, therefore sounds like ETH and other major Ethereum assets should be top of the list to incentivize on the MASP?
Lovely discussion here! Just a few quick comments:
In terms of “dollar access”, I think it’d be nice to open up deposits for both USDC and USDY from Noble, which are simple tokenized dollars and treasuries, respectively. Personally, I’m interested in using these to offer some microgrants disbursed through Namada (but in USDC).
In terms of “privacy friends”, supporting all of UM (Penumbra DEX), NYM (Nym mixnet), and NIL (Nillion) would make sense to me (although I know relatively little about Nillion).
In terms of “major crypto assets”, BTC, ETH, and SOL are a clear top three for me (not an endorsement of these networks, but certainly in terms of adoption). I think we should carefully consider which bridged versions of these we would want. Osmosis has wrapped multi-bridge BTC and ETH which might be a good option in the short-term at least (in no small part because it would make shielded swaps with those assets really easy). I’m not sure what makes most sense for SOL – maybe Osmosis SOL to start, and later Wormhole-SOL once Namada has Wormhole support?
@Daniel and @CosmicValidator - great points / questions, aim to follow up regarding those soon.
I think this is a great starting point — appreciate everyone’s contributions so far. @Daniel brings up an important point about being intentional with asset support and timing, especially if we want to drive toward a specific outcome. As we all know, this space is incredibly narrative-driven, but there are also some core assets that help grow the overall mindshare pie for any ecosystem. The most effective approach will likely be a consistent combination of both: foundational assets and opportunistic integrations.
I haven’t written this down formally before, but when it comes to asset support, I’ve been mentally bucketing potential additions into a few categories (somewhat aligned with how you framed it, @Gavin):
Mindshare Assets (BTC, ETH, SOL)
These are the most widely held assets, and beyond just liquidity, they bring large developer ecosystems - potential users/devs with resources that could build atop Namada or integrate it into their apps.
Mindshare Derivatives (stETH, JitoSOL, LBTC, etc.)
Give users exposure to the same top-tier assets but often come with more utility-focused users. Because these users are already seeking yield or utility, less incentivization is needed to attract and retain.
Low-Lift Assets (UM, Agoric, Juno, etc.)
These might not move the needle in terms of metrics like deposits or shielded volume, but their ease of integration still makes them worthwhile, especially to fill gaps in integration cycles or keep momentum during quieter periods?
Hot/New Assets (BERA, Monad, Initia, etc.)
I see these as high-upside, high effort integrations. New ecosystems are typically well-resourced and eager to experiment. It would be awesome if the MASP could be one of the first places they have to interact with their assets.
Stables (USDC, USDY, etc.)
Fully agree with Chris here, some form of “dollar access” should be a top priority. USDC via Noble feels like the right move to start with, especially considering the relative ease of integration. It also will open to door for pretty unique privacy-preserving use cases (payments, grants, defi).
One thing that would be really helpful is better visibility into integration timelines or complexity — both for current and potential assets based on Heliax’s current and projected workload. I know bridge support is a blocker for some of the assets listed above, but assuming there’s an integration, it’d be great to understand how timelines might differ across these categories.
Lastly, as @Daniel mentioned, deciding on new asset incentives will be key. I’d lean toward letting the current set of incentivized assets play out before committing to more. As I mentioned in a previous post, there’s a good chance that within a few weeks we’ll hit some initial incentive caps or we won’t. Either way (whether caps are hit, incentives taper off, or some assets underperform), we should be able to free up incentives to reallocate, rather than necessarily adding net new rewards. I’m not opposed to additional incentives, but it makes sense to wait and see what the data tells us before expanding further.
In terms of ETH - stumbled across this recently: https://railgun.org/ - looks interesting in terms of a friendly eth project. They even use the shielding terminology (haven’t looked at the code itself)
) may want simple shielding. It could be worth making a batch of tokens based on IBC transfer volume.
