Post-quantum tamper-evident audit trail
for enterprise databases, built to last decades.
BusyXChain anchors cryptographic fingerprints of your database changes on an independent, Byzantine fault-tolerant ledger and signs them with NIST-standardised ML-DSA (FIPS 204). Your records stay verifiable long after today’s signatures could be forged. Raw data never leaves your infrastructure.
Independent, verifiable evidence for regulated industries.
On-premise first. · No application code changes. · No data migration.
Why Signatures Made Today Must Outlive the Quantum Transition
⚠️ The Risk: Forged History
Quantum computers able to run Shor’s algorithm at scale would break the RSA and elliptic-curve signatures that protect most enterprise records today. Nobody can say when. But invoices, contracts, medical files and audit logs must stay trustworthy for 10 to 30 years. A signature forged in 2035 on a record from 2026 is still a forged record.
- Forged history (integrity): a future attacker rewrites or fabricates signed records. This is the risk BusyXChain addresses.
- Harvest now, decrypt later (confidentiality): traffic and backups stolen today are decrypted later. This is addressed by post-quantum TLS and encrypted storage in your own stack. BusyXChain complements it and does not replace it.
- Regulatory context: DORA (in force since January 2025) requires an ICT risk management framework that includes cryptographic controls, and NIS2 requires appropriate cryptography measures. The EU has published a coordinated roadmap for the transition to post-quantum cryptography, and NIST’s draft IR 8547 proposes retiring RSA and elliptic-curve signatures by 2030 and disallowing them by 2035. Regulators do not prescribe a product. They expect a documented plan.
🛡️ What BusyXChain Does
A post-quantum, tamper-evident audit trail for enterprise databases: signed fingerprints of every change, witnessed by an independent validator network and verifiable by auditors without trusting your administrators or us.
- It does: anchor fingerprints of database changes, sign them with ML-DSA-65, and make later modification, deletion or rollback of anchored records detectable.
- It does not: encrypt your database, replace TLS, single sign-on or key management, prevent a privileged user from changing data, or decide whether a change was authorised.
- Status: prototype. 4-node test network, PostgreSQL adapter in development.
Three Layers, Each With One Job
An evidence layer captures and signs, a gateway submits, and an independent validator network witnesses. Each layer can be reviewed and tested on its own.
The Evidence Layer and the Gateway run entirely inside your own network. Raw data never leaves your infrastructure. Only signed Merkle roots travel to the shared validator network, over outbound-only connections.
Validator Network — Independent Witness Prototype
- ML-DSA-65: NIST FIPS 204 signatures, a lattice-based algorithm designed to resist quantum attacks (NIST security category 3).
- PBFT consensus: safe while at most f of 3f+1 validators are faulty, with deterministic finality under standard BFT assumptions.
- SHA-3 hashing for block chaining and Merkle roots.
- Validators are operated by separate organisations, so no single party can rewrite history.
Gateway — Outbound-Only Bridge In development
- Durable submission queue: signed roots are retried until confirmed. Events are never silently dropped.
- Outbound-only connection: mutually authenticated TLS to the validator network. No inbound ports are opened on your side.
- Post-quantum transport: hybrid key exchange is planned.
- Optional zero-knowledge proofs for selected use cases (research).
Evidence Layer — Capture & Sign Prototype
- Data isolation: raw data never leaves your infrastructure. Only signed Merkle roots do.
- Database adapters: change capture through the mechanism native to each database. PostgreSQL first.
- Integrity verification: periodic checks detect later modification, deletion or rollback of anchored records and raise an alert.
- Salted hashes for personal data (planned).
Performance. Design target: finality within a few seconds. Measured on a 4-validator LAN test network: about 0.6 seconds per consensus round. Figures for larger, geographically distributed networks will be published once measured.
Layer Architecture Comparison
| Property | Validator Network | Gateway | Evidence Layer |
|---|---|---|---|
| Primary Goal | Independent witness | Reliable submission | Evidence capture |
| Cryptography | ML-DSA-65, PBFT, SHA-3 | Mutual TLS, outbound-only | Canonical hashing, Merkle trees, ML-DSA-65 |
| Data Visibility | Signed roots only | Roots and receipts | Full (owner only) |
| Location | Shared validator network | Your network | Your network |
| Resilience Against | Forged history, Byzantine validators (up to f) | Lost or delayed submissions | Later tampering (detective control) |
Database Integration Without Application Changes
Your application keeps issuing the same SQL and API calls. A small change-capture component is installed on the database side, using the mechanism native to each system. Your application code is not touched.
bxchain_anchor
Illustrative Example — SAP Invoice (BKPF) Planned
-- SAP creates an invoice (unchanged) INSERT INTO BKPF (BUKRS, BELNR, GJAHR, BLART, BLDAT, BUDAT, WAERS, WRBTR) VALUES ('1000', '1900000847', '2026', 'DR', '2026-03-15', '2026-03-15', 'EUR', 125000);
-- 1. Same posting — SAP is unchanged INSERT INTO BKPF ... VALUES ('1000', '1900000847', ...); -- 2. Adapter runs in the background: -- change captured (supported SAP mechanism) -- canonical record + salted SHA-3-512 -- added to a Merkle batch -- root signed with ML-DSA-65 and anchored -- 3. Receipt stored in a custom table: INSERT INTO ZBXC_ANCHOR (BUKRS, BELNR, GJAHR, BATCH_ID, MERKLE_PROOF) VALUES ('1000', '1900000847', '2026', '...-000847', '...'); -- SAP standard tables are never modified.
Integration Flow
Supported Systems
Anchored Batch (example)
{
"namespace": "prod_erp",
"batch_id": "2026-10-20T09:23:11Z-000847",
"merkle_root": "23e122e9b207...",
"record_count": 512,
"alg": "ML-DSA-65",
"signer_key_id": "adapter-prod-01",
"signature": "<ML-DSA-65 sig>",
"timestamp": "2026-10-20T09:23:11Z"
}
What the Audit Trail Proves
That a record had a given value when it was anchored, and that the history has not been altered since. It does not prove that a change was authorised. We recommend anchoring database audit logs as well (planned). There is a delay of a few seconds between a write and its anchoring.
Personal data. Hashes of personal data are themselves personal data. We use salted hashes, and deleting the salt unlinks the on-chain value from the record to support erasure requests (planned; to be confirmed with your data protection officer).
Zero-Knowledge Proofs (zk-STARKs) Research
For use cases where you need to prove something about private data without disclosing it, for example that no invoice exceeds the approved limit. Hash-based, no trusted setup, built on assumptions believed to resist quantum attacks.
Development Roadmap
Milestones follow evidence. Dates are published once they are backed by completed work.
How BusyXChain Differs
Where an independent witness and post-quantum signatures matter, and where a simpler tool is enough.
| Dimension | BusyXChain | Built-in database ledgers | Permissioned blockchain frameworks | Cloud ledger & KMS services |
|---|---|---|---|---|
| Trust model | Independent validator network as external witness | Inside one vendor’s trust domain | Consortium; depends on how it is set up | Provider-hosted |
| Post-quantum signatures | ML-DSA-65 Prototype |
Typically classical today | Not out of the box | Emerging in key management services |
| Database integration | Adapter at the database layer, no application code changes PostgreSQL first |
Native to that one database | Custom chaincode or SDK work | Custom integration |
| Data location | Raw data stays on your infrastructure | In your database | On-premise possible | Provider cloud |
| Best fit | Long-term independent evidence for regulated enterprises | Tamper-evidence inside a single trust domain | Multi-party business workflows | Managed convenience |
Building since 2016 —
through every bear market
Prague-based. 8+ years of blockchain infrastructure. While others chased trends, we built deep tech. That's why we were ready to implement quantum resistance the moment NIST finalized the standard.
- Applied Mathematics — CTU Prague
- 8+ yrs blockchain infrastructure & security
- Ethical hacker at Kybernet (financial institutions)
- Embedded systems engineer at ASUS
- Web 3.0 market since 2017
- Trend forecasting & real-world use cases
- Business development & investor relations
- Led successful Gate.io token listing
- 10+ yrs: IT, Finance, Project Management
- Backend development & technical operations
- Enterprise architecture & integration strategy
- Managing organization's technical roadmap
- Former engineer — Gov. of India (1.2B+ users)
- Full-stack: JavaScript, Go, Python
- Hyperledger Sawtooth & Fabric experience
- BSc Chemical Engineering, IIT Roorkee
Evidence That Outlives
Today’s Cryptography.
Anchor changes from your on-premise databases without touching application code. Post-quantum signatures and an independent validator network give auditors evidence they can verify on their own. Deployed inside your own network.
info@busyxchain.network · Prague, Czech Republic · © 2026 BusyXChain Foundation