Add tier tracker #9
Conversation
This reverts commit 22fc28b.
WalkthroughThe updates introduce significant enhancements across multiple files. Key changes include updating addresses and start blocks in the configuration, adding new data points and tables in the schema, and implementing new functions in the helper and index files to manage user data and wallet tiers. Additionally, the user history interface has been extended to track new boolean fields. These modifications collectively improve the system's ability to handle new wallet interactions and data points more effectively. Changes
Sequence Diagram(s) (Beta)sequenceDiagram
participant User
participant System
participant Database
User->>System: Initiates wallet interaction
System->>Database: Check if wallet is first in chain
Database-->>System: Returns wallet status
System->>User: Updates user history with new boolean fields
System->>Database: Update WalletsPerTier table
Poem
TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (6)
- ponder.config.ts (5 hunks)
- ponder.schema.ts (4 hunks)
- src/config/constants.ts (1 hunks)
- src/helpers.ts (7 hunks)
- src/index.ts (25 hunks)
- src/types.ts (1 hunks)
Files skipped from review due to trivial changes (1)
- src/config/constants.ts
Additional context used
Biome
src/helpers.ts
[error] 191-191: Unnecessary continue statement (lint/correctness/noUnnecessaryContinue)
Unsafe fix: Delete the unnecessary continue statement
Additional comments not posted (42)
src/types.ts (1)
45-54: LGTM! Ensure that these new fields are properly integrated and utilized in the application logic.Verification successful
The new fields
chainFirstWallet,firstWalletInVPNDLM,firstWalletInVAPELM, andfirstSwapare integrated and utilized in the application logic as follows:
- ponder.schema.ts: The fields are defined as boolean properties.
- src/index.ts: The fields are used in data assignments and conditional checks.
- src/helpers.ts: The fields are used in data assignments and initializations.
These usages indicate that the new fields are properly integrated into the application logic.
ponder.schema.ts:
chainFirstWallet: p.boolean()firstWalletInVPNDLM: p.boolean()firstWalletInVAPELM: p.boolean()firstSwap: p.boolean()
src/index.ts:
data: { firstWalletInVPNDLM: true }data: { firstWalletInVAPELM: true }if (!userData.firstSwap)data: { firstSwap: true }
src/helpers.ts:
data: { chainFirstWallet: true }firstWalletInVPNDLM: falsefirstSwap: falsefirstWalletInVAPELM: falsechainFirstWallet: falseThese findings confirm that the new fields are being utilized correctly in the application.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify integration of new fields in UserHistory interface. # Test: Search for usage of new fields in the application. Expect: Proper handling and usage. rg --type ts $'chainFirstWallet|firstWalletInVPNDLM|firstWalletInVAPELM|firstSwap'Length of output: 903
ponder.config.ts (1)
Line range hint
46-79: LGTM! Verify that the new start blocks align with the intended blockchain events or deployments.ponder.schema.ts (3)
43-45: LGTM! Ensure that these new point sources are correctly integrated into the points calculation logic.Verification successful
The new point sources
chain_first_walletanddex_aggregator_first_swapare correctly integrated into the points calculation logic insrc/index.tsandsrc/helpers.ts.
- In
src/index.ts,dex_aggregator_first_swapis used to create a newPointsentry with the appropriate data.- In
src/helpers.ts,chain_first_walletis similarly used to create a newPointsentry with the relevant data.These integrations ensure that the new point sources are properly handled within the application.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify integration of new point sources. # Test: Search for usage of new point sources in the application. Expect: Proper handling and usage. rg --type ts $'chain_first_wallet|dex_aggregator_first_swap'Length of output: 273
Script:
#!/bin/bash # Extract relevant code snippets from src/index.ts and src/helpers.ts to verify integration of new point sources. # Extract lines around the usage of 'dex_aggregator_first_swap' in src/index.ts rg --context 5 --type ts 'dex_aggregator_first_swap' src/index.ts # Extract lines around the usage of 'chain_first_wallet' in src/helpers.ts rg --context 5 --type ts 'chain_first_wallet' src/helpers.tsLength of output: 883
149-155: LGTM! Ensure that theWalletsPerTiertable is correctly utilized for managing user tiers.
Line range hint
90-114: LGTM! Ensure that the database migrations for these new fields and tables are properly executed and that data integrity is maintained.src/helpers.ts (3)
61-93: LGTM! Ensure that thehandleChainFirstWalletfunction is correctly handling first wallet events and interacting with the database as intended.Verification successful
The function
handleChainFirstWalletis correctly used insrc/index.tsafter callinggetOrCreateUserData, which ensures that the necessaryuserDatais provided. The context and usage of both functions appear to be consistent and appropriate.
handleChainFirstWalletis used insrc/index.tsto handle first wallet events and interact with the database as intended.getOrCreateUserDatais defined insrc/helpers.tsand provides the necessaryuserDataforhandleChainFirstWallet.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify correct handling of first wallet events by `handleChainFirstWallet`. # Test: Search for usage of `handleChainFirstWallet` in the application. Expect: Proper handling and interaction with the database. rg --type ts $'handleChainFirstWallet'Length of output: 305
Script:
#!/bin/bash # Extract lines from `src/index.ts` where `handleChainFirstWallet` is used to understand its context and usage. rg --type ts --context 5 'handleChainFirstWallet' src/index.tsLength of output: 939
Script:
#!/bin/bash # Extract lines from `src/helpers.ts` where `getOrCreateUserData` is defined and used to understand its context and usage. rg --type ts --context 5 'getOrCreateUserData' src/helpers.tsLength of output: 536
396-428: LGTM! Ensure that thegetOrUpdateWalletsPerTierfunction is correctly managing wallets per tier and interacting with the database as intended.Verification successful
The implementation and usage of the
getOrUpdateWalletsPerTierfunction have been reviewed. The function is correctly defined insrc/helpers.tsand is used insrc/index.tsto manage wallets per tier. The database interactions (findUnique, create, update) appear to be correctly implemented and used.
Implementation in
src/helpers.ts:export async function getOrUpdateWalletsPerTier( context: Context, tierId: bigint, userAddress: string ): Promise<any> { const { WalletsPerTier } = context.db; const { chainId } = context.network; const id = `${tierId}-${chainId}`; let walletsPerTier = await WalletsPerTier.findUnique({ id }); if (!walletsPerTier) { walletsPerTier = await WalletsPerTier.create({ id, data: { wallets: [userAddress], }, }); } if (!walletsPerTier.wallets.includes(userAddress)) { walletsPerTier.wallets.push(userAddress); walletsPerTier = await WalletsPerTier.update({ id, data: { wallets: walletsPerTier.wallets, }, }); } return walletsPerTier; }Usage in
src/index.ts:import { ponder } from "@/generated"; import { getOrCreateUserData, queryQuote, getTokenId, getOrUpdateTokenIdData, handleChainFirstWallet, getOrUpdateWalletsPerTier, } from "./helpers"; // Usage example await getOrUpdateWalletsPerTier(context, 0n, userAddressLowerCase); ponder.on("LiquidMining:Deposit", async ({ event, context }) => { const { Points, UserHistory, LiquidMining } = context.db; const { hash } = event.transaction; const { chainId } = context.network; const { seasonId, user: userAddress, amount } = event.args; const userAddressLowerCase = userAddress?.toLowerCase(); const tokenId = await getTokenId(userAddressLowerCase as Address, context); const timestamp = event.block.timestamp; const tier = await context.client.readContract({ abi: context.contracts.RewardsController.abi, address: context.contracts.RewardsController.address as `0x${string}`, functionName: "tierOf", args: [tokenId], }); await getOrUpdateWalletsPerTier(context, tier, event.args.member); });The function is used in scenarios where wallet tiers need to be updated or created based on events, ensuring proper handling and interaction with the database.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify correct functionality of `getOrUpdateWalletsPerTier`. # Test: Search for usage of `getOrUpdateWalletsPerTier` in the application. Expect: Proper handling and interaction with the database. rg --type ts $'getOrUpdateWalletsPerTier'Length of output: 311
Script:
#!/bin/bash # Description: Verify the implementation and usage of `getOrUpdateWalletsPerTier`. # Step 1: Review the implementation of `getOrUpdateWalletsPerTier` in `src/helpers.ts`. echo "Implementation of getOrUpdateWalletsPerTier in src/helpers.ts:" rg --context 10 'export async function getOrUpdateWalletsPerTier' src/helpers.ts # Step 2: Review the usage of `getOrUpdateWalletsPerTier` in `src/index.ts`. echo "Usage of getOrUpdateWalletsPerTier in src/index.ts:" rg --context 10 'getOrUpdateWalletsPerTier' src/index.tsLength of output: 2364
Line range hint
164-175: LGTM! Ensure that the updatedqueryQuotefunction is correctly querying quotes with the new aggregator address parameter.Verification successful
The updated
queryQuotefunction correctly handles the newaggregatorAddressparameter, which is passed asevent.log.address. This address is a valid Ethereum address in the context of theDexAggregator:RouterSwapevent.
src/index.ts: The call toqueryQuotecorrectly passesevent.log.addressas theaggregatorAddressparameter.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify correct functionality of updated `queryQuote`. # Test: Search for usage of `queryQuote` in the application. Expect: Proper handling of new aggregator address parameter. rg --type ts $'queryQuote'Length of output: 158
Script:
#!/bin/bash # Description: Inspect the call to `queryQuote` in `src/index.ts` to ensure the new parameter is correctly handled. # Extract the relevant lines around the call to `queryQuote` in `src/index.ts` rg --context 5 'queryQuote' src/index.tsLength of output: 455
Script:
#!/bin/bash # Description: Verify the context of `event.log.address` in `src/index.ts` to ensure it is a valid Ethereum address. # Extract the relevant lines around the usage of `event.log.address` in `src/index.ts` rg --context 10 'event.log.address' src/index.tsLength of output: 498
Script:
#!/bin/bash # Description: Locate the definition and structure of `event` in `src/index.ts` to confirm that `log.address` is a valid Ethereum address. # Search for the definition of `event` in `src/index.ts` rg --context 10 'event' src/index.tsLength of output: 5917
src/index.ts (34)
7-8: Added new helper functionshandleChainFirstWalletandgetOrUpdateWalletsPerTier.Ensure these functions are thoroughly tested since they are critical for the new tier tracking feature.
29-30: Refactored to useuserAddressLowerCasefor consistency.This change improves consistency in address handling. Ensure all related database queries are updated to handle lowercase addresses.
35-36: Introduced new fieldsuserDataIdanduserHistoryIdin the Points creation logic.This change likely supports better tracking and querying capabilities. Verify that these new fields are supported in the database schema and indexed appropriately.
48-48: Integration ofgetOrUpdateWalletsPerTierin theStratosphere:Transferevent handler.Ensure that the tier calculation logic within this function is optimized for performance, especially under high load.
64-75: RefactoredgetOrCreateUserDataand addedhandleChainFirstWalletto handle new wallet tracking logic.This is a significant change. Ensure comprehensive testing, particularly around edge cases where wallet data might be incomplete or incorrect.
84-84: AddedfirstWalletfield toliquidMiningData.Ensure that this field is properly initialized and used in subsequent logic to track the first wallet interaction correctly.
91-92: New fieldsuserDataIdanduserHistoryIdused in Points creation for liquid mining.As with similar changes, ensure these fields are well-supported in the database and queries are optimized.
100-103: Update operation to setfirstWalletInVPNDLMinUserHistory.This update is crucial for tracking the first wallet interaction. Ensure that the update logic handles concurrent modifications gracefully.
114-115: Points creation for the first deposit in liquid mining.This addition is aligned with the new tracking requirements. Verify that the points calculation and assignment are accurate.
130-131: Handling points for locking in one season of VPN/DLM.This logic extension is necessary for the new seasonal tracking. Ensure that the season tracking is accurate and resets appropriately.
144-144: Update toUserHistoryto track one season points claim.This update is essential for maintaining state across different seasons. Ensure that the state management is robust and handles edge cases.
154-154: Dynamic update toLMSeasonsarray inUserHistory.This dynamic update is a good use of functional programming paradigms. Ensure that the performance implications are considered, especially with larger data sets.
168-169: Creation of points for three seasons lock in VPN/DLM.This addition supports the new tiered system requirements. Verify that the points are calculated correctly and that there are no discrepancies in the season count.
182-182: Flagging of three seasons points claim inUserHistory.It's crucial to accurately track these milestones. Ensure that the flagging mechanism is reliable and triggers appropriately.
193-194: Handling of points for six seasons lock.This is part of the expanded functionality for season tracking. Confirm that the logic correctly handles the transition from five to six seasons without errors.
207-207: Update toUserHistoryfor six seasons points claim.This update is critical for accurate user history tracking. Ensure that the update process is atomic and handles concurrent updates efficiently.
218-219: Points handling for twelve seasons lock.This extension is necessary for the comprehensive tracking of user engagement over extended periods. Verify the accuracy of the season counting and points allocation.
232-232: Flagging of one year points claim inUserHistory.This flagging is essential for milestone tracking. Ensure that the system correctly identifies and flags the one-year milestone.
245-246: Refactored to useuserAddressLowerCaseinVapeStaking:Deposit.Consistent use of lowercase addresses helps prevent errors related to address case sensitivity. Verify that all related components use the lowercase format.
252-263: Integration ofhandleChainFirstWalletinVapeStaking:Deposit.This integration is crucial for the new wallet tracking feature. Ensure that the function is optimized and handles edge cases effectively.
273-273: AddedfirstWalletfield tovapeStakingData.This addition is important for tracking the first wallet interaction in vape staking. Ensure that this field is utilized correctly in subsequent logic.
281-282: New fieldsuserDataIdanduserHistoryIdused in Points creation for vape staking.Consistent with other changes, ensure these fields are supported in the database and that queries involving these fields are optimized.
289-292: Update operation to setfirstWalletInVAPELMinUserHistory.This update is crucial for tracking the first wallet interaction in vape staking. Ensure that the update logic is robust and handles concurrent modifications efficiently.
302-303: Points creation for the first deposit in vape staking.This addition aligns with the new tracking requirements. Verify that the points calculation and assignment are accurate.
316-316: Update toUserHistoryto track the first deposit in vape staking.This update is essential for maintaining accurate user history. Ensure that the update process is atomic and handles concurrent updates efficiently.
332-333: Refactored to useuserAddressLowerCaseinDexAggregator:RouterSwap.Consistent use of lowercase addresses helps prevent errors related to address case sensitivity. Verify that all related components use the lowercase format.
346-357: Integration ofhandleChainFirstWalletinDexAggregator:RouterSwap.This integration is crucial for the new wallet tracking feature. Ensure that the function is optimized and handles edge cases effectively.
365-366: Creation of points for a successful swap in Dex Aggregator.This addition supports the new functionality for tracking swaps. Verify that the points are calculated correctly and that there are no discrepancies in the trade values.
379-396: Handling of the first swap in Dex Aggregator.This logic is essential for tracking the first swap event. Ensure that the flagging mechanism is reliable and triggers appropriately.
400-400: Update toUserHistoryto track total USD value of swaps and total swaps.This update is critical for accurate user history tracking. Ensure that the update process is atomic and handles concurrent updates efficiently.
Line range hint
409-429: Handling of the first $1k swaps in Dex Aggregator.This addition is necessary for the new functionality for tracking swap milestones. Verify that the points are calculated correctly and that there are no discrepancies in the trade values.
Line range hint
437-457: Handling of the first $10k swaps in Dex Aggregator.This addition supports the new functionality for tracking swap milestones. Verify that the points are calculated correctly and that there are no discrepancies in the trade values.
Line range hint
465-485: Handling of the first $100k swaps in Dex Aggregator.This addition is necessary for the comprehensive tracking of user engagement over extended periods. Verify the accuracy of the trade values and points allocation.
499-507: Integration ofgetOrUpdateWalletsPerTierinRewardsController:ClaimPoints.This integration is crucial for the new tier tracking feature. Ensure that the function is optimized and handles edge cases effectively.
| address: [ | ||
| addresses.DexAggregator?.avalanche!, | ||
| addresses.DexAggregatorV2?.avalanche!, | ||
| ], | ||
| startBlock: 43508160, |
There was a problem hiding this comment.
Tip
Codebase Verification
The inspection of the relevant code snippets reveals the following:
- In
src/index.ts, the event handler forDexAggregator:RouterSwapdoes not explicitly handle the new address array format. This needs to be updated to iterate over the array of addresses if necessary. - In
src/helpers.ts, thereadContractfunction usescontracts.DexAggregator.abiandaggregatorAddress. This should be checked to ensure it can handle multiple addresses. - In
src/config/constants.ts, the addresses forDexAggregatorandDexAggregatorV2are defined separately. This aligns with the new array format inponder.config.ts.
To ensure the correct handling of the new address array format, the following updates are recommended:
- Update
src/index.ts: Modify the event handler to iterate over the array of addresses if necessary. - Update
src/helpers.ts: Ensure thereadContractfunction can handle multiple addresses.
Actionable Steps:
-
Update
src/index.ts:- Modify the event handler for
DexAggregator:RouterSwapto handle the array of addresses.
- Modify the event handler for
-
Update
src/helpers.ts:- Ensure the
readContractfunction can handle multiple addresses.
- Ensure the
Code Updates:
src/index.ts:
ponder.on("DexAggregator:RouterSwap", async ({ event, context }) => {
const { Points, UserHistory } = context.db;
const { tokenOut: tokenIn, amountOut: amountIn } = event.args;
const { from: userAddress, hash } = event.transaction;
const { chainId, name } = context.network;
const tokenOut = assets[name].USDC as `0x${string}`;
const timestamp = event.block.timestamp;
const blockNumber = event.block.number;
const userAddressLowerCase = userAddress?.toLowerCase() as Address;
const tokenId = await getTokenId(userAddressLowerCase, context);
// Iterate over the array of addresses
const addresses = [addresses.DexAggregator?.avalanche!, addresses.DexAggregatorV2?.avalanche!];
for (const address of addresses) {
// Your logic here
}
});src/helpers.ts:
async function getQuote(
quoteParams: QuoteParams,
blockNumber: bigint,
aggregatorAddresses: `0x${string}`[]
): Promise<bigint> {
const { client, network, contracts } = context;
let quote: Quote = { amounts: [], adapters: [], path: [], gasEstimate: 0n };
for (const aggregatorAddress of aggregatorAddresses) {
try {
quote = await client.readContract({
abi: contracts.DexAggregator.abi,
address: aggregatorAddress,
functionName: "findBestPath",
args: [
quoteParams.amountIn,
quoteParams.tokenIn,
assets[network.name].USDC as `0x${string}`,
quoteParams.maxSteps,
],
blockNumber: blockNumber,
});
// Break if a valid quote is found
if (quote.amounts.length > 0) break;
} catch (error) {
// Handle error
}
}
return quote;
}These updates will ensure that the new array format for addresses is correctly handled in the contract interactions.
Analysis chain
LGTM! Ensure that the new array format for addresses is correctly handled in contract interactions.
To ensure the new array format for addresses is correctly handled, we need to verify the handling of DexAggregator addresses in the following files:
src/index.tssrc/helpers.tssrc/config/constants.ts
The search results indicate that the handling of DexAggregator addresses needs to be verified in the following files:
src/index.ts: Ensure the event handler forDexAggregator:RouterSwapcorrectly handles the new address array format.src/helpers.ts: Ensure the ABI reference forDexAggregatorcorrectly handles the new address array format.src/config/constants.ts: Ensure the constants forDexAggregatorandDexAggregatorV2correctly handle the new address array format.
Let's inspect the relevant code snippets in these files to verify the correct handling of the new address array format.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify correct handling of new address array format.
# Test: Search for contract interactions using `DexAggregator` addresses. Expect: Correct handling of array format.
rg --type ts $'DexAggregator'
Length of output: 664
Script:
#!/bin/bash
# Description: Verify correct handling of new address array format in relevant files.
# Test: Search for handling of `DexAggregator` addresses in `src/index.ts`.
rg --type ts 'DexAggregator' src/index.ts
# Test: Search for handling of `DexAggregator` addresses in `src/helpers.ts`.
rg --type ts 'DexAggregator' src/helpers.ts
# Test: Search for handling of `DexAggregator` addresses in `src/config/constants.ts`.
rg --type ts 'DexAggregator' src/config/constants.ts
Length of output: 320
Script:
#!/bin/bash
# Description: Inspect code snippets for handling of new address array format.
# Test: Display relevant code snippets in `src/index.ts`.
rg --type ts --context 10 'DexAggregator' src/index.ts
# Test: Display relevant code snippets in `src/helpers.ts`.
rg --type ts --context 10 'DexAggregator' src/helpers.ts
# Test: Display relevant code snippets in `src/config/constants.ts`.
rg --type ts --context 10 'DexAggregator' src/config/constants.ts
Length of output: 2729
| firstWalletInVPNDLM: false, | ||
| firstSwap: false, | ||
| firstWalletInVAPELM: false, | ||
| chainFirstWallet: false, |
There was a problem hiding this comment.
Tip
Codebase Verification
The calls to getOrCreateUserData in src/index.ts do not include the new parameters for tracking first-time activities. This indicates that the function is not being used correctly with the updated parameters.
src/index.ts, lines wheregetOrCreateUserDatais called:await getOrCreateUserData(context, tokenId, userAddressLowerCase);let userData = await getOrCreateUserData(context, tokenId, userAddressLowerCase);
These calls should be updated to include the new parameters for tracking first-time activities.
Analysis chain
LGTM! Ensure that the updated getOrCreateUserData function is correctly managing user data with the new parameters.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify correct functionality of updated `getOrCreateUserData`.
# Test: Search for usage of `getOrCreateUserData` in the application. Expect: Proper handling of new parameters.
rg --type ts $'getOrCreateUserData'
Length of output: 381
Script:
#!/bin/bash
# Extract lines where `getOrCreateUserData` is called in `src/index.ts` to verify parameter handling.
rg --type ts --line-number 'getOrCreateUserData' src/index.ts | awk -F: '{print $1 ":" $2}' | xargs -I {} sed -n '{}p' src/index.ts
Length of output: 433
Script:
#!/bin/bash
# Extract lines where `getOrCreateUserData` is called in `src/index.ts` to verify parameter handling.
rg --type ts --context 5 'getOrCreateUserData' src/index.ts
Length of output: 1316
|
I have pushed the same changes in this pr to avoid conflicts: #8 |
Summary by CodeRabbit
New Features
Improvements
Consistency
Configuration