Security isn’t a slide in our deck, it’s the operating system for how we build. To date, we’ve completed six independent security audits across smart contracts and internal systems (separate from compliance assessments) and we’ve invested ~$700,000 USD specifically in security reviews, testing, and remediation. These audits included architecture reviews, web application and API penetration tests, smart-contract audits, and infrastructure hardening assessments by external firms (e.g. Modus and Secureworks), followed by fix-verify cycles where findings are remediated and re-tested.

Our approach is defense-in-depth and ongoing:

  • Assess → remediate → verify: independent testers probe, our team patches, and we bring auditors back to confirm fixes.
  • Threat-model first: we prioritize risks around storage paths, key handling, auth and orchestration before shipping.
  • Transport & storage protections: TLS in transit; immediate encryption + sharding at rest; no plaintext retention beyond the request lifecycle; owner-gated reads via wallet/session.
  • Responsible transparency: we publish what we responsibly can from audits, due to IP posture and security

We bring in auditors, fix real issues, and keep iterating. That’s how we earn trust, not by slogans, but by rigor.

An open note to the community: 

  • Transport to Iagon is protected by TLS (HTTPS); on receipt we immediately encrypt and shard data across multiple providers, and we do not retain plaintext copies of user files. Reads are gated by the owner’s wallet/session, operators cannot arbitrarily retrieve/decrypt your content. TLS 1.3 is the internet standard for protecting data in transit. (IETF Datatracker, The Cloudflare Blog)
  • GDPR is risk-based: “appropriate technical and organisational measures” (which can include encryption) are chosen based on risk and context—client-side encryption is not a blanket legal requirement. (GDPR, Legislation.gov.uk, ICO)
  • Many mainstream clouds protect data with server-side encryption at rest (SSE), which is entirely compliant when applied correctly (e.g. Amazon S3 automatically encrypts new uploads by default). (AWS Documentation)
  • In Web3, major decentralized storage networks do not encrypt user data by default, they expect encryption to be applied at the app layer. Filecoin’s own docs recommend encrypting your dataset before storage; Arweave is public by default unless you add an encryption layer via tools like ArDrive/ArFS or SDKs. Our model adds encryption + sharding with wallet-gated reads. (docs.filecoin.io, GitHub, help.ardrive.io, ardrive.io, docs.arweavekit.com)

What our stack does today (and why)

Transport (in transit).All uploads & downloads use TLS (HTTPS), which is designed to prevent eavesdropping and tampering between your device and our ingress point. Claims that “a proxy can read the data” reflect how debugging proxies (like Fiddler) work: they install a local root certificate on your machine to terminate TLS locally, so you can inspect your own traffic. That does not prove plaintext on the public internet or plaintext at rest on our side. (IETF Datatracker, fiddlerbook.com, Telerik.com)

Receipt → storage (at rest).On receipt, content is immediately encrypted and sharded across multiple providers; we don’t retain any encrypted data after the instant encryption is done. Durability is delivered by redundant sharding, not by any single gateway or index component.

Access control (who can read later). “Only the owner can read” refers to stored data & retrieval semantics. Reads are wallet/session-gated by the owner; storage node operators cannot arbitrarily pull and decrypt user content, nor can we. We don’t publish key-management details line-by-line for security and IP reasons; what matters is that decryption is owner-authorized, without the end user’s authenticated wallet/session, the system cannot retrieve or decrypt stored content.

About the “centralized gateway” talking point

We’ve never claimed the system is “fully decentralized” today. We’ve publicly laid out a roadmap that further decentralizes orchestration, including our Network Explorer work to replace the indexing layer and reduce dependencies on Iagon-operated components. As with Cardano’s own approach to decentralization, we prioritize by criticality: protect user data first (encryption & sharding, data-residency), then progressively decentralize orchestration further and selection while maintaining performance and reliability. See our Network Explorer proposal for the direction of travel. (Lido Nation, Project Catalyst)

One reference example of admitting that we are not fully decentralized: https://x.com/IagonOfficial/status/1837818656186642665

Durability vs. availability.A gateway or index is about how you find and coordinate data. Durability (whether your data is actually resilient across the network) comes from how it’s sliced and replicated across decentralized providers.

Saying “a gateway could fail, therefore permanent data loss” confuses these two layers, and also is false due to the fact that our gateway(s) are redundant - even if you only may see one "endpoint" from the "outside".

GDPR: what it actually requires

  • Risk-based “appropriate measures” (Art. 32). GDPR doesn’t mandate client-side encryption. It asks controllers/processors to implement appropriate measures, including encryption as appropriate, to ensure confidentiality, integrity, availability, and resilience, plus ongoing testing and evaluation. (GDPR, Legislation.gov.uk)
  • Encryption guidance. Regulators (e.g., the UK ICO) treat encryption as an example of an appropriate measure depending on the risks, not a one-size-fits-all absolute. (ICO)
  • Practical expectations.
    • In transit: TLS 1.2/1.3 is standard and satisfies “appropriate” transmission protection. (IETF Datatracker)
    • Ephemeral handling: plaintext buffers during processing are unavoidable; what matters is not persisting plaintext and preventing logging/caching of sensitive content.
    • At rest: encrypt quickly and manage keys correctly; if encrypted data is breached without keys, GDPR Art. 34(3)(a) recognizes that notification to data subjects may not be required. (Legislation.gov.uk)

What the audits were (and weren’t)

Here at Iagon, audits are not a one-time checkbox, they are a continuous process we’ve applied at every stage of our ecosystem development. Each step forward in our architecture, protocol, and product rollouts has been independently reviewed, ensuring that security, compliance, and reliability are built into the foundation of our technology. We will continue to follow this approach in the future.

  • Why we do this is simple:Trust and transparency. Independent audits verify that our architecture and smart contracts are safe, reliable, and aligned with industry standards.
  • Enterprise readiness. Fortune 500 clients and institutional partners require proof that the infrastructure they rely on has undergone rigorous third-party testing.
  • Continuous improvement. Findings from each audit feed directly into remediation plans, code updates, and strengthened security practices.
  • Ecosystem protection. By validating not just code, but the entire system architecture, we ensure the resilience of the Iagon network as a whole.

We have done multiple independent assessments across architecture, web application security, and smart contract layers:

  • Secureworks - Security Report: https://drive.google.com/file/d/1OT58d7RoJ-YZA84kUqF910Xr1hLz9PII/view 
  • MODUS - Architectural Audit Report: https://drive.google.com/file/d/1c8jG7mdvLx-gV5hE_AHmu6PgI2IRAxik/view
  • VacuumLabs — Delegation Smart Contracts Audit
  • https://drive.google.com/file/d/11nsdQg6onmtslsaVg2ZclGocX84OnE9c/view
  • FYEO — Security Assessment of Iagon Staking & Rewards Contract: https://drive.google.com/file/d/1hLnlIDQQEccP1J0BEX1-Q42uE7hHonD0/view

As a result, every major component of Iagon’s infrastructure, from storage orchestration to delegation and staking smart contracts, has been subject to independent scrutiny.

We commissioned independent assessments (architecture + web application security). As is normal, some reports are redacted before publication to protect our IP and security posture. Where findings touched orchestration or predictability (e.g. selection of management/index components), we documented remediation and have work underway as part of the Network Explorer track. Where findings overlapped standard web-app hardening, the second vendor’s pen test and subsequent fixes addressed them.

Some have paraphrased the audits as ‘uploads are unencrypted’ or ‘Iagon can read everyone’s files.’ That overstates what’s actually written. The text cited (2.1.1) says ‘the gateway processes full, unencrypted files, creating legal and compliance exposure’ i.e. transient handling at the ingress during upload, not clear-text transit over the internet and not plaintext storage at rest. To avoid ambiguity from earlier paraphrases, we’re stating it exactly: the finding concerns ephemeral processing before our immediate encryption and sharding steps. We’ve implemented and continue to implement, mitigations to minimize that ephemeral window and reinforce server-side encryption and access controls. Conflating this with “uploads in clear text” or “staff have ongoing access to files” is inaccurate.

Web2 & Web3 comparisons (why our model is sound)

Web2 clouds.It’s standard to protect traffic with TLS and protect storage with server-side encryption, this is fully compliant when configured properly. For example, Amazon S3 encrypts new object uploads by default with SSE-S3 (AES-GCM), and the practice is widely accepted by regulators and enterprises. We follow the same defence-in-depth pattern (TLS + encryption at rest + access controls), adapted to a decentralized storage topology with sharding. (AWS Documentation)

Web3 networks.

  • Filecoin/IPFS: the network does not encrypt your data by default; the Filecoin docs tell builders to encrypt datasets at the application layer if privacy is required because storage providers could otherwise read uploaded files. (docs.filecoin.io, GitHub)
  • Arweave/permaweb: public by default; if you want privacy you add an encryption layer (e.g., ArDrive/ArFS, ArweaveKit). In other words, many Web3 storage stacks leave confidentiality to the app or middleware. Our model adds encryption + sharding with wallet-gated reads out of the box. (help.ardrive.io, ardrive.io, docs.arweavekit.com)

What we heard in the recent X Space and our answers

“Files go to a centralized server unencrypted; Iagon can read everything.”

  • False. Both parts are incorrect when stated as facts (and even if someone crops it to just ‘Iagon can read everything’). Transport is TLS; on receipt files are immediately encrypted and sharded; we do not retain plaintext after that request lifecycle. If anyone believes clear-text actually traverses the internet, the correct test is simple: publish an off-box/router pcap showing no TLS handshake and a raw http:// payload. By contrast, tools like Fiddler only show contents because the user installed a local HTTPS-decryption proxy (a self-chosen MITM) on their own device.

Separately, being open source does not guarantee a provider cannot access file content: an operator can still terminate TLS early via proxies, change deployment configs, or run a modified build. The only cryptographic guarantee that a server operator can’t ever see file bytes is client-side (end-to-end) encryption with user-held keys (client side encryption is also planned). Our current model applies encryption by default on receipt plus sharding, with owner-authorized reads (wallet/session) and no plaintext retention; operators cannot arbitrarily retrieve or decrypt user content.”

Single gateway = permanent data loss.

  • Incorrect. Gateways/indexes are availability surfaces. Durability is provided by encrypted, redundant sharding across providers.

GDPR requires client-side encryption.

  • Incorrect. GDPR Art. 32 is risk-based and cites encryption as appropriate; TLS + rapid encryption at rest + proper key and access controls are widely recognized as compliant when the risk assessment justifies them. (GDPR, Legislation.gov.uk, ICO)

29 findings

  • Security reviews often list findings across categories and severities. In our case, standard web-app findings overlapped across two vendors and were addressed; several architecture findings related to a proposed compute design not in active development. Two storage-related concerns are addressed above (encryption/availability vs durability) with remediation in progress where relevant. In summary of the 29 findings, only 5 findings were regarding our current product. The remaining findings were associated with future concepts and prior development repositories that aren't in production.

Unencrypted files on your server = massive legal flaw.

  • Exaggerated. Regulators expect appropriate risk controls, not a single crypto pattern everywhere. The real questions are: Is in-transit data protected? Is plaintext retained? Are reads owner-gated? Are storage keys well-protected? Our answers: yes, no, yes, yes. (ICO)

The screenshot of the low finding is a bit without context under that section: https://drive.google.com/file/d/1i9tOGGZL9HKXgK9ewHJ-OwGlUUtRXose/view

How we secure smart contracts, apps and infra (our program at a glance)

  • Independent reviews. Separate architecture and web-application security assessments; follow-up remediation and re-testing as needed.
  • Threat-modeling & change control. Assess material changes (especially around auth, storage paths, and orchestration) before release; enforce least-privilege and secrets hygiene.
  • Defense-in-depth. TLS 1.2/1.3, rapid encryption at rest, sharding across providers, access control tied to the owner’s wallet/session, strict logging without sensitive payloads. (IETF Datatracker)
  • Progressive decentralization. Network Explorer to decentralize orchestration and reduce reliance on any Iagon-hosted discovery/indexing, while maintaining performance and DX. (Lido Nation)
  • Compliance posture. GDPR-aligned, risk-based controls; documentation of data-flows and residual risks; continual testing and monitoring. (GDPR, ICO)

About Nuvola’s “thorough assessment” & transparency claims

Nuvola publicly claims deep diligence. Our operational records show:

  • Operational reliability. For months where Nuvola’s nodes were fully active, their average uptime was ~86.3%, with several nodes being unavailable for more than an entire month (around October 2024). For a random sample of 19 other active nodes (not Novula's nodes) over full months, the average monthly uptime was ~96.5%. None of that downtime was disclosed to their community.
  • Staking & rewards. Nuvola unstaked their OTC tokens in July. Per program rules, rewards stop accruing once unstaked; they later asked about retroactive rewards for downtime, which we declined.

We’re sharing this only to give you full context when you weigh “detailed assessments” claimed publicly against actual operational behavior we observed.