Illuminate Protocol Vetting

[futurethang]

What Feature or Capability does this idea introduce?

Starting to work towards an initial concept for our aggregators API.

Is it related to existing features or Works in progress, or all new work? (Link issue refs)

Not particularly outside of the contract efforts ongoing.

Its late while im writing this so ill likely come back and edit / fill this out further.

I'd like to start introducing the requirements from illuminate's API, as well as the pain points we may face.

A lot of this is highlighted in this overview:

LINK

The only part of the application of the three primary domains (lending, pooling, redeeming) that the API really should touch (or needs to) is lending.

The Illuminate API serves as the primary way for our frontend to request the "best rate" across ~7 AMM's + Swivel's Orderbook. Simply described, the goal is to request the amount of zcTokens returned given an amount in, and then return whichever protocol & quote to the frontend that would return the most zcTokens.

Intricacy comes in due to the differences between each protocol, and the limitations of AMMs when it comes to accurate on-chain predictions.

To get the quote from each AMM you need to (difficulty scaled 1-10):

Yield: On-Chain function - static pool address per market - Difficulty: 1 Illuminate (Yield Fork): On-Chain function - static pool address per market - Difficulty: 1 Tempus: Add 1-1 amount of tokenIn to the return of On-Chain function - static "amm" (pool) address per market - Difficulty: 3 (trades nTokens for zcTokens directly) APWine: On-Chain function - static "amm" (pool) address per market - Difficulty: 4 Element: Off-Chain SDK (I believe) - static pool per market (requires 2 pool params) - Difficulty: 8 (SDK is javascript) Sense: Off-Chain SDK (I believe) - Same as Element Pendle: On Sushiswap, likely Off-Chain SDK - static pool per market- Difficulty: 5-6 Swivel: Ping API + Yieldwith premium - one API for all markets - Difficulty: 3-4 Notional: On-Chain Method -- Complies with ERC-4626 -- Difficulty: 1

Notional Edit: Looks like we can probably use their fcash wrapper and do something like convertToUnderlying to determine the price?

[futurethang]

from @JTraversa :

As far as questions as to whether we should index any of the data, or just rely on reactive reads, I'm open to thoughts.

The concern with indexing is that the quotes may be inaccurate if there is high volume but 🤷.

The concern with reading when requested I assume is DDOS, as well as the fact that the provided SDK's are all in typescript/javascript and are likely slower than we might hope?

[futurethang]

@JTraversa I'm fiddling with UI ideas and wondering about Illuminate allowing for Advanced Settings on transactions, like adjusting max gas fees and slippage rates. In my mind that should all be achievable with wallet interactions, but I am also curious whether those mechanics come into play at all with how the Illuminate contract itself is written, given the routing aspects. Or rather, if such a concern gives rise to opportunity for superior UX at the contract level and not just making for flexible UI.

[JTraversa]

Advanced Settings is a fine thing to add, and it primarily relates to slippage and a transaction deadline.

illuminate.sol doesnt have minimumReceived amount params (converted from slippage), which would be used to revert upon a case where that minimum isnt reached.

This is a design addition I'd be comfortable with. But unless we add those to every illuminate function, the minimum is only relevant for certain AMMs in illuminate's current state.

[clarkahthompson]

Question; on the rates returned via the API, presumably these are all retrieved in parallel as close together in time as possible. But given different latency under high volume, how would we address stale quotes? Throw them out if they take too long, refresh the faster ones? Would we have a minimum number requirement before displaying best rate? What about two or more of the same “best” rate?