diff --git a/docs/1.concepts/web3/near.md b/docs/1.concepts/web3/near.md index 2bc3a0d870c..852d9fd1851 100644 --- a/docs/1.concepts/web3/near.md +++ b/docs/1.concepts/web3/near.md @@ -104,7 +104,7 @@ Throughout this section, we’ve discussed how to call a smart contract from a c Looks simple enough, but there are few gotchas: - In order to provide a call status (success or failure) and a return value to the calling contract, a callback method should be called, so there’s no single activation of ContractA. Instead, an entry method is called first by the user, and then a callback is invoked in response to cross-contract call completion. -- Transaction status is determined by the success or failure of a first method call. For example, if a ContractB.methodB or ContractA.methodACb call fails, the transaction will still be considered successful. This means that to ensure proper rollbacks in case of expected failures, custom rollback code must be written in the ContractA.methodACb, and the callback method itself must not fail at all. Otherwise, smart contract state might be left inconsistent. +- Transaction status is determined by the success or failure of a first function call. For example, if a ContractB.methodB or ContractA.methodACb call fails, the transaction will still be considered successful. This means that to ensure proper rollbacks in case of expected failures, custom rollback code must be written in the ContractA.methodACb, and the callback method itself must not fail at all. Otherwise, smart contract state might be left inconsistent. - Cross-contract calls must have gas attached by the calling contract. Total available gas is attached to a transaction by a calling user, and distributed inside the call chain by contracts. For example, if 15TGas are attached by the user, ContractA may reserve 5TGas for itself and pass the rest to ContractB. All unspent gas will be refunded back to the user. diff --git a/docs/2.develop/contracts/serialization.md b/docs/2.develop/contracts/serialization.md index a5b71603de5..6267ccda376 100644 --- a/docs/2.develop/contracts/serialization.md +++ b/docs/2.develop/contracts/serialization.md @@ -12,7 +12,7 @@ from their complex representation into simpler ones. This process of translating **complex objects into simpler single-value** representations is called **serialization**. NEAR uses two serialization formats: [JSON](https://www.json.org/json-en.html) and [Borsh](https://borsh.io/). -1. [JSON](https://www.json.org/json-en.html) is used to serialize the contract's input/output during a method call +1. [JSON](https://www.json.org/json-en.html) is used to serialize the contract's input/output during a function call 2. [Borsh](https://borsh.io/) is used to serialize the contract's state. --- diff --git a/docs/2.develop/integrate/frontend.md b/docs/2.develop/integrate/frontend.md index 518d8f652d7..596ed2808aa 100644 --- a/docs/2.develop/integrate/frontend.md +++ b/docs/2.develop/integrate/frontend.md @@ -278,7 +278,7 @@ function formatAmount(amount) { NEAR API JS does not limit itself to simply calling methods in a contract. In fact, you can use it to transform your web-app into a rich user experience. While we will not cover these topics in depth, it is important for you to know that with NEAR API JS you can also: - **[Sign and verify messages](https://github.com/near/near-api-js/blob/master/packages/cookbook/utils/verify-signature.js)**: this is very useful to prove that a message was created by the user. -- **[Create batch transactions](https://github.com/near/near-api-js/tree/master/packages/cookbook/transactions/batch-transactions.js)**: this enables to link multiple [actions](/develop/contracts/actions) (e.g. multiple method calls). If one of the transactions fails, then they are all reverted. +- **[Create batch transactions](https://github.com/near/near-api-js/tree/master/packages/cookbook/transactions/batch-transactions.js)**: this enables to link multiple [actions](/develop/contracts/actions) (e.g. multiple function calls). If one of the transactions fails, then they are all reverted. - **[Create accounts](https://github.com/near/near-api-js/tree/master/packages/cookbook/accounts/create-testnet-account.js)**: deploy accounts for your users! Check the [cookbook](/tools/near-api-js/cookbook) to learn how to supercharge your webapp. diff --git a/docs/2.develop/relevant-contracts/ft.md b/docs/2.develop/relevant-contracts/ft.md index d8aecbe5f7c..5a42240ed5f 100644 --- a/docs/2.develop/relevant-contracts/ft.md +++ b/docs/2.develop/relevant-contracts/ft.md @@ -125,7 +125,7 @@ In order to send a fungible token to an account, both the sender and receiver mu
## Attaching FTs to a Call -Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the FT standard enables to attach fungible tokens in a call by using the FT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the FT-contract to do both a transfer and a method call in your name. +Natively, only NEAR tokens (Ⓝ) can be attached to a function calls. However, the FT standard enables to attach fungible tokens in a call by using the FT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the FT-contract to do both a transfer and a function call in your name. diff --git a/docs/2.develop/relevant-contracts/nft.md b/docs/2.develop/relevant-contracts/nft.md index dc6e5955faa..2266a8fe944 100644 --- a/docs/2.develop/relevant-contracts/nft.md +++ b/docs/2.develop/relevant-contracts/nft.md @@ -116,7 +116,7 @@ Implement [events](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) t
## Attaching NFTs to a Call -Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the NFT standard enables to attach a non-fungible tokens in a call by using the NFT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the NFT-contract to do both a transfer and a method call in your name. +Natively, only NEAR tokens (Ⓝ) can be attached to a function calls. However, the NFT standard enables to attach a non-fungible tokens in a call by using the NFT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the NFT-contract to do both a transfer and a function call in your name. diff --git a/docs/3.tutorials/examples/advanced-xcc.md b/docs/3.tutorials/examples/advanced-xcc.md index edeb089008e..79542a87b33 100644 --- a/docs/3.tutorials/examples/advanced-xcc.md +++ b/docs/3.tutorials/examples/advanced-xcc.md @@ -7,7 +7,7 @@ import TabItem from '@theme/TabItem'; import {CodeTabs, Language, Github} from "@site/src/components/codetabs" This example presents 3 instances of complex cross-contract calls. Particularly, it shows: -1. How to batch multiple method calls to a same contract. +1. How to batch multiple function calls to a same contract. 2. How to call multiple contracts in parallel, each returning a different type. 3. Different ways of handling the responses in the callback. diff --git a/docs/3.tutorials/fts/3-circulating-supply.md b/docs/3.tutorials/fts/3-circulating-supply.md index 815c0798fc6..a640336448b 100644 --- a/docs/3.tutorials/fts/3-circulating-supply.md +++ b/docs/3.tutorials/fts/3-circulating-supply.md @@ -47,7 +47,7 @@ src └── storage.rs ``` -In the `internal.rs` file, add the following code to create a method called `internal_deposit` which takes an `AccountId` and a `Balance` and adds the amount to the account's current supply of FTs. +In the `internal.rs` file, add the following code to create a function called `internal_deposit` which takes an `AccountId` and a `Balance` and adds the amount to the account's current supply of FTs. diff --git a/docs/3.tutorials/fts/5.transfers.md b/docs/3.tutorials/fts/5.transfers.md index 42c9bc0be88..555159e1510 100644 --- a/docs/3.tutorials/fts/5.transfers.md +++ b/docs/3.tutorials/fts/5.transfers.md @@ -36,7 +36,7 @@ You'll start by implementing the `ft_transfer` logic which is found in the `src/ There are a couple things to notice here. -1. We've introduced a new method called `assert_one_yocto()`. This method will ensure that the user is signing the transaction with a full access key by requiring a deposit of exactly 1 yoctoNEAR, the smallest possible amount of $NEAR that can be transferred. Since the transfer function is potentially transferring very valuable assets, you'll want to make sure that whoever is calling the function has a full access key. +1. We've introduced a new function called `assert_one_yocto()`. This method will ensure that the user is signing the transaction with a full access key by requiring a deposit of exactly 1 yoctoNEAR, the smallest possible amount of $NEAR that can be transferred. Since the transfer function is potentially transferring very valuable assets, you'll want to make sure that whoever is calling the function has a full access key. 2. We've introduced an `internal_transfer` method. This will perform all the logic necessary to transfer the tokens internally. diff --git a/docs/3.tutorials/nfts/4-core.md b/docs/3.tutorials/nfts/4-core.md index eb2a9161764..748bf1359df 100644 --- a/docs/3.tutorials/nfts/4-core.md +++ b/docs/3.tutorials/nfts/4-core.md @@ -53,7 +53,7 @@ You'll start by implementing the `nft_transfer` logic. This function will transf -There are a couple things to notice here. Firstly, we've introduced a new method called `assert_one_yocto()`. This method will ensure that the user has attached exactly one yoctoNEAR to the call. If a function requires a deposit, you need a full access key to sign that transaction. By adding the one yoctoNEAR deposit requirement, you're essentially forcing the user to sign the transaction with a full access key. +There are a couple things to notice here. Firstly, we've introduced a new function called `assert_one_yocto()`. This method will ensure that the user has attached exactly one yoctoNEAR to the call. If a function requires a deposit, you need a full access key to sign that transaction. By adding the one yoctoNEAR deposit requirement, you're essentially forcing the user to sign the transaction with a full access key. Since the transfer function is potentially transferring very valuable assets, you'll want to make sure that whoever is calling the function has a full access key. diff --git a/docs/3.tutorials/nfts/js/4-core.md b/docs/3.tutorials/nfts/js/4-core.md index 87ba42895c9..de75cf9a0b6 100644 --- a/docs/3.tutorials/nfts/js/4-core.md +++ b/docs/3.tutorials/nfts/js/4-core.md @@ -60,7 +60,7 @@ You'll start by implementing the `nft_transfer` logic. This function will transf -There are a couple things to notice here. Firstly, we've introduced a new method called `assertOneYocto()`. This method will ensure that the user has attached exactly one yoctoNEAR to the call. If a function requires a deposit, you need a full access key to sign that transaction. By adding the one yoctoNEAR deposit requirement, you're essentially forcing the user to sign the transaction with a full access key. +There are a couple things to notice here. Firstly, we've introduced a new function called `assertOneYocto()`. This method will ensure that the user has attached exactly one yoctoNEAR to the call. If a function requires a deposit, you need a full access key to sign that transaction. By adding the one yoctoNEAR deposit requirement, you're essentially forcing the user to sign the transaction with a full access key. Since the transfer function is potentially transferring very valuable assets, you'll want to make sure that whoever is calling the function has a full access key. diff --git a/docs/5.api/rpc/contracts.md b/docs/5.api/rpc/contracts.md index 9cf06c60742..f4fa9ebc347 100644 --- a/docs/5.api/rpc/contracts.md +++ b/docs/5.api/rpc/contracts.md @@ -1585,7 +1585,7 @@ Here is the exhaustive list of the error variants that can be returned by `call_ CONTRACT_EXECUTION_ERROR - The execution of the view method call failed (crashed, run out of the default 200 TGas limit, etc) + The execution of the view function call failed (crashed, run out of the default 200 TGas limit, etc)
  • Check error.cause.info for more details
    • diff --git a/docs/7.primitives/ft.md b/docs/7.primitives/ft.md index 38e02873e3a..9f085563251 100644 --- a/docs/7.primitives/ft.md +++ b/docs/7.primitives/ft.md @@ -165,7 +165,7 @@ To send FT to another account you will use the `ft_transfer` method, indicating --- ## Attaching FTs to a Call -Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the FT standard enables to attach fungible tokens in a call by using the FT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the FT-contract to do both a transfer and a method call in your name. +Natively, only NEAR tokens (Ⓝ) can be attached to a function calls. However, the FT standard enables to attach fungible tokens in a call by using the FT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the FT-contract to do both a transfer and a function call in your name. Let's assume that you need to deposit FTs on Ref Finance. diff --git a/docs/7.primitives/nft.md b/docs/7.primitives/nft.md index e85a3e0bda4..01770310fb5 100644 --- a/docs/7.primitives/nft.md +++ b/docs/7.primitives/nft.md @@ -156,7 +156,7 @@ In both cases, it is necessary to invoke the `nft_transfer` method, indicating t --- ## Attaching NFTs to a Call -Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the NFT standard enables to attach a non-fungible tokens in a call by using the NFT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the NFT-contract to do both a transfer and a method call in your name. +Natively, only NEAR tokens (Ⓝ) can be attached to a function calls. However, the NFT standard enables to attach a non-fungible tokens in a call by using the NFT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the NFT-contract to do both a transfer and a function call in your name. diff --git a/docs/bos/queryapi/context.md b/docs/bos/queryapi/context.md index 439cb544e15..5390f6412fa 100644 --- a/docs/bos/queryapi/context.md +++ b/docs/bos/queryapi/context.md @@ -127,7 +127,7 @@ Except for [upsert](#upsert), all of the below methods are used in [social_feed_ ### Insert -This method allows inserting one or more objects into the table preceding the method call. The inserted objects are then returned back with all of their information. Later on, we may implement returning specific fields but for now, we are returning them all. This goes for all methods. +This method allows inserting one or more objects into the table preceding the function call. The inserted objects are then returned back with all of their information. Later on, we may implement returning specific fields but for now, we are returning them all. This goes for all methods. #### Input diff --git a/docs/bos/tutorial/hello-near.md b/docs/bos/tutorial/hello-near.md index c77581bb9cc..3ba7f3cd01e 100644 --- a/docs/bos/tutorial/hello-near.md +++ b/docs/bos/tutorial/hello-near.md @@ -45,7 +45,7 @@ To modify the greeting, we simply need to use `Near.call` to call the `set_greet Lets create it in two steps: 1. Build the HTML that will be rendered -2. Add the logic to handle the method call +2. Add the logic to handle the function call