# Chapter 4 — Your Vaulta Account: Identity, Keys and Permissions > Where your account lives, who can control it, and how cryptography proves authority. Canonical: https://help.blockzhub.io/articles/chapter-4-your-vaulta-account-identity-keys-and-permissions In the [previous chapters](https://help.blockzhub.io/categories/blocksfinity-onboarding), you learned what a blockchain is, what Vaulta is, and what you can do with a Vaulta account. Now we need to answer a more important question: What actually gives someone the authority to act for that account? A Vaulta account does not use a traditional username and password. Instead, Vaulta combines permissions, public/private keypairs, and cryptographic signatures to decide whether an action has been properly authorized. By the end of this chapter, you should understand where your account exists, what public and private keys do, how signatures prove authority, why Vaulta has owner and active permissions, and how the owner permission can help recover control if an active key is compromised. ## Your account exists on Vaulta [Chapter 2](https://help.blockzhub.io/articles/chapter-2-what-is-vaulta) introduced an important fact: Your Vaulta account exists directly on the Vaulta blockchain. It does not live inside a Blockchain Explorer, inside a Blockchain Authenticator or Wallet, or inside your computer. If your account were named: myvaultacct that account would continue to exist on Vaulta even if you: - closed your browser; - changed computers; - stopped using the blockchain explorer, authenticator, wallet or an application using the blockchain. - removed the blockchain explorer, authenticator, wallet or an application using the blockchain. Applications can display the account and help you interact with it, but they are not the account itself. This leads to an important distinction: Key idea: An account and the credentials used to control that account are two different things. Knowing the account name also does not give somebody control over it. Anyone may be able to inspect public blockchain information associated with an account. That raises the real question: How does Vaulta know whether someone is actually authorized to act for an account? The answer starts with permissions. ## Permissions define authority Every Vaulta account has an on-chain permission system. A permission describes what authority must be satisfied before certain actions can be performed for the account. [1] Every normal Vaulta account begins with two important permissions: Vaulta account │ ├── owner │ └── activeThese permissions form a hierarchy. owner is the highest standard authority. active sits below owner and is normally used for everyday account operations. We will examine both shortly. First, we need to understand how cryptography can prove that the required authority has approved something. ## Public and private keys One common way a Vaulta permission can be controlled is through a cryptographic keypair. A keypair consists of two mathematically related keys: PRIVATE KEY ←→ PUBLIC KEYThey have very different jobs. ### The private key The private key is the secret part. It can be used to create cryptographic signatures. If a private key gives authority over one of your account permissions, anyone who obtains that private key may be able to authorize actions using that permission. That is why it must remain secret. Important: Never share a private key with another person, paste it into an unknown website, send it through email or messaging, or include it in a blockchain transaction. A private key is not simply a password that a company can reset for you. It is a cryptographic credential. ### The public key The public key is the non-secret part of the pair which can be shared with anyone. A Vaulta permission can reference a public key as part of its authority rules. The public key allows the network to verify signatures created by the corresponding private key. Unlike the private key, the public key can appear publicly on the blockchain. You can think of the relationship like this: Private key │ │ creates ↓ Signature Public key │ │ verifies ↓ SignatureThe public key can be derived from the private key. This means software holding a private key can determine which public key — and therefore which account permissions — it corresponds to. The reverse is not practically feasible: knowing a public key does not allow someone to calculate the corresponding private key. The two keys work together, but they perform different jobs. Key idea: The private key creates signatures. The public key allows those signatures to be verified. ## What is a signature? Suppose your account wants to authorize a transaction. Vaulta does not need you to send your private key to the blockchain. That would destroy the entire security model. Instead, software on your side can use the private key to create a digital signature over the transaction data. The process looks roughly like this: Transaction ↓ Private key signs ↓ Digital signature ↓ Transaction + signature ↓ Vaulta verifies the signature using the corresponding public keyThe private key itself does not need to be transmitted with the transaction. Vaulta can mathematically verify that the signature has been produced by someone controlling the corresponding private key. This answers an important question: How can Vaulta verify authority without knowing your private key or storing your password? Through cryptographic signatures. But there is another important step. A valid signature by itself does not automatically mean that every possible action is authorized. Vaulta must also determine: Does this signature satisfy the permission required for this action? That is where keys and permissions connect. ## Keys and permissions are not the same thing For a simple beginner account configuration, imagine this: Vaulta account │ ├── owner permission │ │ │ └── Owner public key │ └── active permission │ └── Active public keySomewhere outside the blockchain, the corresponding private keys are protected: Owner private key ↑ corresponds to ↓ Owner public key on permission Active private key ↑ corresponds to ↓ Active public key on permissionThis distinction matters. The permission is the on-chain authority rule. The keypair is one way of satisfying that authority. Vaulta permissions can actually become more sophisticated than one permission connected to one key. They can support multiple keys, other account permissions, thresholds, and custom permission structures. You do not need those advanced configurations yet. For now, remember: A key is not an account, and a key is not a permission. A key can be one credential used to satisfy a permission on an account. ## The active permission: everyday authority For normal day-to-day activity, Vaulta accounts commonly use the active permission. In a simple configuration, the active permission is controlled by an active keypair. The active private key may therefore be used when authorizing ordinary operations such as: - transferring tokens; - voting; - interacting with smart contracts; - staking or resource-related actions; - performing other normal account operations. Vaulta's underlying permission system uses active as the default permission for ordinary actions unless a more specific permission has been configured. A simplified flow looks like this: You want to send a transaction ↓ Transaction requires active authority ↓ Active private key creates signature ↓ Vaulta verifies the signature against the active authority ↓ Required authority is satisfied ↓ Transaction can be processedThere are still other checks. For example, a properly authorized transfer can fail if the account does not have enough tokens or if another blockchain rule is not satisfied. A signature proves authorization. It does not guarantee successful execution. ## The owner permission: highest authority The owner permission sits at the top of the account's standard permission hierarchy. It has more authority than active. Most importantly, owner can be used to change permissions below it, including the authority controlling active. That makes owner extremely powerful. It also explains why the owner credential should normally not be used for everyday transactions. Think of the separation this way: OWNER Highest authority ↓ Account recovery and permission management ↓ Protect very carefully ACTIVE Day-to-day authority ↓ Transfers, voting, contract actions, etc. ↓ Used more frequentlyKey idea: Use lower authority for ordinary activity and keep higher authority protected for situations where it is genuinely needed. In a straightforward setup, this means using a separate active keypair for normal transactions while keeping the owner keypair much more securely protected. ## What if the active private key is compromised? This separation becomes extremely valuable when something goes wrong. Imagine that your account has two separate keypairs: owner permission └── Owner Public Key A ↕ Owner Private Key A active permission └── Active Public Key B ↕ Active Private Key BNow suppose Active Private Key B is stolen. That is serious. An attacker possessing that key may be able to authorize normal active operations. But if your separately protected owner authority remains secure, you still have a recovery path. You can: - Generate a completely new active keypair using a trusted, secure wallet or authenticator. New Active Private Key C ↕ New Active Public Key C- Use your protected owner authority to authorize a permission change. - Replace the compromised Active Public Key B with the new Active Public Key C. The resulting account configuration becomes: owner permission └── Owner Public Key A active permission └── New Active Public Key CThe compromised key is no longer part of the active authority. Future signatures made only with the old Active Private Key B will therefore no longer satisfy that updated active permission. This is one of the most important reasons for keeping the owner and active authorities separate. Important: The owner permission does not create the new keypair. The new keypair is generated securely first. The owner authority is then used to change the account's on-chain active permission so that the new public key replaces the compromised one. Vaulta's permission hierarchy is specifically designed so the higher owner authority can recover control when a lower permission is compromised. ## Why shouldn't you simply use the owner key every day? You technically have very powerful authority with owner. That is exactly why exposing it unnecessarily is not advisable or can even be dangerous. Suppose two keys are used differently: Owner private key Used rarely Strongly protected ↓ Smaller exposure Active private key Used for normal activity ↓ More frequent exposureIf the active credential is compromised while the owner credential remains secure, the owner authority can be used to replace the active authority. But if the highest-level owner authority itself is compromised, the situation is much more serious because that authority can change the account's permission structure. This is a common security principle: Do not routinely expose more authority than you need. The active and owner structure gives Vaulta accounts a way to apply that principle directly on-chain. ## Your Wallet/Authenticator is not your account The next chapter will explain wallets and Authenticators in more detail. For now, one distinction is essential. An Authenticator or wallet can protect and use credentials such as private keys. The Vaulta account and its permissions remain on the blockchain. A simplified model is: YOUR DEVICE │ └── Private key │ │ creates signature ↓ VAULTA BLOCKCHAIN │ └── Account │ ├── owner permission └── active permission │ └── authority includes public keyThe wallet or authenticator application helps you use a credential in a secure way without having to expose the private key in plain text each time you want to sign a transaction. The wallet/authenticator does not become the blockchain account. This also means that the same public account information can be viewed through different blockchain explorers, because they are all reading data from the same Vaulta blockchain. Likewise, a private key is not tied to a specific wallet application. The same private key can be imported into multiple compatible wallets or authenticators, each of which can use it to sign transactions for the account permissions associated with its public key. Important: Importing the same private key into multiple applications or devices increases the number of places where that key could potentially be compromised. ## Put the whole model together You now have all the pieces. VAULTA ACCOUNT │ ├── owner permission │ └── highest standard authority │ └── active permission └── normal day-to-day authority │ ↓ Public key ↑ verifies signature ↑ Private key │ ↓ signs transactionWhen you authorize a normal transaction, the mental model is: 1. An action needs authority ↓ 2. A permission defines the required authority ↓ 3. A private key creates a signature ↓ 4. Vaulta verifies that signature ↓ 5. Vaulta checks whether the permission is satisfied ↓ 6. If the transaction is valid, it can executeNo website needs to know your private key. No company password needs to be stored on Vaulta. And your account is not trapped inside one application. The authority comes from the rules recorded on-chain and the cryptographic credentials capable of satisfying those rules. ## What you should remember - Your Vaulta account exists on the Vaulta blockchain, not inside an Authenticator or website. - Looking at an account is different from having authority to act for it. - Vaulta accounts use permissions to define what authority is required. - Every standard account has owner and active permissions. - The active permission is normally used for day-to-day transactions and account operations. - The owner permission is the highest standard authority and should be protected carefully. - A private key creates digital signatures and must remain secret. - A public key can be used by Vaulta to verify signatures from the corresponding private key. - A keypair and an account are different things. - A valid signature must still satisfy the permission required by the action. - If a separate active key is compromised while the owner authority remains secure, a new active keypair can be generated and the owner authority can be used to replace the compromised active keypair. - Using separate owner and active credentials reduces the need to expose your highest authority during everyday activity. ## Quick Quiz ### 1. Where does your Vaulta account exist? - A. Inside the Blocksfinity Authenticator - B. Inside the computer where your private key is stored - C. On the Vaulta blockchain - D. Inside whichever blockchain explorer you currently use ### 2. What is the main purpose of a private key? - A. To publicly identify your account - B. To create cryptographic signatures that can authorize actions - C. To store your Vaulta account on your computer - D. To display transactions in an explorer ### 3. Which statement correctly describes the relationship between a permission and a key? - A. A permission and a private key are exactly the same thing. - B. Every Vaulta account can only ever have one private key. - C. A permission defines authority requirements, and a key can be one credential used to satisfy those requirements. - D. Anyone who knows an account name automatically satisfies its permissions. ### 4. Why is the active permission normally preferred for ordinary transactions instead of owner? - A. owner cannot authorize blockchain transactions. - B. active is designed for normal operations, allowing the more powerful owner authority to remain better protected. - C. owner disappears after the account is created. - D. active transactions do not require cryptographic signatures. ### 5. Your active private key has been compromised, but your separately protected owner authority is still secure. What is the correct recovery concept? - A. Delete the Vaulta account and create another account with the same name. - B. Ask the blockchain explorer to reverse every transaction made with the old key. - C. Generate a new active keypair and use owner authority to replace the compromised active public key with the new public key. - D. Publish the owner private key so the network knows you are the legitimate account holder. Answer footnote: Q1:3; Q2:2; Q3:3; Q4:2; Q5:3. ## Editorial references - [Vaulta Guides — Account Permissions](https://vaulta.gitbook.io/vaulta-guides/accounts/vaulta-native-accounts/account-permissions). Current Vaulta documentation describing owner, active, hierarchical permissions, daily operations and recovery authority.