Hi! 
I’m Gavin, I’m responsible for the Knowable team, which includes Spork and Dave 
We’re considered one of the core Namada teams, and we work alongside (but independently from) the founding teams, Heliax and the Anoma Foundation, almost exclusively on Namada and a bit on Anoma. We’re actively seeking to grow Namada’s set of core teams: join us!
If you’ve spent time in the Namada community, you’ll likely be familiar with some of our work. Together with CryptoDruide and a number of friends/supporters, we’re founding a Namada community collective called Luminara, which we aim to grow to support a core Namada community. Having a strong core community will be essential to stewarding Namada’s vision, mission, roadmap and priorities, and perhaps most importantly, our culture. Today we’re proposing an initial set of parameters for the Namada protocol ahead of our anticipated mainnet launch 
The NAM token 
Tokens are often conflated with money because they share some of the same properties. We think of NAM as something that will be more than a financial asset, because it will represent material ownership of the Namada network. NAM is designed to enable the holder to permissionlessly transact on the Namada network (and networks that Namada serves). We are expecting the Anoma Foundation to propose a set of Namada addresses with corresponding NAM allocation amounts. Together with the parameters we agree upon, Namada validators can make the genesis files needed to launch the Namada mainnet.
NAM holders can choose to “stake” NAM (ie. help secure the network), and to vote on proposals to coordinate decisions and actions about the network and community. If a holder has 500k NAM and the supply is 1B, for example, this holder owns 0.05% of the Namada network. If the supply increases and their holdings do not, the holder loses proportional ownership. Namada will increase its supply, issuing new NAM to incentivize three kinds of things: staking, public goods / public goods provisioning, and shielded set deposits. Often people refer to this new issuance as “inflation.”
Incentivizing staking 
Namada’s protocol guarantees will be secured economically. We think that there will need to be adjustments, depending upon how much value is secured by the network, but initially we suggest a target of 40% of the token supply at stake to guarantee the protocol. Since the phases of mainnet propose to launch Namada with staking inflation turned off, we think that the staking inflation rate should begin at 0. However, we suggest agreeing upon a maximum staking inflation rate ahead of Mainnet Phase 2, and we think that a maximum staking inflation rate of 5% should be sufficient to incentivize holders to stake 40% of the token supply.
If 33% of the supply is staked and staking inflation reaches the 5% ceiling, for example, the staking reward rate will effectively be ~15%. A maximum of 5% means that the Namada protocol will issue no more than 5% of additional token supply annually for rewarding staking to secure the network. At this rate, for example, a holder of 500k NAM that does not stake will own 0.0476% at the end of Year 1, versus a holder that stakes 500k NAM, who would instead own 0.0548%. Note that this staking inflation parameter is a maximum: as we get closer to our targeted stake, the rate of increase slows down, and if we exceed our target, the actual staking inflation rate will decrease, and can decrease to as low as 0 (more here).
We’d prefer for the unbonding period for staked tokens to be relatively short, and our understanding is that Namada could have a 14 day unbonding period without introducing much risk of weak subjectivity.
Validating 
We’d like for Namada to have an active set of 255 validators to help ensure that the barrier to become a validator is relatively low. In our experience, stake tends to be sticky: once holders delegate, they often don’t later redelegate to different or new validators. If there’s less competition to be in the active set, we think that there will be a more level playing field for validators to attract delegations as early as possible, and our understanding is that 255 validators shouldn’t meaningfully decrease network performance.
However, we think that a validator should need at minimum 10k NAM 1000 NAM in stake/delegations to qualify for the active set. A validator can be created with any amount of NAM, but the protocol needs to rank all candidate validators, so we should ensure that the performance of the network isn’t slowed by having to rank too many candidate validators.
[Edit: after discussions in the Namada Validator Circle, we have updated our proposed delegation minimum from 10k NAM to 1000 NAM to qualify for active set]
Validators need not be online at all times with CometBFT, but a validator will be removed (“jailed”) from the active set if offline for too long. In this case it would be nice to see the threshold for jailing be relatively high, like 15 hours of consecutive downtime before being jailed. Ideally a validator operator has enough time to recover from a node issue without feeling pressure to do something risky that could result in a security fault. Jailing won’t result in being “slashed,” but a validator and its delegators will not earn staking rewards, their governance voting power will not be part of any voting tallies while jailed, and it will take two epochs (12 hours) after unjailing to return to the active set.
Slashing 
Slashing is an economic penalty that happens when the protocol uses evidence to permanently remove a portion or all of a validator’s stake, which includes their delegated stake. While downtime won’t be slashed, there are two different kinds of slashes by the Namada protocol: a duplicate vote (aka “double-signing” or “equivocation”), and a light client attack. In the case of either type, the penalty is exponentially proportional to the amount of stake involved in the fault to a maximum of 100% slashing. There’s a floor parameter, a minimum slashing penalty, that we propose be 0.1%. We think it’s important to be aware that if two or more validators commit the same fault in the same epoch (6 hour period), the penalty will be exponentially proportional to their combined stake. If it’s large enough, all stake that is delegated to these validators could be permanently removed by the protocol. While providing more robust security, there’s also potentially the fringe benefit of nudging stakers to better distribute their delegated stake amongst validators.
Provisioning and rewarding public goods 
We’ve too often seen delegated proof of stake network protocols reallocate ownership toward the largest, earliest stakers. However, a growing ecosystem needs to maintain their early set of adopters while also growing by creating opportunities for new waves of community member contributors. We think Namada can strike a better balance between early supporters and newcomer stakeholders with its new token issuance policies.
Namada’s protocol can issue new NAM tokens to fund public goods (PGF), such as the work that will be needed to develop and advance Namada’s roadmap, community and ecosystem, to recognize allies advancing our broader vision, and to attract these allies to our mission. Using PGF inflation to reallocate Namada ownership will enable us to create opportunities for new contributors to secure a meaningful Namada position. Since the Phases of Mainnet plan proposes that PGF inflation be turned off in Phase 2, we suggest that PGF inflation rate be 0 at genesis, then 5% at Phase 2, and 10% at 3 months after Phase 5.
We will be one of the first communities to do this. We’ve seen in Cosmos and other ecosystems that foundations tend to be some combination of unsustainable and unaccountable to the community of the network that they’re mandated to support. Rather than being dependent upon an unaccountable foundation, PGF should enable our community to be self-sufficient. Using the value of our own ecosystem, we can reallocate Namada ownership to reward effective efforts and to incentivize necessary developments. The bet is that if we’re all willing to own less of the protocol, we can allocate it effectively enough to make ownership of our community more valuable. How? A dedicated stewardship organization can be elected, rewarded, and held accountable for championing Namada’s PGF work. We suggest beginning with 1 steward organization slot to experiment and observe before updating our protocol to be extensible to multiple, independent steward organizations. We also suggest the same graduated increase for rewarding the PGF steward organization: from 0 at genesis to 0.5% inflation at Phase 2, and 1% at 3 months after Phase 5.
We foresee the entire Namada community benefitting from supporting contributors that maintain and advance the progress of our mission, as well as our broader vision of a data-protected digital world. If well-resourced for self-directed development, we strongly believe that Namada can and will grow to be a self-sufficient, self-organized, decentralized community. We intend to begin a dedicated discussion about Namada’s PGF mission and vision as soon as possible: initial considerations such as PGF priorities, roadmap, and expectations about the steward role.
Incentivizing shielded set deposits 
At launch, Namada faces a “chicken-and-egg” 
kind of problem: there’s no data protection without deposits, and the earliest deposits won’t benefit from data protection until there are more deposits. So we’ll need to bootstrap Namada’s data protection by attracting early deposits for each kind of asset. We can reallocate ownership to those who help bootstrap the security for data protection by rewarding early asset deposits with “shielded set NAM rewards,” similar to our security budget for staking.
For example, if we agreed that we wanted to target 7 500 ATOM 
and 100 000 OSMO 
with a maximum of 0.2% inflation each, the maximum the protocol will issue for shielded set rewards will be at a rate of 0.4%, and the rate of issuance will decrease as we approach our targets and issuance for each will stop when its target is reached. Therefore to understand Namada token issuance, we think maximum NAM “inflation” for shielded set rewards should not be a simple addition of staking plus PGF plus shielded set rewards to determine Namada’s issuance rate–there’s nuance here.
Since the phases of mainnet propose to launch Namada with shielded set rewards turned off, we think that no assets should be designated yet. However, we strongly suggest beginning a dedicated discussion now about how we should govern shielded set parameters and agree upon: a) the initial set of assets (ie. how many? which ones?) that we’ll want to incentivize, b) the amounts we want to target for each asset, and c) the maximum inflation rate that we want to designate for each asset type. We expect that there will be representatives from different communities advocating for deposit rewards for their respective community assets, so we should determine a basic initial approach for decision-making that can be improved upon over time.
Edit: we have initiated this discussion here: Preparing to kick off shielded set rewards 
Just as staking is designed to protect the integrity of transactions, we think of shielded set deposits as securing transaction data (but deposits will not be locked by the protocol). Bootstrapping the shielded set will be critical for Namada to be useful, and we are the first community offering rewards. Therefore we are strongly in favour of prioritizing an attractive reward rate to attract the asset targets that our community agrees upon (and ideally attracts some intrinsically motivated depositors, as well!)
Governing 
Namada has a plutocratic governance structure: the more stake you delegate, the more governance voting power you have. Validators inherit their delegators’ voting power, but a) validators can only vote for just over 2/3 of the voting period and b) delegators vote the entire voting period and can override and decide how to use their voting power. If a validator is outside of the active set (ie. jailed or outranked) when the voting period ends, the validator and its delegators’ governance voting power won’t count.
Currently there are three kinds of governance proposals: 1) default - a generic proposal that can carry wasm code to be executed; 2) StewardProposal - updates the designated PGF steward account; 3) PGFProposal - for conducting PGF activities. They have different quorum and majority thresholds, among other properties that are not governable parameter values, which we intend to propose should be made governable in the near to mid future.
All governance proposals are currently subject to the same parameters, and we are proposing that they be:
- 2000 NAM deposit
- a maximum 2 day delay after proposal launch before the start of the voting period
- A minimum 7.25 day voting period (which gives validators a minimum of 5 days for voting)
- A maximum 21 day voting period
- at minimum a 2 day grace period before a successful proposal is enacted
Edit: more recent update → shortened governance minimum periods prior to Mainnet Phase 5
We think that we should begin a dedicated discussion about Namada’s governance process now. It would also be helpful to begin discussion Namada’s roadmap.
In the near future we strongly suggest proposing an IBC-specific gov proposal type that can be expedited to recover a frozen or expired IBC channel. This helps to ensure that deposited IBC assets are not stranded with Namada, and the governance process would require wasm code and (with our proposed parameters) would take at least 9 days to recover the channel.
There were originally plans for Namada to have a “liquid democracy.” A liquid democracy would enable us as stakers to delegate our governance voting power to any account, whereas the current implementation has staker governance power only delegated to the validators we’ve staked with. We would strongly support implementing what’s needed for a liquid democracy in the near to mid future.
It could also be nice to be able to create governance proposals with a smaller amount of NAM than the deposit required, for which other participants could add to the deposit amount. We think it would be helpful to be able to signal strong support by co-sponsoring a proposal.
IBC 
Since the phases of mainnet propose to launch Namada with IBC transfers turned off, we think the IBC limits should begin at 0, and afterwards any token transferrable to Namada by IBC should be specified by governance proposal. We think that we should begin a dedicated discussion about how we should govern IBC limit parameters: considerations such as amounts, and expectations like the steps we should take for increasing amounts, and the assumptions and needs to secure IBC asset deposits.
Onward!
The full set of proposed parameters can be found at the bottom of this doc: draft proposal for Namada mainnet parameter discussions - Google Docs
That’s it! Let’s discuss 
