Recorded traffic
Attackers can record encrypted sessions today and retain them for future decryption. This is called harvest now, decrypt later.
Research, client information, and internal communications can remain sensitive after a session ends.
Products / Connections
In developmentQuantumLink
Keep business communications private.
QuantumLink helps your organization protect client information, research, and business plans from long-term exposure while teams work across locations.
Quantum risk
Connection risk
A private connection needs to protect both the traffic and the identity of each device.
A sufficiently capable quantum computer could break widely used public-key encryption and digital signatures.
Source: NIST
Device impersonation
Future attacks on vulnerable signing keys could let an attacker impersonate a device that your network trusts.
Protecting traffic also requires checking who can join the connection.
QuantumLink
Private connections
QuantumLink is designed to connect devices through an encrypted mesh: devices communicate directly where possible and use a relay when needed. Public meshes check peer identity through Dytallix. Network traffic stays off-chain.
Verified peers
Check device identity before establishing a connection. Set which peers your team can trust.
Protected sessions
Use post-quantum session establishment to address future attacks on vulnerable key exchange.
Direct paths
Connect peers directly when reachable. Use a relay when network conditions prevent a direct path.
Traffic policy
Choose the routes and applications in scope. Define when traffic must stop if protection fails.
Mesh policy and data paths
QuantumLink is in development. Each pilot must record its cryptographic profile, key storage, relay operator, and failure policy.
Private mesh
Local policy defines approved peers. This mode does not require L1.
Public mesh
The Dytallix registry supplies peer identity records. The chain does not carry session traffic or packets.
Keys and relays
The pilot must identify where each device stores private keys and who operates each relay. Use a direct path where available. Record relay access and metadata handling before deployment.
Failure policy
Define which connections stop if peer verification fails. Test new and existing connections during registry or relay outages before accepting the build.
How it works
How it connects
- 01
Create a device identity. Record and verify the pilot build's device-key storage before use.
- 02
Check peer identity against the mesh's trust policy. Public meshes require a matching Dytallix registry record.
- 03
Discover reachable peers through signed records that expire.
- 04
Authenticate the peer and establish session keys. Select a direct path or use a relay when required.
- 05
Apply the approved routing and failure policy. Carry encrypted traffic outside the blockchain.
Pilot requirements
QuantumLink is in development. Agree on a supported build and a limited pilot before deployment.
- Environment
- Endpoint inventory, operating systems, network topology, and access constraints.
- Policy
- Allowed traffic, endpoint identity rules, routing, and failure behavior.
- Acceptance
- Connection tests, traffic-leak checks, installation, removal, and rollback criteria.
- Record
- Build identifier, cryptographic profile, approved paths, test results, and known exceptions.
Limits
QuantumLink is not an anonymity network. Connection protection does not secure the full endpoint. Malware, application defects, identity errors, and access controls need separate treatment. Data can be exposed after an endpoint decrypts it.
Individual use cases
Journalists and sources
Reduce the long-term exposure of sensitive communications. Connect known devices through a private path when exchanging unpublished work.
Developers
Reach your development machines and test environments privately. Keep internal services accessible to approved peers without exposing them to the public internet.
Remote teams
Work together across locations while keeping shared systems private. Connect teammates through approved peer paths with less dependence on a central gateway.
Personal privacy
Reach your home computer, storage, or private services while away. Keep control of the devices you trust and the connections you permit.
Researchers and auditors
Assess the design before relying on it. Use the open protocol and technical papers to examine peer identity, session protection, and trust decisions.
Sensitive environments
Limit access to known peers when handling sensitive work. Define which traffic can connect and when it must stop if protection fails.