
ENCRYPTED CHAT
PRIVATE COMMUNICATION, INTEGRATED WITH YOUR BITCOIN SELF-CUSTODY
Encrypted chat. Bitcoin payments. Watch-Only Wallet. PSBTs. Encrypted cryptograms. All integrated within the Cuvex ecosystem.


E2EE Chat
Private conversations protected by end-to-end encryption.

Bitcoin
Request Bitcoin addresses and send payment requests directly to your contacts.

WOW + PSBT
Accepted requests can be converted into prepared transactions for review and signing.

Cryptograms
Share encrypted copies without sending your seed phrase in plaintext.

ONE CONTEXT,
CLEARLY SEPARATED
FUNCTIONS

01 REQUEST
Request a Bitcoin address or receive a payment request.
02 ACCEPT
The recipient decides whether to proceed with the request.
03 PREPARE
The Watch-Only Wallet provides the address or loads the transaction data.
04 REVIEW
The user verifies the destination address and amount.
05 SIGN
The transaction continues through the Cuvex PSBT flow.
06 BITCOIN
The signed transaction is broadcast to the Bitcoin network.
07 VERIFY
Chat automatically notifies both participants and provides access to the transaction on mempool.space.


ONE CONTEXT,
CLEARLY SEPARATED
FUNCTIONS

REQUEST AN ADDRESS
TO MAKE A PAYMENT
From the chat menu, request a receiving address from your contact. If the recipient accepts, their Watch-Only Wallet will provide an unused address in the conversation so you can make the Bitcoin payment through the Cuvex PSBT flow.

Avoid copying and pasting sensitive information into external platforms and messaging apps.

Avoid address reuse.

Flow directly connected to the recipient’s wallet.
SEND AN INVOICE TO
RECEIVE A PAYMENT
From the chat menu, you can also send payment requests to your contacts. A payment request includes a new Bitcoin address and the requested amount. If the recipient accepts, the payment details are loaded into their Watch-Only Wallet (WOW) to prepare the transaction and complete the payment. You will receive the transaction amount directly in your wallet.
ACCEPTING ≠ SIGNING
Accepting a request does not automatically move Bitcoin. Chat coordinates. WOW prepares. Authorization still depends on the user’s PSBT signing flow.



Authority Architecture
EACH COMPONENT DOES
ONLY WHAT IT NEEDS TO DO
CHAT
01 / COORDINATION
Communicates and coordinates.
WOW
02 / CONSTRUCTION
Manages addresses and prepares transactions.
CUVEX
03 / AUTHORIZATION
Executes the corresponding PSBT signing flow.
BITCOIN
04 / VERIFICATION
Verifies and confirms the transaction.

Chat does not need access to your private keys to facilitate a payment request.

WOW does not need signing capabilities to prepare a transaction.

The messaging layer and cryptographic authority remain separate.
Request → Payment → Broadcast → On-Chain Tracking
SHARE THE BACKUP,
NOT YOUR SEED
Cuvex Chat also allows you to send encrypted Cuvex cryptograms to your contacts as a backup, since the password is always required to decrypt them.

CHAT SECURITY
End-to-End Encryption
Messages use an end-to-end encryption architecture based on the Signal Protocol ecosystem.
Content is encrypted on the sender’s device and decrypted on the recipient’s device.

PQXDH
Hybrid session establishment combining classical and post-quantum cryptographic components.
KEM
Provides the post-quantum key encapsulation component used during session establishment.
DOUBLE RATCHET
Continuously evolves the cryptographic state as the conversation progresses.
KEY TRANSPARENCY
Adds mechanisms for verifying and monitoring cryptographic identity information.
POST-QUANTUM HYBRID E2EE
Cuvex Chat security does not rely on a single algorithm. Each layer serves a different purpose.

TODAY’S PRIVACY MUST ALSO ACCOUNT FOR TOMORROW
Cuvex Chat incorporates PQXDH and KEM mechanisms into session establishment to add post-quantum protection within a hybrid architecture.
​
The technically accurate description is “post-quantum hybrid session establishment.” This does not mean that every cryptographic component in the system is exclusively post-quantum.

Threat Model
HARVEST NOW,
DECRYPT LATER
Why use post-quantum protection today?
An adversary could capture and store encrypted communications today that they are currently unable to decrypt, with the intention of decrypting them in the future as more advanced cryptographic capabilities become available.
​
Cuvex Chat incorporates PQXDH and KEM mechanisms into session establishment to strengthen protection against this threat.
TODAY’S PRIVACY MUST ALSO ACCOUNT FOR TOMORROW
Cuvex Chat incorporates PQXDH and KEM mechanisms into session establishment to add post-quantum protection within a hybrid architecture.
​
The technically accurate description is “post-quantum hybrid session establishment.” This does not mean that every cryptographic component in the system is exclusively post-quantum.

Technical Implementation
FOR THOSE WHO WANT TO LOOK UNDER THE HOOD
The current integration includes components related to PQXDH, KEM, Kem.swift, KeyTransparency.swift, and ChatConnection. The stack also links cryptographic dependencies such as ring 0.17.14.
The current implementation uses libsignal-android 0.86.5, as specified in the Cuvex Chat build, with the functionality required for PQXDH and the corresponding KEM mechanisms.
Technical Implementation
PRIVACY AND AUTHORITY MODEL
Cuvex Chat facilitates communication and prepares transaction contexts, but authority over your funds always remains outside the chat.

Can deliver messages;

Can request a Bitcoin address.

Can send a payment request.

Can interact with WOW.

Can transport an encrypted cryptogram.
Cuvex Chat cannot spend your BTC by accepting a message
* A request can prepare the context for a transaction.
* It does not constitute a cryptographic signature.
Cuvex Chat does not need to decrypt a cryptogram to transport it
Transmitting encrypted information and being able to interpret its contents are separate capabilities.
Cuvex Chat does not replace the signing device
Critical authorization remains within the corresponding self-custody flow.
SUPPORT
Cuvex Chat is an encrypted communication feature integrated into the Cuvex ecosystem that allows users to communicate, request Bitcoin addresses, send payment requests, interact with Watch-Only Wallet, continue PSBT workflows, and share encrypted cryptograms.
Yes. The architecture uses end-to-end encryption based on the Signal Protocol ecosystem.
It uses post-quantum hybrid session establishment based on PQXDH and KEM mechanisms.
Yes. If the contact accepts the request, their WOW can provide an unused receiving address and send it within the conversation.
No. Accepting a request prepares the transaction context. The transaction must still be reviewed and proceed through the appropriate PSBT and signing flow.
Yes. The recipient receives the encrypted object. Possession of the cryptogram does not automatically provide access to the protected secret.
No. Do not send a seed phrase, private key, full PIN, complete password, or any other plaintext recovery secrets through Cuvex Chat.
ONE CONVERSATION.
MULTIPLE SOVEREIGN
WORKFLOWS.
Communicate. Request. Pay. Sign. Verify. Share encrypted backups. Without giving the messaging layer authority over your keys.


AUTOMATIC
PAYMENT
TRACKING
Once the transaction has been signed and broadcast, Cuvex Chat automatically sends a message to both participants. The conversation includes direct access to the transaction on mempool.space.
​
There is no need to return to the chat, copy the TXID, and manually notify the recipient. The conversation itself preserves the complete transaction flow:



