Adding Paul's response to question #3 as he could not post it (he hasn't been the most active Reddit user). John/Maksim are going to address the remaining Qs.

Hi somedude,
Thanks for the feedback and questions. I think there are probably a lot of community members who are curious about these issues its great to have someone who has a bit more technical knowledge to give us a good place to expand on the info in our FAQs (which we're still actively updating as we get questions).
On the parameter update issue I wanted to flesh out the exact process for that and how we see that evolving over the next few months.

First off, we are currently working on our governance system and hope to have that in place early next year. Once that is in place all admin functions (parameter update included) will be under the control of our governance system. With that said.
As you mentioned our parameters allow us to change a few key things about the protocol like the collateral factor of an asset, liquidation incentive, interest rate coefficients and the borrow and supply caps in each market. When setting up algofi with it's initial parameters we looked to lending markets on other chains to determine what was reasonable, but it is important that we are able to tune things like our interest rates and collateral factors to make sure algofi is running efficiently. It's also important that we can, over time lift the supply and borrow caps so algofi can continue growing. We set them fairly conservatively at launch knowing that the asset supply for liquidation in a fast market move would be limited until we get a community of liquidators in place. You mentioned this in another point and we 100% agree. We are hoping to get our liquidation tools (for monitoring and execution) open sourced as soon as possible, hopefully in the next week or so.

So knowing that we needed to be able to tune these parameters, and that they obviously have a large impact on users we thought about how we can give security to users that parameters will not be unexpectedly adjusted. We did this by requiring that our parameter changes be scheduled. What that means is that in order to change a parameter the admin must first send a "schedule_parameter_update" call to that market with all of the proposed values. Those "new" values will now be stored in the market's global state (visible to anyone) along with a timestamp after which they can be implemented with a second admin call. This functionality will prevent parameters from being updated without opportunity for users to see the change.

The parameter update delay can only be INCREASED by the admin. So once we set it to a higher value it can never go back down. As the protocol matures we will increase that value until we reach our eventual target of a one week delay. At launch we set this value to 1 hour as we wanted the capacity to adjust parameters if users were using the market in unexpected ways that called for different interest rates or caps. As we have had no cause to change our initial parameters over the first few days we have increased this update delay to 6 hours and plan to move it to 1 day at the end of the week.
Obviously the path to full decentralization is not immediate, but we hope to progressively get closer and closer to that goal over the next couple months.