There's something... not quite right about loopy. I think it's just that it has inverters but not diodes?
You can see for example if you try to form an ecosystem with a Sun node feeding one or more plant nodes that feed herbivore nodes that feed carnivore nodes, with Death nodes that kill off living things.
Eventually once the thing is running smoothly you can just turn off the sun and turn up the death and somehow those plants will still be thriving, apparently because the death of the herbivores is the same as sunshine to the plants.
This means that loopy seems to have real trouble with describing dynamic equilibrium states...
It's actually the reverse of fractional reserve banking. Any Dai that is created must be over-collateralized by 150%. It's not capital efficient, but that's a different argument than what's being discussed.
> It's actually the reverse of fractional reserve banking
It's analogous. (More accurately, it's a carry trade.) If Ethereum crashes more than 33% (given 150% overcapitalisation) the token breaks the buck. Betting your less-liquid assets won't fall below your more-liquid liabilities is maturity transformation and presents the classic risks of fractional-reserve banking.
This has happened, and AFAIK, DAI is still stable. Maybe that's the result of some extra manipulation by the project or whatever. I would love to see an in depth analysis of DAI over the past 6 months.
No, it's part of the protocol. When a collateralized position falls below the 150% (or whatever) mark, that position gets automatically liquidated and auctioned off to pay for the debt.
And the positions are set up to where you can borrow less than the maximum amount of DAI per ETH, to make your position more resistant to price drops.
> When a collateralized position falls below the 150% (or whatever) mark, that position gets automatically liquidated and auctioned off to pay for the debt
The same thing happens with banks. It turns into a run when this forced liquidation drives prices down further which in turn fuels further redemption requests. It’s very possible to start the day 150% capitalised and end 20% because you sold 10% which tanked the market.
Pause functions are actually considered a matter of best practice. It's a way of mitigating the contract's risk. Now, who gets control of the pause function is an entirely separate discussion worth having. The controlling address could be a contract implementing a multisig scheme, allowing for the decision to be made by more than just a single individual.
All state transitions are forever visible in the blockchain. Since addresses can be set dynamically in Ethereum, it's possible to update the contract addresses which make up the business logic pipeline. This sort of pluggable design is not a requirement, and some contracts are completely immutable.
Decentralization and immutability are entirely separate subjects. The security benefits of decentralization are not lost just because pipeline components can be altered.
The problem is for other contracts that want to use upgradable contracts - before you could be sure/analyze correctness but now you need to consider the underlying contract's implementation can change in arbitrary way, it's outside of your control, ie. if the upgradable contract you're calling is hacked it can turn malicious towards your contract - something you didn't have to worry about before.
I don't think this functionality is anything new, it's just a design pattern. As for safety, you're absolutely right. Best practices dictate that when calling other contracts, you should mark the code as untrusted, and treat it as such. It's somewhat analogous to running untested dependencies, and stipulating in your requirements that the latest version of those dependencies should always be deployed.
It's not new (if we're allowed to say that anything in system created less than 3 years ago can be "not new") but the core functionality (delegatecall opcode) was added to support linked libraries. Delegatecall's abuse to use it for "upgradable contracts" is relatively new, the opcode was not designed to handle this "pattern", it's somehow undesired consequence of introducing it that it can be abused in this way. Noting more than that. Really, I don't think most people realize what it actually means and what can and cannot be altered in "upgradable contract".
MakerDAO uses collateralized smart contracts to provide stability to their Dai token. Right now, only ETH can be used as collateral, but in Q2 they are starting multi-collateral support.
Their whitepaper's explanation of how this works is horrendously complicated. There's no way you can encode that sort of logic into a cryptocoin in a bug-free manner. Steer clear of this.
And who will abitrate the collateral? While it's smart wallets and crypto currency it can be enforced by cryptographic proof but when the collateral is USD then it's going to have to exist somewhere.
I've tried several of these, and I really think jetzt https://github.com/ds300/jetzt is the best one. It has a progress bar, keyboard shortcuts, and I particularly like the way it wraps words in enclosing elements - like quotations and parentheses - when the word being displayed is within the enclosure.
https://shaunlebron.github.io/parinfer/ https://www.youtube.com/watch?v=K0Tsa3smr1w