Security

Last reviewed: August 2, 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 (Germany, EU). 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.
• A full restore has been rehearsed end-to-end, with a measured recovery time of approximately 3 to 3.5 hours. Point-in-time restore specifically has not yet been drilled.
• The application and database currently run on a single primary host. A hardware failure there is a full outage until restore completes. This is the most significant availability limitation we have and we are not going to bury it — see /api-status for measured uptime.

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.

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]