TrueStake Security Posture

Our security goal, stated plainly

TrueStake protects one thing above all else: the linkage between your email address and your validator public keys and withdrawal addresses. Those on-chain identifiers are already public on the Ethereum blockchain — anyone can look them up. What TrueStake uniquely holds is the connection to you as a person, and that is what we are built to defend.

What this means in practice: if an attacker obtained a copy of our database without any decryption capability, they would find encrypted values they could not read — not your validator pubkeys, withdrawal addresses, or fee recipients in plaintext.

What we protect and how

Sensitive on-chain identifiers stored encrypted. All validator public keys, withdrawal addresses, and fee recipients are encrypted at rest before they are written to the database. Decryption requires server-side credentials that never travel to your browser. You can verify this claim is non-retractable: it is enforced at the database function level, not just by application code.

Row-level isolation. The database enforces that each user can only ever read their own data. This is a database-layer control, not an application-layer check — a bug in the application cannot accidentally expose another user's records.

Passkey-first authentication; no passwords. TrueStake uses WebAuthn passkeys as your primary credential. Email magic links are used only to enroll or replace a passkey — they do not log you in directly. There are no passwords to steal, reuse, or phish.

Read-only by design; cannot move funds. TrueStake reads public on-chain data. We never hold, transmit, or have custody of your ETH or any other asset. We never see your validator private keys or withdrawal private keys. TrueStake cannot initiate a transaction on your behalf.

No KYC, no exchange API keys — ever. These are permanent product non-goals. We do not collect government ID, Social Security Numbers, or date of birth. We do not connect to exchange accounts. This is both a privacy commitment and a security one: data we never collect cannot be breached.

What we build on

TrueStake is hosted on infrastructure that holds industry certifications we do not hold ourselves:

• Supabase (database and authentication) — SOC 2 Type II certified
• Vercel (web hosting) — SOC 2 Type II certified
• Cloudflare (DNS, network protection) — SOC 2 Type II certified

TrueStake itself holds no SOC 2, ISO 27001, or PCI certification. This page describes our self-assessed security posture, not a third-party attestation. We believe honest self-assessment is more useful than marketing language.

Automated security controls

Several controls run automatically on every code change:

• Dependency vulnerability scanning. Every code change is scanned for known high-severity vulnerabilities in the packages we depend on. A release to production is blocked if any unresolved high or critical advisory is present. On individual code changes the scan reports rather than blocks, and a nightly scan of the main codebase raises a tracked issue — this keeps a newly published advisory from halting unrelated work while still forcing it to be resolved before anything reaches production.
• Secret-pattern scanning (Gitleaks) prevents credentials from entering the source repository.
• Pinned build tooling. Every third-party automation step in our build pipeline is pinned to an exact, immutable version rather than a movable label, and an automated check rejects any change that reverts one to a movable label. This is what limits our exposure to a compromised upstream build tool. To be precise about its limits: the check confirms each step is pinned, not that a given pin corresponds to the release its label claims — verifying that correspondence is a manual step when a version is bumped.
• Automated PII-seam check. A continuous-integration check blocks code that would read encrypted PII fields as plaintext outside the designated decryption path.

We do not currently run automated static analysis (SAST) of our own source code. GitHub's CodeQL requires Advanced Security, which is not available on our private repository; we removed the non-functional workflow rather than leave a control listed that did not run. Code review is manual today.

Honest deferrals

We believe you deserve to know where our posture has gaps, not just where it is strong.

Formal data-processing agreements with our infrastructure vendors are planned before we onboard users beyond our internal account. We rely on vendor-standard DPAs today; formally executed DPAs are a prerequisite for beta.

Terms of Service and Privacy Policy are published and in effect (preliminary, pending final counsel review) — see Privacy Policy and Terms of Service.

Off-host database backup beyond the platform's built-in point-in-time recovery is staged to be live before we onboard users beyond our internal account.

Bug bounty program — not yet offered. We accept responsible disclosure with acknowledgment (see security contact below). A formal program is a Phase 2 evaluation.

How to report a vulnerability

Email security@truestake.io. It reaches the founder directly, it needs no account and no prior relationship with us, and it is the preferred channel published in /.well-known/security.txt. Tell us what you found and how to reach you; a pseudonymous address is fine.

Or use our contact form, which is published as the second contact in the same file. Be aware the form requires a name and an email address before it will submit — so if you would rather not supply either, use the mailbox above. We have no fully anonymous intake channel today, and we would rather state that than have you discover it at the submit button.

What we do not currently offer, and why it matters to you: we have no PGP key published, so email to the address above is not end-to-end encrypted — for a finding where that matters, send us a way to reach you rather than the finding itself. GitHub Security Advisories are not usable either: this repository is private, so that reporting form is not reachable by anyone outside the project. The mailbox and the contact form are the whole of the disclosure surface, and we would rather say that than list channels you cannot actually use.

We commit to acknowledging reports promptly and notifying affected users within 72 hours of a confirmed breach.

This is our security posture as of 2026-08-25, self-assessed. It is not a security certification.