Sources, dated
We do not certify a source, we date a verification. Here are the five conditions for entering the list, the list itself, and the two mentions every report carries.
This text is what stands: it is what the reports, the acknowledgement and the other pages quote, word for word. It changes only with a date.
Sources
What we have verified, and when.
The rule: we do not certify a source, we date a verification
A perpetual certification goes stale in silence the moment the source changes its export. A dated verification never goes stale: it ages — visibly — and you decide whether it is still fresh enough.
That is the rule we apply to the public register: declare first, note after, never erase. We apply it to ourselves first.
The five conditions to enter the list
- At least two real files, from two different accounts. No test file generated by us counts. A single file cannot distinguish the format from its owner's quirks.
- At least one file older than twelve months and longer than fifty lines. Formats change. A recent export tells us nothing about what we will read from someone who has been investing since 2021 — and that is exactly the person this audit is for.
- The required fields fill without manual intervention, or the missing ones are named. A source with missing fees can still be covered, as long as its sheet says so and the report degrades accordingly.
- A coverage sheet is published: test date, exact export name in the source interface, columns found, fields not obtainable, resulting degradation, observed caps.
- A twelve-month re-verification date. After that deadline, the sheet itself displays “verified on DD/MM/YYYY — not re-verified for N months”.
There is no exit criterion. A source never leaves this list and a sheet is never rewritten: it is dated, then replaced by a newer sheet, the older one remaining available.
The list
Status on 21/09/2026 — no coverage sheet has been published yet. The six entries below are the sources we qualify first, during our first twenty audits. As long as a sheet has not been published with its date, the source is not certified — and this page says so rather than pretending coverage already exists.
Each row now carries its channel: a deposited export and an API reading — direct, machine-to-machine access to an account's data — are two distinct verifications. The same operator can be verified on one and not the other. That is why Kraken has two rows — and so does Binance, since 21/09/2026: the Spot export and the transaction history are two different exports that do not carry the same movements.
binance.spotbinance.transactionskraken.trades · kraken.ledgerskraken.apiledgerlive.csvSEXTANT_LEDGER_V1
| Source | Format | Channel | What we already know | Status |
|---|---|---|---|---|
| Binance — Spot export (the spot market: direct buys and sells) | binance.spot | Export | Treated as an archive: a frozen format cannot break anymore. Publisher-documented caps, read on 22/08/2026: one year max per statement, 10,000 rows under six months, five statements per month. A three-year history therefore arrives in several files — that is expected. | Being qualified |
| Binance — transaction history (all accounts: Spot, Funding, margin — one row per asset movement) | binance.transactions | Export | Header read on a real file on 15/09/2026: seven columns, a single leg per row — a trade is two rows to pair, a savings placement a single one, and the direction is read from the sign of the amount, not from the label. This export, not the Spot export, is the one that carries crypto-to-crypto conversions and fees line by line. Observed on that file: two years of operations in a single statement. An operation label we do not know is rejected and counted, never guessed. | Being qualified |
| Kraken — Trades and Ledgers reports | kraken.trades · kraken.ledgers | Export | Documentation read on 22/08/2026: the Trades report carries execution details; the Ledgers carry fees. Generation can take from a few minutes to a week — plan for it. | Being qualified |
| Kraken — read-only API key | kraken.api | API, read-only | The same account, read directly at the source instead of through a deposited file. The documentation we read on 22/08/2026 describes permissions limited to consultation: a key that can neither withdraw nor place an order. This channel changes the nature of the proof — a file can be edited by the person who submits it; a direct reading cannot. | Declared — qualification will follow the launch of our source-side reading |
| Ledger Live — CSV export | ledgerlive.csv | Export | Read in the publisher's source code on 22/08/2026: twelve columns, multi-account, countervalue included as of the operation date — which avoids having to recalculate it. Two known limits: there is no “exchange” type, so an exchange reads as two unrelated operations; and commas are stripped from values with nothing to protect them — a value that contained one is silently corrupted. | Being qualified |
SEXTANT_LEDGER_V1 | — | File you produce | The format described in part 01. This is not a platform: it is the source you can produce yourself, or that a third-party tool can produce for you. | Published as 1.0.0-draft |
Then, in this order, and only once the first ones are certified: Coinhouse, SwissBorg, and universal import formats used by portfolio-tracking tools.
What is not a source
A software wallet is not a source: it is an address. The most common wallets produce no native export and point to block explorers. We therefore do not claim to cover them today. If that is your case, write to us: declared-address reading is an open track, and its scope will be set by real cases, not in the abstract.
If your source is not in the list
That means we have never tested its export — not that we cannot read it.
Send us your file at [email protected]: you will get your report, and it will be marked “uncertified source”, because we do not lie about what we have verified. And if your file lets us qualify the source, it enters this list, we tell you so, and your next report will be certified.
The two labels every report carries
They answer two unrelated questions, and we do not confuse them:
| Label | The question it answers |
|---|---|
| Certified or accepted | Have we tested and dated this format? That is a question about our competence. |
| Declared piece or verified at source | Can the person being measured change what they give us? That is a question about data integrity, and it is independent from the first one. |
The second label follows from the channel in the list above: a deposited export remains a declared piece; a reading through a read-only API key is verified at source.
A file from a certified source is still a file its owner can edit. It therefore cannot carry the same label as a reading taken directly at source, in read-only access. The public register and the “Verified by Sextant” label require a source-side reading; an audit report can live with a declared piece, as long as we say so.
↑ Contents