Learn to build on Solana with Figment Learn

Solana 101

Learn to build on Celo with Figment Learn

Celo 101

Learn to build on NEAR with Figment Learn

NEAR 101

Learn to build on Avalanche with Figment Learn

Avalanche 101

Learn to build on Secret with Figment Learn

Secret 101

Learn to build on Polygon with Figment Learn

Polygon 101

Learn to build on Pyth with Figment Learn

Pyth 101

Learn to build on Ceramic with Figment Learn

Ceramic 101

Learn how to index data from NEAR using The Graph

The Graph + NEAR

Build a blog publishing platform that stores content on Arweave and mints a proof-of-ownership NFT that can be transferred by the author

Build a Mirror Clone

Learn to build on Polkadot with Figment Learn

Polkadot 101

Learn to build on The Graph with Figment Learn

The Graph 101

Build a crypto wallet for the Solana blockchain by leveraging the @solana/web3.js Javascript library to access accounts, fetch data, and transfer tokens

Build a Solana Wallet

Learn to build on Tezos with Figment Learn

Tezos 101

The Graph

Secret

Solana

Tezos

Avalanche

Celo

Polygon

Near

Polkadot

Pyth

Ceramic

1 hour

1.5 hours

2 hours +

Beginner

Intermediate

JS/TS

Solidity

React

Truffle

Javascript

Rust

Arweave

Hardhat

Next.js

Typescript

Time Commitment

Difficulty

Programming Language

Technology

We no longer host the Pathway pages on this website, the content has moved to the `learn-web3-dapp` repository at <https://github.com/figment-networks/learn-web3-dapp#-get-started>.

The workflow for Pathways is easy to follow:

- Using the `learn-web3-dapp` code repository, you will be running a local development server (`yarn dev`)
- Each Pathway is accessible from the main page displayed when the development server is running
- Once you begin a Pathway, your completion progress is saved in the local storage of your web browser
- Each Pathway has a similar goal: To guide you through using various code libraries to work with different parts of the web3 stack
- Many of the individual steps of a Pathway provide you with coding challenges, so that you can learn by doing
- You will need to complete the code as explained in the instructions before moving on to the next step
- All of the coding challenges have solutions which are blurred until you click on them, to prevent you from being stuck
- Once you have completed a Pathway, you should have a working knowledge of that protocol which will help you tackle larger projects

For less experienced developers or for anybody who wants to dive in without needing to set up a development environment, **[we recommend using Gitpod](https://gitpod.io/#https://github.com/figment-networks/learn-web3-dapp)** to work with the `learn-web3-dapp` project (this requires you to have a GitHub account to sign in). Gitpod can save you a considerable amount of time, as you don't have to install dependencies or set up any software - everything just works! Gitpod provides you with a fully functional Visual Studio Code editor running in your browser, so you can jump right in. This is what it looks like: 

![Gitpod UI](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/assets/gitpod-firstlook.png?raw=true)

If you are an experienced developer, or if you prefer to use a different code editor, [cloning the repo locally](https://github.com/figment-networks/learn-web3-dapp#-clone-locally) is still possible, however you might encounter various system configuration issues depending on how your local environment is set up. It will be more difficult to develop on a Windows system than on Linux or MacOS, and there are also some known issues with developing Solana programs on Windows. It is strongly recommended to use the [Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/install#manual-installation-steps) (WSL) if you are running Windows 10. 

If you are cloning the repo locally, a minimum of **NodeJS version 14.17 is required**. Some of the Pathways will require use of the [Rust toolchain](https://rustup.rs/). If you are developing on Linux, you will want to make sure you have the [build-essential](https://itsfoss.com/build-essential-ubuntu/) package installed, as the `cc` linker is required for compiling Solana programs.

Get the balance

Deploy a smart contract

Introduction

Setup the project

🎓 Pathway complete!

# What is Polkadot?

Polkadot enables scalability by allowing specialized blockchains to communicate with each other in a secure, trust-free environment.

Polkadot is built to connect and secure unique blockchains, whether they be public, permission-less networks, private consortium chains, or oracles and other Web3 technologies. It enables an internet where independent blockchains can exchange information under common security guarantees.

Polkadot is a living network with the core pillars of governance and upgradeability. The network has an advanced suite of governance tools and, using the [WebAssembly](https://webassembly.org/) standard as a "meta-protocol", can autonomously deploy network upgrades. Polkadot adapts to your growing needs without the risks of network forks.

By connecting these dots, Polkadot serves as a foundational part of a decentralized web, where users control their data and are not limited by trust bounds within the network.

## Why build in the Polkadot ecosystem?

Polkadot is a sharded blockchain, meaning it connects several chains together in a single network, allowing them to process transactions in parallel and exchange data between chains with security guarantees.

Developers can build application-specific chains using [Substrate](https://www.substrate.io/) optimized for their unique use case. Here are the advantages of the Substrate framework and the Polkadot ecosystem:

1. Native Polkadot compatibility: Any blockchain built with Substrate will be natively compatible with Polkadot, so when the mainnet comes you can connect to Polkadot as a parachain.
2. Interchain Connectivity: By connecting your blockchain to Polkadot, your blockchain will be able to pass arbitrary messages to other chains in the Polkadot network.
3. Fork-free upgrades: Upgrade your blockchain without a hard fork. Your runtime is a Wasm binary stored on-chain and can be updated using your chain’s governance mechanism.
4. Instant security: Simply by connecting your blockchain to Polkadot, your blockchain will be secured by Polkadot's [pooled security](https://medium.com/polkadot-network/how-polkadot-tackles-the-biggest-problems-facing-blockchain-innovators-1affc1309b0f).
5. Plug-and-play modular framework: Substrate allows you to simply plug in the functionalities you need, while also giving you the freedom to customize as needed.
6. Multiple Languages:** With Substrate, you can write your blockchain logic in any language that can compile to WebAssembly (Rust, C/C++, C#, Go, etc).

## What can you build on Polkadot?

Substrate comes with everything you need to build your blockchain. Use Substrate’s pallets to easily create what you want, or craft your own custom logic. The Polkadot ecosystem already hosts over 100 application-specific blockchains in development, focus on smart contracts, DeFi, IoT, governance, identity, privacy, and more.

# Network Specifications

## Transaction Fees

Polkadot uses a weight-based fee model as opposed to a gas-metering model. As such, fees are charged prior to transaction execution; once the fee is paid (in DOT), nodes will execute the transaction.

Fees on the Polkadot Relay Chain are calculated based on three parameters:

* A per-byte fee (also known as the "length fee")
* A weight fee
* A tip (optional)

The length fee is the product of a constant per-byte fee and the size of the transaction in bytes.

## Transaction Speed & Finality

While custom consensus mechanics can be implemented for your application-specific blockchain, Polkadot's finality protocol finalizes batches of blocks based on availability and validity checks that happen as the proposed chain grows.

The time to finality varies with the number of checks that need to be performed (and invalidity reports cause the protocol to require extra checks). The expected time to finality is 12-60 seconds on the relay chain.

## Languages supported

Polkadot has [implementations in various programming languages](https://wiki.polkadot.network/docs/en/learn-implementations) ranging from Rust to JavaScript. Currently, the leading implementation is built in Rust and built using the Substrate framework.

With Substrate, you can write your blockchain logic in any language that can compile to WebAssembly (Rust, C/C++, C#, Go, etc).

## EVM compatibility

Substrate EVM will allow Substrate-based blockchains, including Polkadot parachains, to host a nearly-complete instance of the Ethereum state transition function on-chain, alongside any additional Substrate modules as required for custom functionality.

Existing Solidity applications can be deployed and executed in this environment, and will gain the added benefits of being part of a Substrate-based blockchain.

## Role of the DOT token

DOT serve three key functions in Polkadot:

* to be used for governance of the network,
* to be staked for operation of the network,
* to be bonded to connect a chain to Polkadot as a parachain.

DOT can also serve ancillary functions by virtue of being a transferrable token. For example, DOT stored in the Treasury can be sent to teams working on relevant projects for the Polkadot network.


What is Polkadot?

Deploy a program

Create storage for the program

Set the storage of a smart contract

Get the storage of a smart contract

Query the subgraph

Generate a keypair

# What is Solana?

Solana is an open-source project implementing a new, high-performance, permissionless blockchain. The Solana Foundation is based in Geneva, Switzerland and maintains the open-source project. Its goal is to provide a platform that enables developers to create DApps without needing to design around performance bottlenecks. Solana features a new timestamp system called Proof-of-History (PoH) that enables automatically ordered transactions. It also uses a Proof of Stake (PoS) consensus algorithm to help secure the network. Additional design goals include sub-second settlement times, low transaction costs, and support for all LLVM compatible smart contract languages.

# **What can you build on Solana?**

Solana offers a highly scalable platform for Web 3 applications which can now unlock mainstream usage. There are already over 150 projects live on Solana, with a majority of DeFi projects, although NFTs, social apps, and games are starting to launch on the network.

# **The Solana network**

* **Transaction Fees** The network Cluster sets transaction fees based on recent processing history. Transaction fees on Solana are estimated at $10 for 1 million transactions.
* **Transaction Speed & Finality** : Solana can manage up to 65,000 transactions per second and block times at 400ms. This makes Solana one of the fastest production blockchain available, and 4,000 times faster than Ethereum.
* **Languages supported** : Solana applications are built on Rust, but also support C and C++.
* **EVM compatibility** : Solana is not EVM compatible but it offers [a bidirectional token bridge](https://solana.com/wormhole) between Solana and Ethereum so projects can move tokenized assets across blockchains.
* **Role of the SOL token** : The token is used to pay for the transaction fees in the network and to reward participant in the Proof of Stake consensus 


# Gentle introduction to Solanas

{% embed url="https://youtu.be/xiJEESddB5A" caption="Say Hello to Solana" %}

{% embed url="https://youtu.be/4dNuMXBjpr0" caption="Solana Core Concepts (Community Video)" %}



What is Solana?

Transfer some MATIC

Define the schema

The Graph hosted service

Transfer some tokens

Connect to Solana

{% hint style="info" %}
Feel Free to skip this section and [start the challenges](https://learn.figment.io/tutorials/setup-the-near-project)
{% endhint %}

------------------------

# What is NEAR?

NEAR is a decentralized application platform that makes blockchain accessible to everyday people who are excited for the future of the Open Web. A web that is more private, more secure, and puts people in control of their money, data, and identity. NEAR’s purpose is to enable community-driven innovation to benefit people around the world.

What makes NEAR special?

1. NEAR is the inevitable evolution of existing platforms 
   1. Bitcoin made digital currency a reality, a global transfer of value programmed on a blockchain. Ethereum took it a step further and made it possible to create basic applications leveraging digital currency on blockchains, but has faced issues with scaling and prohibitive fees.  
   2. NEAR solves these challenges and finally makes building the Open Web possible by introducing a breakthrough sharding design that creates opportunities for innovation never possible in blockchain before. 
2. NEAR is made for the real world 
   1. NEAR is the fastest path to market for builders to create blockchain applications that are as easy to use as they are to build. It uses common development patterns and programming languages that are immediately familiar to web developers. 
   2. NEAR was built with pragmatism of a Silicon Valley tech startup by engineers who have shipped scalable solutions for the world’s leading technology companies. 
   3. NEAR is secure enough for high value assets like Digital Currencies or Identities and performant enough to scale for DeFi or Gaming applications without prohibitively expensive fees or network latency. 
3. NEAR is designed to be interoperable 
   1. NEAR is designed to work with existing blockchain platforms and is easy for existing applications to migrate to. NEAR uses the Ethereum Virtual Machine and Web Assembly so that builders can seamlessly swap from Ethereum to NEAR (and back) on the NEAR Rainbow Bridge to leverage the performance, security, and favorable economics of NEAR without having to rebuild their applications or smart contracts. 
   2. With NEAR, you don’t have to choose between NEAR and Ethereum or commit to only one blockchain. Interoperability and usability across platforms will be key to the mass adoption of blockchain.

NEAR is the first blockchain platform truly built for the real world. It is a builder's fastest path to market to create blockchain applications that are as easy to use as they are to build.

# Why build on NEAR?

**NEAR is easy to learn**. It uses familiar development patterns and languages for portability and ease of access for any web developers.

* “Writing smart contracts on Rust is awesome. It allows you to code error-free and fault-free. It’s a big reason why we chose NEAR. Other blockchains require you to learn less popular programming languages.” - _Carolin Wend, Co-Founder of Mintbase_

**NEAR is versatile**. It's secure enough for high-value assets like money or identity, and performant enough to scale DeFi or Gaming apps. NEAR helps developers avoid high fees and slow speeds to deliver a delightful user experience.

* “Augur gets $1B in volume and users burn $63M in gas fees. Flux gets $1B in volume and users burn only $10k in gas fees.” _Peter Mitchell, CEO of Flux_

**NEAR is by builders for builders**. NEAR is built by a pragmatic team of engineers that have shipped scalable solutions for many of the world’s leading tech companies. They’ve earned the backing of leading investors including Coinbase Ventures, Andressen Horowitz, Pantera Capital and Naval Ravikant.

* “NEAR approached us with a developer-first attitude hellbent on helping creators create seamless and memorable user experiences. We intuitively felt that NEAR could be the silver bullet that ZEST needed.” _Geoff Wellman, Founding Partner, CTO VHS_

**NEAR works with existing blockchain platforms.** Builders can seamlessly swap from Ethereum to NEAR (and back) on the NEAR Rainbow Bridge to leverage the performance, security, and favorable economics of NEAR without having to rebuild their applications. With NEAR, there is no need to choose between chains. Builders and users get the best of both worlds.

**NEAR makes applications easy to use**. In some cases, users don’t realize they’re using a blockchain application. NEAR Accounts combine human-readable names and a flexible contract-based permission structure that enables business models like recurring, free to play, or freemium that were never before possible using blockchain applications.

**NEAR is fast and future proof**. The unique sharding techniques implemented to enable the NEAR protocol to maintain consensus while splitting the network into multiple pieces. This means that throughput and speed will increase exponentially as the number of nodes on the network increases. There is no theoretical limit on the NEAR network’s capacity. As the Open Web grows, NEAR scales to meet it.

# What can you build on NEAR?

1. Open (decentralized) Finance: NEAR provides both a synchronous environment for atomic transactions, which benefits fast-moving financial applications like decentralized exchanges, and an asynchronous environment which allows every other application to hook into these critical financial rails. This will be possible with the upcoming EVM support.  
2. Open Web: because NEAR is basically the “builder’s blockchain”, it has been optimized to provide substantial flexibility and performance for developers to build great experiences for their end users. This means that consumer-facing blockchain-backed apps are finally possible and the use cases of the Open Web can finally be realized: 
   1. Prediction markets -- markets like Augur have been handicapped by the difficulty of building smooth user experiences on Ethereum.  Apps like [Flux](https://flux.market) on NEAR provide much more user-friendly ways to set up programmatically enforceable bets with fast, easy payments. 
   2. NFT marketplaces -- marketplaces like [Mintbase](https://mintbase.io), which transferred from Ethereum, allow creators of unique digital assets to easily implement marketplaces to buy and sell them. On NEAR, they have access to reasonable costs plus intuitive end-user experiences. 
   3. Gaming -- because NEAR allows for performant and usable apps, developers can create gaming experiences that hook into the blockchain without forcing end-users to suffer through wallets or tokens.

[Take a look at these examples from a recent hackathon](https://near.org/blog/winners-of-hack-the-rainbow)

# Network Specifications

## Transaction Fees

First, transaction fees on NEAR are a tiny fraction of the amount of fees paid on other blockchains. 1000 times lower transaction fees than Ethereum for users and developers earn 30% of transaction fees.

NEAR keeps transaction fees low by dynamically resharding to optimize for performance and avoid congestion on the network. However, the most important feature of the NEAR token isn’t related to fees or rewards, it comes back to the usability and developer experience that truly sets NEAR apart.

Complicated blockchain concepts like tokens, rewards, and fees can be almost entirely hidden from end-users of NEAR applications because smart contracts can be configured to pay fees on their behalf. This allows developers to build experiences which feel more like today’s web to their end-users, but still take advantage of the underlying innovations of blockchain.

## Transaction Speed & Finality

The expected block time is around 1s and the expected time to finality is around 2s. 1,000 TPS benchmarked on a single shard for token transfers (contract ops are slower).

## Languages supported

* **Contracts**: Rust and AssemblyScript
* **Command line**: NEAR CLI
* **API**: JavaScript and JSON RPC API

## EVM compatibility

NEAR is fully compatible with the EVM and interoperable with Ethereum. NEAR does not want Ethereum developers to choose between the two networks and commit to only one. Developers can have the same asset on both blockchains and even have apps that seamlessly communicate across the boundary.

This is made possible by the [**Rainbow Bridge**](https://github.com/near/rainbow-bridge), which connects the Ethereum and NEAR blockchains by leveraging the Ethereum miners and NEAR validators. More info can be found [**here**](https://github.com/near/near-evm).

## Role of the NEAR token

The NEAR token is how people who use applications on the network pay to submit transactions to the nodes who actually run the network. The token is thus a utility — if you hold it, you can use applications hosted on the network.


What is NEAR?

Tweak the Manifest

"An investment in knowledge always pays the best interest.”
― Benjamin Franklin

Connect to Pyth on Solana

Displaying Pyth price data on a convenient chart

Visualize price data

# Access

Getting access to accounts is obviously a critical feature for any wallet application, and given our choice of architecture, we don't have to worry about encrypting and decrypting passwords to log in and out.

The beauty of public-key cryptography is that the private key is effectively your password. And while securing crypto applications is more sophisticated than simply using your private key as a password, especially for industrial-strength wallets, we can achieve the basic functionality of accessing a wallet by leveraging what we learned in [Step 2](https://learn.figment.io/tutorials/solana-wallet-step-2) for creating wallets.

## Recovery phrase

Recall that we've built a type of wallet called a Hierarchical Deterministic (HD) wallet, which means we can map our 12-word phrase to a seed. Since the keypair that makes the account is derived from this seed, as long as we have the recovery phrase, we can get access to the keypair and therefore the account.

{% sidenote title="Box 6.1: Industrial-Strength Wallet Access" %}
In the context of an industrial-strength wallet, you would use the phrase as a recovery mechanism only. Day-to-day access would be enabled through the use of passwords. However, the analogy of the phrase serving as a type of very secure but somewhat cumbersome password still holds. Wallets like [MetaMask](https://metamask.io/) and [Phantom](https://phantom.app/) handle first-time access using recovery phrases and rely on locally encrypted password hashes for subsequent logins.

If you saved your test account's recovery phrase, we'll use it now. Feel free to click log out at the top right. Once we've finished this step, you'll once again have access to your devnet SOL.

# Implementation 🧩

Navigate to the app's home page at [http://localhost:3000](http://localhost:3000). If you click on the **Get Existing Wallet** button, you'll be routed to the page for importing the recovery phrase. But if you click on **Import** after pasting your phrase, you'll notice a message in the console that reads, "Recovery functionality not implemented yet!".

For this feature to work, we need to implement a function that uses the phrase to generate a seed, and then uses the seed to retrieve the keypair (i.e. access the account). 

Recall that in [Step 2](https://learn.figment.io/tutorials/solana-wallet-step-2) we first generated a mnemonic phrase with the Bip39 library by leveraging the `generateMnemonic` function. Then, in order to generate a keypair, we had to convert the phrase to a seed that could be be consumed by Solana's `Keypair` class to generate the `Keypair` that would grant us access to the account.

## Seed from phrase

In this case, we already have a phrase because the user imported it but the rest of the code mirrors [Step 2](https://learn.figment.io/tutorials/solana-wallet-step-2). We can convert the phrase into a seed and then leverage the `fromSeed` method from `Keypair` to access the account.

```javascript
const seed = Bip39.mnemonicToSeedSync(inputMnemonic).slice(0, 32);
const importedAccount = Keypair.fromSeed(seed);
```

With those two lines of code, we have effectively implemented authentication and allowed users to access their accounts from any device as long as they have their recovery phrase.

##### _Listing 6.2: Code for Recovering an Account_
```javascript
const handleImport = async (values: any) => {
  setLoading(true);
  const inputMnemonic = values.phrase.trim().toLowerCase();
  setMnemonic(inputMnemonic);

  const seed = Bip39.mnemonicToSeedSync(inputMnemonic).slice(0, 32);
  const importedAccount = Keypair.fromSeed(seed);
  setAccount(importedAccount);
};
```

This is a good point to reflect on what we've just completed. Clearly we built a crypto wallet capable of performing basic actions on Solana.

But taking a step back, we built something capable of performing actions that have long been the sole purview of giant financial institutions. Think about it. By understanding a few concepts, leveraging some libraries, and writing a few lines of code, you just built a trustless, decentralized bank. Let that sink in.

# Challenge 🏋️

Navigate to `pages/recover.tsx` in your editor and follow the steps included as comments to finish writing the function. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code block is also included in [Listing 6.1](#listing-61-instructions-for-writing-recover-function) below.

##### _Listing 6.1: Instructions for writing recover function_
```javascript
// *Step 6*: implement a function that recovers an account based on a mnemonic phrase
const handleImport = async (values: any) => {
  console.log("Recovery functionality not implemented yet!");

  setLoading(true);
  const inputMnemonic = values.phrase.trim().toLowerCase();
  setMnemonic(inputMnemonic);

  // (a) review the import guidance on lines 9 and 11
  // (b) convert the mnemonic to seed bytes
  // Documentation Reference: https://github.com/bitcoinjs/bip39
  const seed = new Uint8Array();

  // (c) use the seed to import the account (i.e. keypair)
  // Documentation Reference:
  //   https://solana-labs.github.io/solana-web3.js/classes/Keypair.html
  //   https://solana-labs.github.io/solana-web3.js/classes/Keypair.html#fromSeed
  const importedAccount = null;
  setAccount(importedAccount);

  // (d) You can now delete the console.log statement since the function is implemented!
};
```


Step 6: Recover an Account 🔐

# Access The Graph Pathway

We no longer host the Pathway pages on this website, the content has moved to the `learn-web3-dapp` repository at <https://github.com/figment-networks/learn-web3-dapp#-get-started>.

For less experienced developers or for anyone who wants to dive in without complicated setup, **[we recommend using Gitpod](https://gitpod.io/#https://github.com/figment-networks/learn-web3-dapp)** to work with the `learn-web3-dapp` project (this requires you to have a GitHub account to sign in). Gitpod can save you a considerable amount of time, as you don't have to install dependencies or set up a development environment - everything just works!

If you are an experienced developer, [cloning the repo locally](https://github.com/figment-networks/learn-web3-dapp#-clone-locally) is still possible, however you might encounter various system configuration issues depending on how your local environment is set up. A minimum of NodeJS version 14.17 is recommended, and you'll want to make sure you have the `build-essential` package installed. You'll also want to make sure your Rust toolchain is up to date and that you have the `wasm32-unknown-unknown` target triple set up and installed.


You can now access The Graph 101 Pathway on our GitHub repo.

The Graph Pathway has moved to learn-web3-dapp

Deploy a Solidity smart contract

# Airdrop basics

We've now generated a wallet and connected it to the Solana blockchain. In the previous step, we confirmed that our account's balance is zero but wouldn't it be nice to fund our account so we can see the balance change?

You might be wondering whether we'll now need to transfer real money so we can test the account, but as we discussed in [Step 3](https://learn.figment.io/tutorials/solana-wallet-step-3), a blockchain's devnet typically provides a way to test transactions without risking real economic value.

In this step, we'll be building functionality to allow users to "airdrop" SOL tokens into their devnet account. In the crypto world, an airdrop is a way for the protocol to distribute tokens to account holders for free. 


![Figure 5: We're about reinforce our supply lines with some devnet SOL](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/solana/solana-wallet/assets/airdrop.jpeg)

{% label %}
Figure 5: We're about reinforce our supply lines with some devnet SOL

In this case, we'll be tapping into the native devnet airdrop functionality built into Solana to fund our account. This is in contrast to mainnet airdrops performed by blockchain protocols and crypto projects, which are usually issued to reward early adopters or contributors.

{% sidenote title="Box 4.1: Growth Hacking with Aidrops" %}
Protocols and companies use airdrops as a marketing technique to hype their launch and catalyze user growth. By issuing tokens to users that joined by a certain date or performed some action on the protocol, they can spread the word and, if the airdrop is successful, make more people aware of the solution they're building. For example, the Stellar Development Foundation performed a $125 million airdrop in late 2018 to get Stellar Lumens in the hands of crypto users and try to boost mainstream adoptions.

On the right side of the wallet dashboard, you'll find a button with the label **Airdrop**. You might notice that this button goes away if you change the network. This is because the functionality we're implementing is only active for devnet. Moreover, you'll notice a tooltip help icon informing users that they'll receive 1 devnet SOL by clicking on **Airdrop**.

Once we've completed this step, our balance will automatically increase when we click **Airdrop**. This will position us well for [Step 5](https://learn.figment.io/tutorials/solana-wallet-step-5) where we'll build functionality to send funds to other Solana accounts.

# Implementation 🧩

In [Step 3](https://learn.figment.io/tutorials/solana-wallet-step-3) we learned how to instantiate a connection to one of Solana's networks, and how to assign our account's public key property to a variable. We can apply that same code here to start writing the `handleAirdrop` function in `utils/index.ts`:

```javascript
const connection = new Connection(clusterApiUrl(network), "confirmed");
const publicKey = account.publicKey;
```

## Airdrop function

Following our previous heuristic of searching the docs for keywords, we can now search for "airdrop" to see if there's a function we can leverage. Lo and behold the `Connection` class has a `requestAirdrop` function that looks promising. It takes in two properties - `to: PublicKey` and `lamports: number` - and returns a `promise` that resolves to a string.

You might be wondering what a "lamport" is. Solana's native token, SOL, is divisible into 1 billion lamports. You can think of lamports as the cents to SOL's dollar.

![Figure 6: This is also a lamport. Leslie Lamport is the lamport's namesake. He's a computer scientist who has made key contributions to distributed systems](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/solana/solana-wallet/assets/leslie.jpeg)

{% label %}
Figure 6: This is also a lamport. Leslie Lamport is the lamport's namesake. He's a computer scientist who has made key contributions to distributed systems


It's not clear from the documentation, but after a little research you can confirm that the returned string represents a confirmation ID or `signature`. From a function design standpoint, it seems reasonable that to request an airdrop we should pass in the account address (public key) and the amount of funds we're requesting.

```javascript
const confirmation = await connection.requestAirdrop(
  publicKey,
  1000000000
);
```

The above function will work just fine and our users will be able to airdrop 1 SOL every time they click on the button. But you can clean it up a bit by importing and passing in the `LAMPORTS_PER_SOL` constant, which itself equals one billion, from web3.js.

```javascript
const confirmation = await connection.requestAirdrop(
  publicKey,
  LAMPORTS_PER_SOL
);
```

{% sidenote title="Box 4.2: Where Do Devnet Airdrops Come From?" %}
Devnet airdrops come from smart contracts deployed with a high initial token balance and a transfer function that allows anyone to request tokens into their devnet account. These so-called faucets are designed to help developers test dApps before going live on mainnet. In our case, the airdrop function is sending a request to a smart contract that transfers devnet SOL from the original supply to your account by updating the balances of both accounts.

## Confirming airdrop

Finally, before we can refresh our account's balance automatically, we need a way to make sure the blockchain ledger has been updated with our airdropped funds before we call `refreshBalance`. As with any database-type operations, blockchain state changes are asynchronous. In fact, given the decentralized nature of most blockchain protocols, some updates [can take a while](https://twitter.com/CryptoKitties/status/937444644740198400?s=20).

With that in mind, we need to wait for the airdrop to be confirmed before refreshing the balance. Searching the docs once again, we can see that our `Connection` class includes a `confirmTransaction` method that takes in a confirmation `signature` and `commitment`, and returns a `promise` that resolves once the transaction is confirmed by the network.

```javascript
await connection.confirmTransaction(confirmation, "confirmed");
```

Note that we don't need to assign a variable to the confirmation here. Once our wallet knows that the transaction was confirmed by the network, it can call `refreshBalance` and update the balance for the account.

```javascript
return await refreshBalance(network, account);
```

Avid readers might have noticed that the balance in our account looks wrong. It reads one billion SOL when it should read 1 SOL. Now that we know what lamports are, how they relate to SOL, and how to use the `LAMPORTS_PER_SOL` constant, we can go back to our `refreshBalance` function and fix the bug by updating its return value.

```javascript
return balance / LAMPORTS_PER_SOL;
```

![Figure 7: Getting close to the summit](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/solana/solana-wallet/assets/climbing.jpeg)

{% label %}
Figure 7: Getting close to the summit

We've come a long way and now have a better idea of how blockchain protocols work. We built a wallet by creating a keypair, connected to the network, fetched data from it, and successfully requested test tokens. We've covered all of the basic Web 3 interactions except the most important one - transferring funds. We'll do that next in [Step 5](https://learn.figment.io/tutorials/solana-wallet-step-5), so brace yourself.

##### _Listing 4.2: Code for airdropping funds_
```javascript
const handleAirdrop = async (network: Cluster, account: Keypair | null) => {
  if (!account) return;

  try {
    const connection = new Connection(clusterApiUrl(network), "confirmed");
    const publicKey = account.publicKey;
    const confirmation = await connection.requestAirdrop(
      publicKey,
      LAMPORTS_PER_SOL
    );
    const result = await connection.confirmTransaction(confirmation, "confirmed");
    return await refreshBalance(network, account);
  } catch (error) {
    console.log(error);
    return;
  }
};

const refreshBalance = async (network: Cluster, account: Keypair | null) => {
  if (!account) return;

  try {
    .
    .
    .
    return balance / LAMPORTS_PER_SOL;
  } catch (error) {
    .
    .
    .
  }
};
```

# Challenge 🏋️

If you open the browser's console from the `/wallet` page, and click on the **Airdrop** button, you'll notice a message that reads, "Airdrop functionality not implemented yet!". Navigate to `utils/index.ts` in your editor and follow the steps included as comments to finish writing the `handleAirdrop` function. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code block is also included in [Listing 4.1](#listing-41-instructions-for-writing-airdrop-function) below.

##### _Listing 4.1: Instructions for writing airdrop function_
```javascript
const handleAirdrop = async (network: Cluster, account: Keypair | null) => {
  // This line ensures the function returns before running if no account has been set
  if (!account) return;

  try {
    // (a) review the import guidance on line 1
    // (b) instantiate a connection using clusterApiUrl with the active network passed in as an argument
    // Documentation References:
    //   https://solana-labs.github.io/solana-web3.js/classes/Connection.html
    //   https://solana-labs.github.io/solana-web3.js/modules.html#clusterApiUrl
    console.log("Airdrop functionality not implemented yet!");
    const connection = "";

    // (c) get the key using one of the accessors on the account passed in as an argument
    // Documentation Reference: https://solana-labs.github.io/solana-web3.js/classes/Keypair.html
    const publicKey = "";

    // (d) request the airdrop using the connection instance
    // Note that you should include the amount to airdrop (consider using the LAMPORTS_PER_SOL constant from the web3.js library)
    // Documentation Reference: https://solana-labs.github.io/solana-web3.js/classes/Connection.html
    const confirmation = "";

    // (d) confirm the transaction using the connection instance and the confirmation string returned from the airdrop
    // Documentation Reference: https://solana-labs.github.io/solana-web3.js/classes/Connection.html
    const result = "";

    // (e) Refactor the refreshBalance function to return balances in SOL instead of Lamports (Hint: LAMPORTS_PER_SOL)

    // This line returns the balance after the airdrop so the UI can be refreshed
    return await refreshBalance(network, account);
    // (f) You can now delete the console.log statement since the function is implemented!
  } catch (error) {
    console.log(error);
    return;
  }
};
```


Step 4: Airdrop Funds 🪂

We no longer host the Pathway pages on this website, the content has moved to the `learn-web3-dapp` repository at <https://github.com/figment-networks/learn-web3-dapp#-get-started>.

For less experienced developers or for anyone who wants to dive in without complicated setup, **[we recommend using Gitpod](https://gitpod.io/#https://github.com/figment-networks/learn-web3-dapp)** to work with the `learn-web3-dapp` project (this requires you to have a GitHub account to sign in). Gitpod can save you a considerable amount of time, as you don't have to install dependencies or set up a development environment - everything just works!

If you are an experienced developer, [cloning the repo locally](https://github.com/figment-networks/learn-web3-dapp#-clone-locally) is still possible, however you might encounter various system configuration issues depending on how your local environment is set up. A minimum of NodeJS version 14.17 is recommended, and you'll want to make sure you have the `build-essential` package installed. You'll also want to make sure your Rust toolchain is up to date and that you have the `wasm32-unknown-unknown` target triple set up and installed.


You can now access the NEAR 101 Pathway on our GitHub repo.

The NEAR Pathway has moved to learn-web3-dapp

# What is Tezos?

Tezos is a secure, smart contract blockchain platform that uses its built-in governance mechanism for protocol upgrades. Tezos is one of the first blockchain platforms to introduce a formal on-chain governance process. The Tezos network is highly decentralized with over 500 nodes distributed globally. Tezos’ smart contract language, Michelson, is designed to facilitate formal verification, a technique used to improve security by mathematically proving properties. This technique, if used properly, can help avoid costly bugs and contentious debates that follow.

# Why build on Tezos?

Tezos is an open-source platform for assets and applications that can evolve by upgrading itself. Stakeholders govern upgrades to the core protocol, including upgrades to the amendment process itself. **It benefits from three main characteristics: self-amendment, on-chain governance, and decentralized innovation.**

Self-amendment allows Tezos to upgrade itself without having to split (“fork”) the network into two different blockchains. This is important as the suggestion or expectation of a fork can divide the community, alter stakeholder incentives, and disrupt the network effects that are formed over time. Because of self-amendment, coordination and execution costs for protocol upgrades are reduced and future innovations can be seamlessly implemented.

In Tezos, all stakeholders can participate in governing the protocol. The election cycle provides a formal and systematic procedure for stakeholders to reach agreement on proposed protocol amendments. By combining this on-chain mechanism with self-amendment, Tezos can change this initial election process to adopt better governance mechanisms when they are discovered.

Proposed amendments that are accepted by stakeholders can include payment to individuals or groups that improve the protocol. This funding mechanism encourages robust participation and decentralizes the maintenance of the network. Fostering an active, open, and diverse developer ecosystem that is incentivized to contribute to the protocol will facilitate Tezos development and adoption.

# What can you build on Tezos?

Turing-complete smart contract platforms like Tezos or Ethereum allow for arbitrary code to be executed in a trust-minimized manner. However, certain applications may be well suited for Tezos based on formal governance and focus on smart contract security. Below are some preliminary examples:

1. Digital Assets

  Assets like digital money, tokenized real estate, stablecoins, digital collectibles, and so on are particularly well-suited for Tezos. Avoiding contentious forks can preserve value and coordination around one network, making Tezos a compelling platform for issuing digital assets.

Although no system can be unconditionally secure, the Tezos smart contract language, Michelson, was designed with security and formal verification in mind. This is especially critical for smart contracts representing high value assets, given the unforgiving nature of smart contracts bugs.

2. Trust-Minimized Financial Contracts

  Financial contracts such as decentralized exchanges, swaps, loans, and so on demand a high-level of correctness. Decentralized blockchain networks derive their value from the absence of a trusted third party, which makes a loss of funds from a bug in the code particularly unforgiving.

# Network Specifications

## Transaction Fees

So far, this system is similar to the way Ethereum handles transaction. However, we differ in the way we handle fees. Ethereum allows arbitrarily long programs to execute by requiring a fee that increases linearly with the program's executing time.

## Transaction Speed & Finality

Currently, Tezos does around 30-40 transactions per second.

In the current Tezos protocol, 30 confirmations (~30 minutes) may be considered a good rule of thumb for transaction to be considered final. Since Tezos uses a chain-based PoS consensus algorithm, the possibility of a chain re-organization remains after a transaction. Users must wait a number of confirmations before they can be overwhelmingly confident that a transaction will not be reversed.

## Languages supported

There are various high-level languages available for programming Smart Contracts for Tezos. The intention of these languages is to ease the development experience, so you can focus on the content of your Smart Contracts, rather than the implementation.

Current options in development include:

* LIGO: A Smart Contract language offering Pascal, Ocaml, and ReasonML syntax flavors
* SmartPy: A Python library with tools to write and test Smart Contracts
* Morley/Lorentz: A Haskell-flavored eDSL for writing Smart Contracts

## EVM compatibility

Tezos does not currently support an EVM implementation.

## Role of the XTZ token

XTZ, tez, or ꜩ is the native currency of Tezos. XTZ is programmable money created by smart contract on the Tezos blockchain. It is used to pay on-chain fees and influence the network's governance.


What is Tezos?

Existential deposit

Implement the mappings

You can now access the Polygon 101 Pathway on our GitHub repo.

The Polygon Pathway has moved to learn-web3-dapp

# What is Celo?

Celo is a smart contract blockchain network. The technology uses a phone-number-based identity system with address-based encryption and [eigentrust-based reputation](https://en.wikipedia.org/wiki/EigenTrust). Their first application is a social payments system that can be used on a smartphone.

Celo is preparing to launch a variety of stable coins pegged to global fiat and crypto currencies, the first one being pegged to the US dollar (cUSD).

# Why build on Celo?

The Celo blockchain is designed to empower anyone with a smartphone anywhere in the world to have access to financial services, send money to phone numbers, and pay merchants. The project aims to be a decentralized platform that is not controlled by any single entity, but instead developed, upgraded and operated by a broad community of individuals, organizations and partners.

Celo is oriented around providing the simplest possible experience for end users, who may have no familiarity with cryptocurrencies, and may be using low cost devices with limited connectivity. To achieve this, the project takes a full-stack approach, comprising of both a protocol and applications that use that protocol. Celo offers a full suite of powerful features:

* Stable value currencies (cUSD)
* Accounts linked to phone numbers
* Transaction fees in any currency
* Immediate syncing
* Programmable (full EVM compatibility)
* Carbon Neutral

# What can you build on Celo?

Celo enables developers to build a new financial system to empower their users. Developers can:
* Create financial services applications for the underbanked (savings accounts, money transfer interfaces, merchant services, lending, trading)
* Integrate with existing blockchain and traditional financial services
* Create transparent aid services
* Build payroll integrations to allow internet users to earn stable currencies
* Create advanced user wallets (smart contract wallets) 
* Alternative currencies 
* Use the full suite of Ethereum smart contracts right off the shelf

You can view some of the projects that are building on Celo [here](https://docs.celo.org/developer-guide/overview/celo-dapp-gallery).

# Network Specifications

## Transaction Fees

* [Celo uses a gas market based on EIP1559 to set gas prices](https://docs.celo.org/celo-codebase/protocol/transactions/gas-pricing)
* [There are also gateway fees for light clients](https://docs.celo.org/celo-codebase/protocol/transactions/full-node-incentives)
* Currently fees on the network are around $0.001/transaction

## Transaction Speed & Finality

Celo has a 5 seconds block time with instant finality.

## Languages supported

Most of the protocol code is written in Go, while the SDKs are written in Typescript which supports native javascript.

The Celo community is also working on Java and Python SDKs.

## EVM compatibility

While the Celo client originated as a fork of Ethereum Go langauge client, [go-ethereum](https://github.com/ethereum/go-ethereum) (or geth), it has several significant differences, including a proof-of-stake based PBFT consensus mechanism. All the cryptoassets on Celo have ERC-20 compliant interfaces, meaning that while they are not ERC-20 tokens on the Ethereum Mainnet, all familiar tooling and code that support ERC-20 tokens can be easily adapted for Celo assets, including the Celo Native Asset (CELO) and the Celo Dollar (cUSD).

In terms of programmability, Celo is similar to Ethereum. Both networks run the Ethereum Virtual Machine (EVM) to support smart contract functionality. This means that all programming languages, developer tooling and standards that target the EVM are relevant for both Celo and Ethereum. Developers building on Celo can write smart contracts in [Solidity](https://solidity.readthedocs.io/en/latest/), use [Truffle](https://www.trufflesuite.com/) for smart contract management and take advantage of smart contract standards that have already been developed for Ethereum.

## Role of the CELO token

The native Celo token (CELO) is the utility token on the Celo network. CELO are used to pay for transactions and are also staked by token-holders to earn rewards, participate in governance, and to vote for validators.



What is Celo?

Connect to Avalanche

You'll be building the blog application on top of a [Next.js](https://nextjs.org/) template that we have pre-built. This way you can quickly scaffold your way into developing the Web 3 dApp with minimal configuration.

# Add the Mumbai testnet to MetaMask ⛓

You'll need to connect to the Polygon Mumbai testnet for these tutorials, so add it to the list of RPC endpoints in MetaMask. Click on the Fox head icon in your web browser to open the popup, and then follow this workflow to complete the process :

- Click on the current network at the top of the MetaMask popup (by default is says "Ethereum Mainnet")
- Scroll down and click on "Custom RPC"
- Fill in the form:
  - Network Name: `Polygon Mumbai`
  - New RPC URL: `https://rpc-mumbai.maticvigil.com/`
  - Chain ID: `80001`
  - Currency Symbol: `MATIC`
  - Block Explorer URL : `https://mumbai.polygonscan.com`
- Double check the information, then click on the **Save** button.

![](https://raw.githubusercontent.com/figment-networks/learn-web3-dapp/main/markdown/__images__/polygon/add_mumbai.png?raw=true)

We strongly recommend using the testnet for development before moving into production on the main network or "mainnet".

# Fund your account with MATIC 🤑

You will need some MATIC tokens to be able to fund the deployment of the smart contract in one of the following tutorials! Think of this as stopping at the service station to fill up your gastank before a long road trip.

Visit the Polygon Faucet at [https://faucet.polygon.technology](https://faucet.polygon.technology) and paste the address from your selected account in MetaMask into the textinput. It is OK to leave the default options for the **Mumbai** network and **MATIC** tokens selected. 
Click the **Submit** button, then click again on the popup to confirm the transaction. You'll be rewarded with 0.5 MATIC every time you do this, however there is a rate limit so don't get greedy. Half a MATIC is plenty to deploy several contracts and run test transactions.

# Getting Started 🎬

Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git), [Node](https://nodejs.org/en/) and [yarn](https://yarnpkg.com/getting-started/install) installed. Make sure you've setup [SSH or token-based authentication](https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/) for Github. 

Use `git` to clone the project template code repository, then change into the root directory of the project. 

```text
$ git clone git@github.com:figment-networks/web3-evm-template.git
$ cd web3-evm-template
```

{% hint style="warning" %}
When you see a code block that has lines beginning with `$`, it indicates that the commands should be run in your terminal. The dollar sign is a _command prompt_ and should not be included in the command.
{% endhint %}

Now that you have the template, you need to navigate to the branch containing the code for this tutorial and then install the app dependencies with the yarn package manager:

```text
$ git checkout mirror-clone
$ yarn
```

If you run into any Node.js issues, make sure you're running version 14.17.0 or greater. You can use the [Node Version Manager](https://github.com/nvm-sh/nvm) if you need to manage multiple Node versions locally.

Next, you'll need to copy the example environment file `.env.local.example` to set the environment variables needed to deploy the smart contract with Hardhat.

```text
$ cp .env.local.example .env.local
```

Now open the file `.env.local` and set the four environment variables based on the instructions included below. If you are not familiar with them, read more about the [dotenv package and `.env` files](https://docs.figment.io/network-documentation/extra-guides/dotenv-and-.env).

```text
POLYGONSCAN_API_KEY=Polygonscan API Key. Go to https://polygonscan.com/login and login or create an account. Then click on API-KEYs on the left navigation panel to create an api key. Name the app MirrorClone. Copy-paste the API key here.
MAINNET_NODE_URL=https://matic-mainnet.chainstacklabs.com
TESTNET_NODE_URL=https://matic-mumbai.chainstacklabs.com
PRIVATE_KEY=The private key of an account funded with MATIC that you've exported from MetaMask. Go to https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key to learn how to export your private key.
```

If you don't already have MetaMask installed as a browser extension, you should do that before proceeding. You can go to its download page [here](https://metamask.io/download.html).

{% sidenote title="Box 1.1: What is MetaMask?" %}
[MetaMask](https://metamask.io/) is a crypto wallet built as a browser extension that allows you to interact with Ethereum and Ethereum-compatible blockchains as well as dApps built on top of them.

{% hint style="warning" %}
The **PRIVATE_KEY** environment variable is required to deploy the smart contract in Step 6. Despite the fact that the `.env.local` file has been placed in `.gitignore` already so that you don't expose your private key, we still recommend you create a wallet specifically for use in tutorials and local development. That way, you can mitigate the risk of exposing your wallet's private key in case it contains any mainnet tokens with monetary value.
{% endhint %}

Finally, we want to add certain libraries that will set us up for smart contract development in Step 6 but without which we'll get a few compiling errors. 

```text
$ yarn web3:compile
```

With that in place, our dApp template is ready to be built into a functional blog. You can run the local server to get started - once it is up and running, view in your web browser by going to [http://localhost:3000](http://localhost:3000).

```text
$ yarn dev
```

# Reviewing the Template 🧐

Before we dive into the code, we should understand what the template comes with. Along with the standard folder structure and dependencies found in most NextJS applications, we have added two Web 3-specific libraries that we'll leverage throughout the tutorial - [ethers.js](https://docs.ethers.io/) and [Hardhat](https://hardhat.org/).

Ethers is a JavaScript library designed to interact with Ethereum and Ethereum-compatible blockchains. We'll first encounter ethers in Step 2 to interface with MetaMask and connect our wallet.

Hardhat is a development environment for Ethereum and Ethereum-compatible blockchains. It allows you to write and compile Solidity locally, run tests and deploy smart contracts, all while fully supporting Typescript. We'll leverage Hardhat in Step 6 to manage development of the smart contract used to mint and transfer NFTs related to blog entries.

Feel free to explore the rest of the template on your own. It includes standard hooks and components that we'll use to add functionality to our blog. But that's enough set up for now.

Let's build!

![“I can feel the anticipation.”](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/lego.jpeg)

{% label %}
“I can feel the anticipation.”


Developer tools save a lot of time when starting a project

Setup the project 🧑‍💻

If you've developed full stack apps on Web 2, you're probably familiar with the concept of a query builder. These libraries facilitate interactions with databases by creating a language-native API for database interactions that abstract the complexity of writing direct SQL.

We're about to use a similar tool in Web 3. This step will require us to leverage [ArDB](https://www.npmjs.com/package/ardb) - a way to interact with Arweave using Typescript, so we don't need to write GraphQL directly.

# Implementation 🧩

We'll start by opening the entries query endpoint file `pages/api/arweave/search/[[query]].ts`. In this file, we've started a function that will receive a query and return a list of entries. The goal is for the client to receive the list and display it, so users can select an entry to read.

This endpoint should be flexible enough to handle requests for the most recent entries published on the application as well as the most recent entries published by a specific user.

First, we should instantiate an ArDB instance, which we can do by confirming we've installed the relevant package and imported ArDB into this file. We should also create a `tags` variable with the app name.

```typescript
const ardb = new ArDB(arweave);
const tags = [{ name: "App-Name", values: [process.env.APP_NAME as string] }];
```

Next, we should retrieve the author's address from the `query` param if there is one and create another tag in the tags list:

```typescript
const searchAddress = query && query[0];

if (searchAddress) {
  tags.push({ name: "Address", values: [searchAddress] });
}
```

With everything we need in place, we can leverage `ardb` to issue a search query for a transaction matching our `tags`. Similar to other query builders, we can chain methods to increase the specificity of the query. In this case, we'll want to find the latest 10 entries.

```typescript
const txs = await ardb.search("transactions").tags(tags).limit(10).find();
```

Now everything is in place. If you refresh your dApp, you'll see the entries you created in the previous steps. Magic!

![And all the entries simply... appear!](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/magic.jpeg)

{% label %}
And all the entries simply... appear!

At this point, you'll be tempted to create an entry to test the functionality. And you absolutely should do that! But don't be alarmed when you click on the entry you just created and instead of getting the entry, you get a message telling you it hasn't been confirmed yet.

Recall from **Box 4.1** that distributed systems take a few minutes to come to consensus and confirm transactions. Keep making progress, and before you're done with Step 6, your entry will be ready to go.

You'll also notice that if you click on an entry, there's a warning in the NFT box with an error message. That's because we currently have a zero address as the default smart contract address. We'll fix that in Step 6.

##### _Listing 5.1: Code for fetching a list of entries_

```typescript
try {
  const {query} = _req.query;

  const ardb = new ArDB(arweave);

  const searchAddress = query && query[0];

  const tags = [{name: 'App-Name', values: [process.env.APP_NAME as string]}];
  if (searchAddress) {
    tags.push({name: 'Address', values: [searchAddress]});
  }

  const txs = await ardb.search('transactions').tags(tags).limit(10).find();

  const promises = txs.map((tx: any) => getData(tx._id));
  const data = await Promise.all(promises);

  res.status(200).json(data);
}
```

# Challenge 🏋️

Navigate to `api/arweave/search/[[query]].ts` in your code editor and follow the steps included as comments to finish writing the query endpoint. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code block is also included in **Listing 5.2** below.

##### _Listing 5.2: Instructions for fetching a list of entries_

```typescript
try {
  const {query} = _req.query;

  // Initialize ArDB
  // More information about ArDB can be found here: https://www.npmjs.com/package/ardb

  // Retrieve searchAddress

  // Build tags

  // Search for transaction withs App-Name and Address (optional) tags
  // More information can be found here: https://www.npmjs.com/package/ardb

  const promises = txs.map((tx: any) => getData(tx._id));
  const data = await Promise.all(promises);

  res.status(200).json(data);
}
```

Once the code is complete, you will be able to see a list of posts on the Dashboard as well as under your user profile:

![Screenshot displaying a list of entries](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/entries.jpg)


Showing data to users is an important part of any app

Displaying a list of entries 📋

# Access the Tezos Pathway

We no longer host the Pathway pages on this website, the content has moved to the `learn-web3-dapp` repository at <https://github.com/figment-networks/learn-web3-dapp#-get-started>.

For less experienced developers or for anyone who wants to dive in without complicated setup, **[we recommend using Gitpod](https://gitpod.io/#https://github.com/figment-networks/learn-web3-dapp)** to work with the `learn-web3-dapp` project (this requires you to have a GitHub account to sign in). Gitpod can save you a considerable amount of time, as you don't have to install dependencies or set up a development environment - everything just works!

If you are an experienced developer, [cloning the repo locally](https://github.com/figment-networks/learn-web3-dapp#-clone-locally) is still possible, however you might encounter various system configuration issues depending on how your local environment is set up. A minimum of NodeJS version 14.17 is recommended, and you'll want to make sure you have the `build-essential` package installed. You'll also want to make sure your Rust toolchain is up to date and that you have the `wasm32-unknown-unknown` target triple set up and installed.


You can now access the Tezos 101 Pathway on our GitHub repo.

The Tezos Pathway has moved to learn-web3-dapp

Run a local Graph node

Swap cUSD to CELO

Create an account

Non-fungible tokens (NFTs) are a fascinating technology enabled by the ledger capabilities of blockchain protocols. They allow us to prove ownership of digital assets by providing a record of ownership that is decentralized and easy to verify.

In our case, we'll be leveraging a standard referred to as [ERC-721](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/), which defines the basic functionality of an NFT. More importantly, there are standard smart contract implementations that we can use to minimize our work and ensure the security of the tokens we create.

{% sidenote title="Box 6.1: A note on smart contracts" %}
Smart contracts are computer programs that run on certain blockchain protocols and can be executed to perform actions on the blockchain. They are deterministic and have specific, limited functionality designed to react to an input with certain predictable state changes. A common physical analogy are vending machines. You insert a predefined amount of money, and the machine drops a snack into a slot for you to pick up. Note that, as with many labels in crypto, the term "smart contract" can be a bit confusing since these are not smart in the intelligence sense of the word and they're certainly not legal contracts.

# Development Tools 🛠

We'll be leveraging [OpenZeppelin](https://openzeppelin.com/), a library of standard smart contracts that have been audited for security and are fully composable. As with any library or package you may have used before, this allows us to benefit from off-the-shelf functionality and extend it if we need anything custom.

[Hardhat](https://hardhat.org/) is another important tool that we'll be leveraging as a development environment. It will allow us to compile [Solidity](https://docs.soliditylang.org/), which is the programming language we'll use to write our smart contract. Moreover, it will provide us with a testing framework for unit tests, and will facilitate the deployment to [Polygon](https://polygon.technology/) when we're ready.

# Implementation 🧩

If you navigate to `web3/contracts/MirrorClone.sol` you'll notice we have scaffolded a smart contract for you already. Before diving into the `createToken` function we need to write, let's get acquainted with the general structure of the code.

# Smart Contract Review 🧐

Solidity programs must always start with the Solidity version at the top using the `pragma` keyword. This tells the Solidity compiler which version to use. Newer versions of the `solc` compiler are generally backwards compatible to an extent, but it is good practice to keep up to date and not use older versions of the compiler unless there is a good reason to do so.

We've also imported a few pre-built contracts from the OpenZeppelin library in `MirrorClone.sol`. Our contract will be inheriting the basic functionality of an [ERC-721 token](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/). That will allow us to focus on the functionality we want to add instead of having to write it from scratch.

You can think of the smart contract as a class with a constructor, properties, and methods. That maps pretty closely to the subsequent lines, which include defining the properties for our smart contract (e.g. a mapping called `tokenURIToTokenId`), setting up a constructor that takes in a name and symbol, and adding functions to extend the inherited functionality.

# Creating Tokens 🏭

Focusing on the `createToken` function, the first instruction tells us we need to make sure we are passing a `tokenURI` before creating a token. In this context, the token URI will be the transaction id, also known as the transaction hash, from Arweave.

We'll need to leverage Solidity's `require` function to check that the length of the supplied `tokenURI` is greater than zero. If the requirement fails, we should return a simple, descriptive error message.

```solidity
require(bytes(_tokenURI).length > 0, "Empty tokenURI");
```

Next we should increment the counter for `tokenIds` so we can assign a unique token ID for each entry.

```solidity
_tokenIds.increment();
uint256 newItemId = _tokenIds.current();
```

We can then leverage the `_safeMint` function we inherited from the **ERC721.sol contract** to create a token for the entry's author. The intent will be for the dApp to immediately mint an entry's NFT when the author clicks publish.

Once minted we should set the token's URI to link it to the entry using the Arweave transaction hash. We should also add this relationship to our mapping tracker, `tokenURIToTokenId`, so we can later query NFTs by their token URI.

Finally, we should emit a `TokenMinted` event that includes the author's address, the token ID and the token URI before the function completes and returns the token ID.

```solidity
_safeMint(msg.sender, newItemId);
_setTokenURI(newItemId, _tokenURI);
tokenURIToTokenId[_tokenURI] = newItemId;

emit TokenMinted(msg.sender, newItemId, _tokenURI);

return newItemId;
```

# Testing the Smart Contract 🧪

Smart contracts are no different than any other programs we write, so we should write comprehensive tests to ensure we are building robust code and provide a safety net for changes throughout development. We have already written 3 tests for you, and you can confirm they're passing by running:

```text
$ yarn web3:compile
$ yarn web3:test
```

All three of the tests should be passing at this point as long as we implemented the code above. Just to sanity check, we can comment out the code for the `createToken` function we just wrote. If we run the tests again, notice that they will fail:

```text
$ yarn web3:test
yarn run v1.22.11
$ npx hardhat test
.
.
.
MirrorClone
    methods
      createToken
        1) reverts when empty tokenURI passed
        2) mints new token
        3) emits TokenMinted event
0 passing
3 failing
```

If you uncomment the code again, everything will be nice and green.

![Nice and green, just the way we like it.](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/green.jpeg)

{% label %}
Nice and green, just the way we like it.

Let's write one more test for the smart contract. In Solidity, mappings return 0 when a key doesn't have a value assigned to it. In other words, all keys exist with a default value of 0. We can write a test to make sure that any `tokenURI` that doesn't exist returns 0.

Add the following test to `web3/test/index.test.ts` :

```typescript
describe('tokenURIToTokenId', () => {
  it('returns 0 if tokenURI does not exist', async () => {
    expect(await contract.tokenURIToTokenId('ar://does-not-exist')).to.eq(
      0,
    );
  });
});
```

Running the tests again should confirm all four tests are passing. 

# Deploying the Smart Contract 🚀

Now that we have a functional smart contract that works as intended, we're ready to deploy it. We're going to use the Polygon network to avoid the high cost of gas fees on Ethereum. For our purposes, Polygon works identically and is fully compatible with the Ethereum Virtual Machine.

Moreover, we're going to be deploying to Polygon's Mumbai testnet so you don't have to use valuable tokens to complete this dApp. In fact, if you were developing this for production, you'd deploy it to a testnet first in order to test the functionality before deploying it to mainnet. Most production projects do that to make sure that mainnet deployments have been battle tested and are less likely to be crippled by buggy code.

{% sidenote title="Box 6.1: What's a testnet?" %}
If you're unfamiliar with the concept of various networks, you can think of it as different environments for an app in Web 2 (e.g. development, test, production, etc). Most protocols have a mainnet blockchain for production deployments with real economic value, and a testnet for experimentation. The testnet matches the mainnet in functionality but doesn't manage economic value.

In order to deploy the contract, we will use the `web3/scripts/deploy.ts` file where the template provides us with a place to leverage **ethers** and **Hardhat**. We can reference the `getContractFactory` to load the **MirrorClone** smart contract we just wrote. We can then use the `deploy` method, passing in the name and the symbol as required by the `constructor`.

We can also include a console.log statement that prints the smart contract public address, which we'll need to add as an environment variable in a moment.

```typescript
const MirrorClone = await ethers.getContractFactory('MirrorClone');
const mirrorClone = await MirrorClone.deploy('Mirror Clone', 'MRM');

await mirrorClone.deployed();

console.log('MirrorClone deployed to:', mirrorClone.address);
```

Now we can go to the command line and deploy the contract. Note that this can fail from connectivity issues sometimes. If it does, just try again. Also make sure that your private key is saved in `.env.local`, so that the deployment transaction can be paid for from your balance of testnet MATIC.

```text
$ yarn web3:deploy:testnet
```

The contract public address was logged to the console by our deployment script. Let's copy that and replace the default zeros in `.env.development` for the value of the `NEXT_PUBLIC_CONTRACT_ADDRESS` environment variable. The dApp will leverage this when publishing entries to assign them NFTs.

We'll need to restart the local server for the changed variable to take effect. Stop the running server by pressing CTRL+C in the terminal window where it is running. Start the server again with the command:

```text
$ ARWEAVE_WALLET=$(cat arweave-wallet.json) yarn dev
```

We'll also want to verify the contract, which allows chain explorers like [Polygonscan](https://polygonscan.com/) and [Etherscan](https://etherscan.io/) to confirm the deployed contract matches the source code and to display the source code for developers and users to review.

Note that you should replace the `INSERT_CONTRACT_ADDRESS_HERE` in the following command with your smart contract public address. It is also very important to pass the same constructor arguments that were used during deployment of the contract - make sure the 'Mirror Clone' and 'MRM' arguments are using identical case and spacing as the arguments passed to `MirrorClone.deploy()`.

```text
$ yarn web3:verify:testnet INSERT_CONTRACT_ADDRESS_HERE 'Mirror Clone' 'MRM'
```

If the verification fails the error messages are generally quite helpful, but double check your `PRIVATE_KEY` and `POLYGONSCAN_API_KEY`.


_If you deploy the smart contract verbatim_, you will see this error in the terminal during verification:

```text
Error in plugin @nomiclabs/hardhat-etherscan: 
The Etherscan API responded with a failure status.
The verification may still succeed but should be checked manually.
Reason: Already Verified
```

Nothing to worry about! This simply means that the exact bytecode for the smart contract you've deployed has already been verified at a different address. Any change to the source of the smart contract including extra linebreaks, comments added or removed, or even different indentation will alter the compiled bytecode and therefore not trigger this error from the contract verification plugin. 

If you visit [Polygonscan's testnet explorer](https://mumbai.polygonscan.com/), you can copy-paste the contract address from the command line into the search box and confirm the contract is on the blockchain.

![If a contract deployment isn't reason for fireworks, I don't know what is. ](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/fireworks.jpeg)

{% label %}
If a contract deployment isn't reason for fireworks, I don't know what is.

# Minting NFTs for Entries 🍬

Recall from Step 3 that we wrote a function that created entries in Arweave. We now need to integrate the NFT minting functionality into that workflow. If we return to `CreateEntryForm.tsx`, we notice instructions at the bottom of the try block in `handleSubmit` for minting an NFT.

We'll need to instantiate a signer and connect the contract to the signer. We'll then need to leverage the `createToken` function we just wrote to mint the NFT.

```typescript
const signer = provider.getSigner();
const contractWithSigner = contract.connect(signer);

const resp = await contractWithSigner.createToken(transactionId);
const rec = await resp.wait();
```

If you try to create an entry now, your MetaMask wallet will ask you to sign a transaction to mint the NFT. After Arweave confirms the entry, you'll be able to navigate to the entry and see the NFT!

But wouldn't it be nice if you could transfer that NFT to someone else? Perhaps someone wants to purchase the entry from you or you want to gift ownership of the entry to a friend. We'll tackle that next in Step 7.

##### _Listing 6.1: Code for smart contract_
```javascript
function createToken(string memory _tokenURI) public returns (uint) {
    // require statement to check if _tokenURI is not empty
    require(bytes(_tokenURI).length > 0, "Empty tokenURI");

    // Increment counter so it starts with 0
    _tokenIds.increment();
    uint256 newItemId = _tokenIds.current();

    // Mint token
    _safeMint(msg.sender, newItemId);

    // Set token URI
    _setTokenURI(newItemId, _tokenURI);

    // Set tokenURIToTokenId
    tokenURIToTokenId[_tokenURI] = newItemId;

    // Emit TokemMinted event
    emit TokenMinted(msg.sender, newItemId, _tokenURI);

    // Return new tokenId
    return newItemId;
}
```

##### _Listing 6.2: Code for tokenURIToTokenId test_
```javascript
describe('tokenURIToTokenId', () => {
  it('returns 0 if tokenURI does not exist', async () => {
    expect(await contract.tokenURIToTokenId('ar://does-not-exist')).to.eq(
      0,
    );
  });
});
```

##### _Listing 6.3: Code for deployment_
```typescript
async function main() {
  const MirrorClone = await ethers.getContractFactory('MirrorClone');
  const mirrorClone = await MirrorClone.deploy('Mirror Clone', 'MRM');

  await mirrorClone.deployed();

  console.log('MirrorClone deployed to:', mirrorClone.address);
}
```

##### _Listing 6.4: Code for minting the NFT when publishing post_
```typescript
const handleSubmit = useCallback(
.
.
.
    try {
      .
      .
      .
      if (provider && contract) {
        .
        .
        .
        // Mint NFT
        const signer = provider.getSigner();
        const contractWithSigner = contract.connect(signer);

        const resp = await contractWithSigner.createToken(transactionId);
        const rec = await resp.wait();

        alert('Entry created successfully');
      }
    .
    .
    .
```

# Challenge 🏋️

Open `web3/contracts/MirrorClone.sol`, `web3/test/index.test.ts`, `web3/scripts/deploy.ts`, and `components/CreateEntryForm/CreateEntryForm.tsx` in your editor and follow the steps included as comments to finish writing the smart contract, its tests, the deploy script and the NFT minting functionality. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code blocks are also included in the listings below.

##### _Listing 6.5: Instructions for smart contract_
```javascript
function createToken(string memory _tokenURI) public returns (uint) {
    // require statement to check if _tokenURI is not empty

    // Increment counter so it starts with 0

    // Mint token

    // Set token URI

    // Set tokenURIToTokenId

    // Emit TokenMinted event

    // Return new tokenId
}
```

##### _Listing 6.2: Code for tokenURIToTokenId test_
```javascript
// Write a describe block that tests for a 0 return when a token URI doesn't exist in the tokenURIToTokenId mapping
```

##### _Listing 6.3: Code for deployment_
```javascript
async function main() {
  // Deploy MirrorClone smart contract
  // More information can be found here: https://hardhat.org/guides/deploying.html

  console.log('MirrorClone deployed to:', '<CONTRACT ADDRESS>');
}
```

##### _Listing 6.4: Code for minting the NFT when publishing post_
```javascript
const handleSubmit = useCallback(
.
.
.
    try {
      .
      .
      .
      if (provider && contract) {
        .
        .
        .
        // Mint NFT
        // Get signer and connect it to smart contract
        // More information can be found here: https://docs.ethers.io/v5/getting-started/#getting-started--writing

        // Call `createToken` method passing in transactionId
      }
    .
    .
    .
```

Once you have completed the code, creating an entry will mint it as an NFT automatically (once you've confirmed the transaction in MetaMask):

![Screenshot of NFT](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/nft.jpg)

Permanence and censorship-resistance are useful properties of NFTs

Minting an entry NFT 🍬

# Welcome 👋

Welcome to the Mirror Clone tutorial! The goal of this tutorial is to introduce the Web 3 development process in the context of a full stack decentralized application. Specifically, we’ll be bridging you from Web 2 to Web 3 by building a blog similar to [Mirror](https://mirror.xyz/) using a Web 3 stack.

Mirror is a powerful Web 3 platform for publishing content. It allows writers to publish in a decentralized, censorship-resistant way while retaining full ownership of their content. It also enables functionality like tipping writers, splitting proceeds with co-writers and contributors, and crowdfunding projects.

We’ll only be implementing the basics of publishing entries and minting their NFTs, but you’ll end up with a dApp that you can extend as you like. As you build, we’ll introduce key concepts to help you scaffold your mental model and start adding Web 3 skills into your toolbox.

# Prerequisites 🪜

If you know how to program and have [JavaScript](https://www.javascript.com/) experience, you'll be able to complete the tutorial. Having said that, you'll be more comfortable if you have some experience with [Typescript](https://www.typescriptlang.org/), [React](https://reactjs.org/), and [Next.js](https://nextjs.org/). Moreover, while you may not have built full stack Web 3 applications before, hopefully you have used a crypto wallet like [MetaMask](https://metamask.io/) and you're familiar with basic blockchain concepts like public addresses, private keys, and signing transactions.

If any of that sounds unfamiliar, or the idea of engaging with those concepts sounds daunting at this point in your learning, we recommend starting with the [Solana Wallet](https://learn.figment.io/tutorials/solana-wallet-intro) tutorial before completing this one.

It is up to you to choose a code editor that you are comfortable with, although we recommend [Visual Studio Code](https://code.visualstudio.com/) because it is free, packed with useful features and has good cross-platform support.

As always, we think of ourselves as your guide - for a brief amount of time - on your journey to build a better internet. We hope you walk away with a better understanding of what it takes to develop full stack Web 3 decentralized applications (dApps) and perhaps even a bit more confidence to tackle significant projects.

We've tried to show you the door (or maybe part of it). Your job is to discover your path and walk it courageously.

![“I do not believe it to be a matter of hope, it is simply a matter of time.”](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/matrix.jpeg)

{% label %}
“I do not believe it to be a matter of hope, it is simply a matter of time.”

# Tutorial Structure 🧱

The tutorial is structured as a set of steps that break down the development process into specific work blocks on each part of the stack. Each step discusses key concepts and mental models that create the necessary context for you to better understand what we're building and why. Think of this as the **warm up**.

After the warm up we provide a step-by-step implementation of the functionality, including a code snippet of the full solution. While the warm up served to build context, this part serves to guide you through the logic of the **implementation** and helps scaffold your mental model for the feature.

Finally, we **challenge** you to implement the feature on your own by providing just enough instructions. This allows you to exercise [active recall](https://en.wikipedia.org/wiki/Active_recall) and increases your ability to make connections.

# Blog Preview 🖥

By the time you're done, you'll have a blog similar to [Mirror](https://mirror.xyz/). Users will be able to write entries, publish them, mint NFTs for each entry, and transfer those NFTs to other public addresses.

The entries will be saved on [Arweave](https://www.arweave.org/), a decentralized storage solution for immutable data storage, and the NFTs will be [ERC-721](https://eips.ethereum.org/EIPS/eip-721) tokens on [Polygon](https://polygon.technology/), a protocol for scalable Ethereum dApps.

**Step 1** will walk you through some basic set up and configuration. This will include cloning a template repo, so you don't have to write code you're already familiar with (i.e. NextJS). It will also include setting up a few environment variables you'll need in later steps.

In **Step 2**, we'll introduce the [ethers.js](https://docs.ethers.io/) library and learn how to connect a user's MetaMask wallet to the dApp.

![Screenshot of connecting wallet](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/connect.jpg)

Then we'll introduce [Arweave](https://www.arweave.org/) - a decentralized, censorship resistant storage solution - in **Step 3**. We'll write an endpoint to create blog entries and finish a form to submit them. In **Step 4** we'll learn how to fetch them and in **Step 5** we'll write code to display a list of the latest entries.

![Screenshot displaying a list of entries](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/entries.jpg)

**Step 6** will be a brief introduction to smart contracts including inheriting from standard libraries, writing functions, testing them and deploying the smart contract to the Polygon testnet. We'll be minting an NFT for each entry so authors can own their entries.

![Screenshot of NFT](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/nft.jpg)

Finally, **Step 7** will implement functionality that allows authors to transfer NFTs. This sets up the application for expansion into a marketplace for blog entry ownership.

![Screenshot of transfer](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/transfer.jpg)

There are countless ways a dApp like this could be expanded. You could implement the NFT marketplace natively, or you might choose to implement a tipping button for readers who want to reward the writer.

You could even leverage the same smart contracts and Arweave data to restructure the dApp altogether and create a completely new client-side application. Part of what makes Web 3 so powerful is the composability of its stack. There are endless opportunities to get creative and build when data gardens aren't walled and users own their data.

At the end of the tutorial, we'll include a few [additional resources](https://learn.figment.io/tutorials/mirror-clone-conclusion#additional-resources) if you want to dive deeper into these topics or take the next step in your learning journey.

Let's get started!

![All big things come from small beginnings](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/ladder.jpeg)

{% label %}
All big things come from small beginnings


“Reading furnishes the mind only with materials of knowledge; it is thinking that makes what we read ours.”
― John Locke 

Introduction 🎟

Estimate transaction fees

Connect to Secret

Create a subgraph scaffold

How to display Solana account balances on the frontend

Wallet implementation

# Blockchain requests

Crypto wallets serve one primary function - storing your private keys. By storing your private keys, they allow you to manage - transfer, receive, organize - your digital assets. Part of that functionality requires the wallet to retrieve certain data that is stored onchain to display on your user dashboard.

A balance represents a certain amount of cryptocurrency or tokens held by an account. If you think of the blockchain as a database that keeps ownership records, and of the public keys as the owner IDs, then you can think of the balances as an integer column in the database that tracks how much of a certain token each owner holds.

We'll be connecting to one of Solana's networks, and fetching the balance for the account we just created. Later in [Step 4](https://learn.figment.io/tutorials/solana-wallet-step-4), we'll be funding the account with test tokens using the airdrop function.

## Networks

The concept of various networks for a single protocol is similar to that of different environments for an app (e.g. development, test, production, etc). Typically blockchain protocols have a main network or mainnet, which refers to the production blockchain with real economic value and official transactions, and at least one experimentation network, which refers to an identical blockchain used to test features before they go live on mainnet.

![Figure 4: It's always important to test on devnet before deploying on mainnet](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/solana/solana-wallet/assets/consultant.jpeg)

{% label %}
Figure 4: It's always important to test on devnet before deploying on mainnet

Solana has a production network called mainnet and two experimentation networks called testnet and devnet. Solana's devnet is designed for developers and users to play with various features and debug dApps before launching on mainnet with real economic consequences. The testnet is where Solana tests potential protocol updates.

You'll notice the wallet includes a dropdown at the top-right that allows users to select what network they want to connect to. This allows the wallet to manage assets specific to the connected network. Our default network is devnet since we'll be using it to receive test tokens in [Step 4](https://learn.figment.io/tutorials/solana-wallet-step-4) and then transfer them in [Step 5](https://learn.figment.io/tutorials/solana-wallet-step-5), but the functionality we'll build will work for any of the Solana networks.

# Implementation 🧩

In [Step 2](https://learn.figment.io/tutorials/solana-wallet-step-2), we discussed how a wallet is more like a keychain that holds keypairs representing an account address and the key to access it. We built a function that allowed us to generate a unique account and the corresponding phrase that works like a password for accessing the account. Now we need to connect with the Solana blockchain so we can fetch the account's balance, which at this point should be zero because we just created it.

## Connecting

The first step for interacting with any blockchain is to instantiate a connection. Conveniently there's a `Connection` class in web3.js designed to do just that. By reviewing the documentation, we notice the `Connection` constructor requires two arguments: `endpoint: string` and `commitmentOrConfig?: Commitment | ConnectionConfig`.

The description for `endpoint` mentions that it's a "URL to the fullnode JSON RPC endpoint". Since we don't have a URL for the connection, we need to either find one from Solana or look for a function that will return a URL. By searching the web3.js docs for "URL", we see that there's a function called `clusterApiUrl` that returns the "RPC API URL for the specified cluster". Moreover, if we review the `Cluster` type, we see that it refers to the network we want to connect to.

As for `commitmentOrConfig`, it looks like the definition for `Commitment` types describes it as the "level of commitment desired when querying state", which is a meaningless definition to us at this point. However, it looks like `Commitment` can be one of several strings so we should choose one and test the function. In this case, we can choose "confirmed" as a reasonable guess and move forward.

{% sidenote title="Box 3.1: A Note on Technical Sophistication" %}
In his ground-breaking series on software development, Michael Hartl and the [Learn Enough](https://www.learnenough.com/) team introduced the concept of _technical sophistication_ as a key attribute of the technical development process. They define it as "the combination of hard and soft skills that make it seem like you can magically solve any technical problem." Figuring things out and being resourceful is at least half the battle, and sometimes the whole war. When in doubt, refer to the [xkcd flowchart](https://m.xkcd.com/627/).

Putting the above together, we can start implementing the `refreshBalance` function with a connection instance in `utils/index.ts`:

```javascript
const connection = new Connection(clusterApiUrl(network), "confirmed");
console.log(connection)

// console:
> Connection {_commitment: 'confirmed', _confirmTransactionInitialTimeout: undefined, _rpcEndpoint: 'https://api.devnet.solana.com', _rpcWsEndpoint: 'wss://api.devnet.solana.com/', _rpcClient: ClientBrowser, …}
```

## Fetching data

Now that we have a connection, we need to fetch our account's balance. We might speculate that there should be a `getBalance` function that takes an account's public address as a parameter, and returns the account's balance. Searching for the keyword "balance" in the web3.js docs, we can see that, not only is there a `getBalance` method, but it's a `Connection` class method.

Reviewing the `getBalance` method on `Connection`, we can see it expects the account's public key as a parameter.

```javascript
const publicKey = account.publicKey;
const balance = await connection.getBalance(publicKey);
console.log(balance);

// console:
> 0;
```

There are a few ways to structure this part of the function. We've chosen to assign the `publicKey` variable to the account's public key, and then pass that into `getBalance` to query the network for the balance.

From the docs, we know `getBalance` returns a promise so we use `await` and assign its return value to the `balance` variable. By logging `balance`, we can see our account has zero balance as expected.

But that's a bit anticlimactic. We know it's a new account and it should have zero balance. Nothing changed on the frontend because the default value was zero. We need to fund the account to see the balance change, and we'll do just that in [Step 4](https://learn.figment.io/tutorials/solana-wallet-step-4).

##### _Listing 3.2: Code for fetching a balance_
```javascript
const refreshBalance = async (network: Cluster, account: Keypair | null) => {
  if (!account) return;

  try {
    const connection = new Connection(clusterApiUrl(network), "confirmed");
    const publicKey = account.publicKey;
    const balance = await connection.getBalance(publicKey);
    return balance;
  } catch (error) {
    console.log(error);
    return 0;
  }
};
```

# Challenge 🏋️

If you open the browser's console from the `/wallet` page, you'll notice a message that reads, "Balance functionality not implemented yet!". Navigate to `utils/index.ts` in your editor and follow the steps included as comments to finish writing the `refreshBalance` function. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code block is also included in [Listing 3.1](#listing-31-instructions-for-fetching-an-accounts-balance) below.

##### _Listing 3.1: Instructions for fetching an account's balance_
```javascript
// *Step 3*: implement a function that gets an account's balance
const refreshBalance = async (network: Cluster, account: Keypair | null) => {
  // This line ensures the function returns before running if no account has been set
  if (!account) return 0;

  try {
    // (a) review the import guidance on line 1
    // (b) instantiate a connection using clusterApiUrl with the active network passed in as an argument
    // Documentation References:
    //   https://solana-labs.github.io/solana-web3.js/classes/Connection.html
    //   https://solana-labs.github.io/solana-web3.js/modules.html#clusterApiUrl
    console.log("Balance functionality not implemented yet!");
    const connection = "";

    // (c) get the key using one of the accessors on the account passed in as an argument
    // Documentation Reference: https://solana-labs.github.io/solana-web3.js/classes/Keypair.html
    const publicKey = "";

    // (d) get the account's balance using the connection instance
    // Documentation Reference: https://solana-labs.github.io/solana-web3.js/classes/Connection.html
    const balance = 0;

    return balance;
    // (e) You can now delete the console.log statement since the function is implemented!
  } catch (error) {
    console.log(error);
    return 0;
  }
};
```


Step 3: Fetch a Balance ⚖️ 

Transfer some SOL

The previous step left us hanging, since we still have not seen the entry we just created. Let's keep progressing by building an API endpoint to retrieve entries.

# Implementation 🧩

We first need to write another endpoint that will fetch a specified entry for our application. We've structured the endpoint at `pages/api/arweave/[transactionHash].ts`, but we still need to write the core functionality.

Thinking about this endpoint, we should be able to pass in an identifier for a transaction and get the transaction data in response. We can do that by leveraging the `getData` method for Arweave transactions and we can parse the JSON it returns:

```typescript
const txDataResp = (await arweave.transactions.getData(
  transactionHash as string,
  {
    decode: true,
    string: true,
  },
)) as string;
const txData = JSON.parse(txDataResp);
```

We should then check whether the transaction has been confirmed before sending a response to the client.

{% sidenote title="Box 4.1: What does it mean for Arweave transactions to confirm?" %}
As with any distributed system, there is a trade off between speed and being decentralized. In order for the data to be stored, the Arweave protocol has to achieve consensus. You can read more about [Arweave's consensus mechanism](https://arweave.medium.com/what-is-arweave-explain-like-im-five-425362144eb5) but suffice it to say that the lag most databases experience when writing data is exacerbated in distributed storage. That lag is amplified by the fact that data is not only being written over a network but agreed upon across the protocol. This currently takes anywhere from 5-10 minutes.

It will become clear why in Step 6 when we associate NFTs with each entry but, as a preview, we wouldn't want users claiming NFTs before an entry is actually created on Arweave.

Also note that you can choose how many confirmations an entry should receive before considering it confirmed. For this template, we have set the required number of confirmations in `constants.ts` through the `MIN_NUMBER_OF_CONFIRMATIONS` environment variable.

```typescript
const txStatusResp = await arweave.transactions.getStatus(
  transactionHash as string,
);

const txStatus =
  txStatusResp.status === 200 &&
  txStatusResp.confirmed &&
  txStatusResp.confirmed.number_of_confirmations >=
    MIN_NUMBER_OF_CONFIRMATIONS
    ? TransactionStatusE.CONFIRMED
    : TransactionStatusE.NOT_CONFIRMED;
```

Once we've confirmed that our data has been written to Arweave, we can get the transaction by using its identifier from the query parameter `transactionHash`. 

```typescript
const tx = await arweave.transactions.get(transactionHash as string);
```

We should also get the tags, so we have access to the user's address:

```typescript
const tags = {} as PostTagsT;
(tx.get('tags') as any).forEach((tag) => {
  const key = tag.get('name', {decode: true, string: true});
  tags[key] = tag.get('value', {decode: true, string: true});
});
```

And we should get the block, so we have access to the entry's timestamp:

```typescript
const block = txStatusResp.confirmed
  ? await arweave.blocks.get(txStatusResp.confirmed.block_indep_hash)
  : null;
```

With that, we have all the building blocks the client will need to display an entry - entry data, author, and timestamp. We can build the response and return it:

```typescript
res.status(200).json({
  id: transactionHash as string,
  data: txData,
  status: txStatus,
  timestamp: block?.timestamp,
  tags,
});
```

"But we still haven't displayed an entry!", you yell. Yes, we absolutely should do that. We'll get to that in Step 5.

![We're getting very close to some magic.](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/map.jpeg)

{% label %}
We're getting very close to some magic.

##### _Listing 4.1: Code for fetching a post_
```typescript
const {transactionHash} = req.query;
const txDataResp = (await arweave.transactions.getData(
  transactionHash as string,
  {
    decode: true,
    string: true,
  },
)) as string;
const txData = JSON.parse(txDataResp);

const txStatusResp = await arweave.transactions.getStatus(
  transactionHash as string,
);
const txStatus =
  txStatusResp.status === 200 &&
  txStatusResp.confirmed &&
  txStatusResp.confirmed.number_of_confirmations >=
    MIN_NUMBER_OF_CONFIRMATIONS
    ? TransactionStatusE.CONFIRMED
    : TransactionStatusE.NOT_CONFIRMED;

if (txStatus === TransactionStatusE.CONFIRMED) {
  const tx = await arweave.transactions.get(transactionHash as string);

  const tags = {} as PostTagsT;
  (tx.get('tags') as any).forEach((tag) => {
    const key = tag.get('name', {decode: true, string: true});
    tags[key] = tag.get('value', {decode: true, string: true});
  });

  const block = txStatusResp.confirmed
    ? await arweave.blocks.get(txStatusResp.confirmed.block_indep_hash)
    : null;

  res.status(200).json({
    id: transactionHash as string,
    data: txData,
    status: txStatus,
    timestamp: block?.timestamp,
    tags,
  });
} else {
  throw new Error('Transaction not confirmed');
}
```

# Challenge 🏋️

Navigate to `pages/api/arweave/[transactionHash].ts` in your editor and follow the steps included as comments to finish writing the endpoint to retrieve entries. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code block is also included in **Listing 4.2** below.

##### _Listing 4.2: Instructions for fetching a post_
```typescript
const {transactionHash} = req.query;
  // Get Arweave transaction data. Documentation can be found here: https://github.com/ArweaveTeam/arweave-js

  // Get Arweave transaction status. Documentation can be found here: https://github.com/ArweaveTeam/arweave-js
  const txStatus = undefined;
if (txStatus === TransactionStatusE.CONFIRMED) {
  // Get Arweave transaction. Documentation can be found here: https://github.com/ArweaveTeam/arweave-js

  // Get Arweave transaction tags. Documentation can be found here: https://github.com/ArweaveTeam/arweave-js
  
  // Get Arweave transaction block in order to retrieve timestamp. Documentation can be found here: https://github.com/ArweaveTeam/arweave-js

  // Return JSON response in form:
  // res.status(200).json({
  //   id: transactionHash as string,
  //   data: txData,
  //   status: txStatus,
  //   timestamp: block?.timestamp,
  //   tags,
  // });
} else {
  throw new Error('Transaction not confirmed');
}
```


Fetching entries 📬

# Access the Ceramic Pathway

We no longer host the Pathway pages on this website, the content has moved to the `learn-web3-dapp` repository at <https://github.com/figment-networks/learn-web3-dapp#-get-started>.

For less experienced developers or for anyone who wants to dive in without complicated setup, **[we recommend using Gitpod](https://gitpod.io/#https://github.com/figment-networks/learn-web3-dapp)** to work with the `learn-web3-dapp` project (this requires you to have a GitHub account to sign in). Gitpod can save you a considerable amount of time, as you don't have to install dependencies or set up a development environment - everything just works!

If you are an experienced developer, [cloning the repo locally](https://github.com/figment-networks/learn-web3-dapp#-clone-locally) is still possible, however you might encounter various system configuration issues depending on how your local environment is set up. A minimum of NodeJS version 14.17 is recommended, and you'll want to make sure you have the `build-essential` package installed. You'll also want to make sure your Rust toolchain is up to date and that you have the `wasm32-unknown-unknown` target triple set up and installed.


You can now access the Ceramic 101 Pathway on our GitHub repo.

The Ceramic Pathway has moved to learn-web3-dapp

Fund a Polygon account

The Pyth Pathway is available on learn-web3-dapp

Connect to Tezos

You can now access the Polkadot 101 Pathway on our GitHub repo.

The Polkadot Pathway has moved to learn-web3-dapp

Transfer some AVAX

# Not the end

Congratulations! You've built a crypto wallet that is capable of managing on-chain digital assets on the Solana protocol.

## Reflection

By writing a function to generate a mnemonic phrase and using it to create a keypair in [Step 2](https://learn.figment.io/tutorials/solana-wallet-step-2), you gave the wallet access to a unique account. You then implemented functionality to connect to one of Solana's networks and fetch balance data from it in [Step 3](https://learn.figment.io/tutorials/solana-wallet-step-3).

Next, you wrote functionality to request test tokens via an airdrop in [Step 4](https://learn.figment.io/tutorials/solana-wallet-step-4). And after that you sent some of those funds to another account by learning how to initiate and confirm fund transfers in [Step 5](https://learn.figment.io/tutorials/solana-wallet-step-5). Finally, you learned how to recover an account in [Step 6](https://learn.figment.io/tutorials/solana-wallet-step-6) by leveraging the same code we used in [Step 2](https://learn.figment.io/tutorials/solana-wallet-step-2).

In the process of building the wallet, you learned some of the fundamentals of developing for Web 3. You learned how the frontend of the stack is practically identical to what you're already used to. You also learned that interacting with blockchain protocols means leveraging API libraries that help you create, read and update data in a familiar way.

Importantly, you learned just enough about public-key cryptography, crypto wallets, and blockchain concepts like airdrops, keypairs, and mnemonics to unlock a whole world of learning paths to explore next.

## This is the way

Web 3 holds a world of promise for the future of the internet. Moreover, there are vasts areas of greenspace for developers to build amazing things and a ton of low hanging fruit problems to solve.

The opportunities are endless and we wish you well on your journey!

![Figure 10: This is just the beginning, godspeed!](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/solana/solana-wallet/assets/begin.jpeg)

{% label %}
Figure 10: This is just the beginning, godspeed!

# Additional Resources 💻 

- [Figment Learn Pathways](https://learn.figment.io/)
- [Solana Protocol Documentation](https://docs.solana.com/developing/programming-model/overview)
- [Solana Web3.js Documentation](https://solana-labs.github.io/solana-web3.js/)
- [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki): On HD Wallets
- [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki): On Recovery Phrases
- [Why the Blockchain Matters](https://seths.blog/2021/05/why-the-blockchain-matters/) by Seth Godin
- [The Quest for Digital Cash](https://bitcoinmagazine.com/.amp/culture/bitcoin-adam-back-and-digital-cash) by Bitcoin Magazine
- [The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography](https://www.worldcat.org/title/code-book-the-science-of-secrecy-from-ancient-egypt-to-quantum-cryptography/oclc/738479322) by Simon Singh
- [Ethereum Documentation](https://ethereum.org/en/developers/docs/intro-to-ethereum/)
- [Mastering Ethereum: Building Smart Contracts and DApps](https://github.com/ethereumbook/ethereumbook) by Andreas M. Antonopoulos, Gavin Wood


Conclusion 🏁

Liquidation bot implementation

You can now access the Avalanche 101 Pathway on our GitHub repo.

The Avalanche Pathway has moved to learn-web3-dapp

You're about to learn how to develop a wallet for the [Solana](https://solana.com/) protocol. As you build, we'll dive into some of the fundamentals of Web 3 so you can start cultivating an understanding for blockchain technology and decentralized applications (dApps).

# Prerequisites 📋

There are no formal blockchain or Web 3 prerequisites for this tutorial, but you should have some experience with [TypeScript](https://www.typescriptlang.org/) and [React](https://reactjs.org/). Ideally you have heard about [Solana](https://solana.com/), and know that it's a public blockchain protocol capable of running smart contracts with significant scalability advantages.

Having said that, feel free to give it a shot even if you don't meet the above prerequisites since you'll likely get a lot out of it anyway. Just be extra patient because it may be a bit more difficult to navigate.

We think of ourselves as your guide - for a brief amount of time - on your journey to build a better internet. We hope you walk away with a better understanding of Web 3 technologies and perhaps even a bit more confidence to tackle significant problems.

We've tried to show you the door (or maybe part of it). Your job is to discover your path and walk it courageously.

![Figure 1: You take the red pill — you stay in Wonderland and I show you how deep the rabbit hole goes](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/solana/solana-wallet/assets/cat.jpeg?raw=true)

{% label %}
Figure 1: You take the red pill — you stay in Wonderland and I show you how deep the rabbit hole goes

# System dependencies 💻

Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git), [Node](https://nodejs.org/en/) and [yarn](https://yarnpkg.com/getting-started/install) installed.

# Setting up 🧱 

You'll be building Solana interactions on top of a [Next.js](https://nextjs.org/) app that we have pre-built for you. This way you can skip the development phase you're familiar with (e.g. writing React components and Next pages) and dive right into the blockchain-specific phase.

First, clone [the repo](https://github.com/figment-networks/wallet-tutorial) in your system and install the app dependencies by running the following three commands in your terminal:

##### _Listing 1.1: Set up commands to run on your terminal_
```text
$ git clone https://github.com/figment-networks/wallet-tutorial.git
$ cd wallet-tutorial
$ yarn
```

Then, run `yarn dev` in your terminal to start the development server on port 3000. The terminal should print output similar to that in [Listing 1.2](#listing-12-terminal-message-on-app-start-up) informing you that the app is available to be viewed at [http://localhost:3000](http://localhost:3000).

##### _Listing 1.2: Terminal message on app start up_
```text
yarn run v1.22.11
$ yarn dev
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
info  - Using webpack 5. Reason: Enabled by default https://nextjs.org/docs/messages/webpack5
event - compiled successfully
```

# Tutorial structure 🏗 

The tutorial is structured as a set of steps that break down the process of developing the wallet functionality for the pre-built Next.js app. Each step discusses key concepts and mental models that create the necessary context for you to better understand what we're building and why. Think of this as the warm up.

After the warm up, we provide a step-by-step implementation of the functionality including a code snippet of the full solution. After building context with the warm up, this serves as a way for us to guide you through the logic of the implementation and helps scaffold your mental model for the topic.

The implementation is followed by a challenge that aims to give you just enough instructions and references to allow you to implement the functionality on your own if you want to take a shot at it. This allows you to exercise [active recall](https://en.wikipedia.org/wiki/Active_recall) and increases your mind's ability to make connections.

# Wallet preview 🔍

By the time you're done with this tutorial, you'll have a functional wallet capable of changing the state of the Solana blockchain by receiving and transferring onchain funds. In [Step 2](https://learn.figment.io/tutorials/solana-wallet-step-2), we'll generate a 12-word phrase that will grant us access to a wallet.

![](https://github.com/figment-networks/learn-tutorials/blob/master/solana/solana-wallet/assets/create.png?raw=true)

Then we'll build a function to fetch the balance of our newly created wallet in [Step 3](https://learn.figment.io/tutorials/solana-wallet-step-3) before leveraging functionality to issue "test tokens" through something called an "airdrop" that we'll explore in [Step 4](https://learn.figment.io/tutorials/solana-wallet-step-4).

![](https://github.com/figment-networks/learn-tutorials/blob/master/solana/solana-wallet/assets/airdrop.png?raw=true)

Having added funds to our wallet, we'll build the ability to transfer funds to another wallet in [Step 5](https://learn.figment.io/tutorials/solana-wallet-step-5) using bank checks as a scaffolding analogy.

![](https://github.com/figment-networks/learn-tutorials/blob/master/solana/solana-wallet/assets/transfer.png?raw=true)

Finally, we'll use the phrase we generated in [Step 2](https://learn.figment.io/tutorials/solana-wallet-step-2) to recover access to it in [Step 6](https://learn.figment.io/tutorials/solana-wallet-step-6).

![](https://github.com/figment-networks/learn-tutorials/blob/master/solana/solana-wallet/assets/import.png?raw=true)

Although building a production-ready, non-custodial wallet like [Phantom](https://phantom.app/) or [MetaMask](https://metamask.io/) is beyond the scope of this tutorial, by the end of it you'll have developed a foundation of judgment that will let you better allocate your learning time as you explore new projects. To assist with that, we'll end the tutorial with a list of [additional resources](https://learn.figment.io/tutorials/solana-wallet-conclusion#additional-resources) that you'll be well prepared to explore.

![Figure 2: A journey of a thousand miles begins with a single step](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/solana/solana-wallet/assets/journey.jpeg?raw=true)

{% label %}
Figure 2: A journey of a thousand miles begins with a single step


“Any fool can know. The point is to understand.”
― Albert Einstein

Step 1: Getting Up and Running 🏃

You can now access the Celo 101 Pathway on our GitHub repo.

The Celo Pathway has moved to learn-web3-dapp

Connect to NEAR

Get data from the program

# Wrapping up 🎁

Congratulations! You've built a Web 3-native blog that resembles the functionality of [Mirror](https://mirror.xyz/).

By leveraging a handful of protocols and tools like Polygon, Arweave, Hardhat, ethers.js, and ArDB, you were able to quickly build a full stack distributed application (dApp). In **Step 1** we leveraged a Next.js template to scaffold a simple application & we immediately got to work on turning it into a dApp. In **Step 2** we built functionality to connect to a user's MetaMask wallet.

We then gave our users the ability to publish entries by sending data to Arweave in **Step 3**. Not only that but since Arweave stores data forever (or pretty much forever), we gave our users the ability to publish censorship-resistant, immutable entries over which they have full control.

Expanding from write to read functionality, in **Step 4** we implemented the application's fetch function that retrieves data from Arweave by leveraging a transaction id and the address tag on our Arweave application deployment. This allowed us to display individual entries using the transaction id in the URI parameters.

In **Step 5**, we implemented similar functions to fetch the last 10 entries and display them on the dApp's home page. By clicking on these, users call the functionality implemented in **Step 4** to display individual entries.

Not satisfied with a simple blog, and keen to explore the possibilities provided by the economics layer native to crypto rails, we established a smart contract to mint and manage NFTs for each entry in **Step 6**. The contract automatically mints an NFT owned by the author when the entry is published. This gives authors full control of their content while it is in their possession. 

Finally, **Step 7** completed the NFT feature by giving users the ability to transfer their NFTs. An author can choose to transfer their entry's NFT by clicking a button and providing the recipient's address. Thereafter, the NFT owner can do the same with any other user.

In the process of building the blog, we learned how to connect a Web 3 wallet to effectively authenticate a user on the basis of their ownership of an account. We also expanded our understanding of Web 3 primitives like providers, signers and NFTs. 

Moreover, we learned how the frontend of the stack is similar to the Web 2 stack you're used to. We expanded our backend toolbox by interacting with Arweave for storage and Polygon for tracking NFT ownership. And we became familiar with ethers.js, one of the JavaScript libraries for connecting a user's wallet to dApps and interacting with blockchain protocols.

Web 3 offers developers a new world in which to build the future of the internet and re-imagine what is possible. It expands the building blocks offered by the underlying technology and in so doing enhances your ability to create new, innovative applications to solve worthwhile problems. 

The opportunities are endless and we wish you well on your journey!

![With ten miles behind me and ten thousand more to go…](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/hike.jpeg)

{% label %}
With ten miles behind me and ten thousand more to go…

# Additional Resources 📚

- [Mirror's Blog](https://dev.mirror.xyz/)
- [Arweave Overview](https://www.arweave.org/technology)
- [Arweave Lightpaper](https://www.arweave.org/files/arweave-lightpaper.pdf)
- [OpenZeppelin](https://openzeppelin.com/)
- [Hardhat](https://hardhat.org/)
- [Ethereum Virtual Machine](https://ethereum.org/en/developers/docs/evm/)
- [Solidity by Example](https://solidity-by-example.org/)

Wrapping up and reflecting on what we've learned

Conclusion 🎓

Create a keypair

You can now access the Solana 101 Pathway on our GitHub repo.

The Solana Pathway has moved to learn-web3-dapp

{% hint style="info" %}
Feel Free to skip this section and [**start the challenges**](https://learn.figment.io/tutorials/setup-the-secret-project)
{% endhint %}

------------------------

# What is Secret?

Secret Network is the first blockchain with privacy-preserving smart contracts. That means applications built on Secret can utilize encrypted data without revealing it to anyone, even the nodes in the network. For the first time, Secret Network allows developers to build powerful, permissionless, privacy-preserving applications - Secret Apps.

Secret Apps - powered by “secret”, privacy-preserving smart contracts - are built with CosmWasm smart contracts that are written in the Rust programming language and deployed on the Secret Network.

The Secret Network blockchain itself is based on Cosmos SDK / Tendermint, meaning the network has its own independent consensus, on-chain governance, and features like slashing and delegation.

## Why build on Secret?

Secret Network combines the best features of decentralized, open-source networks, and blockchains with the benefits of data privacy and improved usability. These improvements are critical for achieving mass adoption.

Developers can enjoy the benefits of smart contracts and DApps: they are robust, unstoppable, censor-resistant, and transparent. But blockchains, and by extension smart contracts have one glaring problem that is often overlooked - all data stored on them is public. In that sense, blockchains are worse than existing Web 2 solutions when it comes to privacy.

Instead of trusting your data with a single organization, you now have to trust everyone. Secret contracts and Secret Apps combine these benefits of DApps but add the ability to keep data private, helping remove one of the biggest barriers to mass adoption of the decentralized web.

## What can you build on Secret?

As the first blockchain to support encrypted inputs, encrypted outputs, and encrypted state for smart contracts, Secret Network allows for new kinds of powerful decentralized applications to be built. This can unlock substantial value across multiple verticals and industries, including the following:

* Decentralized Finance: Support for privacy-preserving asset transfers, lending, and more
* Data sharing: Sharing and monetizing data while keeping it secure
* Machine learning: Discovering powerful insights while protecting underlying data
* Healthcare: Allowing research over encrypted data, driving innovation
* Gaming Industry: Enabling more open and more usable gaming experiences

# Network Specifications

## Transaction Fees

Transaction fees are currently paid in the native token, SCRT. Since the Secret Network can handle many transactions quickly and the demand for transactions is low, the current cost of Secret transactions is very low (ie. almost nothing).

## Transaction Speed & Finality

Tendermint BFT typically have block times between 1 and 8 seconds, and can handle up to thousands of transactions per second. The Secret Network has a block time of about 7.25 seconds per block.

A property of the Tendermint consensus algorithm is instant finality. This means that forks are never created as long as more than a third of the validators are honest [**Byzantine**](https://en.wikipedia.org/wiki/Byzantine_fault). Users can be sure that their transactions are finalized as soon as a block is created, unlike Proof-of-Work blockchains, like Bitcoin and Ethereum.

## Languages supported

Secret Contracts are developed with the Rust programming language and compiled to WebAssembly ([WASM](https://rustwasm.github.io/docs/book/)) binaries.

## EVM compatibility

The Secret Network has launched a bridge with Ethereum, bringing cheaper and more usable privacy to Ethereum and Ethereum-based assets. It allows users to create synthetic (wrapped) ETH and ERC-20 tokens on Secret Network that can be used with full privacy, at a lower cost.

The bridge is bidirectional, so Secret Tokens can then be redeemed for their Ethereum-based equivalent.

## Role of the SCRT token

The SCRT is the token that: 
1. secures the Secret Network as the asset at stake, which earns its stakers new issuance rewards and transaction fees.
2. is used to pay for transactions on the network.
3. is used by stakers to vote on-chain to set Secret Network policy.


What is Secret?

Get account balance

Traditional blogs use databases to persist an entry. An author might write some content and publish it, which triggers a create action on the server that writes the data to the database. The database would have schema that define the data structure. For instance, we might have an **entries** table with columns for entry id, content, and author id.

The blockchain, however, is a bit different because it's decentralized. Rather than writing to a specific database, we'll be leveraging a distributed system that cannot be controlled by a central authority.
  
# Sustainable, Decentralized Storage 💾

[Arweave](https://www.arweave.org/) is a decentralized network that allows users with extra storage space to provide that space as storage to the network in exchange for economic incentives. Users looking to store data in a decentralized, secure, censorship-resistant way, can leverage the network to do so. Effectively, Arweave is the storage part of the stack for dApps.

Arweave uses a technology called "blockweaves" to achieve this. Similar to a blockchain, which connects transactions in a main chain across blocks, blockweaves are connected blocks that contain data. One of the main differences is that rather than connect blocks as a singly linked list, blockweaves are more like graphs.

This system requires a robust and sustainable economic structure to ensure storage providers are incentivized to replicate information forever at reasonable costs to the user. Basically, the user pays a small fee upfront to permanently store data. That fee is treated as principal that generates interest over time for storage providers.

The architecture to achieve all this is beyond the scope of this tutorial, but if you're interested in going deeper, we recommend checking out the [Arweave yellow paper](https://www.arweave.org/yellow-paper.pdf).

![Like this but decentralized...](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/storage.jpeg)

{% label %}
Like this but decentralized...

# Implementation 🧩

There are several ways to interact with Arweave. In our case we're going to use a faucet program from Arweave that allows us to create an Arweave wallet and fund it with just enough tokens to get us going.

{% sidenote title="Box 3.1: What's a faucet?" %}
Faucets are smart contracts that transfer a limited amount of tokens to users for testing purposes. Most protocols implement faucets to facilitate developers' testing and building efforts.

# Arweave Wallet 👜

Go to the [Arweave mainnet faucet](https://faucet.arweave.net/) and follow the instructions to create a wallet. Make sure you download the JSON file at the end of the process. Re-name that file to `arweave-wallet.json` and save it at the root of the project. You'll notice we have included this in the `.gitignore` to prevent exposing any private information.

Once you've saved the JSON file to the root, we should stop the local server in our terminal (press CTRL+C in the terminal window where the server is running). Then we can initialize the `ARWEAVE_WALLET` environment variable in the command line and run the local server again:

```text
$ ARWEAVE_WALLET=$(cat arweave-wallet.json) yarn dev
```

# Posting to Arweave 📨

With the Arweave wallet in place, we can now develop an endpoint to create entries. In `pages/api/arweave/entry.ts`, we have a skeleton endpoint for us to add the Arweave write logic. You'll notice that we're passing in `req.body` which includes data and address fields. The data in this case will be the entry's text and the address will be the author's public address. In the file `routes.ts` you can see how the routes are defined. 

First we need to initialize the wallet by using `JSON.parse`:

```typescript
const wallet = JSON.parse(process.env.ARWEAVE_WALLET as string);
```

We should also instantiate a transaction by leveraging [Arweave's JavaScript library](https://github.com/ArweaveTeam/arweave-js) and passing in the data and the wallet.

```typescript
const transaction = await arweave.createTransaction({data: data}, wallet);
```

Next, we'll want to add tags as the metadata that will associate the data with our dApp and with the author. We should also include a tag denoting the data as "application/json".

```typescript
transaction.addTag('App-Name', process.env.APP_NAME as string);
transaction.addTag('Content-Type', 'application/json');
transaction.addTag('Address', address);
```

Then, we want to sign the transaction and post it to Arweave:

```typescript
await arweave.transactions.sign(transaction, wallet);
await arweave.transactions.post(transaction);
```

You'll notice that Arweave's syntax is pretty straightforward. The only new aspect of this workflow is the signing piece, which is required to authenticate the transaction as valid.

To finish the endpoint, we'll want to return the transaction id as part of the response:

```typescript
res.status(200).json(transaction.id);
```

# Finishing the Form 📝

Now we need to make use of our entry endpoint. To do that, we need to go to `components/CreateEntryForm/CreateEntryForm.tsx` and finish the `handleSubmit` function.

In order to submit the Arweave transaction that creates the entry, we can use [axios](https://axios-http.com/docs/intro) to call the `entry` endpoint we wrote above. We should pass in the data and address as part of the request body, and we should store the return value - the transaction id - in a variable as well. We'll need the transaction id later when we incorporate the NFT functionality into our dApp.

```typescript
const response = await axios.post(routes.api.arweave.post, {
  data,
  address,
});
const transactionId = response.data;
console.log('transactionId: ', transactionId);
```

With that complete, our users are able to create entries that will live forever on the Arweave blockchain! You can create an entry yourself and confirm that the `transactionId` is printed in the console.

There's one issue though. Even though we can create an entry, we can't see it in our dApp yet. We'll address that shortly, but first we need an endpoint to fetch entries. We'll tackle that next in Step 4.

##### _Listing 3.1: Code for creating a entry endpoint_

```typescript
export default async function (
  req: NextApiRequest,
  res: NextApiResponse<string>,
): Promise<any> {
  try {
    const {data, address} = req.body;

    const wallet = JSON.parse(process.env.ARWEAVE_WALLET as string);
    const transaction = await arweave.createTransaction({data: data}, wallet);

    transaction.addTag('App-Name', process.env.APP_NAME as string);
    transaction.addTag('Content-Type', 'application/json');
    transaction.addTag('Address', address);

    await arweave.transactions.sign(transaction, wallet);
    await arweave.transactions.post(transaction);
    res.status(200).json(transaction.id);
  }
  ...
}
```

##### _Listing 3.2: Code for handling entry submission_

```typescript
if (provider && contract) {
  const data = createJsonMetaData(values);

  const response = await axios.post(routes.api.arweave.post, {
    data,
    address,
  });
  const transactionId = response.data;
  console.log('transactionId: ', transactionId);
}
```

# Challenge 🏋️

Navigate to `pages/api/arweave/entry.ts` and `components/CreateEntryForm/CreateEntryForm.tsx` in your code editor and follow the steps included as comments to finish writing the create entry functionality. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code block is also included in **Listing 3.3** and **Listing 3.4** below.

##### _Listing 3.3: Instructions for creating a entry endpoint_

```typescript
export default async function (
  req: NextApiRequest,
  res: NextApiResponse<string>,
): Promise<any> {
  try {
    const {data, address} = req.body;

    // Initialize wallet using ARWEAVE_WALLET environmental variable (Tip: Use JSON.parse)

    // Create Arweave transaction passing in data. Documentation can be found here: https://github.com/ArweaveTeam/arweave-js

    // Add tags:
    // - App-Name - APP_NAME environmental variable
    // - Content-Type - Should be application/json
    // - Address - Address of a user
    // Documentation can be found here: https://github.com/ArweaveTeam/arweave-js

    // Sign Arweave transaction with your wallet. Documentation can be found here: https://github.com/ArweaveTeam/arweave-js

    // Post Arweave transaction. Documentation can be found here: https://github.com/ArweaveTeam/arweave-js

    // Return transaction id
  }
  ...
}
```

##### _Listing 3.4: Instructions for handling entry submission_

```typescript
if (provider && contract) {
  const data = createJsonMetaData(values);
  // Submit Arweave transaction
  // Use axios to post data and address to api/arweave/entry endpoint.
  // This request should return transactionId

  // Stop here when you complete Step 3 ^^^^
  ...
}
```

Once you have completed the code, you will want to try out creating an entry by clicking on the **Create Entry** button on the Dashboard, then entering a title and some text.

![Screenshot displaying a list of entries](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/entries.jpg)

Writing an entry ✍️

Using the Orca SDK to swap tokens on Solana devnet

Token swaps on a DEX

Connect to Polkadot

Transfer some NEAR

You can now access the Secret 101 Pathway on our GitHub repo.

The Secret Pathway has moved to learn-web3-dapp

Export tokens from X-Chain to C-Chain

Import tokens from X-Chain to C-Chain

# Crypto gateway

Crypto wallets are the most critical piece of user-facing infrastructure in the blockchain space. In the same way that the browser brought the web to a mass audience by providing an easy-to-use gateway into the underlying servers and databases, wallets provide users with an easy-to-use gateway into blockchain protocols.

A wallet is less like the wallet you use for your credit cards, and a lot more like a keychain. If you think of a blockchain as a giant bank safe with digital safety deposit boxes, wallets are the keychains where you keep the key to your box. Once you have access to a box, you can manage the contents of it by receiving, sending, holding and spending digital assets.

![Figure 3: Wallets hold private keys to your public address on a blockchain](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/solana/solana-wallet/assets/safe.jpeg?raw=true)

{% label %}
Figure 3: Wallets hold private keys to your public address on a blockchain

We can think of the box itself as a chunk of memory on the blockchain. The digital box location is referred to as a public key, or more intuitively as a public address, and can be shared with anyone in the same way you might share your address to receive mail at home. As the name implies, this is widely available to others on the network and it is the identifier others use to send digital assets to a box.

The key that can unlock the safety deposit box is referred to as the private key. Anyone with access to a box's private key has access to the box, which is why it's paramount to keep the key private - hence the name, private key.

# HD wallets

In this tutorial, we'll be building a type of wallet called a Hierarchical Deterministic (HD) wallet. We don't need to dive into the full definition of HD wallets here, but it's important to know that they enable the ability to store the private key as a 12-, 18-, or 24-word phrase referred to as a secret recovery phrase or mnemonic phrase. You'll be using a JavaScript library called [Bip39](https://github.com/bitcoinjs/bip39) to facilitate the generation of this phrase, which in turn can be converted into a private key to create a wallet.

{% sidenote title="Box 2.1: Why is the secret recovery phrase also called a mnemonic?" %}
The concept of a mnemonic phrase was introduced by Bitcoin Improvement Proposal 39 (BIP39). The term "mnemonic" refers to a pattern that makes something easier to remember. For instance, some of you might be familiar with the order of operations mnemonic in math: PEMDAS, or "please excuse my dear aunt Sally". The motivation for BIP39 was that "a mnemonic code or sentence is superior for human interaction compared to the handling of raw binary or hexadecimal representations of a wallet seed."

Run and open the app in your browser at [http://localhost:3000](http://localhost:3000). You'll notice the frontend offers the user the option to create a new wallet or import an existing wallet.

Clicking on **Create New Wallet** routes the user to a `/generate` page signaling to our user that by clicking **Generate**, the app will generate a key phrase and thus create a new wallet. But when we click **Generate**, we're routed to a `/phrase` page with an empty phrase container.

# Implementation 🧩

For the app to work, we need to implement a function that generates a phrase and uses it to create a wallet when the `/phrase` page renders. In your editor, navigate to `pages/phrase.tsx`.

In order to generate the phrase, we need to leverage an external library that satisfies the [BIP39 specification](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki), which set the standard for generating phrases for deterministic keys. 

Fortunately, there's the [Bip39 library](https://github.com/bitcoinjs/bip39). It provides us with the functionality we need to generate the phrase and later convert it into the seed we need to generate our Solana wallet keys.

We already installed the library when we ran `yarn` during set up because we included it into the pre-built app's [package.json](https://github.com/figment-networks/wallet-tutorial/blob/main/package.json). So all we need to do is import it:

```javascript
import * as Bip39 from "bip39";
```

## Recovery phrase

Recall that secret recovery phrases are also called mnemonics and Bip39 includes the method `generateMnemonic()` for generating mnemonic phrases. We can call it and replace the variable currently assigned to an empty string:

```javascript
const generatedMnemonic = Bip39.generateMnemonic();
```

This allows us to set the phrase in state and display it for our user to write down and store safely. With this step we have effectively created our wallet because the phrase by itself will allow its holder to access the account that matches it.

{% sidenote title="Box 2.2: The conservation of blockchain accounts" %}
Even though most of the community refers to accounts as being created, technically blockchain accounts can't be created or destroyed. These accounts are mathematical addresses in a system where their existence is established mathematically at inception by the system's architecture. It's more accurate to think of the mnemonic as obtaining the key to access a pre-existing, empty account.

## Keypairs and seeds

Before we can connect to the account on the blockchain, however, we need to convert the phrase into a form that the blockchain can understand. After all, mnemonic phrases are abstractions that translate a long, archaic number into a more human-friendly form.

We need to convert the phrase into bytes so the Solana web3.js library can use it to generate a `keypair` object. The `keypair` will be the wallet account consisting of a public key that can encrypt data and a private key that can decrypt data.

{% sidenote title="Box 2.3: Public-key cryptography" %}
At a high-level public-key cryptography is a cryptographic system that uses keypairs to transmit information securely. Each keypair consists of a public key, which is widely known across the system, and a private key, which should be kept secret by its owner. Suppose Bob wants to send a secure message to Alice while ensuring that, even if Eve intercepts it, she can't read it. Bob would encrypt the message using Alice's public key and then send the message. Because of something called a one-way function, the public key cannot be used to decrypt the message. The only way the message can be decrypted is with the private key that complements the public key used by Bob - that is, the private key that Alice holds. Bob can rest assured that no one but Alice will be able to read the message. The ability to encrypt information without the need to pre-share symmetric keys was a massive technological development. And the history behind these breakthroughs is well worth studying if you're so inclined. We've included a few suggestions as additional resources at the end of the tutorial.

By reviewing Solana's web3.js [documentation](https://solana-labs.github.io/solana-web3.js/index.html), we see that there's a `Keypair` class defined as "an account keypair used for signing transactions." This is exactly what we need to generate using the mnemonic phrase.

We notice that the `Keypair` class has a `fromSeed` method that generates a keypair from a 32-byte seed. It also mentions that the seed needs to be a `Uint8Array`, which means we'll need a way to convert our `string` phrase into a `Uint8Array`.

Going back to the Bip39 library we see a method called `mnemonicToSeedSync(mnemonic)` that returns some sort of `Buffer` object that looks like a list of hexadecimal numbers. We can test this by running it in our application and passing in the mnemonic we generated:

```javascript
const seed = Bip39.mnemonicToSeedSync(generatedMnemonic);
console.log(seed)

// console:
> Uint8Array(64);
```

It looks like we're close. The `Keypair` class requires a 32-byte `Uint8Array` and we're getting a 64-byte `Uint8Array`. We can slice the seed and keep only the first 32 bytes:

```javascript
const seed = Bip39.mnemonicToSeedSync(generatedMnemonic).slice(0, 32);
console.log(seed)

// console:
> Uint8Array(32);
```

With the seed in the right format, we can use `Keypair`'s `fromSeed` method to generate an account keypair:

```javascript
const newAccount = Keypair.fromSeed(seed);
```

We then set the account into context state and we have access to a Solana wallet.

Once you implement the functionality, make sure you save the recovery phrase before you click **Finish** on the browser. We'll be using it in [Step 6](https://learn.figment.io/tutorials/solana-wallet-step-6) to access the wallet once after logging out. 

Once you click on **Finish**, you'll be routed to the wallet page that displays the account's dashboard. You'll notice this page includes a few other features. We'll discuss the Network dropdown in [Step 3](https://learn.figment.io/tutorials/solana-wallet-step-3) while implementing the crucial functionality of showing users their balance.

In [Step 4](https://learn.figment.io/tutorials/solana-wallet-step-4) we'll dive into airdrops and make the **Airdrop** button functional, and in [Step 5](https://learn.figment.io/tutorials/solana-wallet-step-5) we'll enable the **Send** button and transfer funds.

##### _Listing 2.2: Code for creating a wallet_
```javascript
const generatedMnemonic = Bip39.generateMnemonic();
setMnemonic(generatedMnemonic);

const seed = Bip39.mnemonicToSeedSync(generatedMnemonic).slice(0, 32);
const newAccount = Keypair.fromSeed(seed);
setAccount(newAccount);
```

![](https://github.com/figment-networks/learn-tutorials/blob/master/solana/solana-wallet/assets/dashboard.png?raw=true)

# Challenge 🏋️ 

In your editor, navigate to `pages/phrase.tsx` and follow the steps included as comments to finish writing the function. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code block is also included in [Listing 2.1](#listing-21-instructions-for-generating-a-phrase-and-creating-a-wallet) below.

##### _Listing 2.1: Instructions for generating a phrase and creating a wallet_
```javascript
useEffect(() => {
  // *Step 2*: implement a function that generates a mnemonic when the page renders, and uses it to create a wallet (i.e. account)
  // (a) review the import guidance on lines 9 and 11
  // (b) generate a mnemonic phrase by importing Bip39 and then implementing the appropriate method on the imported Bip39 instance
  // Documentation Reference: https://github.com/bitcoinjs/bip39
  const generatedMnemonic = "";

  // This line saves the mnemonic phrase to context state so we can display it for the wallet user to copy
  setMnemonic(generatedMnemonic);

  // (c) convert the mnemonic to seed bytes and make sure it's 32-bytes (Hint: console log the seed to see how many bytes you have vs how many you need)
  // Documentation Reference: https://github.com/bitcoinjs/bip39
  const seed = new Uint8Array();

  // (d) use the seed to generate a new account (i.e. a new keypair)
  // Documentation Reference:
  //   https://solana-labs.github.io/solana-web3.js/classes/Keypair.html
  //   https://solana-labs.github.io/solana-web3.js/classes/Keypair.html#fromSeed
  const newAccount = null;

  // This line sets the account to context state so it can be used by the app
  setAccount(newAccount);
}, []);
```


Defining a crypto wallet and how it works

Step 2: Create a Wallet 💼

Fund the account with SOL

The first step for any dApp is setting up a way to connect to a user's wallet. This allows the dApp to authenticate the user without using traditional passwords. More importantly, this will allow the dApp to pull the user's onchain data so we can build user-specific dApp experiences.

{% sidenote title="Box 2.1: A note on crypto wallets" %}
Crypto wallets are the gateway through which users interact with blockchain protocols. The wallet locally stores a user's private keys encrypted by a password and allows the user to sign transactions that prove control of an account's keys in a trustless way. Developers can leverage this technology to authenticate users and build applications where users control their own data in a portable way. For a more in-depth look at wallets, check out the [Solana Wallet](https://learn.figment.io/tutorials/solana-wallet-intro) tutorial.

In this case, we'll be using a JavaScript library called [ethers.js](https://docs.ethers.io/) to interact with a user's browser extension wallet like MetaMask. This will allow us to detect whether the wallet is installed, and access the user account's API for getting its data and leveraging its functionality.

# Implementation 🧩

The first step in performing any blockchain operation is typically instantiating a connection. This can be accomplished with the **Providers** class in ethers.js. A Web 3 provider object includes functionality to read from a protocol.

If you're familiar with React development, you can probably guess that we'll need a way to preserve application state after we connect to the wallet. That way we don't have to make the user re-connect their wallet every time the page is rendered. For this, we'll use React's [Context](https://reactjs.org/docs/context.html).

There are several ways to implement this, but in our case we'll be using a context provider (not to be confused with the Web 3 provider!) we built into our template in `context/web3Context.tsx`. 

If we look at the Web3Provider function, notice we're using a simple implementation with the ethers.js **Web3Provider**:

```typescript
const provider =
    typeof window == 'undefined' || !window.ethereum
      ? null
      : new ethers.providers.Web3Provider(window.ethereum);
```

Focusing on the last line, notice that we're instantiating a provider based on `window.ethereum`. That object comes [courtesy of MetaMask](https://docs.metamask.io/guide/ethereum-provider.html), so we can pass it in as an argument to instantiate our Web 3 provider object. The rest of the code is simply checking whether the MetaMask extension is present, so the dApp still runs even if there isn't one. 

Once we have a Web 3 provider, we can use the provider's `send` method to request the accounts associated with the wallet we want to connect (it's good to learn about how [Hierarchical Deterministic wallets](https://docs.ethers.io/v5/api/utils/hdnode/) work). Then we can instantiate a **Signer** object that will give us access to functions that allow us to change the state of the blockchain.

In our case, we have a `connect` function that first checks whether a provider is present, and then should get our user's public address and set it in the app state using a React hook: `setAddress`. We've included a check for the chainId, to ensure that users are connected to the Mumbai testnet - every blockchain network uses a unique chain identifier, to prevent transactions from one blockchain being replayed on another. Also, if the user doesn't have MetaMask installed it should alert them to install it.

We can complete this function with four simple lines. First, we need to request the accounts available in the MetaMask provider. Then we need to instantiate a signer that will then give us access to methods to get the user's current address and the chainId. 

```typescript
await provider.send('eth_requestAccounts', []);
const signer = provider.getSigner();
const currentAddress = await signer.getAddress();
const chainId = await signer.getChainId();
```

{% sidenote title="Box 2.2: Without centralized servers, what are we connecting to?" %}
Going deep into something like the Ethereum Virtual Machine is beyond the scope of this tutorial, but this question is critical if you want to better understand the backend you're building on. Instead of connecting to a specific server and reading from a database, we're reading from a distributed state machine. It's distributed because there are lots of nodes all over the world holding the same state. It's a state machine because it's in one state at any given time. We interact with it and compete with others using it to update a slice of its state that will get recorded before the next cycle of state updates. _Don't confuse the state of the EVM with the state of a React app, they're similar concepts but not the same thing!_

Putting these four lines together with our `connect` function and understanding that our custom hook is already in use, our users should now be able to connect by clicking on the **Connect Wallet** button at the top right.

![Forget logins, now our users can connect to our app with their wallets!](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/wallet.gif)

{% label %}
Forget logins, now our users can connect to our app with their wallets!

##### _Listing 2.1: Code for connecting a wallet_
```typescript
const connect = useCallback(async () => {
  if (provider) {
    await provider.send('eth_requestAccounts', []);
    const signer = provider.getSigner();
    const currentAddress = await signer.getAddress();
    const chainId = await signer.getChainId();

    if (chainId != (80001 as number)) {
      alert('Please connect to the Polygon Mumbai testnet in MetaMask!')
    }

    setAddress(currentAddress);
  } else {
    alert('Please install MetaMask at https://metamask.io');
  }
}, [provider]);
```

# Challenge 🏋️

Navigate to `context/web3Context.tsx` in your code editor and follow the steps included as comments to finish writing the `Web3Provider` function. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code block is also included in **Listing 2.2** below.

##### _Listing 2.2: Instructions for connecting a wallet_
```typescript
const connect = useCallback(async () => {
  if (provider) {
    // Request accounts, get signer, signers address & chainId
    // More information can be found at https://docs.ethers.io/v5/getting-started/#getting-started--connecting

    const currentAddress = '';
    const chainId = 0;

    if (chainId != (80001 as number)) {
      alert('Please connect to the Polygon Mumbai testnet in MetaMask!')
    }

    // Read more about React hooks: https://reactjs.org/docs/hooks-intro.html
    // The setAddress React hook sets the value of address in the app state
    setAddress(currentAddress);
  } else {
    alert('Please install MetaMask at https://metamask.io');
  }
}, [provider]);
```

 Once you've completed the code, you will want to try connecting your MetaMask wallet by clicking on the **Connect Wallet** button in the top right corner of the screen:

 ![Screenshot of connecting wallet](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/connect.jpg)


Connecting a wallet 🔌

Query Polygon

You can now access The Graph + NEAR Pathway on our GitHub repo.

The Graph + NEAR Pathway has moved to learn-web3-dapp

One of the key tenets of Web 3 is composability, so you can think of this step as a precursor for a more advanced blog entry marketplace. Maybe you or someone else wants to build a dApp that allows people to buy and sell blog entry ownership.

Because the Web 3 stack is decentralized, it means data no longer lives behind a walled garden where the app owners control access and own the data. In Web 3 users retain not only ownership over the data, but the ability to port their data to other UIs that can access it directly from the blockchain.

![Hooray! No more walled gardens for data](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/free.jpeg)

{% label %}
Hooray! No more walled gardens for data

# Implementation 🧩

In order to make each entry's NFT transferable, we need to write a function that activates the blue **Transfer NFT** button shown on each entry's page. If we go to the `TransferNFTForm.tsx` component, we see a `handleSubmit` button with some simple instructions to connect the smart contract to a signer, and to call `transferFrom` on the smart contract.

Recall from Step 6 that we can instantiate a signer by calling `getSigner` on `provider`. Recall also that we can connect the `signer` to the `contract` as well, so we can use that code here to connect the smart contract and the signer at the top of `handleSubmit`:

```typescript
const signer = provider.getSigner();
const contractWithSigner = contract.connect(signer);
```

# Transferring an NFT ♻️

Now all that's left is calling the `transferFrom` function in the contract. You might be wondering where that function is since we didn't write it in Step 6 when we finalized the `MirrorClone.sol` contract.

The `transferFrom` function actually comes from the ERC721 standard. We inherited the function from the OpenZeppelin ERC721 contract, which means we can call it anytime even though we didn't explicitly write it in our contract. If you open `node_modules/@openzeppelin/contracts/token/ERC721/ERC721.sol`, on line 152 you can see the function requires a from address, a to address, and a tokenId.

Note that it is preferable in many cases to use the `safeTransferFrom` method because otherwise it is possible to send an NFT to an address that is unaware of the ERC721 protocol and is therefore not guaranteed to be able to handle the NFT properly. This is an advanced topic, so for the purposes of this tutorial `transferFrom` will suffice.

We can complete the `handleSubmit` function by calling `transferFrom` on our `contractWithSigner`:

```typescript
const resp = await contractWithSigner.transferFrom(
  address,
  recipient,
  tokenId,
);
const rec = await resp.wait();

console.log(rec);
```

With that in place, we can now test it by transferring the NFT. You should create another account inside your MetaMask wallet by clicking the big colorful button on the top right and then clicking "Create Account".

Once you do this, you'll have another public address controlled by your private key. Copy that address and paste it into the **Recipient Address** field. Then go back to your original account and click **Transfer NFT**.

After accepting the transaction on MetaMask, your second account will own the entry (once the transaction is confirmed)!

##### _Listing 7.1: Code for transferring an NFT_
```typescript
const handleSubmit = useCallback(
  .
  .
  .
  // Connect smart contract to signer
  const signer = provider.getSigner();
  const contractWithSigner = contract.connect(signer);

  // Call `transferFrom` method of smart contract
  const resp = await contractWithSigner.transferFrom(
    address,
    recipient,
    tokenId,
  );
  const rec = await resp.wait();

  console.log(rec);
  .
  .
  .
);
```

# Challenge 🏋️

Navigate to `components/TransferNFTForm/TransferNFTForm.tsx` in your code editor and follow the steps included as comments to finish writing the `handleSubmit` function for transferring NFTs. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code block is also included in **Listing 7.2** below.

##### _Listing 7.2: Instructions for transferring an NFT_
```typescript
const handleSubmit = useCallback(
  .
  .
  .
  // Connect smart contract to signer
  // Call `transferFrom` method of smart contract
  .
  .
  .
);
```

Once you have completed the code, you can try transferring an entry NFT by pasting the address of the account you want to transfer the NFT to into the textinput, then clicking on **Transfer NFT** and confirming the transaction in MetaMask:

![Screenshot of transfer](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/mirror/assets/transfer.jpg)

It's time to share what you have created with others

Transferring an NFT ♻️

# What is Avalanche?

Avalanche is a layer one protocol by Ava Labs that offers high-throughput, fast finality, and unprecedented decentralization. Developers are able to launch their own public or private blockchains (called subnets), create and trade digital assets, and build scalable smart contracts and decentralized applications.

Subnets within the Avalanche network will be highly customizable and will have their own incentive structures.

Because of this customization, companies can create legally compliant permissioned subnets while still being connected to the grander Avalanche network. This could lead to the creation of new financial primitives and bring more traditional financial products into the blockchain space in a decentralized way.

## Why build on Avalanche?

AVA was created to fill use cases that existing platforms are unable to provide while retaining the promise of decentralization. People who use Avalanche do so because they need to support their high-throughput systems but do not wish to rely on a trusted intermediary. With the ability to partition private data away from the rest of the Avalanche network while still being a member of the overall network, Avalanche enables the privacy use cases other platforms do not.

With fast decision times and reasonable hardware requirements, Avalanche powers a system that can accept many times the data and productive yield than existing decentralized systems provide at a low cost to the end user. Avalanche is an asset engine that can deploy and power new markets or integrate existing ones into a global exchange backbone.

## What can you build on Avalanche?

Avalanche provides developers with one of the most versatile protocols available today. Developers can:

* Create their own VM for their needs
* Create their subnets (private and public), to customize their value proposition 
* Create as many chains as needed under their subnet
* Use (almost) the full suite of Ethereum smart contracts right off the shelf 
* Create native NFTs as first-order objects
* Create powerful decentralized financial applications

And more!

# Network Specifications

## Transaction Fees

In order to prevent spam, transactions on the Avalanche network require the payment of a transaction fee. The fee is paid in AVAX, Avalanche’s native token.

The transaction fee is burned. That is, the AVAX tokens paid in a transaction fee do not go to anywhere. Instead, they are destroyed forever.

When you issue a transaction through Avalanche’s API, the transaction fee is automatically deducted from one of the addresses you control.

Different types of transactions require payment of a different transaction fee. This table shows the transaction fee schedule:

```text
+----------+-------------------+------------------------+
| Chain    : Transaction Type  | Transaction Fee (AVAX) |
+----------+-------------------+------------------------+
| P        : Create Blockchain |                   0.01 |
+----------+-------------------+------------------------+
| P        : Add Validator     |                      0 |
+----------+-------------------+------------------------+
| P        : Add Delegator     |                      0 |
+----------+-------------------+------------------------+
| P        : Create Subnet     |                   0.01 |
+----------+-------------------+------------------------+
| P        : Import AVAX       |                  0.001 |
+----------+-------------------+------------------------+
| P        : Export AVAX       |                  0.001 |
+----------+-------------------+------------------------+
| X        : Send              |                  0.001 |
+----------+-------------------+------------------------+
| X        : Create Asset      |                   0.01 |
+----------+-------------------+------------------------+
| X        : Mint Asset        |                  0.001 |
+----------+-------------------+------------------------+
| X        : Import AVAX       |                  0.001 |
+----------+-------------------+------------------------+
| X        : Export AVAX       |                  0.001 |
+----------+-------------------+------------------------+
```

The C-Chain gas price is 4.7e-7 AVAX/gas. The C-Chain gas limit is 10e8.

## Transaction Speed & Finality

Protocols in the Avalanche family are very fast. They can achieve irreversible finality in 1-2 seconds, quicker than a typical credit card transaction. They support many thousands of transactions per second, over Visa’s typical throughput.

Avalanche protocols are lightweight and sustainable. Unlike Nakamoto protocols, they use very little energy, and when there is no work to do, the system quiesces (waits in a low energy consumption state).

## Languages supported

Avalanche's C-Chain uses the standard Ethereum suite of tools.

The X-Chain and P-Chain use a Typescript library that supports native JavaScript cross-platform.

## EVM compatibility

The C-Chain is fully compatible with the EVM and provides support for any Ethereum applications as the EVM API is identical to Geth's API.

## Role of the AVAX token

AVAX is the Avalanche network's native token. All transactions on the Avalanche network require a fee denominated in AVAX.


What is Avalanche?

Restore an account

Transfer some SCRT

Send data to the program

# Sign and send

Now that we've funded our account with test tokens on devnet, we can start to think about how we might use those funds. In a real-world application, we might want to swap SOL for another token, pay for goods or services in SOL, or even gift someone some SOL. To do that we need a way to let the network ledger know that our account should transfer funds to another account.

Thinking about it from first principles, we know we'll need a function that takes in two addresses - the sender and the recipient. We also know that we'll need to pass in an amount - the number of SOL or lamports that we want to send.

But there's one more important component: we need to prove to the network that we are in fact the owner of those funds and that we approve the transfer.

## Paper checks

Consider a traditional paper check that you might use to pay your landlord. The check has your name and address printed on the top left. It includes a field for you to write the recipient's name along with a field for you to write the amount you're paying. Finally, it includes a field for you to sign the check to validate to the bank that you're approving the transfer.

![Figure 8: Crypto transactions are like digital checks (with real signatures)](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/solana/solana-wallet/assets/check.jpeg)

{% label %}
Figure 8: Crypto transactions are like digital checks (with real signatures)

Let's pretend that banks actually use those signatures to validate that you actually signed the check and it's not someone else forging your signature (spoiler alert: they don't for the most part).

## Blockchain transfers

The blockchain model of transferring funds is pretty similar. You need a way to sign the transaction so the network can confirm it as valid and change the corresponding balances.

The concept of cryptographic signing is fascinating, but well beyond the scope of this tutorial. We'll provide [additional resources](#additional-resources) at the end if you want to explore it more, but recall that your keys, along with hashing algorithms and a one-way function, are designed for this very purpose. The signature authenticates the sender and proves to the recipient that the message hasn't been compromised.

With those building blocks in mind, we're ready to search the docs for a way to send and confirm a transaction.

# Implementation 🧩

If you click on the **Send** button on the wallet dashboard, a drawer component opens up that shows a form structured as a paper check thus building on our analogy above. It includes all the components of a transaction but the **Sign and Send** button doesn't work yet.

Navigating to `components/TransactionLayout/index.tsx` we see a partially implemented `transfer` function.

Based on [Step 3](https://learn.figment.io/tutorials/solana-wallet-step-3) and [Step 4](https://learn.figment.io/tutorials/solana-wallet-step-4) we know that we're going to need a connection to the network. We can once again leverage our previous code:

```javascript
const connection = new Connection(clusterApiUrl(network), "confirmed");
```

## Transactions

We can guess that we'll need to build some sort of transaction object and send it through the connection, but it's not immediately obvious how we might do that. By searching the docs, it looks like there are two ways to send transactions - the `sendTransaction` method in `Connection` and the general function `sendAndConfirmTransaction`.

We're going to want to request a confirmation so we can update our balance after sending the transaction, so the latter seems like a good option to try.

Reading through the function's specs, it looks like we need to pass in a `connection`, some sort of `transaction` object and a `signers array`. Moreover, the description says that this function will "sign, send and confirm a transaction" so it looks like we're on the right track. We can begin by importing this function and using it, knowing that we're going to build out its inputs next.

```javascript
const confirmation = await sendAndConfirmTransaction(
  connection,
  transaction,
  signers
);
```

We already have a `connection`, so we can immediately turn to the `transaction` parameter. Following the link to the `Transaction` class in the docs, it looks like to create a `transaction` object, we can use its constructor.

```javascript
const transaction = new Transaction()
console.log(transaction)

// console:
> Transaction {signatures: Array(0), feePayer: undefined, instructions: Array(0), recentBlockhash: undefined, nonceInfo: undefined}
```

Looking at the transaction we created, it clearly lacks any of the components we need for a valid transaction like `sender`, `recipient` and `amount`, but it seems to have a familiar structure that we should be able to populate. You could research each of them, but let's jump right into the `instructions` property as it seems like a promising place to start.

Unfortunately, the docs aren't very intuitive in how to progress but we can leverage our technical sophistication. There's a very useful class called `SystemProgram` with a `transfer` method, which "generates a transaction instruction that transfers lamports from one account to another." This seems like exactly what we need.

## Transfer

The `transfer` method takes in a `TransferParams` object that requires a `sender`, `recipient` and `amount` in lamports. That matches the data we're hoping to use for our transaction and we can get that from the account in context state and the form inputs. The resulting instructions look like this:

```javascript
const instructions = SystemProgram.transfer({
  fromPubkey: account.publicKey,
  toPubkey: new PublicKey(form.to),
  lamports: form.amount,
});
```

Notice that we have to instantiate a `PublicKey` for the recipient because the form is passing in the key as a string but the `toPubkey` property expects a `PublicKey` type. To incorporate these into our transaction, we can use the `add` method:

```javascript
transaction.add(instructions);
```

Or with a bit of on the fly refactoring, we can simply instantiate the transaction after creating the instructions and add them immediately:

```javascript
const transaction = new Transaction().add(instructions);
```

We have two out of the three parameters ready for the `sendAndConfirmTransaction` function - `connection` and `transaction`.

## Signing

Now we need the `signers array`. From the function's specification, we know `signers` will be an array with at least one `Signer` object. Reviewing the `Signer` type in the docs, it looks like it's an object with two properties - `publicKey` and `privateKey`. We can get both from the `account`, so we can build the `signers array`.

```javascript
const signers = [
  {
    publicKey: account.publicKey,
    secretKey: account.secretKey,
  },
];
```

## Send and confirm

Now that all three parameters are complete, we can finally call `sendAndConfirmTransaction` and await its confirmation.

```javascript
const confirmation = await sendAndConfirmTransaction(
  connection,
  transaction,
  signers
);
```

With that we have a fully functional feature capable of transferring funds between Solana accounts. To complete the feature, we need to make sure we call the `refreshBalance` function to update the account's balance after transferring funds.

```javascript
const updatedBalance = await refreshBalance(network, account);
setBalance(updatedBalance);
```

## Test driving

If you haven't already, airdrop some devnet SOL into your account and test transferring funds to another account. If you have another account to use, feel free to do that. Otherwise you can send the devnet SOL back to the smart contract that sent them to you (these are called faucets)! Here's its public address: 9B5XszUGdMaxCZ7uSQhPzdks5ZQSmWxrmzCSvtJ6Ns6g.

Once you fill in the public address of your recipient and the amount, say one million lamports, the **Sign and Send** button will be enabled. Once you click **Sign and Send** you will see a successful message displayed at the top of the page along with a link to the [Solana Block Explorer](https://explorer.solana.com/?cluster=devnet) at the top left of the check.

## Block explorer

The [Solana Block Explorer](https://explorer.solana.com/?cluster=devnet) is a simple dashboard that allows you to search for specific blocks, accounts, transactions, contracts and tokens by network. It displays all the information related to the item you searched for.

![Figure 9: Oh the places you'll go!](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/solana/solana-wallet/assets/explore.jpeg)

{% label %}
Figure 9: Oh the places you'll go!

In this case, if you click the link on the check, you'll be able to see a basic overview of the transfer you just issued. In the middle of the page, you'll see our transfer's information - mainly, the sender (your public address) and how much SOL you sent; and the recipient (the other public address) and how much SOL they received. In fact, you can check whether you sent the SOL back to the same contract that sent it to you by clicking on the previous transaction in the Transaction History.

You might notice a field labeled "Fee (SOL)". If you scroll to the Account Input(s), you'll also notice that it was charged to your account. While the recipient received the funds you specified, your account was deducted the amount you sent plus a small fee. These [transaction fees](https://docs.solana.com/transaction_fees) are designed to reward validators for the compute power spent to process transactions.

At this point, your Solana wallet is almost complete, except for one major flaw. You can create a wallet, and even transfer funds from it. But you can't access an existing wallet. We'll fix that in [Step 6](https://learn.figment.io/tutorials/solana-wallet-step-6) where we'll once again leverage the Bip39 library to access an account based on a mnemonic phrase.

##### _Listing 5.2: Code for transferring funds_
```javascript
const transfer = async () => {
  if (!account) return;

  try {
    setTransactionSig("");

    const connection = new Connection(clusterApiUrl(network), "confirmed");

    const instructions = SystemProgram.transfer({
      fromPubkey: account.publicKey,
      toPubkey: new PublicKey(form.to),
      lamports: form.amount,
    });

    const transaction = new Transaction().add(instructions);

    const signers = [
      {
        publicKey: account.publicKey,
        secretKey: account.secretKey,
      },
    ];

    setSending(true);
    const confirmation = await sendAndConfirmTransaction(
      connection,
      transaction,
      signers
    );
    setTransactionSig(confirmation);
    setSending(false);

    const updatedBalance = await refreshBalance(network, account);
    setBalance(updatedBalance);
    message.success(`Transaction confirmed`);
  } catch (error) {
    message.error("Transaction failed, please check your inputs and try again");
    console.log(error);
  }
};
```

# Challenge 🏋️

Navigate to `components/TransactionLayout/index.tsx` in your editor and follow the steps included as comments to finish writing the `transfer` function. We include a description along with a link to the documentation you need to review in order to implement each line. The relevant code block is also included in [Listing 5.1](#listing-51-instructions-for-writing-transfer-function) below.

##### _Listing 5.1: Instructions for writing transfer function_
```javascript
// *Step 5*: implement a function that transfer funds
const transfer = async () => {
  // This line ensures the function returns before running if no account has been set
  if (!account) return;

  try {
    // (a) review the import guidance on line 1
    // (b) instantiate a connection using clusterApiUrl with the active network passed in as an argument
    // Documentation References:
    //   https://solana-labs.github.io/solana-web3.js/classes/Connection.html
    //   https://solana-labs.github.io/solana-web3.js/modules.html#clusterApiUrl
    console.log("Sign and Send not yet implemented!");
    const connection = "";
    setTransactionSig("");
    // (c) leverage the SystemProgram class to create transfer instructions that include your account's public key, the public key from your sender field in the form, and the amount from the form
    // Documentation Reference:
    //   https://solana-labs.github.io/solana-web3.js/classes/SystemProgram.html
    //   https://solana-labs.github.io/solana-web3.js/classes/SystemProgram.html#transfer
    const instructions = {};

    // (d) instantiate a transaction object and add the instructions
    // Documentation Reference:
    //   https://solana-labs.github.io/solana-web3.js/classes/Transaction.html
    //   https://solana-labs.github.io/solana-web3.js/classes/Transaction.html#add
    const transaction = {};

    // (e) use your account to create a signers interface
    // Documentation Reference:
    //   https://solana-labs.github.io/solana-web3.js/interfaces/Signer.html
    //   note: signers is an array with a single item - an object with two properties
    const signers = [{}];

    setSending(true);
    // (f) send the transaction and await its confirmation
    // Documentation Reference: https://solana-labs.github.io/solana-web3.js/modules.html#sendAndConfirmTransaction
    const confirmation = "";
    setTransactionSig(confirmation);
    setSending(false);

    const updatedBalance = await refreshBalance(network, account);
    setBalance(updatedBalance);
    message.success(`Transaction confirmed`);
    // (g) You can now delete the console.log statement since the function is implemented!
  } catch (error) {
    console.log(error);
    message.error("Transaction failed, please check your inputs and try again");
  }
};
```


Step 5: Transfer Funds 💵

Transfer some TEZ

Access the Pyth Pathway on GitHub

# What is Polygon?

{% hint style="info" %}
"_Polygon is a protocol and a framework for building and connecting Ethereum compatible blockchain networks. Aggregating scalable solutions on Ethereum, supporting a multi-chain Ethereum ecosystem._"
{% endhint %}

**Polygon** is designed to interoperate with and solve some of Ethereum's limitations: Scaling, the speed of transaction throughput - and poor user experience such as the high cost of transactions. Polygon's testnets can currently reach over 7000 transactions per second and the low cost of the MATIC token means cheap transaction fees!  
  
Matic, the predecessor of **Polygon**, utilized a single scaling solution known as [Plasma](https://education.district0x.io/general-topics/understanding-ethereum/understanding-plasma/) which allows for 'child' blockchains to move transaction bloat off of the main Ethereum network. A Plasma chain can have different conditions to the main network, and can be specifically tuned to satisfy certain needs. Sidechains based on Plasma offer cheap and rapid transactions that are ultimately settled in batches on the main chain, so they benefit from the security of the main chain without compromising performance.

Today, **Polygon** operates a Proof-of-Stake (PoS) sidechain. **Polygon** will grow to include other scaling solutions like [zero knowledge proofs](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) and [optimistic rollups](https://blog.polygon.technology/polygon-research-ethereum-scaling-with-rollups-8a2c221bf644) in the future, and allow developers to choose how best to scale their dApps. Currently, connecting to Polygon purely from a user perspective means using a compatible wallet such as Metamask, and being aware of the difference between Polygon and Ethereum.

[**MATIC**](https://coinmarketcap.com/currencies/polygon/) is the native token of **Polygon**, as [ETH](https://coinmarketcap.com/currencies/ethereum/) is the native token of Ethereum. MATIC is used to pay transaction (gas) fees on **Polygon**. It is also used to secure the network via staking and to pay out staking rewards. Holding MATIC allows users to take part in the decentralized governance of the protocol by voting on [Polygon Improvement Proposals](https://forum.matic.network/t/polygon-improvement-proposals/630).

Check out [Awesome Polygon](https://awesomepolygon.com/dapps/) for many examples of what is being built on **Polygon**! [This article](https://finematics.com/polygon-commit-chain-explained/) on Finematics is also worth a look.

There are a few important sites that will be of interest to users of **Polygon**

* [For bridging assets between **Polygon** and Ethereum](https://wallet.matic.network)
* [For knowledge!](https://docs.matic.network/) 
* [For free testnet assets](https://faucet.matic.network/)

-------------------------------------

## Heimdall & Bor

For **Polygon**, the node is designed with a two layer implementation with Heimdall (the Validator layer) & Bor (the Block Producer layer) :

* **Heimdall** uses Proof-of-Stake verification and is responsible for checkpoint blocks on Ethereum mainnet. It also handles the Validators and rewards management. The role of Validators is to run a full node, produce blocks, validate and participate in consensus and commit checkpoints on the Ethereum Mainnet. Heimdall ensures synchronization with Ethereum.
  * On DataHub, the RPC endpoint is used to access Heimdall. 
* **Bor** is compatible with the Ethereum Virtual Machine (EVM), it is a fork of the [Geth client](https://geth.ethereum.org/docs/) with customized consensus algorithms. User interaction on **Polygon** takes place on this chain, it also makes available the functionality and compatibility of Ethereum developer tooling and applications.  Read more about the [core concepts](https://docs.matic.network/docs/contribute/bor/core_concepts) of Bor.
  * On DataHub, the JSON-RPC endpoint is used to access Bor.

-------------------------------------

## Bridging Polygon & Ethereum

Polygon's Validators continuously monitor a contract on Ethereum's mainnet called _**StateSender**_. Each time a registered contract on Ethereum calls this contract, it emits an event. Using this event, Polygon validators relay the data to another contract on the **Polygon** chain. This _**StateSync**_ mechanism is used to send data from Ethereum to **Polygon**.

Validators also periodically submit a hash of all transactions on the **Polygon** chain to the Ethereum chain. This is the mechanism which enables two way data $state$ transfer between **Polygon** and Ethereum. The [_**Checkpoint**_](https://docs.matic.network/docs/contribute/heimdall/checkpoint) can be used to verify any transaction that happened on **Polygon**. Once a transaction is verified to have happened on **Polygon** chain, action can be taken accordingly on Ethereum. 

It is possible to process many transactions on **Polygon** and use relatively little MATIC for gas fees. This helps reduce friction for onboarding new users, because there is a much lower barrier to entry in terms of raw cost as compared to settling the same number of transactions on Ethereum.

In summary, **Polygon** is an attractive solution for developers who wish to keep much of the tooling and community of Ethereum, while leveraging the best scaling for their decentralized applications.

-------------------------------------

# Next Steps

Now that we gave you a quick overview of Polygon ecosystem, we still need to set up our environment.


Learn Web 3 the easy way

We've built some of the best educational content to help you onboard Web 3 technologies