← All articles

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.

CryptoPublished By Stratifyre

Topics

BitcoinBacktestingStrategy research

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.

Saved BTC SMA20/50 entry rule requires flat position and excludes runtime day of week zero and six
The saved rule adds day-of-week ≠ 0 and ≠ 6 to the crossover and flat-position conditions. The runtime calendar is America/New_York; these fields do not establish the proposed UTC next-fill eligibility.
Actual bounded BTC weekday demonstration configuration: January through March 2025, hourly, 10000 capital and final flattening
Both demonstration runs use these dates and execution settings. Final flattening differs from the proposed worksheet's end-boundary mark-to-market policy.
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
Actual unrestricted BTC SMA comparison report with minus 210.18 profit and 3.1 percent rounded maximum drawdown
The unrestricted completed report loses 210.18 across 25 trades.
Actual runtime weekday BTC report with minus 172.35 profit and 2.9 percent rounded maximum drawdown
The runtime weekday run loses 172.35 across 18 trades and spends less time exposed. The smaller loss does not establish a profitable weekend filter.
Actual unrestricted BTC trade ledger with entry and exit timestamps, including Sunday entries
The actual baseline ledger contains weekend entries. UTC grouping of all 25 returned entry timestamps gives six Saturday/Sunday entries; entry-day grouping is separate from exit-based performance segments.
Actual runtime weekday BTC trade ledger with complete entry and exit timestamps after the restriction
The restricted ledger has no weekend entries in this sample. Existing positions can still close on weekends; this rule does not remove weekend exposure.

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