Get desktop application:
View/edit binary Protocol Buffers messages
* Response: Contains address derived from device private seed @prev GetAddress
Coin address in Base58 encoding
* Request: set flags of the device @next Success @next Failure
bitmask, can only set bits, not unset
* Request: change language and/or label of the device @next Success @next Failure @next ButtonRequest @next PinMatrixRequest
* Request: Perform backup of the device seed if not backed up using ResetDevice @next ButtonRequest
(message has no fields)
* Request: Computer agrees to wait for HW button press @prev ButtonRequest
(message has no fields)
* Response: Device is waiting for HW button press. @next ButtonAck @next Cancel
* Type of button request @used_in ButtonRequest
Used in:
* Request: Abort last operation that required user interaction @prev ButtonRequest @prev PinMatrixRequest @prev PassphraseRequest
(message has no fields)
* Request: Starts workflow for setting/changing/removing the PIN @next ButtonRequest @next PinMatrixRequest
is PIN removal requested?
* Request: Ask device to encrypt or decrypt value of given key @next CipheredKeyValue @next Failure
BIP-32 path to derive the key from master node
key component of key:value
value component of key:value
are we encrypting (True) or decrypting (False)?
should we ask on encrypt operation?
should we ask on decrypt operation?
initialization vector (will be computed if not set)
* Response: Return ciphered/deciphered value @prev CipherKeyValue
ciphered/deciphered value
* Request: clear session (removes cached PIN, passphrase, etc). @next Success
(message has no fields)
* Structure representing Coin @used_in Features
Used in:
default=0x0488b21e
default=0x0488ade4
* Request: "Press" the button on the device @next Success
true for "Confirm", false for "Cancel"
* Request: Erase block of flash on device WARNING: Writing to the wrong location can irreparably break the device.
* Request: Computer asks for device state @next DebugLinkState
(message has no fields)
* Response: Device wants host to log event
* Response: Device sends memory back @prev DebugLinkMemoryRead
* Request: Read memory from device @next DebugLinkMemory
* Request: Write memory to device. WARNING: Writing to the wrong location can irreparably break the device.
* Response: Device current state @prev DebugLinkGetState
raw buffer of display
current PIN, blank if PIN is not set/enabled
current PIN matrix
current BIP-39 mnemonic
current BIP-32 node
is node/mnemonic encrypted using passphrase?
word on device display during ResetDevice workflow
current entropy during ResetDevice workflow
(fake) word on display during RecoveryDevice workflow
index of mnemonic word the device is expecting during RecoveryDevice workflow
* Request: Ask device to restart
(message has no fields)
* Request: Ask device to decrypt message @next Success @next Failure
BIP-32 path to derive the decryption key from master node
nonce used during encryption
message to decrypt
message hmac
* Response: Decrypted message @prev DecryptedMessage
decrypted message
address used to sign the message (if used)
* Response: Device provides ECDH session key @prev GetECDHSessionKey
ECDH session key
* Request: Ask device to encrypt message @next EncryptedMessage @next Failure
public key
message to encrypt
show just on display? (don't send back via wire)
BIP-32 path to derive the signing key from master node
coin to use for signing
* Response: Encrypted message @prev EncryptMessage
nonce used during encryption
encrypted message
message hmac
* Response: Reply with random data generated by internal RNG @prev GetEntropy
stream of random generated bytes
* Request: Provide additional entropy for seed generation function @prev EntropyRequest @next ButtonRequest
256 bits (32 bytes) of random data
* Response: Ask for additional entropy from host computer @prev ResetDevice @next EntropyAck
(message has no fields)
* Request: Estimated size of the transaction This behaves exactly like SignTx, which means that it can ask using TxRequest This call is non-blocking (except possible PassphraseRequest to unlock the seed) @next TxSize @next Failure
number of transaction outputs
number of transaction inputs
coin to use
* Response: Contains an Ethereum address derived from device private seed @prev EthereumGetAddress
Coin address as an Ethereum 160 bit hash
* Request: Ask device for Ethereum address corresponding to address_n path @next PassphraseRequest @next EthereumAddress @next Failure
BIP-32 path to derive the key from master node
optionally show on display before sending the result
* Response: Signed message @prev EthereumSignMessage
address used to sign the message
signature of the message
* Request: Ask device to sign message @next EthereumMessageSignature @next Failure
BIP-32 path to derive the key from master node
message to be signed
* Request: Ask device to sign transaction All fields are optional from the protocol's point of view. Each field defaults to value `0` if missing. Note: the first at most 1024 bytes of data MUST be transmitted as part of this message. @next PassphraseRequest @next PinMatrixRequest @next EthereumTxRequest @next Failure
BIP-32 path to derive the key from master node
<=256 bit unsigned big endian
<=256 bit unsigned big endian (in wei)
<=256 bit unsigned big endian
160 bit address hash
<=256 bit unsigned big endian (in wei)
The initial data chunk (<= 1024 bytes)
Length of transaction payload
Chain Id for EIP 155
* Request: Transaction payload data. @prev EthereumTxRequest @next EthereumTxRequest
Bytes from transaction payload (<= 1024 bytes)
* Response: Device asks for more data from transaction payload, or returns the signature. If data_length is set, device awaits that many more bytes of payload. Otherwise, the signature_* fields contain the computed transaction signature. All three fields will be present. @prev EthereumSignTx @next EthereumTxAck
Number of bytes being requested (<= 1024)
Computed signature (recovery parameter, limited to 27 or 28)
Computed signature R component (256 bit)
Computed signature S component (256 bit)
* Request: Ask device to verify message @next Success @next Failure
address to verify
signature to verify
message to verify
* Response: Failure of the previous request
computer-readable definition of the error state
human-readable message of the error state
* Type of failures returned by Failure message @used_in Failure
Used in:
* Response: Reports various information about the device @prev Initialize @prev GetFeatures
name of the manufacturer, e.g. "bitcointrezor.com"
major version of the device, e.g. 1
minor version of the device, e.g. 0
patch version of the device, e.g. 0
is device in bootloader mode?
device's unique identifier
is device protected by PIN?
is node/mnemonic encrypted using passphrase?
device language
device description label
supported coins
does device contain seed?
SCM revision of firmware
hash of the bootloader
was storage imported from an external source?
is PIN already cached in session?
is passphrase already cached in session?
is valid firmware loaded?
does storage need backup? (equals to Storage.needs_backup)
device flags (equals to Storage.flags)
* Request: Ask device to erase its firmware (so it can be replaced via FirmwareUpload) @next Success @next FirmwareRequest @next Failure
length of new firmware
* Response: Ask for firmware chunk @next FirmwareUpload
offset of requested firmware chunk
length of requested firmware chunk
* Request: Send firmware in binary form to the device @next Success @next Failure
firmware to be loaded into device
hash of the payload
* Request: Ask device for address corresponding to address_n path @next PassphraseRequest @next Address @next Failure
BIP-32 path to derive the key from master node
optionally show on display before sending the result
filled if we are showing a multisig address
used to distinguish between various address formats (non-segwit, segwit, etc.)
* Request: Ask device to generate ECDH session key @next ECDHSessionKey @next Failure
identity
peer's public key
ECDSA curve name to use
* Request: Request a sample of random data generated by hardware RNG. May be used for testing. @next ButtonRequest @next Entropy @next Failure
size of requested entropy
* Request: Ask for device details (no device reset) @next Features
(message has no fields)
* Request: Ask device for public key corresponding to address_n path @next PassphraseRequest @next PublicKey @next Failure
BIP-32 path to derive the key from master node
ECDSA curve name to use
optionally show on display before sending the result
Used in:
BIP-32 node in deserialized form
BIP-32 path to derive the key from node
* Structure representing BIP32 (hierarchical deterministic) node Used for imports of private key into the device and exporting public key out of device @used_in PublicKey @used_in LoadDevice @used_in DebugLinkState @used_in Storage
Used in:
, , ,* Structure representing identity data @used_in IdentityType
Used in:
,proto part of URI
user part of URI
host part of URI
port part of URI
path part of URI
identity index
* Request: Reset device to default state and ask for device details @next Features
(message has no fields)
* Type of script which will be used for transaction output @used_in TxInputType
Used in:
, ,standard p2pkh address
p2sh multisig address
reserved for external inputs (coinjoin)
native segwit
segwit over p2sh (backward compatible)
* Request: Load seed and related internal settings from the computer @next ButtonRequest @next Success @next Failure
seed encoded as BIP-39 mnemonic (12, 18 or 24 words)
BIP-32 node
set PIN protection
enable master node encryption using passphrase
device language
device label
do not test mnemonic for valid BIP-39 checksum
U2F counter
* Response: Signed message @prev SignMessage
address used to sign the message
signature of the message
* Mapping between Trezor wire identifier (uint) and a protobuf message
* Type of redeem script used in input @used_in TxInputType
Used in:
, ,pubkeys from multisig address (sorted lexicographically)
existing signatures for partially signed input
"m" from n, how many valid signatures is necessary for spending
* Type of script which will be used for transaction output @used_in TxOutputType
Used in:
used for all addresses (bitcoin, p2sh, witness)
p2sh address (deprecated; use PAYTOADDRESS)
only for change output
op_return
only for change output
only for change output
* Request: Send passphrase back @prev PassphraseRequest
* Response: Device awaits encryption passphrase @next PassphraseAck @next Cancel
(message has no fields)
* Request: Computer responds with encoded PIN @prev PinMatrixRequest
matrix encoded PIN entered by user
* Response: Device is asking computer to show PIN matrix and awaits PIN encoded using this matrix scheme @next PinMatrixAck @next Cancel
* Type of PIN request @used_in PinMatrixRequest
Used in:
* Request: Test if the device is alive, device sends back the message in Success response @next Success
message to send back in Success message
ask for button press
ask for PIN if set in device
ask for passphrase if set in device
* Response: Contains public key derived from device private seed @prev GetPublicKey
BIP32 public node
serialized form of public node
* Request: Start recovery workflow asking user for specific words of mnemonic Used to recovery device safely even on untrusted computer. @next WordRequest
number of words in BIP-39 mnemonic
enable master node encryption using passphrase
enable PIN protection
device language
device label
enforce BIP-39 wordlist during the process
7 reserved for unused recovery method
supported recovery type (see RecoveryType)
U2F counter
perform dry-run recovery workflow (for safe mnemonic validation)
* Type of recovery procedure. These should be used as bitmask, e.g., `RecoveryDeviceType_ScrambledWords | RecoveryDeviceType_Matrix` listing every method supported by the host computer. Note that ScrambledWords must be supported by every implementation for backward compatibility; there is no way to not support it. @used_in RecoveryDevice
use powers of two when extending this field
words in scrambled order
matrix recovery type
* Type of information required by transaction signing process @used_in TxRequest
Used in:
* Request: Ask device to do initialization involving user interaction @next EntropyRequest @next Failure
display entropy generated by the device before asking for additional entropy
strength of seed in bits
enable master node encryption using passphrase
enable PIN protection
device language
device label
U2F counter
postpone seed backup to BackupDevice workflow
* Request: Perform a device self-test @next Success @next Failure
payload to be used in self-test
* Request: Set U2F counter @next Success
counter
* Request: Ask device to sign identity @next SignedIdentity @next Failure
identity
non-visible challenge
challenge shown on display (e.g. date+time)
ECDSA curve name to use
* Request: Ask device to sign message @next MessageSignature @next Failure
BIP-32 path to derive the key from master node
message to be signed
coin to use for signing
used to distinguish between various address formats (non-segwit, segwit, etc.)
* Request: Ask device to sign transaction @next PassphraseRequest @next PinMatrixRequest @next TxRequest @next Failure
number of transaction outputs
number of transaction inputs
coin to use
transaction version
transaction lock_time
* Response: Device provides signed identity @prev SignIdentity
identity address
identity public key
signature of the identity data
* Request: Simplified transaction signing This method doesn't support streaming, so there are hardware limits in number of inputs and outputs. In case of success, the result is returned using TxRequest message. @next PassphraseRequest @next PinMatrixRequest @next TxRequest @next Failure
transaction inputs
transaction outputs
transactions whose outputs are used to build current inputs
coin to use
transaction version
transaction lock_time
* Response: Success of the previous request
human readable description of action or request-specific payload
* Structure representing transaction @used_in SimpleSignTx
Used in:
,* Request: Reported transaction data @prev TxRequest @next TxRequest
* Structure representing transaction input @used_in SimpleSignTx @used_in TransactionType
Used in:
,BIP-32 path to derive the key from master node
hash of previous transaction output to spend by this input
index of previous output to spend
script signature, unset for tx to sign
sequence (default=0xffffffff)
defines template of input script
Filled if input is going to spend multisig tx
amount of previous transaction output (for segwit only)
* Structure representing compiled transaction output @used_in TransactionType
Used in:
* Structure representing transaction output @used_in SimpleSignTx @used_in TransactionType
Used in:
,target coin address in Base58 encoding
BIP-32 path to derive the key from master node; has higher priority than "address"
amount to spend in satoshis
output script type
defines multisig address; script_type must be PAYTOMULTISIG
defines op_return data; script_type must be PAYTOOPRETURN, amount must be 0
* Response: Device asks for information for signing transaction or returns the last result If request_index is set, device awaits TxAck message (with fields filled in according to request_type) If signature_index is set, 'signature' contains signed input of signature_index's input @prev SignTx @prev SimpleSignTx @prev TxAck
what should be filled in TxAck message?
request for tx details
serialized data and request for next
* Structure representing request details @used_in TxRequest
Used in:
device expects TxAck message from the computer
tx_hash of requested transaction
length of requested extra data
offset of requested extra data
* Structure representing serialized data @used_in TxRequest
Used in:
'signature' field contains signed input of this index
signature of the signature_index input
part of serialized and signed transaction
* Response: Estimated size of the transaction @prev EstimateTxSize
estimated size of transaction in bytes
* Request: Ask device to verify message @next Success @next Failure
address to verify
signature to verify
message to verify
coin to use for verifying
* Request: Request device to wipe all sensitive data and settings @next ButtonRequest
(message has no fields)
* Request: Computer replies with word from the mnemonic @prev WordRequest @next WordRequest @next Success @next Failure
one word of mnemonic on asked position
* Response: Device is waiting for user to enter word of the mnemonic Its position is shown only on device's internal display. @prev RecoveryDevice @prev WordAck
* Type of Recovery Word request @used_in WordRequest
Used in: