I want to sit in a cafe, open the laptop, point OPENAI_BASE_URL at the box at home, and have the coding agent work exactly as it does at my desk. Nothing about the model, the harness, or the evals should notice it moved.

That’s the whole goal. The reason it isn’t trivial is the promise the rest of the setup rests on – nothing leaves the local network (see the first post, wher eI put a coding agent on a spare box and the second where I gave the household a chat UI).

The honest version of the goal now isn’t “nothing leaves the LAN”. On a cafe wifi my prompts must cross the public internet. What I still control is who is in the path. So the property to preserve is narrower and more defensible: end-to-end encryption between two machines I own, with no third party able to read it, hold it, or replay it. Self sovereignty basically.

What the network is doing

Before choosing anything, I ran two commands:

curl -4 -s ifconfig.me     # -> a real, public IPv4
whois <that address>

The address is nowhere near carrier-NAT space (100.64.0.0/10) – my ISP doesn’t CGNAT residential lines. So port forwarding works and I don’t need NAT traversal at all, which is what makes everything downstream cheap: a hosted mesh service earns its keep by punching through carrier NAT, and I don’t have any.

The RIPE record lists the range as dynamic xDSL. Like anyone who isn’t paying their ISP for a static address, I don’t have one – what I have is a sticky address: unchanged for months at a time, contractually dynamic, free to move on any modem reboot or line resync.

There’s also native IPv6 on the line, a whole /64. Tempting – no NAT at all. But cafe wifi is frequently IPv4-only, and an endpoint you can’t reach from the network you’re actually sitting on is worthless. IPv6 goes in the drawer for now.

The failure mode that makes DDNS non-optional

Sticky-not-static sounds like a footnote. It’s the one genuinely bad failure in the design: while abroad, the line resyncs, the home IP changes, client config hardcodes the old endpoint, and fixing it requires knowing the new IP – which requires access to the hone LAN. Chicken and egg. And because the IP is sticky, this happens rarely enough that you’ll more than likely have completely forgotten it’s possible by the time it bites you.

So: dynamic DNS, via deSEC – a Berlin-based non-profit, open source, DNSSEC by default. A third party, but a precisely-bounded one: it learns an IP and a hostname, and no traffic flows through it.

Two gotchas, both of which only bite when you can’t debug them:

• wg-quick resolves Endpoint once, at interface start, and never re-resolves. DDNS alone changes nothing for a live tunnel.
• Delete the AAAA record on purpose. The box has native IPv6, so the updater would happily publish one, and wg-quick might then resolve the endpoint to v6 – which works beautifully at home and fails on IPv4-only cafe wifi. curl -4 plus an empty myipv6= forces v4 and drops the AAAA.

Why WireGuard

With NAT traversal off the table as a requirement, the field narrows to one obvious answer, and every property I wanted falls out of it:

• No daemon and no account. WireGuard is in the kernel, about 4k lines of it. Nothing runs as root on my behalf, nothing phones a control plane, nothing rewrites my iptables behind Docker’s back.
• No third party at all. Keys are two files I generate. Nobody brokers them and nobody sees the metadata.
• Invisible to scanners. An unauthenticated packet draws no reply – not a refusal, nothing. The port may as well not exist unless you hold the key.
• Split tunnelling for free. AllowedIPs = 10.10.0.1/32 routes only the tunnel’s own address, so a commercial VPN can stay on alongside it.

The design, and the invariant that makes it cheap

The thing that keeps this small: llama-server doesn’t change at all. It stays bound to 127.0.0.1:8080, never bound to any network interface, mesh or LAN. WireGuard doesn’t expose the model – it makes weebeastie’s SSH reachable, and the existing SSH tunnel does the rest.

travel laptop (café)                     weebeastie (home)
                                           wg0 10.10.0.1  ◀── UDP 51820 forwarded
  qwen-code                                    │
  OPENAI_BASE_URL=localhost:8080/v1            ▼
        │                                    sshd  ◀── LAN + wg0 only; :22 NOT forwarded
        ▼                                      │
  ssh -fN -L 8080:127.0.0.1:8080  ═══════▶  127.0.0.1:8080  llama-server

The tempting shortcut is to bind llama-server to the WireGuard interface and skip SSH. That would mean the model needs its own auth – llama.cpp’s --api-key is a bearer string in a config file, not a credential system – and it puts an unauthenticated inference endpoint one firewall mistake away from the LAN. Going through SSH means the auth is a keypair that already exists, the encryption is doubled, and the loopback-only property from the first post survives untouched.

Port 22 is deliberately not forwarded. WireGuard is the front door; SSH lives behind it. An unauthenticated WireGuard packet gets no reply at all – the box is invisible to internet-wide scanners.

Most tutorials will also tell you to enable ip_forward and add a MASQUERADE rule. Don’t – those are for using the box as a gateway into your LAN. Here the tunnel’s only destination is the box itself, so packets terminate at the interface and the blast radius stays at one host.

The trap: never test this from your own LAN

The obvious test is: laptop on the LAN, dial your own public IP, see if it works. This fails – not because your config is wrong, but because most consumer routers don’t implement NAT loopback (hairpinning), so packets from inside addressed to the WAN IP just die. You get a false negative and go hunting a bug that doesn’t exist.

In order to test it on LAN connect the laptop to a commercial VPN, and bring the tunnel up: your packets exit at its node and re-enter your router from the real internet, so the port-forward gets exercised on the real path with no hairpin involved.

If you want a surefire test use a phone hotspot, since your carrier almost certainly CGNATs you.

Using it

The whole thing collapses into a Makefile target. away re-points REMOTE at the WireGuard peer using a target-specific variable. It’s deliberately explicit rather than a boot-time service: the endpoint is my home public IP, and since my router doesn’t hairpin, a tunnel that came up automatically would be permanently broken at home – which is where the laptop mostly lives. make away pings the peer and tears itself down in 3 seconds if you’re not actually away.

make tunnels      # at home -- straight over the LAN
make away         # outside -- WireGuard up, then the same tunnels over it
make wg-status    # endpoint / handshake / transfer
make away-stop

Everything downstream is untouched. Same OPENAI_BASE_URL, same env vars, same eval gate, same qwen -p artichoke smoke test. From the client’s point of view localhost:8080 is localhost:8080 – the harness genuinely cannot tell it isn’t home.

Where it stands

The box now answers from anywhere, and the model is exactly as private as it was on day one: bound to loopback, never on a network interface, reachable only through a keypair I hold. sshd is key-only, root login off, port 22 not exposed to anything. The front door is a UDP port that doesn’t answer strangers.

Configs, the Makefile and the design doc are in the repository.

Previously I described how I deployed a coding agent running entirely on the home LAN – a spare box, codenamed weebeastie, serving mid-range Qwen3-Coder-30B-A3B model over llama-server, reached from a laptop by Qwen-Code through an SSH tunnel.

I wanted to make the same model usable by e.g. spouse, hence these two additions, both guaranteeing the same self-sovereign posture (loopback-bound, nothing leaves my LAN):

1. A chat UI for everyone. Open WebUI in a container, so any phone, tablet or laptop browser on the LAN gets a ChatGPT-style window onto the local Qwen – with per-user accounts and per-user memory.
2. A grounded document assistant. A retrieval-augmented-generation (RAG) server over European Parliament committee documents, built primarily for my spouse’s work.

The interesting design decision is that the RAG isn’t bolted onto the chat, even though Open WebUI comes with some RAG capabilities. Instead it is a shared RAG server spoken to over MCP, so that the same server can be used both by the household chat and my coding agent.

That is because eventually more collections will be indexed in the RAG db - e.g. my notes, household documents, TODO list, vacay plans …

The chat

The whole security story from last time was that the inference port never touches the LAN – llama-server binds 127.0.0.1:8080 and is only reachable over an SSH tunnel. Adding a web UI must not break that.

Open WebUI runs in Docker with network_mode: host. The UI container reaches the model over loopback and exposes its port 3000 to the LAN, making it visible on 192.168.1.22:3000. The llama-server port stays as private as before.

On the left, the chat at 192.168.1.22:3000 answering from Qwen3-Coder-30B-A3B-Instruct-IQ4_XS; on the right, logs on weebeastie showing the request stream through the model’s slots – ~100 tokens/s of prompt eval, ~19 tokens/s generated.

A few decisions made along the way:

• Reboot survival for free. Just a docker container with restart: unless-stopped means the chat auto-returns.
• Fixed accounts, signup locked. Three accounts (me as admin, spouse, a shared guest), ENABLE_SIGNUP=false. Separate accounts give separate, per-user memories automatically.
• Sandbox gap. The model only turns tokens into tokens; any code it emits runs in the viewer’s browser (WASM/pyodide), not on weebeastie; the container isolates filesystem and processes. The deliberate hole is that host networking removes network isolation, so I keep the dangerous switches (server-side code execution, admin-installed tools) off and apply the cheap hardening (no-new-privileges, cap_drop: ALL).
• Only one thing leaves the LAN, and only on consent. Web search via Exa is on, behind an explicit per-query confirmation. Version checks, telemetry and community sharing are all off.

The RAG MCP server

The document assistant is a Rust pipeline: fetch EP committee PDFs from the Open Data Portal, parse, chunk, embed and upsert into a Qdrant vector database, also hosted locally. Each query is then embedded under the identical recipe as at the insert time, top-k passages are pulled, and the local Qwen is asked to answer using only those passages, citing each one, or saying “I don’t know.”

In my first version the RAG was packaged as an OpenAI-compatible model (retrieval and generation coupled together) – a second entry in the chat’s model dropdown that owned the whole loop (embed → Qdrant → ground → call the generator → cited answer). It worked, but it welded retrieval to this one specific generator. So eventually it got re-cast as a shared MCP retrieval server, ep-rag-mcp, attached to the host (the thing running the agent loop), not to the model server.

llama-server is just a text generator with no MCP client. The decide-to-call → dispatch → feed-back cycle lives above the model, in the host. So the two hosts – Open WebUI and Qwen-Code – each hold their own MCP client, both point at the same retrieval server, and both independently use llama-server as their generator. The win is loose coupling: retrieval is implemented once and reused; the generator stays a swappable dropdown in the chat.

Only :3000 faces the LAN. :8082 (MCP), :6334 (Qdrant) and :8080 (the model) all stay loopback. ep-rag-mcp is deployed exactly like llama-server – a loopback systemd unit, Restart=always, enabled at boot.

Tool call routing: native tool-calling vs. classify-then-answer

The household model needs a way to decide whether a message even needs the RAG.

Both paths start from the same artefact: a small decision tree expressed as JSON, versioned and auditable, whose node questions are natural language the model evaluates (“Is the user asking a substantive question about the content or positions of EMPL/REGI/IMCO committee documents?”). Two ways to consume it are:

• Mode A – native tool-calling. Hand the model the tree as policy plus a search_ep_committee_docs tool, and let it emit a tool_call when it decides to ground. One turn.
• Mode B – walk the tree, emit a JSON decision. Ask the model to walk the tree and return a compact {"reached": …, "tool": …, "reason": …} object. The code then reads that JSON and decides. A separate classify turn before generation.

I was not sure if a smaller model like Qwen-30B will be able to reliably answer in Mode B (although prefferable, given one less model turn).

So I just ran both against the same 10 labelled queries – 4 in-domain EP questions, 4 clearly off-topic (including a carbonara recipe), and 2 deliberately hard “generic-EU-fact” borderline cases (“Who is the current President of the Commission?”) that look on-topic but should not hit the document index:

The read: Qwen can obey the tree flawlessly when asked to reason through it explicitly (B). Native tool-choice (A) short-circuits that reasoning – it pattern-matches “EU institution → call the EU tool” and skips the walk, over-firing on exactly the borderline questions where restraint matters. This tracks, as the Open WebUI’s own docs warn that small local models are unreliable at native tool-calling, and Qwen-30B sits right at the border of a small and a medium model.

So the household path pays a ~2.5-second classify turn to buy a 10/10 vs 8/10 routing score, and does it deterministically – the model never emits a tool_call in the chat; the code decides from parsed JSON, so the routing is as reliable as the classifier and all the grounding logic lives in one place in Rust (“code is law”). For a spouse asking policy questions, correct-and-a-bit-slower beats fast-and-occasionally-wrong.

Answer and a citation, chunk directly from the Qdrant db:

Where it stands

The box that used to just autocomplete my code now has a face the whole household can talk to from any device, a per-user memory, and a grounded, cited answer path over real EP committee documents – all still behind a single LAN-facing port, with the model itself as private as the day it was set up. Setup, the Rust RAG crates, and the routing spike are in the repository.

Commercial coding assistants ship your keystrokes to someone else’s datacenter. That is a fine for most people; but if the whole point is self-sovereignty – keeping your code, your prompts, and your family’s chatbot traffic on hardware you physically own there are now alternatives. Vitalik’s Secure LLMs makes the case for a local-first inference, open weights, and sandboxing everything. Sebastian Raschka’s Using local coding agents showed it is now quite practical – a small mixture-of-experts model with only a few billion active parameters is enough to drive a real agent loop.

So the goal for this project: an agentic coding assistant, plus a household chat frontend, that never leave the local network.

One strongish box, many thin clients

I already have a spare desktop – an i9-10850K with 64 GB of RAM and a modest GTX 1050 Ti codenameweebeastie. The idea was to make it the household’s inference engine: it holds the model and does the heavy lifting, while laptops, phones, and tablets on the LAN are just thin clients talking to it.

laptop / phone / tablet                        weebeastie  192.168.1.22
  coding harness   ──ssh tunnel──▶ localhost:8080 ──▶ llama-server (llama.cpp)
  local git repos                                     Qwen3-Coder-30B-A3B  (GGUF)

A couple of hardware realities that shaped everything downstream:

• The CPU is the real inference engine, not the GPU. 4 GB of VRAM is by far too little to hold a 30B model’s experts, so the expert layers live in RAM and run on the 10 cores. The GPU earns its keep only by accelerating attention.
• Generation is memory-bandwidth-bound. With ~45 GB/s of dual-channel DDR4, token throughput is essentially set by how many bytes you read per token.

llama-server from llama.cpp does the serving: selected mainly because it has every CPU/GPU knob you might think of. It stays bound to loopback address on the remote and is reached over an SSH tunnel – the inference port is never actually on the LAN.

Picking the harness: Qwen-Code

The harness is the agent loop – the thing that reads files, calls tools, runs commands, and feeds results back to the model. It matters as much as the model, harnesses differ very sharply in how they treat tool calls and in turn how many tokens they burn (e.g. Raschka notes Codex is frugal, Claude Code is the most token-hungry).

I went with Qwen-Code for two reasons. Firstly it plays nicely with llama-server, talking to it directly with no proxy required. Second it is tuned for the Qwen model family – which is exactly the model family the hardware pushed me toward.

Choosing the model family, then sweeping it

The harsh truth is my modest hardware at the moment rules out most of the field. A 355B-class model or a dense 70B simply will not fit in 64 GB The one path to a responsive agent on this box is a small-active-parameter MoE – e.g. Qwen3-Coder-30B-A3B-Instruct with 30B total parameters but only ~3B active per token, coder-specialized, and well-supported in GGUF.

So that fixes the family. The open question was which quantization and serving config gives the most tokens/second without the model getting measurably worse at coding. Since generation scales with bytes-read-per-token, a smaller quant should be strictly faster – as long as it still “codes correctly”.

For such tasks, requiring a time-consuming-yet-repetetive sweep over parameters I’ve enjoyed good experience offloading them to the autoresearch loops. So I instructed an agent to do an overnight sweep, benchmarked with llama-bench at a realistic 16k context depth, and measured every candidate with a coding quality eval supplied by Raschka’s local-coding-agent-evals.

Results below:

This table is almost monotonously consistent with one hypothesis: the only lever that ever moves the generation speed is the size of the expert weights you read per token. Dropping from Q4_K_M to IQ4_XS (4.25 bits per weight, 15.25 GiB) buys a clean +5% and uses less VRAM – while scoring identically on the coding eval. Everything else – KV-cache quantization, GPU expert offload, more threads, even speculative decoding with a vocab-compatible draft model – lands within noise. Note that this finding is for my harware, and will more than likely differ, so I just present it as the methodology more than actual open-weighted model recommendation.

Setup instructions

Setup instructions, eval and code published in the repository.

Perhaps a truism but markets behave differently in different regimes: a momentum strategy that works in 2021 stops working in mid-2022. If you want a principled label for “what kind of market is this, right now” evaluated systematically then the obvious tool is a Hidden Markov Model. Textbook since Hamilton applied Markov-switching to the US GNP (Hamilton, 1989). The hard part is what data to feed it.

In this post I argue that for cycle-aware crypto regime detection on daily BTC candles, the right observation is drawdown from the running all-time high:

It’s strictly causal, bounded above by zero, mean-reverts to zero on new highs, and – importantly – it encodes where in the cycle you are without breaking the stationarity assumption. We fit a vanilla 3-state Gaussian HMM to this single number and the latent states line up with what a trader would call a bear, a chop, and a bull, with no hand-labelling and no look-ahead.

The model lives at /regimes/ as a live dashboard, updated daily.

TL;DR On BTCUSDT daily, 2021-06 → 2023-06, a 3-state Gaussian HMM on drawdown from rolling max produces a median bear-state posterior of 1.00 over all of calendar 2022 and exactly one Viterbi flip that year. The bull leg (2021-06 → 2021-10) classifies 100% bull; calendar 2022 is 55% bear / 45% ranging / 0% bull; the 2023-H1 recovery is 59% ranging / 41% bear / 0% bull. Every window matches historical consensus labels. Student’s-t emissions collapse to Gaussian at this feature scale ($\nu$ saturates at the upper bound), so the shipped model is the simpler one.

A short tour of HMM regime models

HMMs in finance have a fairly settled toolkit. EM for HMMs has been used since Rabiner (1989), and the interesting axis of variation are the observation and the transition structure, not the inference machinery itself.

Hamilton (1989) introduced the Markov-switching autoregression for U.S. GNP growth: a $K=2$ model where the observation is the growth rate and the latent states are labelled “expansion” and “recession”. The subsequent literature varies different observations, different K, sometimes time non-homogenous transitions.

For crypto specifically, four papers map the space:

• Koki, Leonardos, Piliouras (2020) fit a Bayesian $K=4$ NH-HMM to the daily percentage log-returns of BTC / ETH / XRP (2014–2019), with Pólya-Gamma augmentation on the multinomial-logit transition probabilities. They report VIX as the dominant transition predictor (posterior inclusion probability 1.00 across all three coins), and that $K=4$ beats $K \in {2, 3, 5}$ on out-of-sample CRPS. The structural finding is the interesting part: the bull regime splits into two sub-states that share an almost identical mean and differ only in volatility – a “bull-high-vol” and a “bull-low-vol” – plus a low-occupancy “calm” auxiliary state. With $K=3$ on log-returns you cannot distinguish bull-vol from bull-quiet; EM either collapses them into one over-flipping bull or lets a heavy-tail emission absorb both via a uniformly fat tail.
• Shih, Huang, Hsu (2024) apply MS-AR(q) to weekly BTC (2018–2022) with $K=2$ and Gaussian shocks. VIX and the USD index enter the mean equation (not the transitions matrix). The high-$\sigma$ “bear” state has $\sigma \approx 0.053$ vs $\sigma \approx 0.007$ for the bull – a $7.5\times$ ratio – and weekly aggregation does most of the work that a heavier emission family would have to do at the daily scale.
• Pakštaitė et al. (2025) do full Bayesian MCMC on daily BTC with a $K=2$ NH-HMM, but the observation is log-transformed scaled price (a price level, not a return). They use a Pólya-Gamma logistic transition with MCMC covariate selection over 16 macro / on-chain predictors, fit on a 100-day rolling window chosen explicitly to match a typical regime duration of 30–60 days.
• Malekinezhad & Rafati (2026) push to 4-hour BTC (2024–2026) with a multivariate observation vector $(r_t, \sigma_t^{\mathrm{RV}}, v_t)$ – log-return, rolling realised volatility, normalised volume – and $K=3$ NH-HMM with locally-varying transitions.

Two patterns stand out:

1. The default observation is log-return (or a growth rate, going back to Hamilton on US GNP) – stationary, well-studied, and what most off-the-shelf finance HMM pipelines feed in. A smaller strand of the literature instead models a level – log-price, optionally scaled or detrended (Pakštaitė et al., 2025).
2. The interesting extensions go in two orthogonal directions: enrich the observation (Pakštaitė: log-price level; Malekinezhad: multivariate channels), or enrich the transitions (Koki: covariate-driven NH-HMM, VIX dominant).

The standard observation has a known structural problem on crypto: it conflates “going down” with “high volatility”, and $K=3$ isn’t enough to encode the bull-vol vs bull-quiet split. The natural responses are Koki’s $K=4$ (more states) or Malekinezhad’s multivariate emission (more channels per state).

In this post we take another approach: keep $K=3$ (for operational reasons), keep the homogeneous transition matrix, keep univariate Gaussian emissions – and change the observation to something that carries cumulative cycle information without secular drift.

The stationarity problem

The log-return as the observation, although established in the literature, has its own failure mode: namely a return is local. What we mean by that is that a single -3% day in a bull market and a single -3% day in a bear market are indistinguishable to the emission.

Discrimination has to come from volatility – bear regimes are detected because their conditional return variance is higher. This works (it’s why the literature settled here) but it conflates “the market is going down” with “the market is volatile”, which is only sometimes the same thing. A long, slow grind down at low volatility – which is what late 2022 looked like once the FTX shock cleared – doesn’t separate well from a sideways chop on log-returns.

Concretely: In an early experimen fitting a 3-state Student’s-t HMM to BTC daily log-returns over 2021-06 → 2023-06 placed 100% of 2022 into a single “ranging” state, with $\hat\nu$ collapsing to the lower bound of $3$ in every state. The model was correctly reporting that daily 2022 returns look like a fat-tailed walk near zero – statistically indistinguishable from any other post-2021 window.

The diagnosis pointed to two structural fixes:

1. More states – Koki’s $K=4$, which gives EM somewhere to send the calm days and lets the bull split into vol vs quiet.
2. A more informative observation – something the latent state can anchor to cumulatively, not just per-day.

Pakštaitė et al. reached for the 2-nd and used the level: scaled log-price. Their approach validates a broader claim that “regime structure lives at the cumulative-price level, not at the per-day return level”.

But log-price is non-stationary – BTC’s log-price has a positive secular drift and a multi-year cycle on top of it. An HMM fit on raw log-price tends to detect “year 1 vs year 2 vs year 3” as the latent state; “bear” becomes “early in the window”.

So the candidate observations split:

Log-return is stationary but cycle-blind. Log-price is cycle-aware but breaks the HMM’s stationarity assumption.

Using drawdownp threads both: it’s bounded above by zero, it reverts to zero whenever a new running ATH is made, and it sits deeply negative throughout sustained drawdowns. It carries cycle information without secular drift.

It’s not strictly stationary in the textbook sense – consecutive $d_t$ values are serially correlated through the running max, which only ever moves up – but it satisfies the property the HMM actually cares about: the marginal distribution of $d_t$ in a long bear looks the same regardless of which bear.

The fit

The recipe:

1. Compute $d_t = \log(p_t) - \mathrm{cummax}(\log(p_t))$ on BTCUSDT daily closes.
2. Fit a $K$-state HMM with Gaussian (and, separately, Student’s-t) emissions via Baum-Welch.
3. K-means warm start, 5 random restarts, keep the best log-likelihood.
4. Decode with Viterbi for the hard label; keep the forward-backward posterior for the soft one.
5. Sort states by ascending $\hat\mu$ and name them bear $\to$ ranging $\to$ bull ($K=3$) or bear $\to$ bull ($K=2$).

Window: 2021-06-01 → 2023-06-30 (covers the 2021 bull leg, the 2022 bear, and the early 2023 recovery – three regimes you’d want a regime detector to definitely find).

We fit four models: Gaussian and Student’s-t at $K \in {2, 3}$. The pass criterion was stated upfront, before looking at any fit:

• Median bear-state posterior over calendar 2022 $\geq 0.6$.
• Viterbi flip count over calendar 2022 $\leq 6$.
• For Student-t vs Gaussian: median-bear-posterior gap $\geq 0.15$ or flip-count reduction $\geq 30\%$.

Does it match what a trader would label?

All four models pass criteria 1 and 2 trivially. The $K=3$ Gaussian fit is the cleanest.

Fitted emission parameters ($K=3$ Gaussian, 2021-06 → 2023-06):

The means form a near-evenly-spaced grid on the drawdown axis with comparable $\sigma$ across states. EM doesn’t have to fight a single dominant distribution for variance share – which is what you see in $K=3$ fits on log-return, where the “high-vol” state usually swallows all the interesting structure.

Calendar-2022 metrics (the pass-criterion window):

Median bear posterior of 1.00 means: on the typical day in 2022, the model is essentially certain we’re in the bear state. One Viterbi flip across the entire year means it doesn’t oscillate. The $K=2$ versions absorb the recovery rallies into “bull” because there’s nowhere else to put them; $K=3$ correctly classifies the rallies as ranging and reserves “bull” for actual proximity to ATH.

Per-window Viterbi composition ($K=3$ Gaussian):

Three windows, three textbook labels, and the model – which never sees those labels – reconstructs each one:

• The 2021 bull leg is 100% bull. Price is making new ATHs continuously; $d_t$ around zero.
• The 2022 calendar year is 100% non-bull (55% bear, 45% ranging), with the ranging mass concentrated in the late-summer recovery rally before the FTX collapse pulled it back to bear.
• The 2023 recovery is 59% ranging, 41% bear, 0% bull. The bear mass is January-February (still near the cycle bottom); the ranging mass is March onward (rising off the low but still ~60% below the cycle ATH).

A level-anchored feature would get the 2023 recovery wrong: full-window z-scored log-price would label rising-but-below-mean days as “bear”, because “bull” for that observation just means “above the window mean”. Drawdown puts the threshold where a trader puts it – at the running ATH.

One unexpected result: Student-t collapses to Gaussian. The fitted $\hat\nu$ saturates at the upper search bound ($30$) in every state, in every $K$. At this feature scale – $\sigma \approx 0.1$–$0.2$ log-units, observations bounded above by zero – there are no outliers far enough from any state’s $\mu$ to warrant heavy tails.

What the model still misses

1. The Gaussian violates the hard upper bound $d_t \leq 0$. For the bull state ($\hat\mu = -0.13$, $\hat\sigma = 0.11$), the fitted Gaussian assigns ~12% probability mass above zero, where the true density is exactly zero. No observations actually fall above zero, so the likelihood is unaffected – but a window dominated by frequent new ATHs would push the model to inflate the bull-state $\sigma$ to absorb mass piled at the boundary. A principled fix is a truncated Gaussian or a Beta on $-d_t$.

2. Serial correlation through the running max. $\mathrm{cummax}$ is monotone non-decreasing, so consecutive $d_t$ values are correlated through the max. This violates the HMM’s conditional-independence assumption. It’s the standard approximation in regime-detection on cumulative features (every implementation of MaxDD-based regime detection makes the same compromise) so we are not too worried here, but what it means is that the log-likelihood should be read as a relative goodness-of-fit signal rather than a calibrated probability.

3. Slow exits from bear. The bear state ends when $d_t$ climbs back toward zero – which requires the price to approach the running ATH from below. A multi-year recovery that ends in a new ATH gets correctly classified as ranging → bull. A V-shaped recovery that doesn’t re-make the ATH stays in ranging indefinitely, which is technically correct but conservative.

4. Pure depth signal. No volume, no funding, no on-chain signals. The model is making strong calls from one number, which is the appeal – but it also means it has no view on, e.g., the difference between a low-volume drift down and a high-volume capitulation flush.

The live dashboard

The same recipe, re-fit over the full 2017-08 → today window, drives the public dashboard at /regimes/.

The dashboard surfaces:

• Today’s posterior $P(\mathrm{bear})$, $P(\mathrm{ranging})$, $P(\mathrm{bull})$ as bars.
• The one-step-ahead distribution $\pi_t \cdot A$.
• The full posterior tape over price history.
• Zoomed-in panels for four named episodes (2018 bear, COVID Q1 2020, 2020-21 bull, 2022 bear) with brief context on each.
• The fitted emission parameters and transition matrix.

It’s not a trading signal – it’s a regime tape, to build trading signals on top of.

What’s next

The lit-review-aligned roadmap is the trinity emission + VIX-in-transitions assembled model, built in stages. The governing principle is a clean split:

Emission channels are things the regime produces. Transition covariates are things the regime responds to.

Daily returns, realised volatility, and drawdown are all produced by the underlying regime – they belong in the emission. VIX, the USD index, and Treasury yields are macro stress signals that drive regime crossings – they belong in the transition. Paper 1 puts VIX in the mean equation; paper 3 puts it in transitions and gets a posterior inclusion probability of 1.00 across three coins.

Ranked by expected information gain per effort:

1. $K=4$ on drawdown alone. Koki et al. report BTC daily-return regime structure resolves to four states. On drawdown, $K=4$ might split the bear into “deep capitulation” vs “approaching ATH from below”, or split the ranging. Cheapest sanity check.

2. Bivariate $(d_t, r_t)$ then trivariate $(d_t, r_t, \sigma_t^{\mathrm{RV}})$. Brings the per-day signal back as a second channel and the realised-volatility signal as a third. The state binds to “where in the cycle” (drawdown), “what happened today” (return), and “how violently” (realised $\sigma$). This is the lit-review’s recommended setup. Realised volatility can be upgraded from a noisy 5-day return-std estimator to intra-day-aggregated realised variance (Andersen-Bollerslev-Diebold-Labys (2001)) at the cost of one Binance klines call, with no change to the HMM frequency.

3. NH-HMM with VIX in transitions. The literature-aligned top of the stack (papers 2, 3, 4 all agree). Softmax-parameterised transition matrix $\log A_{ij}(t) = \mathrm{softmax}j(\beta{ij} \cdot x_t)$ with $x_t = (1, \mathrm{VIX}_t)$. M-step is a per-iteration logistic regression.

4. Fixed-lookback rolling max for $d_t$. The current fit uses an expanding cummax over the full window, so $d_t$ never forgets the 2021 ATH and the bear state implicitly anchors to a specific historical peak. Swap to a true rolling max with lookback $L$ (e.g. $L = 200$ days, matched to the bear-regime duration we’re trying to detect): bounded memory, strictly stationary, and the model stops binding state identity to “how far we are from the ATH” and starts binding it to “how far we are from the recent ATH”. Cheap to implement; the trade-off is shorter $L$ is more responsive but loses the deep multi-quarter bear signal, longer $L$ preserves it but slows edge response. $L$ is a natural candidate for a parameter sweep – e.g. $L \in {60, 100, 200, 365, \infty}$ scored by the existing pass criteria (median bear-posterior in 2022, Viterbi flip count) – which would replace the current judgement call with a principled out-of-sample choice.

Glossary

• VIX – CBOE Volatility Index. The implied 30-day volatility of S&P 500 options, in annualised percentage points. Widely used as a “fear gauge”; spikes during equity stress (2008, March 2020) and tends to lead or coincide with risk-off regimes across asset classes, including crypto.
• HMM (Hidden Markov Model) – A model where observations $y_t$ are drawn from a state-dependent distribution conditional on a latent discrete state $z_t \in {1, \ldots, K}$ that evolves as a first-order Markov chain. The states are not observed directly; they are inferred from the observations.
• Emission distribution – The conditional distribution $p(y_t \mid z_t = k)$. In this post each state’s emission is a Gaussian (or Student’s-t) over the drawdown observation.
• Transition matrix $A$ – The $K \times K$ matrix with $A_{ij} = P(z_{t+1} = j \mid z_t = i)$. Diagonal-heavy in regime models – once you’re in a bear, you tend to stay in a bear.
• Viterbi algorithm – Dynamic-programming decoder that returns the single most likely state sequence $\hat z_{1:T}$ given the observations and fitted parameters. Hard label per timestep.
• Viterbi flip – A timestep at which the Viterbi-decoded state changes from one regime to another. Low flip counts indicate a stable, non-oscillating fit.
• Drawdown – $d_t = \log(p_t) - \max_{s \leq t} \log(p_s)$. The log-distance from the current price to the running all-time high; always $\leq 0$, equals zero exactly when a new ATH is made.
• Log-return – $r_t = \log(p_t) - \log(p_{t-1})$. The standard finance observation: stationary, local, but cycle-blind.
• Stationarity – A time series is (weakly) stationary if its mean, variance, and autocovariance don’t depend on $t$. HMMs assume emissions are stationary conditional on the state. Log-prices fail this; log-returns satisfy it, which is why for log prices are “stationarized” to e.g. sliding window maximum drawdown.
• Secular drift – A slow, persistent trend in a time series that operates on a much longer timescale than the cyclical dynamics of interest (think decade-scale vs month-scale). BTC’s log-price has a positive secular drift from long-run adoption growth; an HMM fit directly on it tends to identify “early in the window” vs “late in the window” as the latent state rather than bear vs bull. “Secular” here is the economics sense (long-term, non-cyclical), not the religious one.
• Realised volatility ($\sigma^{\mathrm{RV}}$) – Sample volatility computed from realised returns over a rolling window (or, at higher frequency, from intraday squared returns). An ex-post estimate, in contrast to VIX which is ex-ante and implied.
• Shocks (innovations) – The random error term $\varepsilon_t$ in a time-series model, e.g. $r_t = \mu + \phi r_{t-1} + \varepsilon_t$ in an AR(1). The “new information” each period that isn’t predicted by the past. “Gaussian shocks” means $\varepsilon_t \sim \mathcal{N}(0, \sigma^2)$; “Student’s-t shocks” allow fat tails.
• Student’s-t emissions – Emission family with an extra degrees-of-freedom parameter $\nu$ that controls tail heaviness. As $\nu \to \infty$ it becomes Gaussian; as $\nu \to 3$ tails get very fat. Used when the data has occasional extreme values a Gaussian would underweight.
• Emission channels – The components of the observation vector $y_t$ that the HMM models conditional on the state. In a univariate setup there’s one channel (e.g. drawdown); in a multivariate setup there are several (e.g. $(r_t, \sigma_t^{\mathrm{RV}}, d_t)$ = return, realised vol, drawdown). Heuristic: emission channels are quantities the regime produces – things you’d expect to look different in a bear than in a bull, by definition of “regime”.
• Transition covariates – External, time-varying inputs $x_t$ that drive the transition probabilities in an NH-HMM (e.g. $A_{ij}(t) = \mathrm{softmax}j(\beta{ij} \cdot x_t)$). Heuristic: transition covariates are quantities the regime responds to – things that don’t themselves describe the regime but help predict when it will flip (VIX, USD index, 10Y yield). Putting a variable in the emission says “this is part of what the regime is”; putting it in the transition says “this is what makes the regime change”.
• NH-HMM (non-homogeneous HMM) – An HMM where the transition matrix $A_t$ depends on time-varying covariates (e.g. $A_{ij}(t) = \mathrm{softmax}j(\beta{ij} \cdot x_t)$ with $x_t$ including VIX). Lets external drivers modulate regime crossings.
• MS-AR (Markov-switching autoregression) – Hamilton’s original specification: an AR(q) process whose coefficients (and/or variance) switch with a hidden Markov state. The HMM with an autoregressive observation equation.
• CRPS (Continuous Ranked Probability Score) – Proper scoring rule for probabilistic forecasts. Generalises MAE to distributions: instead of comparing a point forecast to the realisation, it compares the full predictive CDF $F$ to a point mass at the realisation $y$, integrating $(F(z) - \mathbf{1}{z \geq y})^2$ over $z$. Reduces to MAE when $F$ is a point mass. Lower is better; used to compare HMMs with different $K$ out-of-sample.
• Pólya-Gamma augmentation – A latent-variable trick (Polson, Scott, Windle 2013) that makes logistic / multinomial-logit likelihoods conjugate to Gaussian priors. Lets you Gibbs-sample over Bayesian logistic regressions; used here for the NH-HMM’s softmax transition parameters.

References

• Hamilton, J. D. (1989). A new approach to the economic analysis of nonstationary time series and the business cycle. Econometrica 57(2), 357–384.
• Rabiner, L. R. (1989). A tutorial on hidden Markov models and selected applications in speech recognition. Proceedings of the IEEE 77(2), 257–286.
• Andersen, T. G., Bollerslev, T., Diebold, F. X., Labys, P. (2001). The distribution of realized exchange rate volatility. Journal of the American Statistical Association 96, 42–55.
• Koki, C., Leonardos, S., Piliouras, G. (2020). Exploring the predictability of cryptocurrencies via Bayesian hidden Markov models. Daily percentage log-returns on BTC/ETH/XRP (2014–2019), $K=4$ NH-HMM, Bayesian MCMC with Pólya-Gamma augmentation. VIX (PIP 1.00) and 10Y Treasury yield (PIP 0.90) are the dominant transition predictors; the bull regime splits into bull-vol and bull-quiet sub-states.
• Shih, K.-S., Huang, P.-S., Hsu, C.-Y. (2024). Bitcoin cycle through Markov regime-switching model. Weekly BTC (2018–2022), MS-AR(q), $K=2$, Gaussian shocks. VIX and USD index as mean-equation covariates (not transitions). High-$\sigma$ state $\sigma \approx 0.053$ vs low-$\sigma$ state $\sigma \approx 0.007$.
• Pakštaitė, V. et al. (2025). Bayesian MCMC HMM and NH-HMM for BTC with macro covariates. Daily BTC (2016–2024), $K=2$, observation is log-transformed scaled price (a level, not a return). Pólya-Gamma logistic transitions, MCMC covariate selection over 16 macro / on-chain predictors on a 100-day rolling window.
• Malekinezhad, M., Rafati, P. (2026). NH-HMM on 4-hour BTC with multivariate observation. 4-hour BTC/USDT (2024–2026), $K=3$ NH-HMM with locally-varying transitions. Observation vector $(r_t, \sigma_t^{\mathrm{RV}}, v_t)$ = (log-return, rolling realised volatility, normalised volume).

Notebook with the full fit, plots, and the feed.json exporter: nodrama-labs/research/notebooks/regime_student_t_drawdown_2022.org. Live dashboard: /regimes/. Nothinh here is a financial advice.

In a previous post we looked at GEM market bear models, who can show a win even in a market in a adverse conditions. The bear specialist GEM model won by mostly not playing. It sat in cash for six and a half months of 2022, then entered EURUSDT once a clean uptrend emerged – with a brief rotation through PAXG (tokenized gold) in late December – finishing the window at +6.40% while BTC was down roughly 65% from its all-time high.

In this post we research a different, more aggressive strategy. Instead of a safe haven of tokens, we look at a broader spectrum. We invert the GEM filters, weight by the magnitude of the negative trend, and short the weakest tokens on Binance USDⓈ-M perps.

TL;DR On an 11-token mixed bear-market universe, the best aggressive short-mode GEM config (lin-n1-w15) returns +87.2% over May–Dec 2022 with a -27.4% drawdown, for a Calmar of 5.64 – beating the long-only bear specialist’s Calmar 4.6. Yet it loses on Calmar to a naive equal-weight short of the same universe (+57.72% returns, -16.41% max drawdown, Calmar 5.92). The single most meaningful drawdown comes from an ADA short squeeze - something that a model looking just at the daily candles cannot see coming.

From defense to offense

The bear specialist was long-only and held a single token at a time. The aggressive variant inherits the GEM ranking core, with the adjustments below.

Short mechanics on USDⓈ-M perps. A position is $(\text{quantity}, \text{entry_price})$. PnL on close is $\text{quantity} \times (\text{entry_price} - \text{exit_price})$ – gains when the price falls. Funding is paid (or received) every 8 hours; in a bear market with crowded shorts, funding is usually slightly negative for shorts, so the position accrues a small penalty each settlement. Aggregated to daily, mean funding rates over the window ranged from roughly -5% to -30% annualised across tokens.

Sign-flipped filters. The GEM core rejects positive $a_1$ candidates and requires $\text{momentum} < -\text{momentum_floor}$. The exponential model also wants $a_1 < 1$ (a compounding decline); the linear model wants a negative normalised slope. R-squared and ATR play the same roles as in the bull/bear long specialist models.

Momentum-magnitude weighting. The previous specialists weighted by inverse ATR – resulting in less exposure to the more volatile assets. For an aggressive short, we want the opposite: the strongest negative trend deserves the largest allocation. Weights are $|m_i| / \sum_{j} |m_j|$ over the top $N$ picks.

The rest – fitting window, R-squared threshold, differential rebalancing, cooldown – is identical to the bear specialist.

Experiment Setup

Window: Same May 1 – December 31, 2022 window as previously: BTC already down ~50% from ATH, Luna collapsed (May 9), 3AC liquidated (June), FTX collapsed (November). Unambiguously a bear market.

Universe: 11 Binance USDⓈ-M perpetuals, deliberately mixing fallers and outperformers over the period, such that the selector has a discrimination problem to solve.

The outperformers are the controls: a working momentum selector should not waste capital shorting them when fallers are available.

Data: daily klines and 8-hour funding history from Binance. $10,000 starting capital, 0.3% round-trip fee, 10-day rebalance cooldown.

Sweep: 32 configurations.

Experiment verdict structure: Three stages, each PASS / NO-PASS:

• Stage 1: best-config Calmar > naive equal-weight short Calmar
• Stage 2: best-config Calmar > long-only bear specialist (Calmar 4.6 from the previous post)
• Stage 3: robust across configs ($\geq$ 1/3 positive Calmar AND a dominant fit_window in the top 6 models)

Sweep Results

Top of the 32-config sweep, sorted by Calmar:

Three observations, mirroring the bear-long specialist’s findings:

1. fit_window=15 dominates the top quartile. All top six configs share w=15. Tight windows track the bear’s punctuated drawdowns; wider windows (60, 90) catch the intermittent relief rallies and the max drawdown blows out to ~50% (data not included, we refer to the notebook). Similar finding as in the previous post: the bear-long specialist preferred w=30.

2. Concentration outperforms diversification on this universe. top_n=1 produces the highest return (+87%) and Calmar (5.64). top_n=8 reduces both return (+62%) and DD (-24.6%), but the Calmar drops to 4.31. With only 7 real fallers in the universe, diluting into 5 or 8 names forces the selector to short weaker signals alongside the strongest, and that costs more in return than it saves in drawdown. The token universe is however probably too small to draw any larger conclusions from this fact. The naive model winning on overall Calmar is due to the risk diversification.

3. The choice of regression model is, again, irrelevant. lin-n1-w15 and exp-n1-w15 are within 0.2 Calmar of each other. Same pattern as the previous post: the fitting window dominates the model family.

What the winner does

The best config holds a single token at a time, rebalances every 10 days when momentum changes hands, and goes to cash when no token clears the entry threshold.

Twenty-two rebalances over 245 days. The equity story splits into two phases:

Most of the gains happen in the first seven weeks. The model catches SOL → AVAX → SOL → BNB → ETH in the May–June crash, rides each for 10 days, and exits to cash on June 30 when the momentum-cross trigger fires. It then sits in cash for sixty days through July and August – the bear-market relief rally that wiped out anyone holding shorts through the chop – and re-engages in late August.

The strategy is “catch the trend, then survive the chop.” About 30% of the window is spent in cash.

The most-shorted name was SOL at 17.6% of the window, followed by ETH, ADA, and BNB at ~8% each.

The short squeeze problem

The single meaningful drawdown comes from an ADA short squeeze.

On October 8 the model shorted ADA which at that time had a clean, 15-day downtrend. On October 18 the trend was even cleaner; momentum-magnitude weighting kept ADA at 100% of the book. On October 28 ADA was up roughly 15% from the Oct-18 reentry. The peak equity at Oct 18 was $18,817; by Oct 28 it was $16,622. ~12% drawdown in ten days, on one position.

But than what happened is a textbook short squeeze: a token already down 70% from its highs, heavily shorted (funding rates flipped to “shorts pay longs” in the days before), price ricocheting back from $0.30s to $0.40 as overcrowded shorts got liquidated, forcing even more buying.

Daily OHLCV cannot anticipate this. The price trend was clean and negative – exactly what the model is built to detect. The information that would have flagged the risk – funding rate inversion, open interest divergence, liquidation cluster proximity – is not in the kline feed.

This is the meta-finding the post is about: the model’s risk is mostly squeeze risk, and the information lives outside just the price data.

Baselines and the Stage Report

The two reference strategies on the same universe:

Stage Report:

The Stage 1 NO-PASS deserves comment, because it would be easy to read it as “the model adds nothing over a naive baseline.”, but that is not what is happening. The naive equal-weight short holds 11 tokens equally, all the way through. Its max drawdown is structurally smaller than any 1-asset short can match – the diversification across 11 names naturally limits the impact from DD events – at the cost of lower returns (+57.7% vs +87.2%). The GEM short with top_n=1 is, by construction, more exposed to token event risks (see short squeeze).

Stage 2 confirms the signal is there: the model clears the long-only bear specialist, despite carrying the big drawdown event. Stage 3 confirms the signal is clustered, not a single-config artifact: all top 6 configs share the same fit window, and 32 of 32 configurations produce positive Calmar.

Verdict: the signal is real but marginal

The headline number is good but the universe is too small to know if the strategy generalises.

At top_n=1 the model is a “find the biggest faller” oracle and pays the concentration cost. At top_n=5 and top_n=8 it dilutes into weaker signals – but only because there are only seven real fallers in the universe to begin with. A 25–35 token universe with the same top_n=5 or top_n=8 could more than likely let the diversification do its work without forcing the selector to short noise.

Defences against squeezes

Daily OHLCV cannot see ADA-style snap-backs coming. The model needs information from outside the kline feed.

CoinGlass or e.g. Hyblock offer (paid) liquidation heatmaps, but the sam esignal can be hand-built. Below are some ideas:

1. Per-token concentration cap + trailing stop. Cap any single short at 8–10% of NAV. Apply a 15–20% trailing stop from the entry-adjusted peak P&L. Pure portfolio logic, no new data pipeline. This cheap defense alone would have capped the ADA hit at roughly half of its actual DD cost.

2. Funding rate signal. Binance, Bybit or OKX all publish funding-rate history (already used in the experiment to calculate per-position cost accrual). Potential heuristic: if funding crosses above +0.05% for three consecutive periods on an asset we are short, halve the position, if it crosses +0.1%, exit the position. A crowded-short detector.

3. Intraday volume-spike + reversal exit. If a shorted name prints $\ge 3 \cdot \sigma$ volume on a green candle that reclaims the prior day’s high, exit at next bar. Requires 1h or 15m kline ingestion.

Together these cover most of what a paid liquidation-heatmap API service would.

Next Steps

Capital preservation as a strategy works – the previous post showed that. Aggressive shorting works too, with caveats – as the results of this brief experiment have shown. An interesting question is what happens when the regime detector decides how much of each to deploy.

Below some ideas:

1. Wider universe: All Binance USDⓈ-M majors that existed in May 2022. See if diversified models start to prevail.

2. Squeeze defenses: Add the funding+OI composite score and a trailing stop rules. Akin to liquidation heatmaps. Rerun the same sweep with the defenses on. If the ADA-shaped drawdown shrinks meaningfully without killing the returns, the defenses earn the keep.

3. Regime-weighted composition: connect the specialists (bull, rangin, bear-long, bear-short) to the HMM regime probabilities. Bear sub-specialist models could be blended using a tuned parameter - learned on the historical regime exposure.

In the previous post I compared exponential vs. linear regression GEM models on a hand-curated 4-token bear portfolio. The main finding from that experiment: the choice of regression model was almost irrelevant; the fitting window dominated the returns.

That experiment had two limitations:

• The universe was tiny – four hand-picked safe-haven tokens.
• The manual parameter sweep – I picked window sizes, ran the sweep code, verified the results, iterated again.

This post is about replacing the human-in-the-loop with an LLM agent following a written experimental research recipe. The agent iterates on: pick a hypotheses, edit the allowed parts of the codebase, run the experiment, score the results, keep or revert. Repeat. Human goes to sleep and wakes up to read the overnight results.

TL;DR On the full Binance + DefiLlama universe (437 tokens, 5 years), an LLM-driven autoresearch loop ran 215 configurations across 18 hours, lifted the ensemble score from -inf (every config failing under realistic fees) to 1175.2, and beat a BTC+ETH buy-and-hold baseline by a factor of 142.

Three structural findings emerged: two were genuinely new, one was a confirmation of an earlier 4-token result, but this time at scale.

The Autoresearch Loop

The pattern is borrowed from Andrej Karpathy’s autoresearch experiment. The structure is a two-file one:

• A read-only file harness.py – data loader, evaluation metric, and any constants the agent is not allowed to touch.
• A modifiable sweep.py file – the actual model and the training loop, fair-game for the agent to rewrite.

A program.md tells the agent what is the metric (the scoring function computed from the backtest output) to iterate and improve on, which files it can touch and which are off-limits. Human starts the agent and walks away.

Keeping The Loop Honest

The experiments metric is a single scalar:

where:

• \(\text{drawdown_dampener} = \frac{1}{(1 + \max(0, \text{dd} - 0.15))^{2}}\) (15% drawdown free zone, then quadratic decay)

and

\(\text{diversification_bonus} = 1 + 0.1 \cdot (1 - \text{HHI})\) (up to +10% bonus for a non-concentrated portfolio, where HHI is the Herfindahl-Hirschman index of position weights).

The terms are multiplied, which puts them in tension against each other and doesn’t allow the agent to game the metric.

If you had only the drawdown dampener, the optimal strategy is to sit in cash forever – zero drawdown. If you had only the returns term, the agent can chase any tail-risk strategy that produces a high headline number and accept any drawdown it comes with. If you had only the diversification bonus, equal-weight buy-and-hold trivially wins.

One more loop rule is a hard rejection (-inf) on either one of:

• Annualized return below -50%.
• Stress-test Calmar ratio (1.5× fees) is negative.

The hard-rejection gate adds one more tension: a config can’t game the dampener by accepting a moderate base-fee drawdown that collapses into a negative-Calmar disaster the moment slippage gets worse. Both conditions have to hold: positive expected return at the base 30 bps round-trip, and survive a fee-and-slippage shock.

Reproducibility note

The scaled-down Python version at trader-research shows the methodology used – the contract surface, the modifiable interior, the program.md spec the agent operates under – on a 4-token, bear-specialist-only, 2022-only subset. It is a small runnable example with the same scoring and loop structure – perfect to clone and run on a laptop in minutes. The full Loop 3 run was executed against a Rust implementation over a much larger token universe – not something you can clone and run on a laptop without the Rust codebase and ~18 hours of compute.

Phased Sweeping

The full ensemble has three GEM specialists (bull / bear / ranging) gated by a 3-state HMM regime detector, plus a meta-allocator model that blends specialist portfolios when the HMM outcome is uncertain (< 90%). That is roughly 15 sweepable parameters.

A grid over all 15 is combinatorially prohibitive, which is why the autoresearch loop instead sweeps in phases:

1. Phase 1 – HMM hyperparameters (refit interval, hard-switch threshold, min observations). Specialists held at defaults.
2. Phase 2 – per-specialist GemParams (top_n, $R^2$ threshold, rebalance cooldown). One specialist at a time, the other two at the Phase 1 winner.
3. Verification – combined grid with the new defaults locked in, varying one specialist at a time off the new baseline to try and spot interactions.

Loop 3: 437 Tokens, 18 Hours, 215 Configs

Universe: 431 Binance OHLC tokens (2020-01-01 through 2026-04-18) plus 6 DefiLlama price feeds for tokens not on Binance (AERO, DRIFT, FLUID, GRAIL, HYPE, MNDE) – 437 tokens total, ~508K daily candles.

Evaluation window: 2021-01-01 to 2025-12-31 with a 250-day warmup buffer. Causal walk-forward (No peeking past day t-1 when deciding for day t).

Baseline: the existing ensemble defaults under the old fee regime, score -inf (every config rejected).

Phase 0: the unblocking

Before any model parameters were swept, the agent diagnosed why every baseline config was scoring -inf. The old fee model was 0.001 base with a 2× stress multiplier – which sounds aggressive but actually makes the base look unrealistically cheap and the stress test punitively expensive (effective 0.002 stress).

The loop changed two numbers:

That single calibration fix, a realistic fee with a realistic stress test, unblocked 160+ viable configs.

Phase 1: HMM hyperparameters

48 configs, sweeping hmm_refit_interval × hard_switch_threshold × hmm_min_observations.

The threshold finding is the interesting one. At hard_switch_threshold=0.90 the ensemble almost never hard-switches to a single regime; instead it soft-blends the three specialist portfolios most of the time. That scored 305.7 vs 244.8 at the previous default of 0.80 – a 25% lift from doing less of what the architecture was designed to do.

The HMM’s regime classification is informative but not confident enough for a binary regime decision. Soft blending hedges against misclassification.

Phase 2: per-specialist GemParams

Three sweeps, 36 configs each, for top_n × r2_threshold × rebalance_cooldown per specialist.

Bull (best 5 of 36):

Bear (best 5 of 36):

Ranging (best 5 of 36):

Verification: the combined defaults

With each specialist’s winners locked in, the verification grid hit score 1175.2 on the combined defaults. The buy-and-hold BTC+ETH baseline scored 8.3.

That is a 142× improvement over the buy-and-hold.

What the Loop Found

Two new findings, plus one confirmation of an earlier result at scale. Ranked by how surprising they were:

1. Soft blending beats hard switching. Increasing hard_switch_threshold from 0.80 to 0.90 is less of what the ensemble architecture was designed to do, and it scored +25%. The HMM is a good signal, but not a confident enough signal to act on as a binary classifier. The right way to use it is as a probability-weighted blend.

2. All three specialists prefer lower $R^2$ thresholds than the priors said. The pre-loop defaults were 0.3 / 0.7 / 0.5 for bull / bear / ranging. The winners were 0.2 / 0.5 / 0.3. The $R^2$ filter was rejecting tokens with weak-but-real momentum signals. Across three independent sweeps the loop found the same direction of correction.

3. The bear-portfolio top_n=1 result holds at scale. The previous post’s 4-token result – concentrating on the single best opportunity beats diversification in a bear regime – survived the jump to 437 tokens. top_n=1 won the bear sweep cleanly: in bear regimes there is typically exactly one token with a genuine positive momentum signal (usually PAXG or a stablecoin), and diversifying across 3-8 tokens dilutes the safe-haven effect. This isn’t a new discovery, but it’s a non-trivial confirmation – the loop arrived at the same answer independently, on a universe roughly 100× larger.

The first finding – soft-blend dominance – is the kind of result that’s worth more than any specific parameter value. It tells you the ensemble’s architecture is over-relying on a part of the system (binary regime calls) that the data doesn’t support.

Limitation

This optimization approach has one strong limitation: One-at-a-time phased sweeping cannot find between-parameter interactions.. For example: If the bull and bear specialists models need jointly different parameter values in order to reach a high score, this loop will not find that configuration. This is a structural limitation, one that drives the motivation for the next-phase ideas.

Next Steps

Lifting the phased-sweep limitation

The current loop is a one-parameter-at-a-time scan. The search heuristics – “sweep top_n first, then $R^2$ threshold, then sweep again with the new defaults locked in” – lives in program.md as natural language instructions for the agent.

That’s a workaround for the high-dimensional parameter space, yet a different ordering, a different grid resolution, a different fallback when a sweep stalls – any of these could move the metric meaningfully, and currently there is no no way to discover that.

A potential successor is to replace the loop with a reinforcement-learning approach, with a state.

Improving the regime detector

The current HMM uses Gaussian emissions, which is a known poor fit for stocks (or crypto) data – the empirical distributions are fat-tailed and asymmetric, with the kind of tail events the loop’s hard-rejection gate exists to defend against. A single 30%-down day can fool a Gaussian-emission HMM into a regime call that doesn’t reflect the underlying dynamics.

Finding #1 – soft blending dominating hard switching – is consistent with this: the HMM’s regime calls aren’t confident not because the regimes don’t exist, but because the emission model is too simple to assign them confidently.

Replacements worth trying, ranked by implementation cost:

• Student’s $t$ emissions. Minimal change to the existing HMM, just heavier tails. Cheap to implement, immediate test of whether soft-blend dominance survives a fatter-tailed emission model.
• Hidden semi-Markov models with explicit state-duration distributions, capturing the empirical fact that regimes don’t switch every day.
• Mixture-of-Gaussians or GARCH-style emissions to model volatility clustering inside a regime rather than across them.
• Neural sequence models (LSTM / Transformer) that learn regime structure end-to-end without the Markov assumption – higher capacity, harder to interpret, and the most aggressive departure from the current contract surface.

More aggresive bear specialist model

The bear specialist currently sits in cash when no token has a positive trend. With the use of perpetual funds (such as offered by Kraken or dYdX) the defensive (long safe-haven) startegy could flip int an offensive one (short weak-momentum tokens).

The same $R^2 \cdot (a_1 - 1)$ momentum signal becomes a short-entry signal when negated, and the inverse-volatility weighting carries over directly.

Currently top_n=1 picks PAXG; with futures the specialist can profit from crashes instead of just hiding.

The open questions are funding-rate cost vs. the current 30 bps fee budget, sizing under leverage, and whether the Calmar hard-rejection gate still makes sense once shorting is allowed.

Momentum based strategies work well in up-trending markets. Fit a curve to the price data, rank tokens by the quality and strength of their trend, select a portfolio of winners. In a bull market, there are plenty of winners to choose from.

But what happens in a bear market?

• the winners are few and apart
• the rare upwards trends are short-lived

The 2022 is but the most textbook example of a crypto bear market – especially the period from May through December, when BTC had already fallen 50% from its all-time high, Luna had collapsed, and the market was unambiguously grinding down. I ran a series of experiments on historical data, trying to gauge whether a simpler linear model can be more responsive to the short upward trends as compared to a compounding curve.

TL;DR The choice of regression model turns out to be almost irrelevant, what matters the most seems to be the length of the fitting window.

The GEM Pipeline

The GEM pipeline fits a regression model to each token’s daily closing prices, then selects a portfolio based on the fit quality and trend strength.

For each token on each day:

1. Fit: Normalize timestamps to sequential day indices (0, 1, 2, …) and fit a trend model to the closing prices
2. Evaluate: Compute R-squared and a momentum score
3. Filter: Keep tokens with positive trend, R-squared above a threshold, and the momentum below a cap (to exclude pump-and-dump spikes)
4. Weight: Rank by momentum, take the top N, and assign inverse-volatility weights using Average True Range (ATR). This is the portfolio.

The baseline model uses a two-step exponential regression:

First, a log-linear OLS fit ($\ln y = b_0 + b_1 x$) provides initial parameter estimates. These are refined via Levenberg-Marquardt optimization into the exponential form. Momentum is then $R^{2} \cdot (a_1 - 1) \cdot 100$, where the R-squared exponent controls how much low-quality fits are penalized.

The experimental linear model fits directly in price-space:

Momentum becomes $R^{2} \cdot (b_1 / \bar{p}) \cdot 100$, where $b_1 / \bar{p}$ normalizes the slope by the mean price to produce a percentage daily trend, analogous to $a_1 - 1$ in the exponential case.

The rest of the pipeline – ATR computation, portfolio construction, differential rebalancing, and cooldown – is identical between the two models.

Experiment Setup

Window: May 1 – December 31, 2022. By May, BTC had already dropped roughly 50% from its November 2021 ATH. The Luna collapse (May 9), 3AC liquidation (June), and FTX collapse (November) all fall within this window. No doubt the bear is already here.

Token universe: A curated “bear portfolio” of safe-haven assets available on Binance:

Models and their parameter configs:

We use the so called “bear” and a “ranging” specialist models, GEM models with their parameters selected towards capital preservation and cautious exploration of the token universe, respectively:

Fee model: We assume 0.3% per trade (0.10% exchange fee + 0.20% slippage estimate).

Benchmark: Equal-weight buy-and-hold across all four tokens. This is what we want to beat.

First Attempt: Full History Fitting

First run used the standard GEM approach: fit the regression model to all available history from the start of the window up to the current day. On day 100, the model sees all 100 preceding candles.

The results:

The bear specialist didn’t trade at all, it sat in cash for the entire eight months - winning on capital preservation.

At the same time it failed to capture any of the intermediate rallies that occurred during this period. PAXG, for instance, rallied roughly 10% from its June lows through August as gold spiked during the 3AC liquidation chaos.

To understand why, we examined what the models actually computed on several randomly sampled dates:

Every token, on every date, had a growth parameter below 1.0 (negative overall slope). The R-squared was often strong – meaning the model was confidently fitting a downtrend. But the growth filter ($a_1 > 1$) rejected everything, because the cumulative history from May 1 was dominated by the initial hard crash.

The ranging specialist, with its looser R-squared threshold (0.3), did enter positions – and promptly lost money, because it was catching the tail end of downtrends, not rallies.

The core problem: fitting over the entire history anchors the model to the dominant long-term bear trend. The exponential model compounds this: it assumes multiplicative growth, making it even harder for a short 2-week price rally to overcome the long negative history.

Rolling Window

The solution is to limit the regression to a rolling window of recent data.

This reframes the model from a cumulative trend detector to a short-term momentum detector, catching the short-lived rallies.

R-squared plays a dual role in this setup:

• A genuine rally over a 30-day window produces a clean uptrend and high R-squared
• A “dead cat bounce” is noisy and V-shaped – the linear fit is poor, R-squared is low, and the position gets filtered out

I tested three window sizes – 15, 30, and 60 days – across both models and both parameter configs:

Three observations stand out:

1. The 30-day window seems to be the sweet spot. It captures the PAXG (gold) summer rally: long enough for R-squared to recognize a genuine consistent trend, short enough to not get anchored by the preceding months of decline. The 15-day window is too reactive – it enters and exits on noise, bleeding fees across 24+ rebalances. The 60-day window is too slow – it captures the rally, but enters late and exits late, leaving profits on the table.

2. Bear params (top_n=1) dominate ranging params (top_n=8). In a 4-token safe-haven universe, concentrating on the single best opportunity outperforms diversification.

3. The exponential and linear based GEM models produced almost identical results at every window size. The choice of regression model is irrelevant.

What the Winner Holds

This is how the bear-w30 model earns its return – every rebalance event over the 8-month window:

Model kept patiently for six and a half months of in all cash, then entered into a clean trend:

• From May through October, every rebalance evaluates candidates and finds nothing.
  • No token sustains a positive 30-day slope with R-squared above 0.5 and the model (correctly) stays out of the market.
• On November 9, the EUR begins a sustained rally against the dollar.
  • The 30-day window picks up a clean uptrend – R-squared just clears 0.50 – and the model enters EURUSDT.
  • Over the next 6 weeks, the trend strengthens: R-squared climbs to 0.75, momentum rises, and the portfolio value grows to $10,525.
• On December 19, PAXG briefly shows a stronger trend (R-squared 0.79) and the model rotates for one brief period before returning to EUR.
• The strategy finishes at $10,640 – a 6.40% return in a period where BTC fell 65% from ATH and the equal-weight buy-and-hold benchmark lost 0.65%.

It waits for a trend that passes strict quality filters, then concentrates its entire portfolio on that single opportunity.

Next Steps

The above results come from a hand-curated 4-token safe-haven portfolio. The natural folow-up question is: what happens when we run the same experiment on the full Binance token universe?

With hundreds of tokens, the model has a much richer candidate pool on each rebalance day. Does it converge to the same safe-haven tokens (PAXG, EUR) that we hand-picked, or does it find opportunities we didn’t anticipate?

The full universe also gives the exponential and linear models a chance to diverge on the more volatile altcoin data.

March 2023 has brought an important milestone to the Aleph Zero: the long-awaited launch of smart contracts capabilities.

In this blog post we welcome you to TheButton, a smart-contract based game deployed on the Aleph Zero blockchain. Inspired by the famous Reddit game and social experiment, TheButton utilizes ink! smart contracts and the lightning-fast finality of Aleph Zero to deliver a captivating gaming experience.

At its core, TheButton features a timer countdown that decreases with each finalized block on the Aleph Zero blockchain. Players’ clicks on the button reset the timer, ensuring its survival for 9,000 blocks (around 25 hours).

With three unique buttons, each governed by different rules, players strategically time their engagement to reap the greatest rewards.

Players utilize ticket tokens (PSP22 standard) to enter TheButton’s games and earn reward tokens. These tokens open the doors to TheButton’s Marketplace, where players can partake in a Dutch auction for ticket sales, taking advantage of fluctuating prices.

Additionally, the game introduces the SimpleDex, a Decentralized Exchange that enables seamless swapping between reward tokens and the wAzero token - a PSP22-wrapped native token of Aleph Zero, ensuring liquidity and flexibility.

The integration of the Marketplace and Decentralized Exchange empowers players to devise winning strategies to optimize their rewards, taking advantage of the market conditions. Aleph Zero’s rapid block finality, with blocks produced and finalized every second on average, adds a time-sensitive dimension to gameplay, further fueling strategic thinking.

In the following sections, we will describe the key components that comprise TheButton. This introductory overview serves as a starting point for our series of technical deep-dives, where we will delve into each component

TheButton Game: high level diagram

Following diagram summarizes communication and interaction between the core components of TheButton game.

The Button Contract: Governing Gameplay, Tracking Rewards, and Minting Tokens

At the heart of TheButton lies the Button contract, a pivotal smart contract that governs the game’s rules, records player interactions, and mints the rewards. Let’s dive into the inner workings of this crucial component, which forms the backbone of the game’s mechanics.

When players enter the game, their interaction with the contract begins by granting permission to the Button contract to spend one ticket token on their behalf. Upon receiving the ticket, the Button contract records the player’s score and initiates the payout of rewards based on the game’s specific rules.

The rewards themselves are a PSP22 token, distinct from the ticket tokens used for entry. The Button contract possesses a special role that grants it the authority to mint these rewards directly into the players’ accounts.

As players engage with the game, the Button contract diligently tracks all rewards disbursed throughout the lifespan of the button. This collection of rewards constitutes the coveted pool for ThePressiah - the individual fortunate enough to make the final click on the button before its demise. As the game progresses, the Button contract keeps a meticulous record of the rewards paid out, setting the stage for the climax as the countdown timer nears its end.

Once the button’s life cycle concludes, and before the next round commences, the designated Pressiah account is bestowed with 50% of the total rewards minted during the preceding round.

To initiate a fresh round, the game can be reset by invoking a specific contract message. This crucial action serves multiple purposes:

• Firstly, it rewards the Pressiah, acknowledging their achievement.
• Secondly, it transfers all the tickets held by the Button contract to the Marketplace, ensuring their availability for the upcoming round.
• And finally, it resets the state of the contract, effectively wiping the slate clean and paving the way for a new round to begin, brimming with exciting opportunities and heralding the potential rise of a new ThePressiah.

As we journey deeper into TheButton’s architecture, we will now unravel additional components that contribute to the gameplay.

The Marketplace Contract: Facilitating Ticket Sales and Dynamic Pricing

The Marketplace contract plays a pivotal role in TheButton’s ecosystem by facilitating the sale of tickets to eager players through a dutch auction mechanism. Let’s explore the inner workings of this contract, which ensures a fair and dynamic pricing model for ticket acquisition.

The primary function of the Marketplace contract is to sell tickets to players using a dutch auction approach. The pricing structure follows a linear decrease from a starting price with each block that is finalized on the blockchain. This downward trajectory continues until the auction has spanned a specific number of blocks, at which point the price reaches its minimum threshold. Once the minimum price is reached, tickets remain available for purchase at this fixed rate.

Additionally, the Marketplace contract tracks the average price of all tickets sold. With each new auction, the contract sets the starting price based on the average price of tickets sold up to that point. This mechanism ensures that pricing remains responsive to market demand and reflects the collective value perceived by players.

By implementing a dutch auction model and leveraging the average price as a starting point, the Marketplace contract establishes a fair and dynamic system for ticket sales. This approach allows players to engage in the game at various stages and obtain tickets at a price that aligns with market trends and player participation.

The Marketplace contract serves as a cornerstone of TheButton’s ecosystem, enabling players to enter the game and embark on their quest for rewards. Through its innovative auction mechanism and adaptive pricing strategy, the Marketplace ensures an equitable and engaging experience for all participants.

As we continue our exploration, we will uncover additional components that contribute to the vibrant and dynamic nature of TheButton’s gameplay.

The SimpleDex Contract: Empowering Decentralized Token Swaps

The SimpleDex contract within TheButton’s ecosystem introduces a decentralized exchange functionality, allowing players to seamlessly swap between the reward tokens. SimpleDex utilizes a simplified version of the Uniswap v1 pricing mechanism.

Uniswap revolutionized decentralized exchanges by implementing an automated market maker (AMM) model. This model eliminates the need for traditional order books, and instead relies on a constant product formula to determine token prices. It ensures that trades occur based on the ratio of token reserves in a liquidity pool.

The SimpleDex contract maintains a single multi-token pool where all reward tokens for each game coexist alongside wAzero (wrapped Azero). wAzero acts as a representation of the native A0 token within the ecosystem, consistently exchangeable at a 1:1 ratio.

However, a deliberate design choice was made to restrict swaps only from tokens to wAzero, not the other way around. This limitation was driven by legal considerations, as the possibility of purchasing ticket tokens directly with the native token could potentially classify the game as gambling according to Swiss laws. To mitigate this risk, ticket tokens are pre-minted and airdropped to actively staking accounts on the Aleph Zero blockchain, ensuring fair participation.

It’s worth noting that on an anonymous blockchain, anyone can write and deploy additional contracts, such as an escrow contract, to enable trustless exchanges between Azero and ticket tokens. As long as these contracts are developed by the community members and not directly associated with the Aleph Zero Foundation, it aligns with our core principles of decentralization and community-driven innovation.

Given the straightforward design of the game, there is no need for external liquidity providers within the SimpleDex contract. Liquidity for wAzero is periodically topped up by the Foundation itself, while liquidity for reward tokens is sourced from the swaps executed by players themselves.

The pricing mechanism employed by the SimpleDex holds a strategic value within the game. Players can leverage this mechanism to devise strategies that optimize their token swaps, providing them with a competitive edge in navigating TheButton’s gameplay dynamics.

Conclusion

With this, we conclude our exploration of the core components that drive TheButton, a captivating smart contract-based game deployed on the Aleph Zero blockchain. We have delved into the Button contract, which governs gameplay and rewards, the Marketplace contract that facilitates ticket sales, and the SimpleDex contract, empowering decentralized token swaps.

But our journey is far from over: in the upcoming series of blog posts, we will venture deeper into TheButton’s design and uncover additional components that make it possible. We will discuss design choices we made, and unveil some innovative features, diving into a more technical intricacies.

Stay tuned!

Keep reading

• Next in the series: implementing Access Control
• Source code

If you’re a geek like I am, you must remember that scene in The Matrix Reloaded when Trinity fires up nmap on 10.2.2.2 and finds a vulnerability in SSH to exploit.

Its author was apparently dancing in the aisles of the cinema when he saw his creation in the movie. Well, Spread sorta-kinda had its first moment of fame too!

Congratulations to Professor Philippe Lemey!

First and foremost, I want to start this post by extending my congratulations to my former PhD supervisor, Professor Philippe Lemey, who has received the prestigious Francqui-Collen Prize in Brussels on June 6th, 2023, from the hands of the King of the Belgians, Filip. The prize, aptly referred to as the “Belgian Nobel Prize,” was awarded to Philippe for his pioneering work against the spread of viruses.

Professor Lemey is not only a great researcher but also a fantastic person and a real role model. It’s always great to see when such individuals receive the recognition they deserve. So once again, a huge congratulations to him!

Spread on the national news

On this occasion, VRT, the national public broadcaster for the Dutch-speaking part of Belgium, has aired a segment about Professor Lemey and the work of him and his lab.

It was really cool to see the material include a clear shot of Spread in use 😄. The entire segment can be found here, and at 58 seconds into the second video, there is a close-up of the tool being used.

TL;DR

Spread recently experienced a minor security incident related to increased email login attempts. However, no user data was compromised during the incident.

Introduction

In this blog post, I’ll discuss a recent security incident at Spread and the steps taken to address it. I’ll provide an overview of our authentication approach, explain the incident details, outline the actions I took, and discuss the future directions.

Authentication Approach

When designing Spread, I adopted a passwordless approach for user authorization and authentication. Spread doesn’t store any credentials or passwords. Instead, users can choose to authenticate using OAuth 2.0 with Google or any other email. In the latter case, Spread sends an email containing a “magic link” with a short-lived token. Upon clicking the link, the token is validated, and a longer-lived JWT access token is issued, signed with Spread’s RSA key.

Incident Details

On April 26th, I received an alert from Sendgrid, our email service provider, notifying us that our monthly quotas were almost exceeded. Given our focus on cost-effectiveness¹, I had chosen a very modest plan that had been sufficient until now. My concern was that a potential leak of our API key could result in an unauthorized usage, affecting our reputation as a trusted sender.

Steps taken

To investigate the situation, I reviewed the logs and noticed a significant increase in email login attempts. While this was not ideal, it indicated an attempt to overload the endpoint responsible for sending login emails, rather than credentials leak or a sophisticated attack.

To mitigate the issue, I took the following steps:

• Revoked the Sendgrid API token to prevent further unauthorized usage.
• Temporarily disabled the “magic link” login/sign-on functionality until the API token was rotated.
• Developed a solution to handle similar attacks by implementing an IP-based “jailer” decorator that limits the number of login attempts within a specific timeframe.
• Collaborated with Juan to improve the decorator implementation, resulting in a more efficient and testable state machine-based approach.
• The solution can be found in the following code.

1: sadly the academia is notoriously underfunded.