Stablecoin Questions

[sagapiou]

Good day everyone,

I was looking through lesson 12, the stablecoin implementation which interests me a lot and there are some general question I would like to ask (I dont know if they are answered in later lessons as I am currently at lesson 12).

What is the reason that it was chosen architecturally to call the Decentralised stablecoin contract as an IERC20 and not make the DSCEngine is ERC20? Is it for security reasons or was it just a choice showing us how to call a contract this way?
I ask this because I was trying to implement an interface for playing around with it and that was the moment I realised what we were doing in the tests was sending two different transactions to 2 contracts. In the tests it appeared logical and I didnt give it any thought, but through an interface you actually have to send two different transactions with metamask for every single function we are calling (and even more than 2 for some of the functionality) and that is a bit of a pain... Initially i tried changing the contract and running the approvals before the actual calls but that was the aha moment I had realising that the msg.sender running the call is different from the msg.sender minting and burning DSC so there was no way around this unless DSCEngine is ERC20...
The other thing I would like to ask is the liquidate function and the threshold which I am trying to understand the logic. According to the scenario we have, there will be external entities, listening to events and performing queries that will be trying to liquidate users that are below 1:2 (USD stablecoin : USD Collateral ratio). Up to here I understand it but if this liquidation does not happen and we get close or even below 1:1 (e.g. due to an ugly capitulation), there will come a breaking point for the protocol so should there be some internal or external (chainlink time or price triggers) contract mechanism calling liquidations (I mean this would cost link but this cost should be included in the overall minting)?

[cromewar]

@PatrickAlphaC a hand on this one please.

[danail-vasilev]

I got the same question regarding why not merging the engine with erc20 stable coin contract in terms of reducing transactions and gas saving. (In terms of separation of concerns they must be separated which I guess is the answer:)

[PatrickAlphaC]

1. Why have 2 contracts?

We had two contracts to separate the logic. One is the contract handles the minting/burning of tokens and one handles the token itself. We could have made them 1 contract, but felt the separation actually made the codebases easier to read.

but through an interface you actually have to send two different transactions with metamask for every single function we are calling

I'm not sure I understand this. No matter what, we would need to make 2 transactions (including for approving). It doesn't matter if it's in 1 contract or 2. We would always need to approve access to the DSCEngine. We could have added an "auto approve DSCEngine" feature, but that would add an extra security assumption, and we wanted to keep the codebase simple.

2. if this liquidation does not happen and we get close or even below 1:1 (e.g. due to an ugly capitulation), there will come a breaking point for the protocol

Correct! This is a known issue with the protocol, and a big reason why it's a demo and not a real stablecoin.

To protect against this, we'd need to update a lot of the architecture to have some sort of fail-safe in this scenario. The DAI stablecoin's fail-safe is that it takes an extra fee as a reserve that it uses in the case that liquidators don't act fast enough. I didn't want to make this codebase that big - so we excluded it.