- {/* Language tabs */}
+ {/* Language tabs (plain label when there is only one language) */}
+ {langList.length === 1 ? (
+
diff --git a/tools/sdk.mdx b/tools/sdk.mdx
index 5b5bc6a552b..111b1009af5 100644
--- a/tools/sdk.mdx
+++ b/tools/sdk.mdx
@@ -1,78 +1,54 @@
---
title: SDK Libraries
icon: package
-description: "Choose an SDK to start building contracts."
+description: "The Rust SDK for building smart contracts."
---
-The NEAR SDK is a library that allows you to develop smart contracts. Currently, there are two versions of the NEAR SDK: one for Rust and one for JavaScript.
-
-
-We **strongly recommend using the [Rust SDK](https://docs.rs/near-sdk/latest/near_sdk/)** for production contracts. Rust provides the most mature tooling, best performance, and the strongest safety guarantees when handling real assets on-chain. The JavaScript SDK is a great option for prototyping and learning.
-
+The NEAR SDK for Rust ([near-sdk-rs](https://github.com/near/near-sdk-rs)) is the official library for developing smart contracts. Rust provides the most mature tooling, best performance, and the strongest safety guarantees when handling real assets on-chain.
The best place to start learning is our [QuickStart Guide](/smart-contracts/quickstart).
-
-
- Rust SDK reference documentation.
-
-
- JavaScript SDK reference documentation.
-
-
+
+ Rust SDK reference documentation.
+
## Smart contracts on NEAR
-This is how a smart contract written in Rust and JavaScript using the NEAR SDK looks like:
-
-
-
- ```js
- @NearBindgen({})
- class HelloNear {
- greeting: string = 'Hello';
-
- @view({}) // This method is read-only and can be called for free
- get_greeting(): string {
- return this.greeting;
- }
-
- @call({}) // This method changes the state, for which it costs gas
- set_greeting({ greeting }: { greeting: string }): void {
- near.log(`Saving greeting ${greeting}`);
- this.greeting = greeting;
- }
+This is how a smart contract written in Rust using the NEAR SDK looks like:
+
+```rust
+#[near(contract_state)]
+pub struct Contract {
+ greeting: String,
+}
+
+impl Default for Contract {
+ fn default() -> Self {
+ Self { greeting: "Hello".to_string(), }
}
- ```
-
-
- ```rust
- #[near(contract_state)]
- pub struct Contract {
- greeting: String,
+}
+
+#[near]
+impl Contract {
+ pub fn get_greeting(&self) -> String {
+ self.greeting.clone()
}
- impl Default for Contract {
- fn default() -> Self {
- Self { greeting: "Hello".to_string(), }
- }
+ pub fn set_greeting(&mut self, greeting: String) {
+ self.greeting = greeting;
}
+}
+```
- #[near]
- impl Contract {
- pub fn get_greeting(&self) -> String {
- self.greeting.clone()
- }
+## Community SDKs
- pub fn set_greeting(&mut self, greeting: String) {
- self.greeting = greeting;
- }
- }
- ```
-
-
+Since NEAR contracts compile to WebAssembly, the community maintains SDKs for other languages. They are great for prototyping and learning, but are not covered in this documentation:
+
+- [JavaScript / TypeScript SDK (near-sdk-js)](https://github.com/near/near-sdk-js)
+- [Python SDK (near-sdk-py)](https://github.com/r-near/near-sdk-py)
+- [Go SDK (near-sdk-go)](https://github.com/vlmoon99/near-sdk-go)
## Ready to start developing?
@@ -84,7 +60,4 @@ We have a section dedicated to [tutorials and examples](/smart-contracts/tutoria
## Reference docs
-If you need to find a specific function signature, or understand the SDK structs and classes, visit the SDK-specific pages:
-
-- [Rust SDK](https://docs.rs/near-sdk/latest/near_sdk/)
-- [JavaScript SDK](https://near.github.io/near-sdk-js/)
+If you need to find a specific function signature, or understand the SDK structs and classes, visit the [Rust SDK reference](https://docs.rs/near-sdk/latest/near_sdk/).
diff --git a/web3-apps/tutorials/mastering-near/0-intro.mdx b/web3-apps/tutorials/mastering-near/0-intro.mdx
index b7e173f2fda..e9608a01c60 100644
--- a/web3-apps/tutorials/mastering-near/0-intro.mdx
+++ b/web3-apps/tutorials/mastering-near/0-intro.mdx
@@ -33,41 +33,23 @@ Before starting, make sure to set up your development environment!
-
-
- ```bash
- # Install Node.js using nvm (more option in: https://nodejs.org/en/download)
- curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
- nvm install latest
+```bash
+# Install Rust: https://www.rust-lang.org/tools/install
+curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
- # Install the NEAR CLI to deploy and interact with the contract
- curl --proto '=https' --tlsv1.2 -LsSf https://github.com/near/near-cli-rs/releases/latest/download/near-cli-rs-installer.sh | sh
- ```
+# Contracts will be compiled to wasm, so we need to add the wasm target
+rustup target add wasm32-unknown-unknown
-
+# Install the NEAR CLI to deploy and interact with the contract
+curl --proto '=https' --tlsv1.2 -LsSf https://github.com/near/near-cli-rs/releases/latest/download/near-cli-rs-installer.sh | sh
-
+# Install cargo near to help building the contract
+curl --proto '=https' --tlsv1.2 -LsSf https://github.com/near/cargo-near/releases/latest/download/cargo-near-installer.sh | sh
+```
- ```bash
- # Install Rust: https://www.rust-lang.org/tools/install
- curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
- # Contracts will be compiled to wasm, so we need to add the wasm target
- rustup target add wasm32-unknown-unknown
-
- # Install the NEAR CLI to deploy and interact with the contract
- curl --proto '=https' --tlsv1.2 -LsSf https://github.com/near/near-cli-rs/releases/latest/download/near-cli-rs-installer.sh | sh
-
- # Install cargo near to help building the contract
- curl --proto '=https' --tlsv1.2 -LsSf https://github.com/near/cargo-near/releases/latest/download/cargo-near-installer.sh | sh
- ```
-
-
-
-
-
-We will be using [NEAR CLI](/tools/cli) to interact with the blockchain through the terminal, and you can choose between JavaScript and Rust to write the contract.
+We will be using [NEAR CLI](/tools/cli) to interact with the blockchain through the terminal, and Rust to write the contract.
---
diff --git a/web3-apps/tutorials/mastering-near/1.1-basic.mdx b/web3-apps/tutorials/mastering-near/1.1-basic.mdx
index add5341e043..c18ef229a8c 100644
--- a/web3-apps/tutorials/mastering-near/1.1-basic.mdx
+++ b/web3-apps/tutorials/mastering-near/1.1-basic.mdx
@@ -25,33 +25,17 @@ Make sure to read the [Prerequisites](./0-intro) section and install the necessa
## Cloning the contract
-To get started we'll clone the [tutorial's repository](https://github.com/near-examples/auctions-tutorial) from GitHub. The repository contains the same smart contracts written in JavaScript (`./contract-ts`) and Rust (`./contract-rs`).
+To get started we'll clone the [tutorial's repository](https://github.com/near-examples/auctions-tutorial) from GitHub. The repository contains the smart contracts written in Rust (`./contract-rs`).
-Navigate to the folder of the language you prefer, and then to the `01-basic-auction` folder.
+Navigate to the `contract-rs` folder, and then to the `01-basic-auction` folder.
-
-
+```bash
+git clone git@github.com:near-examples/auctions-tutorial.git
- ```bash
- git clone git@github.com:near-examples/auctions-tutorial.git
+cd contract-rs/01-basic-auction
+```
- cd contract-ts/01-basic-auction
- ```
-
-
-
-
-
- ```bash
- git clone git@github.com:near-examples/auctions-tutorial.git
-
- cd contract-rs/01-basic-auction
- ```
-
-
-
-
**Frontend**
@@ -66,53 +50,26 @@ The repository also contains a frontend application that interacts with the cont
The contract allows users to place bids using `$NEAR` tokens and keeps track of the highest bidder. Lets start by looking at how we define the contract's state, this is, the data that the contract will store.
-
-
-
-
-
-
- #### Decorator
- The first thing to notice is that the main class of the contract is marked using the `@NearBindgen` decorator, which allows also to further specify that the contract **must be initialized** before being used.
- #### Storage (aka State)
- Another important information revealed by the code is that a contract can store different types of data, in this case:
+
- - `highest_bid` is an instance of a `Bid` which stores:
- - `bid`: a `BigInt` representing an amount of `$NEAR` tokens in `yoctonear` (`1Ⓝ = 10^24 yⓃ`)
- - `bidder`: an `AccountId` that represents which account placed the bid
- - `auction_end_time` a `BigInt` representing a `unix timestamp` in **nanoseconds**
- - `auctioneer` an `AccountId` that states who can withdraw the funds at the end of the auction
- - `claimed` a `boolean` that tracks if the auctioneer has claimed the funds
+#### Macros
+A first thing to notice is the use of the `#[near(contract_state)]` macro to denote the main structure and derive the `PanicOnDefault` to specify that the contract **must be initialized** before being used.
-
+We also use the `#[near(serializers = [json, borsh])]` macro to enable both `borsh` and `JSON` (de)serialization of the `Bid` structure. As a rule of thumb: use the `json` serializer for structs that will be used as input / output of functions, and `borsh` for those that will be saved to state.
-
+#### Storage (aka State)
+Another important information revealed by the code is that the contract can store different types of data.
-
+- `highest_bid` is an instance of a `Bid` which stores:
+ - `bid`: a `NearToken` which simplifies handling `$NEAR` token amounts
+ - `bidder`: the `AccountId` that placed the bid
+- `auction_end_time` is a `U64` representing a `unix timestamp` in **nanoseconds**
+- `auctioneer` an `AccountId` that states who can withdraw the funds at the end of the auction
+- `claimed` a `boolean` that tracks if the auctioneer has claimed the funds
- #### Macros
- A first thing to notice is the use of the `#[near(contract_state)]` macro to denote the main structure and derive the `PanicOnDefault` to specify that the contract **must be initialized** before being used.
-
- We also use the `#[near(serializers = [json, borsh])]` macro to enable both `borsh` and `JSON` (de)serialization of the `Bid` structure. As a rule of thumb: use the `json` serializer for structs that will be used as input / output of functions, and `borsh` for those that will be saved to state.
-
- #### Storage (aka State)
- Another important information revealed by the code is that the contract can store different types of data.
-
- - `highest_bid` is an instance of a `Bid` which stores:
- - `bid`: a `NearToken` which simplifies handling `$NEAR` token amounts
- - `bidder`: the `AccountId` that placed the bid
- - `auction_end_time` is a `U64` representing a `unix timestamp` in **nanoseconds**
- - `auctioneer` an `AccountId` that states who can withdraw the funds at the end of the auction
- - `claimed` a `boolean` that tracks if the auctioneer has claimed the funds
-
-
-
-
**Learn More**
@@ -130,33 +87,16 @@ You can read more about the contract's structure and the type of data it can sto
Lets now take a look at the initialization function, which we need to call to determine the time at which the auction will end.
-
-
-
-
-
-
- #### Decorator
- We denote the initialization function using the `@initialize({ privateFunction: true })` decorator. The `privateFunction:true` denotes that the function can only be called by the account on which the contract is deployed.
-
-
-
+
-
+#### Macros
+We denote the initialization function using the `#[init]` macro. Notice that the initialization function needs to return an instance of `Self`, i.e. the contract's structure.
- #### Macros
- We denote the initialization function using the `#[init]` macro. Notice that the initialization function needs to return an instance of `Self`, i.e. the contract's structure.
+Meanwhile, the `#[private]` denotes that the function can only be called by the account on which the contract is deployed.
- Meanwhile, the `#[private]` denotes that the function can only be called by the account on which the contract is deployed.
-
-
-
-
#### End Time
The end time is represented using a `unix timestamp` in **nano seconds**, and needs to be given as a `String` when calling the initialization function. This is because smart contracts cannot receive numbers larger than `52 bits` and `unix timestamps` are represented in `64 bits`.
@@ -183,29 +123,13 @@ You can read more about the contract's interface in our [contract functions docu
The contract implements four functions to give access to its stored data, i.e. the highest bid so far (the amount and by whom), the time at which the auction ends, the auctioneer, and whether the auction has been claimed.
-
-
-
-
-
-
- Functions that do not change the contract's state (i.e. that only read from it) are called `view` functions, and are decorated using the `@view` decorator.
-
+
-
+Functions that do not change the contract's state (i.e. that only read from it) are called `view` functions and take a non-mutable reference to `self` (`&self`).
-
-
- Functions that do not change the contract's state (i.e. that only read from it) are called `view` functions and take a non-mutable reference to `self` (`&self`).
-
-
-
-
View functions are **free to call**, and do **not require** a NEAR account to sign a transaction in order to call them.
@@ -224,28 +148,14 @@ An auction is not an auction if you can't place a bid! For this, the contract in
The function is quite simple: it verifies if the auction is still active and compares the attached deposit with the current highest bid. If the bid is higher, it updates the `highest_bid` and refunds the previous bidder.
-
-
-
-
+
-
-
-
-
-
-
-
-
-
#### Payable Functions
-The first thing to notice is that the function changes the state, and thus is marked with a `@call` decorator in JS, while taking as input a mutable reference to self (`&mut self`) on Rust. To call this function, a NEAR account needs to sign a transaction and expend GAS.
+The first thing to notice is that the function changes the state, and thus takes as input a mutable reference to self (`&mut self`). To call this function, a NEAR account needs to sign a transaction and expend GAS.
Second, the function is marked as `payable`, this is because by default **functions do not accept `$NEAR` tokens**! If a user attaches tokens while calling a function that is not marked as `payable`, the transaction will fail.
@@ -279,25 +189,11 @@ You can read more about the environment variables, payable functions and which a
You'll notice that the contract has a final function called `claim`, this allows the auctioneer to claim the funds from the contract at the end of the auction. Since, on NEAR, a smart contract account and user account are the same, contracts can still have keys when they are deployed, thus a user could just claim the funds from the contract via a wallet. However, this presents a security issue since by having a key the key holder can take the funds from the contract at any point, maliciously change the contract's state or just delete the contract as a whole. By implementing a `claim` function we can later lock the contract by removing all access keys and have the auctioneer claim the funds via preset conditions via code.
-
-
-
-
-
-
-
-
-
-
-
-
+
-
This function is quite simple it does four things:
1) Checks that the auction has ended (the current timestamp is past the auction end time).
diff --git a/web3-apps/tutorials/mastering-near/1.2-testing.mdx b/web3-apps/tutorials/mastering-near/1.2-testing.mdx
index e252eb2b46f..e74c0def2b9 100644
--- a/web3-apps/tutorials/mastering-near/1.2-testing.mdx
+++ b/web3-apps/tutorials/mastering-near/1.2-testing.mdx
@@ -22,23 +22,11 @@ Unit tests are built into the language and are used to test the contract functio
The first thing our test does is to create multiple accounts with 10 `$NEAR` tokens each and deploy the contract to one of them.
-
-
-
-
- To deploy the contract, we pass the path to the compiled WASM contract as an argument to the test in `package.json`. Indeed, when executing `npm run test`, the command will first compile the contract and then run the tests.
-
-
-
-
+
- Notice that the sandbox compiles the code itself, so we do not need to pre-compile the contract before running the tests.
-
-
+Notice that the sandbox compiles the code itself, so we do not need to pre-compile the contract before running the tests.
---
@@ -46,24 +34,6 @@ The first thing our test does is to create multiple accounts with 10 `$NEAR` tok
To initialize, the contract's account calls itself, invoking the `init` function with an `end_time` set to 60 seconds in the future.
-
-
-
-
-
-
-
-**Time Units**
-
-The contract measures time in **nanoseconds**, for which we need to multiply the result of `Date.now()` (expressed in milliseconds) by `10^6`
-
-
-
-
-
-
-
-
**Time is a String**
@@ -94,25 +62,11 @@ Now that the contract is deployed and initialized, we can start bidding and chec
We first make `alice` place a bid of 1 NEAR, and check that the contract correctly registers the bid. Then, we have `bob` place a bid of 2 NEAR, and check that the highest bid is updated, and that `alice` gets her NEAR refunded.
-
-
-
-
-
-
-
-
-
-
-
-
+
-
#### Checking the balance
It is important to notice how we check if `alice` was refunded. We query her balance after her first bid, and then check if it has increased by 1 NEAR after `bob` makes his bid.
@@ -123,25 +77,11 @@ You might be tempted to check if `alice`'s balance is exactly 10 NEAR after she
When testing we should also check that the contract does not allow invalid calls. The next part checks that the contract doesn't allow for bids with fewer `$NEAR` tokens than the previous to be made.
-
-
-
-
-
-
-
-
+
-
-
-
-
-
---
@@ -150,22 +90,11 @@ The sandbox allows us to fast-forward time, which is useful for testing the cont
After which the auction can now be claimed. Once claimed the test checks that the auctioneer has received the correct amount of `$NEAR` tokens.
-
-
-
-
-
-
+
-
-
-
-
If you review the tests in full you'll see that we also test other invalid calls such as the auctioneer trying to claim the auction before it is over and a user attempting to bid once the auction is over.
@@ -175,29 +104,11 @@ If you review the tests in full you'll see that we also test other invalid calls
Now that we understand what we are testing, let's go ahead and run the tests!
-
-
-
-
- ```bash
- # if you haven't already, install the dependencies
- npm install
-
- # run the tests
- npm run test
- ```
-
-
-
-
-
- ```bash
- cargo test
- ```
-
+```bash
+cargo test
+```
-
All tests should pass, and you should see the output of the tests in the console. If you see any errors, please contact us in the [NEAR Discord](https://near.chat) or through [Telegram](https://t.me/neardev) and we'll help you out!
diff --git a/web3-apps/tutorials/mastering-near/1.3-deploy.mdx b/web3-apps/tutorials/mastering-near/1.3-deploy.mdx
index 174242b5246..bf3c888eaa1 100644
--- a/web3-apps/tutorials/mastering-near/1.3-deploy.mdx
+++ b/web3-apps/tutorials/mastering-near/1.3-deploy.mdx
@@ -46,41 +46,19 @@ The faucet is only available on the testnet network - which is the default netwo
To deploy the contract, you need to compile the contract code into WebAssembly (WASM) and then deploy it to the network
-
-
-
- ```bash
- # compile the contract
- npm run build
-
- # deploy the contract
- near deploy ./build/auction-contract.wasm
-
- # initialize the contract, it finishes in 2 minutes
- TWO_MINUTES_FROM_NOW=$(date -v+2M +%s000000000)
- near call init '{"end_time": "'$TWO_MINUTES_FROM_NOW'", "auctioneer": ""}' --useAccount
- ```
-
-
-
-
-
- ```bash
- # compile the contract using cargo-near
- cargo near build
-
- # deploy the contract
- near deploy ./target/near/auction-contract.wasm
+```bash
+# compile the contract using cargo-near
+cargo near build
- # initialize the contract, it finishes in 2 minutes
- TWO_MINUTES_FROM_NOW=$(date -v+2M +%s000000000)
- near call init '{"end_time": "'$TWO_MINUTES_FROM_NOW'", "auctioneer": ""}' --useAccount
- ```
+# deploy the contract
+near deploy ./target/near/auction-contract.wasm
-
+# initialize the contract, it finishes in 2 minutes
+TWO_MINUTES_FROM_NOW=$(date -v+2M +%s000000000)
+near call init '{"end_time": "'$TWO_MINUTES_FROM_NOW'", "auctioneer": ""}' --useAccount
+```
-
Replace `` with the name of another account, this should not be the same as the contract account as we intend on removing its keys.
diff --git a/web3-apps/tutorials/mastering-near/3.1-nft.mdx b/web3-apps/tutorials/mastering-near/3.1-nft.mdx
index 9a441431e9f..530fc19f8de 100644
--- a/web3-apps/tutorials/mastering-near/3.1-nft.mdx
+++ b/web3-apps/tutorials/mastering-near/3.1-nft.mdx
@@ -13,27 +13,13 @@ No one will enter an auction if there's nothing to win, so let's add a prize. Wh
When we create an auction we need to list the NFT. To specify which NFT is being auctioned off we need the account ID of the NFT contract and the token ID of the NFT. We will specify these when the contract is initialized; amend `init` to add `nft_contract` and `token_id` as such:
-
-
+
-
+Note that `token_id` is of type `TokenId` which is a String type alias that the NFT standards use for future-proofing.
-
-
-
-
-
-
- Note that `token_id` is of type `TokenId` which is a String type alias that the NFT standards use for future-proofing.
-
-
-
-
---
@@ -41,34 +27,18 @@ When we create an auction we need to list the NFT. To specify which NFT is being
When the method `claim` is called the NFT needs to be transferred to the highest bidder. Operations regarding NFTs live on the NFT contract, so we make a cross-contract call to the NFT contract telling it to swap the owner of the NFT to the highest bidder. The method on the NFT contract to do this is `nft_transfer`.
-
-
-
-
-
-
- In near-sdk-js we cannot transfer the NFT and send the `$NEAR` independently so we will chain the promises.
-
+We will create a new file in our source folder named `ext.rs`; here we are going to define the interface for the `nft_transfer` method. We define this interface as a `trait` and use the `ext_contract` macro to convert the NFT trait into a module with the method `nft_transfer`. Defining external methods in a separate file helps improve the readability of our code.
-
+We then use this method in our `lib.rs` file to transfer the NFT.
- We will create a new file in our source folder named `ext.rs`; here we are going to define the interface for the `nft_transfer` method. We define this interface as a `trait` and use the `ext_contract` macro to convert the NFT trait into a module with the method `nft_transfer`. Defining external methods in a separate file helps improve the readability of our code.
-
- We then use this method in our `lib.rs` file to transfer the NFT.
+
+
-
-
-
-
-
-
When calling this method we specify the NFT contract name, that we are attaching 30 Tgas to the call, that we are attaching a deposit of 1 YoctoNEAR to the call, and give the arguments `receiver_id` and `token_id`. The NFT requires that we attach 1 YoctoNEAR for [security reasons](/smart-contracts/security/one_yocto).
@@ -84,31 +54,17 @@ In our contract, we perform no checks to verify whether the contract actually ow
Since we are now dealing with more information in our contract, instead of implementing a function to display each field we'll create a function to display the entire contract object. Since the contract doesn't include large complex data structures like a map displaying the contract state in its entirety is easily done.
-
-
-
-
-
-
-
-
-
-
-
- We add the `serilizers` macro to enable json serialization so the object as a whole can easily be displayed to the frontend without having to output each field individually.
+
-
+We add the `serilizers` macro to enable json serialization so the object as a whole can easily be displayed to the frontend without having to output each field individually.
-
+
-
## Testing with multiple contracts
@@ -118,25 +74,11 @@ In our tests folder, we need the WASM for an NFT contract. For this tutorial, we
To deploy the NFT contract, this time we're going to use `dev deploy` which creates an account with a random ID and deploys the contract to it by specifying the path to the WASM file. After deploying we will initialize the contract with default metadata and specify an account ID which will be the owner of the NFT contract (though the owner of the NFT contract is irrelevant in this example). Default metadata sets information such as the name and symbol of the NFT contract to default values.
-
-
+
-
-
-
-
-
-
-
-
-
-
-
---
@@ -144,25 +86,11 @@ To deploy the NFT contract, this time we're going to use `dev deploy` which crea
To start a proper auction the auction contract should own an NFT. To do this the auction account calls the NFT contract to mint a new NFT providing information such as the image for the NFT.
-
-
-
-
-
-
-
-
+
-
-
-
-
-
---
@@ -170,25 +98,11 @@ To start a proper auction the auction contract should own an NFT. To do this the
After `claim` is called, the test should verify that the auction winner now owns the NFT. This is done by calling `nft_token` on the NFT contract and specifying the token ID which will return the account ID that the token belongs to.
-
-
-
-
-
-
-
-
-
-
-
-
+
-
---
diff --git a/web3-apps/tutorials/mastering-near/3.2-ft.mdx b/web3-apps/tutorials/mastering-near/3.2-ft.mdx
index b79ae22f693..c7347c685be 100644
--- a/web3-apps/tutorials/mastering-near/3.2-ft.mdx
+++ b/web3-apps/tutorials/mastering-near/3.2-ft.mdx
@@ -13,25 +13,11 @@ To further develop this contract we will introduce another primitive: [fungible
We want to only accept bids in one type of fungible token; accepting many different FTs would make the value of each bid difficult to compare. We're also going to adjust the contract so that the auctioneer can specify a starting bid amount for the auction.
-
-
+
-
-
-
-
-
-
-
-
-
-
-
---
@@ -43,107 +29,46 @@ When we were making bids in `$NEAR` tokens we would call the auction contract di
The `ft_on_transfer` method always has the same interface; the FT contract will pass it the `sender`, the `amount` of FTs being sent and a `msg` which can be empty (which it will be here) or it can contain some information needed by the method (if you want to send multiple arguments in msg it is best practice to deliver this in JSON then parse it in the contract). The method returns the number of tokens to refund the user, in our case we will use all the tokens attached to the call for the bid unless the contract panics in which case the user will automatically be refunded their FTs in full.
-
-
-
-
-
-
-
-
-
-
+
-
-
-
We need to confirm that the user is attaching fungible tokens when calling the method and that they are using the right FT, this is done by checking the predecessor's account ID. Since it's the FT contract that directly calls the auction contract, the `predecessor` is now the account ID of the FT contract.
-
-
-
-
-
-
-
-
+
-
-
-
-
-
The bidder's account ID is now given by the argument `sender_id` and the bid amount is passed as an argument named `amount`.
-
-
-
-
-
-
+
-
-
-
-
-
-
-
When we want to return the funds to the previous bidder we now make a cross-contract call to the FT contract.
-
-
-
-
-
-
-
- In JavaScript, we have to return the Promise to transfer the FTs but we also need to return how much to refund the user. So after transferring the FTs, we make a `callback` to our own contract to resume the contract flow. Note that the callback is private so it can only be called by the contract. We return 0 because the method uses all the FTs in the call.
-
-
-
-
-
-
-
- We then return 0 because the method uses all the FTs in the call.
+
+
-
+ We then return 0 because the method uses all the FTs in the call.
-
+
-
- If the call was to fail the FT contract will automatically refund the user their FTs.
+If the call was to fail the FT contract will automatically refund the user their FTs.
@@ -159,27 +84,11 @@ When we want to return the funds to the previous bidder we now make a cross-cont
When the auction is complete we need to send the fungible tokens to the auctioneer when we send the NFT to the highest bidder, we implement a similar call as when we were returning the funds just changing the arguments.
-
-
+
-
-
- In JavaScript, since we need to return each cross-contract call we chain the NFT and FT transfer.
-
-
-
-
-
-
-
-
-
-
---
@@ -189,25 +98,11 @@ Just as with the NFT contract, we will deploy an FT contract in the sandbox test
When the contract is deployed it is initialized with `new_default_meta` which sets the token's metadata, including things like its name and symbol, to default values while requiring the owner (where the token supply will sent), and the total supply of the token.
-
-
-
-
-
-
+
-
-
-
-
-
-
-
---
@@ -217,25 +112,11 @@ For one to receive fungible tokens, first their account ID must be [registered](
In our tests, since we are creating a new fungible token and new accounts we will actually have to register every account that will interact with FTs.
-
-
-
-
-
-
+
-
-
-
-
-
-
-
---
@@ -243,28 +124,14 @@ In our tests, since we are creating a new fungible token and new accounts we wil
Then we will transfer the bidders FTs so they can use them to bid. A simple transfer of FTs is done using the method `ft_transfer` on the FT contract.
-
-
-
-
+
+
-
-
-
-
-
-
-
-
-
-
---
@@ -272,28 +139,14 @@ Then we will transfer the bidders FTs so they can use them to bid. A simple tran
As stated previously, to bid on the auction the bidder now calls `ft_transfer_call` on the FT contract which subsequently calls the auction contract's `ft_on_transfer` method with fungible tokens attached.
-
-
-
-
-
-
-
-
-
-
-
+
+
-
-
-
---
@@ -301,28 +154,14 @@ As stated previously, to bid on the auction the bidder now calls `ft_transfer_ca
Previously, to check a user's `$NEAR` balance, we pulled the details from their account. Now we are using FTs we query the balance on the FT contract using `ft_balance_of`, let's check that the contract's balance increased by the bid amount and the user's balance decreased by the bid amount.
-
-
-
-
-
-
-
-
-
-
-
+
+
-
-
-
---
@@ -332,25 +171,11 @@ If we make a lower bid than the previous this will cause the auction contract to
Previous to this, Bob made a bid of 60,000 and Alice was returned her bid bringing her balance back up to 150,000. Now when Alice makes an invalid of 50,000 Alice's balance should remain at 150,000 and the contract should remain at a balance of 60,000.
-
-
-
-
-
-
-
-
+
-
-
-
-
-
---
@@ -378,27 +203,12 @@ When creating an application there are numerous ways to structure it. Here, we h
In such case, the Contract struct would be a map of auctions. We would implement a method to create a new auction by adding an entry to the map with the specific details of that individual auction.
-
-
-
-
- ```javascript
- class Contract {
- auctions: UnorderedMap
- ```
-
-
-
-
- ```rust
- pub struct Contract {
- auctions: IterableMap
- ```
-
-
+```rust
+pub struct Contract {
+ auctions: IterableMap
+```
-
However, this architecture could be deemed less secure since if a bad actor were to gain access to the contract they would have access to every auction instead of just one.
diff --git a/web3-apps/tutorials/mastering-near/4-factory.mdx b/web3-apps/tutorials/mastering-near/4-factory.mdx
index d9867a14513..0028f0c89b5 100644
--- a/web3-apps/tutorials/mastering-near/4-factory.mdx
+++ b/web3-apps/tutorials/mastering-near/4-factory.mdx
@@ -10,8 +10,6 @@ Since an auction contract hosts a single auction, each time you would like to ho
Luckily for us, there is already a [factory contract example](https://github.com/near-examples/factory-rust)! We will fork this example and slightly modify it to suit our use case. If you would like to learn more about how the factory contract works, you can take a look at the [associated documentation](/smart-contracts/tutorials/factories/factory#generic-factory).
-The factory example only comes in rust since, currently, the JavaScript SDK does not allow you to embed the WASM file in the contract. This is a limitation of the SDK and not the blockchain itself.
-
---
## Changing the default contract