astrology-trading-research

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.