العربية
Back to the methodology

Public research record

We stand by our standards.Whatever the results.

At ALQA, we document the criteria used to assess our portfolios, record amendments and disclose exceptions. We publish the fingerprints of our research registry alongside publicly verifiable timestamps. This lets you examine the basis for our conclusions and understand the limits of what the tests establish.

Explore the recordHow to verify
05Public timestamp sealsExplore the seals

Registration and testing records

Read the registration log, dated amendment notes and report metadata together. These selected extracts show what the records say; a public timestamp alone does not establish the whole sequence.

  1. 01

    Registration

    Original registration · UTC

  2. 02

    Amendments

    Amendment entries · UTC

  3. 03

    Testing records

    Report generation · UTC

    • T2
    • T6
    • C1
    • T5b

What the records establish

Every pass line was fixed at registration, before any test was run on the portfolios, with one disclosed exception: the selection-luck test, the deflated Sharpe ratio, had been computed once before registration at the owner’s question; it is logged as prior exposure and was run again after registration under the fixed line. Eight dated and fingerprinted amendments followed. Each one added a test, a case or a disclosure, or fixed a build detail before that test ran. None re-ran a test to change its result, and none moved a pass line or changed a verdict. Two were written after a result had been seen and are labelled so: the first corrected how the tried ideas were counted and kept the registered, harsher count as the gate; the second corrected the cost convention of the capacity disclosure, which has no pass line. The public seals anchor the registry’s fingerprints to their dates.

The eight amendments, in plain words

  1. After the count of tried ideas had been seen: twenty-four variants of one intraday idea had been counted as twenty-four ideas. The corrected count is recorded beside the registered one, and the registered, harsher count stays the gate. No pass line moved, no verdict changed.
  2. Before the false-pass simulation ran: a fourth no-skill case was added to it, a strategy with market exposure and no skill. Pass lines unchanged.
  3. Before the false-pass simulation ran, found by the tool’s own timing check and not by a result: each case runs at two noise levels, so the simulation can say something about the gate it checks. Pass lines unchanged.
  4. Before the 2008 proxy ran: its build and its dates were fixed. Pass lines unchanged.
  5. Before any run: a new disclosure was queued, the capacity test, which asks how much client money a portfolio can carry before its own trading moves the figures. No pass line.
  6. Before the capacity test ran: two of its inputs were fixed, the weights from the real holdings and the Bitcoin leg’s volume and volatility from the second price source.
  7. After the capacity test’s first result had been seen: its cost convention was corrected to the one the published figures carry, 10 basis points a side on the Bitcoin leg. The first result stays in the history and is superseded. The capacity test is a disclosure with no pass line.
  8. Before it ran: a disclosed add-on to the alpha test, the return measured against the funds the portfolio holds. No pass line.

The rule, in one sentence

An amendment is dated, fingerprinted and appended; one made after a result is seen is labelled so and cannot move the pass line of a test already run. No test was run again to improve a result. What was added after registration was more testing of the findings, not a change of them.

Read the source extracts

Registration log

specs/FROZEN_PORTFOLIO_VALIDATION_REGISTRATION_LOG.md

  1. FROZEN_PORTFOLIO_VALIDATION_v1.yaml

    f4915f023842f206

    none (T2 computed once before registration at the owner's question, logged in prior_exposure; to be re-run)

  2. FROZEN_PORTFOLIO_VALIDATION_v1.yaml (amendments 1-2 appended)

    2c9a5b773b169a0a

    T3, T2, W1-W5 on file; R4 running on the nodes; T6 not yet run

  3. FROZEN_PORTFOLIO_VALIDATION_v1.yaml (amendment 3 appended)

    821a57ec6d3bf27a

    T6 not yet run

  4. FROZEN_PORTFOLIO_VALIDATION_v1.yaml (amendment 4 appended)

    d5d194b566831a5f

    R1 not yet run

  5. FROZEN_PORTFOLIO_VALIDATION_v1.yaml (amendment 5: C1 capacity, queued)

    9dfeb7d9580adbc3

    C1 not yet run; T9 step 1 running

  6. FROZEN_PORTFOLIO_VALIDATION_v1.yaml (amendment 6: C1 inputs)

    9e71aaa3df9be796

    C1 starting; T9 step 1 running

  7. FROZEN_PORTFOLIO_VALIDATION_v1.yaml (amendment 7: C1 base costs, labelled after a first result)

    c81cb2f9f5f9cced

    C1 re-run follows

  8. FROZEN_PORTFOLIO_VALIDATION_v1.yaml (amendment 8: T5b)

    c13da69421febc3c

    T5b not yet run

Dated specification notes

specs/FROZEN_PORTFOLIO_VALIDATION_v1.yaml

  • 1_fixed_before_the_data: pass lines, methods and the gating list are fixed here; a result is read against these lines only
  • 2_pre_registration_runs: T2 above is logged as a pre-registration run and re-run; no other test in this specification has been run on the subjects
  • 3_amendments: dated, hashed, appended; an amendment made after a result is seen is labelled so and cannot move a pass line of a test already run
  1. (2026-10-17, 20:45 UTC, AFTER T3's registered result N_eff = 168 was seen - LABELLED as such; it moves no pass line and changes no gating verdict)
  2. (2026-10-17, 20:45 UTC, BEFORE any T6 run)
  3. (2026-10-17, 20:50 UTC, BEFORE any T6 run; found by the tool's 40-strategy timing check, not by a result)
  4. (2026-10-17, 21:05 UTC, BEFORE any R1 run - the addendum R1 method called for)
  5. (2026-10-18, 00:40 Riyadh / 2026-10-17 21:40 UTC, BEFORE any run; the owner's word 'I want to have this queued as it shows the capacity')
  6. (2026-10-18, 03:40 UTC, BEFORE any C1 run; the owner's word 'Start the capacity test now, the nodes can share')
  7. (2026-10-18, 03:55 UTC, AFTER a first C1 result was seen - LABELLED as such; C1 is disclosed and has no pass line)
  8. (2026-10-18, 08:05 UTC, BEFORE the run; the owner's question 'so maybe the only point is to strip the leverage impact, right?')

Testing records

  • results/VALIDATION_v1/T2_deflated_sharpe.json

    2026-10-17 20:34:31 UTC

    Specification fingerprint recorded in the report

    f4915f023842f206226b6134f65e58868135c5ba46ae901b08361ed1e540c65d

  • results/VALIDATION_v1/T6_false_pass.json

    2026-10-17 20:47:30 UTC

    Specification fingerprint recorded in the report

    f4915f023842f206226b6134f65e58868135c5ba46ae901b08361ed1e540c65d

  • results/VALIDATION_v1/C1_capacity.json

    2026-10-18 03:33:02 UTC

    Specification fingerprint recorded in the report

    f4915f023842f206226b6134f65e58868135c5ba46ae901b08361ed1e540c65d

  • results/VALIDATION_v1/T5b_alpha_held_funds.json

    2026-10-18 08:41:00 UTC

    Specification fingerprint recorded in the report

    f4915f023842f206226b6134f65e58868135c5ba46ae901b08361ed1e540c65d

Source file SHA-256

specs/FROZEN_PORTFOLIO_VALIDATION_REGISTRATION_LOG.md
efeea0cc60dfa6206ed23745bc42b81c016efa8afea94246530997b73d419627
specs/FROZEN_PORTFOLIO_VALIDATION_v1.yaml
c13da69421febc3c6722d00230e0eb0db2571a4afca44d0a19868a63ee440d2e
results/VALIDATION_v1/T2_deflated_sharpe.json
74875251cc3992b0f2af56587a149d8636a1f6ef1a41dd179f1dfd943e9b519e
results/VALIDATION_v1/T6_false_pass.json
59db33f525dee60225857b1f0d8acb950e1e59c3202adefee8862a07b20b796b
results/VALIDATION_v1/C1_capacity.json
5640e6a8a773d05e2e08d18c0560bc4416f44e43ceb517b9e97d440f016c0016
results/VALIDATION_v1/T5b_alpha_held_funds.json
9dab34f396c3b760e2225ee7f6faf24402835bc858bc80ad994d4ef75b8f00ce
Download the registration record extracts · JSON
  1. Seal01

    New York

    24 Oct 2026, 00:23 · Riyadh

    Attested in block 972834

    Fingerprint · SHA-256
    b7b378e54e14e512a9902862144650311faeafab09b270b76d3957833ae78746
    Proof file · download
    REGISTRY_DIGEST_2026-10-24.sha256.ots
    Download proof
  2. Seal02

    New York

    23 Oct 2026, 11:56 · Riyadh

    Attested in block 972749

    Fingerprint · SHA-256
    f3d2f3b4c5600e3f9e69638f051ec684b9efc1b577c3aea8de2cd9530199192e
    Proof file · download
    REGISTRY_DIGEST_2026-10-23.sha256.ots
    Download proof
  3. Seal03

    New York

    20 Oct 2026, 12:09 · Riyadh

    Attested in block 972301

    Fingerprint · SHA-256
    aad70330d4f37783632f83a26ab3c64e96a10b655abd044392710bccc2132430
    Proof file · download
    REGISTRY_DIGEST_2026-10-20_dossiers_v2.sha256.ots
    Download proof
  4. Seal04

    New York

    20 Oct 2026, 11:50 · Riyadh

    Attested in block 972295

    Fingerprint · SHA-256
    5263b478c34dca1d0a455a7ac922de5211766ad11f41dea1ece33ac49ef9a901
    Proof file · download
    REGISTRY_DIGEST_2026-10-20_dossiers.sha256.ots
    Download proof
  5. Seal05

    New York

    20 Oct 2026, 11:35 · Riyadh

    Attested in block 972295

    Fingerprint · SHA-256
    8849a3261342daee051371f1fe7d0f274a65e2d827af87957fe6102e7ee97538
    Proof file · download
    REGISTRY_DIGEST_2026-10-20.sha256.ots
    Download proof

How to verify

  1. Identify the fingerprint

    The fingerprint shown is the SHA-256 of the sealed digest file; the proof file (.ots) commits to that fingerprint.

  2. Open the public proof

    Open the proof with any OpenTimestamps client (for example the verifier at opentimestamps.org): it names the Bitcoin block that holds the commitment once attested.

  3. Compare the documents

    When ALQA provides you a document together with the digest, recompute the digest's SHA-256 and compare it with the fingerprint here; then compare the document's own SHA-256 with its line in the digest.

The registry’s contents are provided to reviewers with the documents they examine. Nothing here is a performance figure.