Building a unified market intelligence platform for traders, analysts, researchers, and developers.
After months of development, Jungletrade is now publicly available.
The idea behind Jungletrade is simple: modern market analysis has become fragmented.
Market data, indicators, analytical models, and trading signals are often distributed across multiple platforms, forcing users to maintain several subscriptions, workflows, and dashboards just to build a complete market view.
We wanted to explore a different approach.
📊 The Problem
Most market platforms focus on a specific layer of the analytical stack:
- Raw data
- Technical indicators
- Quantitative models
- Trading signals
Each layer provides value, but users are frequently required to move between multiple tools to connect the pieces.
Our goal was to create a modular ecosystem where these layers can coexist within a single platform.
🧭 The Jungletrade Ecosystem
Today, JungleTrade provides four product categories:
📦 Data
Structured datasets for market research and discovery.
🧠 Models
Analytical frameworks designed to identify patterns and relationships within market data.
📈 Indicators
Tools that transform raw information into actionable insights.
⚡ Triggers
Event-driven signals designed to highlight potential market opportunities.
🔍 Built for Transparency
One design decision was particularly important to us: every product should explain itself.
Each product includes:
- Product description
- Key features
- Use cases
- Interpretation guidelines
- Methodology overview
The objective is not simply to provide charts but to explain the problem being solved and how the underlying analysis works.
🔌 API First
All products available through the platform are also accessible through API endpoints.
Developers interested in integrating JungleTrade data into their own applications, dashboards, or research pipelines can request a demo API key through the platform.
🏗️ Architecture
JungleTrade is built using a modular, service-oriented architecture designed to support both high-performance market data delivery and computationally intensive analytical workloads.
The user interface is built with React, Next.js, and Node.js, providing a modern, responsive platform for accessing market intelligence products across the ecosystem.
At the core of the platform, .NET services are responsible for orchestration, business logic, data processing pipelines, and scalable multithreaded operations that power the underlying infrastructure.
For advanced quantitative research and analytical processing, JungleTrade leverages Python-based services responsible for statistical modeling, machine learning workflows, data science pipelines, and market intelligence calculations.
Communication between services is handled through cross-language gRPC, enabling efficient interoperability between .NET and Python components while maintaining a clean separation of responsibilities.
This architecture allows us to combine the performance and scalability of .NET, the flexibility of the modern JavaScript ecosystem, and the extensive scientific computing capabilities available in Python.
As the platform evolves, new products can be integrated as independent modules while continuing to operate within the same unified ecosystem.
🌍 Free Access
All products are currently available through the Jungletrade interface without registration.
We want users to be able to evaluate the platform and the underlying methodologies before committing to any integration.
🚀 Architecture and Roadmap
Jungletrade is built on a modular architecture that allows new products to be introduced without disrupting the existing ecosystem.
Future development will focus on:
- Additional datasets
- New analytical models
- Enhanced indicators
- Expanded trigger frameworks
- API improvements
🌱 Looking Forward
This public launch is the first step.
We're interested in feedback from traders, analysts, researchers, and developers.
If you have ideas, questions, or suggestions, we'd love to hear them.
Visit
AI-Powered • Data Driven • Built For Traders
Top comments (5)
Ran an empirical retro on OMNIS this morning across 1320 snapshots × 30 days against BTC returns. The "explain itself" discipline on the page is the part I want to ratify forward: publishing Uncertainty % and the "relationship with price may vary" disclaimer is doing real work, and the methodology overview reads honestly enough to be auditable.
What the audit revealed is one floor under that, and it's worth surfacing because the methodology layer doesn't answer it on its own: OMNIS reads as coincident/lagging rather than leading. Score-to-BTC correlation at -24h horizon is -0.30 (score reflects past 24h move), and forward correlations at +1h, +4h, +24h, +48h are all within noise of zero. Bullish-Bias vs Bearish-Bias label bands produce indistinguishable forward returns. The one suggestive contrarian signal is the "Risk-off" tag at n=17 over 30 days, which is too small a sample to deploy against.
Honest caveat on the audit: 30-day window was a clean bearish trend (BTC 76k→61.6k). A bull-regime sample might invert some of the bands. But sensitivity to regime is itself a stability concern.
The question this opens for the "explain itself" rule: does JungleTrade publish per-Model forward-correlation-over-time disclosure as a first-class field alongside methodology overview? The transparency layer covers what the model measures and how. The second-order question is whether what it measures has forward edge versus same-window coincident correlation. Different epistemic gates, both needed.
@mike Czerwinski Thank you for the comment, i really appreciate it.
That i grate question and i have to admit that it highlights the important distinction between the analytical product and execution system.
As for now the Triggers concept is for decision-support rather for automated executions systems. The primary purpose is to identify statistically or analytically significant market conditions or regime changes and present them transparently with the with the methodology that produced them.
I completely agree that there is a difference between the theoretical triggers quality and real world performance. We are very aware of this phenomenon. We are aware that the trigger quality may be compromised by the latency, slippage, infrastructural issues, etc.
We are considering adding trigger execution history and execution success rate, methodology , and other diagnostics for transparency.
In other word we focus not only to explain the Triggers and why it fired but also but also how it behaved in real world production.
I really try to focus on transparency and this is the reason why the whole section is dedicated on explaining tow most fundamental questions: why? & how?
It was nice to read your comment mate, thank you very much!
Appreciate the response and the honest scope clarification, "decision-support rather than automated execution" is the right frame for the Triggers as they stand. Trigger execution history + success rate + diagnostics as future fields would close exactly the gap I was asking about. Looking forward to seeing what shape that takes when it lands.
Sure, Mike! I'm really glad we're thinking along in the same direction.
If you are interested, drop me a PM and i will gladly provide a demo API key so you can explore the endpoints.
I know that everyone is busy these days, but i'd really will appreciate your thoughts and feedback.
Nice taking with you mate!
Thanks Dragomir, appreciate the openness. On our side we're building a trading system too, real positions live, and we're getting close to a point where we can share what the audit pattern looks like in practice. Will take you up on the demo key, and the exchange of notes is exactly the kind of conversation I want going forward. Talk soon.