Skip to content

Evaluate Meru for an adapter #26

Description

@dubemoyibe-star

Context

Meru appears in Stellar ecosystem listings tagged as lending on mainnet, but hasn't been assessed against the independence bar. It's the only known outstanding candidate that could slot into the existing taxonomy with no methodology work — if it clears.

Two protocols have already been investigated and rejected on this bar: YieldBlox turned out to be a community-managed pool on Blend V2 rather than an independent protocol, and Templar's lending state lives on NEAR with only its price oracle native to Stellar. Meru gets the same treatment. The evaluation is the work here; the adapter only follows if it passes.

Scope

In scope: confirm from Meru's own contracts and documentation whether it is an independently-scoreable, native-Soroban lending protocol on mainnet. If it clears, implement the adapter against the existing Adapter interface and five-factor taxonomy.
Out of scope: writing any scoring logic before the independence check passes. If it fails, the deliverable is the documented finding, not code.

Acceptance criteria

  • Independence confirmed from Meru's own source or contract addresses — not another Blend deployment, not a chain-abstraction protocol whose lending state lives elsewhere
  • Confirmed live on Stellar mainnet with meaningful TVL (dust-TVL protocols are out of scope — see the Peridot and Slender precedent)
  • Reserves, utilization, and oracle state confirmed readable via Soroban RPC and Horizon
  • If it clears: all five *Safety factors populated from real on-chain data, each anchored to Meru's own protocol parameters rather than Blend's or K2's numbers
  • Any factor that genuinely can't be computed is flagged rather than approximated
  • If it clears: verified end-to-end through indexer, DB, API, and UI
  • If it fails: the finding documented in ROADMAP.md under investigated-and-skipped, with the specific reason, same as YieldBlox and Templar
  • METHODOLOGY.md updated with any protocol-specific anchoring decisions

Difficulty

Hard — design decision required before code

Notes / open questions

The independence check is the majority of the work. The scoring code is comparatively mechanical once the interface is understood — the Blend and K2 adapters are both available as reference implementations covering two genuinely different on-chain shapes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue maybe eligible for a GrantFox rewardOfficial Campaign | FWC26Official Campaign | FWC26adaptertouches core adapter logichelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions