# Offline device transfer

The protocol moves all entries between two existing unlocked Aftercurve vaults without a server or contract. The receiving vault has its own master password. Imported entries are reencrypted under its local key. Nothing changes Ethereum transaction authorization.

1. **Receiving device:** Open Device transfer and click Create request. Keep the downloaded receive-request JSON. The displayed 64-hex-character fingerprint is SHA-256 over the canonical request, including the one-time ML-KEM-768 public key, ID and expiry. The private key stays encrypted inside this vault. The request expires in 30 minutes.
2. Move the request file to the sending device by USB, local file sharing, or another method. Independently read the complete fingerprint from the receiving device's screen, or communicate it using a trusted separate channel. Do not obtain both the request and its fingerprint from the same untrusted source.
3. **Sending device:** Choose the request file and enter that independently verified fingerprint. Encrypt all entries. Download the encrypted package. Communicate its displayed 64-character package fingerprint independently to the receiving device. This binds the receiver to the sender's exact package; the receiver does not assume that any package encrypted to its public key came from the intended sender.
4. **Receiving device:** Choose the package file, enter the fingerprint obtained from the sender, and click Verify & preview. Review the names/count, then explicitly import. Identical entries are skipped and different entries get fresh IDs; no existing entries are overwritten. The receive request is consumed only with a successful local save.

Both fingerprints are required in full; spaces, hyphens and colons are ignored. The comparison cannot protect you when the attacker controls the independent verification channel or the endpoint itself. This is an application-specific, file-based protocol using standardized primitives, not a standardized or independently reviewed pairing protocol.

Requests survive locking because their private key is encrypted within the vault. Backups intentionally omit active receive keys. Creating a new request replaces the previous request. No remote revocation, background synchronization, or sender identity directory exists.