Write Aave adapter for Bob protocol

[smol-ninja]

Similar to Lido adapter, write an Aave adapter for supported tokens on Aave.

[andreivladbrg]

Before starting, I'd like to align on the API design for the Aave adapter integration.

The current architecture maps one default adapter per token (_defaultAdapters[token]). Since a token could now have both a Lido and an Aave adapter (e.g. WETH), we need to decide how to handle multiple adapters for the same token.

Option A — Breaking change:
Add an AdapterType enum (None, Lido, Aave) and modify createVault / enter to accept it. The _defaultAdapters mapping would become mapping(IERC20 => mapping(AdapterType => ISablierBobAdapter)), so the caller explicitly selects which yield strategy to use. This is cleaner long-term but breaks the existing interface.

Option B — Non-breaking:
Keep the current enter and _defaultAdapters untouched. Add a separate _defaultAaveAdapters mapping and a new enterWithAaveAdapter function that routes deposits through the Aave adapter instead. Avoids breaking changes but duplicates entry-point logic and doesn't scale well if more adapters are added later.

I'd lean toward Option A — it's a cleaner abstraction and avoids accumulating adapter-specific entry points as we add more yield strategies.

Which direction do you prefer? @sablier-labs/evm

[smol-ninja]

Why would a token have more than one adapter? IMO one token should only have one adapter configured for it. Aave is mostly going to be used for non ETH tokens.

We should write Aave adapter in such a way that it should be compatible with the existing Bob release. This is why we have a separate ISablierBobAdapter interface so that we can write more adapters without making any change to Bob contract.

[PaulRBerg]

Yes. KISS

[andreivladbrg]

A few reasons why I think multiple adapters per token is worth considering:

• WETH can have a higher APY on Aave than Lido under certain market conditions — users & us might want to pick the better yield.
• WETH is the token with the highest TVL on aave
• Users should be able to choose their adapter based on their own risk assessment. Someone might consider the Lido adapter less secure than Aave, or vice versa.
• To clarify — I'm not talking about changes to the SablierAaveAdapter contract itself. The question is whether SablierBob needs changes to support routing to different adapters for the same token.

and btw, speaking of ISablierBobAdapter interface, it uses "staking" terminology throughout (stake, unstakeFullAmount, updateStakedTokenBalance, etc.).
As we discussed on Slack, Aave is lending, not staking. We should probably rename these to something protocol-agnostic (e.g. enter/deposit / withdrawFullAmount / updateDepositBalance) so the interface fits both adapters without being misleading (as aave has both stake and lending products)

[smol-ninja]

You have made great points but we just released Bob v1.0 so I would prefer to avoid releasing a new protocol so fast.

Agree with staking/lending terminology but that can be abstracted way by the UI.

We can release multiple adapters for Bob v1.0 and that will teach us a few lessons about the design and interface and then using those lessons, we can release a massive Bob v2.0 in the far future but not now imo.

[smol-ninja]

It may not look like the perfect code after Aave adapter (because of staking terminology) but it will still work. Naming is hard and as soon as we decide to build a third adapter, I am very certain we will want to make more changes to Bob or naming in general.

[andreivladbrg]

You have made great points but we just released Bob v1.0 so I would prefer to avoid releasing a new protocol so fast.

who said it's a new protocol? 😅

Agree with staking/lending terminology but that can be abstracted way by the UI.

it would be fast using agents to rename things, but the confusion is not worth it imo

massive Bob v2.0 in

given the audit findings we had in the current lido adapter, having a new protocol adapter is already pretty "huge"

the time difference wouldn't be big IMO for these polish improvements

[andreivladbrg]

it would lead to code quality debt

[smol-ninja]

who said it's a new protocol? 😅

I meant a new release. Making a new release for Bob would also mean making new release for Lido adapter which I think is not worth it in such a short period.

it would lead to code quality debt

I agree but we can live with that. In Bob v2.0, we can make a massive upgrade. I am very inclined towards writing the new adapter to fit the current Bob release.

[PaulRBerg]

Agree with @smol-ninja, we should stick with v1.0 structure.