> For the complete documentation index, see [llms.txt](https://whitepaper.gemnode.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://whitepaper.gemnode.io/whitepaper/whitepaper-en/network-infrastructure/wallet-setup.md).
# Wallet Setup
Setup OB Wallet
## Preparation Steps
### Prerequisites[](https://docs.avax.network/quickstart/sending-transactions-with-dynamic-fees-using-javascript#prerequisites)
* Basic familiarity with [Javascript](https://developer.mozilla.org/en-US/docs/Web/JavaScript).
* Basic familiarity with [Node.js](https://nodejs.org/en) and [npm](https://www.npmjs.com/).
* Basic familiarity with [EVM compatibility](https://ethereum.org/en/developers/docs/evm/).
### Installing dependencies[](https://docs.avax.network/quickstart/sending-transactions-with-dynamic-fees-using-javascript#installing-dependencies)
Open the terminal and install the following dependencies in a new folder.
* ethers
* avalanche
* dotenv
```
npm install ethers avalanche dotenv
```
### Setting up Environment and Project[](https://docs.avax.network/quickstart/sending-transactions-with-dynamic-fees-using-javascript#setting-up-environment-and-project)
To send a transaction we need to sign it using our private key. But private key should not be hardcoded in the code, rather must be fetched through some environment variables. Make a `.env` file in the root folder with the following content.
```
PRIVATEKEY=
```
Now make a new file `app.js` in the root folder, which will be our main and only file with the `sendG()` function. Follow the rest of the tutorial by understanding and pasting the provided snippets sequentially in the `app.js` file.
### Setting up Wallet[](https://docs.avax.network/quickstart/sending-transactions-with-dynamic-fees-using-javascript#setting-up-wallet)
A wallet is required for signing transactions with your private key and thus making it valid.
```
// For signing an unsigned transaction
const wallet = new ethers.Wallet(privateKey)
const address = wallet.address
```
## Launching Wallet
*Coming Soon!*
## Adjusting Gas Price
The amount of computation used by a transaction is measured in units of `gas`. Each unit of gas is paid for in GEM at the `gas price` for the transaction. The `gas price` of the transaction is determined by the parameters of the transaction and the `base fee` of the block that it is included in.
To avoid draining the user's wallet due to non-terminating execution through the EVM, transactions are submitted with a `gas limit`, which denotes the maximum units of gas that a particular transaction is allowed to consume.
If a transaction attempts to use more than this limit, then the transaction will revert and still consume and pay for the full `gas limit`. Total fees paid by the user can be calculated as `(gas consumed) * (gas price)`, and is known as `gas fees`. Similarly, maximum gas fees can be calculated as `(gas limit) * (gas price)`.
Originally, transactions could only set a single parameter to define how much they were willing to pay for gas: `gas price`. When dynamic fees were introduced, EIP-1559 style transactions were introduced as well which contain two parameters `maxFeeCap` and `maxPriorityFee` to determine the price a transaction is willing to pay.
With the introduction of dynamic fees, legacy style transactions that only have a single `gas price` parameter can lead to both delayed transactions and overpaying for transactions. Dynamic fee transactions are the solution!
For the dynamic fee algorithm, when a block is produced or verified, we look over the past 10s to see how much gas has been consumed within that window (with an added charge for each block produced in that window) to determine the current network utilization. This window has a target utilization, which is currently set to `15M` gas units. Lastly, there is an added charge if a block is produced faster than the target rate of block production. Currently, the target rate of block production is one block every two seconds, so if a new block is produced one second after its parent, then there is an additional surcharge added into the base fee calculation.
Base price could increase, decrease, or remain the same depending upon the amount of activity on the network in the most recent window. If the total gas in the last few blocks of the window is more, less or the same than the target gas, then the base price will increase, decrease, or remain the same, respectively.
When estimating the base fee for users, we simply look at the currently preferred block and calculate what the base fee would be for a block built on top of that block immediately.
Along with a gas limit, users can now pass 2 values in dynamic fee transactions - `gas fee cap` and `gas tip cap`.
The maximum price per unit of gas, that the user is willing to pay for their transaction is called `gas fee cap`. If the base price for a block is more than the gas fee cap, then the transaction will remain in the transaction pool until the base fee has been changed to be less than or equal to the provided gas fee cap (note: the transaction pool limits the number of pending transactions, so if the number of pending transactions exceeds the configured cap then the transactions with the lowest fees may be evicted from the transaction pool and need to be re-issued).
`Gas tip cap` is the maximum price per unit of gas, that the user is willing to pay above the base price to prioritize their transaction. But the tip is capped by both the gas tip cap as well as the gas fee cap. The actual tip paid above the `base fee` of the block is known as the `effective gas tip`.
```
EffectiveTip = min(MaxFeeCap - BaseFee, GasTipCap)
```
##