Basin on Arbitrum

[soilking]

Updated adapter for Basin protocol to include tvl on Arbitrum. Otherwise, none of the other info/metadata etc is changed.

[llamatester]

The adapter at projects/basin exports TVL:

arbitrum                  6.85 M
ethereum                  6.08 k

total                    6.85 M 

[llamatester]

The adapter at projects/basin exports TVL:

ethereum                  6.07 k
arbitrum                  0

total                    6.07 k 

[g1nt0ki]

@soilking can you check if my implementation is correct? I manually checked all the wells on arbitrum, maybe the upgraded event pulls unrelated contracts?

[soilking]

The arbitrum wells can be upgradeable, the addresses emitted in the BoreWell event in this case are the underlying implementations. The other logs call I added was to search for which contract (if any) emitted that Upgraded event. If there is such an event, then the pooled tokens are not in the implementation address but rather in the address emitting Upgraded.

[g1nt0ki]

The arbitrum wells can be upgradeable, the addresses emitted in the BoreWell event in this case are the underlying implementations. The other logs call I added was to search for which contract (if any) emitted that Upgraded event. If there is such an event, then the pooled tokens are not in the implementation address but rather in the address emitting Upgraded.

do you have an example?

[g1nt0ki]

*like a transaction with ungraded event

[soilking]

Here is an example: https://arbiscan.io/tx/0xe530c3ced2dd6ff9e7e8a4e8b721150ebd3de3420935d9b06ac557f296bb7532#eventlog

What are you trying to achieve? I believe the original code I submitted was accounting for this properly.

[g1nt0ki]

hmm, I see what you are doing, but the issue with that implementation is, as time goes by, there will be more event log calls, in my implementation, it is always against one contract, but in your case, it grows.

It is sort of hidden, but we cache each of these event log result (per target), and if we dont cache, it is too expensive. But my implementation is wrong, is there some other way to get the upgraded contract? the new contract is not verified

[soilking]

Unfortunately this is the only way to get it on chain currently. Would it work for you if instead we pulled the list of wells from our subgraph? The upgradeable wells have a hardcoded mapping there until an on chain solution can be developed.

[g1nt0ki]

Unfortunately this is the only way to get it on chain currently. Would it work for you if instead we pulled the list of wells from our subgraph? The upgradeable wells have a hardcoded mapping there until an on chain solution can be developed.

yup, this is a good solution

[g1nt0ki]

*pulling list of wells from subgraph

[llamatester]

The adapter at projects/basin exports TVL:

arbitrum                  6.69 M
ethereum                  5.98 k

total                    6.69 M 

[soilking]

Great, this is done

[llamatester]

The adapter at projects/basin exports TVL:

arbitrum                  6.79 M
ethereum                  6.07 k

total                    6.80 M