Skip to content

[Chore] Deduplicate adapter boilerplate between blend-adapter and defindex-adapter #460

Closed

Description

@collinsezedike

Summary

blend-adapter and defindex-adapter both implement the vault's YieldAdapterInterface, but they duplicate storage-key definitions, initialize(), and admin/pool-getter boilerplate rather than sharing a common base. The two contracts' actual yield-source logic legitimately differs (that shouldn't be merged), but the surrounding scaffolding is copy-pasted.

Motivation

Right now a change to the shared scaffolding (e.g. how the admin address is stored, or how require_auth() is applied on init) has to be made twice and can silently drift between the two contracts. This is maintenance risk, not a correctness bug today, but it's the kind of thing that turns into a real inconsistency the next time someone touches one adapter without remembering to mirror the other.

Proposed Solution

Extract the shared scaffolding (storage keys, initialize(), admin storage/read helpers, any other boilerplate common to both adapters) into a shared crate or module under packages/contracts that both blend-adapter and defindex-adapter depend on. Each adapter keeps its own yield-source-specific logic (accrue(), rate conversion, pool/vault interaction) implementing the interface on top of the shared base.

Scope

Field Value
Area Contracts
Protocol affected Both
Network testnet
Breaking change? No (internal structure only, same ABI)

Alternatives Considered

Leaving the duplication as-is: acceptable short-term since both adapters are small and the interface keeps them aligned externally, but doesn't scale if a third adapter is added.

Acceptance Criteria

  • Shared scaffolding (storage keys, initialize(), admin helpers) lives in one place, not two
  • blend-adapter and defindex-adapter still pass their full existing test suites unmodified in behavior
  • No change to either contract's external ABI or deployed interface
  • cargo clippy --all-targets -- -D warnings, cargo fmt --all -- --check, and cargo test pass in packages/contracts

Activity

  1. added
    hardComplex implementation spanning multiple packages or involving Soroban contracts
    contractsInvolves writing or testing Rust/Soroban contracts in packages/contracts
    choreBuild, CI, dependency updates, or repository maintenance
    on Aug 3, 2026
  2. Adecom16 commented on Aug 4, 2026

    @Adecom16
    Contributor

    I'll extract the shared adapter scaffolding into a reusable module while preserving the existing contract behavior and ABI. I'll ensure both adapters continue to pass their current test suites and validate the changes with cargo fmt, cargo clippy, and cargo test before submitting the PR.

    I will like to jump on this

  3. PrevailUgah commented on Aug 5, 2026

    @PrevailUgah

    Hey maintainer! I'd love to work on this issue.

  4. collinsezedike commented on Aug 6, 2026

    @collinsezedike
    CollaboratorAuthor

    @PrevailUgah before I assign this, what's your read on why blend-adapter and defindex-adapter currently duplicate their initialize()/storage-key boilerplate instead of already sharing it? And concretely, what would you pull into the shared piece versus leave separate?

  5. playmaker410 commented on Aug 7, 2026

    @playmaker410
    Contributor

    Hi Maintainer,
    I’d love to take this on. I have hands-on experience with Rust, Soroban, Cairo, and TypeScript, and I’m confident I can deliver a solid solution within 24 hours.

  6. Adecom16 commented on Aug 8, 2026

    @Adecom16
    Contributor

    I'll extract the shared adapter scaffolding into a reusable module while preserving the existing contract behavior and ABI. I'll ensure both adapters continue to pass their current test suites and validate the changes with cargo fmt, cargo clippy, and cargo test before submitting the PR.

    I will like to jump on this

  7. collinsezedike commented on Aug 8, 2026

    @collinsezedike
    CollaboratorAuthor

    @Adecom16 I'm impressed by your contributions.
    Would love you to take this one.

  8. grantfox-oss commented on Aug 8, 2026

    @grantfox-oss

    🦊 GrantFox — @Adecom16 has been assigned to this issue!

    Next steps:

    1. Open a Pull Request referencing this issue (e.g., Closes #460)
    2. Your PR will be reviewed by the drydocs maintainers

    Good luck! Track your progress on GrantFox.

  9. collinsezedike commented on Aug 16, 2026

    @collinsezedike
    CollaboratorAuthor

    @Adecom16 checking in, any progress on this? Let me know if you're still working on it or if you'd like to hand it off.

  10. Adecom16 commented on Aug 18, 2026

    @Adecom16
    Contributor

    @Adecom16 checking in, any progress on this? Let me know if you're still working on it or if you'd like to hand it off.

    I'm almost done boss

  11. added a commit that references this issue on Aug 19, 2026
    564119e
  12. grantfox-oss commented on Aug 21, 2026

    @grantfox-oss

    🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

    @Adecom16's PR #541 was approved and merged by @collinsezedike.

    🏆 @Adecom16: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (118 total points). Track your full progress on GrantFox.

    👏 Great work, @Adecom16! Keep contributing to drydocs.

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

Metadata

Metadata

Assignees

Labels

GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardThird CampaignCampaign: Third CampaignchoreBuild, CI, dependency updates, or repository maintenancecontractsInvolves writing or testing Rust/Soroban contracts in packages/contractshardComplex implementation spanning multiple packages or involving Soroban contracts

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions