---
name: astrology-trading-research
description: Design and evaluate astrology-informed trading research systems with blind backtesting, frequency-aware signal design, and paper-first execution.
version: 1.0.0
author: Hermes Agent + Alex
license: MIT
metadata:
  hermes:
    tags: [astrology, trading, crypto, blind-backtesting, strategy-research, moon-timing]
    related_skills: [astral-transit-calendar, astral-chart-api, astrology-rulership-chains-alex]
---

# Astrology Trading Research

## Purpose

Use this skill when building or revising systems that test astrology-informed trading hypotheses, especially crypto swap strategies, paper trading, blind backtests, strategy dashboards, or self-improving trading research loops.

This is a **research and simulation skill**, not financial advice and not a live-trading permission layer. Default to paper/simulation until the user explicitly asks for live wallet execution and security/risk controls are designed.

## Core Principle: Frequency-Aware Astrology

A strategy must be evaluated not only for symbolic coherence but for whether it can produce enough samples to be tested and used ongoingly.

Classify every signal by role:

1. **Regime filter** — slow context; controls risk limits and permitted direction.
2. **Setup window** — medium-frequency tradable window; invites a trade search.
3. **Execution trigger** — high-frequency precise timing; schedules entries/exits.
4. **Allocation filter** — modifies size, token selection, or cash/stablecoin exposure.

Avoid treating rare outer-planet or Mars/Saturn events as standalone live trading systems unless there is a deep historical catalog across comparable assets or repeatable derivative triggers.

## Recommended Frequency Ladder for Crypto

Crypto trades 24/7 and has limited history, so prioritize high-sample timing layers.

### Layer 1 — Moon-based execution triggers

Use as the primary source of frequent entry/exit timing:

- Moon applying/separating from benefics/malefics.
- Moon ingress by traditional sign ruler.
- **Moon degree ingresses / degree pulses**: the Moon enters a new zodiacal degree roughly every ~2 hours, creating high-frequency events; use exact ephemeris/transit timings or the finest available candle-aligned calculation, not the rough estimate.
- Moon translating light between slower planets.
- Moon crossing degrees recently occupied by Sun, Mercury, Venus, Mars, Jupiter, or Saturn.
- Moon aspects to the instrument's natal/radix chart when a defensible chart exists; for BTC, use the Genesis block timestamp as the default radix (`2009-01-03T18:15:05Z`) and test repeated lunar contacts to BTC Genesis natal planet degrees.

Good hold windows: 1h, 2h, 3h, 6h, 12h, 24h. For Moon-degree systems, start with 1h–6h so the hold window matches the event cadence.

#### 360-degree Moon sweep protocol

When Alex asks whether “the Moon in degree X” predicts BTC movement, test the full zodiac deliberately rather than eyeballing one degree:

1. Generate an astrology-only event schedule for every Moon ingress into absolute zodiacal degrees `0–359`; record timestamp, absolute degree, sign, sign-degree, traditional sign ruler, and lunar speed if available.
2. Seal/hash the schedule before revealing market outcomes.
3. Score each degree across multiple forward holds (`1h`, `2h`, `3h`, `6h`, `12h`, `24h`) against same-window BTC benchmark with explicit fee/slippage.
4. Display sample count per degree; do not rank tiny-sample buckets as meaningful.
5. Run walk-forward/year splits and same-frequency random schedules before promotion.
6. Check nearby-degree robustness (`degree-1`, `degree`, `degree+1`) and grouped feature families: absolute degree, sign-degree `0–29`, sign/ruler, modality/element, and BTC Genesis natal-contact bands.
7. When comparing Moon degrees for Alex, provide a visible 360-degree matrix, not only a top-N leaderboard: each row/cell should show samples, expected up/down direction, raw hit rate, regime-weighted hit rate, sign ruler, and grouped-feature labels.
8. If extending into Human Design / I Ching, map Moon longitude through the app-consistent 64-gate ring before interpretation: each gate spans `5.625°`, and gate-line sub-buckets span `0.9375°`. Use the HD Prism `GATE_RING_ORDER` as source of truth and treat I Ching meanings as post-statistical context only after candidates survive splits/baselines.
9. Report sober evidence such as “degree 120 outperformed in-sample but failed year splits,” not hypey single-degree winner claims.

A 360-degree leaderboard should therefore rank by robustness-adjusted evidence, not raw best alpha from multiple comparisons.

### Layer 2 — Sun/Mercury/Venus setup windows

Use faster non-lunar bodies to define windows that are frequent enough to test:

- Sun aspects to Mercury/Venus/Mars/Jupiter/Saturn.
- Mercury aspects, ingresses, stations, speed changes.
- Venus aspects/ingresses and dignity changes.
- Sun/Mercury/Venus entering signs ruled by Mars, Venus, Mercury, Jupiter, or Saturn.

These should usually open 12–72h windows; the Moon chooses exact execution timing.

### Layer 3 — Planetary hours as grounded frequent timing

Use planetary hours as a traditionally grounded intraday timing grid because they produce many repeatable windows across crypto's 24/7 market:

- Start with UTC as a neutral crypto-market convention; later compare London, New York, and exchange-server time.
- Test hour-ruler changes, ruler class (benefic/malefic/luminary), day-ruler/hour-ruler relationship, sect-style day/night distinctions, and relationship to Moon sign ruler.
- Use 15m or finer candles where feasible; holds can be next hour, 1h, 2h, or 3h.
- Treat planetary hours as a candidate execution/setup layer, not as proof of live edge until it beats same-frequency random hour labels.

### Layer 4 — Mars/Saturn/Jupiter regime filters

Use slower or rarer factors as context, not usually as direct trade triggers:

- Mars/Saturn pressure: lower allocation, defensive bias, stablecoin rotation tests.
- Jupiter/Venus support: risk-on permission or increased allocation only when execution layer agrees.
- Dignity and traditional rulership modify signal confidence.

### Layer 5 — Long-wave background

Outer planets, nodes, and rare configurations can be logged as background context but should not dominate MVP trade scheduling unless the test design can avoid tiny sample sizes.

## Blind Backtesting Protocol

For historical tests:

1. Choose window and strategy rule without inspecting price/news for that period.
2. Generate an astrology-only trade schedule.
3. Seal the schedule with a hash and store all rationale/actions.
4. Only then fetch price data and simulate outcomes.
5. Compare against benchmark and record interpretation notes.
6. Group results by feature family, not single one-off events.

Never ask the model what happened in the market during the test window before sealing. Do not use known historical narratives as rationale.

## Market Data Granularity

Match price data resolution to astrology trigger precision:

- Daily candles are too blunt for exact lunar degree/aspect triggers.
- Use 1h candles as the minimum serious resolution for Moon/execution research.
- Prefer 15m or 5m candles for Moon-degree, planetary-hour, and scalping-style tests when provider limits and storage allow.
- When the research goal is maximum sample size, explicitly surface the tradeoff between longer history and finer candles (for example, full-history 15m first, then recent-history 5m if full 5m is too expensive).
- Record the price source, candle size, fee/slippage assumption, and whether price was fetched only after schedule sealing.
- For Coinbase Exchange public candles, chunk historical requests because the API limits candle count per request; sort and deduplicate by timestamp before simulation.

## Strategy Design Template

For every strategy, specify:

- Name:
- Strategy key:
- Frequency class: regime / setup / execution / allocation
- Astrology signal:
- Required transit data source:
- Token universe:
- Action rule:
- Hold rule:
- Allocation rule:
- Benchmark:
- Why this could work:
- What would falsify it:
- Expected sample count:
- Live usability score criteria:

## Executable Research Loop

When building an ongoing astrology/crypto research system, do not stop at generating hypotheses or research-cycle notes. The system should maintain an executable task queue that Hermes cron can claim and run:

1. Seed tasks from the current research agenda and skill protocols.
2. Claim one queued task per worker run.
3. Execute the concrete backtest/data-ingestion command.
4. Parse machine-readable metrics from stdout or output files.
5. Mark the task completed/failed with result metrics and logs.
6. Feed completed results back into the next task-generation pass.

For Alex, the UI for this class of system should primarily be a **leaderboard + monitor**: show what is queued/running/completed/failed and rank completed tests by visible evidence. Keep hypothesis/provenance views secondary. In monitor/task views, expandable rows should explain why a run was scheduled: the astrology trait being tested, data source/granularity, hold window, cron cadence, sealing-before-reveal rule, and promotion gate (benchmark + same-frequency random baselines), so the scheduling rationale is visible at the point of execution.

## Evaluation Metrics

Rank strategies by more than alpha. For crypto astrology research, make sample size and data granularity visible in the UI before celebrating returns.

Core metrics:

- Alpha vs benchmark.
- Win rate.
- Drawdown.
- Trade count / sample count.
- Signal frequency per day/week and maximum gap between signals.
- Price candle granularity vs astrology trigger precision.
- Consistency across blind windows.
- Overtrading risk.
- Symbolic specificity and falsifiability.
- Live usability score.

Confidence-building metrics:

- Full-history coverage for the instrument where possible. For BTC/USD public/free research, prefer Bitstamp public OHLC as the default full-history exchange source (verified back to `2011-08-18T13:00:00Z`) rather than Coinbase-only coverage (~2015/2016+); keep Coinbase as a secondary cross-source check.
- Walk-forward / out-of-sample splits by year or market regime.
- Random same-frequency schedule baseline percentile.
- Parameter robustness across nearby hold windows, entry offsets, and fee/slippage assumptions.
- Forward-paper sample count after strategy design is frozen.
- Multiple-testing awareness: family-level performance matters more than the single best variant.

A high-alpha strategy with very few events is not automatically better than a smaller-alpha Moon-based strategy with many repeatable samples. A strategy with thousands of samples but no edge versus same-frequency random schedules should also be demoted.

## Interpretation Guidance

When reviewing runs, answer:

- Was this actually frequent enough to trade ongoingly?
- Did it act as a regime filter, setup window, execution trigger, or allocation filter?
- Was the result alpha, beta, cash avoidance, or lucky timing?
- Should the strategy be promoted, demoted, split, or turned into a filter?
- What exact feature should be tested next?

### Regime-aware Moon-degree interpretation

When Alex asks whether a 360-degree Moon matrix is "smart" or whether a 60%+ degree is meaningful, do not stop at a raw leaderboard. Add a regime-aware validation layer:

1. Define BTC macro trend explicitly for each event. Alex's corrected default is a high-timeframe BTC swing peak/valley regime map (macro highs/lows confirmed by broad reversals, e.g. ~25%), not merely current price versus `30d/90d/180d/365d` ago. Prior-return windows can remain diagnostics, but they are not the primary macro-trend label.
2. Score each degree separately for trend-following versus counter-trend behavior. Correct counter-trend calls are more valuable than simply riding BTC beta.
3. Run a grid across hold windows (`1h`, `3h`, `6h`, `12h`, `24h`) and trend lookbacks, then report stable candidates that recur across variants.
4. Treat `~60–66%` per-degree winners as candidates until they survive multiple-testing correction, random same-frequency baselines, nearby-degree robustness, and walk-forward/year splits.
5. For HD/I Ching integration, group 360 degrees into 64 gates using HD Prism's gate order (`5.625°` per gate), then validate gate buckets before pulling symbolic meanings.

For Hermes Trader session-specific implementation details, see `references/hermes-trader-regime-degree-matrix-validation-2026-05.md`.

## Alex-Specific Astrology Defaults

- Use traditional rulerships unless Alex explicitly asks otherwise.
- Mars rules Scorpio, Saturn rules Aquarius, Jupiter rules Pisces.
- For crypto systems, prefer Moon-heavy execution plus Sun/Mercury/Venus medium-frequency windows.
- Do not over-center rare events unless they are expanded into a broader catalog of derivative triggers.

## References

- `references/hermes-trader-frequency-ladder-2026-05.md` — session note capturing the correction that Hermes Trader strategies must be ongoing/frequency-aware, with Moon-first execution design.
- `references/hermes-trader-high-frequency-btc-genesis-2026-05.md` — session note on BTC Genesis-block lunar aspect testing, Coinbase 1h candle retrieval, sample-size/confidence UI metrics, and first high-sample baseline result.
- `references/hermes-trader-executable-research-loop-2026-05.md` — session note capturing Alex's correction that Hermes Trader must execute queued cron tasks, not just research ideas; includes leaderboard/monitor UI pattern, full-history 1h BTC baseline, and payload-size pitfall.
- `references/hermes-trader-granular-frequent-astrology-2026-05.md` — session note capturing Alex's later correction toward finer 15m/5m candles, Moon-degree ingress signals, planetary hours, 10-minute cron execution, and no fabricated win-rate metrics.
- `references/hermes-trader-public-btc-data-and-leaderboard-grading-2026-05.md` — session note on replacing Coinbase-only history with public Bitstamp BTC/USD OHLC back to 2011-08-18, avoiding paid APIs, and making leaderboard rows sober one-sentence graded evidence summaries.
- `references/hermes-trader-degree-matrix-hd-gates-2026-05.md` — session note on surfacing the full 360 Moon-degree matrix in Hermes Trader, persisting latest sweep reports, and mapping degree buckets into HD Prism/I Ching 64-gate aggregates.

## Common Pitfalls

1. **Rare-event overconfidence** — A Mars/Saturn strategy can look good in one run but be too sparse for live use.
2. **Raw degree overfitting** — Degree pulses are valuable timing grids, but single degrees should be grouped into feature families.
3. **Ingress-as-direction error** — Mercury/Venus/Sun ingresses often make better setup windows than automatic directional trades.
4. **Ignoring benchmark beta** — Positive return is not alpha if the benchmark moved more.
5. **Skipping sample-count reasoning** — Every proposed strategy needs an expected frequency and live usability rating.
6. **Using astrology as post-hoc explanation** — Seal rules and schedules before market reveal.
7. **Timing precision mismatch** — Do not evaluate exact Moon/aspect triggers with daily candles; use 1h or finer data and surface granularity in the result.
8. **Ignoring null baselines** — High-frequency astrology rules must beat random same-frequency schedules, not just buy-and-hold or cash.
9. **Stopping at paid or short-history data** — When Alex asks for public/free historical crypto data, do not suggest paid feeds or settle for Coinbase-only 2016-era coverage. Actively check public exchange sources such as Bitstamp and report actual first/last candle coverage.
10. **Hypey leaderboard interpretation** — Leaderboards should show a short sober evidence sentence and a data-centric grade. A large-sample negative result is valuable evidence and should say “no edge yet,” not be spun as success.