Feature Requests
Browse ideas under consideration for the product roadmap.
15 requests
Add support for additional wallet integrations (WalletConnect, Ledger, etc.)
Add support for multiple wallet connection methods beyond MetaMask, including WalletConnect and hardware wallets such as Ledger. Use case: users who prefer alternative wallets or hardware signing should be able to connect, authenticate, and sign transactions through their chosen provider. Expected behavior: the wallet selection flow presents supported options (e.g., MetaMask, WalletConnect, Ledger via WalletConnect or native Ledger integration), successfully establishes a secure connection, displays account information and balances, allows transaction signing and submission, and persists the chosen wallet selection where appropriate. The implementation should include error handling for connection failures and clear UI guidance for connecting hardware wallets.
Add real-time order lifecycle and price-threshold notification system
Provide a configurable, real-time notification system that alerts users about order lifecycle events and price proximity to user-defined thresholds. The system should generate alerts for events including order fully filled, partially filled, canceled (by user or system), rejected, and expired. It should also notify when market price approaches configured stop-loss or target levels (by absolute distance or percentage). Notifications must be deliverable via in-app popups, browser/OS push notifications, and optional email, with per-user controls to enable/disable channels and event types. Users should be able to set proximity criteria (percentage or fixed price), customize basic message templates, and specify throttling/aggregation settings to avoid notification spam. The implementation should guarantee near real-time delivery, record notification history for audit/debugging, and expose settings in the UI for managing preferences and thresholds. This enables users to monitor execution status and manage risk more effectively by receiving timely, actionable alerts.
Provide dummy submission capability for testing
Implement a dummy submission feature that creates a placeholder submission for testing and demonstration purposes. Use case: QA engineers and developers can generate a predictable, non-production submission to verify workflows, UI rendering, and integrations without affecting real data. Expected behavior: creating a dummy submission produces a record with predefined sample fields, is distinguishable from real submissions (e.g., a 'dummy' flag), appears in submission lists and logs, does not trigger production notifications or external side effects, and can be easily removed or expired.
Enable trading with up to 200x leverage
The product should allow users to place trades with leverage settings of 100x or 200x (in addition to any existing lower leverage options). When a user selects 100x or 200x, the platform should apply the chosen leverage to position sizing, margin requirements, liquidation calculations, and PnL reporting in real time, following existing risk and account constraints. The feature should support aggressive trading strategies while ensuring leverage limits, liquidation thresholds, and related safeguards remain consistent with current trading behavior.
Add Cardano (ADA) support for trading and funding accounts
Enable Cardano (ADA) as a supported asset for both funding (deposits/withdrawals) and spot trading. Use case: allow users who hold ADA to fund accounts, withdraw ADA, and trade ADA against fiat and other crypto to increase user acquisition and trading volume. Expected behavior: users can view ADA balances in wallets and portfolio, deposit ADA with network-specific deposit addresses and clear confirmations, withdraw ADA with fee estimation and network status, and place/cancel orders for ADA trading pairs (e.g., ADA/USD, ADA/BTC) via existing order types. Backend requirements include wallet custody or third-party node integration, address and transaction monitoring, confirmation requirements, fee handling, and AML/KYC and risk checks consistent with other supported assets. Frontend requirements include UI for ADA deposits/withdrawals, trading pair listings, price/market data, order entry, trade history, and appropriate error/notification handling for network issues and insufficient confirmations.
Add Hedera (HBAR) support for trading and funding accounts
Enable native Hedera Hashgraph (HBAR) support across funding and trading workflows. Users should be able to deposit and withdraw HBAR to/from platform funding accounts, hold HBAR in trading accounts, and trade HBAR against supported fiat and crypto pairs. Expected behavior: generate valid HBAR account IDs for deposits, display incoming deposit transactions with configurable confirmation thresholds, estimate and display network fees for withdrawals, validate external HBAR addresses on withdrawal, execute trades using HBAR balances and update user balances in real time, and display HBAR balances and transaction history in the UI. Backend requirements: connect to Hedera mainnet nodes or a reliable provider, support HBAR native token transfers, implement hot/cold custody flows with secure key management, integrate deposit/withdrawal monitoring, and surface explorer links and reconciliation data for compliance and auditing. Include rate limits, failure/error handling, and monitoring/alerting for unusual activity. Support documentation and UI labels should be updated to include HBAR.
Add Rexas Finance (RXS) support for trading and funding accounts
Add official support for the Rexas Finance (RXS) token across trading and funding accounts. The feature should enable deposits and withdrawals of RXS, display RXS balances in user wallets, and allow placing and executing trades on one or more RXS trading pairs (e.g., RXS/USD, RXS/USDC). Expected behavior includes: on-chain deposit/withdrawal handling with correct confirmations and fee estimation; custody and ledgering of RXS balances; market data and price feeds for RXS shown in the UI and API; order book and matching engine support for configured RXS pairs; configurable trading fees, limits, and margin/collateral rules if applicable; clear UI elements for RXS deposits, withdrawals, and trading (including order entry, balance display, and transaction history); and programmatic access via existing APIs. Implementation must include compliance and risk checks (KYC/AML, sanctions screening, liquidity and slippage assessment), operational monitoring and alerting for RXS chains, and documentation updates for users and internal teams. The use case is to support community demand and increase user acquisition and trading volume by making RXS fully tradable and fundable on the platform.
Add Shiba Inu (SHIB) support for trading and funding accounts
Enable full Shiba Inu (SHIB) support across funding and trading accounts so users can hold, deposit, withdraw, and trade SHIB. Use case: capture demand from the SHIB community, increase user acquisition and trading volume by offering a widely used token. Expected behavior: users can deposit SHIB to their funding accounts and see accurate on‑chain confirmations and balances; initiate withdrawals with applicable network fees and withdrawal limits; transfer SHIB between funding and trading accounts; view real‑time SHIB market data and historical price charts; place market, limit, and cancel orders on enabled SHIB trading pairs (e.g., SHIB/USD, SHIB/USDC, SHIB/BTC) with correct price and quantity validation; balances and P&L reflect SHIB positions; platform enforces configured risk limits, fees, and KYC/AML checks for SHIB activity; admin tools support enabling/disabling SHIB, viewing on‑chain activity, and executing emergency delisting or wallet freezes. Implementation should include wallet infrastructure, hot/cold key management, monitoring/alerting, reconciliation, QA with testnet/mainnet deposits and withdrawals, and documented launch criteria.
Add Little Pepe (LPEPE) support for trading and funding accounts
Enable support for Little Pepe (LPEPE) in both funding (deposits/withdrawals) and trading (spot order entry, order book, market data, balances) workflows. Use case: community demand and high on-chain activity (≈36,000 active addresses/day) suggest adding LPEPE will attract users and increase trading volume. Expected behavior: users can deposit and withdraw LPEPE to platform wallets, view LPEPE balances in funding and trading accounts, place and manage buy/sell orders for an LPEPE trading pair(s), see real-time market data (price, bid/ask, depth), and have accurate ledger/accounting entries for fees and fills. The integration should include token listing criteria verification, wallet infrastructure or custodial support, trading pair configuration, risk controls (price/size limits, circuit breakers), KYC/AML and compliance checks, fee schedule updates, and monitoring/alerting for deposits/withdrawals and abnormal activity.
Add DOGE (Dogecoin) support for trading and funding accounts
Enable Dogecoin (DOGE) as a supported asset for both funding (deposits and withdrawals) and trading on the platform. Use case: community demand and high on-chain activity suggests adding DOGE will attract new users and increase trading volume. Expected behavior: users can deposit DOGE into their funding accounts, view DOGE balances and transaction history, place and fill orders on newly enabled DOGE trading pairs, and withdraw DOGE to external addresses. Platform responsibilities include integrating a DOGE node or third-party custodial provider, displaying DOGE market data and fees, enforcing existing KYC/AML and risk controls for DOGE activity, implementing deposit/withdrawal confirmations and minimums, and providing UI/UX elements (wallet, order entry, balances, trade history) and monitoring/alerting for DOGE network health and liquidity.
Provide press and media contact and response workflow
Add a clear press and media request flow that enables journalists to request comments or interviews. The feature should surface an official contact method (email address and/or web form), specify typical turnaround time (e.g., initial acknowledgement within 24–48 hours and full response or scheduling within X business days), and outline expected information to provide (reporter name, outlet, deadline, topic, embargo requirements). The workflow should include automated acknowledgement, assignment to a designated PR/contact person, escalation guidelines for urgent requests, and published guidance on preferred communication channels and availability for interviews or written comments.
Add dark mode support and chart appearance customization
Provide a user-configurable dark mode and basic chart appearance customization to reduce eye strain during extended trading sessions. Users can toggle between light and dark themes via a persistent setting in the UI (and option to follow system theme). Dark theme should apply consistently across the application chrome, menus, dialogs, and chart background/axes/labels. Additionally, allow configurable chart appearance options such as background color (light/dark/auto), grid visibility, and color palettes for price series and indicators. The feature should persist user preferences across sessions and not affect data or trading functionality.
Add interactive liquidity heatmap for trading
Implement an interactive market-depth liquidity heatmap that visualizes buy and sell pressure across price levels in real time. The feature should present a heatmap-style order book with color intensity representing aggregated liquidity at each price, separate visual lanes for bids and asks, and configurable depth and resolution. Users must be able to hover or click price levels to highlight liquidity, view tooltips with aggregated size, best bid/ask, and recent order flow, and optionally jump to the corresponding order book entries or place orders at that price. The heatmap must update in real time with low latency, include controls to toggle the visualization, adjust time smoothing and size filters, and be performant for high-frequency updates. Use case: provide traders with clear, actionable visibility into order flow and potential price movement, offering pro-level transparency comparable to centralized exchanges.
Add Smart Slippage Simulator to Swap Confirmation
Introduce a slippage simulation tool in the swap confirmation flow that predicts likely execution price outcomes using historical volatility, current liquidity depth, and recent mempool activity. Use case: allow traders to preview and compare expected and worst-case slippage before confirming a swap to reduce unexpected losses during high-volatility periods. Expected behavior: when a user opens the swap confirmation, the simulator calculates and displays a visual estimate showing (1) expected slippage with a confidence range, (2) worst-case slippage during recent volatility spikes, and (3) comparative execution-price impacts for preset slippage tolerances (0.1%, 0.5%, 1%). The display updates in near real-time (e.g., refresh cadence configurable, default <10s), surfaces key data inputs and assumptions, and degrades gracefully with a clear notice if required data (liquidity depth or mempool info) is unavailable. Performance budget, data sources, and privacy considerations should be defined in the implementation plan.
Increase default platform font sizes to meet accessibility standards
Adjust the default font sizing across the Polyester platform so body text and UI elements meet recognized accessibility guidelines (recommendation: minimum 16px for body text). Use case: users with visual impairments, high-DPI displays, or without browser zoom should be able to comfortably read and interact with labels, buttons, dropdowns, and content text. Expected behavior: default typography scales and CSS variables ensure readable sizes on desktop and mobile, text passes standard accessibility checks (WCAG contrast/readability where applicable), and UI components retain layout integrity. Verify changes across supported browsers (e.g., Chrome, Edge) and screen resolutions.