From 40d7625748d2d390ca9ce33b66e1abb4e9c6ae3b Mon Sep 17 00:00:00 2001 From: Tina Thomsen Date: Thu, 17 Jul 2025 14:39:40 +0200 Subject: [PATCH 1/5] updated glossary --- source/mainnet/docs/resources/glossary.rst | 298 ++++++++++----------- 1 file changed, 146 insertions(+), 152 deletions(-) diff --git a/source/mainnet/docs/resources/glossary.rst b/source/mainnet/docs/resources/glossary.rst index f872d9c58e..387f0ac616 100644 --- a/source/mainnet/docs/resources/glossary.rst +++ b/source/mainnet/docs/resources/glossary.rst @@ -15,14 +15,21 @@ Also see the Concordium `Whitepaper `, in cooperation with the account's :term:`identity provider`. + Account address + + Characters associated with an account that stores funds to access the account and perform transactions. + Account credential A certificate derived from the :term:`identity object` that proves that the owner has been verified by an identity provider. The key feature of the credential is that it **does not** identify the owner to the identity provider, nor to any other single entity, however it contains enough information to allow disclosing an identity in concert with the identity provider to find the owner. + Account private key + + Per account private key - 64 characters long hexadecimal string. Account weight - The Account weight of an account corresponds to the weight this account has for voting. In the 2025 election, this is computed as the average amount of CCD on the account between the 26th of February and the 25th of May 2025. + The account weight of an account in an election is computed as the average amount of CCD on the account during the designated calculation period. Accumulated weight @@ -36,29 +43,21 @@ Also see the Concordium `Whitepaper `. + Archive - Baker pool + Action of hiding a verifiable credential from a wallet. - This term is no longer used. See :term:`staking pool`. - - Best block + Attributes - This term is no longer used. See :term:`Concordium Byzantine Fault Tolerance (BFT) protocol`. + User data, such as date of birth or country of residence, that is associated with a user :term:`identity`. Users can choose which attributes should be revealed in each of their accounts. - Best chain + Backup file - This term is no longer used. See :term:`Concordium Byzantine Fault Tolerance (BFT) protocol`. + A secure, portable data file containing wallet information, keys, and/or credentials that can be exported from a wallet application and later imported to restore access to blockchain assets. Backup files provide one method for disaster recovery and wallet migration. Block - The basic unit of the blockchain, which is produced by a :term:`validator`. A block contains a (possibly empty) list of :term:`transactions`, and has a pointer to a previous block (with the exception of the :term:`genesis block`). A block and its predecessors form a chain, and the sequence of transactions they contain form a ledger. Each block has a :term:`slot time` that records when it was produced. A block also contains information relating to consensus, for instance establishing which validator created the block, and that the validator was entitled to do so. + The basic unit of the blockchain, which is produced by a :term:`validator`. A block contains a (possibly empty) list of :term:`transactions`, and has a pointer to a previous block (with the exception of the :term:`genesis block`). A block and its predecessors form a chain, and the sequence of transactions they contain form a ledger. Each block records when it was produced. A block also contains information relating to consensus, for instance establishing which validator created the block, and that the validator was entitled to do so. Block reward commission @@ -83,11 +82,11 @@ Also see the Concordium `Whitepaper ` cannot be reused (e.g., if they are stolen), the verifier can and should specify a challenge string. This can be an arbitrary byte array which is used by the prover (wallet) when producing the proof. The proof will only validate with respect to the challenge that was used to produce it. The verifier server can thus use the challenge to make sure the proofs it is receiving are not reused, and to handle their lifetime (e.g., it can set the challenge it supplied to expire in 5 minutes). + Combined decryption share + + The combination of all decryption shares, allows to fully decrypt a tallied result. + Concordium client - A command-line tool that ships with the Concordium distribution. It is designed as a low-level interface to the Concordium blockchain. It cannot be used to create identities, but it can :ref:`import accounts` exported from the mobile wallets. Once an account has been imported, Concordium client can be used to do CCD transfers from the account and other :ref:`transaction` types supported by the Concordium blockchain. + The Concordium command line tool. It is designed as a low-level interface to the Concordium blockchain. It cannot be used to create identities, but it can :ref:`import accounts` exported from the |bw|. Once an account has been imported, Concordium client can be used to do CCD transfers from the account and other :ref:`transaction` types supported by the Concordium blockchain. + + + Concordium Byzantine Fault Tolerance (BFT) protocol + + The consensus protocol for the blockchain. The protocol offers high transaction throughput and lower confirmation time because a block can be produced as soon as the previous block has been signed. The protocol proceeds by rounds. In each round, a predetermined leader among the validators should produce a block. The other validators then sign this block, and their collective signatures are aggregated to form a quorum certificate (QC). This quorum certificate is then included in the next block. If the leader fails to produce a block in the round, or not enough signatures were gathered for a QC, then the validators will instead send timeout messages, which are aggregated to form a timeout certificate (TC). Each block always contains a quorum certificate and may contain a timeout certificate for the previous round if and only if the previous round timed out. When blocks on a common chain in two consecutive rounds have quorum certificates, the block in the first of these rounds (together with its ancestors) is considered final. At this point, the protocol ensures that it cannot be rolled back. The two consecutive blocks must also be within the same epoch. Consensus The process by which nodes agree which :term:`transactions` have occurred and in what order. This consists of :term:`validation`. - Cool-down period + Contract address - A period of time during which the funds are frozen and cannot be spent. + Address of the smart contract; made up of contract index and subindex. + Contract index - Concordium Byzantine Fault Tolerance (BFT) protocol + Used when adding and managing tokens in the wallet. - The consensus protocol for the blockchain. The protocol offers high transaction throughput and lower confirmation time because a block can be produced as soon as the previous block has been signed. The protocol proceeds by rounds. In each round, a predetermined leader among the validators should produce a block. The other validators then sign this block, and their collective signatures are aggregated to form a quorum certificate (QC). This quorum certificate is then included in the next block. If the leader fails to produce a block in the round, or not enough signatures were gathered for a QC, then the validators will instead send timeout messages, which are aggregated to form a timeout certificate (TC). Each block always contains a quorum certificate and may contain a timeout certificate for the previous round if and only if the previous round timed out. When blocks on a common chain in two consecutive rounds have quorum certificates, the block in the first of these rounds (together with its ancestors) is considered final. At this point, the protocol ensures that it cannot be rolled back. The two consecutive blocks must also be within the same epoch. + Contract initialization - Credential + The act of initializing a smart contract on the chain. - See :term:`account credential`. + Contract subindex - Credential holder + Not used in any user facing context. Always 0. - The user holding a credential. An account is owned by one or more credential holders. + Cool-down period - Credential registry contract + A period of time during which a transaction is frozen. Examples of when cool-down periods apply include removing a validator and updating stake. The length of a cool-down period varies between transactions. + + Credential holder - A smart contract used by :term:`issuers` of :term:`verifiable credentials` to register credentials when they are issued. This contract will also be used to track the state of a credential, e.g., valid, revoked, expired. + User holding one or more credentials. The role usually involves the ability to generate presentations from the credentials or zero-knowledge proofs about their attributes. - Cryptographic proof + Credential registry contract - A method by which one party (the prover) can prove to another party (the verifier) that a given statement is true while the prover avoids conveying any additional information apart from the fact that the statement is indeed true. This is known as a :term:`zero-knowledge proof`. + A contract used by issuers of verifiable credentials to register credentials when they are issued. This contract will also be used to track the state of a credential. dApp connectivity - The abiity of a wallet to interact with decentralized applications, dApps, on the blockchain. This allows users to access various services and platforms built on blockchain technology, such as DeFi, NFTs, and gaming. + The ability of a wallet to interact with decentralized applications, dApps, on the blockchain. This allows users to access various services and platforms built on blockchain technology, such as DeFi, NFTs, and gaming. - Decryption key + Decryption proof - Dual to :term:`encryption key`. In contrast to the encryption key, which is public, this key is only known to the account holder. + A proof that a decrypted plain text is correct with respect to a given joint election public key. Decryption share - A guardian's partial share of a ballot decryption or tally decryption for an election. + A partial decryption by a single guardian that will contribute to the full decryption. Delegated weight Sum of account weights that delegated to an account. Delegated weight is made up of the account weight of each account that delegated a vote to the account that cast a ballot. - Delegator + Delegation - An account that contributes stake to a staking pool, or to passive delegation. When an account becomes a delegator, the delegated amount of CCD is locked so that it cannot be spent or transferred while it is delegated. Delegators earn rewards, minus a commission to the validator, in proportion to their delegated stake. + The act of contributing part of one's stake to a staking pool or to passive delegation. - For delegation in an election, see :term:`Vote delegation`. + Delegator - Delegation + An account that contributes to a staking pool, or to passive delegation. When an account becomes a delegator, the delegated amount of CCD is locked so that it cannot be spent or transferred while it is delegated. Delegators earn rewards, minus a commission to the validator, in proportion to their delegated stake. - The process of contributing CCD stake to a validator's staking pool or to passive delegation without running a node. When delegating, the CCD amount becomes locked and cannot be spent or transferred until undelegated.Delegation allows CCD holders to earn rewards proportional to their stake, minus any applicable commission paid to validators. + For delegation in an election, see :term:`Vote delegation`. Deploy Command that takes the built :term:`Wasm` file for a smart contract module and deploys it on chain. This command is run from :term:`Concordium client`. + Earn + + To receive rewards on one's stake. + Election manifest - The manifest is the information that uniquely specifies and describes the structure and type of the election, including geopolitical units, contests, candidates, ballot styles, etc. In the Guardian app, it is a file that is created before running an election. The internal manifest is a wrapper around the manifest used in programming code to simplify and avoid processing the same information twice. Unlike the manifest, the internal manifest is not meant for serialization. + The manifest is the information that uniquely specifies and describes the structure and type of the election, including geopolitical units, contests, candidates, ballot styles, etc. In In ElectionGuard, it is a file that is created before running an election. The internal manifest is a wrapper around the manifest used in programming code to simplify and avoid processing the same information twice. Unlike the manifest, the internal manifest is not meant for serialization. Election phase @@ -200,11 +215,7 @@ Also see the Concordium `Whitepaper ` (:ref:`deprecated`) on the account. - - Endpoint - - A point at which an API -- the code that allows two software programs to communicate with each other -- connects with the software program. APIs work by sending requests for information from a web application or web server and receiving a response. + An `ElGamal`_ public key associated to an account. Entrypoint @@ -234,17 +245,45 @@ Also see the Concordium `Whitepaper ` in concert with the identity provider. + An initial account is an account submitted to the chain by the identity provider during the process of requesting a new identity. The initial account can perform all of the same actions as a regular account, however the real-life identity of the initial-account owner is known by the identity provider who submitted it to the chain. In contrast, the real-life identity of the owner of a regular account can only be ascertained by the :term:`Privacy Guardians` in concert with the identity provider. Initial accounts are only relevant for Desktop Wallet. @@ -276,7 +315,7 @@ Also see the Concordium `Whitepaper ` affects the lottery power of the validator by increasing their stake, thus increasing the odds of that validator being chosen to produce a block. + A validator's lottery power is its relative stake and is therefore proportional to the staked amount of that validator. The lottery power is updated each :term:`pay day`, and is based on the stake distribution at the end of the epoch before last. (This delay ensures that the stake distribution is determined before the randomness that fixes the validators for the epoch; otherwise, stakeholders might redistribute their stake to luckier validators, which undermines the security of the system.) :term:`Delegation` affects the lottery power of the validator by increasing their stake, thus increasing the odds of that validator being chosen to produce a block. Mainnet The main Concordium network which launched in June 2021. The mainnet will receive periodic upgrades, but in contrast to the :term:`testnet`, it will never be reset, and accounts created on the mainnet will remain indefinitely. + Member/Comitte member/Governance committee member + + Individual elected to the Concordium governance committee. + Membership proof A proof to determine if an attribute of a user's identity is included in a given set, for example, lives in the EU. Can also be a :term:`non-membership proof`. Node - A participant in the Concordium network. Nodes receive blocks and transactions, and track the current state of the blockchain. A :term:`validator node` has cryptographic keys that enable it to take part in validation. A node without these keys is referred to as a *passive node*. + A participant in the Concordium network. Nodes receive blocks and transactions, and track the current state of the blockchain. A validator node has cryptographic keys that enable it to take part in validation. A node without these keys is referred to as a *passive node*. Nominee Someone who has volunteered to be a candidate in an election. + Non-membership proof + + A proof to determine that an attribute of a user's identity is **not** included in a set, for example, that they are **not** a resident of a country under trade sanctions. + Nonce May refer to: @@ -322,10 +369,6 @@ Also see the Concordium `Whitepaper ` that is used to seed the :term:`leader election` process. - :term:`Transaction sequence number` (same as account sequence number) - Non-membership proof - - A proof to determine that an attribute of a user's identity is **not** included in a set, for example, that they are **not** a resident of a country under trade sanctions. - Off-chain Refers to activities outside of the Concordium blockchain. Some on-chain actions need preliminary actions off-chain, for example to create an account on the Concordium blockchain the user must first work with an identity provider, e.g., via their website or mobile application, to obtain a specific digital certificate. Concordium refers to this certificate as the **identity**. @@ -334,22 +377,35 @@ Also see the Concordium `Whitepaper `): - - An amount of :term:`CCD` that is encrypted with the public key of an account. Only the owner of the secret key can determine how many CCDs are contained in the encryption. - - Shielded balance - - (:ref:`deprecated`): - - The part of the balance of an :term:`account` that only the owner of the account can see. This is achieved by encrypting transfers to an account with the account's :term:`encryption key`. Every participant of the Concordium network can see the `ciphertexts`_ of all the transfers, however they provide no information on how many CCDs were transferred. The receiver of the transfer can use their secret key to decrypt the ciphertexts, and seeing how many CCDs they have received. - - For technical reasons the shielded balance of the account consists of two parts, the "self balance" and the "incoming shielded amounts". - - - Self balance: This is a single shielded amount that is updated each time the account performs a shielded transfer, :term:`shielding`, or :term:`unshielding`. Only the account itself can update this value. - - - Incoming shielded amount: This is a list of shielded amounts that is extended each time an account receives an shielded transfer. When the account makes a shielded transfer it can use a number of shielded amounts from this list as inputs to the transfer. - - Shielded transfer - - (:ref:`deprecated`): - - Transfer from :term:`shielded balance` of an account to a shielded balance of another account. The amount that is transferred is only visible to the sender and the receiver. - - Shielding - - (:ref:`Deprecated`): - - The action of transferring a part of the public balance to the :term:`shielded balance`. + Mnemonic word list preceding the Seed. A seed phrase consists of 24 words. Sigma protocols A class of efficient interactive :term:`zero-knowledge proof` systems that follow a three-round structure; commitment, challenge, and response. Sigma protocols enable a prover to demonstrate knowledge of secret information without revealing it. They can also be used for OR and AND statements, and can be made non-interactive with the Fiat-Shamir transform. - Slot - - See :term:`round`. - Smart contract A computer program or a transaction protocol that is intended to automatically execute, control or document events and actions according to the terms of a contract or an agreement. An example is a smart contract for selling NFTs on a marketplace; it may contain information about royalties, selling the NFT on to others, and so on. - Staked Amount - - :term:`Validators` can have part of the balance of their account staked. The amount that is staked remains locked while staked and cannot be transferred or moved in any way. The staked amount is proportional to the :term:`lottery power` of a validator. - - :term:`Delegators` can delegate stake to a staking pool or passive delegation. This affects the staked amount of the validator and thus their lottery power. - Staking pool A validator and delegators that collectively pool their stake to participate in the consensus protocol and earn rewards. The validator runs a validator node on behalf of the staking pool to produce blocks using the collective stake of the pool to determine its lottery power. Rewards are accrued to the pool each time the validator produces a block. Each pay day, the accrued rewards are distributed to the pool's participants in proportion to their relative stakes in the pool, with the validator (the pool owner) receiving an additional commission from the delegators' rewards. @@ -464,7 +472,7 @@ Also see the Concordium `Whitepaper `): - - The action of transferring a part of the :term:`shielded balance` to the public balance. - User identity certificate - Issued to the individual or entity once their real-world identity has been verified and recorded by an Identity Provider. You cannot use the Concordium Platform without a User Identity Certificate. - The user identity certificate includes attributes such as name, age, and nationality. When the Identity Provider has validated the attributes, it issues a user identity certificate, which is basically the Identity Provider’s signature over some cryptographic keys of the user and the validated personal attributes. Unlike usual public key certificates such as X.509 certificates, the user identity certificate is private to the user; it is not submitted to the chain. Note that the Identity Provider also stores some information, but this is only used for a possible, subsequent investigation of the user’s activities (i.e. disclosing an identity). The Identity Provider is not involved in any subsequent use of the user identity certificate. The user identity certificate is signed using the Pointcheval-Sanders signature scheme. + Issued to the individual or entity once their real-world identity has been verified and recorded by an identity provider. You cannot use the Concordium platform without a user identity certificate. + The user identity certificate includes attributes such as name, age, and nationality. When the identity provider has validated the attributes, it issues a user identity certificate, which is basically the identity provider’s signature over some cryptographic keys of the user and the validated personal attributes. Unlike usual public key certificates such as X.509 certificates, the user identity certificate is private to the user; it is not submitted to the chain. Note that the identity provider also stores some information, but this is only used for a possible, subsequent investigation of the user’s activities (i.e. disclosing an identity). The identity provider is not involved in any subsequent use of the user identity certificate. The user identity certificate is signed using the Pointcheval-Sanders signature scheme. Validation - The process of production of :term:`blocks` done by validators. Validation makes the block part of the authoritative :term:`chain`. Transactions that are part of validated blocks are considered authoritative. Validation is conducted by the validators with a staked amount of at least 0.1% of the :term:`total effective stake` in staking pools. Total effective stake in staking pools does not include passive delegation and any amount that exceeds the :ref:`staking pool bounding caps`. + The process of production of :term:`blocks`. Validator @@ -529,44 +531,36 @@ Also see the Concordium `Whitepaper `. The issuer can choose to have the verifiable credential expire, or revoke it, if necessary. The issuer manages the verifiable credentials with a smart contract, a credential registry contract. + Verifiable credentials are Web3 credentials. They have attributes that don’t have to have stringent requirements on anonymity revocation, but can also witness a number of other attributes of the holder. Examples of this would be club membership credentials, reward programs, etc. There are no requirements imposed on who can be an issuer of these credentials, and in contrast to protocol level identities, the Web3 ID credentials can be revoked according to the logic imposed by the issuer. This could be that the credential holder can revoke it, the credential expires, or the issuer or some other third party has rights to revoke it. Verifiable credentials are not associated with accounts. Verifiable credentials can be used to build verifiable presentations, which can also be cryptographically verified. Verifiable presentation - Data derived from one or more verifiable credentials and/or account credentials, issued by one or more issuers or identity providers, that is shared with a specific verifier. A verifiable presentation is tamper-evident and encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. It contains a link that points to the contract and holder ID. A presentation that contains a **zero-knowledge proof** might contain data that confirms the truth of a statement from verifiable credentials or account credentials, but the presentation does not reveal the actual attributes of verifiable credentials. + Data derived from one or more verifiable credentials, issued by one or more issuers, that is shared with a specific verifier. A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that is synthesized from, but do not contain, the original verifiable credentials (for example, zero-knowledge proofs). Verifier - Party that checks users' :term:`verifiable credentials`. + Party that verifies users' Web3 ID credentials. Vote delegation - Method whereby a user can add account weight of their account to another account that will cast the ballot. This is used by users of Desktop Wallet to cast ballots in the 2025 election. - - For delegation related to earning rewards on an account, see :term:`delegator`. - - Wallet + Method whereby a user can add account weight of their account to another account that will cast the ballot. This allows accounts accessed from wallets without smart contract capabilities to cast votes by delegating to another account held by the same owner. - A wallet is an app that allows cryptocurrency users to store and retrieve their digital assets, and manage identities and accounts. Concordium has three wallet types. + W3C standard - - The Desktop Wallet: a digital wallet that enables you to create and manage your Concordium identities, credentials, and accounts from your desktop and to create transactions such as sending CCD, adding a validator, and exporting and importing account information. + Standards and guidelines developed by the World Wide Web Consortium (W3C), an international organization that creates technical specifications to ensure the long-term growth and interoperability of the web. - - |cryptox|: a digital smartphone wallet that enables you to create and manage your Concordium identities and accounts, to create simple transactions, be a validator and delegate, and to export and import your accounts and identities. + Wallet - - The |bw|: a web browser extension wallet that enables you to create and manage your Concordium identities and accounts, to create simple transactions, and to connect to dApps. + A wallet is an app that allows cryptocurrency users to store and retrieve their digital assets, and manage identities and accounts. Web3 ID - Web3 ID is an extension of the core protocol identity with other types of credentials that don’t have stringent requirements and won't be part of the identity disclosure process, but can also witness a number of other attributes of the holder. Examples of this would be club membership credentials, reward programs, etc. There are no requirements imposed on who can be an issuer of these credentials, and in contrast to protocol identities, the Web3 ID credentials can be revoked according to the logic imposed by the issuer. This could be that the credential holder can revoke it, the credential expires, or the issuer or some other third party has rights to revoke it. + Web3 ID is an extension of the core protocol identity with other types of credentials that don’t have to have stringent requirements on anonymity revocation, but can also witness a number of other attributes of the holder. Examples of this would be club membership credentials, reward programs, etc. There are no requirements imposed on who can be an issuer of these credentials and in contrast to protocol identities the Web3 ID credentials can be revoked according to the logic imposed by the issuer. This could be that the credential holder can revoke it, the credential expires, the issuer, or some other third party has rights to revoke it. WebAssembly WebAssembly (Wasm) defines a portable binary-code format and a corresponding text format for executable programs as well as software interfaces for facilitating interactions between such programs and their host environment. Smart contracts are deployed on chain as Wasm files. - W3C standard - - Standards and guidelines developed by the World Wide Web Consortium (W3C), an international organization that creates technical specifications to ensure the long-term growth and interoperability of the web. - Winning probability The winning probability is the probability that a validator wins in a given round. The probability is :math:`\alpha`, which equals the validator's relative stake. From 82c33523256756458f491ac7f00e25a1b1aa8c7d Mon Sep 17 00:00:00 2001 From: Tina Thomsen Date: Thu, 17 Jul 2025 15:03:54 +0200 Subject: [PATCH 2/5] removed all references to old term secret recovery phrase and replaced with seed phrase in browser wallet faq page --- .../browser-wallet/browser-wallet-faq.rst | 48 +++++++++---------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/source/mainnet/docs/browser-wallet/browser-wallet-faq.rst b/source/mainnet/docs/browser-wallet/browser-wallet-faq.rst index 9b17184bd0..6a046478b2 100644 --- a/source/mainnet/docs/browser-wallet/browser-wallet-faq.rst +++ b/source/mainnet/docs/browser-wallet/browser-wallet-faq.rst @@ -7,36 +7,36 @@ .. dropdown:: Why was the |bw| made? - The |bw| was created as a tool for developers to connect `dApps `__ to the Concordium blockchain and interact with it, and for users who are using dApps. It provides a simplified interface for users and introduces a :term:`secret recovery phrase`, which simplifies any restoration of an account should you lose access to the phone/app. Also, this version supports easy portability of accounts between this and the |mw-gen2|. + The |bw| was created as a tool for developers to connect `dApps `__ to the Concordium blockchain and interact with it, and for users who are using dApps. It provides a simplified interface for users and introduces a seed phrase, which simplifies any restoration of an account should you lose access to the phone/app. Also, this version supports easy portability of accounts between this and the |mw-gen2|. .. dropdown:: What are the features and benefits of the |bw|? - Some of the functionality is the same as other Concordium wallets in that you can still send and receive funds. But the |bw| uses a :term:`secret recovery phrase` that allows you to recover your wallet should you need to replace your device. That same secret recovery phrase will also allow you to recover the wallet on, for example, |mw-gen2|. + Some of the functionality is the same as other Concordium wallets in that you can still send and receive funds. But the |bw| uses a seed phrase that allows you to recover your wallet should you need to replace your device. That same seed phrase phrase will also allow you to recover the wallet on, for example, |mw-gen2|. In |bw| initial accounts are no longer created by the :term:`identity provider` when your identity is verified, ensuring complete privacy of all your accounts. Going forward you :ref:`create all accounts yourself` in your Concordium Wallet. -.. dropdown:: What is a secret recovery phrase? +.. dropdown:: What is a seed phrase? - A :term:`secret recovery phrase` is a “master key” that unlocks all of your Concordium accounts. When entered into the wallet in the correct order, the 24 words in the recovery phrase will recover all of the private keys you were storing on your original wallet and give access to all :term:`CCDs` in the wallet. This means that even if you lose your physical hardware device, you’ll still have access to your blockchain assets. Secret recovery phrases are sometimes referred to as seed phrases, mnemonic phrases, mnemonic seeds and backup phrases. + A seed phrase is a “master key” that unlocks all of your Concordium accounts. When entered into the wallet in the correct order, the 24 words in the recovery phrase will recover all of the private keys you were storing on your original wallet and give access to all :term:`CCDs` in the wallet. This means that even if you lose your physical hardware device, you’ll still have access to your blockchain assets. Secret recovery phrases are sometimes referred to as seed phrases, mnemonic phrases, mnemonic seeds and backup phrases. -.. dropdown:: How is a secret recovery phrase different from private keys? +.. dropdown:: How is a seed phrase different from private keys? :term:`Private keys` allow you to send, spend, and delegate your CCDs. - Your :term:`secret recovery phrase` gives you access to your wallet and all of the private keys in the wallet. You can think of a wallet as being like a password manager for your accounts. As long as you have your master password (the secret recovery phrase), you have access to all CCDs in the wallet. + Your seed phrase gives you access to your wallet and all of the private keys in the wallet. You can think of a wallet as being like a password manager for your accounts. As long as you have your master password (the seed phrase), you have access to all CCDs in the wallet. -.. dropdown:: What happens if I lose my secret recovery phrase? +.. dropdown:: What happens if I lose my seed phrase? - If you accidentally throw away the paper your secret recovery phrase is written on, forget where you hid it, or do not pass it on to an heir, you no longer have the ability to recover your wallet and can lose access to your CCDs. If someone steals your secret recovery phrase, they can access your CCDs. **If you lose your secret recovery phrase you lose access to your CCDs.** + If you accidentally throw away the paper your seed phrase is written on, forget where you hid it, or do not pass it on to an heir, you no longer have the ability to recover your wallet and can lose access to your CCDs. If someone steals your seed phrase, they can access your CCDs. **If you lose your seed phrase you lose access to your CCDs.** - As long as you have your secret recovery phrase, you have your CCDs. If you break a device containing your wallet, you haven’t lost your CCDs. You can simply :ref:`enter your secret recovery phrase` into a newly downloaded |cryptox| or |bw|. + As long as you have your seed phrase, you have your CCDs. If you break a device containing your wallet, you haven’t lost your CCDs. You can simply :ref:`enter your seed phrase` into a newly downloaded |cryptox| or |bw|. -.. dropdown:: How can I keep my secret recovery phrase secure? +.. dropdown:: How can I keep my seed phrase secure? - - Don't take a picture of it; if you save photos to any cloud provider this could potentially expose your :term:`secret recovery phrase` so anyone could access your accounts and funds. + - Don't take a picture of it; if you save photos to any cloud provider this could potentially expose your seed phrase so anyone could access your accounts and funds. - Don't keep it with your device. If you lose your device, anyone who finds it could access your accounts and funds. - - Put it in a safe location. Keep your secret recovery phrase in a safe location that is fireproof and waterproof, and that you will remember and can access relatively easily. There are companies that make devices, such as https://shop.ledger.com/products/the-billfodl that can safely store your secret recovery phrase. - - Keep multiple physical copies of your secret recovery phrase in safe locations. + - Put it in a safe location. Keep your seed phrase in a safe location that is fireproof and waterproof, and that you will remember and can access relatively easily. There are companies that make devices, such as https://shop.ledger.com/products/the-billfodl that can safely store your seed phrase. + - Keep multiple physical copies of your seed phrase in safe locations. .. dropdown:: Can I use the |bw| extension in a web browser on a mobile phone or tablet device? @@ -44,33 +44,33 @@ .. dropdown:: Do I still need to make backups of my wallet? - No. For the |bw| and |mw-gen2| you do not need to make backups. Your :term:`secret recovery phrase` that you write down is the only way to recover your accounts and identities. + No. For the |bw| and |mw-gen2| you do not need to make backups. Your seed phrase that you write down is the only way to recover your accounts and identities. .. dropdown:: Can I migrate from the |mw-gen1| or Desktop Wallet to the |bw|? No. Because the way that keys are protected differs between the old and new wallets you cannot simply migrate. If you use the |mw-gen1| or Desktop Wallet but want to use the |bw|, you should do the following: - #. Download the |bw| and set it up so you have a :term:`secret recovery phrase`, a verified identity, and at least one account. + #. Download the |bw| and set it up so you have a seed phrase, a verified identity, and at least one account. #. Open the |mw-gen1| and send your funds from it to your new account(s) in the |bw|. #. Once you are sure that all of your funds have been transferred and you have no incoming transfers, you can delete the |mw-gen1| on your phone. -.. dropdown:: Can I access my wallet on multiple devices with the secret recovery phrase? +.. dropdown:: Can I access my wallet on multiple devices with the seed phrase? Yes, you can access your wallet concurrently using |cryptox| and |bw|. You can :ref:`recover` your wallet in a device that uses either of these. Be aware that any names you have given to identities and accounts are **specific to the device**, so if you have used special names for them, they will not appear when you recover the wallet on another device. You can edit the account name and edit the identity name, if desired. - It is also important to note that if, for example, you add an account on one wallet that is recovered on two devices in parallel (from the same recovery phrase), nothing is dynamically updated across wallets from the same recovery phrase except balances. To get updates such as a new account or new identity, it is necessary to :ref:`recover` from your recovery phrase again; however you do not need to enter the recovery phrase again as the wallet will remember it. + It is also important to note that if, for example, you add an account on one wallet that is recovered on two devices in parallel (from the same seed phrase), nothing is dynamically updated across wallets from the same seed phrase except balances. To get updates such as a new account or new identity, it is necessary to :ref:`recover` from your recovery phrase again; however you do not need to enter the seed phrase again as the wallet will remember it. -.. dropdown:: Can I use my secret recovery phrase to restore my accounts in third-party wallets? +.. dropdown:: Can I use my seed phrase to restore my accounts in third-party wallets? At the moment Concordium identities and accounts are only supported in Concordium Wallets. However, Concordium expects to provide support for CCD and CIS-2 tokens in third party wallets in the future. -.. dropdown:: I have a secret recovery phrase from another wallet. Can I use that in my Concordium Wallet? +.. dropdown:: I have a seed phrase from another wallet. Can I use that in my Concordium Wallet? - Reusing a :term:`secret recovery phrase` in multiple wallets is not recommended, as it increases the risk of having all your wallets compromised. Concordium recommends that you generate a new secret recovery phrase when setting up a new wallet on Concordium. For advanced users who understand the risks involved it is possible to reuse a 24 word recovery phase from another wallet with Concordium through the wallet recovery process. The wallet will not recover anything if you reuse your secret recovery phrase from another wallet, but it will set your wallet up with the secret recovery phrase, and from there you can request a new identity and accounts. + Reusing a seed phrase in multiple wallets is not recommended, as it increases the risk of having all your wallets compromised. Concordium recommends that you generate a new seed phrase when setting up a new wallet on Concordium. For advanced users who understand the risks involved it is possible to reuse a 24 word recovery phase from another wallet with Concordium through the wallet recovery process. The wallet will not recover anything if you reuse your seed phrase from another wallet, but it will set your wallet up with the seed phrase, and from there you can request a new identity and accounts. -.. dropdown:: I have a Concordium Desktop Wallet set up with a LEDGER device and a 24 word secret recovery phrase. Can I use that recovery phrase in my |bw|? +.. dropdown:: I have a Concordium Desktop Wallet set up with a LEDGER device and a 24 word seed phrase. Can I use that recovery phrase in my |bw|? - Identities and accounts from the Concordium Desktop Wallet cannot be recovered in the |bw|. It is also not recommended to use secret recovery phrases from cold wallets in “hot wallets” like the |bw|, as that defeats the purpose of having the :term:`secret recovery phrase` in a cold wallet, like the LEDGER devices. + Identities and accounts from the Concordium Desktop Wallet cannot be recovered in the |bw|. It is also not recommended to use seed phrases from cold wallets in “hot wallets” like the |bw|, as that defeats the purpose of having the seed phrase in a cold wallet, like the LEDGER devices. .. dropdown:: Can I migrate from another wallet to the |bw|? @@ -80,8 +80,8 @@ .. dropdown:: Can I access the same accounts on different devices? - If you are using |bw| and |cryptox|, you can because the |cryptox| also uses the :term:`secret recovery phrase`. You simply enter your :ref:`recovery phrase` into the wallet to see the same identities and accounts on both. Note that the account and identity names are specific to the device and are not the same between devices. + If you are using |bw| and |cryptox|, you can because the |cryptox| also uses the seed phrase. You simply enter your :ref:`seed phrase` into the wallet to see the same identities and accounts on both. Note that the account and identity names are specific to the device and are not the same between devices. .. dropdown:: What do I do if I forget my passcode on the |bw|? - If you forget your passcode for your installed |bw|, you will need to :ref:`remove the extension in your internet browswer and reinstall it`, choosing the option to :ref:`recover` your wallet. Use your :term:`secret recovery phrase` to recover the wallet. + If you forget your passcode for your installed |bw|, you will need to :ref:`remove the extension in your internet browswer and reinstall it`, choosing the option to :ref:`recover` your wallet. Use your seed phrase to recover the wallet. From ab7bcf8735651727a3b629c142a09109c216a468 Mon Sep 17 00:00:00 2001 From: Tina Thomsen Date: Thu, 17 Jul 2025 15:38:37 +0200 Subject: [PATCH 3/5] deleted references to terms deleted in glossary in various files --- .../docs/browser-wallet/browser-wallet-faq.rst | 2 +- .../docs/browser-wallet/setup-browser-wallet.rst | 10 +++++----- .../desktop-wallet/create-credentials-file.rst | 2 +- source/mainnet/docs/guides/cryptox-faq.rst | 2 +- .../docs/guides/overview-shared-accounts.rst | 2 +- .../mainnet/docs/guides/shield-ccd-wallets.rst | 4 ++-- .../docs/network/guides/stop-validator.rst | 2 +- source/mainnet/docs/protocol/concepts-baker.rst | 4 ++-- .../docs/protocol/concepts-delegation.rst | 2 +- .../docs/protocol/concordium-protocol.rst | 2 +- source/mainnet/docs/protocol/manage-accounts.rst | 6 +++--- source/mainnet/docs/protocol/transactions.rst | 2 +- source/mainnet/docs/voting/gc-voting.rst | 2 +- source/mainnet/docs/voting/guardians.rst | 2 +- source/mainnet/tools/query-node.rst | 16 ++++++++-------- source/mainnet/tools/transactions.rst | 2 +- 16 files changed, 31 insertions(+), 31 deletions(-) diff --git a/source/mainnet/docs/browser-wallet/browser-wallet-faq.rst b/source/mainnet/docs/browser-wallet/browser-wallet-faq.rst index 6a046478b2..8bfc60b7d1 100644 --- a/source/mainnet/docs/browser-wallet/browser-wallet-faq.rst +++ b/source/mainnet/docs/browser-wallet/browser-wallet-faq.rst @@ -21,7 +21,7 @@ .. dropdown:: How is a seed phrase different from private keys? - :term:`Private keys` allow you to send, spend, and delegate your CCDs. + Private keys allow you to send, spend, and delegate your CCDs. Your seed phrase gives you access to your wallet and all of the private keys in the wallet. You can think of a wallet as being like a password manager for your accounts. As long as you have your master password (the seed phrase), you have access to all CCDs in the wallet. diff --git a/source/mainnet/docs/browser-wallet/setup-browser-wallet.rst b/source/mainnet/docs/browser-wallet/setup-browser-wallet.rst index b6505d77b2..3ef683a63b 100644 --- a/source/mainnet/docs/browser-wallet/setup-browser-wallet.rst +++ b/source/mainnet/docs/browser-wallet/setup-browser-wallet.rst @@ -144,15 +144,15 @@ Get started Recovery phrase setup ===================== -If you are creating a new wallet, you must set up a :term:`secret recovery phrase`. This is a 24 word phrase that stores your private keys, identities, and accounts. You must write down and confirm your recovery phrase. It is important to keep this secret recovery phrase in a safe location in case you need to recover your wallet on a new device. +If you are creating a new wallet, you must set up a seed phrase. This is a 24 word phrase that stores your private keys, identities, and accounts. You must write down and confirm your seed phrase. It is important to keep this seed phrase in a safe location in case you need to recover your wallet on a new device. -#. When you click **Create**, the 24 word secret recovery phrase is shown. Write it down and click **Continue**. +#. When you click **Create**, the 24 word seed phrase is shown. Write it down and click **Continue**. .. image:: ../images/browser-wallet/new/recovery.png :alt: screen with recovery phrase and continue option :width: 50% -#. Enter all 24 words of your secret recovery phrase to confirm it. Click **Continue**. +#. Enter all 24 words of your seed phrase to confirm it. Click **Continue**. #. Choose whether to connect to Mainnet or Testnet to create your wallet. @@ -307,7 +307,7 @@ Removing your wallet does not remove your data on the Concordium blockchain. .. Warning:: - Before proceeding, if you wish to continue to access your wallet and accounts, make sure you have your secret recovery phrase. + Before proceeding, if you wish to continue to access your wallet and accounts, make sure you have your seed phrase. .. dropdown:: Chrome @@ -341,7 +341,7 @@ Removing your wallet does not remove your data on the Concordium blockchain. .. Note:: - If you forget your passcode for your installed |bw|, you will need to remove the extension in your internet browswer and reinstall it, choosing the option to :ref:`recover your wallet`. Use your secret recovery phrase to recover the wallet. + If you forget your passcode for your installed |bw|, you will need to remove the extension in your internet browswer and reinstall it, choosing the option to :ref:`recover your wallet`. Use your seed phrase to recover the wallet. .. |chrome-ext| image:: ../images/browser-wallet/chrome-extensions-icon.png :width: 20px diff --git a/source/mainnet/docs/desktop-wallet/create-credentials-file.rst b/source/mainnet/docs/desktop-wallet/create-credentials-file.rst index 5b376e8c51..f81c40c4f2 100644 --- a/source/mainnet/docs/desktop-wallet/create-credentials-file.rst +++ b/source/mainnet/docs/desktop-wallet/create-credentials-file.rst @@ -5,7 +5,7 @@ Create a credentials file ========================= -This topic describes how you create and export a file with :term:`credentials`. For information about adding more credentials to an account, see :ref:`Add credentials to an account `. +This topic describes how you create and export a file with credentials. For information about adding more credentials to an account, see :ref:`Add credentials to an account `. Create and export a file with credentials ========================================= diff --git a/source/mainnet/docs/guides/cryptox-faq.rst b/source/mainnet/docs/guides/cryptox-faq.rst index a152936c3e..e0763d4feb 100644 --- a/source/mainnet/docs/guides/cryptox-faq.rst +++ b/source/mainnet/docs/guides/cryptox-faq.rst @@ -20,7 +20,7 @@ .. dropdown:: How is a seed phrase different from private keys? - :term:`Private keys` allow you to send, spend, and delegate your CCDs. + Private keys allow you to send, spend, and delegate your CCDs. Your :term:`seed phrase` gives you access to your wallet and all of the private keys in the wallet. You can think of a wallet as being like a password manager for your accounts. As long as you have your master password (the seed phrase), you have access to all funds in the wallet. diff --git a/source/mainnet/docs/guides/overview-shared-accounts.rst b/source/mainnet/docs/guides/overview-shared-accounts.rst index 53b8a668df..abb455bdeb 100644 --- a/source/mainnet/docs/guides/overview-shared-accounts.rst +++ b/source/mainnet/docs/guides/overview-shared-accounts.rst @@ -10,7 +10,7 @@ In the Desktop Wallet, you have the option of creating shared accounts, also kno Credentials =========== -It’s the :term:`credentials` on an account that determine who’s allowed to sign transactions. An account credential holds signature verification keys, information related to the :term:`Privacy Guardians`, and the public :term:`attributes` of the account owner. The credential proves that the account owner has been verified by an :term:`identity provider`, but it doesn’t identify the account owner to the identity provider. However, in the case of a valid request from a government authority via established legal channels, it allows the Privacy Guardians and the identity provider, when they work together, to link the account to the users. For more information, see :ref:`Identity framework on Concordium `. +It’s the credentials on an account that determine who’s allowed to sign transactions. An account credential holds signature verification keys, information related to the :term:`Privacy Guardians`, and the public :term:`attributes` of the account owner. The credential proves that the account owner has been verified by an :term:`identity provider`, but it doesn’t identify the account owner to the identity provider. However, in the case of a valid request from a government authority via established legal channels, it allows the Privacy Guardians and the identity provider, when they work together, to link the account to the users. For more information, see :ref:`Identity framework on Concordium `. Signature threshold =================== diff --git a/source/mainnet/docs/guides/shield-ccd-wallets.rst b/source/mainnet/docs/guides/shield-ccd-wallets.rst index ff5c7beabf..bd6ff61b4e 100644 --- a/source/mainnet/docs/guides/shield-ccd-wallets.rst +++ b/source/mainnet/docs/guides/shield-ccd-wallets.rst @@ -17,8 +17,8 @@ Unshield CCD on an account The next few paragraphs contain some old context regarding the old shielding feature before protocol 7. -Accounts on the Concordium blockchain had two balances, the **Balance** and the :term:`shielded balance`. You were able to move funds between these -two balances using either a :term:`shield CCD transaction` or an :term:`unshield CCD transaction`. +Accounts on the Concordium blockchain had two balances, the **Balance** and the shielded balance. You were able to move funds between these +two balances using either a shield CCD transaction or an unshield CCD transaction`. When you shield an amount on an account, only the account's credential holder can see the shielded amounts. Other participants in the network will be able to see the shielding transaction, but can't see the shielded balance or any shielded transfers going in or out of the account. You weren't able to make shielded transfers on multi-signature accounts, only on accounts with a single credential. diff --git a/source/mainnet/docs/network/guides/stop-validator.rst b/source/mainnet/docs/network/guides/stop-validator.rst index 81cdc0616b..ca49079f4e 100644 --- a/source/mainnet/docs/network/guides/stop-validator.rst +++ b/source/mainnet/docs/network/guides/stop-validator.rst @@ -5,7 +5,7 @@ Stop a validator ================ -If you remove a validator, the node that is configured with the :term:`validator keys` will stop producing blocks after the next :term:`pay day`. +If you remove a validator, the node that is configured with the validator keys will stop producing blocks after the next :term:`pay day`. After the :term:`cool-down period`, the amount that you previously staked is returned to your disposable balance at the next pay day. diff --git a/source/mainnet/docs/protocol/concepts-baker.rst b/source/mainnet/docs/protocol/concepts-baker.rst index 0891f6b7dc..d489915345 100644 --- a/source/mainnet/docs/protocol/concepts-baker.rst +++ b/source/mainnet/docs/protocol/concepts-baker.rst @@ -12,7 +12,7 @@ Validation is key to the Concordium blockchain. A :term:`node` is a validator no Stake and lottery ================= -A validator needs to :term:`stake` a part of its CCD balance on the validator account (at least 500,000 CCD), which is then locked. At any point, the validator can manually release a part of the staked amount, as long as the minimum 500,000 CCD remain staked, or close down the validator and release everything. Unstaked CCD goes through a :term:`cool-down`, during which it does not earn rewards. Once the cool-down is over, the CCD is unlocked and available in the wallet to be moved or transferred. +A validator needs to stake a part of its CCD balance on the validator account (at least 500,000 CCD), which is then locked. At any point, the validator can manually release a part of the staked amount, as long as the minimum 500,000 CCD remain staked, or close down the validator and release everything. Unstaked CCD goes through a :term:`cool-down`, during which it does not earn rewards. Once the cool-down is over, the CCD is unlocked and available in the wallet to be moved or transferred. .. note:: @@ -72,7 +72,7 @@ For example, if you decrease a valiator's stake, the stake will be decreased at Validator keys ============== -A node uses a set of :term:`cryptographic keys` called validator keys to sign the blocks that it produces. The validator keys are uniquely determined from the associated account. The validator keys are used for signing the block that the node produces and for verifying whether the validator has won the :term:`lottery ` as described below. To become a validator node, the node must be configured with a set of validator keys. You generate the validator keys in the wallet when you add validation to an account. The validator node will start validation after the next :term:`pay day` once the transaction has been approved. +A node uses a set of cryptographic keys called validator keys to sign the blocks that it produces. The validator keys are uniquely determined from the associated account. The validator keys are used for signing the block that the node produces and for verifying whether the validator has won the :term:`lottery ` as described below. To become a validator node, the node must be configured with a set of validator keys. You generate the validator keys in the wallet when you add validation to an account. The validator node will start validation after the next :term:`pay day` once the transaction has been approved. Validator account ----------------- diff --git a/source/mainnet/docs/protocol/concepts-delegation.rst b/source/mainnet/docs/protocol/concepts-delegation.rst index 97ea512b2d..1b2e72ac20 100644 --- a/source/mainnet/docs/protocol/concepts-delegation.rst +++ b/source/mainnet/docs/protocol/concepts-delegation.rst @@ -5,7 +5,7 @@ Delegation ========== -On the Concordium blockchain, :term:`validators` run the protocol that generates blocks, and the action of creating and verifying blocks is an important part of what validators do. Validators are rewarded for every block that they create with a payment of some :term:`CCD`. Because Concordium runs a proof-of-stake protocol, each validator needs to :term:`stake an amount to produce blocks`, and the :term:`probability of being selected to create the next block` is proportional to each validator's stake. So the payment may be seen as an interest on the validator's capital. +On the Concordium blockchain, :term:`validators` run the protocol that generates blocks, and the action of creating and verifying blocks is an important part of what validators do. Validators are rewarded for every block that they create with a payment of some :term:`CCD`. Because Concordium runs a proof-of-stake protocol, each validator needs to stake an amount to produce blocks, and the :term:`probability of being selected to create the next block` is proportional to each validator's stake. So the payment may be seen as an interest on the validator's capital. Not everyone with CCD has the resources needed to run a validator. :term:`Delegation` enables everyone to earn rewards for delegating some stake without the need to run a node or become a validator. Any party with CCD may delegate some of their capital to a validator. This increases the validator's chance of producing the next block and getting rewards, which are then shared with the delegators. This is a non-custodial solution: when a party delegates an amount of CCD to a validator, the CCDs are not transferred to the validator and remain under the party's control; they are just considered part of the validator's stake for the proof-of-stake protocol. Staked CCDs, both for delegators and validators, cannot be spent while staked. Unstaking CCDs is subject to a :term:`cool-down period`. diff --git a/source/mainnet/docs/protocol/concordium-protocol.rst b/source/mainnet/docs/protocol/concordium-protocol.rst index 1624f1d095..f5cf906f9c 100644 --- a/source/mainnet/docs/protocol/concordium-protocol.rst +++ b/source/mainnet/docs/protocol/concordium-protocol.rst @@ -52,7 +52,7 @@ Economics and validation The protocol uses :term:`CCD` (ConCorDium) as its native token. CCD serves multiple purposes: - Paying for transaction fees -- :term:`Staking` by :term:`validators` +- Staking by :term:`validators` - Rewards for network participation Validators must stake CCD to participate in block production. Other CCD holders can delegate their tokens to validators to earn rewards without running a node themselves. The maximum size of a validator's staking pool is capped at 5% of the total stake to maintain decentralization. diff --git a/source/mainnet/docs/protocol/manage-accounts.rst b/source/mainnet/docs/protocol/manage-accounts.rst index b02dbb44ed..fe1901f921 100644 --- a/source/mainnet/docs/protocol/manage-accounts.rst +++ b/source/mainnet/docs/protocol/manage-accounts.rst @@ -17,7 +17,7 @@ An account on the Concordium blockchain is owned by one or more :term:`credentia The on-chain part of the account consists of: -- the :term:`credentials` of the credential holders associated with the account +- the credentials of the credential holders associated with the account - public balance - account sequence number - public keys of each credential to verify transaction signatures. @@ -67,7 +67,7 @@ Once you have an identity and a user identity certificate from an identity provi .. Note:: |cryptoX| does not submit the transaction directly to a node, but via a proxy. |cryptox| does not need to be connected to a node. -The input to the transaction is a *credential*, which contains a number of :term:`cryptographic proofs`. The proofs reveal no information about the owner of the account. In particular, the identity provider itself cannot determine the owner of the account. +The input to the transaction is a *credential*, which contains a number of cryptographic proofs. The proofs reveal no information about the owner of the account. In particular, the identity provider itself cannot determine the owner of the account. .. image:: ../protocol/images/account-creation.png :alt: graphic drawing showing how user creates accounts @@ -104,7 +104,7 @@ producing blocks, and transfers. At any given time some of the public balance might be unavailable for use. This can happen in two ways: -- the account has :term:`staked` some of the public +- the account has staked some of the public balance in order to become a validator or to delegate - some of the public balance is locked up because it was received via a :term:`transfer with schedule` diff --git a/source/mainnet/docs/protocol/transactions.rst b/source/mainnet/docs/protocol/transactions.rst index 124acf4861..e08fa7c18e 100644 --- a/source/mainnet/docs/protocol/transactions.rst +++ b/source/mainnet/docs/protocol/transactions.rst @@ -6,7 +6,7 @@ Transactions ============ -A transaction on the Concordium blockchain is an operation which applies some change to the chain. All transactions are recorded on the chain and once recorded, they are immutable. A transaction always has one sender :term:`account` and is signed using the :term:`keys` of this account. +A transaction on the Concordium blockchain is an operation which applies some change to the chain. All transactions are recorded on the chain and once recorded, they are immutable. A transaction always has one sender :term:`account` and is signed using the keys of this account. The most basic transaction is the CCD transfer that is used to send CCD from one account to another. However, there are several transaction types on the Concordium blockchain. diff --git a/source/mainnet/docs/voting/gc-voting.rst b/source/mainnet/docs/voting/gc-voting.rst index cae893e62b..d5dabb1ab8 100644 --- a/source/mainnet/docs/voting/gc-voting.rst +++ b/source/mainnet/docs/voting/gc-voting.rst @@ -24,7 +24,7 @@ The diagrams and descriptions below describe the process during each phase of th Before the election =================== -The period of time before the election is the :term:`setup phase`. Several roles are involved in the setup of the election. +The period of time before the election is the setup phase. Several roles are involved in the setup of the election. .. image:: ../images/voting/pre-election.png :alt: diagram showing steps below diff --git a/source/mainnet/docs/voting/guardians.rst b/source/mainnet/docs/voting/guardians.rst index b68e0cd890..aa587c5d9f 100644 --- a/source/mainnet/docs/voting/guardians.rst +++ b/source/mainnet/docs/voting/guardians.rst @@ -5,7 +5,7 @@ Guardians ========= -The :term:`guardian` participates (via the guardian application) in all three phases of the election: the :term:`setup phase` before the election, the :term:`election phase` during which they may cast votes, and the :term:`tally phase` at the end of the election. +The :term:`guardian` participates (via the guardian application) in all three phases of the election: the setup phase before the election, the :term:`election phase` during which they may cast votes, and the :term:`tally phase` at the end of the election. In the setup phase, a distributed encryption key is generated. This ensures the secrecy of ballots. A number of guardians, as defined by the election parameters in the smart contract, register their public keys in the smart contract to say that they will :term:`tally` election votes. After the election closes, the guardians :term:`decrypt their share of the votes` and send the decrypted tally back to the smart contract. In this way, no one party tallies the votes for the election, ensuring privacy of the votes. Correctness of the result follows from the zero-knowledge proofs generated by the guardians and voters to prove that they performed their parts correctly. diff --git a/source/mainnet/tools/query-node.rst b/source/mainnet/tools/query-node.rst index 27d6c2a677..b6d69320f9 100644 --- a/source/mainnet/tools/query-node.rst +++ b/source/mainnet/tools/query-node.rst @@ -34,7 +34,7 @@ List accounts List the addresses of all accounts on the chain as of a specific block: -- ``BLOCK-HASH``: Full hash of the block. Defaults to the current :term:`best block`. +- ``BLOCK-HASH``: Full hash of the block. Defaults to the current best block. Example ~~~~~~~ @@ -60,8 +60,8 @@ can also decrypt the shielded balance (:ref:`deprecated`). +- ``BLOCK``: Full hash of target block. Defaults to the current best block`. +- ``--shielded``: Show the shielded balance (:ref:`deprecated`). - ``--reveal-shielded``: Show the shielded balance and reveal it (:ref:`deprecated`). @@ -92,8 +92,8 @@ The output shows that the account with the local name ``my-account`` - has a balance of 1026 CCD, - has :term:`transaction sequence number` ``1``, - has ``a820662531d...`` as the key for receiving shielded transfers (:ref:`deprecated`). -- has no :term:`incoming shielded amount` (:ref:`deprecated`). -- has a :term:`self balance` of ``a9d35bf62442aabad72c...`` (:ref:`deprecated`). By default this +- has no incoming shielded amount (:ref:`deprecated`). +- has a self balance of ``a9d35bf62442aabad72c...`` (:ref:`deprecated`). By default this only shows the first 20 characters of the encrypted amount. With a ``--verbose`` flag the full encryption is shown. @@ -149,7 +149,7 @@ Display information about a specific block. Note that some fields (e.g. slot time) are objective (i.e. all nodes participating in the Concordium network will agree on these) while others (e.g. arrival time) are specific to the local node: -- ``BLOCK-HASH``: Full hash of the block. Defaults to the current :term:`best block`. +- ``BLOCK-HASH``: Full hash of the block. Defaults to the current best block. Example ~~~~~~~ @@ -190,7 +190,7 @@ Inspect consensus parameters Show :term:`election parameters` for a specific block, optionally including bakers and their :term:`lottery power`: -- ``BLOCK-HASH``: Full hash of the block. Defaults to the current :term:`best block`. +- ``BLOCK-HASH``: Full hash of the block. Defaults to the current best block. - ``--include-bakers``: If set, include table of bakers and their lottery power. The lottery power is recomputed periodically, so operations that affect them do not take effect immediately. @@ -274,7 +274,7 @@ ID layer $concordium-client identity show (identity-providers|anonymity-revokers) [--block BLOCK] Display the list of identity providers or :term:`Privacy Guardians` at a given block, -defaulting to the :term:`best block`. +defaulting to the best block. .. _exchange-rates: diff --git a/source/mainnet/tools/transactions.rst b/source/mainnet/tools/transactions.rst index 26614f5c65..d977e93c4c 100644 --- a/source/mainnet/tools/transactions.rst +++ b/source/mainnet/tools/transactions.rst @@ -290,7 +290,7 @@ This This command has all of the additional options of ``send``, as well as an additional flag ``--index.`` If given, this flag is used to select which -:term:`incoming shielded amounts` that will be used as input to the transaction. +incoming shielded amounts that will be used as input to the transaction. .. code-block:: console From 8e5daa3d2dee7cd51099f4e8b6504601f0331029 Mon Sep 17 00:00:00 2001 From: Tina Thomsen Date: Thu, 17 Jul 2025 15:43:29 +0200 Subject: [PATCH 4/5] deleted term removed from glossary --- source/mainnet/tools/query-node.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/mainnet/tools/query-node.rst b/source/mainnet/tools/query-node.rst index b6d69320f9..82fd9bb6b6 100644 --- a/source/mainnet/tools/query-node.rst +++ b/source/mainnet/tools/query-node.rst @@ -282,7 +282,7 @@ Exchange rates ============== Conversion rates between NRG, CCD, and Euros can fluctuate between blocks. To get a best estimate of the current -exchange rates, query the chain parameters of the :term:`best block`: +exchange rates, query the chain parameters of the best block: .. code-block:: console From ca8bca93c665ca9e1122f74141ca4ad7176aab1b Mon Sep 17 00:00:00 2001 From: Tina Thomsen Date: Thu, 17 Jul 2025 16:15:51 +0200 Subject: [PATCH 5/5] added Identity record to glossary --- source/mainnet/docs/resources/glossary.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/source/mainnet/docs/resources/glossary.rst b/source/mainnet/docs/resources/glossary.rst index 387f0ac616..306616f7ea 100644 --- a/source/mainnet/docs/resources/glossary.rst +++ b/source/mainnet/docs/resources/glossary.rst @@ -13,7 +13,7 @@ Also see the Concordium `Whitepaper `, in cooperation with the account's :term:`identity provider`. + An addressable store of funds on the blockchain. An account is associated with one or more *account keys* that can be used to authorize transactions originating from the account, as well as with an :term:`encryption key`. An account is also associated with the account holder's :term:`identity`, although this association is encrypted. This identity can only be disclosed by :term:`privacy guardians`, in cooperation with the account's :term:`identity provider`. Account address @@ -291,7 +291,11 @@ Also see the Concordium `Whitepaper