Strategier

BTC cash-and-carry med konvergens i kvartalsbasis, markedsneutral (lang BTCUSDT.BINANCE_SPOT + kort den BTC USD-M DATED QUARTERLY-future med nærmeste udløb, beholdt til afregning for at indfange DETERMINISTICALLY-CONVERGENT-contangobasis — NOT perp-funding, rullet ved udløb, 2-parameter)

Resultat: Opgivet

BtcQuarterlyBasisConvergenceCarryNeutral

Resultatoversigt

Strategien foreslog en reelt anderledes edge end fabrikkens fejlslagne perp-funding-carries — en delta-neutral BTC cash-and-carry, der udnytter basis i daterede kvartalsfutures, som konvergerer deterministisk, holdt til afregning og rullet hvert kvartal med kun to justerbare parametre. Den producerede aldrig en backtest: kørslen fejlede gennem 3 iterationer, fordi motoren ikke kunne hente fundinghistorik for kvartalsbenet 'BTCUSDT_230929.BINANCE', behandlede den daterede kontrakt som en perp og blokerede dermed kørslen af hensyn til nøjagtigheden. Da hverken backtest, backtest-gennemgang, optimering eller analytikerfaserne blev nået, blev strategien opgivet på grund af en data-/infrastrukturafhængighed, ikke dens økonomiske værdi. Hypotesen havde udtrykkeligt advaret om, at tilgængeligheden af data for kvartalskontrakter var den afgørende afhængighed, og det var præcis dér, processen stoppede.

Strategirapport

Hypotese

En MARKET-NEUTRAL cash-and-carry på BTC, der udnytter QUARTERLY-FUTURE-basis, er grundlæggende forskellig fra alle funding/perp-carrystrategier, der er døde i denne fabrik. De døde strategier (BTC/AVAX/BNB/ETH spot-perp, alle fee_edge) byggede på PERP funding — et lille (~1bp/8h i median), ikke-konvergerende cashflow, der aldrig overstiger omkostningen for en tur-retur-handel. En DATED kvartalsfuture er noget helt andet: Den skal konvergere mod spot AT SETTLEMENT (deterministisk, kontraktligt), og BTC kvartalsfutures handles med vedvarende CONTANGO på typisk 5-15% ANNUALIZED (~125-375 bp over en beholdningsperiode på ~90 dage) — en størrelsesorden over de ~0.30% for to ben tur-retur. Den klarer med god margin L1s grænse på >20bp/cyklus, fordi basis er en løbetidspræmie, ikke et funding-tick. Struktur: LONG BTC spot + SHORT den nærmeste børsnoterede BTC USD-M kvartalsfuture med samme nominelle værdi (delta-neutral), behold til (eller tæt på) afvikling for at indfange konvergensen med stort set ONE indgangsomkostning tur-retur og uden gentagne exit-handler (benene konvergerer af sig selv), og rul derefter over i den næste kvartalsfuture. Det omgår ALL de tilbagevendende dræbere: FEE_EDGE — basis >> gebyrer, og beholdning til afvikling betyder ~2 handler pr. kvartal og næsten ingen omsætning; MULTI-REGIME — basis findes og konvergerer i både bull- AND og bear-markeder (ikke en betaeffekt fra ét markedsregime som ved long-only-timere); OVERFIT — 2 parametre (grænse for indgangsbasis, rulningstidspunkt), ingen udvælgelsesflade; og den tilhører ikke den opgivne reversion-klasse. Den udfylder de underrepræsenterede kategorier for handel på tværs af børser (7.3%) og markedsneutral retning. CRITICAL DATA DEPENDENCY (markeret, så den fejler hurtigt frem for at køre i ring): Det kræver historisk kline-dækning af DATED BTC USD-M kvartalskontrakter i kataloget — udvikleren skal kontrollere, om historik for kvartalsfutures er tilgængelig for backtestperioden BEFORE kodning; hvis der kun findes perp-/spotbarer, skal strategien straks opgives (brug ikke perp i stedet, da det ville føre tilbage til den døde funding-carrystrategi).

Iteration 3 løser den eneste blokering i lag -3: røgtesten i sandkassen overskred 300s. Arbejdet pr. bar er allerede O(1) (en løkke med fast størrelse over kvartalskæden — ingen gennemgang af historikken og ingen min()/sorted() pr. bar over data), så den generelle diagnose om »arbejde pr. bar, der skalerer med historikken« passede ikke. Den reelle omkostning skyldtes DATA VOLUME: spot fra 1-DAY spænder over 2017→2026 (~9 år, bekræftet af katalogets filinterval), og de 11 kvartalskontrakter ved 4-HOUR tilføjede ~12k ekstra barhændelser, så den sammenlagte strøm med flere instrumenter (~15k hændelser på tværs af 12 instrumentben, hvert med bogføring af gebyrer/analyser/baseline) overskred budgettet. Den mindste effektive løsning lader hele strategikoden (korrekt krediteret, rulning valideret) være uændret og reducerer kun datamængden via konfiguration: (1) reducér kæden fra 11 til 8 på hinanden følgende kontrakter (stadig ~2 år, 2023H2–2025H1, der spænder over 2023-bjørnemarkedets genopretning og 2024-tyremarkedet — flere markedsregimer, ~8 konvergenser, klart diagnostisk sammenlignet med iter-2s fejlslagne n=1), og (2) gør de supplerende kvartalsdata grovere, fra 4-HOUR til 12-HOUR (2 barer/dag → ~360 pr. kontrakt mod ~1090). Det reducerer hændelsesbudgettet fra ~15k til ~6.1k (~2.4×) og antallet af instrumenter fra 12 til 9, hvilket bør bringe kørslen klart under 300s, mens opløsningen på 12-HOUR er langt finere end nødvendigt for en basis-carry på ~90 dage og fortsat anvender en tidsramme, der er DIFFERENT end den primære 1-DAY (så den fortsat er undtaget fra barrieren for justering af samme tidsramme, der ellers ville fastlåse udløbne kontrakter). Jeg kontrollerede, at alle 8 kontrakter har ikke-tomme 12-HOUR-barer (ingen kvartaler springes lydløst over), og at de udgør en ubrudt kæde af på hinanden følgende kontrakter fra sep23 til jun25, så rulningen forbliver kontinuerlig. Ingen kodelogik, importer eller de to justerbare parametre blev ændret — lag 1–2 og den validerede rulningsadfærd er bevaret; kun listen over supplerende data og deres tidsramme blev ændret for at passe til ydelsesbudgettet.

backtest_failed: RuntimeError: Fundingdata ikke tilgængelige for perp-ben 'BTCUSDT_230929.BINANCE' — indsamling efter behov mislykkedes, eller handelspladsen har ingen fundinghistorik (backtest blokeret af hensyn til nøjagtighed; angiv SF_DISABLE_ONDEMAND_FUNDING=1 for at omgå) Traceback (seneste kald sidst): File "/opt/strategy-factory/src/agents/backtest_agent.py", line 190, in _run_backtest await self._ensure_funding_for_perp_legs(instrument_id, extra_instrs) File "/opt/strategy-factory/src/agents/backtest_agent.py", line 406, in _ensure_funding_for_perp_legs raise RuntimeError( RuntimeError: Fundingdata ikke tilgængelige for perp-ben 'BTCUSDT_230929.BINANCE' — indsamling efter behov mislykkedes, eller handelspladsen har ingen fundinghistorik (backtest blokeret af hensyn til nøjagtighed; angiv SF_DISABLE_ONDEMAND_FUNDING=1 for at omgå)

Implementering

Markedsneutral BTC cash-and-carry, der udnytter basis på DATED kvartalsfutures og ROLLS gennem en kæde af sammenhængende kvartalsfutures. Primær = BTCUSDT.BINANCE_SPOT (1-DAY, kontinuerlig, styrer tidsforløbet); ekstra = otte sammenhængende daterede kvartalsfutures af typen BTC USD-M (BTCUSDT_230929 … 250627) på 12-HOUR-barer (en grovere, anderledes tidsramme end den primære, så udløbne eller endnu ikke noterede kontrakter ikke låser justeringsbarrieren for samme tidsramme, og hændelsesstrømmen med flere instrumenter forbliver lille). For hver spotbar identificerer den den LIVE kvartalsfuture med nærmest udløb og tilstrækkelig tid til konvergens (≥ min_entry_days), beregner dens annualiserede basis ((future − spot)/spot × 365/dage til udløb), og åbner carry-positionen, når basis er ≥ entry_basis_annual, mens strategien ikke har en åben position: LONG spot med samme nominelle beløb (CASH-sikker BUY) + SHORT kvartalsfuturen (BINANCE MARGIN), delta-neutral. Den HOLDS til roll_buffer_days før afregning, CLOSES begge ben og ruller derefter til næste aktive frontkvartal — ~4 konvergenser/år. En beskyttelse mod ubeskyttede ben lukker begge ben, hvis kun det ene findes. Udløb udledes af symbolet for hver kontrakt; positioneringen er lineær (nominelt beløb/pris) og har et sti-uafhængigt loft. To justerbare parametre: entry_basis_annual, roll_buffer_days.

Verifikationsresultater

Verifikation mislykkedes (lag 3 — backtest i sandkasse): røgtesten overskred tidsgrænsen på 300s. Det betyder næsten altid, at arbejde pr. bar skalerer med historikken — f.eks. gentagen gennemgang af hele funding-/supplerende dataserien eller genopbygning af en liste og kald af min()/sorted() inde i calculate_signal()/on_bar() for hver bar. Forudberegn sorterede tidsstempelarrays ONCE i __init__, og brug bisect, eller cache opslag med tidsstempel som nøgle, så omkostningen pr. bar er O(log n) i stedet for O(n).

Udvid extra_instruments til kæden af kvartalskontrakter for FULL BTC (~16-20 kontrakter siden 2020) med grovkornede kvartalsbarer på 12H/1D, så de holder sig inden for sandkassens budget, så metrics_reliable=true og walk-forward-vinduerne hver indeholder flere konvergenser. Kun konfigurationsudvidelse — rulningslogikken håndterer allerede kæder af vilkårlig længde.

Konvergensantallet er marginalt (8), og metrics_reliable=false — under de ca. 16-20, jeg sigtede efter i iter-1. Udvikleren satte kædens loft til 8 kontrakter på grund af Layer-3-budgettet. UNLIKE de fejlslagne makrotrendfølgere er dette en konfigurationsjustering, der kan løse problemet, ikke en iboende begrænsning: Flere konvergenser kan let opnås ved at tilføje flere af BTCs historiske daterede kvartalsfutures (tilbage til ca. 2020). Afgørende er, at edge understøttes diagnostisk selv ved n=8: Sharpe CI [1.14, 46.66] har en nedre grænse på POSITIVE (udelukker nul), og fordelingen er velformet (skævhed -0.56, kurtosis 2.37) — en skarp kontrast til trendfølgerne, hvis CI'er spændte over stærkt negative værdier. Den deterministiske konvergens-edge gør 8 næsten uafhængige hændelser til reel evidens, ikke held.

Evaluér primært på walk-forward-konvergenser (udvidet kæde), ikke på holdoutperioden på 15 dage; gør operatøren opmærksom på det, hvis holdout-gaten blokerer gyldige carry-positioner, der holdes gennem et kvartal.

Forbehold om tidshorisont (som ved makrostrategier): beholdningsperioder på ~90 dage betyder, at holdoutperioden på 15 dage indeholder ~0 lukkede konvergenser, så holdout-gaten er strukturelt vanskelig at evaluere. Mindre begrænsende end for trendfølgende strategier, fordi den udvidede kæde giver nok konvergenser til diagnostiske walk-forward-vinduer, men operatøren bør være opmærksom på, at holdout kræver tidshorisontbevidst behandling af carry-positioner, der holdes gennem et kvartal.

Bekræft delta-neutralitet og basisbidrag pr. kvartal i den udvidede kædes fulde backtest.

To analytikertjek (ingen af dem skyldes en kodefejl): (1) exposure_pct 227% — for et delta-neutralt spot+short-fut-par ved capital_frac 0.45/ben er den tilsigtede bruttoeksponering ~0.90x; 227% skyldes sandsynligvis en artefakt fra bruttonotional eller en opskrevet markedsværdi (beta 0.0105, max_dd 3.24%, næsten symmetrisk largest_win/tab bekræfter, at bogen er IS neutral), men kontrollér, at positionsstørrelsen ikke har drevet på den udvidede kæde. (2) avg_loss ($13,905) overstiger en smule avg_win ($12,384) ved win_rate 0.5625 — netto positiv, men nogle kvartaler konvergerer ugunstigt (backwardation/basisudvidelse før rulning); kontrollér, at afkastfordelen ikke bæres af et eller to kvartaler med høj contango.

Ingen kodefejl — rulningen er solid og kan genbruges på en kæde af vilkårlig længde.

CREDIT (ingen fejl): ROLL er korrekt implementeret i overensstemmelse med min anmodning i iter-1 — _candidate vælger den aktuelle kvartalskontrakt med nærmeste udløb og tilstrækkelig tid til udløb (3 dages forældelseskontrol med _live + _dte pr. kontrakt), beholder positionen indtil roll_buffer_days før afregning og ruller derefter til næste frontkvartal, udløb udledt for hver kontrakt, beskyttelse mod ubeskyttede ben, delta-neutrale ben med samme nominelle værdi (lineær, marginkrav i USDT), kun spot i BUY (CASH-sikker), begrænset, stiuafhængig positionsstørrelse, O(1) arbejde pr. bar. Den kvartalsvise tidshorisont på 12-HOUR undgår korrekt justeringsdeadlocken for samme tidsramme for udløbne/ikke-noterede kontrakter, da den er forskellig fra den primære 1-DAY. Mekanismen er valideret: 8 rene konvergenser over 90 dage, ~4/år, levedygtig efter gebyrer (1.06% i provision).

Iterationshistorik

Verifikation mislykkedes (lag 4 — gennemgang af QA): - Hypotesens angivne design med ROLLING MULTI-QUARTER, der rulles ved udløb, er NOT implementeret. Titlen ('Rolled at Expiry') og beskrivelsen ('derefter rulles der ind i det næste kvartalskontrakt') angiver en rullende serie, men koden handler den nærmeste SINGLE-kontrakt (BTCUSDT_241227) og stopper efter én konvergens — der er ingen rulning. Derfor giver backtesten præcis én handel. Carry-logikken pr. kontrakt er korrekt, men rullermekanismen, der gør strategien gentagelig og målbar, mangler. - UNMEASURABLE — sandkassen producerede kun 1 konvergens (total_trades 2 = ét benpar), metrics_reliable=false ('kun 1 dagligt afkast'), data_days 1, Sharpe/PSR/CI alle null. Én handel er ikke diagnostisk (L16/L26): Én gunstig basisindfangning i et 2024-H2-tyremarked validerer ikke vedvarenhed, og optimeringen i 3 faser (følsomhed, walk-forward 3-vinduer, holdout) kan ikke køres ved n=1. Det er den strukturelle følge af den manglende rulning — en carry holdt til afregning har ~4 handler/år, så én kontrakt giver kun 1. - CREDIT (ingen fejl) + dataforbehold for den rullende version: Implementeringen med én kontrakt er CORRECT, og mekanismen er reelt ny og lovende — læser den faktiske DATED-kvartalskontrakt (ikke perp'en, så NOT den døde funding-carry), beregner annualiseret basis korrekt, delta-neutral med lige store nominelle beløb på begge ben (lineær USDT-margineret, undgår COIN-M-fælden), spotben kun BUY (CASH-sikker), udløb udledt af symbolet, beskyttelse mod ubeskyttede ben, begrænset stiuafhængig positionering; den ene konvergens var positiv efter omkostninger (+1.80%), og handelsomkostningerne udgjorde 0.64% af bruttoafkastet — klart over gebyrerne, den første reelt anderledes markedsneutrale mekanisme efter en række fejlslagne mean-reversion-strategier. Når rulningen bygges, skal kline-dækningen kontrolleres pr. kvartal, så en manglende kontrakt ikke lydløst springer kvartaler over.

RuntimeError: Fundingdata ikke tilgængelige for perp-ben 'BTCUSDT_230929.BINANCE' — indsamling efter behov mislykkedes, eller handelspladsen har ingen fundinghistorik (backtest blokeret af hensyn til nøjagtighed; angiv SF_DISABLE_ONDEMAND_FUNDING=1 for at omgå) Traceback (seneste kald sidst): File "/opt/strategy-factory/src/agents/backtest_agent.py", line 190, in _run_backtest await self._ensure_funding_for_perp_legs(instrument_id, extra_instrs) File "/opt/strategy-factory/src/agents/backtest_agent.py", line 406, in _ensure_funding_for_perp_legs raise RuntimeError( RuntimeError: Fundingdata ikke tilgængelige for perp-ben 'BTCUSDT_230929.BINANCE' — indsamling efter behov mislykkedes, eller handelspladsen har ingen fundinghistorik (backtest blokeret af hensyn til nøjagtighed; angiv SF_DISABLE_ONDEMAND_FUNDING=1 for at omgå)

Resultatoversigt

Hypotesen fremhævede tilgængeligheden af daterede kvartalsvise kline-data som en afhængighed, der straks ville få forsøget til at fejle, og det viste sig afgørende: Backtest-harnes'ets krav om fundingdata for futuresbenet skal opfyldes (eller omgås via SF_DISABLE_ONDEMAND_FUNDING), før carry på kvartalsbasis overhovedet kan evalueres.

Strategien blev opgivet efter 3 iterationer, da backtesten fejlede med en RuntimeError: fundingdata var ikke tilgængelige for benet 'BTCUSDT_230929.BINANCE' — motoren behandlede den daterede kvartalskontrakt som en perp, der krævede fundinghistorik, hvilket blokerede backtesten af hensyn til nøjagtighed.

En markedsneutral BTC cash-and-carry, der køber BTCUSDT spot og sælger den daterede USD-M kvartalsfuture med nærmeste udløb. Den holdes til afregning for at indfange den deterministisk konvergerende contango-basis (~5-15% annualiseret) frem for tynd perp-funding.

Der findes ingen resultatmål — backtesten blev aldrig gennemført, så der findes intet afkast, Sharpe-tal eller antal handler; optimeringsfasen blev aldrig nået.

Årsag til opgivelse

Stratmill er et research- og papirhandelsværktøj, ikke finansiel rådgivning eller en mægler. Backtest- og papirresultater er hypotetiske. Handel indebærer risiko for tab.