Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retroactive Morpho reward Distribution automation #1563

Open
Xeonus opened this issue Dec 9, 2024 · 3 comments · May be fixed by #1575
Open

Retroactive Morpho reward Distribution automation #1563

Xeonus opened this issue Dec 9, 2024 · 3 comments · May be fixed by #1575
Assignees

Comments

@Xeonus
Copy link
Collaborator

Xeonus commented Dec 9, 2024

Morpho wants to distribute MORPHO rewards to boosted pool depositors. At the moment, they only distribute rewards every 2 weeks based on the 2 previous weeks deposits into their vaults. Given this, the cleanest solution is to also count boosted pool deposits retroactively and distribute rewards accordingly

Requirements

  • Morpho tracks rewards to v3 vault
  • Maxis provide code-base to track deposits into boosted pools retroactively (v3 subgraph has pool snapshots)
  • Rewards get distributed to depositors either by Morpho or Maxis

Not clear yet:

  • If Morpho will send rewards to a new safe or do its own distro based on our airdrop csv
  • Angle can't do retroactive campaigns, so we need to do our own airdrop

Implementation details

Example: deployed test pool on Gnosis chain

Endpoint: https://api.studio.thegraph.com/query/75376/balancer-v3-gnosis/version/latest

Query operation:

query Users($where: User_filter, $block: Block_height) {
  users(where: $where, block: $block) {
    shares {
      balance
      id
      user {
        id

      }
    }
  }
}

Variables:

{
  "where": {
    "shares_": {
      "pool_in": [
        "0xd1d7fa8871d84d0e77020fc28b7cd5718c446522"
      ],
      "balance_gt": 0.0001
    }
  },
  "block": {
    "number_gte": 37435326
  }
}

Response:

{
  "data": {
    "users": [
      {
        "shares": [
          {
            "balance": "0.210018189788151984",
            "id": "0xd1d7fa8871d84d0e77020fc28b7cd5718c446522-0x75d06bae37a9c349142fe7cee77804900b1c0ec3",
            "user": {
              "id": "0x75d06bae37a9c349142fe7cee77804900b1c0ec3"
            }
          }
        ]
      }
    ]
  }
}
```
@gosuto-inzasheru
Copy link
Collaborator

@Xeonus
Copy link
Collaborator Author

Xeonus commented Dec 10, 2024

As discussed with Fabio and Franz and @gosuto-inzasheru , the subgraph has data for each block. We therefore shall query by a set of blocks every x hours to get shares. As there are no gauges yet, this approach is ok. Need to add additional logic once staking gauges go live! We can reuse some logic from this repo Trit made: https://github.com/BalancerMaxis/ecosystem_balances_example

More efficient query logic shared here

Query:

query PoolShares($where: PoolShare_filter, $block: Block_height) {
  poolShares(where: $where, block: $block) {
    user {
      id
      shares {
        balance
      }
    }
  }
}

Variables (example for gnosis boosted v3 pool):

{
  "where": {
    "balance_gt": 0.001,
    "pool_in": ["0xd1d7fa8871d84d0e77020fc28b7cd5718c446522"]
  },
  "block": {
    "number": 37435326
  }
}

@gosuto-inzasheru
Copy link
Collaborator

@Xeonus Xeonus removed their assignment Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants