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

[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

[Adecom16]

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

[PrevailUgah]

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

[collinsezedike]

@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?

[subheeksh5599]

hi, interested. recently shipped anchorfx on stellar mainnet and completed fwc26 issues across grainlify, finchippay, guildpass — rust + soroban contracts (grainlify, finchippay, guildpass mainnet work). approach:

1. read the contract + existing tests
2. implement with the repo's conventions
3. add tests, run cargo test, link PR
   can submit a PR today. happy to adjust to feedback.

[playmaker410]

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.