worldchain explorer updates #3351
Conversation
…nds (#3287) * feat(rfq-relayer): add MaxRelayAmount (#3259) * Feat: add quoteParams helper for test * Feat: add MaxQuoteAmount to relconfig * Feat: use MaxQuoteAmount * Feat: handle MaxQuoteAmount in quoter test * Replace: MaxQuoteAmount -> MaxRelayAmount * Feat: shouldProcess() returns false if max relay amount exceeded * Feat: add test for MaxRelayAmount * add request field for refunds * adding to events typing --------- Co-authored-by: dwasse <wassermandaniel8@gmail.com> Co-authored-by: defi-moses <jakedinero@protonmail.com>
Defi-Moses
requested review from
dwasse,
trajan0x,
aureliusbtc,
bigboydiamonds and
abtestingalpha
as code owners
WalkthroughThe changes introduced in this pull request enhance the integration of the "Worldchain" blockchain into various components of the codebase. This includes adding a new data key for "worldchain" in the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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 using PR comments)
Other keywords and placeholders
Documentation and Community
|
github-actions
bot
added
go
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3351 +/- ##
============================================
Coverage ? 33.25951%
============================================
Files ? 543
Lines ? 34766
Branches ? 82
============================================
Hits ? 11563
Misses ? 22180
Partials ? 1023
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Deploying sanguine-fe with
|
| Latest commit: |
24fbf3e
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://5c590219.sanguine-fe.pages.dev |
| Branch Preview URL: | https://feat-explorer-w.sanguine-fe.pages.dev |
Bundle ReportChanges will decrease total bundle size by 3.86MB (-10.84%) ⬇️. This is within the configured threshold ✅ Detailed changes
ℹ️ *Bundle size includes cached data from a previous commit |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Outside diff range and nitpick comments (24)
packages/rfq-indexer/indexer/src/utils/chains.ts (1)
Line range hint 1-11: Consider adding documentation for chain IDs.
Consider adding a comment block above the chainIdToName object to document the source or reference for these chain IDs, making it easier for future maintainers to verify and update them.
+/**
+ * Mapping of EVM chain IDs to their respective network names.
+ * Reference: https://chainlist.org/
+ */
export const chainIdToName: { [key: number]: string } = {services/explorer/static/chainIDs.yaml (1)
Line range hint 1-22: Consider sorting chain IDs for better maintainability.
The entries in the file are not sorted, which makes it harder to spot duplicates and maintain the file. Consider sorting the entries by chain ID.
Here's how the file could look when sorted:
packages/rfq-indexer/api/src/queries/depositsQueries.ts (1)
Line range hint 23-27: Document the timestamp filter value.
The hardcoded timestamp (1722729600) and the comment about partial index loading could benefit from additional context.
Consider adding a more descriptive comment:
.where('BridgeRequestEvents.blockTimestamp', '>', 1722729600)
- // if index is partially loaded, we must limit lookback or will have various data issues from relays
- // that happened to be in flight at the point of the index's start.
- // may also improve query performance
+ // Filter events after April 2024 (1722729600)
+ // Note: This filter is required when the index is partially loaded to:
+ // 1. Prevent data inconsistencies from in-flight relays at index start
+ // 2. Optimize query performance by limiting the data rangepackages/rfq-indexer/api/src/routes/disputesRoute.ts (1)
Line range hint 1-47: Consider enhancing the API documentation further.
While the current documentation is clear, consider these improvements to make it more developer-friendly:
- Document any supported query parameters (e.g., filtering, pagination)
- Add response examples for better understanding
- Specify which nested properties are required vs optional
Example enhancement:
* @openapi
* /disputes:
* get:
* summary: Get all active disputes
* description: Retrieves a list of all active disputes
+* parameters:
+* - in: query
+* name: status
+* schema:
+* type: string
+* enum: [pending, resolved]
+* description: Filter disputes by status
+* examples:
+* success-response:
+* value:
+* - Bridge:
+* txHash: "0x123..."
+* BridgeDispute:
+* status: "pending"packages/rfq-indexer/api/src/routes/invalidRelaysRoute.ts (1)
Line range hint 1-47: Consider documenting rate limiting details.
Since this endpoint retrieves data from a 2-week window, it could be resource-intensive. Consider adding rate limiting documentation in the OpenAPI spec to help API consumers understand usage limits.
Add the following to the OpenAPI documentation:
* summary: Get recent invalid relays
* description: Retrieves a list of recent invalid relay events from the past 2 weeks
+* x-rateLimit:
+* description: Rate limited to protect server resources
+* limit: <rate_limit_value>
+* period: <time_period>
* responses:packages/rfq-indexer/api/src/routes/refundedAndRelayedRoute.ts (1)
Line range hint 15-47: Consider standardizing error responses across the API
While the current error documentation is adequate, consider enhancing it by:
- Adding specific error codes in the response schema
- Including more detailed error scenarios in the 500 response
- Considering additional error status codes (e.g., 400 for invalid parameters)
This would improve error handling consistency and make the API more developer-friendly.
Example enhancement:
/**
* error response schema:
* schema:
* type: object
* properties:
* code:
* type: string
* enum: [INTERNAL_ERROR, DATABASE_ERROR, VALIDATION_ERROR]
* message:
* type: string
* details:
* type: object
* description: Additional error context
*/packages/rfq-indexer/api/src/routes/conflictingProofsRoute.ts (1)
Line range hint 19-39: Consider enhancing the schema documentation.
The response schema could be more detailed to improve API documentation:
- Add specific types for each property in the nested objects
- Include example values
- Specify which fields are required
Example improvement for one property:
* Bridge:
* type: object
* description: General transaction fields
+* required:
+* - txHash
+* - chainId
+* properties:
+* txHash:
+* type: string
+* description: Transaction hash
+* example: "0x1234..."
+* chainId:
+* type: integer
+* description: Chain identifier
+* example: 1packages/rfq-indexer/api/src/graphql/types/events.graphql (1)
20-20: Add field descriptions for better documentation
Consider adding descriptions to the GraphQL fields using the """ syntax. This would improve the schema's self-documentation and help API consumers understand the purpose of each field, especially the new request field.
Example:
+ """
+ The serialized request data associated with the bridge event
+ """
request: String!packages/rfq-indexer/api/src/routes/transactionIdRoute.ts (1)
Line range hint 1-63: Consider adding examples to the OpenAPI documentation
While the schema documentation is comprehensive, adding example responses would make the API documentation more developer-friendly.
Add an example response using the example field in the OpenAPI specification:
* BridgeDispute:
* type: object
* description: Dispute information (if available)
+* example:
+* Bridge:
+* id: "123"
+* status: "completed"
+* BridgeRequest:
+* amount: "1000000000000000000"
+* timestamp: "2024-01-01T00:00:00Z"packages/rfq-indexer/indexer/ponder.schema.ts (1)
8-8: Consider adding documentation for the new field.
To improve maintainability, consider adding a JSDoc comment above the field explaining:
- The purpose of this field
- The expected format of the request data
- Any validation requirements
Example:
sender: p.string(),
+ /**
+ * Raw bridge request data containing the complete transfer details.
+ * @format JSON string
+ */
request: p.string(),packages/rfq-indexer/api/src/types/index.ts (1)
13-13: Add documentation for the new request field.
Consider adding a JSDoc comment to explain the purpose and expected content of the request field, which would improve maintainability and help other developers understand its usage.
+ /** Unique identifier or metadata for the bridge request */
request: ColumnType<string>services/explorer/graphql/server/graph/schema/types.graphql (1)
183-183: Add documentation for the worldchain field.
While the field addition follows the established pattern, consider adding a description string to document what the worldchain represents and whether the field can be null.
Example addition:
+ """
+ Volume/count/etc. for the Worldchain network transactions.
+ """
worldchain: Floatpackages/rfq-indexer/api/src/routes/pendingTransactionsRoute.ts (2)
20-20: LGTM! The response handling changes align with REST API best practices.
The consistent update of response descriptions across all endpoints to return 200 with an empty array (instead of 404) when no transactions are found is a good practice. This approach simplifies error handling for API consumers and follows the REST principle where "no results" is a valid response, not an error condition.
Consider enhancing the OpenAPI documentation by adding examples for both populated and empty responses. This would make the API more developer-friendly. Here's a suggested addition for each endpoint:
* content:
* application/json:
* schema:
* type: array
* items:
+* examples:
+* withResults:
+* summary: Response with pending transactions
+* value: [{ "deposit": { "id": "0x123..." } }]
+* noResults:
+* summary: Response with no pending transactions
+* value: []Also applies to: 69-69, 101-101, 131-131
Response pattern is inconsistent with controller implementation
The controller implementation returns a 200 status with a message for not found cases, but the OpenAPI documentation in transactionIdRoute.ts specifies a 404 response. The route documentation should be updated to match the actual implementation:
- Remove the 404 response specification from
/transaction-id/{transactionId}endpoint intransactionIdRoute.ts - Update the 200 response schema to include the message property for the not found case
🔗 Analysis chain
Line range hint 1-153: Verify consistent error handling across related routes.
Let's ensure this response handling pattern is consistently implemented across all related route files.
Let me check the content of the transactionIdRoute.ts file to verify if the 404 response is justified or needs to be updated for consistency.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for inconsistent response handling patterns across route files
# Expected: All route files should use 200 with empty array instead of 404
# Search for any remaining 404 response definitions in route files
echo "Checking for inconsistent 404 responses in routes:"
rg -l "404:" "packages/rfq-indexer/api/src/routes/"
# Search for response descriptions to verify consistency
echo "Checking response descriptions in routes:"
rg "description: Successful response" "packages/rfq-indexer/api/src/routes/"
Length of output: 1556
Script:
#!/bin/bash
# Check the specific endpoint implementation in transactionIdRoute.ts
echo "Content of transactionIdRoute.ts:"
cat packages/rfq-indexer/api/src/routes/transactionIdRoute.ts
# Also check the corresponding controller to understand the response behavior
echo -e "\nChecking controller implementation:"
fd -e ts transactionId packages/rfq-indexer/api/src/controllers/
Length of output: 2314
Script:
#!/bin/bash
# Check the implementation of the transaction ID controller
cat packages/rfq-indexer/api/src/controllers/transactionIdController.ts
# Also check if there are any similar endpoints that look up specific resources by ID
rg -l "/:.*Id" packages/rfq-indexer/api/src/routes/
Length of output: 2646
packages/rfq-indexer/api/src/controllers/pendingTransactionsController.ts (3)
41-41: LGTM! Improved REST API response handling.
Changing from 404 to 200 for empty results aligns with REST API best practices. A 404 status code should indicate that a resource doesn't exist, while a 200 status with an empty result set is more appropriate for "no matches found" scenarios.
Consider documenting this pattern in your API guidelines to ensure consistency across other endpoints.
Also applies to: 79-79, 124-124, 169-169
Line range hint 44-47: Consider enhancing error handling.
The current error handling could be improved to provide more detailed information and follow a consistent structure:
- Use structured error responses
- Include more details in development environments
- Add error codes for better client-side handling
Consider implementing a centralized error handler:
// errorHandler.ts
interface ApiError {
code: string;
message: string;
details?: unknown;
}
export function handleControllerError(error: unknown, res: Response): void {
console.error('Error:', error);
const response: ApiError = {
code: 'INTERNAL_SERVER_ERROR',
message: 'Internal server error',
...(process.env.NODE_ENV === 'development' && { details: error }),
};
res.status(500).json(response);
}Then update the controllers to use it:
} catch (error) {
handleControllerError(error, res);
}Also applies to: 82-85, 127-130, 172-175
Line range hint 13-35: Consider extracting common query patterns.
The controllers contain similar query construction patterns that could be extracted into reusable query builders to improve maintainability and reduce duplication.
Consider creating a shared query builder:
// queryBuilders.ts
export function createBaseTransactionQuery(db: Database) {
return db
.with('deposits', () => qDeposits())
.with('relays', () => qRelays())
.with('proofs', () => qProofs({ activeOnly: true }));
}
export function withMissingClaim(query: QueryBuilder) {
return query
.with('combined', (qb) =>
qb
.selectFrom('deposits')
.innerJoin('relays', 'transactionId_deposit', 'transactionId_relay')
.innerJoin('proofs', 'transactionId_deposit', 'transactionId_proof')
.leftJoin('claims', 'transactionId_deposit', 'transactionId_claim')
.where('transactionId_claim', 'is', null)
);
}Then simplify the controllers:
const query = withMissingClaim(createBaseTransactionQuery(db))
.selectFrom('combined')
.selectAll()
.orderBy('blockTimestamp_proof', 'desc');Also applies to: 52-74, 89-117, 134-162
services/explorer/api/server_test.go (1)
38-62: LGTM! Field definitions are consistent.
The new Worldchain field follows the established pattern with consistent types and tags. The alphabetical ordering of chain fields with Total at the end maintains good structure.
Consider adding field documentation to describe what each chain field represents and any special handling for the Total field. This would improve test maintainability.
Response: []*struct {
+ // Date represents the timestamp for these statistics
Date *string "json:\"date\" graphql:\"date\""
+ // Ethereum represents the daily statistics for Ethereum chain
Ethereum *float64 "json:\"ethereum\" graphql:\"ethereum\""
// ... (similar comments for other chains)
+ // Total represents the sum of statistics across all chains
Total *float64 "json:\"total\" graphql:\"total\""
}packages/rfq-indexer/indexer/ponder.config.ts (2)
199-203: Consider cleaning up commented code
The disableCache configuration is commented out across all chains. Consider either:
- Removing the commented code if it's no longer needed
- Documenting why it's kept commented out
- Implementing it if it's meant to be used
240-244: Maintain formatting consistency
The startBlock property access is split across multiple lines, while other chains keep it on a single line. Consider maintaining consistent formatting:
- startBlock:
- networkDetails[worldchainChainId]?.FastBridgeV2.startBlock,
+ startBlock: networkDetails[worldchainChainId]?.FastBridgeV2.startBlock,packages/explorer-ui/components/ChainChart/index.tsx (1)
323-328: Consider the visual hierarchy of the stacked bars
The worldchain bar is added at the end of the stack. Consider if this positioning aligns with its importance in the data visualization hierarchy. You might want to adjust its position based on expected volume or significance.
services/explorer/consumer/parser/rfqparser.go (1)
123-127: Document the WLD token addresses.
Please add comments explaining:
- Which networks these addresses belong to
- Why there are two different addresses
- The relationship between these addresses and the Worldchain network
services/explorer/consumer/parser/tokendata/cache.go (1)
290-294: Track technical debt: CCTP token decimals retrieval.
Related to the token additions, there's a TODO in the codebase about retrieving CCTP token decimals from on-chain data. Consider addressing this technical debt to ensure accurate token decimal handling.
Would you like me to create a GitHub issue to track the implementation of on-chain decimal retrieval for CCTP tokens?
services/rfq/relayer/quoter/quoter_test.go (1)
Line range hint 256-309: Resolve merge conflict to fix syntax errors
There's an unresolved merge conflict in the test file that's causing syntax errors and contains duplicate test cases. The conflict markers (<<<<<<<, =======, >>>>>>>) need to be removed, and the duplicate test cases need to be consolidated.
Please resolve the merge conflict by:
- Keeping only one copy of the test case
- Removing all merge conflict markers
- Ensuring proper indentation after resolution
Here's the suggested resolution:
-<<<<<<< HEAD
quoteAmount, err = s.manager.GetOriginAmount(s.GetTestContext(), input)
s.NoError(err)
expectedAmount = big.NewInt(500_000_000)
s.Equal(expectedAmount, quoteAmount)
// Set QuotePct to 50 with QuoteOffset of -1%. Should be 1% less than 50% of balance.
setQuoteParams(quoteParams{
quotePct: 50,
quoteOffset: -100,
minQuoteAmount: "0",
maxBalance: "0",
})
quoteAmount, err = s.manager.GetOriginAmount(s.GetTestContext(), input)
s.NoError(err)
expectedAmount = big.NewInt(495_000_000)
s.Equal(expectedAmount, quoteAmount)
// Set QuotePct to 25 with MinQuoteAmount of 500; should be 50% of balance.
setQuoteParams(quoteParams{
quotePct: 25,
quoteOffset: 0,
minQuoteAmount: "500",
maxBalance: "0",
})
-=======
->>>>>>> master
quoteAmount, err = s.manager.GetOriginAmount(s.GetTestContext(), input)
s.NoError(err)
expectedAmount = big.NewInt(500_000_000)
s.Equal(expectedAmount, quoteAmount)
- // Set QuotePct to 25 with MinQuoteAmount of 500; should be 50% of balance.
- setQuoteParams(quoteParams{
- quotePct: 25,
- quoteOffset: 0,
- minQuoteAmount: "500",
- maxBalance: "0",
- })
-<<<<<<< HEAD
-=======
- quoteAmount, err = s.manager.GetOriginAmount(s.GetTestContext(), input)
- s.NoError(err)
- expectedAmount = big.NewInt(500_000_000)
- s.Equal(expectedAmount, quoteAmount)
-
- // Set QuotePct to 25 with MinQuoteAmount of 500; should be 50% of balance.
- setQuoteParams(quoteParams{
- quotePct: 25,
- quoteOffset: 0,
- minQuoteAmount: "500",
- maxBalance: "0",
- })
->>>>>>> master🧰 Tools
🪛 GitHub Check: Lint (services/rfq)
[failure] 256-256:
expected statement, found '<<' (typecheck)
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (36)
- packages/explorer-ui/components/ChainChart/index.tsx (1 hunks)
- packages/rfq-indexer/api/src/constants/networkConfig.ts (2 hunks)
- packages/rfq-indexer/api/src/controllers/conflictingProofsController.ts (1 hunks)
- packages/rfq-indexer/api/src/controllers/disputesController.ts (1 hunks)
- packages/rfq-indexer/api/src/controllers/pendingTransactionsController.ts (7 hunks)
- packages/rfq-indexer/api/src/controllers/transactionIdController.ts (2 hunks)
- packages/rfq-indexer/api/src/graphql/resolvers.ts (1 hunks)
- packages/rfq-indexer/api/src/graphql/types/events.graphql (1 hunks)
- packages/rfq-indexer/api/src/queries/depositsQueries.ts (1 hunks)
- packages/rfq-indexer/api/src/routes/conflictingProofsRoute.ts (1 hunks)
- packages/rfq-indexer/api/src/routes/disputesRoute.ts (1 hunks)
- packages/rfq-indexer/api/src/routes/invalidRelaysRoute.ts (1 hunks)
- packages/rfq-indexer/api/src/routes/pendingTransactionsRoute.ts (4 hunks)
- packages/rfq-indexer/api/src/routes/refundedAndRelayedRoute.ts (1 hunks)
- packages/rfq-indexer/api/src/routes/transactionIdRoute.ts (2 hunks)
- packages/rfq-indexer/api/src/types/index.ts (1 hunks)
- packages/rfq-indexer/indexer/.env.example (1 hunks)
- packages/rfq-indexer/indexer/ponder.config.ts (5 hunks)
- packages/rfq-indexer/indexer/ponder.schema.ts (1 hunks)
- packages/rfq-indexer/indexer/src/index.ts (2 hunks)
- packages/rfq-indexer/indexer/src/utils/chains.ts (1 hunks)
- packages/rfq-indexer/indexer/src/utils/formatAmount.ts (1 hunks)
- services/explorer/api/server_test.go (1 hunks)
- services/explorer/consumer/parser/rfqparser.go (1 hunks)
- services/explorer/consumer/parser/tokendata/cache.go (1 hunks)
- services/explorer/graphql/client/client.go (2 hunks)
- services/explorer/graphql/client/queries/queries.graphql (1 hunks)
- services/explorer/graphql/server/graph/model/models_gen.go (1 hunks)
- services/explorer/graphql/server/graph/partials.go (6 hunks)
- services/explorer/graphql/server/graph/resolver/server.go (6 hunks)
- services/explorer/graphql/server/graph/schema/types.graphql (1 hunks)
- services/explorer/static/chainIDs.yaml (1 hunks)
- services/explorer/static/tokenIDToCoinGeckoID.yaml (1 hunks)
- services/explorer/static/tokenSymbolToCoinGeckoID.yaml (1 hunks)
- services/explorer/static/tokenSymbolToTokenID.yaml (1 hunks)
- services/rfq/relayer/quoter/quoter_test.go (3 hunks)
✅ Files skipped from review due to trivial changes (4)
- packages/rfq-indexer/api/src/controllers/conflictingProofsController.ts
- packages/rfq-indexer/api/src/controllers/disputesController.ts
- packages/rfq-indexer/api/src/controllers/transactionIdController.ts
- packages/rfq-indexer/indexer/.env.example
🧰 Additional context used
🪛 GitHub Check: Lint (services/rfq)
services/rfq/relayer/quoter/quoter_test.go
[failure] 256-256:
expected statement, found '<<' (typecheck)
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
🔇 Additional comments (38)
packages/rfq-indexer/indexer/src/utils/chains.ts (1)
10-10: Verify Worldchain chain ID.
The addition follows the correct format and naming convention. However, let's verify that 480 is indeed the official chain ID for Worldchain to prevent potential issues.
✅ Verification successful
Chain ID 480 is verified as Worldchain's official chain ID
Based on the search results, chain ID 480 is consistently used across multiple configuration files and components to identify Worldchain:
- It is defined in core configuration files like
chains.ts,chainIds.ts, andnetworkConfig.ts - The chain ID is used consistently with Worldchain's RPC endpoints and explorer URLs
- The chain ID mapping appears in bridge configurations, indexer configs, and network definitions
- The implementation matches other chain ID configurations in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for other occurrences of chain ID 480 in the codebase
# to verify consistency and check documentation
# Look for chain ID references
rg -i "480|worldchain" --type yaml --type typescript --type javascript
# Check if there's any documentation about chain IDs
fd -e md -e txt . -x grep -l -i "chain.?id|network.?id"
Length of output: 165
Script:
#!/bin/bash
# Search for chain ID and worldchain references with correct file extensions
rg -i "480|worldchain" --type ts --type js --type yaml
# Search for any chain ID documentation in markdown files
rg -i "chain.?id|network.?id" --type md
# Look specifically in config files and documentation
fd "config|chain" -e yaml -e json -e md -e ts -e js -x rg -i "480|worldchain" {}
Length of output: 490404
services/explorer/static/chainIDs.yaml (2)
22-22: Verify format consistency and uniqueness.
The new entry follows the correct format. Let's verify there are no duplicate chain IDs.
✅ Verification successful
Chain ID format is consistent, but entries should be sorted
The verification shows:
- No duplicate chain IDs are present
- The format
<number>: '<name>'is consistent across all entries - Chain ID 480 is properly added with the correct format
However, the entries in the file are not sorted numerically, which makes it harder to maintain and spot duplicates. Consider sorting the chain IDs numerically for better maintainability.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for duplicate chain IDs and format consistency
# Test 1: Check for duplicate chain IDs
echo "Checking for duplicate chain IDs..."
DUPLICATES=$(cat services/explorer/static/chainIDs.yaml | grep -v '^$' | cut -d':' -f1 | sort -n | uniq -d)
if [ ! -z "$DUPLICATES" ]; then
echo "Found duplicate chain IDs: $DUPLICATES"
exit 1
fi
# Test 2: Verify format consistency (number: 'name')
echo "Checking format consistency..."
grep -vE '^[0-9]+: '\''[^'\'']+'\''$' services/explorer/static/chainIDs.yaml
Length of output: 305
Script:
#!/bin/bash
# Let's try a different approach to verify the chain IDs file
# Check for duplicate chain IDs
echo "=== Checking for duplicate chain IDs ==="
yq -r 'keys | .[]' services/explorer/static/chainIDs.yaml | sort -n | uniq -d
# Show all entries for format verification
echo -e "\n=== Current entries format ==="
cat services/explorer/static/chainIDs.yaml
# Search for chain ID 480 specifically
echo -e "\n=== Searching for chain ID 480 ==="
grep "480:" services/explorer/static/chainIDs.yaml
Length of output: 858
22-22: Verify chain ID assignment.
Please ensure that chain ID 480 is officially assigned to Worldchain to prevent potential conflicts.
✅ Verification successful
Chain ID 480 is correctly assigned to Worldchain/World Chain.
The chain ID 480 is officially assigned to World Chain (also known as Worldchain) according to chainlist.org. The chain is properly registered with complete network details including RPC endpoints, native currency configuration, and explorer information.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for chain ID documentation or references
# Test: Look for any existing references to chain ID 480 or Worldchain
echo "Searching for chain ID documentation..."
rg -i "chain.*id.*480|worldchain" --type md
Length of output: 305
Script:
#!/bin/bash
# Search for chain ID 480 and Worldchain references in YAML files
echo "Searching in YAML files..."
rg -i "480:.*worldchain|worldchain.*480" --type yaml
# Extract all chain IDs from YAML files to check for duplicates
echo -e "\nChecking for duplicate chain IDs..."
rg "^\d+:" --type yaml | cut -d':' -f1 | sort -n | uniq -c | grep -v "^\s*1\s"
# Search for any documentation about chain ID assignments
echo -e "\nSearching for chain ID documentation..."
fd -e md -e txt README LICENSE CONTRIBUTING
Length of output: 682
Script:
#!/bin/bash
# Check for chain ID documentation in README files
echo "Searching for chain ID documentation in README files..."
fd README -t f -X cat {}
# Check chainlist.org API for chain ID 480
echo -e "\nChecking chainlist.org data..."
curl -s https://chainid.network/chains.json | jq '.[] | select(.chainId==480)'
# Look for any configuration or documentation files related to chain IDs
echo -e "\nSearching for chain ID related files..."
fd -t f -e yaml -e json -e md chain
Length of output: 206805
packages/rfq-indexer/indexer/src/utils/formatAmount.ts (1)
10-13: Verify the default decimal places assumption.
The function logic looks correct, but let's verify that 6 decimals is the appropriate default for all other tokens in the system.
services/explorer/static/tokenSymbolToTokenID.yaml (1)
45-45: LGTM! The new Worldcoin token mapping follows the established format.
The addition of wld: 'worldcoin' is consistent with the file's purpose and maintains the expected mapping format.
services/explorer/static/tokenIDToCoinGeckoID.yaml (1)
43-43: Verify the CoinGecko ID mapping for WLD token
The format is consistent with other entries, but let's verify that 'worldcoin' is the correct CoinGecko ID for the WLD token.
✅ Verification successful
CoinGecko ID 'worldcoin' is valid and actively returning price data
The mapping WLD: 'worldcoin' is correct as verified by a successful API response from CoinGecko, which returns current USD price data for this identifier.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that 'worldcoin' is a valid CoinGecko ID and matches the WLD token
# Test: Check if the CoinGecko ID exists and corresponds to WLD
curl -s "https://api.coingecko.com/api/v3/simple/price?ids=worldcoin&vs_currencies=usd" | jq .
Length of output: 143
services/explorer/static/tokenSymbolToCoinGeckoID.yaml (1)
43-43: Verify the CoinGecko ID mapping.
The format and case convention are consistent with other entries. Let's verify that 'worldcoin' is a valid CoinGecko ID.
✅ Verification successful
Mapping is consistent across token configuration files
The verification shows that 'worldcoin' is consistently mapped across all related configuration files:
tokenIDToCoinGeckoID.yaml: WLD -> worldcointokenSymbolToTokenID.yaml: wld -> worldcointokenSymbolToCoinGeckoID.yaml: wld -> worldcoin
The case conventions and mappings are aligned properly across all files, maintaining data consistency.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if any other tokens are mapped to 'worldcoin' and verify the CoinGecko ID exists
echo "Checking for duplicate mappings..."
rg "worldcoin" --type yaml
echo -e "\nVerifying CoinGecko ID exists..."
# Note: In a real implementation, we would call CoinGecko's API to verify the ID
# For example: curl -X GET "https://api.coingecko.com/api/v3/simple/price?ids=worldcoin&vs_currencies=usd"
Length of output: 394
packages/rfq-indexer/api/src/queries/depositsQueries.ts (1)
20-20: LGTM! Verify data availability for the new field.
The addition of the 'request' field to the query selection aligns with the schema changes.
Let's verify the data availability for this field:
✅ Verification successful
✅ Field addition is properly supported by schema
The 'request' field is correctly defined in the Ponder schema as a required string field and is consistently used in the query alongside other related fields like 'sender', 'originAmountFormatted', and 'destAmountFormatted'. The timestamp filter (1722729600) ensures this change only affects records from April 2024 onwards, aligning with the schema update.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the request field exists in the schema and verify its nullability
# Test 1: Verify the field definition in GraphQL schema
rg -A 5 "type BridgeRequestEvent" packages/rfq-indexer/api/src/graphql/types/events.graphql
# Test 2: Check Ponder schema definition
rg "request:" packages/rfq-indexer/indexer/ponder.schema.ts
Length of output: 329
Script:
#!/bin/bash
# Let's try a more precise search for schema definitions
# Check GraphQL schema with better context
rg -A 10 "type BridgeRequestEvent" --type graphql
# Check Ponder schema with better context
rg -B 2 -A 5 "request:" packages/rfq-indexer/indexer/ponder.schema.ts
# Check if there are any existing records with this field
rg -B 3 -A 3 "BridgeRequestEvents.*request" packages/rfq-indexer/api/src/queries/
Length of output: 1161
packages/rfq-indexer/api/src/routes/disputesRoute.ts (1)
15-15: LGTM! Documentation change aligns with REST best practices.
The updated description clarifies that an empty array is a valid successful response, which is the correct RESTful approach for "no data" scenarios.
packages/rfq-indexer/api/src/routes/invalidRelaysRoute.ts (1)
15-15: Documentation update aligns with REST best practices!
Good change to clarify that a successful response may return an empty array instead of using a 404 status. This follows REST best practices and maintains consistency with other endpoints in the codebase.
packages/rfq-indexer/api/src/routes/refundedAndRelayedRoute.ts (1)
15-15: Documentation update improves clarity!
The updated response description better reflects the API behavior by explicitly stating that an empty array is a valid successful response. This aligns with REST best practices where empty collections should return 200 rather than 404.
packages/rfq-indexer/api/src/routes/conflictingProofsRoute.ts (1)
15-15: Documentation update aligns with REST best practices.
The clarification about empty array responses is a good improvement. This follows REST best practices where empty collections should return 200 with an empty array rather than 404, making the API behavior more predictable and consistent with other routes.
packages/rfq-indexer/api/src/graphql/types/events.graphql (1)
20-20: Verify handling of breaking schema change
Adding a non-nullable field request to BridgeRequestEvent is a breaking change that requires careful consideration:
- Existing clients will need to update their queries
- Existing data might need migration to populate this field
Let's verify the GraphQL queries using this type:
packages/rfq-indexer/api/src/routes/transactionIdRoute.ts (1)
28-48: LGTM! Well-documented response schema
The response schema documentation has been enhanced with clear descriptions for each component:
- Bridge: General transaction fields
- BridgeRequest: Deposit information
- BridgeRelay: Relay information
- BridgeRefund: Refund information
- BridgeProof: Proof information
- BridgeClaim: Claim information
- BridgeDispute: Dispute information
This provides good clarity about the response structure.
packages/rfq-indexer/indexer/ponder.schema.ts (1)
8-8: Please clarify the migration strategy and field purpose.
The addition of a required request field raises some concerns:
- How will existing records be handled? Since this is a required field, existing records need to be migrated.
- What type of data will this field store? The field name could be more descriptive.
Let's check for existing records that might be affected:
packages/rfq-indexer/api/src/constants/networkConfig.ts (2)
11-11: LGTM! Import follows established pattern
The worldchain import is correctly placed alongside other chain imports from 'viem/chains'.
118-128: Please verify network configuration details
While the configuration structure is correct, please verify:
- The FastBridgeV2 address (0x5523D3c...fB59E) is reused across multiple networks - confirm this is intentional
- The http transport might need specific RPC URL configuration
- Confirm chainId 480 is the correct Worldchain identifier
packages/rfq-indexer/api/src/controllers/pendingTransactionsController.ts (2)
4-4: LGTM! Clean import statement.
Removing the unused qDisputes import improves code cleanliness.
17-17: LGTM! Consistent function call formatting.
The spacing in qProofs({ activeOnly: true }) calls is now consistent across the codebase.
Also applies to: 58-58
packages/rfq-indexer/indexer/src/index.ts (2)
Line range hint 1-250: Overall structure and patterns look good!
The code maintains good consistency across all event handlers with:
- Proper TypeScript usage
- Consistent error handling
- Standardized data transformation
- Clean separation of concerns
19-19: Add validation and documentation for the new request field.
The new request field is being stored directly without validation or transformation. Consider:
- Adding type information for better code maintainability
- Validating the field before storage
- Documenting the purpose and expected format of this field
Also applies to: 37-37
services/explorer/api/server_test.go (1)
Line range hint 63-69: Enhance test coverage for the new Worldchain field.
The current test only verifies the Total field. Consider adding test cases to:
- Validate Worldchain field values
- Verify Total calculation includes Worldchain correctly
- Handle edge cases (nil values, zero values)
Example test cases to add:
func TestHandleJSONDailyStatWithWorldchain(t *testing.T) {
worldchainValue := 10.5
ethereumValue := 5.5
expectedTotal := 16.0
valueStruct := gqlClient.GetDailyStatisticsByChain{
Response: []*struct {
// ... other fields ...
Worldchain *float64 `json:"worldchain" graphql:"worldchain"`
Ethereum *float64 `json:"ethereum" graphql:"ethereum"`
Total *float64 `json:"total" graphql:"total"`
}{
{
Worldchain: &worldchainValue,
Ethereum: ðereumValue,
Total: &expectedTotal,
},
},
}
res := api.HandleJSONDailyStat(&valueStruct)
NotNil(t, res)
Equal(t, worldchainValue, *res[0].Worldchain)
Equal(t, expectedTotal, *res[0].Total)
}packages/rfq-indexer/indexer/ponder.config.ts (3)
16-16: LGTM: Chain ID constant follows conventions
The constant declaration follows the established pattern and uses the correct chain ID for Worldchain.
147-154: LGTM: Network details configuration is consistent
The network details configuration follows the established pattern and correctly references the chain configuration values.
73-78: Verify environment variable and contract address
The configuration looks structurally correct, but please ensure:
- The
WORLDCHAIN_MAINNET_RPCenvironment variable is properly set in the deployment configuration - The FastBridgeV2 contract address
0x05C62156C7C47E76223A560210EA648De5e6B53Bis the correct deployment for Worldchain
✅ Verification successful
Configuration verified with deployment artifacts
The verification confirms:
- The FastBridgeV2 contract address
0x05C62156C7C47E76223A560210EA648De5e6B53Bmatches the deployed contract on Worldchain as shown in the deployment artifact. - The
WORLDCHAIN_MAINNET_RPCenvironment variable is properly defined in.env.example. - The start block
4598830matches the deployment block number from the contract receipt.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the environment variable is defined in any .env files
echo "Checking for WORLDCHAIN_MAINNET_RPC in environment files..."
fd -t f -e env -e env.example -e env.local -x grep -l "WORLDCHAIN_MAINNET_RPC" {}
# Verify if the FastBridgeV2 contract address exists on other chains
echo "Checking if this FastBridgeV2 address is used on other chains..."
rg -l "0x05C62156C7C47E76223A560210EA648De5e6B53B"
Length of output: 510
Script:
#!/bin/bash
# Let's check the deployment file content to verify the contract address
echo "Checking FastBridge deployment on Worldchain..."
cat packages/contracts-rfq/deployments/worldchain/FastBridge.json
# Let's check for environment variable in more files including docker and deployment configs
echo "Checking for WORLDCHAIN_MAINNET_RPC in deployment and docker files..."
rg "WORLDCHAIN_MAINNET_RPC" -A 2 -B 2
# Let's verify if there are any other FastBridgeV2 addresses in the config
echo "Checking other FastBridgeV2 addresses in config..."
rg "FastBridgeV2Address.*0x" packages/rfq-indexer/indexer/ponder.config.ts
Length of output: 26074
packages/explorer-ui/components/ChainChart/index.tsx (1)
323-328: Verify worldchain data handling
The chart should gracefully handle cases where worldchain data is undefined or missing.
Let's verify the data handling:
services/explorer/consumer/parser/tokendata/cache.go (1)
290-294: Verify token addresses across networks.
The addition of WLD token across multiple networks (Worldchain, Optimism, Ethereum) and other tokens on Worldchain requires verification.
Let's verify the token contracts:
services/rfq/relayer/quoter/quoter_test.go (1)
262-272: LGTM! Good test coverage for quote offset functionality
The new test case effectively validates the quote offset calculation, ensuring that a -1% offset correctly reduces the quoted amount by 1% from the base amount (50% of balance).
services/explorer/graphql/server/graph/model/models_gen.go (2)
107-107: LGTM: Field addition follows consistent patterns
The Worldchain field:
- Uses consistent type (
*float64) - Has consistent JSON tag format
- Maintains alphabetical ordering
84-108: Warning: This is a generated file
This file is auto-generated and should not be modified directly. Changes should be made to the source GraphQL schema instead.
Let's verify the schema changes:
✅ Verification successful
Schema changes are properly defined
The worldchain field is correctly defined in the GraphQL schema at services/explorer/graphql/server/graph/schema/types.graphql within the DateResultByChain type. The generated code accurately reflects the schema definition, maintaining consistency with other chain fields in terms of type (Float) and placement.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the Worldchain field is properly defined in the GraphQL schema
# Expected: Find the worldchain field definition in the schema
# Search for worldchain field in GraphQL schema files
fd -e graphql -x rg -l 'worldchain.*Float'
Length of output: 106
Script:
#!/bin/bash
# Let's check the actual schema definition in types.graphql
cat ./services/explorer/graphql/server/graph/schema/types.graphql
Length of output: 4329
packages/rfq-indexer/api/src/graphql/resolvers.ts (2)
Line range hint 132-146: LGTM! Nesting logic handles the new field correctly.
The nest_results function will automatically process the new request field as part of the bridgeRequest object since it doesn't have a suffix. The existing error handling and field processing logic is sufficient.
23-23: Verify schema definition for the new request field.
The addition of BridgeRequestEvents.request field looks good. However, let's verify its integration:
services/explorer/graphql/client/client.go (2)
109-133: LGTM! The struct changes are well-structured.
The addition of the Worldchain field maintains consistency with existing fields in terms of type (*float64) and tag formatting.
506-506: LGTM! The GraphQL query document is properly updated.
The worldchain field is correctly added to the query document, maintaining consistency with the struct definition.
services/explorer/graphql/server/graph/partials.go (1)
404-404: LGTM! Consistent integration of worldchain support.
The changes consistently add worldchain (chain ID 480) across all relevant SQL query templates, maintaining the existing structure and format.
Let's verify the consistency of the chain ID usage:
Also applies to: 449-449, 546-546, 649-649, 681-681, 714-714
services/explorer/graphql/server/graph/resolver/server.go (3)
103-127: LGTM! Complexity functions are properly declared.
The Worldchain complexity function follows the established pattern and maintains alphabetical ordering with other chains.
664-670: LGTM! Complexity calculation is properly implemented.
The implementation includes proper nil checks and follows the established pattern for complexity calculation.
7243-7244: LGTM! Field resolution mapping is properly implemented.
The Worldchain field is correctly mapped in both the field context and resolution switch statement.
Also applies to: 10489-10490
| const ADDRESSES_WITH_18_DECIMALS = [ | ||
| '0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE', // ETH | ||
| '0x2cFc85d8E48F8EAB294be644d9E25C3030863003', // WLD | ||
| '0x163f8c2467924be0ae7b5347228cabf260318753', // WLD | ||
| '0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1', // WLD | ||
| ].map(address => address.toLowerCase()) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using a more maintainable token configuration approach.
While the current implementation works, having hardcoded addresses might make maintenance challenging. Consider:
- Moving these addresses to a configuration file
- Using an object structure that maps addresses to their metadata (symbol, decimals, etc.)
- Adding comments explaining why there are multiple WLD addresses
Example structure:
interface TokenConfig {
symbol: string;
decimals: number;
description?: string;
}
const TOKEN_CONFIGS: Record<string, TokenConfig> = {
'0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee': {
symbol: 'ETH',
decimals: 18,
},
'0x2cfc85d8e48f8eab294be644d9e25c3030863003': {
symbol: 'WLD',
decimals: 18,
description: 'Worldchain Token - Network X',
},
// ... other configurations
};| * summary: Get transaction details by ID | ||
| * description: Retrieves details of a specific transaction by its ID |
There was a problem hiding this comment.
💡 Codebase verification
Based on the results, I can now generate the final response since the implementation code clearly shows that the endpoint supports lookup by both transaction ID and transaction hash through the OR condition in the query:
Documentation should mention support for both transaction ID and hash lookup
The current documentation undersells the endpoint's capabilities. The implementation shows that the endpoint supports lookup by both transactionId and transactionHash, but the documentation only mentions transaction ID lookup. The documentation should be expanded to reflect this dual functionality.
- Line 11: Update summary to "Get transaction details by ID or hash"
- Line 12: Expand description to "Retrieves details of a specific transaction by its ID or origin transaction hash"
- Line 19: Update parameter description to clarify that it accepts either transaction ID or hash
🔗 Analysis chain
Verify if the simplified endpoint description is accurate
The documentation has been simplified to only mention transaction ID lookup, removing references to origin transaction hash. Please confirm if this accurately reflects the current implementation's capabilities.
Also applies to: 19-19
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the controller implementation still supports origin transaction hash lookup
rg -A 10 "getTransactionById" packages/rfq-indexer/api/src/controllers/
Length of output: 1185
| @@ -10,6 +10,7 @@ export interface BridgeRequestEvents { | |||
| originChainId: ColumnType<number> | |||
| originChain: ColumnType<string> | |||
| sender: ColumnType<string> | |||
| request: ColumnType<string> | |||
There was a problem hiding this comment.
💡 Codebase verification
The request field should be marked as non-nullable in TypeScript
The GraphQL schema explicitly defines the request field as String! (non-nullable), but the TypeScript interface shows it as ColumnType<string> without a non-null constraint. To maintain type consistency, the TypeScript definition should reflect the same nullability constraint as the GraphQL schema.
- In
packages/rfq-indexer/api/src/types/index.ts, update the field to enforce non-nullability:request: ColumnType<string>!
🔗 Analysis chain
Verify nullable constraint consistency with GraphQL schema.
The AI summary indicates this field is non-nullable (String!) in the GraphQL schema, but the TypeScript interface doesn't reflect this constraint. Consider making the types consistent across the codebase.
Let me gather more information about the request field definition in the GraphQL schema.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the request field is consistently defined as non-nullable across the codebase
# Test 1: Check GraphQL schema definition
echo "Checking GraphQL schema definition..."
rg -A 1 "type BridgeRequestEvent"
# Test 2: Check database schema definition
echo "Checking database schema definition..."
rg -A 1 "BridgeRequestEvents.*request"
Length of output: 782
Script:
#!/bin/bash
# Check the complete definition of BridgeRequestEvent type in GraphQL schema
echo "Checking complete BridgeRequestEvent type definition..."
rg -A 20 "type BridgeRequestEvent" packages/rfq-indexer/api/src/graphql/types/events.graphql
# Check the database table definition
echo "Checking database table definition..."
rg -A 20 "CREATE TABLE.*bridge_request_events"
Length of output: 833
| @@ -180,6 +180,7 @@ type DateResultByChain { | |||
| blast: Float | |||
| scroll: Float | |||
| linea: Float | |||
| worldchain: Float | |||
There was a problem hiding this comment.
💡 Codebase verification
Chain naming inconsistency detected
The codebase shows inconsistent naming conventions for "worldchain":
- GraphQL schema and queries use lowercase
worldchain - Constants and type definitions use uppercase
WORLDCHAIN - Some references use "Worldchain" (first letter capitalized)
- Chain ID 480 is consistently used across all references
Consider standardizing to either:
- Use
WORLDCHAINfor constants/enums - Use
Worldchainfor display names/labels - Use
worldchainfor variable names and GraphQL fields
Locations needing alignment:
services/explorer/static/chainIDs.yaml: Uses 'Worldchain'services/explorer/graphql/server/graph/schema/types.graphql: Uses 'worldchain'packages/synapse-constants/src/constants/chains/master.ts: Mixed usagepackages/rfq-indexer/api/src/constants/networkConfig.ts: Uses 'Worldchain'
🔗 Analysis chain
Verify chain name consistency.
The field addition looks good, but let's verify the chain name is consistent across the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent naming of "worldchain" across the codebase
# Expect: All references should use the same casing (worldchain vs Worldchain vs WorldChain)
echo "Checking for different variations of worldchain naming:"
rg -i "worldchain" --type-add 'config:*.{json,yaml,yml,env}' -g '!node_modules' -t config
rg -i "worldchain" --type=go
rg -i "worldchain" --type=graphql
Length of output: 3450
Script:
#!/bin/bash
# Let's check GraphQL files specifically since the previous command didn't recognize the type
rg -i "worldchain" --type-add 'graphql:*.graphql' -t graphql
# Also check for any other potential references in TypeScript/JavaScript files
rg -i "worldchain" --type=ts --type=js
Length of output: 9029
| @@ -155,6 +155,7 @@ query GetDailyStatisticsByChain($chainID: Int, $type: DailyStatisticType, $durat | |||
| blast | |||
| scroll | |||
| linea | |||
| worldchain | |||
There was a problem hiding this comment.
💡 Codebase verification
Frontend integration needs to be updated for the worldchain field
The frontend components are using the GetDailyStatisticsByChain query but need to be updated to handle the new worldchain field in the statistics data. The changes required are:
- Update chart data processing in
packages/explorer-ui/components/pages/Home/index.tsxto handle the worldchain field in the cumulative calculations - Update chart data processing in
packages/explorer-ui/pages/chain/[chainId].tsxto handle the worldchain field in chain-specific views
🔗 Analysis chain
LGTM! The worldchain field is properly integrated.
The addition of the worldchain field follows the existing pattern and maintains consistency with other chain fields in the query response structure.
Let's verify the frontend integration:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the frontend components are updated to handle the new worldchain field
# Test: Search for components that consume the GetDailyStatisticsByChain query
rg -l "GetDailyStatisticsByChain"
# Test: Look for any worldchain-related UI components or charts
rg -i "worldchain.*component|worldchain.*chart"
Length of output: 291
Script:
#!/bin/bash
# Let's check the actual usage of GetDailyStatisticsByChain in the frontend code
# and server implementation to understand the integration better
# Check the resolver implementation to see how worldchain is handled
rg -A 10 "GetDailyStatisticsByChain" services/explorer/api/server.go
# Check the test files to understand the expected behavior
rg -A 5 "worldchain" services/explorer/api/server_test.go services/explorer/api/resolver_test.go
# Look for any frontend components that might consume statistics data
rg -l "DailyStatistics|ChainStatistics"
Length of output: 20302
Script:
#!/bin/bash
# Let's check the frontend components to see how they handle chain statistics
# Check the Home page component for statistics handling
rg -A 10 "DailyStatistics" packages/explorer-ui/components/pages/Home/index.tsx
# Check the GraphQL query definitions in the UI
rg -A 5 "GetDailyStatisticsByChain" packages/explorer-ui/graphql/queries/index.ts
# Check the chain-specific page for statistics handling
rg -A 10 "DailyStatistics" "packages/explorer-ui/pages/chain/[chainId].tsx"
Length of output: 2417
| <Bar | ||
| isAnimationActive={false} | ||
| dataKey="worldchain" | ||
| stackId="a" | ||
| fill={loading ? 'rgba(255, 255, 255, 0.1)' : '#FFFFFF'} | ||
| /> |
There was a problem hiding this comment.
Consider adjusting the worldchain bar color for better visibility
The white fill color (#FFFFFF) might make the bar difficult to see on light backgrounds. Consider using a more distinctive color that maintains good contrast across different background colors.
Apply this change to improve visibility:
- fill={loading ? 'rgba(255, 255, 255, 0.1)' : '#FFFFFF'}
+ fill={loading ? 'rgba(255, 255, 255, 0.1)' : '#4A90E2'}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <Bar | |
| isAnimationActive={false} | |
| dataKey="worldchain" | |
| stackId="a" | |
| fill={loading ? 'rgba(255, 255, 255, 0.1)' : '#FFFFFF'} | |
| /> | |
| <Bar | |
| isAnimationActive={false} | |
| dataKey="worldchain" | |
| stackId="a" | |
| fill={loading ? 'rgba(255, 255, 255, 0.1)' : '#4A90E2'} | |
| /> |
| } else if strings.EqualFold(tokenAddressStr, "0x2cFc85d8E48F8EAB294be644d9E25C3030863003") || strings.EqualFold(tokenAddressStr, "0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1") { | ||
| rfqEvent.TokenSymbol = "WLD" | ||
| rfqEvent.TokenDecimal = new(uint8) | ||
| *rfqEvent.TokenDecimal = 18 | ||
| curCoinGeckoID = "worldchain" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Extract token addresses as named constants.
The hardcoded WLD token addresses should be moved to named constants at the package level for better maintainability and documentation.
+const (
+ // WLDTokenAddress1 represents the primary WLD token contract on chain X
+ WLDTokenAddress1 = "0x2cFc85d8E48F8EAB294be644d9E25C3030863003"
+ // WLDTokenAddress2 represents the secondary WLD token contract on chain Y
+ WLDTokenAddress2 = "0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1"
+)
func (p *RFQParser) MatureLogs(ctx context.Context, rfqEvent *model.RFQEvent, iFace rfqTypes.EventLog, chainID uint32) (interface{}, error) {
// ...
- } else if strings.EqualFold(tokenAddressStr, "0x2cFc85d8E48F8EAB294be644d9E25C3030863003") || strings.EqualFold(tokenAddressStr, "0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1") {
+ } else if strings.EqualFold(tokenAddressStr, WLDTokenAddress1) || strings.EqualFold(tokenAddressStr, WLDTokenAddress2) {Committable suggestion was skipped due to low confidence.
| rfqEvent.TokenSymbol = "WLD" | ||
| rfqEvent.TokenDecimal = new(uint8) | ||
| *rfqEvent.TokenDecimal = 18 | ||
| curCoinGeckoID = "worldchain" |
There was a problem hiding this comment.
💡 Codebase verification
Based on the search results, I can now provide a definitive response about the CoinGecko ID verification:
The CoinGecko ID "worldchain" appears incorrect and needs to be updated
The codebase shows that:
- The token being referenced is "WLD" (Worldcoin)
- The CoinGecko price fetching implementation expects valid CoinGecko IDs to be mapped in
coingeckoIDLookup - "worldchain" is not a valid CoinGecko ID - it appears to be confused with the chain ID (480) for World Chain
This needs to be corrected to use the proper CoinGecko ID for the WLD token.
🔗 Analysis chain
Verify CoinGecko ID "worldchain" exists.
The code assumes the existence of a "worldchain" CoinGecko ID for price data fetching. This needs verification to prevent potential runtime issues.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for CoinGecko ID usage and configuration
# Test: Look for CoinGecko ID configuration. Expect: "worldchain" ID definition or usage
# Search for CoinGecko ID definitions
echo "Searching for CoinGecko ID definitions..."
rg -l "worldchain.*coingecko"
# Search for CoinGecko price fetching configurations
echo "Searching for CoinGecko price fetching configurations..."
rg -l "GetPriceData.*worldchain"
Length of output: 282
Script:
#!/bin/bash
# Let's try a broader search for CoinGecko related configurations and worldchain mentions
# Search for CoinGecko configuration files
echo "=== Searching for CoinGecko configuration files ==="
fd -e json -e yaml -e toml | xargs rg -l "coingecko"
# Search for worldchain mentions in the codebase
echo -e "\n=== Searching for worldchain mentions ==="
rg -i "worldchain" -A 3 -B 3
# Search for CoinGecko price related code
echo -e "\n=== Searching for CoinGecko price fetching code ==="
rg "coingecko.*id" -A 3 -B 3
Length of output: 55782
Script:
#!/bin/bash
# Let's search for CoinGecko ID mappings and price fetching configurations
# Search for CoinGecko ID mappings
echo "=== Searching for CoinGecko ID mappings ==="
rg -A 5 -B 5 "coingeckoIDLookup"
# Search for token price service implementations
echo -e "\n=== Searching for token price service implementations ==="
rg -A 10 -B 10 "type.*PriceService"
# Search for WLD token configurations
echo -e "\n=== Searching for WLD token configurations ==="
rg -A 5 -B 5 '"WLD".*coingecko'
Length of output: 5140
| "480_0x2cFc85d8E48F8EAB294be644d9E25C3030863003": {"WLD", 18, "0x2cFc85d8E48F8EAB294be644d9E25C3030863003"}, | ||
| "10_0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1": {"WLD", 18, "0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1"}, | ||
| "480_0x79A02482A880bCE3F13e09Da970dC34db4CD24d1": {"USDC.e", 6, "0x79A02482A880bCE3F13e09Da970dC34db4CD24d1"}, | ||
| "480_0x4200000000000000000000000000000000000006": {"WETH", 18, "0x4200000000000000000000000000000000000006"}, | ||
| "1_0x163f8c2467924be0ae7b5347228cabf260318753": {"WLD", 18, "0x163f8c2467924be0ae7b5347228cabf260318753"}, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider enhancing token data management and documentation.
While the token additions are structurally correct, consider the following improvements:
- Add comments documenting the source/authority for these token addresses
- Consider moving token data to a configuration file for easier maintenance
- Add validation checks for token addresses during initialization
Consider refactoring to use a configuration-based approach:
// config/tokens.yaml
tokens:
worldchain:
wld:
address: "0x2cFc85d8E48F8EAB294be644d9E25C3030863003"
decimals: 18
chain_id: 480
usdc_e:
address: "0x79A02482A880bCE3F13e09Da970dC34db4CD24d1"
decimals: 6
chain_id: 480
# ... more tokensThis would make token management more maintainable and less error-prone.
| func (ec *executionContext) _DateResultByChain_worldchain(ctx context.Context, field graphql.CollectedField, obj *model.DateResultByChain) (ret graphql.Marshaler) { | ||
| fc, err := ec.fieldContext_DateResultByChain_worldchain(ctx, field) | ||
| if err != nil { | ||
| return graphql.Null | ||
| } | ||
| ctx = graphql.WithFieldContext(ctx, fc) | ||
| defer func() { | ||
| if r := recover(); r != nil { | ||
| ec.Error(ctx, ec.Recover(ctx, r)) | ||
| ret = graphql.Null | ||
| } | ||
| }() | ||
| resTmp, err := ec.ResolverMiddleware(ctx, func(rctx context.Context) (interface{}, error) { | ||
| ctx = rctx // use context from middleware stack in children | ||
| return obj.Worldchain, nil | ||
| }) | ||
| if err != nil { | ||
| ec.Error(ctx, err) | ||
| return graphql.Null | ||
| } | ||
| if resTmp == nil { | ||
| return graphql.Null | ||
| } | ||
| res := resTmp.(*float64) | ||
| fc.Result = res | ||
| return ec.marshalOFloat2ᚖfloat64(ctx, field.Selections, res) | ||
| } | ||
|
|
||
| func (ec *executionContext) fieldContext_DateResultByChain_worldchain(ctx context.Context, field graphql.CollectedField) (fc *graphql.FieldContext, err error) { | ||
| fc = &graphql.FieldContext{ | ||
| Object: "DateResultByChain", | ||
| Field: field, | ||
| IsMethod: false, | ||
| IsResolver: false, | ||
| Child: func(ctx context.Context, field graphql.CollectedField) (*graphql.FieldContext, error) { | ||
| return nil, errors.New("field of type Float does not have child fields") | ||
| }, | ||
| } | ||
| return fc, nil | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider adding validation for negative values.
While the resolver implementation is correct, consider adding validation to ensure the Worldchain value is not negative, as this represents financial data (transaction volume).
func (ec *executionContext) _DateResultByChain_worldchain(ctx context.Context, field graphql.CollectedField, obj *model.DateResultByChain) (ret graphql.Marshaler) {
// ... existing code ...
if resTmp == nil {
return graphql.Null
}
res := resTmp.(*float64)
+ if res != nil && *res < 0 {
+ ec.Error(ctx, fmt.Errorf("worldchain value cannot be negative"))
+ return graphql.Null
+ }
fc.Result = res
return ec.marshalOFloat2ᚖfloat64(ctx, field.Selections, res)
}Committable suggestion was skipped due to low confidence.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
- packages/rfq-indexer/indexer/abis/FastBridgeV2.ts (1 hunks)
- packages/rfq-indexer/indexer/src/index.ts (2 hunks)
- packages/rfq-indexer/indexer/src/utils/formatAmount.ts (1 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/rfq-indexer/indexer/abis/FastBridgeV2.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/rfq-indexer/indexer/src/index.ts
🔇 Additional comments (1)
packages/rfq-indexer/indexer/src/utils/formatAmount.ts (1)
3-8: Previous review feedback about token configuration remains unaddressed.
The current implementation with multiple WLD addresses still lacks clarity about their purpose and differences. The previous suggestion about moving to a configuration-based approach remains valid.
Let's verify if these WLD addresses are used consistently across the codebase:
#!/bin/bash
# Search for WLD addresses usage to understand their context
rg -i "0x2cFc85d8E48F8EAB294be644d9E25C3030863003|0x163f8c2467924be0ae7b5347228cabf260318753|0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1" -A 3 -B 3| export const formatAmount = (amount: bigint, tokenAddress: string): string => { | ||
| const decimals = ADDRESSES_WITH_18_DECIMALS.includes( | ||
| tokenAddress.toLowerCase() | ||
| ) | ||
| ? 18 | ||
| : 6 | ||
| return formatUnits(amount, decimals) | ||
| } No newline at end of file | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider performance and maintainability improvements.
- The
toLowerCase()conversion is performed for every check, while the input addresses are already lowercased during initialization. - The default of 6 decimals is not documented.
Consider this implementation:
export const formatAmount = (amount: bigint, tokenAddress: string): string => {
+ if (!tokenAddress) {
+ throw new Error('Token address is required');
+ }
+ // Convert to lowercase once
+ const normalizedAddress = tokenAddress.toLowerCase();
const decimals = ADDRESSES_WITH_18_DECIMALS.includes(
- tokenAddress.toLowerCase()
+ normalizedAddress
)
? 18
- : 6
+ : 6 // Default for tokens with 6 decimal places (e.g., USDC, USDT)
return formatUnits(amount, decimals)
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export const formatAmount = (amount: bigint, tokenAddress: string): string => { | |
| const decimals = ADDRESSES_WITH_18_DECIMALS.includes( | |
| tokenAddress.toLowerCase() | |
| ) | |
| ? 18 | |
| : 6 | |
| return formatUnits(amount, decimals) | |
| } | |
| \ No newline at end of file | |
| } | |
| export const formatAmount = (amount: bigint, tokenAddress: string): string => { | |
| if (!tokenAddress) { | |
| throw new Error('Token address is required'); | |
| } | |
| // Convert to lowercase once | |
| const normalizedAddress = tokenAddress.toLowerCase(); | |
| const decimals = ADDRESSES_WITH_18_DECIMALS.includes( | |
| normalizedAddress | |
| ) | |
| ? 18 | |
| : 6 // Default for tokens with 6 decimal places (e.g., USDC, USDT) | |
| return formatUnits(amount, decimals) | |
| } |
There was a problem hiding this comment.
Actionable comments posted: 12
🧹 Outside diff range and nitpick comments (26)
services/explorer/static/chainIDs.yaml (1)
Line range hint 1-22: Consider sorting chain IDs numerically.
The file currently has chain IDs in a mixed order. Consider sorting them numerically for better maintainability and easier lookup.
Here's the suggested order:
packages/rfq-indexer/api/src/queries/depositsQueries.ts (1)
Line range hint 24-27: Consider extracting the timestamp filter to a configurable constant
The hardcoded timestamp (1722729600) would be more maintainable if extracted to a named constant or configuration value. This would make it easier to update and understand its purpose.
+const MIN_BLOCK_TIMESTAMP = 1722729600; // April 2024: Prevent partial index data issues
export const qDeposits = () => {
return db
.selectFrom('BridgeRequestEvents')
.select([
// ... fields ...
])
- .where('BridgeRequestEvents.blockTimestamp', '>', 1722729600)
+ .where('BridgeRequestEvents.blockTimestamp', '>', MIN_BLOCK_TIMESTAMP)packages/rfq-indexer/api/src/routes/disputesRoute.ts (1)
Line range hint 15-42: Consider adding response examples to the OpenAPI documentation.
While the schema is well-defined, adding examples would make the documentation more developer-friendly.
Add examples using the OpenAPI example field:
* type: object
* description: General transaction fields
+* example:
+* txHash: "0x1234..."
+* blockNumber: 12345
* BridgeRequest:
* type: object
* description: Deposit information
+* example:
+* amount: "1000000000000000000"
+* token: "0xabcd..."packages/rfq-indexer/api/src/routes/invalidRelaysRoute.ts (1)
Line range hint 15-42: Consider adding response examples to enhance documentation.
While the schema is well-documented, adding examples would make the API documentation more developer-friendly.
Add examples using the example field in OpenAPI spec:
items:
type: object
+ example:
+ Bridge:
+ txHash: "0x123..."
+ fromChain: "ethereum"
+ toChain: "worldchain"
+ BridgeRequest:
+ amount: "1000000000000000000"
+ timestamp: "2024-10-15T14:30:00Z"
+ BridgeRelay:
+ relayer: "0xabc..."
+ status: "invalid"packages/rfq-indexer/api/src/routes/refundedAndRelayedRoute.ts (1)
Line range hint 16-39: Consider adding response examples
The schema documentation is comprehensive, but adding examples would make it even more developer-friendly. Consider adding example responses for both populated and empty array scenarios.
* items:
* type: object
* properties:
* Bridge:
* type: object
* description: General transaction fields
+* example:
+* txHash: "0x1234..."
+* timestamp: 1634567890
* BridgeRequest:
* type: object
* description: Deposit information
+* example:
+* amount: "1000000000000000000"
+* sourceChain: "ethereum"
* BridgeRelay:
* type: object
* description: Relay information
+* example:
+* relayerAddress: "0xabcd..."
+* relayTimestamp: 1634567990
+* examples:
+* withResults:
+* value: [{ Bridge: {...}, BridgeRequest: {...} }]
+* empty:
+* value: []packages/rfq-indexer/api/src/routes/conflictingProofsRoute.ts (1)
Line range hint 15-42: Consider enhancing documentation with examples.
While the schema is well-documented, adding examples would make the API documentation more developer-friendly. Consider including sample responses showing both cases: conflicting proofs found and empty array scenario.
Example addition:
* BridgeDispute:
* type: object
* description: Dispute information (if available)
+* examples:
+* conflicting_proofs_found:
+* value:
+* - Bridge:
+* txHash: "0x123..."
+* BridgeRelay:
+* relayer: "0xabc..."
+* BridgeProof:
+* relayer: "0xdef..."
+* no_conflicting_proofs:
+* value: []packages/rfq-indexer/api/src/graphql/types/events.graphql (1)
20-20: Add documentation for the new request field.
While the field is properly typed, please add documentation comments to explain what this field represents and its purpose in bridge requests.
Apply this diff to add documentation:
destChainId: Int!
destChain: String!
+ """
+ The serialized bridge request data.
+ """
request: String!
sendChainGas: Boolean!packages/rfq-indexer/api/src/routes/transactionIdRoute.ts (1)
28-48: Enhance response schema documentation
While the response schema structure is well-organized, several improvements would make the documentation more useful:
- Add example responses for each component
- Specify required vs optional fields
- Add detailed property definitions for each object
- Re-add 500 error response documentation for server errors
Example enhancement for one component:
* Bridge:
* type: object
* description: General transaction fields
+* required:
+* - id
+* - status
+* properties:
+* id:
+* type: string
+* description: Transaction identifier
+* status:
+* type: string
+* enum: [pending, completed, failed]
+* description: Current transaction status
+* example:
+* id: "0x1234..."
+* status: "completed"packages/rfq-indexer/indexer/ponder.schema.ts (1)
8-8: Add documentation for the new request field.
The schema change looks good, but please add a comment explaining the purpose and expected format of the request field to improve maintainability.
Apply this diff:
sender: p.string(),
+ // Stores the serialized bridge request data
request: p.string(),packages/rfq-indexer/api/src/constants/networkConfig.ts (2)
118-128: Consider documenting network-specific details
While the configuration is technically correct, consider adding comments to document:
- The rationale for reusing the FastBridgeV2 address from Ethereum/Arbitrum
- Any network-specific considerations for Worldchain
Add documentation above the configuration:
+ // Worldchain configuration
+ // FastBridgeV2 address shared with Ethereum mainnet deployment
+ // Chain ID: 480124-127: Consider adding transport configuration
The current implementation uses the default HTTP transport without specific configuration. Consider whether Worldchain requires specific RPC endpoints or retry configurations.
packages/rfq-indexer/api/src/types/index.ts (1)
13-13: Add documentation for the new request field.
While the type definition is correct, please add JSDoc comments explaining the purpose and expected format of the request field to improve maintainability.
Consider adding documentation like this:
+ /** Serialized bridge request data */
request: ColumnType<string>services/explorer/graphql/server/graph/schema/types.graphql (1)
183-183: LGTM! Consider adding field documentation.
The addition of the worldchain field follows the schema's conventions for chain-specific statistics.
Consider adding a description for better maintainability:
+ """
+ Volume/count for Worldchain network
+ """
worldchain: Floatpackages/rfq-indexer/api/src/routes/pendingTransactionsRoute.ts (2)
20-20: Document this breaking change in API changelog.
Removing 404 responses in favor of empty arrays is a breaking change that might affect existing clients. Consider documenting this change in your API changelog and notifying API consumers.
Also applies to: 69-69, 101-101, 131-131
Line range hint 1-150: Consider extracting common schema definitions.
The response schemas contain repeated object structures (e.g., deposit, relay objects). Consider extracting these into reusable OpenAPI components to improve maintainability and reduce duplication.
Example refactor:
/**
* @openapi
* components:
* schemas:
* Deposit:
* type: object
* description: Deposit information
* Relay:
* type: object
* description: Relay information
* ErrorResponse:
* type: object
* properties:
* message:
* type: string
*/Then reference these in your endpoint schemas using $ref: '#/components/schemas/Deposit'
packages/rfq-indexer/api/src/controllers/pendingTransactionsController.ts (1)
41-41: LGTM! Status code change aligns with REST best practices.
Returning 200 with an empty result set is more appropriate than 404, which should be reserved for "resource not found" scenarios. This change improves API consistency.
Consider these additional improvements for better API design:
- Standardize the response format across all endpoints to always return an object with:
data: array (empty when no results)message: string (optional)
- Consider adding pagination metadata even for empty results to maintain consistent response structure.
Also applies to: 79-79, 124-124, 169-169
packages/rfq-indexer/indexer/src/index.ts (1)
Line range hint 1-38: Document and test the new request field integration.
The addition of the request field to bridge request events requires:
- Documentation updates explaining the field's purpose and format
- GraphQL schema updates to expose the new field
- Integration tests to verify event processing with the new field
Consider adding:
- Field documentation in README or API docs
- Test cases covering the new field in bridge request scenarios
- GraphQL schema updates if this field needs to be queryable
services/explorer/api/server_test.go (1)
38-62: Consider adding validation for required fields.
The struct definition includes many nullable fields (*float64), but there's no clear indication of which fields are required vs optional. Consider adding validation in the test to ensure critical fields are present.
Add field validation:
// Add this helper function
func TestRequiredFieldsPresent(t *testing.T) {
valueStruct := gqlClient.GetDailyStatisticsByChain{
Response: []*struct{
// ... existing fields ...
}{
{
Date: nil, // Date should be required
Total: nil, // Total should be required
},
},
}
res := api.HandleJSONDailyStat(&valueStruct)
NotNil(t, res)
// Add assertions for required fields
NotNil(t, res[0].Date, "Date field should be required")
NotNil(t, res[0].Total, "Total field should be required")
}packages/rfq-indexer/indexer/ponder.config.ts (1)
240-244: Fix code formatting for consistency.
The line breaks in the contract configuration differ from other chain configurations. Let's maintain consistent formatting.
[configByChainId[worldchainChainId].chainName]: {
address: networkDetails[worldchainChainId]?.FastBridgeV2.address,
- startBlock:
- networkDetails[worldchainChainId]?.FastBridgeV2.startBlock,
+ startBlock: networkDetails[worldchainChainId]?.FastBridgeV2.startBlock,
},services/explorer/consumer/parser/tokendata/cache.go (2)
290-295: Document the token mapping additions.
Consider adding comments to document:
- The purpose of adding these specific tokens
- The relationship between these tokens (e.g., if USDC.e is a bridged version of USDC)
- The significance of chain ID 480 (Worldchain)
Add documentation above the new entries:
"1_0xAdF7C35560035944e805D98fF17d58CDe2449389": {"SPEC", 18, "0xAdF7C35560035944e805D98fF17d58CDe2449389"},
"8453_0x96419929d7949D6A801A6909c145C8EEf6A40431": {"SPEC", 18, "0x96419929d7949D6A801A6909c145C8EEf6A40431"},
+ // Worldchain (chain ID: 480) token mappings
+ // WLD: Native token of Worldchain
+ // USDC.e: Bridged version of USDC on Worldchain
+ // WETH: Wrapped ETH on Worldchain
"480_0x2cFc85d8E48F8EAB294be644d9E25C3030863003": {"WLD", 18, "0x2cFc85d8E48F8EAB294be644d9E25C3030863003"},290-295: Consider adding validation for chain IDs.
The hardcoded chain IDs in the map keys could benefit from validation against a central source of truth for supported chains.
Consider:
- Creating a constants package for chain IDs
- Adding runtime validation to ensure all chain IDs in the map are supported
- Adding tests to verify token data consistency across chains
services/rfq/relayer/quoter/quoter_test.go (2)
Line range hint 256-309: Resolve merge conflicts
There are unresolved merge conflict markers in the test file. The conflicting sections appear to contain duplicate implementations of the same test case. This needs to be resolved before the code can be merged.
Remove one of the duplicate sections and the conflict markers:
- <<<<<<< HEAD
quoteAmount, err = s.manager.GetOriginAmount(s.GetTestContext(), input)
s.NoError(err)
expectedAmount = big.NewInt(500_000_000)
s.Equal(expectedAmount, quoteAmount)
// Set QuotePct to 25 with MinQuoteAmount of 500; should be 50% of balance.
setQuoteParams(quoteParams{
quotePct: 25,
quoteOffset: 0,
minQuoteAmount: "500",
maxBalance: "0",
})
- =======
- >>>>>>> master
quoteAmount, err = s.manager.GetOriginAmount(s.GetTestContext(), input)
s.NoError(err)
expectedAmount = big.NewInt(500_000_000)
s.Equal(expectedAmount, quoteAmount)
// Set QuotePct to 25 with MinQuoteAmount of 500; should be 50% of balance.
setQuoteParams(quoteParams{
quotePct: 25,
quoteOffset: 0,
minQuoteAmount: "500",
maxBalance: "0",
})🧰 Tools
🪛 GitHub Check: Lint (services/rfq)
[failure] 256-256:
expected statement, found '<<' (typecheck)
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
262-272: Consider adding error case tests for invalid quote parameters
While the test coverage for valid quote parameters is good, consider adding test cases for invalid scenarios such as:
- Negative quote percentages
- Quote offsets outside reasonable bounds
- Invalid combinations of quote parameters
Would you like me to help generate these additional test cases?
packages/rfq-indexer/api/src/graphql/resolvers.ts (1)
Line range hint 1-23: Consider adding documentation for the new request field.
The request field has been added to the qDeposits function, but its purpose and format are not documented. Consider adding a comment explaining:
- The purpose of this field
- Expected format/structure of the data
- Any validation requirements
const qDeposits = () => {
+ // request: Contains the serialized bridge request data
+ // Format: JSON string containing {...}
return dbservices/explorer/graphql/server/graph/partials.go (1)
Technical debt confirmed: Chain definitions are duplicated and hardcoded
The verification reveals:
- A central chain registry exists in
services/explorer/static/chainIDs.yaml, but it's not being utilized across the codebase - The same chain definitions are duplicated in multiple SQL queries in
partials.go - Each service maintains its own chain configuration maps (e.g., in
config.gofiles)
This creates maintenance overhead and risk of inconsistencies when:
- Adding new chains
- Updating chain information
- Ensuring consistency across services
Recommendations:
- Create a shared chain registry package
- Generate SQL queries dynamically using the registry
- Have services import chain configurations from the central registry
- Implement proper validation to ensure chain IDs match the registry
🔗 Analysis chain
Line range hint 404-714: Consider implementing a more dynamic query generation system.
The current approach of manually listing chains in multiple SQL queries creates maintenance overhead and increases the risk of inconsistencies. Consider:
- Implementing a dynamic chain registry
- Generating these queries programmatically
- Using a more flexible data structure that doesn't require query modifications for new chains
This would reduce technical debt and make the system more maintainable.
Let's verify the extent of this pattern:
Let me search for any existing chain registry or configuration to see if we can validate the full extent of this hardcoding:
Let me check if there's a centralized chain registry or configuration that could be leveraged:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all hardcoded chain definitions to assess the scope of the technical debt
# Search for chain ID definitions
rg "results\[\d+\]\s+AS\s+\w+" -A 1
Length of output: 14170
Script:
#!/bin/bash
# Look for chain configuration or registry files
fd -e go -e json -e yaml -e toml . | rg -i "chain|network"
# Look for any chain ID definitions in Go code
rg "const.*chain.*id|var.*chain.*id|map\[.*\].*chain" -t go
Length of output: 188774
Script:
#!/bin/bash
# Look for chain configuration files and potential registry implementations
fd -e yaml -e go . | rg -i "chain.*config|chain.*registry"
# Look for the chain IDs yaml file specifically mentioned in the output
cat services/explorer/static/chainIDs.yaml 2>/dev/null
Length of output: 595
services/explorer/graphql/server/graph/resolver/server.go (1)
4844-4883: Add documentation for the Worldchain resolver
While the implementation is correct and follows the established pattern, consider adding documentation comments to explain the resolver's purpose and any specific Worldchain considerations.
+// _DateResultByChain_worldchain resolves the worldchain field for DateResultByChain.
+// It returns the transaction volume for the Worldchain blockchain.
func (ec *executionContext) _DateResultByChain_worldchain(ctx context.Context, field graphql.CollectedField, obj *model.DateResultByChain) (ret graphql.Marshaler) {📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (36)
- packages/explorer-ui/components/ChainChart/index.tsx (1 hunks)
- packages/rfq-indexer/api/src/constants/networkConfig.ts (2 hunks)
- packages/rfq-indexer/api/src/controllers/conflictingProofsController.ts (1 hunks)
- packages/rfq-indexer/api/src/controllers/disputesController.ts (1 hunks)
- packages/rfq-indexer/api/src/controllers/pendingTransactionsController.ts (7 hunks)
- packages/rfq-indexer/api/src/controllers/transactionIdController.ts (2 hunks)
- packages/rfq-indexer/api/src/graphql/resolvers.ts (1 hunks)
- packages/rfq-indexer/api/src/graphql/types/events.graphql (1 hunks)
- packages/rfq-indexer/api/src/queries/depositsQueries.ts (1 hunks)
- packages/rfq-indexer/api/src/routes/conflictingProofsRoute.ts (1 hunks)
- packages/rfq-indexer/api/src/routes/disputesRoute.ts (1 hunks)
- packages/rfq-indexer/api/src/routes/invalidRelaysRoute.ts (1 hunks)
- packages/rfq-indexer/api/src/routes/pendingTransactionsRoute.ts (4 hunks)
- packages/rfq-indexer/api/src/routes/refundedAndRelayedRoute.ts (1 hunks)
- packages/rfq-indexer/api/src/routes/transactionIdRoute.ts (2 hunks)
- packages/rfq-indexer/api/src/types/index.ts (1 hunks)
- packages/rfq-indexer/indexer/.env.example (1 hunks)
- packages/rfq-indexer/indexer/ponder.config.ts (5 hunks)
- packages/rfq-indexer/indexer/ponder.schema.ts (1 hunks)
- packages/rfq-indexer/indexer/src/index.ts (2 hunks)
- packages/rfq-indexer/indexer/src/utils/chains.ts (1 hunks)
- packages/rfq-indexer/indexer/src/utils/formatAmount.ts (1 hunks)
- services/explorer/api/server_test.go (1 hunks)
- services/explorer/consumer/parser/rfqparser.go (1 hunks)
- services/explorer/consumer/parser/tokendata/cache.go (1 hunks)
- services/explorer/graphql/client/client.go (2 hunks)
- services/explorer/graphql/client/queries/queries.graphql (1 hunks)
- services/explorer/graphql/server/graph/model/models_gen.go (1 hunks)
- services/explorer/graphql/server/graph/partials.go (6 hunks)
- services/explorer/graphql/server/graph/resolver/server.go (6 hunks)
- services/explorer/graphql/server/graph/schema/types.graphql (1 hunks)
- services/explorer/static/chainIDs.yaml (1 hunks)
- services/explorer/static/tokenIDToCoinGeckoID.yaml (1 hunks)
- services/explorer/static/tokenSymbolToCoinGeckoID.yaml (1 hunks)
- services/explorer/static/tokenSymbolToTokenID.yaml (1 hunks)
- services/rfq/relayer/quoter/quoter_test.go (3 hunks)
✅ Files skipped from review due to trivial changes (4)
- packages/rfq-indexer/api/src/controllers/conflictingProofsController.ts
- packages/rfq-indexer/api/src/controllers/disputesController.ts
- packages/rfq-indexer/api/src/controllers/transactionIdController.ts
- packages/rfq-indexer/indexer/.env.example
🧰 Additional context used
🪛 GitHub Check: Lint (services/rfq)
services/rfq/relayer/quoter/quoter_test.go
[failure] 256-256:
expected statement, found '<<' (typecheck)
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
[failure] 256-256:
expected statement, found '<<'
🔇 Additional comments (39)
packages/rfq-indexer/indexer/src/utils/chains.ts (2)
10-10: Implementation follows established patterns
The addition follows the existing code patterns:
- Maintains consistent lowercase naming convention
- Uses numeric chain ID as key
- Follows the same type structure
10-10: Verify Worldchain chain ID authenticity
Let's verify that chain ID 480 is the official chain ID for Worldchain to prevent potential security issues from chain ID spoofing.
✅ Verification successful
Let me search for more specific information about chain ID 480 in configuration files.
Let me search for any additional references to Worldchain in the codebase to verify its configuration.
Chain ID 480 is verified as the official Worldchain ID
The verification confirms that chain ID 480 is consistently configured across the codebase as Worldchain's official chain ID, with proper integration including:
- RPC endpoints at
worldchain-mainnet.g.alchemy.com - Explorer URL at
worldchain-mainnet.explorer.alchemy.com - Consistent token contract addresses and configurations
- Integration with FastBridge and other core infrastructure
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for chain ID verification in configuration files
rg -l "480" --type yaml --type json
Length of output: 5553
Script:
#!/bin/bash
# Search for chain ID 480 in network configurations and chain definitions
rg -A 5 -B 5 '"480"' --type json --type yaml packages/synapse-interface/ services/explorer/
Length of output: 1196
Script:
#!/bin/bash
# Search for "worldchain" references in the codebase
rg -i "worldchain" --type ts --type json --type yaml -C 3
Length of output: 34682
services/explorer/static/chainIDs.yaml (1)
22-22: Verify the Worldchain chain ID and add documentation.
While the format is consistent with other entries, please ensure that:
- The chain ID 480 is the official identifier for Worldchain
- Documentation about this network's integration is added to the repository
Let's verify the chain ID and gather more context:
services/explorer/static/tokenSymbolToTokenID.yaml (1)
45-45: Verify token mapping consistency across configuration files.
Let's ensure this new token mapping is consistently defined across related configuration files.
✅ Verification successful
Token mapping is consistently defined across configuration files ✓
The Worldcoin token mapping is correctly and consistently defined across all three configuration files:
tokenSymbolToCoinGeckoID.yaml:wld: 'worldcoin'tokenSymbolToTokenID.yaml:wld: 'worldcoin'tokenIDToCoinGeckoID.yaml:WLD: 'worldcoin'
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent Worldcoin token mappings across configuration files
echo "Checking token mapping consistency..."
# Check related token mapping files
rg -l "worldcoin|WORLDCOIN|WLD|wld" services/explorer/static/
Length of output: 305
Script:
#!/bin/bash
# Check the actual content of these files to verify consistency
echo "Content of tokenSymbolToCoinGeckoID.yaml:"
cat services/explorer/static/tokenSymbolToCoinGeckoID.yaml | grep -i "wld\|worldcoin" -A 1 -B 1
echo -e "\nContent of tokenSymbolToTokenID.yaml:"
cat services/explorer/static/tokenSymbolToTokenID.yaml | grep -i "wld\|worldcoin" -A 1 -B 1
echo -e "\nContent of tokenIDToCoinGeckoID.yaml:"
cat services/explorer/static/tokenIDToCoinGeckoID.yaml | grep -i "wld\|worldcoin" -A 1 -B 1
Length of output: 662
services/explorer/static/tokenIDToCoinGeckoID.yaml (2)
43-43: LGTM! The mapping follows the established format.
The new entry maintains consistency with existing mappings and properly associates the WLD token ID with its CoinGecko identifier.
43-43: Verify CoinGecko ID validity
Let's ensure the CoinGecko ID 'worldcoin' is valid and matches the token's official listing.
✅ Verification successful
CoinGecko ID 'worldcoin' is valid and correctly mapped
The CoinGecko API successfully returned price data for the ID 'worldcoin', confirming it's a valid identifier. The mapping in the YAML file is correct and follows the established format.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the CoinGecko ID exists and is valid
# Expected: Response should include valid coin data if ID exists
curl -s "https://api.coingecko.com/api/v3/simple/price?ids=worldcoin&vs_currencies=usd" | jq .
Length of output: 143
services/explorer/static/tokenSymbolToCoinGeckoID.yaml (2)
43-43: LGTM! The addition follows the file's format conventions.
The new entry maintains consistent formatting with lowercase symbol and proper YAML syntax.
43-43: Verify CoinGecko ID and cross-file consistency
Let's ensure the new token mapping is accurate and consistent across configuration files.
✅ Verification successful
Token mapping for 'worldcoin' is consistent across configuration files
The verification confirms that the token mappings are properly aligned across all relevant configuration files:
tokenSymbolToCoinGeckoID.yaml:wld: 'worldcoin'tokenIDToCoinGeckoID.yaml:WLD: 'worldcoin'tokenSymbolToTokenID.yaml:wld: 'worldcoin'
The mappings follow the correct format with lowercase symbols and maintain consistency in the CoinGecko ID usage.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify token mapping consistency across files and validate CoinGecko ID
# Test 1: Check if the token ID mapping exists in tokenIDToCoinGeckoID.yaml
echo "Checking tokenIDToCoinGeckoID.yaml for WLD mapping..."
rg "WLD.*worldcoin" services/explorer/static/tokenIDToCoinGeckoID.yaml
# Test 2: Check if the symbol mapping exists in tokenSymbolToTokenID.yaml
echo "Checking tokenSymbolToTokenID.yaml for wld mapping..."
rg "wld.*worldcoin" services/explorer/static/tokenSymbolToTokenID.yaml
# Test 3: Check for any other occurrences of worldcoin to ensure consistency
echo "Checking for other worldcoin references..."
rg -i "worldcoin" --type yaml
Length of output: 746
packages/rfq-indexer/api/src/queries/depositsQueries.ts (1)
20-20: LGTM: Request field addition is consistent with schema changes
The addition of the 'request' field to the query aligns with the broader changes across the codebase for supporting bridge request events.
packages/rfq-indexer/api/src/routes/disputesRoute.ts (1)
15-15: Good improvement to the API response handling!
Returning an empty array instead of a 404 status for "no results" is a better RESTful practice for collection endpoints. This change:
- Makes the API more consistent and predictable
- Simplifies client-side handling
- Follows REST best practices where 404 should be reserved for invalid resources, not empty results
packages/rfq-indexer/api/src/routes/invalidRelaysRoute.ts (1)
15-15: LGTM! Documentation update follows REST best practices.
The clarification that a successful response may return an empty array is correct. This aligns with REST conventions where empty collections should return 200 OK with an empty array rather than 404 Not Found.
packages/rfq-indexer/api/src/routes/refundedAndRelayedRoute.ts (1)
15-15: Good improvement to REST practices!
Updating the response description to indicate an empty array possibility and removing the 404 response is a better REST practice. This change correctly indicates that the endpoint will return a 200 status with an empty array when no results are found, rather than treating it as a 404 error condition.
packages/rfq-indexer/api/src/routes/conflictingProofsRoute.ts (1)
15-15: Documentation update aligns with REST best practices.
The updated description correctly indicates that a 200 response may contain an empty array, which is the proper REST approach for representing zero results instead of using 404.
packages/rfq-indexer/api/src/graphql/types/events.graphql (1)
20-20: Verify the impact of this breaking change.
Adding a required field (request: String!) to the BridgeRequestEvent type is a breaking change that could affect existing clients. Existing queries that don't include this field will fail.
Let's verify the impact:
packages/rfq-indexer/api/src/routes/transactionIdRoute.ts (1)
11-12: Verify API behavior change regarding origin transaction hash support
The documentation no longer mentions support for origin transaction hash lookup. This suggests a breaking change that could impact existing API consumers.
Please confirm if the underlying implementation in getTransactionById controller still supports lookup by origin transaction hash. If not, this change should be explicitly documented as a breaking change.
packages/rfq-indexer/indexer/ponder.schema.ts (1)
8-8: Verify migration strategy for existing records.
Since this adds a non-optional field to an existing table, we need to ensure there's a migration strategy in place.
packages/rfq-indexer/api/src/constants/networkConfig.ts (2)
11-11: LGTM: Import addition is consistent
The worldchain import follows the established pattern of importing chains from 'viem/chains'.
118-128: Verify Worldchain configuration details
The configuration follows the established pattern, but there are a few points that need verification:
- Chain ID 480 for Worldchain
- FastBridgeV2 contract address reuse from Ethereum/Arbitrum networks
- Proper initialization of the HTTP transport without specific RPC URL
Let's verify these details:
✅ Verification successful
Worldchain configuration verified
Based on the comprehensive verification results:
- Chain ID 480 is consistently used for Worldchain across the codebase
- FastBridgeV2 contract address (0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E) is correctly reused, matching other networks like Ethereum and Arbitrum
- RPC configuration is properly set using Alchemy's public endpoint (worldchain-mainnet.g.alchemy.com/public)
The configuration follows the established pattern and is consistent with other supported chains in the system.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify Worldchain configuration consistency across the codebase
# Test 1: Check if chain ID 480 is consistently used for Worldchain
echo "Checking chain ID consistency..."
rg -l "480.*[\"']Worldchain[\"']|[\"']Worldchain[\"'].*480"
# Test 2: Verify FastBridgeV2 address usage
echo "Checking FastBridgeV2 address usage..."
rg "0x5523D3c98809DdDB82C686E152F5C58B1B0fB59E"
# Test 3: Look for RPC configuration
echo "Checking for RPC configuration..."
fd -t f "config" -x rg -l "worldchain.*rpc|rpc.*worldchain"
Length of output: 19903
Script:
#!/bin/bash
# Let's verify additional details about Worldchain configuration
# Check chainIDs.yaml content for Worldchain details
echo "Checking chainIDs.yaml content..."
cat services/explorer/static/chainIDs.yaml
# Check RPC configuration in config-template
echo "Checking RPC configuration in loadtest config..."
cat packages/rfq-loadtest/config-template.yaml
# Check for worldchain chain definition
echo "Checking for worldchain chain definition..."
rg -A 5 "worldchain.*=.*{" --ignore-case
# Check for any other Worldchain configurations
echo "Looking for other Worldchain configurations..."
rg "Worldchain" --ignore-case -C 2
Length of output: 43317
packages/rfq-indexer/api/src/types/index.ts (1)
13-13: ```shell
#!/bin/bash
Let's check the entire codebase for any SQL or migration-related files
fd -e sql -e ts . packages/rfq-indexer
Look for any files containing BridgeRequestEvents
rg -l "BridgeRequestEvents" packages/rfq-indexer
Check for any database schema or table definitions
rg -l "createTable|addColumn" packages/rfq-indexer
</details>
<details>
<summary>packages/rfq-indexer/api/src/routes/pendingTransactionsRoute.ts (1)</summary>
`20-20`: **LGTM! Consistent response handling across endpoints.**
The standardization to return empty arrays instead of 404 responses aligns with REST best practices for collection endpoints. This makes client-side handling more straightforward and reduces unnecessary HTTP roundtrips.
Also applies to: 69-69, 101-101, 131-131
</details>
<details>
<summary>packages/rfq-indexer/api/src/controllers/pendingTransactionsController.ts (2)</summary>
`4-4`: **LGTM! Import cleanup looks good.**
Removing the unused `qDisputes` import improves code cleanliness.
---
`17-17`: **Verify the impact of filtering for active proofs only.**
The addition of `{ activeOnly: true }` parameter to `qProofs` calls will filter out inactive proofs. Please ensure this aligns with the business requirements.
Let's check the implementation of `qProofs` and its usage:
Also applies to: 58-58
<details>
<summary>✅ Verification successful</summary>
The results show a clear pattern of `qProofs` usage across the codebase. Let me verify one more aspect to understand the business context better:
---
**The `activeOnly: true` filter is correctly applied based on the endpoint's purpose**
The codebase analysis reveals a consistent pattern in handling proofs:
- Pending transactions and conflicting proofs endpoints correctly filter for active proofs only
- Transaction by ID endpoint explicitly shows all proofs (active and disputed) for historical context
- GraphQL resolvers use the default behavior (activeOnly: false)
The implementation in `qProofs` shows this is a designed feature where `activeOnly` defaults to `false` and filters disputed proofs when set to `true`. This change aligns with the business logic where pending transactions should only consider active (non-disputed) proofs.
</details>
<details>
<summary>🏁 Scripts executed</summary>
The following scripts were executed for the analysis:
Script:
```shell
#!/bin/bash
# Check the implementation of qProofs and its usage
echo "Checking qProofs implementation:"
rg -A 10 "export const qProofs"
echo "\nChecking other usages of qProofs:"
rg "qProofs\(" --type ts
Length of output: 2456
Script:
#!/bin/bash
# Check the controller implementations to understand the context
echo "Checking pendingTransactionsController:"
rg -B 5 -A 5 "pendingTransactionsController" --type ts
echo "\nChecking transactionIdController:"
rg -B 5 -A 5 "transactionIdController" --type ts
echo "\nChecking conflictingProofsController:"
rg -B 5 -A 5 "conflictingProofsController" --type ts
Length of output: 4456
packages/rfq-indexer/indexer/src/index.ts (1)
19-19: Verify FastBridgeV2 contract compatibility with the new request parameter.
The addition of the request parameter suggests a contract upgrade. Please ensure that:
- The contract ABI has been updated
- All chains have the compatible contract version deployed
services/explorer/graphql/client/queries/queries.graphql (2)
158-158: LGTM! The worldchain field addition follows consistent patterns.
The new field follows the established naming conventions and is positioned logically within the response structure.
158-158: Verify the complete integration of worldchain support.
Let's verify that all necessary components for worldchain support are in place across the codebase.
✅ Verification successful
Worldchain integration appears to be properly implemented across the codebase
The verification shows that worldchain support is fully integrated with:
- Complete GraphQL resolver implementation in
server.go - Client-side support in
client.gowith proper type definitions - Parser implementation with coin ID mapping in
rfqparser.go - Test coverage in
server_test.go - Configuration presence in multiple config files
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the complete integration of worldchain support
# Expected results: Find corresponding changes in related files for full integration
# Check resolver implementations
echo "Checking resolver implementations..."
rg -l "worldchain" --type go
# Check SQL schema updates
echo "Checking SQL schema changes..."
fd -e sql -x rg -l "worldchain" {}
# Check configuration files
echo "Checking configuration files..."
fd -e yaml -e json -e toml -x rg -l "worldchain" {}
# Check test coverage
echo "Checking test coverage..."
fd -e test.go -e spec.ts -e test.ts -x rg -l "worldchain" {}
Length of output: 905
Script:
#!/bin/bash
# Let's examine the actual implementation details to verify integration completeness
# Check the GraphQL schema definition
echo "Checking GraphQL schema definitions..."
rg -p "type.*worldchain|input.*worldchain|enum.*worldchain" services/explorer/graphql/server/graph/
# Check resolver implementation details
echo "Checking resolver implementations..."
rg -p "worldchain" services/explorer/graphql/server/graph/resolver/server.go
# Check client implementation
echo "Checking client implementation..."
rg -p "worldchain" services/explorer/graphql/client/client.go
# Check parser implementation
echo "Checking parser implementation..."
rg -p "worldchain" services/explorer/consumer/parser/rfqparser.go
# Check test implementation
echo "Checking test coverage details..."
rg -p "worldchain" services/explorer/api/server_test.go
Length of output: 1637
packages/rfq-indexer/indexer/ponder.config.ts (3)
147-154: LGTM! Network details configuration follows the established pattern.
The network details configuration for worldchain follows the same structure as other chains, maintaining consistency.
73-78: ```shell
#!/bin/bash
Let's verify the contract deployment details from the deployment JSON
Check the deployment file content
echo "Checking FastBridge deployment details..."
cat packages/contracts-rfq/deployments/worldchain/FastBridge.json
Verify environment variable setup in other configuration files
echo "Checking for environment configurations..."
fd -e env -e env.example -e env.local -e env.development -e env.production | xargs cat
---
`16-16`: **Verify the worldchain chain ID.**
The chain ID 480 needs verification as it's a critical identifier for the blockchain network.
Let's verify this chain ID:
<details>
<summary>✅ Verification successful</summary>
**Chain ID 480 is correctly configured for World Chain**
The chain ID 480 for World Chain is consistently defined across multiple configuration files in the codebase:
- Defined in chain configuration files:
- `packages/widget/src/constants/chains.ts`
- `packages/synapse-interface/constants/chains/extraWagmiChains.ts`
- `packages/synapse-interface/constants/chains/master.ts`
- `packages/rest-api/src/constants/chains.ts`
- `packages/rfq-indexer/indexer/src/utils/chains.ts`
The chain ID is used consistently with the same RPC endpoints, explorer URLs, and network configurations across all these files, confirming its validity.
</details>
<details>
<summary>🏁 Scripts executed</summary>
The following scripts were executed for the analysis:
Script:
```shell
#!/bin/bash
# Description: Search for any chain ID references or documentation
# to verify the correct chain ID for worldchain
# Look for chain ID references in markdown files
echo "Searching for worldchain documentation..."
rg -i "worldchain.*480|480.*worldchain" -g "*.md"
# Look for chain ID references in configuration files
echo "Searching for chain ID in config files..."
rg -i "worldchain.*480|480.*worldchain" -g "*.{ts,js,json}"
Length of output: 749
Script:
#!/bin/bash
# Let's try a broader search for chain ID 480 and worldchain references
# Search for chain ID 480 in all files
echo "Searching for chain ID 480..."
rg "480" -C 2
# Search for worldchain references
echo "Searching for worldchain references..."
rg -i "worldchain" -C 2
# Check package.json or similar files for network configurations
echo "Checking configuration files..."
fd -e json -x cat {} \; | rg -i "worldchain|480"
Length of output: 24823
Script:
#!/bin/bash
# Let's search for chain ID references in blockchain configuration files and documentation
# Search for chain configuration files
echo "Searching for chain configuration files..."
fd -e ts -e js -x grep -l "chainId" {} \;
# Search for worldchain in configuration files with context
echo "Searching for worldchain configuration..."
rg -C 5 "worldchain" --type ts --type js
# Search for network documentation
echo "Searching for network documentation..."
fd -e md -x grep -l -i "worldchain\|chain.*480" {} \;
Length of output: 30222
services/explorer/consumer/parser/rfqparser.go (1)
Line range hint 127-133: Review the broad USDC assumption.
The else branch assumes any unrecognized token address is USDC, which could lead to incorrect token identification. Consider implementing proper token resolution or logging a warning when encountering unknown tokens.
Let's verify if there are other token types in use:
services/explorer/consumer/parser/tokendata/cache.go (1)
290-294: Verify token addresses and decimals for Worldchain.
The addition of new tokens for Worldchain (chain ID 480) should be verified:
- WLD token:
0x2cFc85d8E48F8EAB294be644d9E25C3030863003 - USDC.e token:
0x79A02482A880bCE3F13e09Da970dC34db4CD24d1 - WETH token:
0x4200000000000000000000000000000000000006
services/explorer/graphql/server/graph/model/models_gen.go (1)
84-108:
While the addition of the Worldchain field is consistent with other chain fields in the DateResultByChain struct, this file is auto-generated by gqlgen. Any changes should be made in the corresponding GraphQL schema file instead.
Let's verify the schema changes:
✅ Verification successful
Let me gather more context about the schema file and its location:
✅ Changes are properly reflected in the schema
The worldchain field has been correctly added to the GraphQL schema in services/explorer/graphql/server/graph/schema/types.graphql, and the generated code accurately reflects this change. The modification follows the established pattern for chain fields in the schema.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find and check the GraphQL schema file for Worldchain field
rg -l "type DateResultByChain" | grep "\.graphql$" | xargs rg "worldchain"
Length of output: 94
Script:
#!/bin/bash
# Find the GraphQL schema file containing DateResultByChain
rg -l "type DateResultByChain" | grep "\.graphql$"
# Show the complete DateResultByChain type definition
rg -A 30 "type DateResultByChain" | grep "\.graphql$" | xargs rg -A 30 "type DateResultByChain"
Length of output: 16477
services/explorer/graphql/client/client.go (2)
109-133: LGTM! The struct fields follow a consistent pattern.
The new Worldchain field is properly added to the GetDailyStatisticsByChain response struct, maintaining consistency with existing fields in terms of:
- Type (
*float64) - Tag format (
json:"worldchain" graphql:"worldchain") - Positioning (before the
Totalfield)
506-506: LGTM! The GraphQL query field is properly added.
The worldchain field is correctly added to the GetDailyStatisticsByChainDocument query, maintaining consistency with the struct definition.
✅ Verification successful
Let me gather more information to verify the GraphQL schema and its usage.
Based on the search results, I can see that the worldchain field is properly integrated into the GraphQL schema and codebase:
- It's defined in the
DateResultByChaintype in the GraphQL schema - It's included in the
GetDailyStatisticsByChainquery response structure - The field is used consistently across the codebase in the client implementation and server handlers
The GraphQL query field is correctly added and properly integrated with the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the worldchain field is properly used in the schema and resolvers
# Test: Search for worldchain field definition in schema
rg -p "worldchain.*Float" --type graphql
# Test: Search for worldchain field in resolvers
ast-grep --pattern 'worldchain'
Length of output: 586
Script:
#!/bin/bash
# Search for GraphQL schema files and their content
fd -e graphql -e gql | xargs cat
# Search for any GraphQL type definitions or queries containing worldchain
rg -p "type.*{[^}]*worldchain|query.*{[^}]*worldchain" -g "*.{graphql,gql}"
# Look for the specific query definition
rg -p "GetDailyStatisticsByChain" -A 10 -B 10
Length of output: 62284
services/explorer/graphql/server/graph/partials.go (1)
404-404: LGTM! Consistent integration of Worldchain support.
The addition of Worldchain (chain ID 480) follows the established pattern and maintains consistency across all query templates.
Also applies to: 449-449, 546-546, 649-649, 681-681, 714-714
services/explorer/graphql/server/graph/resolver/server.go (5)
103-127: LGTM: Consistent struct field addition
The Worldchain field is correctly added to the DateResultByChain struct, following the established pattern for blockchain complexity calculations.
664-670: LGTM: Proper complexity calculation implementation
The complexity calculation for Worldchain follows the established pattern with appropriate nil checks.
1675-1675: LGTM: Schema type properly defined
The Worldchain field is correctly typed as Float, maintaining consistency with other blockchain fields in the schema.
7243-7244: LGTM: Proper field context routing
The Worldchain field is correctly integrated into both routing mechanisms, maintaining consistency with the existing implementation pattern.
Also applies to: 10489-10490
103-127: Verify complete Worldchain integration
While the GraphQL resolver implementation is correct, let's verify the complete integration chain.
Also applies to: 664-670, 1675-1675, 4844-4883, 7243-7244, 10489-10490
✅ Verification successful
Worldchain integration is properly implemented across the codebase
The verification shows complete integration of Worldchain across all necessary components:
- GraphQL schema and resolvers properly define and handle Worldchain data
- Chain configuration is consistent across packages (ID: 480)
- RPC endpoints and contract addresses are properly configured
- UI components include Worldchain in charts and displays
- Database queries include Worldchain in aggregations
- Token configurations and bridging support are in place
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify complete Worldchain integration across the codebase
# Check for corresponding model definitions
echo "Checking model definitions..."
rg -l "type DateResultByChain struct" .
# Check for Worldchain references in tests
echo "Checking test coverage..."
rg -l "worldchain" . --type test
# Check for related database schema changes
echo "Checking database schema..."
rg -l "worldchain" . --type sql
Length of output: 450
Script:
#!/bin/bash
# Let's do a more comprehensive check for Worldchain integration
# Check for Worldchain references across the codebase
echo "Checking Worldchain references..."
rg -i "worldchain" -A 3 -B 3
# Check for test files specifically containing Worldchain
echo "Checking test files..."
fd -e test.go -x rg -l "worldchain" {}
# Check GraphQL schema definitions
echo "Checking GraphQL schema..."
fd -e graphql -e gql -x rg -l "worldchain" {}
# Check for any configuration or initialization code
echo "Checking configuration files..."
rg -i "worldchain" -g "*.{yaml,yml,json,toml}"
Length of output: 51751
| const ADDRESSES_WITH_18_DECIMALS = [ | ||
| '0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE', // ETH | ||
| '0x2cFc85d8E48F8EAB294be644d9E25C3030863003', // WLD | ||
| '0x163f8c2467924be0ae7b5347228cabf260318753', // WLD | ||
| '0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1', // WLD | ||
| ].map(address => address.toLowerCase()) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider improving maintainability of token address configuration.
The hardcoded array of addresses could be better structured for maintainability:
- Consider moving these addresses to a configuration file
- Add comments explaining which network/chain each WLD address belongs to
- Document the source or reference for these addresses
Consider restructuring like this:
interface TokenConfig {
address: string;
symbol: string;
network: string;
decimals: number;
}
const TOKEN_CONFIGS: TokenConfig[] = [
{
address: '0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE',
symbol: 'ETH',
network: 'ethereum',
decimals: 18
},
{
address: '0x2cFc85d8E48F8EAB294be644d9E25C3030863003',
symbol: 'WLD',
network: 'worldchain',
decimals: 18
},
// ... other configs
];
const ADDRESSES_WITH_18_DECIMALS = TOKEN_CONFIGS
.filter(config => config.decimals === 18)
.map(config => config.address.toLowerCase());| export function formatAmount(amount: bigint, tokenAddress: string): string { | ||
| const decimals = tokenAddress.toLowerCase() === ETH_ADDRESS.toLowerCase() ? 18 : 6 | ||
| const decimals = ADDRESSES_WITH_18_DECIMALS.includes(tokenAddress.toLowerCase()) ? 18 : 6 | ||
| return formatUnits(amount, decimals) | ||
| } | ||
| } |
There was a problem hiding this comment.
💡 Codebase verification
The binary decimal choice (6 or 18) is insufficient - tokens with 8 decimals exist
The current implementation in formatAmount doesn't handle tokens with 8 decimals, which are present in the codebase's bridge mappings. This could lead to incorrect amount formatting for these tokens.
Consider this improved implementation:
export function formatAmount(amount: bigint, tokenAddress: string): string {
if (!tokenAddress) {
throw new Error('Token address is required');
}
try {
- const decimals = ADDRESSES_WITH_18_DECIMALS.includes(tokenAddress.toLowerCase()) ? 18 : 6
+ let decimals = 6;
+ if (ADDRESSES_WITH_18_DECIMALS.includes(tokenAddress.toLowerCase())) {
+ decimals = 18;
+ } else if (ADDRESSES_WITH_8_DECIMALS.includes(tokenAddress.toLowerCase())) {
+ decimals = 8;
+ }
return formatUnits(amount, decimals)
} catch (error) {
throw new Error(`Failed to format amount: ${error.message}`);
}
}🔗 Analysis chain
Enhance error handling and token decimal flexibility.
The current implementation has several potential issues:
- The binary choice between 6 or 18 decimals might not cover all tokens
- Missing input validation for tokenAddress
- No error handling for potential formatUnits failures
Consider applying these improvements:
export function formatAmount(amount: bigint, tokenAddress: string): string {
+ if (!tokenAddress) {
+ throw new Error('Token address is required');
+ }
+
+ try {
const decimals = ADDRESSES_WITH_18_DECIMALS.includes(tokenAddress.toLowerCase()) ? 18 : 6
return formatUnits(amount, decimals)
+ } catch (error) {
+ throw new Error(`Failed to format amount: ${error.message}`);
+ }
}Let's verify if there are any tokens with decimals other than 6 or 18:
Based on the search results, I can see that there are tokens with decimals other than 6 and 18 in the codebase. Specifically, there are tokens with 8 decimals mentioned in the bridgeMap configurations. Let me verify this with a more focused search:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for token decimal declarations in the codebase
rg -i "decimals.*[^6|18]" --type ts
Length of output: 125202
Script:
#!/bin/bash
# Search specifically for decimal values other than 6 and 18
rg "decimals:\s*(8)" --type ts
Length of output: 1640
| @@ -42,3 +42,4 @@ usdbc: 'usd-coin' | |||
| crvusd: 'usd-coin' | |||
| usdb: 'usdb' | |||
| spec: 'spectral' | |||
| wld: 'worldcoin' | |||
There was a problem hiding this comment.
Maintain consistent token ID format.
The token ID 'worldcoin' should follow the established CamelCase/uppercase pattern used throughout the file. Consider using 'WORLDCOIN' or 'WorldCoin' for consistency.
-wld: 'worldcoin'
+wld: 'WORLDCOIN'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| wld: 'worldcoin' | |
| wld: 'WORLDCOIN' |
| * parameters: | ||
| * - in: path | ||
| * name: transactionId | ||
| * required: true | ||
| * schema: | ||
| * type: string | ||
| * description: The unique identifier of the transaction or the origin transaction hash | ||
| * description: The ID of the transaction to retrieve |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider adding format validation for transactionId parameter
The parameter accepts any string value. Consider adding format validation to ensure valid transaction ID patterns.
Add format validation to the schema:
* schema:
* type: string
+* pattern: ^0x[a-fA-F0-9]{64}$
+* example: "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| * description: The ID of the transaction to retrieve | |
| * description: The ID of the transaction to retrieve | |
| * schema: | |
| * type: string | |
| * pattern: ^0x[a-fA-F0-9]{64}$ | |
| * example: "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef" |
| @@ -33,6 +34,7 @@ ponder.on('FastBridgeV2:BridgeRequested', async ({ event, context }) => { | |||
| data: { | |||
| transactionId, | |||
| sender: trim(sender), | |||
| request: request, | |||
There was a problem hiding this comment.
Consider data sanitization for the request field.
Unlike other fields such as sender which use trim(), the request field is stored without any sanitization. Consider:
- Adding appropriate sanitization if this is an address
- Adding type validation for data consistency
If this is an address field, apply this fix:
- request: request,
+ request: trim(request),Committable suggestion was skipped due to low confidence.
| <Bar | ||
| isAnimationActive={false} | ||
| dataKey="worldchain" | ||
| stackId="a" | ||
| fill={loading ? 'rgba(255, 255, 255, 0.1)' : '#FFFFFF'} | ||
| /> |
There was a problem hiding this comment.
💡 Codebase verification
Consider using a more distinctive color for better visibility
The white fill color (#FFFFFF) for the worldchain bar should be changed since:
- The chart appears to be using a dark theme (evidenced by white YAxis stroke color
stroke="#ffffff") - Other chains use distinctive colors that contrast well with the background (e.g., Linea uses black
#000000, Scroll uses#FFEEDA, etc.) - The loading state already uses a semi-transparent white
rgba(255, 255, 255, 0.1)
Consider using a unique, contrasting color like other chains in the chart to ensure the worldchain data is clearly visible against the dark background.
🔗 Analysis chain
Consider adjusting the fill color for better visibility.
The white fill color (#FFFFFF) might have visibility issues on light backgrounds. Consider using a more distinctive color that maintains good contrast across different themes.
Let's verify the worldchain data integration:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if worldchain data is properly integrated in the chart data structure
rg -A 5 "worldchain.*interface|type.*worldchain" --type typescript
Length of output: 103
Script:
#!/bin/bash
# Let's try different approaches to verify the worldchain integration
# Check for worldchain-related code patterns
rg -i "worldchain" -A 5 -B 5
# Look for data transformation or preparation related to worldchain
ast-grep --pattern 'const $_ = $$$worldchain$$$'
# Check the component's props and interfaces
ast-grep --pattern 'interface $_ {
$$$
worldchain
$$$
}'
# Look for worldchain in data mapping or processing
ast-grep --pattern '$_.worldchain'
Length of output: 74044
Script:
#!/bin/bash
# Let's check the theme/styling context around the chart component
rg -B 10 -A 10 "ChainChart.*theme|theme.*ChainChart" --type typescript
# Look for other bar colors in the chart for comparison
ast-grep --pattern 'fill={$_}'
# Check if there's any dark theme or background color definition
rg -i "background.*dark|dark.*background|theme.*dark|dark.*theme"
Length of output: 5157
Script:
#!/bin/bash
# Let's check the specific file content around the Bar components
rg -B 15 -A 15 "dataKey=\"worldchain\"" packages/explorer-ui/components/ChainChart/index.tsx
# Look for any theme or background color definitions in the ChainChart component
cat packages/explorer-ui/components/ChainChart/index.tsx
Length of output: 10816
| } else if strings.EqualFold(tokenAddressStr, "0x2cFc85d8E48F8EAB294be644d9E25C3030863003") || strings.EqualFold(tokenAddressStr, "0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1") { | ||
| rfqEvent.TokenSymbol = "WLD" | ||
| rfqEvent.TokenDecimal = new(uint8) | ||
| *rfqEvent.TokenDecimal = 18 | ||
| curCoinGeckoID = "worldchain" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider externalizing token configurations.
The hardcoded WLD token addresses and their configurations should be moved to a configuration file or constants package for better maintainability. Additionally, please add comments explaining the significance of these specific addresses.
Consider refactoring to use a token configuration map:
// Define in a separate config package
type TokenConfig struct {
Symbol string
Decimals uint8
GeckoID string
}
var TokenConfigs = map[string]TokenConfig{
"0x2cFc85d8E48F8EAB294be644d9E25C3030863003": {
Symbol: "WLD",
Decimals: 18,
GeckoID: "worldchain",
},
"0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1": {
Symbol: "WLD",
Decimals: 18,
GeckoID: "worldchain",
},
}| expectedAmount = big.NewInt(500_000_000) | ||
| s.Equal(expectedAmount, quoteAmount) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using named constants for magic numbers
Replace magic numbers with named constants to improve code readability and maintainability. For example:
+ const (
+ defaultBalance = 1000_000_000 // 1000 USDC
+ halfBalance = 500_000_000 // 500 USDC
+ reducedBalance = 495_000_000 // 495 USDC
+ )
- expectedAmount = big.NewInt(500_000_000)
+ expectedAmount = big.NewInt(halfBalance)
- expectedAmount = big.NewInt(495_000_000)
+ expectedAmount = big.NewInt(reducedBalance)Also applies to: 271-272
| 'BridgeRequestEvents.request', | ||
| 'BridgeRequestEvents.sendChainGas', |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider adding null handling for the request field.
The new field might be null in existing records. Consider adding explicit null handling in the nest_results function or documenting if null values are acceptable.
- 'BridgeRequestEvents.request',
+ sql`COALESCE(BridgeRequestEvents.request, '{}') as request`.as('request'),📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 'BridgeRequestEvents.request', | |
| 'BridgeRequestEvents.sendChainGas', | |
| sql`COALESCE(BridgeRequestEvents.request, '{}') as request`.as('request'), | |
| 'BridgeRequestEvents.sendChainGas', |
| @@ -20,6 +20,7 @@ | |||
| 'BridgeRequestEvents.originAmountFormatted', | |||
| 'BridgeRequestEvents.destAmountFormatted', | |||
| 'BridgeRequestEvents.sender', | |||
| 'BridgeRequestEvents.request', | |||
There was a problem hiding this comment.
💡 Codebase verification
Schema compatibility verified, but GraphQL type needs update
The database schema in ponder.schema.ts shows that the request field exists in the BridgeRequestEvents table as a string type, but it's missing from the GraphQL type definition. This needs to be addressed to maintain schema compatibility.
- Add the
request: String!field to theBridgeRequestEventtype inpackages/rfq-indexer/api/src/graphql/types/events.graphql
🔗 Analysis chain
Verify GraphQL schema compatibility.
The new field BridgeRequestEvents.request has been added to the SQL query. While the AI summary confirms the schema update, please ensure that:
- The GraphQL schema type
BridgeRequestEventincludes this field - The field type matches between the database and GraphQL schema
Let me gather more information about the schema definition to see if the request field is defined further down.
Let me try another command to get the complete schema definition:
Let me check the database schema definition to understand the field structure:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify GraphQL schema compatibility
# Test: Check if the field is properly defined in the GraphQL schema
rg -A 5 "type BridgeRequestEvent" packages/rfq-indexer/api/src/graphql/types/
Length of output: 578
Script:
#!/bin/bash
# Description: Check complete BridgeRequestEvent type definition
rg -A 15 "type BridgeRequestEvent" packages/rfq-indexer/api/src/graphql/types/events.graphql
Length of output: 1637
Script:
#!/bin/bash
# Description: Get the complete content of the events.graphql file
cat packages/rfq-indexer/api/src/graphql/types/events.graphql
Length of output: 2827
Script:
#!/bin/bash
# Description: Check the database schema definition for BridgeRequestEvents
cat packages/rfq-indexer/indexer/ponder.schema.ts
Length of output: 2531
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
- packages/rfq-indexer/indexer/abis/FastBridgeV2.ts (1 hunks)
- packages/rfq-indexer/indexer/src/index.ts (2 hunks)
- packages/rfq-indexer/indexer/src/utils/formatAmount.ts (1 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/rfq-indexer/indexer/abis/FastBridgeV2.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/rfq-indexer/indexer/src/index.ts
| export const formatAmount = (amount: bigint, tokenAddress: string): string => { | ||
| const decimals = ADDRESSES_WITH_18_DECIMALS.includes( | ||
| tokenAddress.toLowerCase() | ||
| ) | ||
| ? 18 | ||
| : 6 | ||
| return formatUnits(amount, decimals) | ||
| } No newline at end of file | ||
| } |
There was a problem hiding this comment.
Add input validation to prevent undefined behavior.
The function should validate its inputs to prevent potential issues with undefined, null, or invalid addresses.
Apply this diff:
export const formatAmount = (amount: bigint, tokenAddress: string): string => {
+ if (!amount || typeof amount !== 'bigint') {
+ throw new Error('Amount must be a valid bigint');
+ }
+ if (!tokenAddress || typeof tokenAddress !== 'string' || !tokenAddress.startsWith('0x')) {
+ throw new Error('Token address must be a valid hex string starting with 0x');
+ }
const decimals = ADDRESSES_WITH_18_DECIMALS.includes(
tokenAddress.toLowerCase()
)
? 18
: 6
return formatUnits(amount, decimals)
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export const formatAmount = (amount: bigint, tokenAddress: string): string => { | |
| const decimals = ADDRESSES_WITH_18_DECIMALS.includes( | |
| tokenAddress.toLowerCase() | |
| ) | |
| ? 18 | |
| : 6 | |
| return formatUnits(amount, decimals) | |
| } | |
| \ No newline at end of file | |
| } | |
| export const formatAmount = (amount: bigint, tokenAddress: string): string => { | |
| if (!amount || typeof amount !== 'bigint') { | |
| throw new Error('Amount must be a valid bigint'); | |
| } | |
| if (!tokenAddress || typeof tokenAddress !== 'string' || !tokenAddress.startsWith('0x')) { | |
| throw new Error('Token address must be a valid hex string starting with 0x'); | |
| } | |
| const decimals = ADDRESSES_WITH_18_DECIMALS.includes( | |
| tokenAddress.toLowerCase() | |
| ) | |
| ? 18 | |
| : 6 | |
| return formatUnits(amount, decimals) | |
| } |
| const ADDRESSES_WITH_18_DECIMALS = [ | ||
| '0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE', // ETH | ||
| '0x2cFc85d8E48F8EAB294be644d9E25C3030863003', // WLD | ||
| '0x163f8c2467924be0ae7b5347228cabf260318753', // WLD | ||
| '0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1', // WLD | ||
| ].map((address) => address.toLowerCase()) |
There was a problem hiding this comment.
Document the purpose of multiple WLD addresses and add address validation.
While the addresses are properly normalized using toLowerCase(), there are two areas for improvement:
- Add comments explaining the purpose of each WLD address (e.g., which network/chain they belong to)
- Add validation to ensure addresses are valid hexadecimal strings
Consider this implementation:
const ADDRESSES_WITH_18_DECIMALS = [
'0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE', // ETH
- '0x2cFc85d8E48F8EAB294be644d9E25C3030863003', // WLD
- '0x163f8c2467924be0ae7b5347228cabf260318753', // WLD
- '0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1', // WLD
+ '0x2cFc85d8E48F8EAB294be644d9E25C3030863003', // WLD on Ethereum mainnet
+ '0x163f8c2467924be0ae7b5347228cabf260318753', // WLD on Worldchain
+ '0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1', // WLD on testnet
].map((address) => {
+ if (!/^0x[a-fA-F0-9]{40}$/.test(address)) {
+ throw new Error(`Invalid address format: ${address}`);
+ }
return address.toLowerCase();
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const ADDRESSES_WITH_18_DECIMALS = [ | |
| '0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE', // ETH | |
| '0x2cFc85d8E48F8EAB294be644d9E25C3030863003', // WLD | |
| '0x163f8c2467924be0ae7b5347228cabf260318753', // WLD | |
| '0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1', // WLD | |
| ].map((address) => address.toLowerCase()) | |
| const ADDRESSES_WITH_18_DECIMALS = [ | |
| '0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE', // ETH | |
| '0x2cFc85d8E48F8EAB294be644d9E25C3030863003', // WLD on Ethereum mainnet | |
| '0x163f8c2467924be0ae7b5347228cabf260318753', // WLD on Worldchain | |
| '0xdC6fF44d5d932Cbd77B52E5612Ba0529DC6226F1', // WLD on testnet | |
| ].map((address) => { | |
| if (!/^0x[a-fA-F0-9]{40}$/.test(address)) { | |
| throw new Error(`Invalid address format: ${address}`); | |
| } | |
| return address.toLowerCase(); | |
| }); |
Description
A clear and concise description of the features you're adding in this pull request.
Additional context
Add any other context about the problem you're solving.
Metadata
103f6db: explorer-ui preview link
Summary by CodeRabbit
New Features
BarChartcomponent to display data for the "Worldchain" alongside existing blockchains.BridgeRequestEventsto capture additional data in the GraphQL schema.Documentation
Bug Fixes
231d67f: explorer-ui preview link
0bcc744: explorer-ui preview link