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
-
How many assets should we incentivize, initially? and which ones?
-
What size deposit (in tokens) should we target for each asset?
-
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
Governing
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.