Account types

docs/architecture.mdx

@@ -151,7 +151,7 @@ Optionally, this node can open its RPC interface to serve different kinds of req
 
 For more information about the architecture of Tezos, see:
 
-- [Accounts](./architecture/accounts)
+- [Accounts and addresses](./architecture/accounts)
 - [Tokens](./architecture/tokens)
 - [Smart Optimistic Rollups](./architecture/smart-rollups)
 - [Governance](./architecture/governance)

docs/architecture/accounts.md

@@ -1,21 +1,27 @@
 ---
-title: Accounts
+title: Accounts and addresses
 authors: "Tim McMackin"
 last_update:
-  date: 29 December 2023
+  date: 10 January 2024
 ---
 
+## Accounts
+
 Tezos uses these types of accounts:
 
-- Classic accounts (also known as _implicit accounts_) store tez (ꜩ) and tickets.
-These accounts have addresses that start with "tz1", "tz2", "tz3" or "tz4."
-Any wallet application or the Octez command-line tool can create implicit accounts.
+- User accounts (sometimes known as _implicit accounts_) store tez (ꜩ) and tickets.
+Any wallet application or the Octez command-line tool can create user accounts.
 
-- Smart contract accounts (also known as _originated accounts_) store immutable code, mutable storage, tez (ꜩ), and tickets.
-Smart contracts have addresses that start with "KT1."
+- Smart contract accounts (sometimes known as _originated accounts_) store immutable code, mutable storage, tez (ꜩ), and tickets.
 See [Smart contracts](../smart-contracts).
 
-- Smart Rollup accounts are another type of originated account.
-Their addresses start with `SR1`.
+## Addresses
+
+- User accounts have addresses that start with "tz1", "tz2", "tz3" or "tz4."
+
+- Smart contracts have addresses that start with "KT1."
+
+- Smart Rollups have addresses, but are not accounts because they cannot store tez.
+Their addresses start with "SR1".
 They have a tree of commitments attached to them.
 See [Smart Optimistic Rollups](./smart-rollups).

docs/dApps/taquito.md

@@ -89,13 +89,13 @@ Tezos.setWalletProvider(wallet)
 
 ## Getting data from the Tezos blockchain
 
-Taquito provides methods to get different types of data from the Tezos blockchain, for example, the balance of an implicit account, the storage of a contract or token metadata.
+Taquito provides methods to get different types of data from the Tezos blockchain, for example, the balance of a user account, the storage of a contract or token metadata.
 
 > Note: querying data from the blockchain doesn't create a new transaction.
 
 ### Getting the balance of an account
 
-Taquito allows developers to get the current balance in tez of an implicit account. The `getBalance` method is available on the instance of the TezosToolkit and requires a parameter of type `string` that represents the address of the account.
+Taquito allows developers to get the current balance in tez of a user account. The `getBalance` method is available on the instance of the TezosToolkit and requires a parameter of type `string` that represents the address of the account.
 
 The returned value is of type `BigNumber`:
 

docs/overview/glossary.md

@@ -129,7 +129,7 @@ The following is adapted from this [Agora post](https://forum.tezosagora.org/t/n
     In the context, each account is associated with a balance (an amount of
     tez available).
 
-    An account can be either an originated account or an implicit account.
+    An account can be a user account or a smart contract.
 
 - **Baker**
 
@@ -190,9 +190,9 @@ The following is adapted from this [Agora post](https://forum.tezosagora.org/t/n
 
 - **Delegate**
 
-    An implicit account that can participate in consensus and in governance.
+    A user account that can participate in consensus and in governance.
     Actual participation is under further provisions, like having a minimal stake.
-    An implicit account becomes a delegate by registering as such.
+    A user account becomes a delegate by registering as such.
     Through delegation, other accounts can delegate their rights to a delegate account.
     The delegate's rights are calculated based on its stake.
     Note that `tz4` accounts cannot be delegates.
@@ -252,15 +252,7 @@ The following is adapted from this [Agora post](https://forum.tezosagora.org/t/n
 
 - **Implicit account**
 
-    An account that is linked to a public key. Contrary to a smart
-    contract, an implicit account cannot include a script and it
-    cannot reject incoming transactions.
-
-    If *registered*, an implicit account can act as a delegate.
-
-    The address of an implicit account always starts with the
-    letters tz followed by 1, 2, 3, or 4 (depending on the
-    signature scheme) and finally the hash of the public key.
+    See [User account](#user-account).
 
 - **Layer 1**
 
@@ -345,6 +337,20 @@ The following is adapted from this [Agora post](https://forum.tezosagora.org/t/n
     An operation to transfer tez between two accounts, or to run the code of a
     smart contract.
 
+<a name="user-account"/>
+
+- **User account**
+
+    An account that is linked to a public key. Contrary to a smart
+    contract, a user account cannot include a script and it
+    cannot reject incoming transactions.
+
+    If *registered*, a user account can act as a delegate.
+
+    The address of a user account always starts with the
+    letters tz followed by 1, 2, 3, or 4 (depending on the
+    signature scheme) and finally the hash of the public key.
+
 - **Validation pass**
 
     An index (a natural number) associated with a particular kind of

docs/smart-contracts/data-types/complex-data-types.md

@@ -392,7 +392,7 @@ The ticket's information is public and can be read by any contract that holds th
 
 Contracts can pass tickets to entrypoints to change which contract is in control of the ticket.
 If contract A passes a ticket to contract B, contract A loses all access to the ticket.
-Contracts can pass tickets only to other contracts (implicit accounts) because the entrypoint must accept a ticket of the correct type; contracts cannot pass tickets to user accounts.
+Contracts can pass tickets only to other contracts because the entrypoint must accept a ticket of the correct type; contracts cannot pass tickets to user accounts.
 
 ### Ticket features
 

docs/smart-contracts/data-types/primitive-data-types.md

@@ -160,16 +160,16 @@ The following operations are supported on timestamps:
 
 ## Addresses {#addresses}
 
-On Tezos, each account is uniquely identified by its `address`, whether it is a user account (implicit account) or a contract (originated account).
+On Tezos, each account is uniquely identified by its `address`.
 
 Internally, addresses take the form of a `string` type.
-For implicit accounts, the string starts with "tz1", "tz2", "tz3" or "tz4".
-For originated accounts, the string starts with "KT1".
+For user accounts, the string starts with "tz1", "tz2", "tz3" or "tz4".
+For smart contract accounts, the string starts with "KT1".
 
 | Type of Account | Example |
 | --- | --- |
-| Implicit Account | `tz1YWK1gDPQx9N1Jh4JnmVre7xN6xhGGM4uC` |
-| Originated Account | `KT1S5hgipNSTFehZo7v81gq6fcLChbRwptqy` |
+| User account | `tz1YWK1gDPQx9N1Jh4JnmVre7xN6xhGGM4uC` |
+| Smart contract | `KT1S5hgipNSTFehZo7v81gq6fcLChbRwptqy` |
 
 The next part of the string is a `Base58` encoded hash, followed by a 4-byte checksum.
 

docs/smart-contracts/deploying.md

@@ -5,7 +5,7 @@ last_update:
   date: 6 November 2023
 ---
 ## Introduction
-In Tezos, deploying a smart contract is often referred to as “origination”. This process essentially creates a new account that holds the smart contract's script. Contracts originated in this manner have addresses that start with `KT1` (known as originated accounts), which distinguishes them from the implicit accounts with addresses beginning with `tz1`, `tz2`, or `tz3`.
+In Tezos, deploying a smart contract is often referred to as “origination”. This process essentially creates a new account that holds the smart contract's script. Contracts originated in this manner have addresses that start with `KT1`, which distinguishes them from the user accounts with addresses beginning with `tz1`, `tz2`, or `tz3`.
 
 ## Prerequisites
 - Compile your contract and its initial storage

docs/smart-contracts/logic/comparing.md

@@ -17,7 +17,7 @@ How values are compared depends on the type of the values:
 - Strings, `bytes`, `key_hash`, `key`, `signature` and `chain_id` values are compared lexicographically.
 - Boolean values are compared so that false is strictly less than true.
 - Address are compared as follows:
-  - Addresses of implicit accounts are strictly less than addresses of originated accounts.
+  - Addresses of user accounts are strictly less than addresses of smart contracts.
   - Addresses of the same type are compared lexicographically.
 - Pair values (and therefore records) are compared component by component, starting with the first component.
 - Options are compared as follows:

docs/smart-contracts/multisig-usage.md

@@ -58,7 +58,7 @@ Note, this section uses the
 
 The Generic Multisig allows us to set administrators of the contract
 (`signerKeys`) and the number of those administrators required to sign
-(`threshold`). As of writing, the command line tool only allows `tz1` implicit
+(`threshold`). As of writing, the command line tool only allows `tz1` user
 accounts to be administrators, though the contract allows `KT1` originated
 accounts as well.
 

docs/smart-contracts/special-values.md

@@ -27,7 +27,7 @@ For example, assume that user A called contract B that in turn called contract C
   When C runs, `source` is the address of A, while `caller` is the address of B.
 
 :::warning Access permissions
-It is best practice to implement permissioning based on `caller` instead of `source` because any implicit account can call any entrypoint on Tezos.
+It is best practice to implement permissioning based on `caller` instead of `source` because any user account can call any entrypoint on Tezos.
 :::
 
 - `self`: The address of the contract itself.

docs/tutorials/dapp/part-1.md

@@ -164,7 +164,7 @@ Taqueria is generating the `.tz` Michelson file on the `artifacts` folder. The M
 
 The default Tezos testing testnet is called **Ghostnet**.
 
-> :warning: You need an account to deploy a contract with some `tez` (the Tezos native currency). The first time you deploy a contract with Taqueria, it is generating a new implicit account with `0 tez`.
+> :warning: You need an account to deploy a contract with some `tez` (the Tezos native currency). The first time you deploy a contract with Taqueria, it is generating a new user account with `0 tez`.
 
 1. Deploy your contract to the `testing` environment. Ut forces Taqueria to generate a default account on a testing config file.
 

docs/tutorials/dapp/part-2.md

@@ -201,7 +201,7 @@ sequenceDiagram
 
    - `#import "./pokeGame.jsligo" "PokeGame"` to import the source file as module in order to call functions and use object definitions.
    - `export type main_fn` it will be useful later for the mutation tests to point to the main function to call/mutate.
-   - `Test.reset_state ( 2...` this creates two implicit accounts on the test environment.
+   - `Test.reset_state ( 2...` this creates two user accounts on the test environment.
    - `Test.nth_bootstrap_account` this return the nth account from the environment.
    - `Test.to_contract(taddr)` and `Tezos.address(contr)` are util functions to convert typed addresses, contract and contract addresses.
    - `let _testPoke = (s : address) : unit => {...}` declaring function starting with `_` is escaping the test for execution. Use this to factorize tests changing only the parameters of the function for different scenarios.

docs/tutorials/dapp/part-3.md

@@ -49,7 +49,7 @@ Tickets features:
 
 - Not comparable: it makes no sense to compare tickets because tickets from same type are all equals and can be merged into a single ticket. When ticket types are different then it is no more comparable.
 - Transferable: you can send ticket into a Transaction parameter.
-- Storable: only on smart contract storage for the moment (Note: a new protocol release will enable it for implicit account soon).
+- Storable: only on smart contract storage for the moment (Note: a new protocol release will enable it for user account soon).
 - Non dupable: you cannot copy or duplicate a ticket, it is a unique singleton object living in specific blockchain instance.
 - Splittable: if amount is > 2 then you can split ticket object into 2 objects.
 - Mergeable: you can merge ticket from same ticketer and same type.