Inaya Trust Center
A transparency layer over the same security, audit, and permission infrastructure Inaya runs on internally — not a separate marketing claim. Where something below is independently checkable, this page shows you how to check it yourself rather than asking you to take our word for it.
Files are encrypted and sharded client-side before anything reaches the network — no server, node, or administrator ever holds a complete, decryptable copy. Consequential AI-initiated actions go through Guarded Execution: a human with the same real authority the action itself requires must approve it, and even after approval a 36-hour delay passes before it executes, giving time to reconsider or cancel. Access follows a department/role permission model enforced server-side on every request, not just hidden in the interface.
Live, public threat-intelligence network status (reporting nodes, confirmed threats, network health) is on the Security transparency page — the same public data the mobile and desktop apps' own security screens read from.
Inaya implements the operational controls commonly required for SOC 2 / HIPAA / similar frameworks — access control, audit logging, incident tracking, data classification, retention policy. This describes controls, not certification — Inaya has not itself completed a formal SOC 2, HIPAA, ABA, FedRAMP, or equivalent certification; that remains a separate workstream, not something this page claims.
Every audit-relevant action is written to a hash-linked chain: each entry commits to every entry before it, so altering or deleting any past entry breaks every hash after it. An organization's own Audit Trail view (Business Workspace → Audit Trail) exports this chain in full — paste an export below and this page recomputes every hash in your own browser, matching Inaya's own verification exactly. This server is never trusted for the verification result itself.
Backup existing is not the same as recovery being proven. Institutions can define recovery requirements (an RTO/RPO threshold, critical asset categories, a test frequency) and Inaya continuously runs real, non-destructive recovery tests against them — exercising the exact same encryption, replication, and reconstruction pipeline described above. Each test produces a real recovery-time/recovery-point measurement and a PASS/FAIL result; a resilience test's evidence uses the identical verifiable evidence-package model as the audit chain above, so it can be checked with the same verifier — paste a recovery-test evidence export instead of an audit export and it works unchanged. Per-organization resilience status is authenticated (Business Workspace → Recovery Resilience), not published here, since it would otherwise disclose one customer's specific security posture publicly.
Every on-chain contract Inaya runs on is publicly deployed and verifiable — see the Deployed Contracts section on the dApp home page for live addresses linked directly to BscScan, not a static list here that could drift out of date.
No publicly disclosed platform-level incidents to date. This section will be updated if that changes — nothing here is a claim that no incident could ever occur.
Documents are encrypted and sharded before upload; access is governed by an explicit per-document permission model (Private / Department / Project); every access and permission change is recorded in the evidence trail described above.
See the changelog for release history.