This is a huge departure from the point you made above, where you claimed “the risk is real” for money in FDIC-insured checking accounts due to risky bets by banks with my money.
“There are trade offs for the user” isn’t really in dispute. The major concern being raised throughout the comments here is that advertising FC as a “checking account” is deceptive: it encourages people to think of it like a checking account, despite having a very different set of trade offs.
In engineering, we would similarly talk about violating the principle of least surprise. If my library has a function for saving files that’s very fast but sometimes loses data, I don’t call it super_fast_write, I call it unsafe_write. I think the idea behind this project is super cool, but it’s not high_upside_checking, it’s high_flexibility_brokerage.
The risk is real in banking. I wasn't just referring to customers there, but to the whole system, since the criticism of this idea has been quite broad. But there is some real risk for customers. There are caps on FDIC coverage and there can still be significant disruption even if you are insured and will be made whole.
“There are trade offs for the user” isn’t really in dispute. The major concern being raised throughout the comments here is that advertising FC as a “checking account” is deceptive: it encourages people to think of it like a checking account, despite having a very different set of trade offs.
In engineering, we would similarly talk about violating the principle of least surprise. If my library has a function for saving files that’s very fast but sometimes loses data, I don’t call it super_fast_write, I call it unsafe_write. I think the idea behind this project is super cool, but it’s not high_upside_checking, it’s high_flexibility_brokerage.