Comment on page
The State of the ABM Protocol
The Core Module is crucial to the system as it contains the entire state of the ABM Protocol and controls the central mechanisms of the system while it is in the expected normal state of operation.
Vat- The core Vault, dotBTC, and collateral state is kept in the
Vatcontract has no external dependencies and maintains the central "Accounting Invariants" of dotBTC.
Cat- The system's liquidation agent. The two main mechanisms within it are:
bite(bytes32 ilk, address urn)- In charge of Vault Liquidation. It checks if the Vault is in an unsafe position and if it is, it starts a Flip auction for a piece of the collateral to cover a share of the debt.
pokeis the only non-authenticated function in
spot. The function takes in a
ilkto be "poked".
- The methods in the
Vatare written to be as generic as possible and as such have interfaces that can be quite verbose. Care should be taken that you have not mixed the order of parameters. Any module that is
authed against the
Vathas full root access, and can, therefore, steal all collateral in the system. This means that the addition of a new collateral type (and associated adapter) carries considerable risk.
- When the
Catis upgraded, there are multiple references to it that must be updated at the same time (
Vow.rely). It must also rely on the
End, the system's
pause.proxy(). Read more here.
- The methods in the
spotterare relatively basic compared to most other portions of
dss. There is not much room for user error in the single unauthed method
poke. If an incorrect
bytes32is supplied the call will fail. Any module that is authed against the
spothas full root access, and can, therefore, add and remove which
ilkscan be "poked". While not completely breaking the system, this could cause considerable risk.
Vat- A bug in the
Vatcould be catastrophic and could lead to the loss (or locking) of all dotBTC and Collateral in the system. It could become impossible to modify Vault's or to transfer dotBTC. Auctions could cease to function. Shutdown could fail.
Cat- A bug in the
Catcould lead to loss (or locking) of dotBTC and Collateral by assigning it to an address that cannot recover it (i.e. a bad Vow address or an incorrectly programmed Flipper). The main coding failure mode of
Catis if it has a bug that causes auctions to cease to function. This would require upgrading the system to a corrected
Catcontract. If there is a bug in
Catthat reverts on
cagethen it would cause Shutdown could fail (until a correct
Spot- A bug in
spotwould most likely result in the prices for collaterals not being updated anymore. In this case, the system would need to authorize a new
spotwhich would then be able to update the prices. Overall this is not a catastrophic failure as this would only pause all price fluctuation for some period.
Vat- relies upon a set of trusted oracles to provide price data. Should these price feeds fail, it would become possible for unbacked dotBTC to be minted, or safe Vaults could be unfairly liquidated.
Cat- relies indirectly on the price Feeds as it looks to the
Vat's tracking of the collateral prices (
spot) to determine Vault safety. If this system breaks down, it could lead to theft of collateral (too low
spot) or unbacked dotBTC (incorrectly high
Spot- relies upon a set of trusted oracles to provide price data. Should these price feeds fail, it would become possible for unbacked dotBTC to be minted, or safe Vaults could be unfairly liquidated.
Vat- Governance can authorize new modules against the
Vat. This allows them to steal collateral (
slip) or mint unbacked doyBTC (
suck/addition of worthless collateral types). Should the crypto economic protections that make doing so prohibitively expensive fail, the system may be vulnerable and left open for bad actors to drain collateral.
Cat- Governance can authorize and configure new collaterals for
Cat. This could lead to misconfiguration or inefficiencies in the system. Misconfiguration could cause
Catnot to operate properly or at all. For instance, if an
Ilk.lumpis set to be greater than 2**255 could allow for very, very large Vaults to be un-
bite-able. Inefficiencies in the
chopcould affect auctions. For instance, a
lumpthat is too large or too small could lead to disincentives for keepers to participate in auctions. A
chopthat is too small would not sufficiently dis-incentivize risky Vaults and too large could lead to it being converted to bad debt. Further discussion of how the parameters could lead to system attacks is described in this Auction Grinding paper.