Security

Security Model Overview

ProofChain's security architecture combines cryptographic controls (HXMP encryption), decentralized tamper-evidence (X1 on-chain commitments), identity-based access control (wallet-authenticated AgentIDs), and defense-in-depth network posture (firewall, CrowdSec, rate limiting). Each layer is designed so that a compromise of one layer does not expose the others: ciphertext is useless without keys, keys are useless without the right identity, and the ledger is useless as a tampering target because any alteration is publicly detectable.

HXMP End-to-End Encryption at Rest

All potentially personal or sensitive data processed through ProofChain — agent operator identifiers, action logs, timestamps, and compliance-report inputs — is encrypted at rest using HXMP, ProofChain's hybrid encryption scheme. Key properties:

• Hybrid construction. HXMP combines asymmetric key encapsulation with symmetric bulk encryption: each record is encrypted with a unique data key, which is itself wrapped by the authorized recipients' public keys.
• Encrypt before storage. Data is encrypted prior to being written to storage or committed to the X1 blockchain. ProofChain never stores plaintext copies of protected records.
• Key separation. Keys are managed and stored independently from ciphertext, so a storage-layer breach yields only unreadable ciphertext.
• Recipient scoping. Only the key holders designated by the customer workspace can unwrap record keys; ProofChain operators holding no such keys cannot decrypt customer records.
• In transit. All transport uses TLS 1.2 or later; HXMP protects data at rest and on-chain, while TLS protects it in motion.

On-Chain X1 Immutability

ProofChain records cryptographic commitments of agent actions and compliance events on the X1 blockchain. On-chain records are immutable by design:

• Tamper-evidence. Any attempt to alter, backdate, or delete a recorded event would break the chain of hashes and be publicly detectable by anyone verifying against the ledger.
• Public verifiability. Attestations and registry entries can be verified independently — for example via the AgentID verification surface — without trusting ProofChain's servers.
• Distributed redundancy. Records do not live only on our infrastructure; they are replicated across the network, eliminating single-point data loss and single-point tampering.
• Accountability. Immutability is the foundation of ProofChain's compliance value: audit trails that cannot be rewritten are audit trails a regulator can trust.

Cryptographic Erasure

Because on-chain records cannot be deleted, ProofChain implements cryptographic erasure as the erasure mechanism for personal data (GDPR Article 17 compliance):

• When erasure is required, ProofChain destroys the HXMP encryption keys associated with the relevant records, rendering the ciphertext permanently and irreversibly unreadable.
• Key destruction is a logged, attested operation: ProofChain records a verifiable erasure attestation on-chain, so the fact and time of erasure are themselves provable.
• After key destruction, no party — including ProofChain — can recover the plaintext, which satisfies the standard of erasure recognized under applicable data protection law.
• Backup and replication copies of ciphertext are equally unreadable once keys are destroyed; no separate plaintext or key copies are retained.

Wallet-Based Authentication (AgentID)

ProofChain uses wallet-based authentication as its primary identity model. Each agent and each operator is identified by an AgentID — a pseudonymous, cryptographic identity derived from a public key held in the agent's or operator's wallet:

• No passwords, no shared secrets. Authentication is performed by signing a challenge with the wallet's private key; ProofChain never stores passwords or password-equivalent credentials.
• Non-repudiation. Actions attributed to an AgentID are backed by the signer's private key, providing cryptographic attribution for audit trails.
• Self-sovereign. Identities are not issued by ProofChain; they belong to the wallet holder and can be verified independently of our infrastructure.
• Key rotation and revocation. Compromised keys can be rotated or revoked, with the rotation event itself recorded on-chain for accountability.
• Pseudonymity. AgentIDs are cryptographic identifiers, minimizing the collection of directly identifying personal data.

API Key Scoping

Where API keys supplement wallet-based authentication for programmatic access, ProofChain enforces granular scoping:

• Per-key permissions. Each API key is restricted to a defined set of operations (e.g. read-only audit queries, report generation, agent registration) and cannot be used outside its scope.
• Per-workspace isolation. Keys are bound to a single customer workspace and cannot access other workspaces' data.
• Least privilege by default. New keys are created with the minimum permissions required and must be explicitly elevated.
• Rotation and revocation. Keys can be rotated or revoked at any time; revocation takes effect immediately.
• Usage visibility. Key usage is logged, and customers can audit which key performed which operation.

Rate Limits

All public and authenticated endpoints are subject to rate limiting to mitigate brute-force, credential-stuffing, enumeration, and denial-of-service abuse:

• Per-IP and per-key limits are enforced at the edge for authentication endpoints, API routes, and form submissions.
• Exceeding a limit triggers exponential backoff or a temporary block, with automated alerts.
• Repetitive abusive traffic is escalated to CrowdSec-managed decisions (see §8).
• Legitimate traffic patterns are not affected; limits are configured conservatively above expected use.

Network Posture: Firewall and CrowdSec

ProofChain infrastructure is protected by a layered network defense:

• Host and network firewalls. Only required ports are exposed; administrative interfaces are restricted to approved sources; internal services are segmented.
• CrowdSec. A crowd-sourced IP reputation engine continuously correlates attack signals across a global community. Suspicious IPs are automatically blocked or challenged based on shared threat intelligence, and local detections feed back into the community.
• Intrusion detection and monitoring. Traffic anomalies, failed-authentication patterns, and scanning behavior generate automated alerts for the operations team.
• TLS everywhere. All public surfaces are served over HTTPS with modern TLS configuration; HSTS is enforced where supported.
• Hardened hosts. Production hosts run minimal software, apply security updates promptly, and enforce strong local access controls with key-based authentication only.

Data Minimization and Pseudonymity

Security is also achieved by not holding data in the first place. ProofChain collects only what the service requires: cryptographic identifiers instead of email addresses where possible, encrypted records instead of plaintext logs, and no tracking cookies or behavioral data (see the Cookie Policy). This minimizes the blast radius of any potential compromise.

SOC 2 Type II Controls Mapping

ProofChain's controls are designed to satisfy the AICPA SOC 2 Type II trust services criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy). The table below maps our implemented controls to the relevant criteria. ProofChain is pursuing SOC 2 Type II attestation; the mapping documents the control environment today.

Vulnerability Disclosure Program

We take the security of our systems seriously and welcome the help of the security research community. If you believe you have found a security vulnerability in ProofChain:

• Contact: security@proofchain.us — please use PGP encryption where available (key published on request).
• Do not test against production customer data, perform denial-of-service testing, or exfiltrate data beyond what is necessary to demonstrate the issue.
• Provide a clear description of the vulnerability, the affected surface, reproduction steps, and your suggested fix or impact assessment.
• Response commitment. We acknowledge receipt within 5 business days and provide a preliminary assessment within 15 business days. We work with researchers to coordinate disclosure and will not pursue legal action against good-faith researchers who follow this policy.

Incident Response

ProofChain operates a documented incident response process aligned with NIST SP 800-61 guidance:

• Detection and reporting. Security events are detected through automated monitoring, CrowdSec telemetry, and external reports; any suspected incident is reportable to the on-call security team 24/7.
• Assessment and triage. Incidents are classified by severity and impact; data breaches involving personal data are escalated immediately and trigger GDPR Article 33 obligations.
• Containment. Affected systems are isolated; compromised credentials and keys are revoked or rotated; rate limits and firewall decisions are updated.
• Eradication and recovery. Root cause is identified and remediated; systems are restored from verified backups or on-chain records; integrity of the ledger is re-verified.
• Notification. Personal data breaches are notified to affected customers without undue delay and in any event within 72 hours of confirmation, with details of nature, scope, and mitigation (see the DPA §9).
• Post-incident review. Lessons learned are documented, controls are hardened, and — for incidents affecting integrity or availability — the on-chain record of the event and response is preserved as evidence.

Access Control and Personnel Security

Access to production systems, decryption keys, and customer workspaces is governed by least-privilege principles: wallet-based authentication for customer-facing access, role-based access for personnel, quarterly access reviews, and immediate revocation on role change or departure. All personnel are bound by confidentiality obligations and receive security awareness training, including secure handling of keys and credentials.

Logging, Monitoring, and Auditability

Security-relevant events — authentication attempts, key usage, administrative actions, rate-limit violations, and erasure operations — are logged and monitored. Customer-facing events are additionally committed to the X1 chain where they form part of compliance evidence, giving customers a tamper-evident, independently verifiable record of activity. Logs are access-controlled and retained for the periods described in our Privacy Policy.

Business Continuity and Backup

Encrypted data is backed up with redundancy across availability zones, and on-chain records provide an additional, network-replicated copy of commitments. Recovery procedures are tested; recovery point and time objectives are documented. In the event of infrastructure loss, the on-chain ledger ensures that compliance evidence — the core value of the service — survives independently of ProofChain's servers.

Compliance Alignment

ProofChain's security controls align with the frameworks our customers must satisfy:

• GDPR Art. 32 — appropriate technical and organizational measures, including encryption, access control, and regular testing (see §2–§8, §13).
• GDPR Art. 5(1)(f) — integrity and confidentiality of processing, protected against unauthorized or unlawful processing and accidental loss.
• EU AI Act — transparency and record-keeping for AI agents: tamper-evident audit trails and verifiable AgentID attribution support deployer obligations under Articles 12 and 50.
• SOC 2 Type II — the controls mapping in §10.
• NIS2 — risk management, incident reporting, and supply-chain security practices as applicable to digital infrastructure providers.

Contact the Security Team

For security questions, disclosures, or to request our security documentation: