[Feature] TVL/APY displays can go stale indefinitely with no accrual keeper

[collinsezedike]

Summary

accrue() on blend-adapter is permissionless and documented as needing to be called "by the vault or a keeper" before any pricing-relevant read, but nothing in the repo ever calls it outside contract/test/docs code — no scheduled job, cron, or backend service. fetchTestnetVaults() (used for the dashboard's TVL and for recommendedVaultId) reads get_total_assets via a read-only RPC simulation, which never submits a transaction, so it can never itself trigger a persisted accrual. Only a real submitted transaction can update the cached total on-chain.

Motivation

This is distinct from #418 (which fixes deposit/withdraw-time pricing by refreshing inside a real submitted transaction): TVL and APY shown on the dashboard for a quiet Blend-backed vault can go stale indefinitely even after #418 lands, because the dashboard's read path is a simulation, not a submitted transaction. DeFindex-backed vaults aren't affected since total_assets() is computed live there, but any Blend-backed vault with no recent deposit/withdraw activity will show an increasingly wrong TVL/APY to users just browsing the dashboard.

Proposed Solution

Stand up a scheduled keeper that periodically submits a real accrue() transaction for each live Blend-backed adapter. This needs: a funded Stellar signing key with nonce/sequence-number management (submitting accrue() costs fees even though the call itself needs no auth), a way to discover which live adapters are Blend-backed vs DeFindex-backed (only Blend needs accrual), a sensible accrual interval, and monitoring/alerting if an accrual transaction fails so stale pricing doesn't go unnoticed.

Scope

Field	Value
Area	API / Contracts / CI
Protocol affected	Blend
Network	testnet
Breaking change?	No (new operational service, no ABI change)

Alternatives Considered

Relying on deposit/withdraw activity to keep accrue() fresh incidentally: this is the current de facto behavior, but it means TVL/APY accuracy for quiet vaults depends entirely on other users' unrelated activity, which isn't a real guarantee.

Acceptance Criteria

• A scheduled process periodically submits accrue() for each live Blend-backed adapter
• Adapter discovery correctly distinguishes Blend-backed (needs accrual) from DeFindex-backed (doesn't) vaults
• Signing key and sequence-number handling documented, with the key scoped to only what accrue() submission needs
• Failure to submit an accrual transaction is observable (logged/alerted), not silent
• Documented expected max staleness window for TVL/APY under normal operation

[Adecom16]

I will like to jumpon this issue.

I'll implement a scheduled keeper to periodically submit accrue() for Blend-backed adapters, ensure reliable adapter discovery and sequence management, add logging for failed submissions, and document the operational setup and expected TVL/APY staleness window. I'll validate the implementation before opening the PR.

[PrevailUgah]

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

[collinsezedike]

@Adecom16 you've still got #475 open for #459, and now you're on this one too. How are you thinking about sequencing all three? Would you take this after the other two land, or in parallel?

Separately, since this one is really operational infrastructure rather than a pure code change: where does the keeper's signing key live, and how do you handle fee costs for repeated accrue() submissions? And what happens in your design if a submission fails, does it retry, alert, or silently skip that cycle?

[Adecom16]

Thanks for checking. I'll take these sequentially rather than in parallel. I'm wrapping up #459 first, then I'll move to this one once it's reviewed.

For the keeper, my plan is to keep the signing key outside the codebase via environment variables or a secrets manager, discover only Blend-backed adapters, submit scheduled accrue() transactions with proper sequence-number management, and make failures observable through structured logging with retry/backoff and alerting rather than silently skipping cycles. I'll document the operational assumptions and expected staleness window as part of the PR.

[collinsezedike]

Thank you, that's a solid plan, especially the retry/alerting over silent-skip and keeping the key out of the codebase.

You mentioned sequencing #459 then this one, but you're also on #460. Where does that fit? I'd rather assign one or two at a time than have three queued if that's not realistic.

Assigning this to you now on the sequential plan: #459 first, then this one.

[grantfox-oss]

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

Next steps:

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

Good luck! Track your progress on GrantFox.