MIP10c9-SP26: Subproposal to whitelist Instadapp/Gelato Automation contract for ETH/USD Oracle Access


MIP10c9-SP#: 26
Author(s): Samyak Jain, Luis Schliesske
Contributors: Samyak Jain, Luis Schliesske
Status: Formal Submission
Date Proposed: 2021-1-4
Date Ratified:



Instadapp and Gelato have worked together to create refinance automation functionality into Instadapp’s DeFi Smart Account (DSA). Defi Smart Accounts are permissionless and non-custodial. Users will be able to set up refinance automation functionality in case of liquidation for ETH-A vaults into Aave, ETH-B or Compound. One of the Instadapp Gelato Automation smart contracts - ConditionMakerVaultUnsafe.sol - requires access to the Maker Oracle feed so that it may acquire and verify price data. This oracle will be used to facilitate automation on behalf of DSA users.

The process of refinancing will be prioritized as follows (in case of ETH-A liquidation):-

  1. Aave, but if no DAI liquidity then
  2. ETH-B vault, but if ceiling reached then
  3. Compound
  • Automation without oracle data: User selects a ratio at which they would want their ETH-A vaults to refinance.
  • Automation with oracle data: ETH-A will only get refinanced if the ETH-A vault is about to get liquidated.

Oracle Name


The contract to be whitelisted does neither return nor store the ETH/USD price. It reads and processes the price in-memory. Based on that in-place data processing it will only return either the string “OK”, if the inputted maker vault is about to get liquidated, or “NOT OK”, if the inputted maker vault is still safe. If the contract returns “OK”, the Gelato bots will automatically refinance the debt position.

Therefore, no other contract can access the raw price data from the Maker Oracle via ConditionMakerVaultUnsafe. The oracle data is inherently permission only to the latter and thus we are confident that it meets all the requirements for whitelisting.


Instadapp – [email protected]
Gelato – [email protected]


ConditionMakerVaultUnsafe.sol – 0x3b50336E3E1E618FE74DF351966ebaD2B12cD24a


For each customer address to be whitelisted:

· Is the contract source code verified on etherscan? Yes
· Is the Oracle data used in a permission manner that would prevent parasitic behaviour? Yes
· Is Oracle data written to storage? No
· If Oracle data is stored, is it stored in a private variable? n/a
· If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? n/a


In accordance with the Responsible Oracle Migration Proposal, fees are waived for the first year and determined by MKR Governance after that.


Why would you refinance on aave before eth b? Rates are lower on eth b vault and you have an additional 1 hour delay

Liquidation on ETH on Aave V2 is at 82.5% (debt/col) while on ETH-B it’s at 77.92% (debt/col).


This is a great proposal!

Out of curiosity, do you know if Aave has an oracle price delay like we do? Or are prices entered into their system live?

I think the prices are live as they use Chainlink oracle. Although, if making ETH-B the first priority makes much more sense then we can think around that too.

1 Like

Wasn’t suggesting that at all! Just curious.


If you use ETH-B and the Oracle Security Module you can guarantee you never get liquidated because you’ll always know an hour ahead of time and can unwind the position. Let me know what you think.

In the meantime I’ve reviewed the contract and noticed the function used to query the Oracle price is publicly accessible. One of the requirements for Oracle whitelisting is that the price data is used in a permissioned manner such that only the applicable user can query it. Please update your contract with the appropriate changes.

Thanks a lot for your inputs. We can change the priority to ETH-B, Aave and then Compound if it makes more sense after some discussion. Although, currently we’re focused on only refinancing and we’ve plans to get self-liquidation automation functionality in future.

The function is publicly available but it returns String “OK” if the vault is going to liquidate. The oracle price is never exposed. All a user can know is if the particular vault is going to get liquidate on the next price update. Let me know what you think and we can change it accordingly.

1 Like

If you use ETH-B and the Oracle Security Module you can guarantee you never get liquidated because you’ll always know an hour ahead of time and can unwind the position.

The use case we are targeting right now does not involve “unwinding the position” i.e. self-liquidation, it involves the refinancing to another protocol with lower collateral requirements.

Let’s say ETH price drops rapidly, leading to your ETH-A Vault becoming subject to liquidation in an hour and even if you refinance to ETH-B, given the current transaction fees you would have to pay (which are usually very high when ETH price crashes and which you as the user have to pay for), your resulting refinanced position on ETH-B could still be in danger of being liquidated, because the price simply dropped very rapidly. Maybe not in next period, but latest in the price update period that follows if ETH continuous to drop. As we don’t unwind the position, users will still get liquidated in ETH-B in that case. This scenario is what we want to avoid.

Given these circumstances, the best option for the User is be refinanced to the where the lowest colla requirements are at that time to avoid being liquidated and needing to self liquidate in the first place. If we don’t do that, users might end up being refinanced to ETH-B where they would still get liquidated + they had to pay a large transaction fee for the refinance, which would be very suboptimal.

That is why we prioritise the destination of the refinance to the protocol which makes most sense given the changing market conditions at that time. In practice what will happen, some of the ETH-A vaults will be refinanced to Aave, some to ETH-B and some to Compound in times of price distress, all based on the available liquidity and what would the best option for the end-user at that time.

In the meantime I’ve reviewed the contract and noticed the function used to query the Oracle price is publicly accessible

Yes they are, but as Samyak mentioned, the only thing that “leeches” could do is to know whether a certain Vault will be subject to liquidation in the next period or not. It is impractical to defer the price from that statement imo. If you still would like us to restrict knowing that only our use case can use the Condition contract, we could implement a simple require() in the view call, restricting it only to our system. Let me know whether you require that.


1 Like

To add to Samyak’s point and summarize our rationale behind this Refinancing use case and the priority of Aave => ETH-B => Compound:

The goal: minimize liquidation risk

The constraint: without self-liquidating (or selling collateral)

The priority favors protocols with lower collateral requirements.

Reason: in the current version this is a one-time automated refinancing only without any added automated liquidation protection via further consecutive debt refinancing or self-liquidation mechanisms thereafter.

Therefore the destination of the refinancing should stay “safe” the longest under price crashes i.e. have the lowest collateral requirement.

Any actual self-liquidation, if necessary, will have to be done manually by the users.

1 Like

Hi everyone, quick update from our side:

We changed the source code of the contract in question to adapt the decoding of the return values to the (bytes32, bool) returned by peep().

The contract we submit for whitelisting (or consensual kissing :kissing: ) is now called ConditionMakerVaultUnsafeOSM and lives at 0xDF3CDd10e646e4155723a3bC5b1191741DD90333.

Nothing much has changed other than this adaptation:

    (bytes32 colPrice, bool hasNxt) = abi.decode(returndata, (bytes32, bool));

    require(hasNxt, "FMakerVaultUnsafeOSM._isVaultUnsafeOSM: !hasNxt");


        wdiv(wmul(vault.collateral, uint256(colPrice)), vault.debt) <

Please consider this updated and deployed contract as the only candidate for this subproposal.

The application for its predecessor ConditionMakerVaultUnsafe is hereby deprecated and replaced by ConditionMakerVaultUnsafeOSM

1 Like