Description

Maps the ETH symbol to #5E6DB7 in both the series card (PredictCryptoUpDownMarketCard) and the details screen (PredictCryptoUpDownDetails) so Ethereum up/down markets render with a distinct accent — chart line, sparkline, badge, and current-price text — instead of falling back to the default amber.

Symbol resolution was already in place via getCryptoSymbol() (ethereum tag + eth- slug prefix), so only the two color lookup tables (CRYPTO_SYMBOL_TO_ACCENT_COLOR on the details screen, CRYPTO_ACCENT_BY_SYMBOL on the card) needed extending. BTC keeps its orange accent and any unmapped symbol continues to fall back to the default amber.

Changelog

CHANGELOG entry: null

Related issues

Fixes: PRED-941

Manual testing steps

Feature: Predict Ethereum up/down accent color

  Scenario: user views an Ethereum up/down market card on the feed
    Given the predict up/down feature flag is enabled
    And an Ethereum up/down market is available in the feed

    When the user scrolls to the Ethereum market card
    Then the card's sparkline and accent elements render in the Ethereum accent (#5E6DB7)
    And BTC up/down cards continue to render in the BTC orange accent
    And any unmapped crypto up/down card falls back to the default amber accent

  Scenario: user opens the Ethereum up/down details screen
    Given the predict up/down feature flag is enabled
    And an Ethereum up/down market is available

    When the user taps the Ethereum market card and opens the details screen
    Then the chart line, "Current price" label, and current price value render in the Ethereum accent (#5E6DB7)
    And opening a BTC up/down market still renders in the BTC orange accent

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

Not applicable; static color constant addition only.

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.