# Chapter 5 — What Is a Wallet and an Authenticator? Hot vs. Cold > Your assets and account exist on Vaulta. The Explorer and wallet interface can provide web-based tools to view and prepare actions, while a separate Authenticator protects your signing credentials and signs the requests you approve. Canonical: https://help.blockzhub.io/articles/chapter-5-what-is-a-wallet-and-an-authenticator-hot-vs-cold [In Chapter 4](https://help.blockzhub.io/articles/chapter-4-your-vaulta-account-identity-keys-and-permissions), you learned that your Vaulta account exists on the blockchain and that permissions such as owner and active determine what authority is required to act for that account. Now we need to clear up one of the most confusing terms in cryptocurrency: wallet. People often say: “My crypto is stored in my wallet.” That is a useful shortcut, but technically it creates the wrong mental model. Your Vaulta account, token balances, permissions, and transaction history exist on the Vaulta blockchain. A wallet or Authenticator does not contain the blockchain account itself. Instead, wallet and Authenticator software helps you protect credentials and create signatures that can satisfy the account's permissions. Key idea: Your assets and account exist on the blockchain. A wallet or Authenticator manages credentials that can authorize instructions for that account. ## What does each component actually do? Keep these roles separate: - Vaulta — the blockchain network and authoritative shared state. - Vaulta account — your named on-chain identity containing permissions, resources, activity, and relationships to token balances. - Private key — a secret cryptographic credential capable of creating signatures. - Public key — the non-secret counterpart that can appear in an account's on-chain authority. - Permission — the on-chain rule defining what authority is required. - Wallet — software or hardware that helps manage blockchain credentials, accounts, and signing. - Authenticator — a signing component focused on protecting credentials and approving authentication or transaction requests. - Explorer — an interface for reading blockchain information. - Blocksfinity Explorer — a non-custodial Explorer and wallet toolkit used to inspect and interact with Vaulta. - Smart contract — a program whose rules execute on-chain. - Transaction — a request to change blockchain state. The important distinction is between what exists on the blockchain and what exists on your device. VAULTA BLOCKCHAIN │ └── Your account ├── balances ├── resources ├── history └── permissions ├── owner └── active YOUR DEVICE / SIGNING TOOL │ └── credential │ └── creates signature │ ↓ Vaulta verifies whether the required permission is satisfiedClosing your wallet does not remove your account. Deleting an Explorer does not delete your tokens. Changing to another compatible wallet does not move the account to another blockchain. The tools change. The Vaulta account remains on Vaulta. ## What is the Blocksfinity Authenticator? Blocksfinity Authenticator is the signing component used with Blocksfinity Explorer. When you import a normal Vaulta private key into the Authenticator, that key is stored in an encrypted local vault protected by a master password on your device. The Authenticator can then identify which account permissions correspond to the key, receive signing requests, show you what you are approving, create signatures, and return those signatures for authentication or blockchain transactions. A simplified flow is: Blocksfinity Explorer │ │ "Please authorize this" ↓ Blocksfinity Authenticator │ │ You review the request │ │ Credential creates signature ↓ Signed request │ ↓ Vaulta blockchain processes itThe private key itself does not need to be sent to Vaulta. Blocksfinity also describes its products as non-custodial. Blocksfinity does not take custody of your tokens or collect your private keys, seed phrases, recovery phrases, or wallet passwords as a custodial service. The Authenticator instead protects imported private keys locally on your device. Important: Non-custodial does not mean risk-free, and it does not mean cold storage. You remain responsible for protecting your credentials and recovery paths. ## Hot wallets and cold wallets The difference between hot and cold is primarily about how the credential controlling an account is generated, stored, and used. It is not about where the tokens themselves are located. The tokens remain on the blockchain either way. ### Hot wallet A hot wallet keeps or uses signing credentials on an internet-connected device. Examples can include: - desktop wallet/authenticator software; - mobile wallet/authenticator software; - browser-based wallet/authenticator software; - an Authenticator containing an imported private key on your normal computer. Hot wallets are convenient because they can quickly sign normal transactions. But convenience creates a larger attack surface. An internet-connected computer can potentially be exposed to: - malware; - malicious browser extensions; - phishing; - clipboard manipulation; - compromised operating systems; - malicious software updates; - remote access attacks. That does not mean a hot wallet is automatically unsafe. It means its threat model is different. ### Cold wallet or cold storage Cold storage aims to keep the sensitive signing credential isolated from internet-connected systems. A stronger cold-storage design normally generates and keeps the private key offline or inside hardware designed to prevent the key from being exposed to the connected computer. The trade-off is straightforward: HOT More convenient More frequent use Internet-connected environment Larger remote attack surface COLD Less convenient Used rarely Credential created offline and kept offline or isolated Smaller remote attack surfaceFor high-value or recovery authority, accepting some inconvenience can be desirable. ## Hot and cold are properties of the credential setup There is an important technical correction to common wallet terminology. Your owner permission itself is not a cold wallet. Your active permission itself is not a hot wallet. Both permissions are on-chain rules. What can be hot or cold is the credential capable of satisfying that permission. For example: VAULTA ACCOUNT │ ├── owner permission │ │ │ └── Owner public key on-chain │ ↑ │ │ │ corresponding private key │ created offline │ kept offline / highly protected │ └── active permission │ ├── Active public key │ ↑ │ │ │ Private key in Authenticator │ used for daily activity │ └── Passkey public key ↑ │ Device/browser passkey used for daily activityThis is the security model we want to work toward: High authority → less exposure. Everyday authority → convenient but limited exposure. [Chapter 4](https://help.blockzhub.io/articles/chapter-4-your-vaulta-account-identity-keys-and-permissions) explained why owner should normally be used rarely. It can change lower permissions and can help recover control when an active credential is compromised. active, by contrast, is normally used for routine operations. Hot versus cold now gives us the practical security reason for that separation. ## Is Blocksfinity Authenticator app hot or cold? It depends on how and where the private key is used. If you import a private key into the Blocksfinity Authenticator app on a normal internet-connected computer or phone and keep it there for regular signing, you should treat that credential as hot. The Authenticator encrypts the private key locally and protects its vault with a master password. That is important protection, but the encrypted key still resides on a device that connects to the internet and can be unlocked there for signing. There is a different case. If the computer is deliberately kept offline, you import the private key only temporarily—for example, to create a key certificate—and then completely remove the private key from the Authenticator before that device reconnects to the internet, the key can remain part of an offline or cold-storage workflow and continue to be treated as cold. However, simply disconnecting a normal computer from the internet for a few minutes does not automatically make it secure cold storage. The device itself must also be trusted and free from malware or other compromise. A stronger institutional cold-storage setup therefore uses a dedicated offline or isolated environment that is not normally exposed to the internet. Private key kept in Authenticator on an internet-connected device ↓ HOT credential Private key used only on a trusted, offline or isolated device and removed before reconnecting ↓ OFFLINE / COLD workflowKey idea: The Authenticator app itself is not inherently “hot” or “cold.” The classification depends on the environment in which the private key is stored and used. Keeping a private key in Authenticator on an online device makes it hot; using it only within a properly isolated offline workflow can preserve cold-storage characteristics. Note: Calling Blocksfinity app non-custodial does not change that classification. Custody asks who controls the credential. Hot versus cold asks how exposed that credential is to an online environment. Those are different questions. ## What about the Blocksfinity Web Authenticator and passkeys? There is another way to prove that you are authorized to use a Vaulta account without importing a traditional private key into Blocksfinity Authenticator: a passkey. To understand passkeys, first we need to introduce WebAuthn. ### What is WebAuthn? WebAuthn, short for Web Authentication, is a web standard that allows websites to authenticate users using public-key cryptography instead of relying only on passwords. You may already have used this technology without knowing its technical name. For example, a website or application may let you sign in using: - a fingerprint; - Face ID or another form of biometric approval; - your computer's PIN; - a phone or other trusted device; - a hardware security key. Behind that familiar approval step can be a cryptographic credential. Instead of the website receiving a secret password that it must compare or store, the device can use a private cryptographic credential to prove that it possesses the correct authority. A simplified model looks like this: Website │ │ "Prove that you control this credential" ↓ Your device / authenticator │ │ You approve │ │ Private credential creates a signature ↓ Website verifies the signature using the corresponding public keyThe important part is that the private credential does not need to be sent to the website. Key idea: WebAuthn allows your device to prove possession of a cryptographic credential by signing a challenge instead of sending the private credential itself. ### What is a passkey? A passkey is a user-friendly way of using this type of public-key authentication. When a passkey is created, there are two cryptographic parts: Private credential │ │ stays protected by │ the authenticator/device ↓ Used to create signatures Public credential │ ↓ Can be registered with the service or accountThe private portion is normally managed by the authenticator environment rather than being shown to you as a long private-key string that you copy and paste. Depending on the device and passkey provider, the credential may be protected by: - device security; - a PIN; - fingerprint or facial recognition; - operating-system security; - secure hardware; - a hardware security key. This makes a passkey different from the traditional Vaulta private key you may manually back up or import into wallet software. However, the underlying idea should now look familiar: A private cryptographic credential creates a signature, and the corresponding public credential allows that signature to be verified. That is the same fundamental public/private-key concept you learned earlier, presented through a different authentication system. ## What is the Blocksfinity Web Authenticator? Blocksfinity can use WebAuthn credentials as another way to authorize account activity. Instead of importing a traditional Vaulta private key into the local Blocksfinity Authenticator app vault, you can use a WebAuthn passkey associated with a Vaulta account permission. At a high level: Vaulta account │ └── active permission │ └── WebAuthn public key ↑ │ corresponding passkey protected by your deviceWhen authorization is required, the process can look like this: Blocksfinity │ │ requests authorization ↓ Web Authenticator │ │ asks your device/passkey │ to approve the request ↓ You approve │ ↓ Passkey creates a signature │ ↓ Signature is verified against the authorized public credentialThe important security distinction is that Blocksfinity does not need to receive the private part of your passkey. Your device or authenticator uses the private credential to create the required cryptographic proof. ## Is the Web Authenticator a hot or cold wallet? For the security model used in this course, a passkey used through the Blocksfinity Web Authenticator should generally be considered a hot, day-to-day credential. Why? Because it is intended to authorize activity from an internet-connected browser or device. Passkey ↓ Protected by device/authenticator ↓ Used from internet-connected device ↓ Web Authenticator ↓ Routine account authorizationThat does not mean that a passkey has exactly the same security characteristics as importing a normal private key into software. There can be an important difference. With a traditional private key, you may have a secret string that can be: - displayed; - copied; - pasted; - backed up; - accidentally exposed; - stolen by software that obtains access to it. A WebAuthn credential may instead be designed so that its private component cannot simply be exported as a readable private-key string. The device or authenticator performs the signing operation on your behalf. That can substantially reduce certain risks involving copying, phishing, or accidental disclosure of raw private-key material. But on the other side it can increase the risk to lose access to the Vaulta account, when the browser data is deleted or the device is stolen. However, the credential is still being used through an internet-connected environment. For our hot-versus-cold mental model: Blocksfinity Authenticator + imported private key ↓ HOT / day-to-day credential Web Authenticator + device/passkey ↓ HOT / day-to-day credential Separately protected owner/recovery credential ↓ COLD / Prefer offline stored or strongly isolatedKey idea: “Hot” does not mean “bad.” It means the credential is available for use from an online environment. Different hot credentials can still have very different security properties. ## Why might a passkey be useful for active? Remember the purpose of Vaulta's permissions. The owner permission represents the account's highest standard authority and should normally be used rarely. The active permission is intended for more frequent account activity. That creates a useful security architecture: OWNER Highest authority ↓ Separate recovery credential ↓ Keep highly protected and use rarely ACTIVE Day-to-day authority ↓ Passkey and/or everyday signing credential ↓ Convenient regular useA passkey can therefore be useful as a credential associated with active. It provides convenient signing without requiring you to expose your highest-authority recovery credential whenever you want to use your account. The important principle is not that one particular technology is always safe. It is separation of authority: Do not expose your highest-value recovery credential every time you perform an ordinary account action. ## If I never import my owner private key, is it cold? Not automatically. This distinction is extremely important. Suppose you create a Vaulta account in an internet-connected browser. The private key is generated and displayed there. You copy it to an encrypted USB drive, remove your other copies, and never import it into Blocksfinity Authenticator. You have significantly reduced its future exposure. That is good security practice. But the key was still created or displayed inside an internet-connected computing environment. Strictly speaking, you therefore cannot claim that the private key has never been exposed to an online system. The current Blocksfinity paid account-creation flow, for example, generates and displays the account private key during the browser-based creation process and recommends securely retaining an offline backup. For this course, it is therefore more precise to call such a key: an offline owner/recovery key rather than automatically calling it a true cold-wallet key. A stricter cold-storage design would generate and retain the key in an offline environment or within dedicated hardware where the private key is designed not to leave the isolated signing environment or was never exposed online. Key idea: Moving a key offline reduces future exposure. It does not prove that the key was never exposed while it was generated, displayed, copied, or previously used. ## One more important trap: the same key on owner and active There is another reason to inspect your Vaulta permissions instead of relying on labels. Suppose the same public key appears under both: owner └── Public Key A active └── Public Key AThere is only one corresponding Private Key A. If you import Private Key A into a hot Authenticator for normal active transactions, that same private key can also satisfy the owner authority if the on-chain configuration gives it that authority. In that situation, saying: “My owner key is cold because I have an offline backup” would be incorrect. You have an offline backup of the key, but the same key is also present in a hot environment. Real separation requires different credentials: owner └── Owner Public Key A ↑ Owner Private Key A kept separately / rarely used active └── Active Public Key B ↑ Active Private Key B used in AuthenticatorA passkey can then be added as an addtional active credential where appropriate. This is why you should always inspect the actual keys and permissions recorded on-chain rather than assuming that an owner label automatically means cold storage. ## The security model to remember For everyday use, think in layers: OWNER AUTHORITY Highest standard authority ↓ Separate recovery credential ↓ Keep offline or strongly isolated where practical ↓ Use rarely ACTIVE AUTHORITY Normal day-to-day authority ↓ Blocksfinity Authenticator private key and/or WebAuthn passkey ↓ Convenient online interactionThis does not make the active layer harmless. A compromised active credential may still authorize transfers, staking, voting, and smart-contract interactions depending on the account's permission configuration. The purpose of the architecture is to avoid exposing your highest recovery authority every time you perform a normal action. ## Before you import a private key Later, in the step-by-step missions, you may import a Vaulta private key into Blocksfinity Authenticator. Before doing that, you should be able to answer four questions: - Which Vaulta permission does this private key control? - Does the same public key appear under both owner and active? - Am I comfortable turning this credential into a hot credential? - Do I still have an independent recovery path if this device is compromised or lost? If you cannot answer those questions, inspect your account's permissions first. Important: Importing a private key is not moving your Vaulta account into the Authenticator. You are giving an internet-connected signing tool access to a credential capable of satisfying whichever account permissions reference its public key. That is what is actually happening. ## What you should remember - Your Vaulta account and assets exist on the blockchain, not inside a wallet. - Wallets provide functions and features for the accounts. - Authenticators manage credentials and create signatures. - Blocksfinity Explorer and Authenticator are non-custodial; that does not automatically make a signing method a cold wallet. - A hot credential is available through an internet-connected signing environment. - Cold storage aims to keep high-value credentials offline or isolated from the beginning (creation of the keypair). - owner and active permissions themselves are neither hot nor cold. - The credential controlling owner should normally receive stronger protection than everyday credentials. - Blocksfinity Authenticator with an imported private key should be treated as hot. - A browser/device WebAuthn passkey should be treated as a convenient hot active credential for this course, even though its private component can be non-exportable and device-protected. - Never importing an owner key into Authenticator reduces exposure but does not by itself prove that the key was generated and kept entirely cold. - If the same private key controls both owner and active, importing it into a hot wallet exposes authority over both permissions. ## Quick Quiz ### 1. Where are the tokens associated with your Vaulta account actually recorded? - A. Inside Blocksfinity Authenticator - B. Inside your browser - C. On the Vaulta blockchain through on-chain state maintained by the relevant contracts - D. Inside whichever wallet you last used ### 2. Why should a private key imported into Blocksfinity Authenticator on your normal computer be treated as hot? - A. Because Blocksfinity takes custody of the key - B. Because the credential is stored and used in an internet-connected signing environment - C. Because every encrypted private key is public - D. Because Vaulta automatically changes the owner permission ### 3. Which description best fits the browser/device passkey used by the Blocksfinity Web Authenticator? - A. It is automatically the account's cold recovery key. - B. Its private component must be uploaded to Blocksfinity before every transaction. - C. It is a convenient day-to-day credential whose private component can remain protected by the device or authenticator. - D. It stores the Vaulta account itself inside the browser. ### 4. You create a private key in an internet-connected browser, save it to an offline encrypted drive, remove your online copy, and never import it into a wallet. Which statement is most accurate? - A. The key was unquestionably generated in true cold storage. - B. The key is useless because it is offline. - C. Its future exposure has been reduced, but the key was still created or displayed in an online environment. - D. Vaulta automatically removes the corresponding public key from the account. ### 5. The same Public Key A controls both your owner and active permissions. You import the corresponding Private Key A into a hot Authenticator. What does this mean? - A. Only the active authority is exposed because the Authenticator automatically ignores owner. - B. The same credential can potentially satisfy both permissions, so the highest authority is no longer isolated from the hot credential. - C. The blockchain creates a second private key automatically. - D. The offline backup of Private Key A makes the imported copy cold. Answer footnote: Q1:3; Q2:2; Q3:3; Q4:3; Q5:2.