Methodology

reout · Systematic BTC. This document specifies how every figure in this repository is produced. Part A defines what is measured and from which sources (sections 1 to 3), Part B how each figure is calculated (sections 4 to 8), Part C how the figures are published and verified (sections 9 to 11), and Part D how the documents and the program may change (sections 12 to 14).

Status. This document is pre-registered. Its hash is anchored on the Bitcoin blockchain before the record begins (section 14). Changes are versioned, hashed and timestamped before they take effect (section 12). Where a published figure disagrees with the code that generated it, the code and the exchange responses received by the workflow take precedence, and the disagreement is treated as an incident (section 10).

Relation to industry standards. No claim of compliance is made with the Global Investment Performance Standards (GIPS). Compliance is claimed by a firm as a whole and carries presentation requirements that this record does not meet, and independent verification, which the standards recommend but do not require, has not been obtained. The methodology follows the standards' principles where they apply and uses their terminology so that a reader familiar with them can map each section: returns are time-weighted, with external cash flows treated under a policy fixed in advance (section 4); returns are calculated after transaction costs and reflect the leverage actually employed, and gross of fees equals net of fees while no fees are charged (sections 1 and 3); the leverage-normalized series is supplemental and is never linked to actual returns (section 5); the composite is the account register, consisting entirely of proprietary, non-fee-paying capital, and accounts are never removed from the history (section 13); a benchmark is defined and disclosed (section 8); policies are documented and hashed before use (sections 12 and 14).

---

Part A. Scope and valuation§

1Scope of measurement§

The table defines the program as measured. A change to any item in it is a change to the program. It takes effect only after this document has been revised under section 12 and the change has been announced in a monthly report, and the date of the change is stated in every subsequent report. Past figures are not restated.

Pilot. From account inception to record inception the program traded the designated account as a pilot, run in live conditions so that defects could be found and corrected before measurement began. The pilot is not part of the record. Its results are published once, in the pilot report (section 10), and are labelled as pilot results wherever they appear. They are not linked to the record, not included in any figure since record inception, and not assessed against the Kill Criteria. Defects found and corrected during the pilot are not itemised.

2Data sources of the record§

All figures derive from responses of the exchange API, retrieved by a public GitHub Actions workflow (.github/workflows/pull.yml) with a read-only key that cannot trade or withdraw. The runner commits the responses and the derived files under the GitHub Actions service account. No file in raw/ or data/ is written or edited by hand, and a commit by any other author would be visible in the history. The key is separate from the keys used for trading, which are never stored in this repository or its secrets.

Requests to the exchange may pass through network infrastructure operated by reout. Connections are encrypted end to end between the workflow and the exchange, and the workflow verifies the exchange's certificate, so that infrastructure can neither read nor alter a request or a response.

The account responses (balance, positions, income ledger and fills) are not published: they disclose the size of the account, the positions it held and the time and size of every fill. The exchange's daily record carries the positions open at the valuation point, with the mark price of the record, alongside the balance; the unrealized P&L is computed from them (section 3), and no position or fill is published. The account responses are retained in encrypted form in a private repository, as one copy of all the responses each run receives; the SHA-256 hash of the unencrypted copy received by the run that publishes a day is included in that day's anchor, and verifiers are given access to the copies (section 11). Published figures are returns and ratios relative to net asset value; no currency amount is published.

The endpoints and field names in use are those in pull.py; each day's files are produced by the version of that script recorded in the same commit. A change of endpoint or field name that leaves these quantities unchanged is a code change, visible in the repository history, and not a change to this document.

The workflow runs once a day. The exchange composes its record of a day's balance only after that day has ended, so each run publishes every day whose record has since become available and is not yet published; a day therefore appears on the day after it ends. The exchange's timestamp of each daily record is carried into mark_ts_utc, and that timestamp, not the time of the request, is the valuation point. It falls at the end of the day, in the same UTC day as the close of the benchmark's daily candle and before the funding settlement that opens the next day, so that the account mark and the benchmark close refer to the same day and each funding payment falls in the day that incurred it. A run started by hand after a missed schedule executes the same code and is listed as an incident.

A second, independent ledger of the designated accounts is maintained on reout's own server. The monthly report states whether the two ledgers and a record of the month's transactions generated by the exchange itself agree (section 10).

Exchange responses are not cryptographically signed by the exchange. What the record establishes is the content the public runner received, the time at which it was committed, and the anchoring of its hash on Bitcoin (section 11).

3Valuation§

Valuation point. The account is valued once a day, at the instant at which the exchange marks its daily record of the account, recorded as mark_ts_utc. That instant is the end of the UTC day. The valuation interval of a day runs from the previous valuation point (exclusive) to the current one (inclusive), and every daily quantity of the account is measured on these points and intervals. The first valuation point of the record is record inception (section 1). Its net asset value, which includes open positions at their mark, is the base of the record: P&L accrued before it belongs to the pilot, and P&L after it to the record. If a valuation point is missed, the next interval spans the missed days and the omission is listed as an incident (section 10).

Net asset value. nav = wallet + unrealized, where wallet is the wallet balance in the exchange's daily record, excluding unrealized P&L, and unrealized is the sum, over the positions in that record, of each position's signed size times the difference between the record's mark price and the position's entry price. Every term refers to the valuation point, so nav is a mark-to-market value that includes open positions. A total of unrealized P&L stated by the exchange is not used, since nothing establishes that it was struck at the valuation point. Before a day is published, the workflow confirms against the exchange's public mark-price history that the record's mark price is the mark price at the end of that day, and confirms that the size and entry price of every position in the record follow from the previous record and the fills between the two. Exchange commissions and funding payments are charged inside the account and are therefore reflected in nav and in every return figure. Taxes are not deducted.

External cash flows. An external cash flow is a transfer into or out of the designated account. Each transfer is assigned to the valuation interval in which its exchange timestamp falls; F_t is the net transfer of interval t. Transfers are the only external cash flows: realized P&L, commissions, funding and any other income type reported by the exchange are internal to the account and are not flows.

Aggregation. Where more than one account is listed in the account register, wallet, unrealized, nav and F_t are sums across the accounts at the same valuation point (the aggregate method), so that the record is a single series regardless of the number of accounts.

Part B. Calculation§

4Returns§

Daily time-weighted return. The net transfer of the interval (section 3) is treated as occurring at the start of the interval:

$$r_t = \frac{\mathrm{NAV}_t}{\mathrm{NAV}_{t-1} + F_t} - 1$$

where $\mathrm{NAV}_t$ is the net asset value at valuation point $t$ (section 3) and $F_t$ is the net external transfer of the interval ending at $t$. $r_t$ is published as ret_twr and $F_t / \mathrm{NAV}_{t-1}$ as flow_frac; the currency amounts themselves are not published (section 9).

Flows are infrequent. The start-of-interval convention is fixed here so that it cannot be selected after the fact. Days on which a flow occurred are identified in the monthly report together with the timestamp of the flow.

Period return. The geometric link of the daily returns in the period:

$$R = \prod_{t \in \text{period}} (1 + r_t) - 1$$

Periods are UTC calendar months. The first period runs from record inception to the end of that month.

Money-weighted return. The annual rate $y$ that equates the net asset value at record inception and the external transfers since, compounded to the current valuation point, with the net asset value at that point:

$$\mathrm{NAV}_T = \sum_{i} F_i \,(1 + y)^{(T - t_i)/365}$$

where $F_i$ is the net asset value at record inception, treated as an initial deposit, or a subsequent transfer (deposits positive, withdrawals negative) at time $t_i$, $T$ is the current valuation point, and times are measured in days. This is the XIRR convention. Until the record spans 365 days it is stated for the period, $(1 + y)^{(T - t_0)/365} - 1$ where $t_0$ is record inception, rather than as an annual rate, since annualizing a shorter period exaggerates it. It is computed by the workflow from the unpublished amounts and, being invariant to scale, can be reproduced from flow_frac and nav_idx. The time-weighted return measures the strategy; the money-weighted return measures what the capital earned. Both are reported.

5Leverage-normalized series (ret_l1)§

The live account runs at the notional multiple $L$ stated in section 1, three at record inception. To allow comparison with unlevered strategies and with the benchmark, a derived series at one times notional is published:

$$r^{(1)}_t = \frac{r_t}{L}$$

where $r_t$ is the daily time-weighted return of section 4 and $r^{(1)}_t$ is published as ret_l1. Holding the same positions at $1/L$ of the notional-to-equity ratio scales the daily P&L, including commissions and funding, by $1/L$. Path-dependent effects that arise only at the live multiple, such as margin calls or liquidation, are not modelled. Should such an event occur, it is reported as an incident and the derived series is annotated at that date.

ret_l1 is labelled as derived wherever it appears. It does not correspond to a traded account.

6Risk statistics§

$r_t$ is the daily time-weighted return of section 4 and $I_t$ its cumulative index, nav_idx (section 9). Drawdown and days underwater are measured on the index rather than on net asset value, so that an external transfer is neither a loss nor a recovery. Because $\mathrm{NAV}$ is marked to market, these statistics include unrealized changes in open positions.

7Trade statistics§

Trade-level statistics (number of trades, holding times, long and short shares, gaps between trades) are not published. They are computed by the workflow from the unpublished income ledger (section 2) and are available to verifiers under NDA (section 11). Individual fills are not published; see the Disclosure, section 2.

8Benchmark§

The benchmark is a buy-and-hold position in bitcoin, measured by the spot BTCUSDT daily close of the venue listed in the account register, without leverage or costs. A change of venue does not restate past benchmark values. It is compared with the one-times derived series rather than with the three-times live account, since a comparison across different leverage would not be informative. The correlation of daily ret_twr with ret_btc is reported monthly.

The backtest is not a benchmark. Live results are assessed against the thresholds pre-declared in the Kill Criteria (sections 2 and 3; section 10) and are not compared with simulated returns.

Part C. Publication and verification§

9Published files§

No currency amount is published. Every published figure is a return or a ratio relative to net asset value, so the record shows the program's performance and not the size of the account.

data/equity_daily.csv. One row per UTC day covered by the record. date_utc is the day that the valuation interval covers: a row dated D is struck at the mark that ends D, and its benchmark close is the close of the daily candle for D. Returns and ratios are decimal fractions. A missed valuation point has no row, and the next row's return spans the gap (section 3). The first row is record inception: nav_idx and nav_l1_idx are 100, and it has no ret_twr, ret_l1, flow_frac or ret_btc. The benchmark comparison starts at the same valuation point.

data/transfers.csv. Every external transfer: ts_utc and amount_frac, the transfer as a fraction of the net asset value at the preceding valuation point, positive for a deposit.

data/income_daily.csv. One row per UTC day with the sums of the income ledger records whose timestamps fall in the day's valuation interval, each as a fraction of the net asset value at the previous valuation point: realized_pnl_frac, costs_frac (commissions and funding payments combined) and other_frac; other_types names the types grouped under other_frac on the day, without their separate amounts. Commissions and funding are combined because their separate totals would disclose position size and utilization; the split is available to verifiers (section 11). The monthly report names the types grouped under other_frac when they occur.

data/monthly.csv. One row per calendar month, produced by the daily workflow: for the month and since record inception, the time-weighted return, the risk statistics of section 6 and the benchmark return of section 8; the money-weighted return since record inception (section 4); and the account's position on each metric of the Kill Criteria at the last valuation point the row includes, which the row states. The row of the month in progress is replaced by each daily run until the month ends, after which it is final.

data/corrections.csv. Corrections to data values (section 10), append-only. Empty until a correction is needed.

raw/YYYY-MM-DD/. The published exchange response of the day, btc.json, unmodified (section 2).

pilot/. The pilot report and the daily series it is computed from, in the columns of data/equity_daily.csv. These files are not part of the record (section 1).

10Reports, reconciliation and corrections§

Canonical record. The data files data/equity_daily.csv, data/income_daily.csv, data/transfers.csv and data/monthly.csv, together with the published benchmark responses in raw/ and the anchored hashes of the unpublished account responses (section 2), constitute the record. Files in pilot/ are not part of it. The monthly report, the tear sheet, the PDF and the pages of the public site are renderings of these files produced by a script in this repository. Any two renderings of the same period show the same figures because they are derived from the same source.

Daily publication. The workflow commits raw/, data/ and the day's manifest and proof (section 11). The commit author is the GitHub Actions service account.

Monthly report. tools/monthly_report.py, located in this repository and taking every figure from data/, generates reports/YYYY-MM.md and, rendered from it, reports/YYYY-MM.pdf. The workflow commits both on the third day of the following month at 00:00 UTC, irrespective of the result. No month is omitted; a month without trades is reported like any other. The first report covers the part of the month from record inception. The PDF is the form intended for distribution; the Markdown is the form intended for line-by-line comparison. Each report contains:

1. Returns: the time-weighted return for the month and since record inception, the money-weighted return since record inception, and the nav_idx and nav_l1_idx series to date (sections 4 and 5).
2. The risk statistics of section 6, for the month and since record inception.
3. Benchmark: the benchmark return for the month and since record inception, and the correlation of section 8.
4. Position against the kill criteria: the current value of each metric in the Kill Criteria next to its three pre-declared thresholds, computed as defined in sections 4, 6 and 7. None of the thresholds is an automatic stop; the action taken at each is specified in the Kill Criteria.
5. Flows and costs: every external transfer of the month with its timestamp, and the month's total costs, each as a share of net asset value.
6. Version: the program version in force on each day of the month (section 12).
7. Reconciliation, changes and incidents, as set out below.
8. The SHA-256 hashes of the month's data files and the location of their proofs. A file cannot state its own hash: the hashes of the report, in both forms, are anchored beside it, and the PDF states the hash of the Markdown it is rendered from (section 11).

The figures are generated. The descriptions of changes, of incidents, of the findings of reviews under the Kill Criteria and of any reconciliation difference are written by reout at the time, published with the record, and carried into the report for their month; they are the only text in the report that is not generated.

Reconciliation. Each report states whether three sources agree for the month: the record's ledger (the account responses retained for the record, section 2), reout's server ledger and a record of the account's transactions generated by the exchange itself, apart from the responses the workflow retrieves. Agreement means that (1) the wallet balance at the month's last valuation point matches across the three sources to within 0.01 USDT, the exchange's record giving it as the sum of the account's transactions from account inception, unrealized P&L being excluded because the sources mark at different times; (2) the cumulative sum of the income ledger equals that wallet balance; and (3) the same transfers, with the same timestamps and amounts, appear in all three. The comparison is made on currency amounts, which are not published; its outcome is published without any amount and the report states it. A comparison not complete when the report is published is stated as such, and its outcome is given in the next report. Any larger difference is stated and explained.

Changes. The report announces, before they take effect, changes of account (section 13), of program version (section 12) and of any item in section 1, and records the date on which an announced change took effect.

Corrections. Published files are not edited, with one exception: the row of the month in progress in data/monthly.csv is replaced by each daily run until the month ends (section 9), and each day's version of the file is anchored in that day's manifest (section 11). An error in a report is corrected by a new file, reports/YYYY-MM.correction-N.md, stating what was incorrect, the cause and the corrected figures. An error in a data value is corrected by a row in data/corrections.csv (date, file, column, published value, corrected value, reason), which the rendering scripts apply; the erroneous value remains in place. A correction is issued for any error in a published figure, whatever its size, and is anchored in the same way as the report (section 11).

Pilot report. At record inception the pilot report is published, derived as in sections 3 to 6 from the exchange's records of the pilot period, which the workflow retrieved and retained day by day (section 2); the valuation point of each day is the exchange timestamp of the record it is derived from. The pilot's first valuation point is account inception, where the net asset value is the first deposit, so that the report covers the pilot from its first day. Those records are hashed and anchored as the daily account responses are. Every page of the report states that it covers the pilot and that its results are not part of the record.

Incidents. From record inception, every operational incident (outage, missed valuation point, manual action, defect, exchange downtime) is listed in the report for the month in which it occurred, with its time, its effect on the record and the remedy, including incidents with no effect on P&L. Each incident is entered in the incident log when it occurs, and manual actions are also logged in the intervention log.

11Anchoring and verification§

Each daily commit includes a manifest, attest/YYYY-MM-DD.sha256, listing the SHA-256 hash of every file of the day, published and unpublished (section 2), and an OpenTimestamps proof of that manifest, attest/YYYY-MM-DD.sha256.ots. Each monthly report, in both Markdown and PDF form, and each correction are anchored in the same way, and the hashes are additionally posted on the public X account on the day of publication. A proof is complete once the Bitcoin transaction that carries it is confirmed; the workflow upgrades pending proofs, so a proof may show as pending for some hours after its commit.

To verify: check the published files against the manifest with sha256sum -c; run ots verify on the manifest's .ots file, against a Bitcoin node or by comparing the Merkle root it reports with that of the block; read .github/workflows/pull.yml and its public execution logs to see how the figures were produced; compare the published responses in raw/ against data/. A verifier with access to the unpublished responses can complete the comparison.

Verifier access. A prospective allocator or an independent verifier may request, under NDA, a separate read-only API key to the designated account, records of its transactions generated by the exchange, the unpublished daily responses (section 2), individual fills, and the sealed configuration file whose hash appears in the pre-registration manifest. Requests are addressed to ops@reout.io. Grants are logged in the verifier register.

Part D. Governance§

12Changes to the documents and to the program§

Documents. This document, the Disclosure and the Kill Criteria are versioned. A change is made by writing the new version, hashing and anchoring it, recording the change and its reason in the changelog, and only then applying it to future reports. Past reports are not recomputed under a later methodology. The thresholds in the Kill Criteria are not changed while the account is in a drawdown.

Program versions. The strategy is researched continuously and the deployed version changes over time. The record belongs to the program, not to any version of it. Every deployed version is listed in the version register with its deployment date, the class of the change and the hash of its sealed configuration, which is anchored before deployment. The monthly report states which version ran on which days. Changes are of three classes:

A change of version does not reset drawdown, days underwater, trailing windows or losing streaks; these are measured on the program's single series. Renewals follow a schedule announced in advance and are neither brought forward nor deferred on account of recent results. A renewal that fails its pre-declared acceptance test is not deployed, and the report says so. No version is changed in response to a loss.

13Account roster and transitions§

The record is the sum of the accounts listed in the account register. Adding or removing an account follows a fixed procedure so that a change of account cannot be used to exclude a period from the record:

1. The change is announced in the "Changes" section of the monthly report before it takes place.
2. The account register is updated, hashed and anchored.
3. Capital is moved only through transfers that appear in data/transfers.csv on both sides.
4. Both accounts remain in the ledger for the overlap period.
5. The old account is removed only after its balance is zero and reconciled.

Former accounts remain in the ledger permanently.

14Pre-registration§

Before record inception, the following are hashed and anchored on Bitcoin in the pre-registration manifest: the date of record inception; this document; the Disclosure; the Kill Criteria; the account register; the version register; and the sealed configuration of the deployed strategy (hash only; the file is not public). The purpose is to make any later change to the methodology, the deployed configuration or the thresholds detectable rather than a matter of trust.