Skip to content

midas-rwa: mGLO and mGLOBAL missing from adapter (~$81M used as collateral) #2964

Description

@yieldhunting

The midas-rwa adapter configures 26 products, but at least two Midas funds with material size are missing, plus one chain. All three are already being used as collateral on lending venues, so they show up in the yields data only as apyBase: 0 collateral rows with no source pool behind them.

Missing

product chain token evidence
mGLO Base 0xFCc9Cc1209651Ed8867332d6F664CF82743A2584 $26.4M as Morpho Blue collateral
mGLO Robinhood Chain 0xFEd493F38c1aAcb4EA4e6A11F8b9287849EE0096 $24.5M as Morpho Blue collateral; chain not configured in addresses.js
mGLOBAL Ethereum 0x7433806912Eae67919e66aea853d46Fa0aef98A8 $30.5M on Aave Horizon

Verified on-chain:

Base     0xFCc9Cc12…  name="Midas Fasanara Global Open"  symbol=mGLO     supply=26,487,520
Ethereum 0x74338069…  name="Midas Fasanara Global"       symbol=mGLOBAL  supply=66,235,380

(mGLO also exists on Ethereum at 0x1DD91a111606382B77A917633ED90feAf25E0F76, but total supply there is ~2.5 tokens, so mainnet looks like a placeholder deployment rather than where the float lives.)

What's needed

Each entry in addresses.js needs a dataFeed whose aggregator() resolves, since getAggregatorAddress() returns null when that call reverts and the product is then skipped.

I traced the Base mGLO price path as far as:

Morpho oracle 0x182e072F2C9C58c6F19F144c97986F7496c6A109
  BASE_FEED_1() -> 0x3732F1E48499922426F9Ddad37D79C98B1fBf29E  "mGLO/USD PriceLowered"
    underlyingFeed() -> 0x6B593a5FAbb90F36e125562Db833f761d274fcBC  "mGLO/USD"

but 0x6B593a… is a raw aggregator — it has no aggregator() or getDataInBase18(), so it isn't the MidasDataFeed wrapper the adapter expects. I didn't want to guess at the correct wrapper addresses and submit a PR that silently skips these products, hence an issue rather than a patch.

If someone with the canonical deployment list can supply the dataFeed address per product/chain, I'm happy to open the PR adding them. Alternatively, getAggregatorAddress() could fall back to treating the configured address as the aggregator when aggregator() reverts, which would make raw aggregators usable directly — but that's a behavioural change to a shared helper and seemed worth raising before making it.

Related: #2963 marks the products the adapter does cover as intrinsic APY sources, which is the same underlying gap (yield-bearing collateral showing 0% at the lending venue).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions