MakerDAO Extended Schema QA

[bye43]

Description	Value
Subgraph Reviewed	https://subgraphs.messari.io/subgraph?endpoint=https://api.thegraph.com/subgraphs/name/tnkrxyz/makerdao-ext&tab=protocol
Date Reviewed	October 12 2022
Schema Version	2.0.1
Subgraph Version	2.0.0
Methodology Version	1.1.0

Issues

1. cumulativeUniqueUsers - It looks like the the old schema is tracking 49,082 and the 2.0.1 schema is tracking 31,515

2. I see for this account that there is two closed positions. It looks like there is a lending position and then a borrowing position. How come there is only repay though? For the lending side shouldn't there be a deposit and the borrow side there should be a repay and a borrow? This might be weird though because it looks like an early makerDAO transaction since its in SAI, but figure I’d double check. Query - https://api.thegraph.com/subgraphs/name/tnkrxyz/makerdao-ext/graphql?query=%7B%0A++ac[…]estampOpened%0A++++++timestampClosed%0A++++%7D%0A++%7D%0A%7D

3. This liquidation looks correct, but I am not sure about the profitUSD. IIRC this should be the penalty fee correct ? Looks like this is $8.47K on maker risk (https://maker.blockanalitica.com/liquidations/per-date/2022-09-19/) but only $638 on the subgraphs. Maybe, I am interpreting wrong and this account did not provide the full liquidation so it only received $638 for their share? Query - https://api.thegraph.com/subgraphs/name/tnkrxyz/makerdao-ext/graphql?query=%7B%0A++account+%28id%3A+%220x045bf24164b9dd5949bcd780f679fb60effe7637%22%29+%7B%0A++++openPositionCount%0A++++closedPositionCount%0A++++depositCount%0A++++liquidateCount%0A++++liquidates+%28orderBy%3A+timestamp%2C+orderDirection%3A+desc%2C+first%3A+1%29+%7B%0A++++++market+%7B%0A++++++++id%0A++++++%7D%0A++++++hash%0A++++++amount%0A++++++col%0A++++++amountUSD%0A++++++profitUSD%0A++++++asset+%7B%0A++++++++name%0A++++++++id%0A++++++%7D%0A++++%7D%0A++%7D%0A%7D

[tnkrxyz]

Thx! Will take a look of them soon.

[tnkrxyz]

1. `cumulativeUniqueUsers` - It looks like the the old schema is tracking 49,082 and the 2.0.1 schema is tracking 31,515

This is due to a bug in the new implementation not taking into account urns owned by DSProxy owned by a user. I fixed it and redeployed the subgraph. The new subgraph also handles transfers of CDP (urn) positions, while not in the old implementation (1.1.3). The fix should bring the two number closer, but may not be exactly equal.

2. I see for this account that there is two closed positions. It looks like there is a lending position and then a borrowing position. How come there is only repay though? For the lending side shouldn't there be a deposit and the borrow side there should be a repay and a borrow? This might be weird though because it looks like an early makerDAO transaction since its in SAI, but figure I’d double check. Query - [https://api.thegraph.com/subgraphs/name/tnkrxyz/makerdao-ext/graphql?query=%7B%0A++ac[…]estampOpened%0A++++++timestampClosed%0A++++%7D%0A++%7D%0A%7D](https://api.thegraph.com/subgraphs/name/tnkrxyz/makerdao-ext/graphql?query=%7B%0A++ac%5B%E2%80%A6%5DestampOpened%0A++++++timestampClosed%0A++++%7D%0A++%7D%0A%7D)

Can you post the complete link again - the one above was truncated.

3. This liquidation looks correct, but I am not sure about the profitUSD. 

For tx 0x60d9aa1de054884827dc5e7ae032dbe8e09e5da09f3145138d6d4cdf7c18367c, the debt was $65156, and maker imposes a 13% penalty on liquidations (that goes to the protocol), the liquidation auction was set for and won at $73626, but market value of the seized ETH was $74264, netting a profit of $638 to the liquidator.

[bye43]

@tnkrxyz Sounds good for 1 and 3. Sorry about that here is the full query - https://api.thegraph.com/subgraphs/name/tnkrxyz/makerdao-ext/graphql?query=%7B%0A++account+%28id%3A+%220x41e335ef0d3f9c7fec0eb86d3fbe81d062d66133%22%29+%7B%0A++++openPositionCount%0A++++closedPositionCount%0A++++depositCount%0A++++liquidateCount%0A++++borrowCount%0A++++repayCount%0A++++positions+%7B%0A++++++isCollateral%0A++++++borrows+%7B%0A++++++++id%0A++++++%7D%0A++++++repays+%7B%0A++++++++id%0A++++++++amountUSD%0A++++++%7D%0A++++++deposits+%7B%0A++++++++id%0A++++++%7D%0A++++++side%0A++++++id%0A++++++timestampOpened%0A++++++timestampClosed%0A++++%7D%0A++%7D%0A%7D

[tnkrxyz]

A quick update that I'm still working on 1. I found a bug in subgraph version 1.1.3 (the account.id all missing the proper 0x prefix), so 49k unique users is certainly incorrect. I believe it only affects user count metrics, position and transaction entity. I fixed the bug and re-deployed to my own account to see if it matches with ext subgraph number.

I have a hypothesis for 2; will write up once I confirm it.

[tnkrxyz]

@bye43 Sorry for the delay in getting back to this - redeployed makerdao-ext subgraphs took a long time to sync & I had to do it a few times before I got it right.

For unique user count, there were a bug in the makerdao-ext subgraph AND a separate bug in the makerdao subgraph, so neither unique user count was correct. After fixing both bugs, the ext subgraph has a cumulative unique user count of 22,334 as of 2022-11-12, while the number for the fixed makerdao subgraph is 21,877. I believe the difference is due to whether cdp ownership change is included. I think the current implement in makerdao-ext is better.

In terms of the positions/repaycount for address 0x41e335ef0d3f9c7fec0eb86d3fbe81d062d66133, the discrepancy was indeed because of account migration from old SAI to MCD contract. I implemented a fix for it and the repaycount is now correct using this query.

Note that: 1). the deposit count & borrow count is still off (both=0) because they happened in the old contract; 2). You have to use "0xe617cb6f95ee083b18287e86be729f87c172f949" as the account id, because 0x41e335ef0d3f9c7fec0eb86d3fbe81d062d66133 is a proxy owned by 0xe617cb6f95ee083b18287e86be729f87c172f949. With the bug fixed, the Account entity only includes owner aadresss of urns/proxies. You can see this in the above query

[bye43]

@tnkrxyz Trust your judgement for cumulativeUniqueUsersand looks good for positions/repaycount for address 0x41e335ef0d3f9c7fec0eb86d3fbe81d062d66133. Thanks and will close issue! @jaimehgb should this be deployed to the messari hosted service?

[tnkrxyz]

@bye43 thanks!

I forgot to tag #696 where the bug fix was pushed.