Security is the product,
not a feature.
Veritas stores professional liability documents — structural reports, compliance certificates, and as-built drawings that carry legal and financial consequence. Our threat model begins with the assumption that any single infrastructure component can fail or be compromised, and designs accordingly.
Defence-in-Depth
Every security guarantee is layered. A breach at one layer does not compromise the others. Documents remain unintelligible without the encryption key even if storage is accessed.
Privacy by Design
No Veritas server can read your document content. Only encrypted ciphertext is stored. The cryptographic design guarantees this at the architecture level, not by policy.
Cryptographic Agility
We use only NIST-standardised algorithms. No proprietary cryptography. As standards evolve, our architecture supports migration without breaking historical records.
Cryptographic Foundation
Public standards. No proprietary cryptography.
Every algorithm Veritas uses is published, peer-reviewed, and standardised by NIST. The security of your records does not depend on trusting Veritas — it depends on the mathematical properties of openly auditable algorithms.
Symmetric encryption for all stored documents. Approved for US TOP SECRET classification. The same standard protecting national security communications.
Protects against: content exposure if any storage layer is breached
CRYSTALS-Kyber key encapsulation. The only NIST-standardised post-quantum algorithm for key establishment. Protects against harvest-now-decrypt-later attacks by quantum-capable adversaries.
Protects against: future quantum computers decrypting today's stored documents
Edwards-curve digital signatures for every attestation. 128-bit security level. Independently verifiable using only the signer's public key — no Veritas involvement required, now or in 50 years.
Protects against: signature forgery and impersonation of attestors
Every attestation is hashed and rolled into a daily Merkle root. A single byte change in any document alters the root — detectable by anyone with a copy of the original hash.
Protects against: undetected post-attestation modification of any record
All algorithms are publicly specified. The security properties of AES-256-GCM, ML-KEM, Ed25519, and SHA-256 are documented in open NIST publications and verifiable by any independent cryptographer. We rely on mathematical strength, not on keeping our methods secret.
Layered Architecture
Five independent layers.
Each protecting against a distinct threat.
No single layer is a single point of failure. A compromise at any one layer is contained — the other layers maintain the integrity and confidentiality of every record.
L1Document LayerAES-256-GCMProtects against: Content exposure if storage is breached
Protects against: Content exposure if storage is breached
Every document is encrypted before it leaves the client. The server receives and stores only ciphertext. No Veritas employee can read document content.
L2Key Distribution LayerML-KEM (FIPS 203)Protects against: Future quantum computers decrypting today's data
Protects against: Future quantum computers decrypting today's data
Post-quantum key encapsulation protects the symmetric key exchange. Documents encrypted today remain confidential even if quantum computers become available in future.
L3Storage LayerIPFS + Azure BlobProtects against: Single-provider failure, censorship, or data loss
Protects against: Single-provider failure, censorship, or data loss
Content is stored in two independent systems. IPFS provides content-addressed decentralised storage; Azure Blob provides geo-redundant cloud backup in Australian data centres.
L4Integrity LayerSHA-256 Merkle TreesProtects against: Undetected post-attestation modification
Protects against: Undetected post-attestation modification
All attestations are rolled into a daily Merkle root. Modifying any document changes the root — detectable by any third party holding the original hash, without needing to access the document.
L5Anchor LayerCometBFT BlockchainProtects against: Institutional revisionism — altering historical records
Protects against: Institutional revisionism — altering historical records
Merkle roots are anchored to the Veritas L1 chain. Forging a record requires collusion of 2/3+ of independent validators — structurally impossible across separate legal entities and jurisdictions.
Storage & Data Sovereignty
Your documents stay in Australia.
The truth stays everywhere.
Document content and private metadata are stored in Australian data centres, meeting the Australian Privacy Act data residency requirements. The public record — hashes only, no personal information — is anchored to a globally distributed blockchain.
Documents are stored by their cryptographic hash (CID). The content is the address — it cannot be moved or substituted without the CID changing. No single party controls removal.
Geo-redundant backup in Microsoft Azure's Australian data centres. Satisfies Australian Privacy Act data residency requirements for private metadata and encrypted document storage.
For records that must survive all institutional changes, Arweave provides provably permanent storage: a single fee funds storage in perpetuity. No Veritas server required to retrieve the record in 50 years.
Each organisation's encrypted documents are logically isolated. Cross-tenant data access is not possible at the storage layer — encryption keys are scoped per tenant and never shared.
Consensus & Validator Security
Forging a record requires collusion
of 2/3+ independent validators.
The Veritas chain uses CometBFT Byzantine Fault Tolerant consensus — the same consensus engine powering hundreds of Cosmos SDK chains with billions of dollars of value secured. BFT consensus means the system tolerates up to 1/3 of validators acting maliciously without compromising record integrity.
Record integrity maintained even if up to 1/3 of validators act maliciously or go offline.
Each validator operated by a separate Trinity subsidiary under independent legal structure.
Validator signing keys stored in hardware security modules — keys cannot be extracted from the device.
Validator nodes do not expose direct network addresses. Public-facing sentry nodes absorb and filter traffic.
What Byzantine Fault Tolerance Means for Your Records
A Byzantine fault is the worst-case scenario: a validator that is not just offline, but actively trying to forge records. BFT consensus ensures that even if 1 in 3 validators behaves maliciously, the remaining honest validators will reject the fraudulent records. Forging a Merkle root into the chain requires controlling more than 2/3 of all validators simultaneously — structurally impossible across separate corporate entities, separate legal jurisdictions, and separate physical infrastructure.
Validator Key Management
Each validator uses a Hardware Security Module (HSM) to protect the consensus signing key. HSMs are tamper-resistant hardware devices: the private key is generated inside the device and cannot be extracted in any form. If a validator server is physically seized or remotely compromised, the signing key remains protected inside the HSM and cannot be used to impersonate that validator. This is the same standard used by institutional custodians for digital asset key management.
Access Control & Privacy
Zero-knowledge server.
We cannot read your documents.
The access model is not enforced by policy — it is enforced by the cryptographic architecture. Even with full database access, a Veritas employee would see only encrypted ciphertext. Decryption requires keys that are never stored server-side.
Documents are encrypted client-side before upload. Veritas servers receive and store only encrypted bytes. This is not a policy — it is an architectural property.
Every grant to an external party (bank, insurer, council) has a defined expiry. Access is automatically revoked at expiry — no manual action required and no risk of forgotten active grants.
Every document access event — who, when, and what they accessed — is recorded in an append-only log. The audit trail cannot be edited or deleted, even by administrators.
Owner, Engineer, Reviewer, and Authorised Third Party roles have distinct permissions. Principle of least privilege applied at every level: each role can access only what the function requires.
Access Role Hierarchy
Permissions flow downward only. Third-party access is always owner-authorised, scoped, and time-limited.
Compliance & Regulatory
Built for Australian regulatory requirements.
From data residency to privacy principles, Veritas is designed to meet the requirements of Australian enterprise customers — engineering firms, insurers, councils, and banks.
Australian Privacy Act 1988
- APP 11: Appropriate technical security safeguards for all personal information
- APP 13: Correction rights — data architecture supports correction without modifying historical attestations
- No personal data stored on-chain — only hashes and anonymised asset metadata
- Private metadata encrypted and stored in Australian data centres
GDPR Alignment
- Data minimisation: only necessary data is collected and stored
- Encryption at rest and in transit satisfies Art. 32 appropriate technical measures
- No personal data on the public blockchain — GDPR right to erasure does not conflict with immutable records
- Data Processing Agreement available on request
Certification Roadmap
- SOC 2 Type II: targeted Q4 2026, concurrent with external Verification API launch
- ISO 27001: targeted Q1 2027
- Smart contract audit: 60 days before Phase 1 chain mainnet launch
- Audit reports will be published in redacted form following Iagon and Vanta transparency models
What data is stored where
- Document SHA-256 hash (fingerprint only — no content)
- Asset type and classification (e.g. "Commercial Building")
- Attestation timestamp
- Attester public key (not name or identity)
- Merkle root (daily batch)
- Document content (AES-256-GCM encrypted)
- Private asset metadata (owner details, addresses)
- Attester professional credentials
- Access grant records (who accessed what)
- Audit trail logs
Audit Program
Planned independent reviews
before every major milestone.
Independent security audits are planned at each milestone, not performed retrospectively. We believe in publishing the plan before the audits are complete — because the commitment to audit is itself a signal of security maturity.
Audit summary reports will be published in redacted form. Redaction covers only exploit-specific implementation details — severity classifications, remediation status, and overall findings will be publicly accessible, following the transparency model established by Iagon, Vanta, and Proof.com.
Full architecture review of the Opus/Veritas integration layer: storage paths, key handling, authentication, and API surface.
Under evaluation: Hacken, Oak Security, Halborn
Independent audit of all four Cosmos SDK modules: x/asset, x/attestation, x/access, x/lifecycle. Line-by-line review by external blockchain security specialists.
Under evaluation: Hacken, Oak Security, Halborn
Black-box and grey-box penetration testing of the full stack: API endpoints, authentication flows, validator infrastructure, and document access paths.
Separate firm from smart contract audit to ensure independent coverage
Third-party attestation covering security, availability, and confidentiality trust service criteria. Required for enterprise API customers in banking and insurance.
Firm to be selected through formal RFP process
Operational Security
Security by practice, not just by architecture.
Technical controls are only part of the picture. Operational security ensures the right people have the right access and that incidents are detected and responded to rapidly.
Infrastructure Redundancy
Multi-location infrastructure with automated failover. No single point of failure across compute, storage, or network layers. Chain validators operate on separate physical infrastructure.
24/7 Monitoring
Continuous monitoring across chain health, storage availability, attestation processing, and authentication events. Automated alerting with defined escalation paths for security-relevant events.
Least-Privilege Access
Internal staff access is scoped to the minimum required for their role. No single employee has access to all system components. Production access requires approval and is time-limited.
Personnel Screening
Background and reference checks for all personnel with system access. Security awareness training at onboarding and annually. Secure offboarding with immediate access revocation.
Incident Response
Documented incident response plan with defined severity classifications and response timelines. Security incidents that affect customer data will be disclosed within 24 hours of detection and confirmation.
Vendor Risk Management
All third-party service providers are assessed for security posture before engagement. Only providers with appropriate security certifications are used for infrastructure and data handling.
Responsible Disclosure
We welcome security researchers
acting in good faith.
Security research that responsibly identifies and discloses vulnerabilities makes the platform safer for everyone who depends on it. We commit to working with researchers openly and without legal action for good-faith disclosure.
In Scope
- Attestation integrity — forgery or manipulation of attestation records
- Authentication bypass — gaining access to documents or accounts without authorisation
- Data exposure — access to document content without valid grants
- Privilege escalation — accessing capabilities beyond your assigned role
- Cryptographic weaknesses in our implementation (not in the underlying standards)
Out of Scope
- Denial-of-service attacks or any testing that degrades system availability
- Social engineering of Veritas or Trinity DAO personnel
- Physical security attacks on infrastructure
- Automated scanning results without demonstrated exploitability
- Theoretical vulnerabilities in NIST-standardised cryptographic algorithms
Researchers who follow this policy and report in good faith — without unauthorised access to production data, without disclosure to third parties before resolution, and without denial-of-service testing — will not face legal action from Veritas or Trinity DAO Pty Ltd in relation to their security research.
Security Standards & Commitments
Built to hold documents that must remain true
for the next 50 years.
Security questions? Contact us at [email protected] or request early access to discuss your specific requirements.