How to Backtest a Strategy with Funding Rates and Macro Events
Learn how to test an onchain trading strategy that combines funding rates, price behavior, and macro-event filters before moving it from research to live alerts.
Short answer
To backtest an onchain trading strategy that uses funding rates and macro events, make both parts explicit before testing.
Define the funding-rate signal, define how macro events should affect the rule, test the combined condition against historical data, inspect every trigger, and start with alerts before any live execution. If the macro data source is not available in your workflow yet, keep that part as a manual event filter until coverage is confirmed.
Why combine funding and macro events?
Funding rates show how crowded perpetual futures positioning is. Deeply positive funding can mean longs are paying a lot to stay long. Negative funding can mean shorts are paying to stay short.
Macro events change how those signals behave. A funding extreme before CPI, FOMC, payrolls, an ETF decision, or a major policy speech may behave differently from the same funding extreme on a quiet day.
That is why the test should not ask only:
What happens when funding is high?
It should ask:
What happens when funding is high, price confirms or fails, and no major macro event is about to distort the next few hours?
The backtesting workflow
| Step | What to define | Why it matters | | --- | --- | --- | | 1. Market | Asset, venue, and instrument | BTC spot, ETH perp, Hyperliquid, Binance, and other venues do not behave the same | | 2. Funding signal | Direction, threshold, and interval | “High funding” needs a number and time frame | | 3. Price filter | Breakout, failed breakout, trend, or volatility condition | Funding alone is often too noisy | | 4. Macro event filter | Events to avoid, include, or treat separately | Major events can change the forward-return distribution | | 5. Cooldown | Minimum time between fires | Prevents one event from creating many duplicate triggers | | 6. Review windows | 1h, 4h, 24h, or custom horizons | Shows what happened after each signal | | 7. Activation rule | Alert, preview, confirm, or execute where supported | Keeps live risk separate from research evidence |
Example prompt
A usable prompt is specific:
Backtest BTC-PERP on Hyperliquid. Signal when 8-hour funding is above 0.08%, BTC fails to make a new 4-hour high, and no major macro event is scheduled in the next 2 hours. Use a 4-hour cooldown. Show 1-hour, 4-hour, and 24-hour forward returns, and separate results for days with macro events versus quiet days.
That prompt tells the backtest engine:
- The venue and market.
- The exact funding threshold.
- The price behavior that must confirm the thesis.
- The macro-event window.
- The cooldown.
- The review horizons.
- The comparison between event and non-event regimes.
The result should be an inspectable rule and trigger history, not a black-box recommendation.
Define the funding-rate signal
Funding can be used several ways:
- Crowding filter: avoid longs when positive funding is extreme.
- Mean-reversion signal: fade a crowded side when price fails to confirm.
- Carry signal: look for opportunities where funding can be collected while price risk is controlled.
- Risk alert: notify when the market becomes one-sided.
Do not use words like “high” or “extreme” without a threshold. Use a number, a funding interval, and a venue. For example:
- BTC-PERP funding above 0.08% per 8-hour period.
- ETH-PERP funding below -0.03% per 8-hour period.
- Funding in the top 5% of the last 90 days.
The more precise the input, the easier it is to review the output.
Define the macro-event filter
Macro can enter the strategy in three ways:
- Avoidance filter: do not fire within a set window before or after major events.
- Separate regime: compare event days with quiet days.
- Catalyst filter: only evaluate the signal around events you explicitly care about.
Avoidance is usually the simplest first test. For example, “do not fire two hours before CPI or FOMC.” This keeps the funding signal from being judged during periods when liquidity, spreads, and positioning can change quickly.
If your workflow depends on a live macro feed, verify current coverage before relying on it. If coverage is not available, keep macro as a manual event calendar filter while you backtest and monitor the funding logic.
What to inspect before going live
Before live alerts, review:
- Number of fires after cooldown.
- Whether performance is concentrated in one regime.
- Event-day versus quiet-day results.
- Forward returns at each review horizon.
- Worst historical drawdown after a trigger.
- Fees, slippage, and funding payments.
- Whether the rule still works with a simpler threshold.
- Whether removing the macro filter improves or damages the result.
The goal is not to find the most flattering backtest. The goal is to understand what would make the rule fail.
Start live with alerts
The first live version should be an alert, not a trade.
An alert lets you compare the rule’s live behavior against the backtest without committing capital. When the rule fires, review:
- Did the funding condition match the thesis?
- Was the macro calendar clean?
- Did price confirm or invalidate the setup?
- Would you still want to act after seeing the live context?
Only after the alert version behaves sensibly should you consider preview-confirmed execution or stricter automation where supported.
Where Stingray fits
Stingray is built for the part of the workflow before live risk: turning the thesis into a typed rule, running the backtest, showing the trigger history, and then monitoring the same condition as an alert.
For a narrower funding-only walkthrough, read How to Automate a Funding Rate Strategy on Hyperliquid. For the broader no-code workflow, read How to Automate an Onchain Trading Strategy Without Code.
Verdict
A funding-plus-macro strategy should not go live because the idea sounds plausible. It should go live only after the exact rule has been tested, the macro-event handling is explicit, and the first live stage is alerting.
Backtest the rule, inspect the triggers, compare event days with quiet days, and treat execution as a later step.
Next reads:
- Funding-Rate Rule Backtested
- How to Automate a Funding Rate Strategy on Hyperliquid
- How to Automate an Onchain Trading Strategy Without Code
