Slovak developer Pavol Rusnák helped build Trezor and establish rules for backing up and restoring Bitcoin wallets. You encounter his work when recording recovery words or moving to another device.
Anna loses her hardware wallet. With the correct backup, she can restore the same private keys in a compatible wallet: the secret data used to authorize spending bitcoin. If she also used a passphrase, an additional password she chose herself, she needs its exact text too. This restores her access to her bitcoin; the records themselves remain on the network, not inside the device. For recovery to work beyond a single product, developers need to agree on how to read a backup and derive keys from it. Pavol Rusnák, known as Stick, helped write and implement some of those agreements. [7] [8] [9] [14]
According to SatoshiLabs’ history, Rusnák and Marek Palatinus began exploring a hardware wallet in 2011 at brmlab, a Prague hackerspace where people share tools and experiment with technology. They wanted to reduce the risk of malicious software stealing keys from an ordinary computer. With Alena Vránová they founded SatoshiLabs in 2013; the first Trezor devices reached customers in 2014. The product grew from collaboration between people with technical and organizational skills, rather than the work of a lone inventor. [1] [4] [15]
When Anna pays with Trezor, an application prepares the transaction and the device signs it after she confirms it. The private key, the secret that authorizes spending, is meant to stay inside the device. What leaves is a signature that the network can verify. That is why a Hardware Wallet has its own screen: Anna checks the address and amount there instead of trusting the computer alone. The device does not itself replace a Full Node that verifies the network’s rules, and it cannot protect a backup published online. [5] [6]
Trezor publishes its hardware designs and the source code for its firmware, the program running inside the device. Other developers can examine how it works, find flaws and propose fixes. Anna does not need to program to benefit from that scrutiny. Openness is not a certificate of perfection, though, nor proof that a particular delivered device has never been tampered with. Actual review, the process used to build the software and checks on the device still matter. [5] [6]
BIP39, assigned on 10 September 2013, lists four authors: Marek Palatinus, Pavol Rusnák, Aaron Voisine and Sean Bowe. It describes encoding computer-generated randomness as words, with a checksum that helps detect mistakes. A common Seed Phrase has 12 or 24 words; it is not a sentence you should invent. The words and an optional passphrase produce a seed, the starting secret from which keys are derived. Recovery requires the exact word order and the original passphrase if one was used. Do not translate the words into another language. [7]
Recovering the starting secret does not automatically locate every address you have used. An HD Wallet derives a tree of keys, rather like a cabinet with many drawers. BIP43 and BIP44, authored by Palatinus and Rusnák, help wallets look in the same places. The BIP44 path is m / 44' / coin_type' / account' / change / address_index: it identifies the purpose, currency, account, receiving or change branch, and individual address. The change branch contains addresses that receive the unused remainder of the amount being spent. For Anna, preserving the account type is the practical point. A path to keys is not a backup of them and cannot replace lost words. [8] [9]
SLIP39 began in 2017 as the work of six authors, including Rusnák. It specifies Shamir Secret Sharing for word-based backups. Anna might choose 3 out of 5 shares: any three recover the protected secret, while two are insufficient. These shares are calculated mathematically; cutting an ordinary word list into pieces does not provide the same protection. SLIP39 and BIP39 are not interchangeable, and the destination wallet must support the right format. Moving between incompatible formats may require a new wallet and a transfer of funds. Understand thresholds, any groups and the passphrase beforehand, and test recovery safely. [10]
Rusnák also co-authored SLIP10, SLIP21 and SLIP44. The first covers key derivation for different cryptographic curves, the mathematical foundations used in different key systems. The second derives separate symmetric keys, where the same secret can serve, for example, to encrypt and decrypt data. The third registers currency identifiers in BIP44 paths so applications do not confuse them. These are developer references. A beginner does not need to study them before making a first payment; their purpose is to let different programs work together under known rules. [11] [12] [13]
In September 2021, the company announced that Tomáš Sušánka was taking over technical leadership at Trezor. Rusnák remained involved in group management. At the time of this review, the SatoshiLabs presskit lists him as co-founder and CTO, or chief technology officer, of SatoshiLabs. That is different from saying he still holds his former Trezor role. Trezor focuses on wallets and their software, while SatoshiLabs is the wider group that also includes other projects. [2] [3]
Rusnák’s contribution connects devices that protect keys during payments with public rules for recovering those keys. For Anna, that can mean avoiding dependence on one box or company, provided another wallet supports the necessary standards and settings. Self-custody means managing your own keys; it does not make the software’s author responsible for your backup. Before storing a larger amount, understand the backup format, safely check recovery and know what the passphrase does. A familiar developer’s name cannot replace those steps or a review of the particular product. [5] [7] [10]
For the clearest picture, read this entry together with Bitcoin, Trezor, Hardware Wallet, Self-custody, SatoshiLabs, Marek “Slush” Palatinus. The reverse links also lead from SatoshiLabs, Trezor, Marek “Slush” Palatinus, brmlab.