Files

Deploy to Phoenix / deploy (push) Has been cancelled

Details

docs: Ledger Live integration, contract deploy learnings, NEXT_STEPS updates

- ADD_CHAIN138_TO_LEDGER_LIVE: Ledger form done; public code review repo bis-innovations/LedgerLive; init/push commands
- CONTRACT_DEPLOYMENT_RUNBOOK: Chain 138 gas price 1 gwei, 36-addr check, TransactionMirror workaround
- CONTRACT_*: AddressMapper, MirrorManager deployed 2026-02-12; 36-address on-chain check
- NEXT_STEPS_FOR_YOU: Ledger done; steps completable now (no LAN); run-completable-tasks-from-anywhere
- MASTER_INDEX, OPERATOR_OPTIONAL, SMART_CONTRACTS_INVENTORY_SIMPLE: updates
- LEDGER_BLOCKCHAIN_INTEGRATION_COMPLETE: bis-innovations/LedgerLive reference

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-02-12 15:46:57 -08:00

3.3 KiB

Raw Permalink Blame History

Critical Task Investigation Results

Last Updated: 2026-01-31
Document Version: 1.0
Status: Active Documentation

Date: 2026-01-18
Tasks: T1.1 (CCIP Selector), T1.2 (Bridge Configuration Block)

🔍 T1.1: ChainID 138 CCIP Selector Investigation

Findings

Conflicting Values Found:

networks.json: 5009297550715157269 (same as Mainnet selector)
Relay Service Config: BigInt('138') - using chain ID directly

Location of Conflicting Values:

networks.json: Line 13 - "chainSelector": "5009297550715157269"
services/relay/src/config.js: Line 34 - sourceChainSelector: BigInt('138')

Analysis:

Relay service uses chain ID (138) - This suggests a custom CCIP implementation
networks.json uses Mainnet selector - This appears to be a placeholder or incorrect value
For custom CCIP, selector is typically the chain ID (138)
For official Chainlink CCIP, selector must be obtained from CCIP Directory

Recommendation: Use 138 as the ChainID 138 selector (matches relay service implementation)

🔍 T1.2: ChainID 138 Bridge Configuration Block Investigation

Test Results

✅ Working Functions:

admin(): Returns 0x4A666F96fC8764181194447A7dFdb7d471b301C8 ✅

❌ Reverting Functions:

getDestinationChains()(uint64[]): REVERTS
destinations(uint64)(uint64,address,bool): REVERTS

Analysis

Issue: ChainID 138 bridges have different interface than Mainnet bridges

Possible Causes:

Different contract version - ChainID 138 bridges may be older/different implementation
Proxy pattern - Functions may exist in implementation but not exposed via proxy
Missing functions - getDestinationChains() and destinations() may not exist
Different ABI - Contract interface may be different

Observations:

admin() works - Basic admin function exists
Bridge code exists (confirmed via cast code)
Configuration functions revert - Suggests interface mismatch

Next Steps for T1.2

Check contract source code - Compare ChainID 138 bridge source with Mainnet
Query contract ABI - Get actual function signatures
Check event logs - See if destinations were configured via events
Verify proxy implementation - Check if proxy forwards calls correctly
Check if different function names - May use different naming

📊 Summary

T1.1: CCIP Selector

Status: ⚠️ CONFLICT DETECTED

Resolution:

Use 138 as ChainID 138 selector (matches relay service)
Update .env with CHAIN138_SELECTOR=138
Update networks.json if needed
Document that this is a custom CCIP implementation

T1.2: Bridge Configuration

Status: ⚠️ INTERFACE MISMATCH

Issue: ChainID 138 bridges have different interface - configuration functions revert

Resolution Needed:

Determine correct interface for ChainID 138 bridges
Find alternative method to configure destinations
Or update bridges to match Mainnet interface

🚨 Critical Blocking Issues

Selector Mismatch: networks.json vs relay service (use 138)
Interface Mismatch: ChainID 138 bridges different from Mainnet

Impact:

Selector conflict prevents correct bridge configuration
Interface mismatch prevents configuration calls

Last Updated: 2026-01-18

3.3 KiB Raw Permalink Blame History