Security
The asset worth stealing here is not the money. It is the address book.
This page describes the security properties of the architecture, the vulnerability disclosure policy, and where we stand on certification, which is nowhere yet and is stated as such.
Threat model
We hold no funds and no keys that can move funds, so the obvious attack is not available. What we do hold is the knowledge of which institutions are watching which addresses. Knowing that a particular treasury monitors a particular set of settlement addresses tells you how that treasury is structured and where it is exposed. For an attacker, and for a competitor, this is the highest-value data in the system.
The consequence runs against normal operational instinct: address book confidentiality ranks above availability. When we cannot guarantee isolation between customers, the correct behaviour is to refuse service rather than to degrade it and stay up.
Controls
Architecture-level, so that the property survives an operational mistake rather than depending on nobody making one.
| Control | How it works |
|---|---|
| Address book encryption | Envelope encryption. One data key per customer, wrapped by a customer-specific key in a KMS. The service holds ciphertext and never the plaintext book. |
| Matching without decryption | An HMAC index is computed under the customer key. Matching runs against the index, so answering a query does not require unwrapping anything. |
| Cross-customer isolation | Customer identifier is the partition key and the first column of the primary key on every customer table, injected at the query layer. The target is a query across customers that cannot be written, not one that is denied. |
| Evidence immutability | Every external fetch is snapshotted as retrieved. Snapshots are content-addressed and stored with versioning and object lock. Decision records reject updates and deletes. Derived conclusions can be recomputed; raw data is never rewritten. |
| Audit logging | Every internal access, including operational and support queries, is appended to a separate log. You can export the portion that concerns you, on demand, without asking us what we looked at. |
| Key management | Customer keys live in a KMS with rotation. In a self-hosted deployment the KMS is yours, which means the operator of the software and the holder of the keys are the same party: you. |
| Collector credentials | Read-only, scoped per endpoint. There is no credential anywhere in the system that can sign a transaction, so there is no credential worth stealing for that purpose. |
| Public pipeline separation | The pipeline that produces the public record is physically separate from the one that holds customer data. There is no code path by which an address book can reach anything we publish. |
Deployment models
- Self-hosted (default)
- The software runs in your environment. Your address book, your decision records and your evidence store never leave it. We receive operational telemetry only if you choose to send it, and it contains no addresses.
- Managed
- Available where self-hosting is not practical. The region is fixed at onboarding and written into the contract. All controls above apply, plus the audit log export, which exists so that you do not have to trust the assertion.
Vulnerability disclosure
We would rather hear it from you than read it later. Report to security@4shock.xyz.
Scope
In scope
- 4shock.xyz and its subdomains
- The published client SDK and verifier repositories
- The self-hosted distribution and its default configuration
- Any issue that could expose one customer's data to another, which we treat as the most severe class regardless of how hard it is to reach
Out of scope
- Third-party services we do not operate
- Social engineering of staff, suppliers or customers, and physical access
- Volumetric denial of service and load testing of any kind
- Scanner output with no demonstrated impact, including missing headers with no exploit path
- Findings that require a compromised endpoint or a malicious browser extension already present
Response targets
- Acknowledgement
- Within three business days
- Triage and initial assessment
- Within ten business days
- Status updates while open
- At least every fourteen days
- Coordinated disclosure
- Ninety days by default, earlier by agreement, with an advisory published here
There is no monetary bounty at present, and we will not imply one by calling it something else. Reporters are credited by name or handle if they want it, and anonymously if they do not. If a bounty is introduced, it will be announced in the newsroom rather than mentioned quietly on this page.
security.txt
Machine-readable contact details are published under RFC 9116 and point back to this page.
Certification status
We hold no security certification today. Stating that plainly is cheaper than being asked for a report we do not have.
- SOC 2 Type II Planned
- Planned, because institutional procurement asks for it. The observation window has not started. When it does, the start date and the expected report date get published here.
- ISO 27001
- Not held, not in progress, and not claimed anywhere in our materials.
- Third-party penetration test Planned
- Planned before the first production deployment. Its summary will be published, and the full report made available under NDA.
Until each of those lines changes, treat this page as the whole of the evidence, and treat the self-hosted deployment as the control that does not depend on it.