feat: add fee detector #338
Conversation
marktoda
force-pushed
the
add-fee-detector
branch
2 times, most recently
from
b8ff275 to
913f64e
Compare
marktoda
force-pushed
the
add-fee-detector
branch
from
913f64e to
0baee94
Compare
marktoda
force-pushed
the
add-fee-detector
branch
from
8ffaf8e to
3c4aa2e
Compare
|
From the slack thread, it sounds like interface will use it as FOT workaround to begin with. routing team still evaluating whether we need to take on quoting FOT after we mitigate the quote latencies. |
The old one still serves a different purpose! it categorizes based on whether the token has a fee at all, or fails on transfer. It also allows checking against multiple bases, which doesn't make as much sense here because which fee would we show if it was different depending on the base |
There was a problem hiding this comment.
Appreciate you jumping on this @marktoda! Handful of comments, feel free to ping me for any questions; happy to elaborate.
| return { | ||
| getFeesByToken: (token: Token) => | ||
| tokenToResult[token.address.toLowerCase()], | ||
| }; | ||
| } |
There was a problem hiding this comment.
I'm also not a fan of returning anonymous functions as part of the response rather than objects of a specific class.
Could we instead do:
export class TokenFeeResults {
constructor(private readonly tokenToResult: { [tokenAddress: string]: TokenFeeResult }) {}
getFeesByToken(token: Token): TokenFeeResult | undefined {
return this.tokenToResult[token.address.toLowerCase()];
}
}
and here return:
return new TokenFeeResults(tokenToResult);
| constructor( | ||
| private chainId: ChainId, | ||
| private multicall2Provider: IMulticallProvider, | ||
| private tokenFeeCache: ICache<TokenFeeResult>, |
There was a problem hiding this comment.
As I'm working on the router backend support for FOT, I realized that this TokenFeeProvider is tightly coupled with the in-memory ICache. We will need both in-memory memory (for client-side fallback), as well as dynamo caching (for routing-api distributed caches).
I think I will create another PR, meanwhile leveraging the insights and feedbacks from this PR.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
Other information: