Preparing to kick off shielded set rewards

Existing blockchain networks protect digital assets and the ability to transact, but they don’t protect their data. Namada’s primary purpose is to provide data protection for the existing multichain (ie. many chains), beginning with the IBC ecosystem, (which is bigger than just Cosmos!), then Ethereum and beyond.

Further to Mainnet parameter discussions: Knowable's proposal, we’ll need to bootstrap Namada’s data protection by attracting early deposits for each kind of asset, and we can incentivize deposits by reallocating ownership (allocating new NAM token issuance, or “inflation”) to depositors.

From this discussion I think we’ll want to get three questions answered.

Three key questions

  1. How many assets should we incentivize, initially? and which ones?

  2. What size deposit (in tokens) should we target for each asset?

  3. What maximum inflation rate should we use to incentivize each asset?

Things that I think we should care about

a) maximizing social good while minimizing social bad, by starting small and expanding in a considered, controlled way, eg. setting the IBC limit for tokens per epoch in-flow
b) safety of deposits: the Namada network and protocol will be responsible for any deposited assets
c) testing before doing it on mainnet
d) experimenting by observing and updating often

Things I think we’ll need

Goals: protection for what sized transactions, generally? what kinds of metrics do we want to track and achieve?
For example, I’d like for there to be an ATOM pool that protects users’ data for a 1 500 ATOM transaction, which is much more important to me than protecting the data of a 15 000 ATOM transaction. To provide protection, my fairly uneducated estimate is that we would want 50 to 100 deposits, which we can’t properly incentivize, and an ATOM pool between 8 500 and 17 000 ATOM. I’d love some feedback from folks that have a sense for how to reason around quantifying data protection, maybe @cwgoes @brentstone @adrian

a) mission: perhaps this could start simple and informal, but should get clearer over time… some starting questions may be: which kinds of assets would benefit from being supported by Namada, and why? why incentivize one asset and not another?
b) process: a simple, extensible off-chain process for governing (ie. signalling and deciding support for) new & existing shielded set reward parameters values.

Metrics: tracking and a dashboard for observations

I’d love to hear thoughts from folks like @Daniel @sirouk @preto @cwgoes @awa @brentstone Gian @adrian @Rigorous and any others who may be interested and capable of weighing in on governing, tracking, and displaying metrics in meaningful ways.


Eventually, the bigger the pool, the more effective its protection, as explained in Namada’s mission: The Namada mission.

First, we can measure the percentage of cryptocurrency tokens (by relative market capitalization) that are shielded at rest. This includes, for example, shielded assets on Zcash, Namada, Penumbra, Aleo , Anoma , Aztec , etc. - any well-designed shielded pool counts. Privacy is created by assets shielded at rest, so by and large, more assets shielded at rest means more privacy available for users. We should also measure technical stability: are assets that are shielded remaining secure, or are there incidents of them being drained in exploits?

Conversely, a small pool offers less protection.

  • The transaction size could be capped at a certain percentage of the pool size.
  • Also, transaction sizes should not be idiosyncratic, but a few preset amounts.

The corollary is for the best data protection, the number of different assets should be kept to a minimum. Better to have big ETH and ATOM pools than to support 500 different assets with many having little to no liquidity.

Exotic assets are hard to protect anyway because of trivial chain analysis.

An added benefit of focusing on a few primary assets is that it reduces the complexity and thus the potential breakage of the infrastructure. Imagine keeping 500 IBC channels alive.

Support for other than primary assets can be done implicitly with intents. Protect TIA? Automatically swap TIA for ATOM through the Osmosis Hub, then process it on Namada.

1 Like