TrueStake Security Posture
Built to comply with — Defense of the identity↔validator linkage
An honest, self-assessed overview of how TrueStake protects the identity↔validator linkage — what we encrypt, how access is controlled, and where we hold ourselves to account.
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 blocks high-severity vulnerabilities from being deployed.
- Secret-pattern scanning (Gitleaks) prevents credentials from entering the source repository.
- Static analysis (CodeQL) scans every pull request.
- Automated PII-seam check. A continuous-integration check blocks code that would read encrypted PII fields as plaintext outside the designated decryption path.
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 admit any non-founder user. We rely on vendor-standard DPAs today; formally executed DPAs are a prerequisite for beta.
Terms of Service and Privacy Policy are in preparation with counsel and will be published before public launch.
Off-host database backup beyond the platform's built-in point-in-time recovery is staged to be live before any non-founder customer data is admitted.
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
Primary (live now): GitHub Security Advisories — private, encrypted reporting, no live inbox required.
Email: security@truestake.io is being provisioned. It is documented in our SECURITY.md and /.well-known/security.txt, but is not yet active. Use the GitHub path until it is live.
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-06-26, self-assessed. It is not a security certification.
Citations
- [1]SECURITY.md — TrueStake responsible disclosure policy· Public disclosure policy and security contact
- [2]GitHub Security Advisories — report a vulnerability· Interim reporting channel until security@truestake.io is provisioned