System Features & Product¶
Planned user-facing capabilities: PineScript backtest in-app, native strategy execution (reduce TradingView dependency), one-webhook multi-account (Pro/B2B), market expansion, and frontend improvements.
PineScript Compiler & In-App Backtest (Strategy Editor)¶
Goal: Let users run backtests directly in 4pass using the same visual strategy editor and logic they already use, without depending on TradingView for backtest.
| Current | Planned |
|---|---|
| Free strategy editor (Vue Flow → PineScript v6 code) | PineScript compiler in backend to produce executable signal series |
| Backtest engine exists (vectorbt, magnifier) but not exposed to end users | User-facing backtest: run strategy against historical OHLCV (TimescaleDB), show equity curve, drawdown, trade list, stats |
| Users rely on TradingView for backtest | Single flow: edit strategy in 4pass → backtest in 4pass → deploy to live/paper |
Value: Lower friction for strategy design and validation; one less reason to leave the platform.
Native Strategy Execution (Reduce TradingView Dependency)¶
Goal: Support running strategies entirely on 4pass and auto-execute trades, so TradingView is optional rather than required.
| Current | Planned |
|---|---|
| TradingView alerts → webhook → 4pass → broker | 4pass-native execution: strategy runs on 4pass (scheduled or event-driven), signals generated in-app, orders sent to broker |
| Strategy logic lives in TradingView (Pine + alerts) | Strategy logic in 4pass: same PineScript compiler output, run in worker or dedicated runner; no external alert needed |
| One execution path: webhook | Two paths: webhook (TradingView / external) and native (4pass engine) |
Value: Users who prefer not to pay for or depend on TradingView can build, backtest, and run strategies entirely on 4pass. Expands addressable market and retention.
One Webhook URL → Multiple Trading Accounts (Pro / B2B)¶
Goal: Allow one webhook URL to trigger orders on multiple linked trading accounts — for professional users and B2B asset managers running the same signal across many accounts.
| Current | Planned |
|---|---|
| One webhook URL ↔ one trading account | Multi-account binding: one webhook URL can be linked to N accounts (same or different brokers) |
| Each account needs its own alert / URL | Single signal (e.g. one TradingView alert) → 4pass fans out to all linked accounts (with optional per-account sizing or filters) |
| B2B / asset managers must manage many URLs | One URL per strategy or client group; 4pass handles fan-out, audit, and per-account credentials |
Use cases: Asset managers executing the same strategy across client accounts; pro users with multiple broker accounts; white-label or API partners. May be gated as a Pro or Enterprise feature.
Broker Integration: Special Architectures¶
Some brokers cannot be integrated with the current Linux-based worker model because they rely on Windows-only or native binary interfaces. We plan to support these in the future so 4pass can serve forex and other markets that depend on such stacks.
DLL-only APIs¶
| Situation | Challenge | Possible approach |
|---|---|---|
| Broker provides only a Windows .dll (or COM) API | Current workers run Linux (ECS); no direct load of Windows DLLs | Bridge service: a small Windows process (e.g. on Windows EC2 or a Windows container) that loads the DLL, exposes a thin REST or queue interface, and is called by 4pass orchestration. One bridge per broker or per tenant; credentials stay in 4pass, bridge is stateless. |
| Multiple such brokers | Each may need its own adapter | Reusable adapter pattern: same 4pass ↔ bridge protocol; only the DLL wrapper is broker-specific. |
Goal: Allow brokers that offer only DLL/Windows APIs to be added as first-class 4pass brokers via a dedicated Windows-based bridge, without changing the core Linux worker or API design.
Windows-only applications (e.g. MT4 / MT5)¶
| Situation | Challenge | Possible approach |
|---|---|---|
| Broker requires MetaTrader 4/5 or similar standalone terminal that runs only on Windows | Order execution goes through the terminal (or its API); terminal must be running on a Windows host | Terminal bridge: Windows VM or container running the terminal (or headless MT4/MT5 server API if available); 4pass sends signals to the bridge, which places orders via the terminal or official API. Alternatively, integrate with an existing MT4/MT5 copy-trading or FIX bridge provider. |
| Licensing / resource usage | One terminal instance per account or per strategy is common | Pool of Windows nodes (e.g. Windows EC2 or dedicated hosts) running terminal instances; 4pass assigns users/strategies to an instance and manages lifecycle. |
Goal: Support forex (and other) brokers that depend on MT4/MT5 or similar Windows-only applications, via a dedicated Windows bridge or partnership with a bridge provider, so strategies can run from 4pass and execute through these platforms.
Architecture impact
These options imply a separate Windows capacity pool or partner bridge: the existing Linux ECS workers continue to serve Shioaji, Gate.io, and other REST/WebSocket brokers; DLL and MT4/MT5 support are additive. Timeline and exact design (in-house Windows pool vs. partner API) will depend on demand and broker requirements.
Market Expansion¶
US Market Support¶
| Component | Work Required |
|---|---|
| New broker integration | Implement BrokerService for US broker (e.g., Interactive Brokers, Alpaca) |
| Symbol normalization | Map US symbols to NormalizedSymbol format |
| Trading hours | Add US market hours to scheduling logic |
| Regulatory compliance | US securities regulations, pattern day trading rules |
The abstract broker interface means adding US market support requires only a new broker implementation — no changes to the API, worker, or frontend.
Additional Crypto Exchanges¶
Potential additions using the same BrokerService pattern:
- Binance (spot + futures)
- Bybit (derivatives)
- OKX (unified trading)
Frontend & UX¶
Backtest Results Dashboard¶
Dedicated view for displaying backtest results with:
- Equity curve chart (lightweight-charts)
- Drawdown visualization
- Trade table with entry/exit markers
- Performance statistics grid
- Strategy parameter comparison
Mobile Responsive Optimization¶
The current dashboard is responsive (375px-8K) but optimized for desktop. Planned improvements:
- Touch-friendly order placement
- Swipe navigation between tabs
- Push notifications for order fills
- Progressive Web App (PWA) support
Overview · Infrastructure · System Architecture · DevOps & Quality