diff --git a/developer-docs-site/docs/guides/building-from-source.md b/developer-docs-site/docs/guides/building-from-source.md index cc1d4cb2737f4..7c559b09f1d92 100644 --- a/developer-docs-site/docs/guides/building-from-source.md +++ b/developer-docs-site/docs/guides/building-from-source.md @@ -106,7 +106,8 @@ If the script above does not work for you, you can install these manually, but i 1. [Rust](https://www.rust-lang.org/tools/install). 1. [CMake](https://cmake.org/download/). 1. [LLVM](https://releases.llvm.org/). -1. [libssl-dev](https://packages.ubuntu.com/bionic/libssl-dev) and [libclang-dev](https://packages.ubuntu.com/bionic/libclang-dev) +1. [libssl-dev](https://packages.ubuntu.com/jammy/libssl-dev) and [libclang-dev](https://packages.ubuntu.com/jammy/libclang-dev) + diff --git a/developer-docs-site/docs/guides/nfts/mint-nft-cli.md b/developer-docs-site/docs/guides/nfts/mint-nft-cli.md index b1ebdbc399748..61545c1610c09 100644 --- a/developer-docs-site/docs/guides/nfts/mint-nft-cli.md +++ b/developer-docs-site/docs/guides/nfts/mint-nft-cli.md @@ -335,7 +335,7 @@ The final phase of development is to make the smart contract module ready for pr We prepare the module for production by: * adding a `TokenMintingEvent` to emit a custom event for tracking minting of tokens from this module. -* enabling signature verification and ntroducing the concept of a proof challenge to prevent bot spamming. +* enabling signature verification and introducing the concept of a proof challenge to prevent bot spamming. * including [unit tests](../../move/book/unit-testing.md) to make sure our code works as expected. @@ -526,7 +526,7 @@ In the [NFT Tutorial](https://github.com/aptos-labs/aptos-core/tree/main/aptos-m ### Mint more NFTs and disable minting from admin account -1. Mint another NFT using the `nft-receiver` profile, sustituting in the resource account's address: +1. Mint another NFT using the `nft-receiver` profile, substituting in the resource account's address: ```shell aptos move run --function-id ::minting::mint_nft --profile nft-receiver diff --git a/developer-docs-site/docs/guides/nfts/mint-onchain-data.md b/developer-docs-site/docs/guides/nfts/mint-onchain-data.md index 15051bd3232de..6b53153458f79 100644 --- a/developer-docs-site/docs/guides/nfts/mint-onchain-data.md +++ b/developer-docs-site/docs/guides/nfts/mint-onchain-data.md @@ -32,7 +32,7 @@ Parameters: All the parameters could be adjusted as appropriate. ## Create tokens -The fungible token in Aptos has an unique `TokenId`, a set of creator, collection name, token name and property version. +The fungible token in Aptos has a unique `TokenId`, a set of creator, collection name, token name and property version. For fungible tokens, the property version is always 0. To create a token named "Silver Coin", you run: ```bash aptos move run --function-id 0x3::token::create_token_script --args string:"Game Coins" string:"Silver Coin" string:"The currency in my game" u64:100 u64:0 string:$TOKEN_URL address:$YOUR_ADDRESS u64:0 u64:0 'bool:[false,false,false,false,false]' raw:00 raw:00 raw:00 @@ -42,7 +42,7 @@ Parameters: - token name: "Silver Coin". - token description: "The currency in my game". - maximum: 0. 0 means there is no maximum supply of this token. -- uri: Your token url can point to anything. Usually it is an arweave or ipfs url pointing to an token image or JSON +- uri: Your token url can point to anything. Usually it is an arweave or ipfs url pointing to a token image or JSON file containing the required metadata. - royalty_payee_address: Used for NFT. For FT, it is recommended to set the creator address. - royalty_points_denominator: Used for NFT. Set to 0 as N/A. diff --git a/developer-docs-site/docs/guides/transaction-management.md b/developer-docs-site/docs/guides/transaction-management.md index 7c910fdd6a970..2bee267248210 100644 --- a/developer-docs-site/docs/guides/transaction-management.md +++ b/developer-docs-site/docs/guides/transaction-management.md @@ -41,7 +41,7 @@ Currently this framework assumes that the network builds no substantial queue, t - Further handling of transaction processing rates to ensure that the expiration timer is properly set. - Handling of transaction failures to either be ignored or resubmitted based upon desired outcome. -Note, an account should be manged by a single instance of the transaction manager. Otherwise each instance of the transaction manager will likely have stale in-memory state resulting in overlapping sequence numbers. +Note, an account should be managed by a single instance of the transaction manager. Otherwise each instance of the transaction manager will likely have stale in-memory state resulting in overlapping sequence numbers. ### Implementations @@ -63,7 +63,7 @@ Each transaction requires a distinct sequence number that is sequential to previ In parallel, monitor new transactions submitted. Once the earliest transaction expiration time has expired synchronize up to that transaction. Then repeat the process for the next transaction. -If there is any failure, wait until all outstanding transactions have timed out and leave it to the application to decide how to proceed, e.g., replay failed transactions. The best method for waiting for outstanded transactions is first to query the ledger timestamp and ensure it is at least elapsed the maximum timeout from the last transactions submit time. From there, validate with mempool that all transactions since the last known committed transaction are either committed or no longer exist within the mmempool. This can be done by querying the REST API for transactions of a specific account, specifying the currently being evaluated sequence number and setting a limit to 1. Once these checks are complete, the local transaction number can be resynchronized. +If there is any failure, wait until all outstanding transactions have timed out and leave it to the application to decide how to proceed, e.g., replay failed transactions. The best method for waiting for outstanded transactions is first to query the ledger timestamp and ensure it is at least elapsed the maximum timeout from the last transactions submit time. From there, validate with mempool that all transactions since the last known committed transaction are either committed or no longer exist within the mempool. This can be done by querying the REST API for transactions of a specific account, specifying the currently being evaluated sequence number and setting a limit to 1. Once these checks are complete, the local transaction number can be resynchronized. These failure handling steps are critical for the following reasons: * Mempool does not immediate evict expired transactions. diff --git a/developer-docs-site/docs/nodes/validator-node/operator/staking-pool-operations.md b/developer-docs-site/docs/nodes/validator-node/operator/staking-pool-operations.md index a4450d6936b03..890efeb0b54e3 100644 --- a/developer-docs-site/docs/nodes/validator-node/operator/staking-pool-operations.md +++ b/developer-docs-site/docs/nodes/validator-node/operator/staking-pool-operations.md @@ -301,7 +301,7 @@ aptos stake request-commission \ --profile mainnet-operator ``` -If you run the `aptos stake request-commission` command before the end of the the lockup expiration, the command will initiate unlock for any locked commission earned up until that moment in time. +If you run the `aptos stake request-commission` command before the end of the lockup expiration, the command will initiate unlock for any locked commission earned up until that moment in time. See example below: @@ -387,4 +387,4 @@ aptos node analyze-validator-performance \ ## Tracking rewards -`DistributeEvent` is emitted when there is a transfer from staking_contract to the operator or staker (owner). Rewards can be tracked either by listening to `DistributeEvent` or by using the [View functon](../../../integration/aptos-apis.md#reading-state-with-the-view-function) to call `staking_contract_amounts`. This will return `accumulated_rewards` and `commission_amount`. +`DistributeEvent` is emitted when there is a transfer from staking_contract to the operator or staker (owner). Rewards can be tracked either by listening to `DistributeEvent` or by using the [View function](../../../integration/aptos-apis.md#reading-state-with-the-view-function) to call `staking_contract_amounts`. This will return `accumulated_rewards` and `commission_amount`. diff --git a/developer-docs-site/docs/tools/aptos-cli/use-cli/use-aptos-cli.md b/developer-docs-site/docs/tools/aptos-cli/use-cli/use-aptos-cli.md index 7405f20c0a288..ef285a7c396ac 100644 --- a/developer-docs-site/docs/tools/aptos-cli/use-cli/use-aptos-cli.md +++ b/developer-docs-site/docs/tools/aptos-cli/use-cli/use-aptos-cli.md @@ -874,9 +874,9 @@ The `aptos` tool supports bootstrapping new blockchains through what is known as - The genesis organizer constructs a `Layout` and distributes it. - The genesis organizer prepares the Aptos framework's bytecode and distributes it. - Each participant generates their `ValidatorConfiguration` and distributes it. -- Each participant generates a `genesis.blob` from the resulting contributions +- Each participant generates a `genesis.blob` from the resulting contributions. - The genesis organizer executes the `genesis.blob` to derive the initial waypoint and distributes it. -- Each participant begins their `aptos-node`. The `aptos-node` verifies upon startup that the `genesis.blob` with the waypoint provided by the genesis organizer . +- Each participant begins their `aptos-node`. The `aptos-node` verifies upon startup that the `genesis.blob` with the waypoint provided by the genesis organizer. - The blockchain will begin consensus after a quorum of stake is available. ### Prepare aptos-core diff --git a/developer-docs-site/docs/tutorials/build-e2e-dapp/1-create-smart-contract.md b/developer-docs-site/docs/tutorials/build-e2e-dapp/1-create-smart-contract.md index 1bd1a00abe468..0a27e51fe4f1a 100644 --- a/developer-docs-site/docs/tutorials/build-e2e-dapp/1-create-smart-contract.md +++ b/developer-docs-site/docs/tutorials/build-e2e-dapp/1-create-smart-contract.md @@ -163,7 +163,7 @@ Let’s try to compile what we have now: **Seeing errors?!** Let’s understand them. -We have some errors on `Unbound type`- this is happening because we used some types but never imported them, and the compiler doesnt know where to get them from. +We have some errors on `Unbound type`- this is happening because we used some types but never imported them, and the compiler doesn't know where to get them from. 3. On the top of the module, import those types by adding: @@ -497,7 +497,7 @@ Additionally, the function itself now accepts a signer argument. **Let’s understand our tests.** -Since our tests runs outside of an account scope, we need to _create_ accounts to use in our tests. The `#[test]` annotation gives us the option to declare those accounts. We use an `admin` account and set it to a random account address (`@0x123`). The function accepts this signer (account) and creates it by using a built-in function to create an account for test. +Since our tests run outside of an account scope, we need to _create_ accounts to use in our tests. The `#[test]` annotation gives us the option to declare those accounts. We use an `admin` account and set it to a random account address (`@0x123`). The function accepts this signer (account) and creates it by using a built-in function to create an account for test. Then we simply go through the flow by: @@ -581,7 +581,7 @@ use std::string; // add this 2. Run: `aptos move test` and `aptos move compile` - all should work without errors. 3. Run: `aptos move publish` 4. Enter `yes` in the prompt. -5. That will compile, simulate and finally publish you module into devnet. You should see a success message: +5. That will compile, simulate and finally publish your module into devnet. You should see a success message: ```rust {