[rename] updating doc site md diem->aptos

gramanje · Mar 7, 2022 · 0510e6f · 0510e6f
1 parent 25b6ce3
commit 0510e6f
Show file tree

Hide file tree

Showing 30 changed files with 401 additions and 401 deletions.
diff --git a/developer-docs-site/docs/basics/basics-accounts.md b/developer-docs-site/docs/basics/basics-accounts.md
@@ -3,7 +3,7 @@ title: "Accounts"
 id: "basics-accounts"
 hidden: false
 ---
-An account represents a resource on the Diem Blockchain that can send transactions. Each account is identified by a particular 16-byte account address and is a container for Move modules and Move resources.
+An account represents a resource on the Aptos Blockchain that can send transactions. Each account is identified by a particular 16-byte account address and is a container for Move modules and Move resources.
 
 ## Introduction
 
@@ -12,11 +12,11 @@ The state of each account comprises both code and data:
 - **Code**: Move modules contain code (type and procedure declarations), but they do not contain data. The module's procedures encode the rules for updating the blockchain's global state.
 - **Data**: Move resources contain data but no code. Every resource value has a type that is declared in a module published in the blockchain's distributed database.
 
-An account may contain an arbitrary number of Move resources and Move modules. The Diem Payment Network (DPN) supports accounts created for Regulated Virtual Asset Service Providers [Regulated VASP](/reference/glossary#regulated-vasp) and Designated Dealers.
+An account may contain an arbitrary number of Move resources and Move modules. The Aptos Payment Network (DPN) supports accounts created for Regulated Virtual Asset Service Providers [Regulated VASP](/reference/glossary#regulated-vasp) and Designated Dealers.
 
 ## Account address
 
-A Diem account address is a 16-byte value. The account address is derived from a cryptographic hash of its public verification key concatenated with a signature scheme identifier byte. The Diem Blockchain supports two signature schemes:[Ed25519](/reference/glossary#ed25519) and MultiEd25519 (for multi-signature transactions). You will need the account's private key to sign a transaction.
+A Aptos account address is a 16-byte value. The account address is derived from a cryptographic hash of its public verification key concatenated with a signature scheme identifier byte. The Aptos Blockchain supports two signature schemes:[Ed25519](/reference/glossary#ed25519) and MultiEd25519 (for multi-signature transactions). You will need the account's private key to sign a transaction.
 
 An account address is derived from its initial authentication key.
 
@@ -39,30 +39,30 @@ Creating a K-of-N multisig authentication key is similar to creating a single si
 
 Every account on the DPN is created with at least two resources:
 
-* [RoleId](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/core/doc/Roles.md#resource-roleid), which grants the account a single, immutable [role](basics-accounts.md#account-roles) for [access control](https://github.com/diem/dip/blob/main/dips/dip-2.md).
-* [DiemAccount](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/core/doc/DiemAccount.md#resource-diemaccount), which holds the account’s [sequence number](/reference/glossary#sequence-number), authentication key, and event handles.
+* [RoleId](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/core/doc/Roles.md#resource-roleid), which grants the account a single, immutable [role](basics-accounts.md#account-roles) for [access control](https://github.com/aptos/dip/blob/main/dips/dip-2.md).
+* [AptosAccount](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/core/doc/AptosAccount.md#resource-aptosaccount), which holds the account’s [sequence number](/reference/glossary#sequence-number), authentication key, and event handles.
 
 ### Currencies
 
 The DPN supports an account transacting in different currencies.
 
-From a standards perspective, [`Diem<CoinType>`](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/core/doc/Diem.md#resource-diem) is the Diem Blockchain equivalent of [ERC20](https://eips.ethereum.org/EIPS/eip-20). At the Move level, these are different generic instantiations of the same Diem resource type (e.g., `Diem<Coin1>`, `Diem<XUS>`).
+From a standards perspective, [`Aptos<CoinType>`](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/core/doc/Aptos.md#resource-aptos) is the Aptos Blockchain equivalent of [ERC20](https://eips.ethereum.org/EIPS/eip-20). At the Move level, these are different generic instantiations of the same Aptos resource type (e.g., `Aptos<Coin1>`, `Aptos<XUS>`).
 
-`Diem<XUS>` will be the currency type available at launch.
+`Aptos<XUS>` will be the currency type available at launch.
 
 ### Balances
 
-A zero balance of `Diem<CoinType>` is added whenever `Diem<CoinType>` currency is authorized for an account.
+A zero balance of `Aptos<CoinType>` is added whenever `Aptos<CoinType>` currency is authorized for an account.
 
-Each non-administrative account stores one or more [Balance`<CoinType>`](https://github.com/diem/diem/blob/main/aptos-move/diem-framework/core/doc/DiemAccount.md#resource-balance) resources. For each currency type that the account holds such as `Diem<Coin1>` or `Diem<XUS>`, there will be a separate Balance resource such as Balance`<Diem<Coin1>>` or Balance`<Diem<XUS>>`.
+Each non-administrative account stores one or more [Balance`<CoinType>`](https://github.com/aptos/aptos/blob/main/aptos-move/aptos-framework/core/doc/AptosAccount.md#resource-balance) resources. For each currency type that the account holds such as `Aptos<Coin1>` or `Aptos<XUS>`, there will be a separate Balance resource such as Balance`<Aptos<Coin1>>` or Balance`<Aptos<XUS>>`.
 
 When a client sends funds of type CoinType to an account, they should:
 * check if the account address exists
 * ensure that the account address has a balance in CoinType, even if that balance is zero.
 
-To send and receive `Diem<CoinType>`, an account must have a balance in `Diem<CoinType>`. A transaction that sends `Diem<CoinType>` to an account without a balance in `Diem<CoinType>` will abort.
+To send and receive `Aptos<CoinType>`, an account must have a balance in `Aptos<CoinType>`. A transaction that sends `Aptos<CoinType>` to an account without a balance in `Aptos<CoinType>` will abort.
 
-Balances can be added either at account creation or subsequently via the [add_currency script](../transactions/txns-types/txns-manage-accounts.md#add-a-currency-to-an-account). Only the account owner can add new balances after account creation. Once you add a balance to an account, it cannot be removed. For example, an account that accepts `Diem<XUS>` will always accept `Diem<XUS>`.
+Balances can be added either at account creation or subsequently via the [add_currency script](../transactions/txns-types/txns-manage-accounts.md#add-a-currency-to-an-account). Only the account owner can add new balances after account creation. Once you add a balance to an account, it cannot be removed. For example, an account that accepts `Aptos<XUS>` will always accept `Aptos<XUS>`.
 
 ## Account roles
 
@@ -79,7 +79,7 @@ A ChildVASP knows the address of its ParentVASP. If off-chain communication is r
 
 ## Create accounts
 
-When the Diem main network (mainnet) is launched, only the [TreasuryCompliance account](https://github.com/diem/dip/blob/main/dips/dip-2.md#roles) can create ParentVASP accounts. Once a ParentVASP account is created, the Regulated VASP can then create ChildVASP accounts.
+When the Aptos main network (mainnet) is launched, only the [TreasuryCompliance account](https://github.com/aptos/dip/blob/main/dips/dip-2.md#roles) can create ParentVASP accounts. Once a ParentVASP account is created, the Regulated VASP can then create ChildVASP accounts.
 
 To create a new account, the creator must specify
 * the address of the new account

diff --git a/developer-docs-site/docs/basics/basics-events.md b/developer-docs-site/docs/basics/basics-events.md
@@ -3,13 +3,13 @@ title: "Events"
 slug: "basics-events"
 hidden: false
 ---
-Events are Move data that are emitted during the execution of a transaction on the Diem Blockchain.
+Events are Move data that are emitted during the execution of a transaction on the Aptos Blockchain.
 
-For example, whenever a payment transaction is sent or received on-chain, the transaction will emit the relevant data using the `SentPaymentEvent` and `ReceivedPaymentEvent`. This data is stored in the EventStore, which is part of the Diem Blockchain’s ledger state. You can query the EventStore to get proof of executed transactions on-chain.
+For example, whenever a payment transaction is sent or received on-chain, the transaction will emit the relevant data using the `SentPaymentEvent` and `ReceivedPaymentEvent`. This data is stored in the EventStore, which is part of the Aptos Blockchain’s ledger state. You can query the EventStore to get proof of executed transactions on-chain.
 
 ## Introduction
 
-Events are grouped into **event streams** based on event type. The Diem Framework uses different types of events for payments, minting/burning, and system operations. A detailed list of the event types accessible from JSON-RPC is available in the [JSON-RPC documentation](https://github.com/diem/diem/blob/main/json-rpc/docs/type_event.md).
+Events are grouped into **event streams** based on event type. The Aptos Framework uses different types of events for payments, minting/burning, and system operations. A detailed list of the event types accessible from JSON-RPC is available in the [JSON-RPC documentation](https://github.com/aptos/aptos/blob/main/json-rpc/docs/type_event.md).
 
 ### Payment transaction events
 
@@ -22,7 +22,7 @@ Both `SentPaymentEvent` and `ReceivedPaymentEvent` have the same structure:
 
 | Field Name | Type                                                         | Description                                                  |
 | ---------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
-| amount     | [Amount](https://github.com/diem/diem/blob/main/json-rpc/docs/type_amount.md) | Amount received from the sender of the transaction           |
+| amount     | [Amount](https://github.com/aptos/aptos/blob/main/json-rpc/docs/type_amount.md) | Amount received from the sender of the transaction           |
 | sender     | string                                                       | Hex-encoded address of the account whose balance was debited to perform this deposit. If the deposited funds came from a mint transaction, the sender address will be 0x0...0. |
 | receiver   | string                                                       | Hex-encoded address of the account whose balance was credited by this deposit.<br /> |
 | metadata   | string                                                       | An optional field that can contain extra metadata for the event. This information can be used by an off-chain API to implement a sub-addressing scheme for a wallet. |
@@ -42,18 +42,18 @@ There are also several events related to system-level operations, for example:
 
 * `UpgradeEvent` — when a special system maintenance WriteSet transaction is applied
 * `NewEpochEvent` — when an on-chain configuration is modified
-* `NewBlockEvent` — when a new block of transactions is added to the Diem Blockchain
+* `NewBlockEvent` — when a new block of transactions is added to the Aptos Blockchain
 
 ## Event concepts
-![Figure 1.0 EventHandle and event streams in the Diem Framework](/img/docs/events-fig1.svg)
-<small className="figure">Figure 1.0 EventHandle and event streams in the Diem Framework</small>
+![Figure 1.0 EventHandle and event streams in the Aptos Framework](/img/docs/events-fig1.svg)
+<small className="figure">Figure 1.0 EventHandle and event streams in the Aptos Framework</small>
 
 * **Event stream**: Events are grouped into “**event streams,**” which are append-only vectors of ContractEvent payloads. For example, an account can have a SentPaymentEvent stream and a ReceivePaymentEvent stream. The entries in an event stream are assigned sequence numbers beginning from zero.
 * **Event key**: Each event stream is associated with a key value, which is a globally unique 40-byte array that is defined when the stream is created. The event key for an account’s event stream will never be modified.
-* **EventHandle**: An EventHandle contains the event key and the number of events in the stream. This count is always equal to the biggest sequence number for the events in the stream. An EventHandle resource is typically embedded inside other Move resources to record related events. For example, every DiemAccount resource contains a `sent_events` EventHandle for a SentPaymentEvents stream and also a `received_events` EventHandle for a ReceivedPaymentEvents stream. Event streams are referenced from the StateStore via EventHandle Move resources.
+* **EventHandle**: An EventHandle contains the event key and the number of events in the stream. This count is always equal to the biggest sequence number for the events in the stream. An EventHandle resource is typically embedded inside other Move resources to record related events. For example, every AptosAccount resource contains a `sent_events` EventHandle for a SentPaymentEvents stream and also a `received_events` EventHandle for a ReceivedPaymentEvents stream. Event streams are referenced from the StateStore via EventHandle Move resources.
 * **ContractEvent**: A ContractEvent payload contains the event key, the sequence number, and a serialized Move value, along with a tag to identify the type of that value. Different kinds of events are distinguished by the Move value types, such as `SentPaymentEvent` or `ReceivedPaymentEvent`, which are emitted to the event streams.
 
-The Event module in the Diem Framework specifies the details of event implementation in Move. The views of event information from JSON-RPC are often presented somewhat differently than the underlying implementation. For example, EventHandles are typically displayed as only the key values, e.g., `sent_events_key` instead of a `sent_events` EventHandle structure containing the key. This rest of this page shows examples of events as they are viewed through the JSON-RPC interface.
+The Event module in the Aptos Framework specifies the details of event implementation in Move. The views of event information from JSON-RPC are often presented somewhat differently than the underlying implementation. For example, EventHandles are typically displayed as only the key values, e.g., `sent_events_key` instead of a `sent_events` EventHandle structure containing the key. This rest of this page shows examples of events as they are viewed through the JSON-RPC interface.
 
 
 ## How to query events
@@ -65,31 +65,31 @@ There are several JSON-RPC API methods associated with events:
 ### Get `SentPaymentEvent` for an account
 
 This example demonstrates how to query a `SentPaymentEvent` for an account. In this example, account 0x996b67d has two event streams, with 3 sent payments and 2 received payments:
-![Figure 1.1 Example event streams for a Diem Account](/img/docs/events-fig2.svg)
-<small className="figure">Figure 1.1 Example event streams for a Diem Account</small>
+![Figure 1.1 Example event streams for a Aptos Account](/img/docs/events-fig2.svg)
+<small className="figure">Figure 1.1 Example event streams for a Aptos Account</small>
 
-1. The first step is to find the event key for the account’s `SentPaymentEvent` stream. We can send a [`get_account`](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_account.md)
-query to the JSON-RPC endpoint to get the state of that [`account`](https://github.com/diem/diem/blob/main/json-rpc/docs/type_account.md), including two event keys: one for the `SentPaymentEvent` stream (the `sent_events_key` field) and one for the `ReceivedPaymentEvent` stream (the `received_events_key` field). The response will look like the following:
+1. The first step is to find the event key for the account’s `SentPaymentEvent` stream. We can send a [`get_account`](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_account.md)
+query to the JSON-RPC endpoint to get the state of that [`account`](https://github.com/aptos/aptos/blob/main/json-rpc/docs/type_account.md), including two event keys: one for the `SentPaymentEvent` stream (the `sent_events_key` field) and one for the `ReceivedPaymentEvent` stream (the `received_events_key` field). The response will look like the following:
 ```json
 {
-  "diem_chain_id" : 2,
+  "aptos_chain_id" : 2,
   "jsonrpc" : "2.0",
-  "diem_ledger_timestampusec" : 1597084681499780,
+  "aptos_ledger_timestampusec" : 1597084681499780,
   "result": {
     "received_events_key": "00000000000000001668f6be25668c1a17cd8caf6b8d2f25",
     "sent_events_key": "01000000000000001668f6be25668c1a17cd8caf6b8d2f25",
     ...
   },
   "id" : 1,
-  "diem_ledger_version" : 1303433
+  "aptos_ledger_version" : 1303433
 }
 ```
-2. The next step is to use the [`get_events`](https://github.com/diem/diem/blob/main/json-rpc/docs/method_get_events.md) API method to fetch the event details. In the JSON-RPC query, we can specify to fetch one event beginning with sequence number 2 from the `sent_events_key` event stream. The response will look like the following:
+2. The next step is to use the [`get_events`](https://github.com/aptos/aptos/blob/main/json-rpc/docs/method_get_events.md) API method to fetch the event details. In the JSON-RPC query, we can specify to fetch one event beginning with sequence number 2 from the `sent_events_key` event stream. The response will look like the following:
 ```json
 {
   "id": 1,
   "jsonrpc": "2.0",
-  "diem_chain_id": 2,
+  "aptos_chain_id": 2,
   "result": [
     {
       "data": {