Skip to content

Funding payments for perpetual futures #106

Closed

Description

@stefan-jansen

Version: ml4t-backtest 0.1.8

The engine has no way to apply periodic funding cash flows to open perpetual-futures positions. There is no funding concept in the source. The only workaround is to write broker.cash directly from strategy code (or patch broker._update_time), which bypasses accounting: the transfers do not appear in fills, trades or the equity decomposition, and they are easy to apply at the wrong time relative to marks.

Requested:

  • A funding input keyed by asset and timestamp (rate, or payment per unit of notional), applied to positions held at the funding time, long pays positive rate and short receives.
  • Funding reported as its own cash-flow series in the result, so gross P&L, costs and funding can be separated.
  • Clear timing: which mark the notional uses and whether a position opened at the funding timestamp pays.

A backtest of a perpetual-futures strategy without funding is wrong by the full carry, which for a funding-driven strategy is the whole return.

Activity

  1. added
    type: featureNew or expanded user-facing behavior
    priority: highMaterial user impact requiring prompt remediation
    compatibility: affectedHas Python, platform, dependency, or cross-library compatibility impact
    on Sep 23, 2026
  2. added a commit that references this issue on Sep 24, 2026
    9c5e10e
  3. stefan-jansen commented on Sep 24, 2026

    @stefan-jansen
    ContributorAuthor

    Verified on PR #119 at commit 8343029. The focused tests in tests/futures/test_funding.py passed locally (15 passed); the remote coverage job passed. Perpetual funding changes cash and equity and survives artifact export and recovery; the LEAN crypto pair passes in retained real-strategy evidence. Real-strategy evidence records the supported LEAN crypto comparison.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    compatibility: affectedHas Python, platform, dependency, or cross-library compatibility impactpriority: highMaterial user impact requiring prompt remediationstatus: acceptedAccepted for implementationtype: featureNew or expanded user-facing behavior

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions