diff --git a/docs/3.tutorials/auction/2.1-frontend.md b/docs/3.tutorials/auction/2.1-frontend.md
index 116beb5524..b652b95bae 100644
--- a/docs/3.tutorials/auction/2.1-frontend.md
+++ b/docs/3.tutorials/auction/2.1-frontend.md
@@ -3,8 +3,14 @@ id: creating-a-frontend
title: Creating a Frontend
---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import {Github, Language} from "@site/src/components/codetabs"
+
Now that we have successfully created a contract, it's time to build a frontend to provide a user-friendly interface for interacting with it. Up until now, we have been using the CLI to send transactions and view the contract's state. However, frontends offer a more intuitive way for end users to interact with the contract. They can display all the relevant information in one place, allow users to make calls with a simple button click, and only require a wallet as a prerequisite.
+---
+
## Frontend structure
Navigate to the auction frontend.
@@ -27,5 +33,143 @@ For starters, let's take a look at how the code in the frontend is structured by
| **Navigation.jsx** | A component that contains a button to sign users in and out of wallets |
| **Bid.jsx** | A component allowing a user to make a bid |
| **LastBid.jsx** | A component that displays the highest bid and when the highest bid will next refresh |
-| **AuctionItem.jsx** | A component that displays information about the NFT being auctioned |
| **Timer.jsx** | A component that shows how long till the auction is over, or, if over, displays a button to claim the auction and then states the auction is over
+
+---
+
+## Specifying the contract
+
+We have a config file that specifies the contract name of the auction that the frontend will interact with. There has been an example auction contract deployed and sepcfiied already but feel free to change the contract to your own auction contract you deployed.
+
+
+
+
+
+---
+
+## Setting up wallets
+
+To be able to fully interact with the contract - send bids and claim the auction - you'll need a `wallet` to sign transactions. Wallets securely store your private keys and allow you to sign transactions without exposing your private key to the frontend. The wallet selector allows users to choose between a selection of wallets.
+
+We abstract the wallet selector in our `near.js` file by exposing methods to complete various tasks. Feel free to [explore the file](https://github.com/near-examples/auctions-tutorial/blob/reorg-auction/frontends/01-frontends/01-frontend/src/wallets/near.js) to understand fully how the wallet selector is implemented.
+
+The wallet object is initiated in the `app.js` file and its added to the global context along with the account that is signed in to make it easier to access anywhere in the application.
+
+
+
+
+
+
+:::tip Access keys
+
+On NEAR, in additional to normal full access keys, we have `function-call access keys` that are given to applications to allow them to sign `non-payable` transactions on behalf of the user. This is so the wallet doesn't have to pop up for each non critical transaction, improving the user experience. When creating the wallet object you can decide to create an access key for the application to use. However, in this example we opt out since the main function - `bid` - we'll be calling is `payable`.
+
+You can read further about NEAR's key model [here](../../1.concepts/protocol/access-keys.md).
+
+:::
+
+We add a sign-in and sign-out button in the `navigation` component to call the respective methods in the `near.js` file.
+
+
+
+
+
+
+---
+
+## Displaying the highest bid
+
+To get the highest bid from the auction and who made it we call `get_highest_bid`. Since this method returns the highest bid in `yoctoNEAR` we divide by `10^24` to get the amount in NEAR.
+
+
+
+
+
+
+In the wallet file, you'll see that we make a query to the RPC provider, since we are not signing a transaction the wallet isn't required here. Here we are using https://rpc.testnet.near.org but note there are [many different providers available](../../5.api/rpc/providers.md). We are querying the RPC with optimistic finality, which queries the latest block recorded on the node. Alternatively, one could use final finality where the block has been validated by at least 66% of the validators on the network but this will provide slightly delayed information (only by a couple of seconds).
+
+We then pass the information about the highest bidder into the `LastBid` component to display the bid amount and the bidder's account Id.
+
+
+
+
+
+
+---
+
+## Updating the highest bid
+
+We want to know the highest bid at all times, someone else could have placed a higher bid since the page was loaded. To solve this we fetch the contract information every 20 seconds using `setInterval` and update the highest bid if it has changed. In reality you would want to refresh the bid amount more requently but for the sake of saving on RPC calls we are doing it every 20 seconds.
+
+
+
+
+
+---
+
+## Auction end time
+
+The contract stores the end time of the auction in the number of nanoseconds since the Unix epoch (1 January 1970 00:00:00 UTC). In our frontend we will display the time left in days, hours, minutes, and seconds.
+
+
+
+
+
+---
+
+## Making a bid
+
+To make a bid we make a call to the contract using the `bid` method. We specify the deposit amount in `yoctoNEAR` which will be the bid amount. The input box will take the bid amount in NEAR so we multiply by `10^24` to get the correct amount to send. We also specify the amount of gas to attatch to the transaction, here we are attaching 30Tgas which is more than enough for the transaction to go through, we are refuned any unused gas anwyway.
+
+Here, since the user is changing the state of the contract, not just viewing it, the user needs to sign the transaction. Thus the wallet will pop up displaying the transaction details.
+
+
+
+
+
+
+---
+
+## Claiming the auction
+
+Once the auction is over (the current time is greater than the end time) the auction can be claimed. At this point, the timer will be hidden and a button to claim the auction will be displayed. Once clicked the `claim` method will be called on the auction contract to send the highest bidder the NFT and the auctioneer the FTs.
+
+
+
+
+
+---
+
+## Conclusion
+
+In this part of the tutorial, we have implemented a simple frontend for a NEAR contract. Along the way, you have learned how to use the wallet selector to sign the user in and out, how to view the contract’s state, how to sign and send transactions.
+
+While we can see the highest bid, we may want to see the auction's bidding history. Since the contract only stores the most recent bid (to reduce storage costs), we need to use an indexer to pull historical data. In the [next part](./2.2-indexing.md) of the tutorial, we'll look at querying historical data using an API endpoint.
diff --git a/docs/3.tutorials/auction/3.3-new-frontend.md b/docs/3.tutorials/auction/3.3-new-frontend.md
index b61901d0e4..6f36cdabb9 100644
--- a/docs/3.tutorials/auction/3.3-new-frontend.md
+++ b/docs/3.tutorials/auction/3.3-new-frontend.md
@@ -146,6 +146,7 @@ We want to know the highest bid at all times, someone else could have placed a h
url="https://github.com/near-examples/auctions-tutorial/blob/reorg-auction/frontend/src/pages/index.js#L41-L55"
start="41" end="55" />
+
---
## Auction end time
@@ -157,6 +158,7 @@ The contract stores the end time of the auction in the number of nanoseconds sin
url="https://github.com/near-examples/auctions-tutorial/blob/reorg-auction/frontend/src/components/Timer.jsx#L11-L35"
start="11" end="35" />
+
---
## Displaying the NFT