Skip to main content

SECURITY & TRUST

Designed to be truthful, fail-closed,
and auditable by default.

Decoda RWA Guard is an early-access production SaaS. We make honest claims about what we are and what we are not. This page documents the security and trust posture of the platform as it stands today.

Live EVM telemetry provenEvidence chain end-to-end verified100/100 production readinessSOC 2 — in roadmap, not yet certified

Secure-by-design principles

Fail-closed by design

Status labels default to degraded or offline rather than healthy when data is missing or stale. No alert is never silently shown as healthy. No data is never shown as safe.

No fake telemetry

Simulator and seeded data is never presented as live customer evidence. Runtime status is derived from canonical backend facts — heartbeat, poll, and telemetry are treated as distinct signals.

Workspace isolation

All data is scoped to your workspace. Cross-tenant queries are not permitted. Customer data does not appear in another customer's workspace under any circumstances.

Evidence integrity

Evidence packages carry stable UUIDs assigned at generation time. Once exported, the record cannot be retroactively altered. Package IDs are logged in the immutable audit trail.

Immutable audit logs

Every governance action, incident record, response action, and export operation is written to an append-only audit log. Audit entries are not editable after creation.

Proof gates in CI

Every push triggers a release proof pipeline that validates the full evidence chain end-to-end: telemetry receipt → detection → alert → incident → evidence package. The pipeline is fail-closed — a broken gate blocks release.

Truthfulness rules — enforced in code

These rules are implemented in the product codebase, not just written in a policy document. They govern every status label, every runtime summary, and every evidence export.

  • No data is never shown as safe.
  • No alert is never silently shown as healthy.
  • Simulator or seeded data is never presented as customer evidence.
  • Runtime status is derived from canonical backend facts — not frontend assumptions.
  • Heartbeat, poll, and telemetry are distinct signals. Heartbeat alone does not claim live monitoring.
  • Telemetry is not “current” when it is missing or stale. The UI surfaces this explicitly.
  • Live monitoring is not claimed as healthy when reporting systems are at zero.

Data protection overview

The following describes our current data handling posture. This is not a comprehensive security policy — it covers the most important operational facts for pilot and early paid customers.

Certifications & disclosure

Is Decoda SOC 2 certified?

Not yet. We are an early-access production SaaS. SOC 2 Type II audit is on our roadmap. We will not claim certification until it is achieved.

Is this GDPR-compliant?

The platform is designed to process operational data (on-chain addresses, telemetry events, governance records), not personal data. We minimise data collection. See our Privacy Policy for detail.

How do I report a security issue?

Email security@decoda.app with a description of the issue. We will acknowledge within 48 hours and coordinate disclosure. We do not have a formal bug bounty programme at this stage.

Where is data stored?

Production data is stored in a managed PostgreSQL database hosted in the EU (Neon). Evidence exports can be configured to land in your own S3-compatible bucket.

Responsible disclosure

If you believe you have found a security vulnerability in Decoda RWA Guard, please report it responsibly. We do not have a formal bug bounty programme at this stage, but we take every report seriously and will coordinate disclosure with you.

Email: security@decoda.app · Response within 48 hours.

Operational expectations

← HomePricingPrivacy PolicyTerms of ServiceLive ProofSupport