Integrate staking amount requirement - #3632
Conversation
- Added ExchangeApiKeysModule for managing exchange API keys. - Added validation for exchange names using ExchangeNameValidator. - Integrated AES encryption for storing API keys securely. - Implemented exchange-specific services (GateExchangeService, MexcExchangeService) for interacting with respective APIs. - Enhanced AuthService to check staking eligibility based on exchange balances. - Added configuration services for encryption and staking parameters. - Created migration for the exchange_api_keys table in the database.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
4 Skipped Deployments
|
dnechay
left a comment
dnechay
left a comment
There was a problem hiding this comment.
Just a though: it can probably make sense to have just exchanges module where you have all the logic of working with api keys and exchange APIs to avoid circular dependencies and simplify how you instantiate exchange client with api keys of specific user
Review summary
Implementation-wise (i.e. not taking into account code-style/refactoring comments) I have a question regarding of UX of this feature.
Right now in case of errors from exchange (no matter what error: access error or network error) we always fallback to 0 balance. It can lead to situations when some request had a short "hiccup" (dumb network error) and as a result user has "not eligible stake" for the whole JWT lifetime, and for the user it will look like they just don't have any oracles/jobs even if they have necessary staked amount, so that would be very confusing and only thing on how they can understand that is to reach our support, we go to logs, see error and etc. Another case is that they staked after the sing in: they will have to wait until token refresh.
Would be nice to discuss some options of how we can improve this (if we need to, because maybe it's fine to just let them know about "delays"). Maybe instead of having stake_eligible: boolean we can have some sort of stake_status: 'eligible' | 'error' | 'not_eligible' that will help UI to distinguish between different states and to show some hints + ability to trigger refresh. That might be an overhead though, so let's discuss it internally
- Introduced ExchangeClientFactory to handle exchange client creation for different exchanges. - Implemented GateExchangeClient and MexcExchangeClient for API interactions. - Removed deprecated ExchangeRouterService and related services. - Updated error handling to include ExchangeApiClientError for better clarity.
dnechay
left a comment
dnechay
left a comment
There was a problem hiding this comment.
LGTM overall
- Please change back volume for services as mentioned in the earlier comment
- Let's wait for UI/UX to make sure they are aligned
- Can add unit tests where necessary (e.g. for
auth.service) - Let's try to DRY send request logic in each of exchange clients (i.e. separately for each exchange, not one logic shared across all of them)
…geClient, MexcExchangeClient and exchangeApiKeyService
flopez7
added
the
do-not-merge
… to return null and zero respectively
…TOs; update env schema and service logic
Co-authored-by: Dmitry Nechay <lelekkofe@gmail.com>
4 participants
Issue tracking
Close #3618, #3560, #3619, #3633
Context behind the change
Reputation Oracle:
Human App:
How has this been tested?
In progress
Release plan
Add new
AES_ENCRYPTION_KEYandSTAKING_ELIGIBILITY_ENABLEDin Reputation OracleAdd
VITE_STAKING_DASHBOARD_URLin Human App FEPotential risks; What to monitor; Rollback plan
Not yet defined