Does your Bitcoin strategy behave differently on weekends?
Test a weekday-only entry rule without confusing weekend entries, weekend exits, and the risk of holding Bitcoin through Saturday and Sunday.
Skipping Bitcoin trades on weekends sounds like a small change. It can remove losing entries, miss winning ones, leave Friday positions exposed through Sunday, or simply reduce the time your money is at risk. Those are different outcomes.
The useful question is specific: does rejecting new Saturday and Sunday entries improve this strategy after costs, without changing its exit rules? This article gives you a testing recipe, not a result showing that weekday-only trading works.
Kaiko’s Q1 2024 report documented a historical decline in the share of Bitcoin volume traded on weekends, with differences between dollar and tether markets. That motivates investigation; it does not establish today’s conditions on your exchange or a profitable calendar filter. Volume patterns and strategy returns answer different questions. Source: Kaiko’s Q1 2024 report, “Where Did Weekend Traders Go?”
Separate three weekend questions
Before adding a filter, decide which behavior you want to change.
| Question | What changes? | What can still happen? |
|---|---|---|
| Should I reject weekend entries? | No new positions begin on Saturday or Sunday. | A Friday position can remain open all weekend. |
| Should I reject weekend exits? | Exit execution is delayed or prevented during the weekend. | Existing positions keep their exposure; losses can continue. |
| Should I avoid weekend exposure? | Positions must be closed before the weekend, with a defined reopening policy. | Extra exits and reentries can add costs and miss moves. |
Start with the first question. Keep exits active every day. A weekday-only entry rule is not a promise that the strategy will be flat on weekends.
Define the weekend as Saturday 00:00 UTC through Monday 00:00 UTC, excluding Monday’s boundary. Use that same clock for entry eligibility, trade grouping, and exposure calculations.
Freeze one experiment before comparing results
Use your existing strategy if its rules are already explicit. If you need a simple teaching setup, the following is a proposed experiment, not a recommended or tested strategy.
| Setting | Proposed specification |
|---|---|
| Market | Binance BTC/USDT spot, long only; verify the exact venue’s historical data coverage. |
| Signal | On completed one-hour candles, buy when the 20-bar simple moving average moves from at or below the 50-bar average to above it. |
| Exit | Sell when the 20-bar average moves from at or above the 50-bar average to below it. No short position. |
| Execution | Signal after candle completion; fill at the next candle’s open with adverse slippage. |
| Size | Start with 10,000 USDT; each entry buys 1,000 USDT of BTC before costs. One position at a time, no leverage or compounding. |
| Costs | Illustrative commission of 0.10% of executed notional on each side; illustrative adverse slippage of 0.05% on each fill. These are assumptions, not current exchange rates. |
| History | Supply 100 completed hourly candles before each period starts; warm up without trades and begin each period flat. |
| Development period | From 2023-01-01 00:00 UTC up to, but excluding, 2025-01-01 00:00 UTC. |
| Later validation | From 2025-01-01 00:00 UTC up to, but excluding, 2026-01-01 00:00 UTC; inspect only after freezing the comparison. |
Keep every candle in both versions, including weekends. Deleting Saturday and Sunday data would change the moving averages and signal sequence, rather than testing entry eligibility alone.
For the restricted version, reject an entry if its intended next-open fill falls in the UTC weekend. Discard that signal rather than saving it for Monday. A fresh crossover is required later. Apply the same cash checks, price rounding, data-gap policy, and end-of-period treatment to both versions. Mark any remaining position to market at the boundary; separate unrealized value from completed-trade statistics.
Check the clock at the boundary
Binance’s candle specification identifies candles by their opening time and supplies opening and closing timestamps. Its timeZone option changes candle interval boundaries; startTime and endTime remain UTC. Record the data’s timezone instead of inferring it from a chart label. Source: Binance’s Spot REST specification, Kline/Candlestick data
Stratifyre documents time.day_of_week with Sunday numbered 0 and Saturday numbered 6. Numbering alone does not establish a UTC calendar rule. Before using a weekday expression, verify the rule’s clock and whether it checks signal time, order time, or fill time. Source: Stratifyre’s time expression reference
Check these intended entry fills against your UTC definition:
| Intended fill time | Weekday-only entry eligible? |
|---|---|
| Friday 23:00 UTC | Yes |
| Saturday 00:00 UTC | No |
| Sunday 23:00 UTC | No |
| Monday 00:00 UTC | Yes |
The Friday 23:00 candle can produce a signal for a Saturday 00:00 fill. Checking Friday’s candle date would allow the very weekend entry you meant to reject. Conversely, a Sunday candle can produce a Monday fill that is eligible under this definition.
If the available rule cannot enforce this exact clock and timing, choose and document a different calendar definition before testing. Grouping completed trades by UTC entry time can diagnose the original run, but cannot replace a new restricted simulation.
Read entries, exits, and exposure separately
Stratifyre’s calendar performance dimensions are Exit Day of Week, Exit Month, and Exit Quarter. The calendar groups use UTC exit timestamps. A Monday segment therefore contains trades that finished on Monday, including trades opened on Friday or Sunday. Source: Stratifyre’s segment documentation
Consider a purely illustrative position opened Friday at 18:00 UTC and closed Monday at 12:00 UTC:
- Entry group: weekday, because the position began Friday.
- Exit group: Monday, because the position finished Monday.
- Weekend exposure: 48 hours, even though neither endpoint is on Saturday or Sunday.
The trade’s full profit or loss belongs to its exit group in an exit-based report. That does not tell you how much of its price change occurred over the weekend.
For the entry question, group actual fills by UTC entry date and compare trade count, net outcome, and holding duration. For the exposure question, measure the overlap between each open-position interval and the UTC weekend. Report weekend hours at risk alongside total hours at risk; a short weekend trade and a position held throughout both days are not equivalent. Measuring profit earned during weekend hours requires a price or equity path through those hours, not just entry and exit records.
Run the comparison, then protect the later period
Run an unrestricted baseline and a version with the single entry restriction. Use identical data, signal history, sizing, costs, and fill assumptions. Record rejected signals so that you can inspect what the filter actually removed.
Rerunning matters: a rejected Saturday entry leaves the account flat, which can change its next eligible trade. Subtracting weekend-entry trades from the original profit total does not reproduce the restricted strategy’s state.
Compare net return after costs, maximum portfolio drawdown, completed trades, total exposure, and weekend exposure. A higher win rate can accompany lower total profit. A smaller drawdown can accompany much less time invested. Inspect the largest winners and losers to see whether one removed trade explains most of the difference.
Use realistic costs for your venue and size, then repeat with a predeclared higher slippage assumption. A candle-based fixed-slippage test does not measure actual weekend spreads or market depth. Keep any claim about worse weekend execution separate until you have relevant observations.
Freeze the filter before opening the later period. Run both versions there without choosing new weekdays, changing the moving averages, or shifting the timezone to rescue the result. If you have already examined that period while developing the strategy, it is no longer an untouched validation sample.
Record whether the restriction helped, hurt, or produced too few trades to support a conclusion. Include both periods and both versions in your research log. Testing many calendars and reporting only the winner turns a narrow question into a search for an appealing backtest.
The available weekday rule in a real demonstration
A separate demo-account comparison runs the hourly SMA20/50 rules on CRYPTO:BINANCE:BTCUSDT for January–March 2025, with 10,000 starting capital and 1,000 cash allocations. It changes only the entry rule’s calendar conditions; exits remain active every day. This is a shorter demonstration than the proposed research above, and uses the runtime’s America/New_York evaluation calendar, not a certified UTC intended-next-fill filter.
| Observed output | Unrestricted baseline | Runtime weekday entry rule |
|---|---|---|
| Completed trades | 25 | 18 |
| Reported profit | −210.18 | −172.35 |
| Ending equity | 9,789.82 | 9,827.65 |
| Maximum drawdown | 3.12% | 2.93% |
| Time exposed | 43.61% | 32.87% |
| Entries on Saturday/Sunday, grouped from UTC fill timestamps | 6 | 0 |
| Returned trade fees | 0 | 0 |
Both runs configure 0.10% commission and 0.05% slippage, but return zero charged fees. Their outputs therefore do not answer the proposed question after verified exchange costs. The full development and later periods, exact UTC next-fill boundary checks, rejected-signal ledger and weekend exposure-overlap analysis remain unexecuted.
The decision is whether this defined restriction deserves further testing for this strategy and venue. It is not a rule about Bitcoin weekends in general, and a historical improvement does not establish future profitability.
Use the Stratifyre backtesting guide to prepare your baseline, then compare one precisely defined entry restriction against it.
Put your strategy rules to the test
Build your strategy, inspect historical trades, and review the assumptions behind your results.
Build and test your strategy

