composer added to whitelist.json

[0xDEnYO]

Which Jira task belongs to this PR?

Why did I implement it this way?

Checklist before requesting a review

• I have performed a self-review of my code
• This pull request is as small as possible and only tackles one problem
• I have added tests that cover the functionality / test the bug
• For new facets: I have checked all points from this list: https://www.notion.so/lifi/New-Facet-Contract-Checklist-157f0ff14ac78095a2b8f999d655622e
• I have updated any required documentation

Checklist for reviewer (DO NOT DEPLOY and contracts BEFORE CHECKING THIS!!!)

• I have checked that any arbitrary calls to external contracts are validated and or restricted
• I have checked that any privileged calls (i.e. storage modifications) are validated and or restricted
• I have ensured that any new contracts have had AT A MINIMUM 1 preliminary audit conducted on by <company/auditor>

[coderabbitai]

Walkthrough

Adds a new public entity named "Composer" with address 0x9706b69De23Fe0B471Addd642175126B3A8BF071 and selector 0x00a32e6c to multiple sections of config/whitelist.json across various DEX and periphery groupings, with no modifications to existing entries.

Changes

Cohort / File(s)	Summary
Whitelist Configuration Updates config/whitelist.json	Added public entity "Composer" (address: 0x9706b69De23Fe0B471Addd642175126B3A8BF071, selector: 0x00a32e6c) to multiple sections including PERIPHERY and chain-specific groupings (e.g., arbitrum, aurora, base, apechain); entries have empty signature fields; no removals or modifications to existing entries

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify the Composer address (0x9706b69De23Fe0B471Addd642175126B3A8BF071) is correct and intended for all sections
• Confirm consistency of selector (0x00a32e6c) and empty signature fields across all additions
• Check that no unintended modifications were made to adjacent entries in the JSON structure

Possibly related PRs

• New whitelist format #1405: Introduces new whitelist/periphery format and tooling for config/whitelist.json modifications

Suggested labels

DO NOT MERGE

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description uses the template structure but all critical fields are empty or unchecked: Jira task, implementation rationale, and all contributor/reviewer checklist items are incomplete.	Fill in the Jira task reference, explain the implementation rationale, verify all checklist items (especially audit confirmation for the new contract), and update audit date/company details before review.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: adding Composer to the whitelist.json configuration file.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch restore-composer-whitelisting

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 7471aa0 and 5f11c3c.

📒 Files selected for processing (1)

• config/whitelist.json (21 hunks)

🧰 Additional context used

🧠 Learnings (3)

📓 Common learnings

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1334
File: deployments/mainnet.json:54-54
Timestamp: 2025-08-26T02:20:52.515Z
Learning: For deployment PRs in the lifinance/contracts repository, carefully verify the specific scope mentioned in the PR title and description before suggesting updates to other networks. Not all deployments are cross-network updates - some are targeted to specific chains only.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1256
File: deployments/zksync.diamond.json:81-87
Timestamp: 2025-07-04T08:59:08.108Z
Learning: When analyzing deployment PRs in the lifinance/contracts repository, carefully verify that target state configuration files (like script/deploy/_targetState.json) have been updated before flagging missing entries. The AI summary section should be consulted to understand all file changes, as manual searches might miss entries due to formatting differences or search limitations.

Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: config/dexs.json:748-752
Timestamp: 2024-11-21T08:39:29.530Z
Learning: In the 'worldchain' network, the addresses `0x50D5a8aCFAe13Dceb217E9a071F6c6Bd5bDB4155`, `0x8f023b4193a6b18C227B4a755f8e28B3D30Ef9a1`, and `0x603a538477d44064eA5A5d8C345b4Ff6fca1142a` are used as DEXs and should be included in `config/dexs.json`.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1196
File: script/helperFunctions.sh:1447-1462
Timestamp: 2025-06-19T06:23:47.848Z
Learning: 0xDEnYO prefers to keep eval usage in local bash scripts when the security risk is acceptable in their controlled environment, prioritizing simplicity over security hardening for local tooling.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1266
File: script/deploy/safe/execute-pending-timelock-tx.ts:627-628
Timestamp: 2025-07-17T04:21:26.825Z
Learning: In the lifinance/contracts repository, 0xDEnYO prefers to keep '0x0' as a fallback address in gas estimation calls rather than throwing errors when the wallet account address is not available, prioritizing code simplicity over strict validation.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1325
File: script/tasks/diamondSyncDEXs.sh:116-116
Timestamp: 2025-08-27T08:45:59.606Z
Learning: In script/tasks/diamondSyncDEXs.sh, user 0xDEnYO has chosen to selectively apply ShellCheck fixes, keeping array assignments using $() construct and other patterns as-is in their controlled deployment environment, prioritizing functionality over strict ShellCheck compliance.

Learnt from: 0xDEnYO
Repo: lifinance/contracts PR: 1212
File: .github/workflows/convertForkedPRsToInternal.yml:81-106
Timestamp: 2025-07-16T06:18:02.682Z
Learning: 0xDEnYO prefers to use printf "%q" for shell escaping in GitHub workflows to increase security and protection from potential injections, even when it might cause formatting issues, prioritizing security over convenience.

📚 Learning: 2024-11-21T08:39:29.530Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 861
File: config/dexs.json:748-752
Timestamp: 2024-11-21T08:39:29.530Z
Learning: In the 'worldchain' network, the addresses `0x50D5a8aCFAe13Dceb217E9a071F6c6Bd5bDB4155`, `0x8f023b4193a6b18C227B4a755f8e28B3D30Ef9a1`, and `0x603a538477d44064eA5A5d8C345b4Ff6fca1142a` are used as DEXs and should be included in `config/dexs.json`.

Applied to files:

• config/whitelist.json

📚 Learning: 2025-11-14T12:58:18.040Z

Learnt from: ezynda3
Repo: lifinance/contracts PR: 1463
File: config/whitelist.json:24-26
Timestamp: 2025-11-14T12:58:18.040Z
Learning: In lifinance/contracts reviews, selectors must be verified by code or concrete on-chain evidence (ABI/tx) rather than assumed; provide a reproducible script or reference when proposing selector mappings.

Applied to files:

• config/whitelist.json

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: run-unit-tests

🔇 Additional comments (2)

config/whitelist.json (2)

4353-4360: Verify Composer deployment scope and chain addresses manually.

Verification confirms the config/whitelist.json data is internally consistent:

• 21 chains have Composer contracts with distinct or reused addresses
• 7 chains use non-standard addresses (berachain, hyperevm, ink, katana, plume, soneium, unichain)
• 41 chains lack Composer entries

However, confirming intentionality and correctness requires:

• Reviewing the PR description/scope to understand which chains should have Composer
• Validating deployment transactions and ABIs for each unique address
• Confirming that omitted chains align with intended deployment targets

The codebase consistency check passes, but deployment correctness cannot be verified without deployment evidence (transaction hashes, block explorers, or PR documentation).

---

4353-4360: Verify Composer deployment and populate function signatures for selector 0x00a32e6c.

The selector is consistently applied across all 21 chains and 6 distinct Composer addresses, but empty "signature" fields and lack of on-chain verification remain unaddressed. Confirm each Composer address is a live deployment and provide the canonical function signature for 0x00a32e6c (not found in public signature databases). Per the codebase learnings, selectors require code or on-chain evidence—provide ABI/bytecode verification or a reference to the Composer contract implementation.

Warning

Review ran into problems

🔥 Problems

Errors were encountered while retrieving linked issues.

Errors (1)

• JIRA integration encountered authorization issues. Please disconnect and reconnect the integration in the CodeRabbit UI.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}