I just want to interrupt this with a note about model risk. The platform will need to adapt and evolve over time, so change is both something we anticipate and also will require. Sidechains and other scalability solutions will require changes, and the growth of the platform is even now largely moving in directions that we not entirely foreseeable when the platform was being developed. At the same time, we need to have those changes to be stable and predictable as possible; we don’t want the fundamental rules arbitrarily changing underneath people’s feet.
It’s helpful to think of updates as one of 3 things:
1 - Ledger Changes
Ledger changes need to be raised as CIPs and the time frame for implementation is much longer than for parameter updates. The the CIP forums have some of the discussion and their is a biweekly call to discuss issues. I highly encourage you to engage with that process.
Cardano Improvement Proposals
CIP Bi-Weekly Meetings
2 - Parameter Changes that represent a change in direction
Some parameter changes represent a conceptual change in direction. While these certainly have a lower barrier to change than CIPs, these will need to have overwhelming popular approval or go through some form of governance.
I don’t have an ETA for the governance - I am not strongly tied into that process; it’s complicated. Some parameters are fairly opaque in function and have significant public misconceptions about what they do. Having a straight up public vote about parameters every 36 hours may sound like an easy solution - but even on these there needs to be a long-term direction and consistency. There are trade-offs as well: decentralization, performance and security are a famous example from Vitalik Buterin … but even things like the staking rewards creating a barrier for people engaging in other forms of economic activity need to be considered.
3 - Parameter Changes that represent staying on course
Some parameters need to be periodically adjusted as the price of Ada changes and to respond to changes in the ecosystem (like rewards being release from the ecosystem.) These are about the only things that, as a custodian of the platform trying to keep it on course, we can really change right now.
For economic parameters: the minimum pool fee, the fixed transaction cost, the portion of transaction cost based on byte size are the main ones that need to be updated as the price moves and as the reserve get drawn down. (The changes to K were previously discussed as a several step change, so this is again trying to deliver on that commitment - not as a change of direction, but staying on a course that was previously set.)
For non-economic parameters: the block height, the size of scripts, the timing of blocks could all be changed.
The whole point of that is: these are great ideas - but they I don’t want to tie up the “stay on course” discussions with the “change the ledger rules” types of changes. They are both important - but they operate on different time scales.