This page is LinkSilo's transparency report. It describes the categories of legal request we expect to receive, the architectural and procedural limits on what we can disclose in response, the warrant canary statement, the deletion and retention policies that bound the data set in scope, and the contact path for binding legal process. Reports are published annually after the first 12 months of public operation; this page is the structural framework for those reports plus the current pre-launch state.
Last reviewed 2026-05-11 · Reporting framework v1
LinkSilo has not yet operated publicly. No user accounts have been registered through the production environment, no user content has been received, and no legal request of any category has been delivered to LinkSilo, its operators, or its hosting providers. All numeric counts on this page reflect that pre-launch state and are marked accordingly.
The first operational transparency report will publish twelve months after the public launch date, covering the preceding twelve months. Subsequent reports publish annually. Each annual report supersedes the previous; the past-reports archive (Section 9) retains all prior reports without modification.
LinkSilo publishes the following statement and updates it weekly. The continued presence of an updated statement is the affirmative signal. The absence of an updated statement is itself the signal that one or more categories below no longer hold; LinkSilo may be legally prevented from describing the change directly.
Last updated: 2026-05-11 · Next update due: 2026-05-18
As of the date above, LinkSilo has not received, complied with, or been subject to any of the following:
This statement is reviewed and re-signed weekly by LinkSilo's named legal point of contact. If the statement is not updated by the due date listed above, treat its absence as a signal that one or more of the listed categories no longer holds and that LinkSilo may be legally prevented from describing the change directly. The signature is published alongside this statement at LinkSilo's open-source repository commit log as a tamper-evident record of each weekly attestation.
The table below enumerates every category of legal request LinkSilo expects to encounter and the counts received in the current reporting period. Pre-launch counts are reported as zero and explicitly marked. The methodology for what counts as a single request is described in Section 8.
| Category | Period | Cumulative | Note |
|---|---|---|---|
| Warrants (search, seizure, surveillance) | 0 | 0 | Pre-launch |
| National security letters or equivalent | 0 | 0 | Pre-launch |
| Gag orders attached to a received request | 0 | 0 | Pre-launch |
| Compelled-access / key-disclosure orders | 0 | 0 | Pre-launch |
| MLAT (Mutual Legal Assistance Treaty) requests | 0 | 0 | Pre-launch |
| Civil litigation subpoenas and discovery orders | 0 | 0 | Pre-launch |
| Voluntary government cooperation responded to | 0 | 0 | Will remain 0; see Section 10 |
Each annual report will also break down complied-with versus challenged-and-dismissed counts within each category, with summary descriptions of the legal grounds on which each challenge was made or declined.
The set of data LinkSilo could theoretically produce in response to a binding order is bounded by the architecture described on the security page. Several categories of user data are encrypted under keys LinkSilo does not hold; for those categories, the response to any binding order is a signed declaration that LinkSilo cannot produce the requested data, accompanied by an offer to deliver the ciphertext.
customer=None — a load-bearing privacy invariant pinned in silo-billing/src/services/stripe_outbound.rs::create_topup_checkout. Payment and credit allocation are deliberately decoupled via a short-lived allocation code (24-hour TTL) that the user redeems explicitly after paying; the allocation code is the only intermediate connecting the payment to the account, and that connection is severed once redemption mints credit. A binding order targeting a manual top-up user's billing surface returns the credit ledger + invoice metadata; cannot produce any Stripe linkage because none is stored.stripe_customer_id + payment_method_id + threshold + refill amount + completed-top-up history on the credit-ledger row. Stripe holds the corresponding persistent Customer + saved PaymentMethod + off-session charge history. The ledger flip (auto-topup-enabled = TRUE + Stripe identifiers stored) happens server-side only after Stripe confirms saved-method capture via webhook — abandoning mid-Checkout leaves the ledger clean, no half-enabled state. A binding order targeting an auto-top-up user's billing surface returns all of the local fields above plus the Stripe linkage; LinkSilo can additionally query Stripe via API for default-payment-method metadata (brand, last four, expiry) and past invoice PDFs if requested by the order. A binding order delivered directly to Stripe under its own jurisdiction is the alternative path and is outside LinkSilo's process.checkout.stripe.com, not on any LinkSilo page — LinkSilo bundles no Stripe JavaScript and does not see card data even momentarily. The response to a binding order targeting any of these categories is a signed declaration that LinkSilo cannot produce the requested data.pending_payment row carries no account identifier. The account-to-payment linkage is forged only at the redemption step, where the user submits the allocation code returned at top-up start; the code is the only intermediate. The plaintext allocation code is returned ONCE at top-up time (never retrievable from the database afterward — only its HMAC-peppered hash is stored), and the pending_payment row is reconciled against the redemption when credit mints. A binding order targeting a pending payment cannot be answered with an account identifier — silo-billing does not hold that mapping for unredeemed payments.Accept-Language header per regulatory minimum-disclosure requirements; see the architectural-ceiling block below) — only the resulting two-letter country code is persisted on the allocation_code row, never the IP itself. LinkSilo cannot produce IP records that no longer exist.LinkSilo's architecture pushes the unlinkability boundary as far as the regulatory and technical constraints allow. Some facts about a payment cannot be eliminated by design because they are intrinsic to how the payment system works. We document them here so the page is honest about the ceiling rather than overclaiming the floor.
checkout.stripe.com (not on a LinkSilo page), Stripe is in the payment loop for every paid-tier transaction. LinkSilo cannot eliminate this by design.Accept-Language primary preference) and persists only the resulting country code; the raw IP is not retained. This is the smallest disclosure that satisfies the regulation, not the maximum-privacy posture conceivable without it.When a user initiates account deletion, the deletion is immediate and unrecoverable. LinkSilo does not implement a grace period during which logging back in cancels the deletion; the user's keys are wiped at the moment of deletion confirmation, after which no procedural reversal is possible.
stripe_customer_id and payment_method_id fields are cleared as part of the ledger-row cascade. Connect-account rows (for tip-receiving creators) are deleted. Encrypted invoice blobs are NOT deleted; Finnish tax law requires six-year retention. The plaintext columns retained alongside the encrypted blobs are aggregate-friendly (date bucket, amount, currency, VAT country) and do not identify the user.Each annual report applies the following methodology to ensure the numeric counts in Section 4 are reproducible and comparable across reporting periods.
No annual reports have been published yet. The first report will publish twelve months after the public launch date and will cover the preceding twelve months. Each annual report is published as a stable URL under https://linksilo.io/transparency/<year> and is never modified after publication. Corrections, if necessary, publish as separate addendum documents with cross-references.
The annual reports are signed under LinkSilo's published Ed25519 transparency-report signing key. The signing key is rotated on the same cadence as the warrant canary signing key and the previous key is preserved in the open-source repository's key directory for verification of historical reports.
Binding legal process should be directed to the address below. LinkSilo does not voluntarily respond to non-binding inquiries; receipt of a binding instrument under Finnish or Swiss jurisdiction is the minimum bar for any response.
Email is monitored during Finnish business hours and acknowledged within five business days. Substantive response timeline depends on the request category and jurisdictional complexity.