Open protocol / COLDCARD Q

Move secrets.Not trust.

Key Teleport moves highly sensitive data between two COLDCARD Q devices. Secrets are wrapped on the sender, moved as encrypted BBQr, and opened only by the intended receiver.

  • Endpoint encrypted
  • Transport agnostic
  • One-time receive keys
Transfer mapKT / 01

A secret crosses the gap. Its keys do not.

The protocol separates the encrypted packet from the short passwords needed to use it. The receiver and sender each contribute fresh key material, while the human confirms the handoff through a different channel.

01 / RECEIVE

Create a one-time destination

The receiving Q creates and stores a fresh elliptic-curve keypair, then publishes its encrypted compressed public key as an R-type BBQr.

02 / SEPARATE

Split the channels

The receiver shares the BBQr and its eight-digit Receiver Password separately. A phone call, in-person note, or another independent path is the point.

03 / WRAP

Encrypt twice

The sending Q creates its own keypair, derives an ECDH session key, and wraps the typed payload under both that session and a fresh eight-character Teleport Password.

04 / DESTROY

Open once, then forget

The receiver reconstructs the session key, checks both layers, asks for the Teleport Password, imports the decoded item, and deletes the receive keypair after success.

Two gates around one payload.

ECDH protects the destination. The Teleport Password adds an independent human-held layer. Neither the website nor the QR transport needs to understand what is inside.

Outer layer / device-to-device

ECDH → SHA-256 → AES-256-CTR

Fresh sender and receiver keypairs arrive at the same session key. The key is derived by hashing the ECDH point coordinates, then used to encrypt the packet body.

Inner layer / human-held

40-bit password → PBKDF2-SHA512 → AES-256-CTR

An eight-character Base32 Teleport Password is stretched with the session key as context. Its derived upper 256 bits wrap the secret itself.

The package declares what it is.

A one-byte type code tells the receiving COLDCARD how to handle plaintext only after successful decryption. Key Teleport does not decode arbitrary content.

s

Seeds

12 / 18 / 24 words, raw master secret, or compact XPRV material

x

Extended private keys

XPRV mode plus decoded binary extended-key details

n

Secure notes

One or more exported notes encoded as a JSON array

v

Seed Vault items

A secret together with its name and source metadata

p

PSBTs

A binary Partially Signed Bitcoin Transaction ready for signing

b

System backups

A complete COLDCARD backup in its internal text format

The browser sees ciphertext.

keyteleport.com is the COLDCARD-branded QR rendezvous. A Q can put an encrypted BBQr packet after the URL hash; the static page renders that packet for scanning without interpreting its contents.

Open COLDCARD rendezvous
URL boundary
https://keyteleport.com/#B$2R01…ENCRYPTED
Server requestorigin + path
Browser onlyfragment / encrypted BBQr
The fragment is not included in the HTTP request. It remains in the browser.

Encryption is one part. Ceremony is the other.

Key Teleport assumes supported COLDCARD Q endpoints and careful humans. Its short passwords are practical to speak or write—but only provide their intended separation when they travel by a different path than the BBQr.

Use it as designed

  • Share the Receiver Password separately from the receiver BBQr.
  • Share the Teleport Password separately from the encrypted payload.
  • Confirm the person and destination before exporting keys that control funds.
  • Keep both Q devices on firmware that supports the same protocol behavior.

Know the boundary

  • NFC URL transport is limited to roughly 4 KiB after encoding; direct BBQr is not subject to that URL limit.
  • The current firmware design requires COLDCARD Q because QR scanning is part of the receive path.
  • Encrypted QR images reveal no on-chain identity by themselves, but unnecessary copies still enlarge operational exposure.
  • The protocol protects the handoff; it cannot rescue a compromised endpoint or a disclosed password.
Key Teleport can transfer seeds and XPRVs. The receiver gains full access to any Bitcoin controlled by those keys. Treat the handoff like the keys themselves.

A fast lane for co-signers.

When both devices already share a multisig wallet, the sender can derive a one-time destination from the receiver's known XPUB. No receiver setup QR or numeric Receiver Password is needed.

Derived rendezvous

The sender chooses a random 28-bit nonce and derives the co-signer key at …/20250317/{nonce}. The nonce travels in the clear; the PSBT remains wrapped under the derived ECDH session and Teleport Password.

Daisy-chain signing

After signing, each co-signer can teleport the updated PSBT to the next. The final required signer can finalize it and, where appropriate, broadcast with COLDCARD PushTx.

Short answers to serious questions.

Is keyteleport.org the transfer service?

No. This .org site documents the protocol and does not accept, render, or process transfer payloads. The optional COLDCARD-branded QR rendezvous remains at keyteleport.com.

Why are the passwords short?

They are designed to be practical over an independent human channel: a phone call, handwritten note, or in-person exchange. The eight-character Teleport Password represents 40 random bits and is stretched inside the protocol. The eight-digit Receiver Password protects a public key and is intended to expose an injected replacement key when the channels are kept separate.

Can the encrypted QR be saved or sent through a cloud service?

The protocol design treats this as acceptable because the QR carries encrypted data, the one-time receiver key is forgotten after a successful transfer, and the separately shared Teleport Password is still required. Avoiding extra copies remains the cleaner operational choice whenever practical.

Is the protocol specification public?

Yes. The design document, firmware implementation, and tests live in the public COLDCARD firmware repository. The firmware document is authoritative when this overview and implementation details differ.