Security

Last reviewed: September 12, 2026

This page describes how MadeOnSol is actually built and operated. It is a statement of posture, not a certification: we hold no SOC 2, ISO 27001, or third-party penetration-test report, and we would rather say so here than have you discover it in a procurement questionnaire. Everything below is verifiable — where a claim can be checked from outside, we say how.

Reporting a vulnerability

Email [email protected]. Machine-readable contact details are published at /.well-known/security.txt. We aim to acknowledge within 2 business days and to keep you updated until the issue is closed.

We do not operate a paid bug-bounty programme. We ask that you give us reasonable time to remediate before public disclosure, and that testing stays within your own account — no denial-of-service, no automated scanning that degrades the service for others, and no access to data belonging to other users. Report in good faith under those conditions and we will not pursue action against you.

Infrastructure

• Dedicated servers at Hetzner and OVH (both Germany, EU) — two providers on purpose, so a single provider event cannot take production and its safety net together. No third-party cloud tenancy for application data, and no data processing outside the EU except where a named sub-processor requires it — those are listed in our Privacy Policy.
• Self-hosted Postgres and Supabase stack. We are not a multi-tenant SaaS reselling another vendor's database.
• Host firewall (UFW) with a default-deny inbound policy; the public edge sits behind Cloudflare.
• OS and dependency updates applied on a rolling basis; the kernel is pinned deliberately where a known regression exists.

Data in transit and at rest

• TLS on every public endpoint, including the WebSocket streams. Certificates are renewed automatically and monitored for expiry.
• Database backups are encrypted with GPG before leaving the host, and stored off-site on separate infrastructure.
• Backup integrity is verified by checksum on every run, not assumed.
• Disk-level encryption is not enabled on the database volumes. We would rather state that plainly than imply otherwise — if it is a requirement for you, raise it before contracting.

Authentication and API keys

• API keys (msk_ prefix) are stored as hashes. The full key is shown once at creation and cannot be recovered afterwards — if you lose it, you rotate it.
• Keys can be revoked at any time from your dashboard; revocation takes effect immediately.
• Account authentication uses Supabase Auth with email confirmation, and Google OAuth where you choose it.
• Administrative access is restricted by an explicit server-side flag, never by a client-supplied value.
• Webhook payloads are signed with a per-endpoint HMAC secret so you can verify origin and integrity.

Access control

• Row-level security is enabled on user-scoped tables; the anonymous role cannot read another account's rows.
• Server-side administrative operations use a separate privileged client that is never exposed to the browser.
• Secrets live in root-owned environment files with restricted permissions, not in the application bundle.
• Access to production is limited to the operator (see Terms for the operating entity). This is a sole proprietorship — there is no internal team with standing database access, which removes a class of insider risk and concentrates key-person risk. Both are true and you should weigh both.

Monitoring and resilience

• Automated health checks run continuously across services, database, backups, certificates and data pipelines, with alerting on failure.
• Continuous write-ahead-log archiving gives point-in-time recovery with a recovery-point objective of roughly one minute.
• A warm standby database replicates to a second physical machine at a second provider (OVH, Germany), which also produces the nightly encrypted backups.
• Restore-from-backup is drilled monthly on separate hardware, with a measured recovery time of roughly 3–3.5 hours and a recovery point of about one minute (a streaming warm standby at a second provider).
• The application and database serve from a single active host; the standby is warm, not active-active. A hardware failure on the primary is therefore an outage until failover completes — a rehearsed procedure, but hours, not seconds. We are not going to bury that — see /api-status for measured uptime and /benchmarks for measured latency.

Data handling

• We do not sell personal data.
• Most of what we serve is public blockchain data, which is not personal data about you.
• Account data can be exported or deleted from your profile; deletion removes the account and its associated records.
• Retention windows per dataset are documented internally and summarised in our Privacy Policy.
• A GDPR-compliant Data Processing Agreement is available at /dpa.
• How served data stays reproducible and auditable — point-in-time queries, per-request audit IDs, the immutable archive, continuous verification — is documented at /data-integrity.

What we do not have

Stated once, plainly, so it never has to be extracted from us: no SOC 2, no ISO 27001, no external penetration test, no bug-bounty programme, no 24/7 on-call rota, and no contractual uptime guarantee on self-serve tiers. The 99.5% figure published elsewhere on this site is an operating target. A binding service-level agreement with credits is available on Enterprise terms — ask and we will send the template before you commit to anything.

Contact

Security: [email protected] · General: [email protected]