Generalize registry

[MrChico]

The registry makes a lot of assumptions on the structure of ilks, their adapters and liquidation methods.
This makes it difficult to register non-standard ilks and their adapters, such as the manager of MIP-22.
In particular, in my opinion the sanity checks of https://github.com/makerdao/ilk-registry/blob/master/src/IlkRegistry.sol#L141, are too coupled with the typical infrastructure of ilks and can be removed. It also doesn't really feel like the role of a registry to perform these checks anyway. How do you feel about this?

[brianmcmichael]

Hi @MrChico,

This specificity was by design, it's important to make sure that our adapters conform to rigid standards to assist with integrations, user interfaces, keeper integrations, and general developer system comprehension. The sanity checks are required here because add() is an unauthorized public function, so it helps to prevent invalid information from being added to the registry.

I would honestly prefer that MIP-22 conformed to the ilk-registry standards than rebuilding the registry, as we can not really maintain non-conformant adapters at scale. That said, we're already probably going to have to push out a new version of the registry when we break the API with liquidations 2.0. At that time we can work around the exceptions for some of these early bespoke RWA collateral types, but in the longer-term we will need to take what we learn from these first RWA MIPS to build out a standard adapter type that can be used for future RWA asset classes.

We do have a more generalized solution for on-chain tracking of assets; check out the dss-chain-log which is a governance-managed store of on-chain addresses. The goal of the ilk-registry is to have a very standardized and publicly modifiable source of information on standard collateral types, something that an integration can iterate over and perform common actions on. Since MIP-22 will not really be compatible with most of the MakerDAO integrations requiring the standard collateral structure (i.e. it's not publicly liquidatable and many of the functions in, say, MCD-CLI can't be performed on it) it's probably not a good candidate for entry into the ilk-registry anyways.

[MrChico]

Good points. I overlooked the fact that the add() method is unauthorized. In light of that the checks make more sense, vat.wards(adapter) == 1 being the crucial one.

I would honestly prefer that MIP-22 conformed to the ilk-registry standards than rebuilding the registry, as we can not really maintain non-conformant adapters at scale.

It would be nice, but misleading, as MIP22 has no flip. Perhaps a compromise would be to allow for flip to be the zero address in the case that the ilk is an RWA or uses an otherwise non-standard liquidation procedure? It might lead to the need for some special casing for some clients, but they would otherwise still get the benefits of the ilk-registry.