# Semantic Signal (qrak.org) — full site text Source: https://qrak.org | Generated from the deployed build; every page of the site as plain text, for LLM tools and crawlers. Fact sheet in JSON: https://qrak.org/project.json Short index: https://qrak.org/llms.txt Source code: https://github.com/qrak/LLM_trader Status carried with every page: paper trading only (simulated capital), executor on an exchange testnet, profitability unproven, not financial advice. ============================================================================== ## Home URL: https://qrak.org/ ============================================================================== Open source • Python 3.13 • simulated capital by default Most trading bots do arithmetic. This one reads the chart, remembers its trades, and has to defend every call. Semantic Signal renders a 1920×1080 candlestick chart for a multimodal model, keeps a 768-dimensional memory of every closed trade, and puts one deterministic expected-value gate between the model's opinion and any order. Read the 9-month storyLive dashboard ↗GitHub ↗ trading simulated capital (paper) live executor exchange testnet only — no real funds test suite 1,549 tests · 1,532 passing · 17 skipped providers Google AI, DeepSeek, OpenRouter, local — switchable How it compares — including the rows where I lose Feature-by-feature against three mature products. ✔ / ✘ only where I could check their public documentation; a question mark means I could not verify it and would rather show a gap than a guess. Freqtrade, 3Commas and Cryptohopper have been in production for years and run thousands of accounts — the rows near the bottom say so. CapabilityFreqtrade3CommasCryptohopperThis project Chart vision — an image goes to the model, not floats✘??✔ 1920×1080 PNG per cycle Semantic memory of its own closed trades✘✘✘✔ ChromaDB, 768D Bull case / bear case before deciding✘??✔ one prompt, two roles Deterministic expected-value gate before entry✘??✔ math overrides the model Free news / community context (no paid API keys)✘??✔ RSS + Reddit Automated order execution✔✔✔✔ separate executor service Trading with real money today✔✔✔✘ testnet only Years in production, thousands of users✔✔✔✘ started Dec 2025 Hosted for you — nothing to install or babysit✘✔✔✘ you run it yourself Proven, audited profitability✘✘✘✘ neither do I — nobody can promise this Comparison reflects the vendors' public documentation as of September 2026, not their paid marketing material. If a ✔ or ✘ is wrong, mail contact@qrak.organd it gets fixed. chart_vision An image, not just indicator floats A Plotly candlestick chart at 1920×1080 with SMA, RSI, CMF and OBV goes to the multimodal model alongside the numeric stack. Wick geometry, volume spikes and wedges are read off the picture — but every number the model cites is checked against the computed values. vector_memory 768D memory of its own mistakes Every closed trade is embedded with BAAI/bge-base-en-v1.5 into ChromaDB. Before each decision the bot retrieves the top-5 most similar past setups, each tagged with aSurprise Ratio so a lucky win does not become a rule. ev_gate Deterministic math beats the model Expected value is computed from the bot's own closed-trade history. If the math says the trade is not worth taking, the signal is rejected — the model does not get a vote. Position size comes from the same history, not from a confidence score. executor Reasoning and execution are separate processes The engine emits one atomic JSON decision; a second service does CCXT order placement, leverage and exchange-side stops, and writes a verdict journal the engine reads back. The bot confirms what happened to its own order instead of assuming it. Built in a Wrocław apartment after warehouse shifts In December 2025 I was working 8-hour warehouse shifts in Poland and testing "AI trading bot" templates in the evenings. Nine months later the project has 1,549 automated tests, an 8-agent development system that maintains the codebase, and a live executor running against an exchange testnet — not a cent of real money, by design. Read the full development history → From the blog How the bot reads charts 999 candles, 50+ Numba indicators, a 1080p chart image — and a model that has to defend its call. Vector memory How 768D embeddings turn closed trades into lessons the bot retrieves before every decision. Paper → live: the executor Why reasoning and order placement are separate services, and what is still missing before real capital. Where every number on this page comes from Nothing here is a screenshot from a course. All of it lives ingithub.com/qrak/LLM_trader: chart image 1920x1080 src/analyzer/pattern_engine/chart_generator.py 999 candles, 50 lvls config/config.ini · src/analyzer/data_fetcher.py trade memory 768D src/trading/vector_memory.py (BAAI/bge-base-en-v1.5) EV gate, pre-entry src/trading/position_management.py dev agents x8 .ai/ (supervisor + 7 specialists) tests 1,549 python -m pytest tests -q -> 1,532 passed, 17 skipped ⚠️ Risk disclaimer: Semantic Signal is an experimental, open-source software project — not financial advice, not a money machine. It trades simulated capital by default, it has lost money on paper during development, and trading cryptocurrencies carries substantial risk of loss. Read the full disclaimer. ============================================================================== ## The full development story & technology URL: https://qrak.org/story/ ============================================================================== Published July 2026 · last updated 19 September 2026 · by @qrak I Built a Trading Bot That Doesn't Just Calculate — It Sees, Remembers, and Learns from Its Failures The engineering history of an open-source, vision-capable crypto bot — first commit 21 December 2025. 1. The Wrocław warehouse spark In December 2025 I was living in Wrocław, Poland, working 8-hour warehouse shifts. My back was sore, my energy depleted, and my mind was stuck on one question: why are all the "AI trading bots" out there so dumb? I did what every YouTube tutorial recommends. Pull RSI, MACD and Bollinger Bands in Python, write a prompt template, dump the floats into an LLM API. The decisions came back confident, articulate — and wrong. "RSI is at 28, oversold. BUY." Then the market went down instead, and the paper portfolio went with it. The model was not the problem. The architecture was. I had built a stateless calculator and called it a reasoning engine. 2. The timeline, taken from git log Every date below is the date a file first appeared in the repository or a commit landed. You can check all of them with git log --date=short --diff-filter=A. Phase 1 — December 2025: the stateless calculator First commit 21 Dec 2025, multimodal support via OpenRouter on 28 Dec. The candle_limit = 999 value has been in config.ini since that very first commit, the order book is fetched at 50 levels, and the bot had no memory of anything it did. Phase 2 — January 2026: the bot gets eyes The dashboard server lands 6 Jan; the ChartGenerator (16 Jan) renders OHLCV and RSI into a PNG the model can actually look at, with the image-export retry logic that Plotly/Kaleido makes necessary. The bot stops reading floats and starts reading a chart. Phase 3 — May 2026: the brain 16 May: the vector-memory era. brain_experience, brain_context and brain_reflection arrive — closed trades become 768D embeddings in ChromaDB, retrievable before the next decision, with a reflection pass that writes rules in plain language. A few days earlier (12 May) came the blunt commit message "make bot profitable with Gemini Flash 3 Preview" — that one aged badly, and I left it in the history on purpose. Phase 4 — July 2026: the bot starts maintaining itself 26 Jul: the .ai/ directory appears — a supervisor plus seven specialist agents (Bolt, Palette, Sentinel, Refactor, Concise, Bugfixer, Smoke Tests) with their own journals. 30 Jul: Reddit/RSS sentiment lands, and with it the public landing page. Phase 5 — August 2026: the executor and the verdict journal 14 Aug: executor integration. The engine stops assuming what happened to its orders and starts reading a verdict journal — one line per decision, written by the executor service, keyed by the bot's own order_id. Orders that cannot be confirmed go to a dead-letter queue instead of vanishing. Phase 6 — September 2026: providers, tests, and a smaller ego 12 Sep: provider transport consolidation and the official DeepSeek API added next to Google AI. 19 Sep: the test suite is reorganised into domain modules and the entry gate is reduced to expected value alone — the fixed R/R floor is gone, and the brain earns its own floor from its own expectancy. 1,549 tests collected, 1,532 passing, 17 skipped. 3. The mathematics and the engineering The Numba JIT indicator engine Indicators are written in NumPy and decorated with Numba's @njit(cache=True), so they compile to machine code on first call and cache the result. src/indicators/ contains 97 Numba-compiled functions (134 across the whole src/ tree) with zero external technical-analysis dependencies. Real code, not a screenshot: @njit(cache=True) def supertrend_numba(high: np.ndarray, low: np.ndarray, close: np.ndarray, length: int = 10, multiplier: float = 3.0) -> tuple[np.ndarray, np.ndarray]: """Calculate Supertrend indicator.""" n = len(close) atr = atr_numba(high, low, close, length) hl2 = (high + low) / 2 upperband = hl2 + multiplier * atr lowerband = hl2 - multiplier * atr # ... band adjustments, then the trend/direction loop return trend, direction src/indicators/trend/trend_indicators.py — trimmed; the full function is in the repo. Chart vision Plotly renders a 1920×1080 candlestick chart (SMA, RSI, CMF, OBV, swing annotations) to PNG and it is sent to a multimodal model alongside the numeric stack. Images arrive from an export pipeline that hangs often enough that the code carries timeouts and exponential-backoff retries around it — src/analyzer/pattern_engine/chart_generator.py. The Surprise Ratio A support break that won because of a random news spike should not become a rule. Every closed trade gets a surprise score: Surprise Ratio = |Realized P&L − Expected P&L| / |Expected P&L| Anything above 1.5 is tagged ⚠️ high surprise in vector memory so the model discounts it later (src/trading/brain_reflection.py). The bot learns from what it understood, not from what it got lucky on. The expected-value gate EV = (Win Rate × Average Win) − ((1 − Win Rate) × Average Loss) − Fees EV is computed from the bot's own closed-trade history. If it is negative, the signal is rejected outright — deterministic arithmetic that overrides the model, not a suggestion. This is now the only hard gate: the old fixed 1.5 R/R floor was removed (config/config.ini → min_rr_entry = 0.0) and replaced by a floor the brain derives from its own expectancy once it has enough losing low-R/R trades to learn from. What is not in here - No Kelly criterion. An earlier version of this page claimed Kelly-sized positions. There is no Kelly code in the repository. Position size is the model's proposal, clamped to a 10% of capital cap, with 1% / 2% / 3% fallbacks by conviction level. - No magic win rate. I have no sustained profitable period to show, so I do not quote one. - No backtest-to-live claim. Simulated fills have no slippage, no partial fills and no liquidity limits. Paper numbers are not live numbers. 4. Honest status — September 2026 - Trading: simulated capital only (a 10,000 USDC paper book). No real funds are involved anywhere in this project. - Executor: implemented as a separate service and wired to an exchange testnet (ENABLE_TESTNET=true, sandbox endpoints). It has placed test orders and journals their verdicts; live trading with real money is not enabled. - Profitability: unproven. Development has had losing stretches and the code comments admit it. If that ever changes, this page changes with it. - Source: the whole thing is at github.com/qrak/LLM_trader. Read the code before you believe a word of this page. 5. Quick start git clone https://github.com/qrak/LLM_trader.git && cd LLM_trader python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate pip install -r requirements.txt cp keys.env.example keys.env # add GOOGLE_STUDIO_API_KEY, DEEPSEEK_API_KEY or OPENROUTER_API_KEY python start.py # dashboard at http://localhost:8000 Paper trading is the default. The executor only sees decisions when you enable it — and it defaults to testnet. 6. Errata — what this page used to claim Kept visible on purpose, because a page that silently edits its own history is worth less than one that shows its corrections: - "Kelly Criterion position sizing" — removed. No Kelly code exists in the repo. - "a hard 1.5 R/R floor rejects the signal" — no longer true; EV is the only hard gate and the R/R floor is learned from expectancy. - "how the system earns real money" — removed. The executor runs against an exchange testnet, and no real capital is at stake. - "1,270 automated tests" (August) → 1,549 today. The number moves with the code, so it is now generated from a test run, not typed from memory. - Chart vision and vector memory were previously dated February–April 2026. The code says 22 Dec 2025 and 16 May 2026 — the timeline above is the one that matches git log. ============================================================================== ## Articles URL: https://qrak.org/articles/ ============================================================================== Articles · updated September 2026 Articles Deep dives into how the system actually works — written by the developer, grounded in the code, corrected in public when the code changes. Latest How the bot reads charts: from candles to conviction The pipeline from raw market data to a reasoned decision — 999 candles, a 50-level order book, 97 Numba-compiled indicator functions, a 1920×1080 chart image, and an expected-value gate that overrides the model. Vector memory: how an LLM trader remembers its mistakes Closed trades become 768-dimensional vectors in ChromaDB. Before each decision the bot reviews its own history — 3 nearest setups, 20-trade statistics, 5 recent rejections — and a math check separates luck from skill. From paper to a live executor: why order placement is a separate service Reasoning and order execution are deliberately decoupled. The seven checks every decision passes, the verdict journal that closes the loop — and the honest state of the live path: testnet only, reconciliation still the weak link. The full development story (December 2025 – September 2026) The engineering history with real commit dates, the mathematics behind the gates, an honest status report, and a list of the claims this site got wrong and had to fix. See the system in action: the live dashboard streams every decision, prompt and reasoning step in real time. Live dashboard ↗GitHub ↗ ============================================================================== ## How the bot reads charts URL: https://qrak.org/articles/chart-vision/ ============================================================================== Article · first published August 2026 · updated September 2026 How the Bot Reads Charts: From Candles to Conviction What actually happens inside a 4-hour analysis cycle — from raw exchange data to a reasoned decision with stop-loss and take-profit levels. The input: more than candles Most trading bots reduce the market to a handful of indicator values. Semantic Signal starts wider. Every cycle, CCXT pulls 999 candles, a 50-level order book, the funding rate, 24-hour volume and the last 500 trades from the exchange. The order book matters because it shows where counterparties are actually sitting: bid/ask depth by level, imbalance, spread. That is real market microstructure — information a line chart cannot carry. 97 Numba-compiled functions, microseconds each The indicator engine is NumPy plus Numba with @njit(cache=True): each function compiles to machine code on first call and caches the result. src/indicators/ holds 97 of them (134 across the whole src/ tree) — EMA, ADX, Supertrend, Ichimoku, Parabolic SAR, CMF, OBV, RSI, custom support/resistance and volatility work — with zero external technical-analysis dependencies. That matters for the next step: the model receives a numeric stack that was computed deterministically and can be cross-checked line by line, instead of a black-box library's output. The chart image: seeing like a human trader Plotly renders a 1920×1080 candlestick chart with SMA, RSI, CMF and OBV panels plus swing-point annotations. That PNG is sent to the multimodal model alongside the raw indicator values. Why an image at all? Because geometry carries information: the shape of a wick, a volume spike at support, a wedge that is about to break. A human trader sees these at a glance and struggles to express them as floats. The model reads both channels — picture and numbers — and every numeric claim it makes is checked against the computed values. Nothing is taken on faith. One honest engineering note: Plotly's image export (Kaleido) hangs often enough that the exporter runs in a thread with a hard timeout and exponential-backoff retries. It is in the repo, not hidden. Fresh context: news and community sentiment Before reasoning, the cycle ingests up to 5 articles from live RSS feeds (CoinDesk, CoinTelegraph, Decrypt, CryptoSlate) — optionally enriched with the full article body via Crawl4AI — plus Reddit community sentiment from public Atom feeds. On-chain fundamentals come from CoinGecko and DefiLlama, and the mood index from Alternative.me's Fear & Greed. No paid API keys are involved. X/Twitter is not used: without paid authentication it is not reliably scrapable, so the bot runs on Reddit + RSS rather than pretending otherwise. The debate: bull vs bear The multimodal model argues the bull case, then the bear case, then evaluates the trade against the bot's own closed-trade history: EV = (Win Rate × Average Win) − ((1 − Win Rate) × Average Loss) − Fees If EV comes out negative, the signal is rejected. This is deterministic arithmetic that overrides the model — it is not a suggestion in a prompt. Expected value is currently the only hard entry gate: the old fixed 1.5 R/R floor was removed in September 2026 (min_rr_entry = 0.0) and replaced by one shared floor policy that combines the configured value with the brain's own borderline R/R, so that the number shown to the model is the same number the executor enforces. The falsification check Before a signal is accepted, the model has to write an explicit price invalidation trigger: the exact condition under which the trade is wrong. If it cannot defend the call against its own invalidation test, the signal is rejected. A missed +EV opportunity is treated as mathematically identical to a realized loss, so the bot is penalised for not trading when it should have. The final output is a decision with reasoning, risk parameters and stop-loss/take-profit levels — logged to the audit trail and visible on the live dashboard. Stops are ATR-scaled rather than fixed percentages, and exits poll live prices every 15 minutes in hard mode. Watch a real cycle end-to-end — the dashboard streams every prompt and decision. Live dashboard ↗Next: vector memory → Risk notice: This is an experimental open-source project, not financial advice. It trades simulated capital by default; results are not live trading results. Trading crypto carries substantial risk. See the full risk disclaimer. ============================================================================== ## Vector memory URL: https://qrak.org/articles/vector-memory/ ============================================================================== Article · first published August 2026 · updated September 2026 Vector memory: how an LLM trader remembers its mistakes A stateless LLM is just a calculator. This one keeps a semantic memory of every closed trade — and reviews its own history before acting. The problem with stateless bots An LLM without memory treats every decision as if it were the first one ever made. It does not know that it bought the same breakdown pattern twice before — and lost both times. The first version of this project (December 2025) was exactly that: a stateless prompt pipeline producing confident, articulate, consistently wrong decisions. The fix was not a better model. It was architecture: give the system a brain that actually remembers. Every closed trade becomes a vector When a trade closes, its full context and outcome are embedded with BAAI/bge-base-en-v1.5 — 768 dimensions — and stored in ChromaDB. Three collections carry the memory: - trading_experiences — every closed trade with its context, outcome and P&L; - semantic_rules — rules the reflection engine has written from results, in plain language; - system_constraints_rejections — signals that were refused, and the reason. Confidence statistics are not a fourth collection: they are computed on demand from the same embeddings (compute_confidence_stats), which keeps one source of truth for "how am I actually doing?". Retrieval: "have I seen this before?" Before each decision the brain assembles a context it can reason from: - 3 most similar past trades — retrieved by vector similarity (over-fetched, then re-scored 70% similarity / 30% recency), each labelled with a match breakdown; - win-rate statistics computed over the 20 nearest trades in the current market context; - 5 most recent rejected signals — so the bot remembers what it refused and why; - 3 learned rules that match the current regime (trend + ADX + volatility label). If the sample is too thin the prompt says so, in capitals: "⚠️ LIMITED DATA: treat these as ANECDOTES, not as an established pattern". A bot that pretends two trades are a track record is worse than one with no memory at all. The Surprise Ratio: separating luck from skill Not all outcomes are equally informative. A support breach that won because of a random news spike teaches the wrong lesson. Every trade therefore gets a surprise score: Surprise Ratio = |Realized P&L − Expected P&L| / |Expected P&L| Anything above 1.5 is tagged ⚠️ high surprise in vector memory, so the model discounts it in later cycles. The bot learns from what it understood, not from what it got lucky on. The reflection engine Periodically a reflection pass reviews recent outcomes and synthesises new rules from what worked and what did not. The rules are semantic — natural language, embedded, retrieved when conditions match — and they are typed: anti_pattern (things to avoid), corrective (adjustments) and best practice. A matched anti-pattern forces the model to state the conflict and lower its confidence instead of quietly ignoring it. A missed +EV opportunity is treated as mathematically identical to a realized loss (it is written into the prompt that way), so the loop stays honest about omissions too: act → embed the outcome → retrieve the lesson → act differently. The dashboard shows the memory bank in action — retrievals, rules and rejections behind every decision. Live dashboard ↗Next: the executor → Risk notice: This is an experimental open-source project, not financial advice. It trades simulated capital by default; results are not live trading results. Trading crypto carries substantial risk. See the full risk disclaimer. ============================================================================== ## From paper to a live executor URL: https://qrak.org/articles/executor-separation/ ============================================================================== Article · first published August 2026 · updated September 2026 From paper to a live executor: why order placement is a separate service The engine thinks. The executor acts. Keeping those apart is the difference between a research prototype and something you would trust near a real exchange. Two very different jobs Reasoning and execution have opposite failure modes. Reasoning is slow, deliberate and benefits from context. Execution is fast, unforgiving and benefits from discipline. Semantic Signal splits them: the engine produces an atomic JSON decision — symbol, side, size, stop-loss, take-profit, reasoning. A separate service, llm_trader_executor, does everything on the exchange side: CCXT order placement, leverage, exchange-side stops, and a JSONL verdict journal that answers the only question that matters — what actually happened to this order? The guard chain in the executor Every decision is checked in order before a single order can leave the process (src/safety.py): - Duplicate detection — a content hash of the decision, not a timestamp, persisted to disk so a bot restart cannot re-execute the same trade; - Actionable signal — anything that is not a known entry, close or update is dropped; - Confidence floor — entries below the configured minimum confidence are blocked, while exits and stop updates are deliberately exempt (you do not want a low-confidence signal keeping you in a losing trade); - Quantity sanity — entries need a positive size; - Leverage cap — anything above the configured maximum is rejected; - Order type enforcement — with market entries configured, limit orders are refused rather than quietly resized; - Max position notional — quantity × entry price has to fit the USDC limit, re-priced from the exchange if the decision arrives without a price. On the engine side the same decision already passed the configured pair (crypto_pair = BTC/USDC, 4h — the bot does not roam the market), a cooldown window, the shared R/R floor policy and the position cap. A spot SELL is capped to what is actually held, so a short can never be created by accident. Stop distances come from the regime risk profile (a tight 1.5× ATR in choppy markets, a wider 2× ATR in trends) instead of a fixed percentage. If governance or risk validation cannot decide safely, the system fails closed: no order, no exception. Soft exits trigger at candle close; hard exits poll live prices every 15 minutes. The verdict journal A successful HTTP call is not proof that an order exists. Instead of assuming, the executor appends one line per processed decision to a JSONL journal — executed, blocked or error, with the reason, keyed by the bot's own order_id. The engine reads that file back to find out what actually happened to its order. Friction is reported, not swallowed: if position size gets clamped or a decision is blocked, that shows up in the journal and on the dashboard. When a state genuinely cannot be determined, the dashboard says so instead of showing a green checkmark it cannot back up. Where this actually stands (September 2026) No overselling: - The executor runs against an exchange testnet (ENABLE_TESTNET=true, sandbox endpoints). It has placed test orders — the verdict journal has entries — and it has never touched real funds. - It was last exercised in August 2026. Since then the work went into the brain, the tests and the R/R policy, so the live path is the least-recently-certified part of the system. - The part I trust least is reconciliation: proving that what the exchange holds matches what the journal claims. That is exactly what has to be boring and reliable before any real capital is considered — and it is not there yet. - The executor is a separate local service and is not open-sourced yet; the engine is. Capital stays simulated until the pipeline proves itself over a sustained period. That is a deliberate decision, not a limitation to hide: demo and live are different worlds, and a system should earn live trading the way it earns everything else — by surviving its own history. The dashboard shows live position state and the audit trail behind every decision. Live dashboard ↗GitHub ↗ Risk notice: This is an experimental open-source project, not financial advice. Real-money trading is not enabled; everything you see runs on simulated capital or an exchange testnet. Trading crypto carries substantial risk. See the full risk disclaimer. ============================================================================== ## About the developer URL: https://qrak.org/about/ ============================================================================== About About the developer Self-taught backend developer. AI/LLM specialist. Building autonomous systems after hours in Wrocław, Poland. Who I am I'm Piotr Kurnicki (@qrak) — a self-taught backend developer with deep AI/LLM experience. By day I work in warehouse logistics; after hours I build autonomous AI systems. My strength is depth rather than breadth: every line of this codebase was written, tested and understood by me. Before the warehouse I worked with enterprise SAP environments at BSH Sprzęt Gospodarstwa Domowego, where I learned how large, mission-critical systems are structured — and what happens when they are built carelessly. What I'm building now Semantic Signal is an open-source, vision-capable AI trading agent: it reads candlestick charts as images, keeps a semantic vector memory of its own trades, and reasons with bull/bear cases and a deterministic expected-value gate before acting. Right now I'm hardening the trade executor — the separate service that carries the system from simulated capital towards real exchange orders, under the same guard chain and with a verdict journal that confirms what happened to every order. Capital stays simulated until that path proves itself; today it runs against an exchange testnet, and the site says so instead of implying otherwise. More on the project: the full development history. What I actually work on (repositories) - qrak/LLM_trader — the main project, and the one this site documents: the reasoning engine, the Numba indicator library, the vector memory, the dashboard and this website. Started December 2025, still active. - qrak/ti_numba — high-performance technical indicators built on Numba JIT, extracted as a standalone library. This is the indicator work the bot runs on. - qrak/DiscordCryptoAnalyzer — the earlier Discord bot that analysed crypto markets and posted to a server. The precursor to the current project; less maintained, kept public for the history. - Everything else on my GitHub is older experiments and tools, and I would rather say that than pad the list. How I work - Tests before claims. The suite is at 1,549 tests (1,532 passing, 17 skipped) and runs in under a minute — python -m pytest tests -q. Numbers on this site come from that run, not from memory. - A changelog with the ugly parts in it. Decisions, reversals and the "this aged badly" notes are in the public CHANGELOG.md, including a brain-learning reset after a losing streak. - Corrections in public. When the site claims something the code no longer does, the page changes and the old claim stays visible in the story's errata section. Open to work I'm looking for a role as a backend developer (Python/FastAPI) or AI/LLM engineer — ideally where I can apply both my AI knowledge and backend skills, in Wrocław or remote. No university degree — but the work is public: a repo with 1,549 tests you can run yourself, a live dashboard you can inspect right now, and a codebase whose history is fully documented. Contact Email: contact@qrak.org · GitHub: @qrak · Discord: community server ============================================================================== ## Contact URL: https://qrak.org/contact/ ============================================================================== Contact Contact Questions about the project, the code, or the development process — I read everything. Email The fastest way to reach me: contact@qrak.org. I typically reply within 1–2 business days. Community & Code - GitHub: github.com/qrak — the full source lives in qrak/LLM_trader - Discord: join the community server — build questions, bug reports, feature ideas - Live dashboard: semanticsignal.qrak.org — watch the bot's decisions in real time Support the Project This is an open-source project built in spare time. If it's useful to you, you can buy me a coffee. Business / Collaboration For collaboration, sponsorship, or employment inquiries, please use contact@qrak.org with a clear subject line. I'm open to backend/AI engineering opportunities in Wrocław or remote. ============================================================================== ## Risk disclaimer URL: https://qrak.org/disclaimer/ ============================================================================== Risk Disclaimer · Last updated: September 19, 2026 Risk Disclaimer Please read this before acting on anything shown on this site. Not Financial Advice Semantic Signal is an experimental, open-source software project created for engineering and educational purposes. Nothing on this website — including the project description, the code, the dashboard, or any articles — constitutes financial advice, investment advice, or a solicitation to buy or sell any asset. This Is Not a Money Machine The system is an LLM reasoning experiment. It is not guaranteed to be profitable, and it can and will lose money. It has lost money on paper during development (the changelog documents a brain-learning reset after a losing streak, and the development history discusses it openly). Real-money execution is not enabled: the pipeline trades simulated capital by default, and the separate executor service runs against an exchange testnet (sandbox) — no real funds are at stake anywhere in this project. Live trading stays disabled until the system proves itself over a sustained period. Paper Results ≠ Live Results Results shown on the dashboard are simulated (paper) results. Paper trading does not involve real order execution: no slippage, no partial fills, no liquidity constraints, no exchange outages. Historical or simulated performance is not a reliable indicator of future results. Trading Risk Trading cryptocurrencies carries substantial risk, including the loss of your entire capital. Markets are volatile and can move against you faster than any automated system can react. Never trade money you cannot afford to lose, and never rely on an automated system without understanding its logic. No Fiduciary Relationship Use of this site or the software creates no advisory, fiduciary, or professional relationship with the developer. You are solely responsible for your own trading decisions. ============================================================================== ## Privacy policy URL: https://qrak.org/privacy-policy/ ============================================================================== Privacy Policy · Last updated: September 19, 2026 Privacy Policy This policy applies to qrak.org and all pages under this domain. 1. Who Operates This Site This site is operated by Piotr Kurnicki (@qrak), Wrocław, Poland. Contact: contact@qrak.org. 2. Data We Collect This site is a static, read-only website. It has no user accounts, no forms, and no newsletter. We do not directly collect, store, or process any personal data from visitors. Third-party services used by this site may process technical data automatically: - Cloudflare (CDN, DNS, security) — processes IP addresses and request metadata as part of standard web delivery. - Google Fonts — loads fonts from Google servers; Google's privacy policy applies to that request. - Google AdSense — if/when ads are displayed, Google and its partners may use cookies or device identifiers to serve and measure ads. See section 4. 3. Cookies This site does not set first-party tracking cookies. A small cookie-consent preference is stored in your browser's local storage when you accept or decline the cookie notice. Third-party services (Cloudflare, Google AdSense) may set their own cookies as described in their privacy policies. You can control or delete cookies through your browser settings at any time. 4. Advertising (Google AdSense) This site may display ads served by Google AdSense. When ads are displayed: - Google, as a third-party vendor, uses cookies (including the DoubleClick DART cookie) to serve ads based on your visits to this and other websites. - Google's use of advertising cookies enables it and its partners to serve ads based on your prior visits to this site and/or other sites on the internet. - You can opt out of personalized advertising by visiting Google Ads Settings. You can also opt out of third-party vendors' cookies via www.aboutads.info. Current state: no advertising script is loaded on this site today. This section exists because AdSense is planned; if ads ever go live they will be gated behind the cookie-consent banner, and this page will say so. 5. Your GDPR Rights If you are located in the European Economic Area (EEA) or the UK, you have the right to: - Access, rectify, or erase personal data concerning you; - Restrict or object to processing; - Data portability; - Withdraw consent at any time; - Lodge a complaint with your local supervisory authority (in Poland: UODO). Because this site collects no personal data directly, most of these rights are already satisfied by design. For any privacy question, contact contact@qrak.org. 6. Changes to This Policy This policy may be updated as the site evolves. The "Last updated" date at the top of this page reflects the current version.