Learn the basics of how Unlock Membership works

Introduction to Unlock Protocol

Unlock Protocol

Christopher Carfi

<Section name="Intro to Polygon PoS">

# Polygon Proof-of-Stake (PoS) Explained

Polygon creates blockchain protocols & technologies that enable developers to build scalable user-friendly dApps on Ethereum, with low transaction fees but without ever sacrificing security. Like Ethereum, Polygon's live blockchain in production uses the [Proof-of-Stake consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) (PoS for short). In this guide, we'll learn how to build and deploy our first Solidity smart contracts to Polygon PoS.

## Key Features of Polygon

- **Speed** The Polygon Network uses a high-throughput blockchain with consensus provided by a group of Block Producers selected by stakeholders at each checkpoint. A Proof of Stake layer is used to validate blocks and periodically post proofs of Block Producers to the Ethereum mainnet. This enables rapid block confirmation rates of about 2 seconds while preserving a high amount of decentralization, resulting in excellent throughput for the network.
- **Scalability** Polygon Network achieves a hypothetical transaction speed of fewer than 2 seconds on a single sidechain. Using multiple sidechains helps the network to handle millions of transactions per second. This mechanism (already demonstrated in the first Matic sidechain) allows the Polygon network to scale easily.
- **Security** Polygon's smart contracts rely on Ethereum’s security. To safeguard the network, it employs three critical security models. It uses Ethereum's staking management contracts and a group of incentivized validators running Heimdall and Bor nodes. Developers can also implement both models (Hybrid) into their dApp.
- **EVM-Compatability** Polygon is designed to provide the ultimate Layer-2 scaling solution for Ethereum. You don't have to worry about the underlying architecture while moving or deploying your dApps to the Polygon Network as long as it is EVM-compatible. Deploying your dApp to the Polygon Mainnet allows you to leverage Polygon as a faster transaction layer for your dApp. 


## Building on Polygon

If you are an Ethereum developer, you are already a Polygon developer. Simply switch to the Polygon RPC and get started. All the tools you are familiar with on the Ethereum blockchain are supported on Polygon by default, such as Truffle, Remix, and Web3js.

You can deploy decentralized applications to either Polygon Mumbai Testnet or the Mainnet. The Polygon Mumbai Testnet connects with the Ethereum Goërli Testnet, which acts as its ParentChain. You can find all the network-related details in the network documentation.

# Interacting with the Polygon Network: two approaches

## Wallets

Polygon PoS runs on Ethereum Virtual Machine (EVM). To interact with the Polygon Network, you need to have an [Ethereum-based wallet](https://ethereum.org/en/wallets/) like Metamask or Arkane Wallet. Ethereum wallets are applications that let you interact with your Ethereum account. Think of it like an internet banking app – without the bank. Your wallet lets you read your balance, send transactions and connect to applications.

### Smart Contracts

Polygon supports many services you can use to test, compile, debug, and deploy [smart contracts](https://ethereum.org/en/developers/docs/smart-contracts/), the programs that decentralized Ethereum applications run on, onto the Polygon Network. Where wallets allow users to interact with the Ethereum blockhain manually, smart contracts let us automate the interactons between the blockchain and aDapp. Examples of interactions include deployment using Alchemy, Chainstack, QuickNode, Remix, Truffle, Hardhat, and Replit.


<Quiz id="z6s8f" />

<Quiz id="1n9i7" />


</Section>

<Section name="Minting your first NFT">

🎫 One of the simplest use cases for Ethereum smart contracts is using them to trigger minting [Non Fungible Tokens (NFTs)](https://ethereum.org/en/nft/). This guide will take you through minting your own NFT as a worked example to learn basics of Polygon PoS.


🌟 Your final deliverable will be an app that lets users purchase and transfer NFTs. Deploy your contracts to a testnet, and then build and upload your app to a public web server. This solution uses a template React app full of important Polygon components and hooks. This will let you deploy an NFT to a public network to share with friends! 🚀 Like in the image below:

![image](https://i.imgur.com/vaIM2qj.png)


# Before we start: 📦 Set up your dev environment and look 📚

This worked example assumes you have the following dependencies installed in your system before you start:

1. Install [VS Code IDE](https://code.visualstudio.com/) 
2. Install the [👷‍♀️ HardHat](https://hardhat.org/getting-started/) extension for VS code will let you compile and deploy smart contracts. 
3. Install and set up [Git](https://git-scm.com/downloads)
4. Install [Node JS](https://nodejs.org/dist/latest-v16.x/)  (🧨 Currently use Node v16 as v17 & v18 are unstable 🧨)
5. Install [Yarn](https://classic.yarnpkg.com/en/docs/install/#mac-stable) (⚠️ Don't install the linux package `yarn` make sure you install yarn with `npm i -g yarn` or even `sudo npm i -g yarn`!)
6. Set up your [Metamask](https://metamask.io/) wallet (You will need a wallet installed for all the following activities in this guide. If you don't currently have one installed, follow ETH Global's [getting started with Metamask guide](https://ethglobal.com/guides/getting-started-with-metamask-cjf72) to set one up first.) 

#  Preview the minting Dapp for your contract

You can see the starter code for your Dapp following the steps below on your command line:


```sh
git clone https://github.com/llsourcell/scaffold-eth-challenges.git challenge-0-simple-nft
```

```sh
cd challenge-0-simple-nft
git checkout challenge-0-simple-nft
yarn install
yarn chain
```

> **in a second terminal window, start your 📱 frontend:**

```sh
cd challenge-0-simple-nft
yarn start
```

> **in a third terminal window, 🛰 deploy your contract:**

```sh
cd challenge-0-simple-nft
yarn deploy 
```

> **You can `yarn deploy --reset` to deploy a new contract any time.**

> **📱 Open http://localhost:3000 on your browser to see the app**

![image](https://i.imgur.com/PmuF18K.png)

</Section>

<Section name="Setting up with Polygon Testnet">


**Testnets** are test blockchain networks that act and perform similarly to the main networks (mainnets) they are associated with. Since they operate on separate ledgers from the mainnet, the coins on a testnet have no connection to transactions and value on the mainnet. This allows developers to deploy, test, and execute their projects on a functioning blockchain freely.

The cost of failure or mistakes on a mainnet is very high and at times irreversible so developers need an environment where they can comfortably work without these risks. 

The Polygon testnet is called Mumbai. Like other testnets, Mumbai allows developers to deploy and test their applications on the Polygon network without having to spend real money. We can use what's called a 'faucet' to receive your first test tokens. 

**Faucets** are smart contracts that allow developers to receive test tokens instantly. 

Let's Install and connect your metamask wallet to the Mumbai testnet, and use a faucet to collect your first test tokens. 

**Setting up your wallet to work with the Polygon Mumbai Tesnet**

1. After your first install, your Metamask wallet is by default connected to the Ethereum network. In order to connect your wallet to the Mumbai Testnet, lets change its configuration by clicking the account icon on the top right of the app. 
2. Select *“Settings”* from the drop down menu on the top right corner of your Metamask wallet.

![image](https://i.imgur.com/Zuvm0fb.png)

3.  Select *“Networks”* from the menu to the left.

![image](https://i.imgur.com/6a0JRJN.png)

3. In the Networks UI, complete the form to connect your wallet to the Mumbai Testnet using the following parameters.

**Network Name:** Polygon Testnet

**New RPC URL:** https://matic-mumbai.chainstacklabs.com

**ChainID:** 80001

**Symbol:** matic

**Block Explorer URL:** https://mumbai-explorer.matic.today/

![image](https://i.imgur.com/9dRU8GF.png)

Once you save the form,notice the addition of Polygon testnet to the network list dropdown next to the account icon. You can now select the Polygon testnet to perform your transactions on the Polygon network.


**Using the Matic faucet to get test tokens in your wallet**

1. Access the following website: https://faucet.matic.network/ and make sure the following parameter are set:

![image](https://i.imgur.com/MgvCUXs.png)

2. Add your address. Note that this address is the same for your ETH wallet.

![image](https://i.imgur.com/ePwOWij.png)

3. Confirm the transaction.

![image](https://i.imgur.com/cmslDJZ.png)

4. Once the transaction is confirmed, you will be able to check the settled transaction the Polygonscan block explorer app, Matic’s version of [Etherscan](https://etherscan.io/) when clicking on the following link: https://explorer-mumbai.maticvigil.com/

5. As you can see, here is a quick summary of the amount transferred to you in Polygonscan.

![image](https://i.imgur.com/eaVCStT.png)

</Section>

<Section name="⛽️ Setting up a Burner Wallet to test NFT contracts 👛" >

A **Burner Wallet** is a quick web wallet used to move small amounts of crypto quickly. It is basically an Ethereum address that is associated to your browser window and you can use to peform blockchain transactions with a simple interface. It is ephemeral, meaning that when you close that window, the wallet (and the funds left in it) is gone. Sending funds is as easy as a QR code scan. Burner wallets are great for local development but you'll move to more permanent wallets when you interact with public networks. 

In this guide we will use burner wallets to examine how our contract assigns ownership of an NFT to a specific wallet address, and how ownership can be transferred from one wallet to another through a transaction.

⛽️ To test this we'll use 🔥**burner wallets**🔥 on localhost and start by getting some gas on our burner wallet.

1. Explore how **burner wallets** work. Reload your starter app and open a new *incognito* window.

2. Navigate the incognito window to http://localhost:3000. You'll notice it has a new wallet address in the top right different from the wallet address in your starter app window. 

3. Use the [faucet](https://faucet.matic.network/) to put some gas funds in the incognito wallet.

![image](https://i.imgur.com/brNuzSN.png)


4. Copy the incognito browsers' wallet address and send funds from  the localhost burner wallet to it. Once you see the funds in the initial wallet, you are ready to go. 

![image](https://i.imgur.com/K60DQ8i.png)

5. Close your incognito window.
>👨🏻‍🚒 Careful! When you close an incognito window, the burner wallet, account address and any funds remaining in it are gone forever.  

</Section>

<Section name="🖨 Minting some NFTs and modding your Dapp">

1. On your starter code window app let's ✏️ mint some NFTs!  Click the `MINT NFT` button in the YourCollectables tab.  

![MintNFT](https://i.imgur.com/2MCF5vj.png)

👀 You should see your collectibles start to show up:

![nft3](https://i.imgur.com/pyFMY9H.png)

2. Open an **incognito** window and navigate to http://localhost:3000 to open a burner version of the minter app.

3. 🎟 Transfer an NFT to the burner (incognito) address using the UI:

![nft5](https://i.imgur.com/Q3cCukc.png)

4. Try to mint an NFT from the incognito window. 

>Notice that you can't mint an NFT with no funds in this address! Try grabbing some funds from the faucet to pay the gas!

5. When the transfer is complete. 🕵🏻‍♂️ Inspect the `Debug Contracts` tab. What address is the `owner` of `YourCollectible`? Notice that it is now the destination address.


</Section>

<Section name="Checking your Dapp's main files">

Now that you have seen a smart contract in action, let's look at some of the key files that make it work:

1. 🔏 You can also see your smart contract `YourCollectible.sol` in `packages/hardhat/contracts` folder of the app source. This is the file that contains all the solidity code that the smart contract runs to kick off Ethereum transactions.

YourCollectible.sol

```solidity
pragma solidity >=0.6.0 <0.7.0;

import "hardhat/console.sol";
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract YourCollectible is ERC721, Ownable {

  using Counters for Counters.Counter;
  Counters.Counter private _tokenIds;

  constructor() public ERC721("YourCollectible", "YCB") {
    _setBaseURI("https://ipfs.io/ipfs/");
  }

  function mintItem(address to, string memory tokenURI)
      public
      onlyOwner
      returns (uint256)
  {
      _tokenIds.increment();

      uint256 id = _tokenIds.current();
      _mint(to, id);
      _setTokenURI(id, tokenURI);

      return id;
  }
}
Footer
```

3. 💼 Take a quick look at your deploy script `00_deploy_your_contract.js` in `packages/hardhat/deploy`. This deploys the contract for use in the public testnet.

```sh
import {HardhatRuntimeEnvironment} from 'hardhat/types';
import {DeployFunction} from 'hardhat-deploy/types';
import {parseEther} from 'ethers/lib/utils';

const func: DeployFunction = async function (hre: HardhatRuntimeEnvironment) {
	const {deployments, getNamedAccounts} = hre;
	const {deploy} = deployments;

	const {deployer, simpleERC20Beneficiary} = await getNamedAccounts();

	await deploy('SimpleERC20', {
		from: deployer,
		args: [simpleERC20Beneficiary, parseEther('1000000000')],
		log: true,
		autoMine: true, // speed up deployment on local network (ganache, hardhat), no effect on live networks
	});
};
export default func;
func.tags = ['SimpleERC20'];
```

4. 📝 If you want to make frontend edits, open `App.jsx` in `packages/react-app/src`.


</Section>

<Section name="Deploy the smart contract to testnet 🛰">

🛰 Ready to deploy to a public testnet?!?

1. Change the `defaultNetwork` in `packages/hardhat/hardhat.config.js` to `mumbai`

2.  🔐 Generate a **deployer address** with `yarn generate'. This is the wallet address your app will use to interact with the polygon testnet.

3. ⛽️ Use a faucet like [https://faucet.polygon.technology/](https://faucet.polygon.technology/) to fund your **deployer address**.


🚀 Deploy your NFT smart contract:

```sh
yarn deploy
```

> 💬 Hint: You can set the `defaultNetwork` in `hardhat.config.js` to `mumbai` OR you can `yarn deploy --network mumbai`. 


</Section>

<Section name="Talking to testnet contract">

1. ✏️ Edit your frontend `App.jsx` in `packages/react-app/src` to change the `targetNetwork` to `NETWORKS.mumbai`:

You should see the correct network in the frontend (http://localhost:3000). It should say mumbai instead of goerli:

![nft10](https://i.imgur.com/WxcrjJO.png)

> 🦊 At this moment, you will need to connect the dapp to a browser wallet where you have some ether available to mint tokens.  Keep in mind that the address you generated in the previous step to deploy the contract will likely be different from the one you have configured in your wallet.

🎫 Ready to mint a batch of NFTs for reals?  Use the `MINT NFT` button.

![MintNFT2](https://i.imgur.com/uKWrnLO.png)


📦 Build your frontend:

```sh
yarn build
```

💽 Upload your app to surge:
```sh
yarn surge
```
(You could also `yarn s3` or maybe even `yarn ipfs`?)

>  😬 Windows users beware!  You may have to change the surge code in `packages/react-app/package.json` to just `"surge": "surge ./build",`

⚙ If you get a permissions error `yarn surge` again until you get a unique URL, or customize it in the command line. 

⚠️ Run the automated testing function to make sure your app passes

```sh
yarn test
```
![testOutput](https://i.imgur.com/hHBxo6j.png)

</Section>

<Section name="📜 Contract Verification">

Update the `api-key` in `packages/hardhat/package.json` file. You can get your key [here](https://etherscan.io/myapikey).

![Screen Shot 2021-11-30 at 10 21 01 AM](https://i.imgur.com/SPCS9Qn.png)

Now you are ready to run the `yarn verify --network your_network` command to verify your contracts on etherscan 🛰


</Section>

<Section name="💪 Share with friends!">

👩‍❤️‍👨 Share your public url with a friend and ask them for their address to send them a collectible :)

![nft15](https://i.imgur.com/LnUttKI.gif)

<Quiz id="4ro4r" />

</Section>


Quick tutorial on how to create your first ERC20 token on Polygon network

Creating ERC20 Token on Polygon

Polygon

Alex Games

<Section name="Introduction" description="">

**What are smart contract wallets**

Before we discuss what a smart contract wallet is, let’s talk about the traditional wallets. There are multiple ways to store crypto and interact with the blockchain. The most common is by using an Externally Owned Account (EOA), which is a wallet that is secured with a private key. There is no way to access or control the wallet without using the private key. Some EOAs you may have heard of are Metamask and Coinbase Wallet. They also include cold wallets like Legder and Trezor, which store your keys offline.

Custodial wallets are also EOAs. These are wallets that are controlled by a separate centralized entity such as Binance. You have a custodial wallet when you are not given the private key and therefore cannot access your coins independently of the exchange.

Both custodial and non-custodial EOAs have been problematic in the web3 world. It’s easy to forget your private key and have no other way to access your wallet. It’s also relatively common for exchanges, which work similarly to banks, to lose your crypto in acts of negligence, fraud, or security breaches, making it impossible for you to withdraw.

That’s where smart contract wallets come in. They introduce the familiar user experience of exchanges, while providing you true ownership and control over your assets.

Smart wallets hold your assets in a smart contract on the blockchain. They are programmable, offering multiple types of support and security that a traditional EOA does not. The opportunities of smart contract wallets are endless, only limited to the creativity of the developer.

<Quiz id={"own1i"} title={"Which of the following is true about smart contract wallets?"} />

<Quiz id={"rjuqm"} title={"Which of the following is true about smart contract wallets?"} />

</Section>

<Section name="Smart Contract Wallets vs EOAs" description="">

There are four main differences between smart wallets and Externally Owned Accounts, as you can see from the image below.

![https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357788_eoas_vs_smart_contract_wallets.png](https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357788_eoas_vs_smart_contract_wallets.png)

# Multiple private keys and account recovery

When creating a web3 wallet, you will be given two different keys: a public key and a private key. The public key is able to be shared with others and acts similarly to your email address, enabling you to send and receive assets to and from other wallets. Your private key is known by only you, and acts like a password allowing you to control your assets. When you make a transaction on the blockchain, it is associated with your public key, but you verify that you are the only making the transaction using your private key. 

This brings up one big concern - the loss of your private key means the loss of your assets. Custodial wallets attempt to solve this, by handling the private key themselves and allowing you to log in using your email address or social media account. However, this gives up access to your assets to the centralized entity, which has proven to be problematic as we mentioned earlier.

Smart contract wallets enable the ability to unlock your account through multiple private keys. This is because your assets are handled by a smart contract, creating a degree of separation between the verification mechanism and the wallet. This means that if you lose your private key, you are able to recover your account and create a new key to control your wallet. 

Different smart contract wallets implement this feature in different ways, such as allowing a trusted guardian to access the wallet, or enabling social and email login.

# Gasless transactions

One of the biggest UX concerns in the web3 world is gas. In general, web2 applications cover the transaction cost for their users, so It is a huge turn-off for non-crypto users if they have to pay a transaction fee to write to the blockchain.

Gasless transactions are a type of meta transaction, which is an umbrella term to describe a transaction in which the sender and the payer of gas are separate entities. This is achieved through relaying a transaction to another party, who then pays the gas and commits it to the blockchain. Smart contract wallets are able to act as this relayer, allowing the company or developer to pay the gas fees for their users.

Below you can see the architecture of a modern web3 application with smart contract wallet and relayer.

![https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1676682062962_image%20(11).png](https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1676682062962_image%20(11).png)


# Versatile

While traditional EOAs are all very similar, smart contract wallets have huge potential. On top of recovery features and meta transactions, the relayer makes it possible to batch transactions or submit them in parallel for faster transactions, implement fiat-to-crypto onramps, whitelist or blacklist addresses, add rate-limits and more directly from the wallet.

The Sequence Wallet implements many of these features, and is built to be customizable. Developers can choose whether or not their users can use specific elements of the Wallet. Head to the next section to learn about the unique features of Sequence Wallet.


<Quiz id={"s8pro"} title={"Which of the following is not true about smart contract wallets?"} />

<Quiz id={"msapo"} title={"What are gasless transactions?"} />


</Section>

<Section name="Understanding Sequence Wallet" description="">

Sequence Wallet was developed by Horizon Blockchain Games, the creators of Skyweaver. Creating a web3 trading card game with hundreds of thousands of players helped them discover the pain points of users and developers. That’s how Sequence was born - a smart contract wallet developed with seamless user experience in mind.

It’s worth noting that Sequence is an all-in-one developer platform to make building web3 games and apps easy. This guide focuses on the Sequence Wallet, and we’ll touch on the other tools at the end of the guide.

Sequence Wallet can be easily implemented into any game or dapp and allows users to utilize all the security of a smart wallet in a friendly format.

# Embeddable

The wallet is embeddable onto any screen, which mean that users can connect to your game or dapp without the need to install a browser extension. Users can also easily take their wallet everywhere, accessing it via a web browser, a browser app, or a mobile app.

![https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357788_embeddable.png](https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357788_embeddable.png)

# Social/email login

Without any additional code, users can create and access their wallet with a variety of logins. Sequence Wallet comes with social and email log in, so users feel like they are interacting with any other app on the web.

![https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357790_skyweaver-wallet.png](https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357790_skyweaver-wallet.png)

Developers can customize the colour scheme and branding, so that the Sequence Wallet feels native to their application

# Non-custodial

Users own their own tokens and they cannot be used or altered by any centralized party.

# Improved gas UX

With Sequence, developers can sponsor the gas for their users, giving users completely gasless transactions.

The Sequence Wallet can bundle transactions, which saves gas and time. It also provides some other functionality for improving gas fees and user experience.

Sequence offers gas abstraction, which gives users the ability to pay gas in any token they want, removing the need to have ETH just to process a transaction. The wallet also supports on-ramps directly within the embedded app, allowing users to purchase crypto with fiat without leaving the app and going to an exchange. 

![https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357788_gas-abstraction.png](https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357788_gas-abstraction.png)


## Multi-network support

Sequence supports all EVM-compatible chains in an easy-to-understand UI. Find out exactly which chains are supported [here](https://docs.sequence.xyz/multi-chain-support).

The wallet also has built-in bridges, so users do not have to leave the app to transfer tokens cross chain.

## NFT and SFT Support

Through building Skyweaver, the Horizon team discovered that the lack of NFT and SFT support in most browser wallets was confusing for new users. The Sequence Wallet was designed with this in mind and has a great UI for displaying and sending digital collectibles.

![https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357789_skyweaver-nfts.png](https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357789_skyweaver-nfts.png)


</Section>

<Section name="Sequence Platform" description="">

The Sequence Platform is more than the Sequence Wallet. It has many other plug-and-play capabilities to make user onboarding and accessibility easy for developers. 

## Indexer

The Sequence [Indexer](https://docs.sequence.xyz/indexer) is a modular web3 service that makes it easy to query blockchain token and NFT data from EVM-compatible chains. The Indexer automatically indexes every ERC20, ERC721 and ERC1155 token.

## Metadata

The [metadata API](https://docs.sequence.xyz/metadata) offers an easy and fast service for querying NFT metadata.

## Relayer

The [Sequence Relayer](https://docs.sequence.xyz/relayer) allows developers to implement meta transactions into their EVM-compatible dapp or game. Meta transactions offer a multitude of benefits including but not limited to:

- Sponsored gas where the developer can pay transaction fees instead of the user
- Gas abstraction, meaning users can pay gas with any token they have in their wallet instead of the chain’s native token
- Batched transactions, improving speed and cost

## Unity and Unreal Engine SDKs

Implement web3 features directly into your Unity or Unreal Engine game without users having to install an extension or navigate away from the game.

## Node Gateway

[Sequence Node Gateway](https://docs.sequence.xyz/node-gateway) is a reliable node service that aggregates the top node providers and internally managed nodes. It automatically switches between them so that your dapp runs smoothly with low latency for your users.

## Marketplace SDK

Easily build your custom in-app digital collectibles marketplace using the Sequence Marketplace SDK. This also comes in a no-code solution.


<Quiz id={"an6ei"} title={"Which of these is not a feature of Sequence Wallet?"} />

<Quiz id={"0seo9"} title={"What is the Sequence SDK?"} />

</Section>

<Section name="Getting Started" description="">

# Pre-requisites

The demo dapp uses `yarn`. You can install this using npm:

`npm install --global yarn`.

Read more on the [yarn website](https://classic.yarnpkg.com/lang/en/docs/install/#mac-stable).

# Quick-start from our demo

We have created a demo dapp to give you an insight into what the Sequence Wallet and SDK can do. Play around with it [here](https://0xsequence.github.io/demo-dapp/) (you do not need to download a wallet extension).

![Connect to Wallet without extension](https://storage.googleapis.com/ethglobal-api-production/guides%2Fz64hk%2Fimages%2F1673362357783_connect-wallet.png)

Clone the repository directly to see how you could implement the Sequence Wallet into your game or dapp. 

```
git clone https://github.com/0xsequence/demo-dapp.git
```

To run the dapp, do the following:

```
cd demo-dapp
yarn install
yarn start
```

The app will run on [localhost:4000](http://localhost:4000/). You can open the inspector to see the responses from the Wallet.

When you run the app, you should see something similar to [this](https://0xsequence.github.io/demo-dapp/). The app allows you to explore some of the features of the Sequence Wallet, including:

1. Connecting Wallet and validating a proof
2. Checking if the Wallet is connected
3. Checking the state, such as the current Chain ID and balance of the account
4. Signing a message
5. Estimating gas for a transaction to withdraw $WMATIC
6. Calling a smart contract

We'd recommend looking into the code and trying to edit some of it yourself. Go to [App.tsx](https://github.com/0xsequence/demo-dapp/blob/master/src/App.tsx) to see a variety of the functions.

To add more customization to the wallet, find the `connect()` function in App.tsx. It should look like this:

```js
const connect = async (authorize: boolean = false, withSettings: boolean = false) => {...}
```

Within this function, you will see this:

```js
const connectDetails = await wallet.connect({...})
```

The variables that are provided within the `wallet.connect()` function let you personalize the wallet experience. In the `settings` parameter, try changing it to light mode, adding some more payment providers, changing the default currency, and only allowing users to login with email (no social accounts). To do this, change the settings to these:

```js
settings: {						
	theme: 'light',
	includedPaymentProviders: ['moonpay', 'ramp'],
	defaultFundingCurrency: 'eth',
	signInOptions: ['email']
}
```

You can find a list of the other personalization settings [here](https://docs.sequence.xyz/wallet/guides/connect-wallet#wallet-login-and-connect-options).

</Section>

<Section name="Resources" description="">

# Learn more about Sequence

Watch [this series of videos](https://youtube.com/playlist?list=PLN_CsIpJBRih1baRCSxkwvVrrU_Ta4ue3) to see many of the Sequence smart wallet features and its seamless UI in action.

Stay up to date with Sequence and smart contract wallets by following our [blog](https://medium.com/@0xSequence/c4218560c8dd).

Recommended reading: [Build web3 games and apps with ease using the Sequence web3 stack](https://medium.com/@0xSequence/c4218560c8dd)

# Twitter

Follow Sequence on [Twitter](https://twitter.com/0xsequence) for regular updates, Twitter Spaces  with web3 builders, and weekly recaps on what is happening in the web3 gaming world.

# Docs

We’ve recently enhanced our docs! They are full of quickstart guides and simple tutorials so you can get started in less than 10 minutes. Check out the docs [here](https://docs.sequence.xyz/).

# Discord

Discord is the first place we will share updates, promotions, campaigns, and everything else. We’d love to chat with you - join us [here](https://www.notion.so/ETH-Global-Guides-dfdf0cb4f11845f890eaf368646cfdf8).

</Section>

Learn the basics of what smart wallets are and how Sequence Wallet works under the hood

Intro to Sequence Smart Contract Wallet

Sequence

Cat McGee

<Section name="Introduction" description="Introduction to MetaMask Snaps">

## Extend the functionality of MetaMask

[Snaps](https://metamask.io/snaps/) is a system that allows anyone to safely extend the capabilities of MetaMask. A snap is a program that runs in an isolated environment that can customize the wallet experience.

For example, a snap can add new APIs to MetaMask, add support for different blockchain protocols, or modify existing functionality using internal APIs. Snaps is a new way to create web3 end user experiences, by modifying MetaMask in ways that were impossible before.

## Secure execution

Snaps execute in a sandboxed environment based on [Hardened JavaScript](https://docs.agoric.com/guides/js-programming/hardened-js.html) by Agoric. Snaps uses a permissions model for protecting user data and respecting user consent. 

## Developer preview software

Snaps is pre-release software. To try Snaps, install [MetaMask Flask](https://metamask.io/flask/), a canary distribution for developers that provides access to upcoming features.

_Note: You cannot run MetaMask Flask alongside MetaMask. It is recommended to install it in a separate browser profile, and you should not use any of your existing accounts in Flask._


<Quiz id={"oqonp"} />


<Quiz id={"doexp"} />



</Section>


<Section name="Overview of Features" description="Features">

# Features

At present, snaps can (1) create new RPC methods for websites to call, (2) call many of the same RPC methods that websites can call, and (3) access a limited set of snap-exclusive RPC methods. The following methods are currently live in MetaMask Flask: 

## Display a custom confirmation screen in MetaMask

Show a MetaMask popup with custom text and buttons to approve or reject an action. This can be used to create requests, confirmations, and opt-in flows for a snap. [Learn more](https://docs.metamask.io/guide/snaps-rpc-api.html#snap-confirm)

## Notify users in MetaMask

MetaMask Flask introduces a generic notifications interface that can be utilized by any snap with the notifications permission. A short notification text can be triggered by a snap for actionable or time-sensitive information.  [Learn more](https://docs.metamask.io/guide/snaps-rpc-api.html#snap-notify)

## Store and manage data on your device

Store, update, and retrieve data securely, with encryption by default.[Learn more](https://docs.metamask.io/guide/snaps-rpc-api.html#snap-managestate)

## Control non-EVM accounts and assets in MetaMask

Derive BIP-32 and BIP-44 keypairs based on the Secret Recovery Phrase without exposing it. With the power to manage keys, you can build snaps to support a variety of blockchain protocols. [Learn more](https://docs.metamask.io/guide/snaps-rpc-api.html#snap-managestate)

## Populate MetaMask's pre-transaction window with custom transaction insights

Bring your insights, anti-phishing, and security solutions to the MetaMask UI with the transaction insights API. [Learn more](https://docs.metamask.io/guide/snaps-rpc-api.html#snap-managestate)




<Quiz id={"eb5p1"} />



</Section>


<Section name="Getting Started" description="Learn how to build your own snap">

# Pre-requisites

First, make sure you have an up to date Chromium or Firefox browser and make sure you have [MetaMask Flask](https://metamask.io/flask/) installed in a separate browser profile from any other installation of MetaMask. Then, make sure you have [Node.js](https://nodejs.org/) version 16.0 (it is recommended to use [nvm](https://github.com/nvm-sh/nvm)). 

# Quick start using our template

Start building your own snap using [our template](https://github.com/MetaMask/template-snap-monorepo) built with TypeScript and React. Clone the repository [via GitHub](https://github.com/MetaMask/template-snap-monorepo/generate) and open it on your local machine using e.g. the command line.

> NB: Snaps should work with the LTS version of Node.js, but we recommend using the version specified in the template's `.nvmrc` file. If you use [nvm](https://github.com/nvm-sh/nvm) you can switch easily with calling `nvm use` at the root of the project.

From the root of the repo, install the dependencies:

```shell
yarn
```

Start the development server:

```shell
yarn start
```

You should now be serving both (1) the front-end and (2) the snap locally. Time to check it out in action with MetaMask Flask at [`http://localhost:8000/`](http://localhost:8000/). 

1. Click the Connect button and the MetaMask Flask extension should pop up and require you to approve the template snap's permissions. 
2. Once connected, try out the Send message button to display a custom message within a confirmation screen in MetaMask.

You've now successfully connected, installed, and interacted with your snap.



<Quiz id={"by5yt"} />


</Section>

<Section name="Building your snap" description="Learn how to build your own snap with this example">

## Learn how to build your own snap by modifying the template

Customize your snap by editing and expanding `index.ts` in the `packages/snap/src` folder.

Initially it contains an example request that utilizes the `snap_confirm` method to display a custom confirmation screen:

```ts
import { OnRpcRequestHandler } from '@metamask/snap-types';
import { getMessage } from './message';

export const onRpcRequest: OnRpcRequestHandler = ({ origin, request }) => {
  switch (request.method) {
    case 'hello':
      return wallet.request({
        method: 'snap_confirm',
        params: [
          {
            prompt: getMessage(origin),
            description:
              'This custom confirmation is just for display purposes.',
            textAreaContent:
              'Edit the source code to make your snap do what you want.',
          },
        ],
      });
    default:
      throw new Error('Method not found.');
  }
};
```

> The "hello" method is exported by the snap, meaning that it can be called by a dapp after connecting to the snap. This is how a snap can have its own API for dapps: by exporting methods to be called by dapps. Any dapp can connect to this snap and call the "hello" method to display this custom confirmation window. 

Modify the text in the `description` or `textAreaContent` field. Refresh the dapp in your browser, and click the **Connect** button to reinstall the snap.

The next time you click the **Send message** button, you will see the updated text in the confirmation screen.

Congratulations! You just learned how to build your own snap!


<Quiz id={"y0ne3"} />



</Section>

<Section name="Dev Resources" description="Developer Resources">


# [MetaMask Snaps Development Guide](https://docs.metamask.io/guide/snaps-development-guide.html)

Covers a wide range of topics related to developing snaps.

# Open-Source Example Snaps
- FilSnap for Filecoin: [Repo](https://github.com/chainsafe/filsnap) &bull; [Demo](https://filsnap.chainsafe.io/)
- StarkNet Snap: [Repo](https://github.com/ConsenSys/starknet-snap) &bull; [Demo](https://app.starknet-snap.consensys-solutions.net/)
- Password Manager Snap: [Repo](https://github.com/ritave/snap-passwordManager)
- Transaction Insights with the 4byte API: [Guide](https://hackmd.io/@rekmarks/devcon-vi) &bull; [Repo](https://github.com/rekmarks/devcon-2022-snap/tree/completed)


# Talks and Workshops
- [How to Revolutionize Web3 Development in 20 Minutes](https://www.youtube.com/watch?v=KhpCS8EbKTE) - ETH Denver, Feb 2022
- [Introduction to MetaMask Snaps](https://www.youtube.com/watch?v=h5xW_NGYykw) - ETH Rio, March 2022
- [Workshop: Expand MetaMask with Snaps](https://www.youtube.com/watch?v=BWII6nkT-2w) - EthCC Paris, Aug 2022

# Stay in touch

Have questions? Need help? Head to the [MetaMask Snaps Discussion Board](https://github.com/MetaMask/snaps-skunkworks/discussions) on GitHub to talk to the platform team. 

</Section>

Become an expert in creating Metamask Snaps 

Introduction to MetaMask Snaps

MetaMask

Christian Montoya


<Section name="Introduction" description="Introduction to Optimism">

# Optimism Collective
  
The [Optimism Collective](https://app.optimism.io/announcement) is a band of companies, communities, and citizens working together to reward public goods and build a sustainable future for Ethereum.

Together we will dispel the myth that public goods cannot be profitable. 
Public goods (such as Optimism and Ethereum) often go underfunded when incentives aren't properly aligned, forcing many to make trade-offs between earning a profit and building for the common good. 
We are bound by a mutually beneficial pact, [our vision](https://www.optimism.io/vision) can be summed up with the equation **Impact = Profit**.
[You can read more about who we are and what we are doing here](https://community.optimism.io/docs/governance/#impact-profit).

We intend to achieve this vision through retroactive public goods funding, funding for public goods that have already proven their usefulness and impact.
Retroactive public goods funding is advantageous because it is relatively easy to agree on what *is* useful, and see who built it. 
It is a lot harder to identify in advance what *will be* useful, and *which team* will do the best job of building it. 
The possibility of an eventual exit payment can also encourage investors to fund initial public good development efforts until the usefulness is obvious, in the same way that the possibility of an eventual IPO or buy out encourages investors to fund startups today.

Whether you are interested in exploring novel forms of human coordination via decentralized governance, re-aligning monetary incentives to be positive-sum for humanity through retroactive funding, creating novel dApps that were not possible before, or growing Ethereum technically and philosophically, The Optimism Collective has room for you.
We could use your help, and if you make valuable contributions we'll be happy to see they are properly rewarded.
  
Come explore the rest of the guide and dive into the rabbit-hole of possibilities and cement yourself as a part of a community that moves steadfast in furthering the power of Optimism, Ethereum and the Open Internet. 
Together, we will create the future of coordinated, collaborative cyberspace. 
Together, we will summon [Ether’s Phoenix](https://optimism.mirror.xyz/x4LGFwa6RJ_opOaCOwr_VGk04Lp3of41H8ynWaFB27E).
 
  
<Quiz id={"f9117"} />


<Quiz id={"0to28"} />


  
</Section>

<Section name="How It Works" description="What are optimistic rollups, and how Optimism offers Ethereum-level security at a fraction of the cost">
  
#  How It Works
  
[Ethereum has limited capacity](https://ethereum.org/en/layer-2/) because of the [blockchain trilemma](https://medium.com/certik/the-blockchain-trilemma-decentralized-scalable-and-secure-e9d8c41a87b3). 
To have decentralization we need to enable as many people as possible to run a node, which means that the number of transactions that can be processed per minute is limited by the capacity of standard hardware. 
This limits our ability to scale, unless we accept the security implication of not having every node process every transaction.

Solutions that build on top on Ethereum are called layer 2 or L2 (with Ethereum itself called layer 1 or L1). 
Optimism uses a type of solution called an [optimistic rollup](https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/).
*Rollups* post all transactions on layer 1, so data integrity and availability are provided by Ethereum. 
 
*Optimistic Rollups* use economic incentives to ensure the data processing, done offchain, is done correctly. 
The *sequencer* node posts the merkle root of the blockchain state on L1 (called the *state root*).
Other nodes, called *verifiers*, can issue *fault challenges* if they believe the state root is incorrect.
In the case of a fault challenge part of the transaction is executed on L1 to verify which is the correct state root.
  
Sequencers that post correct state roots, and verifiers that challenge incorrect ones, are rewarded for their honesty.
Sequencers that post incorrest state roots are penalized for dishonesty.
Verifiers that challenge correct results, which could be used as a denial of service attack, are penalized.
If a state is not challenged for the challenge period (seven days on the production network), it is assumed to be correct. 
As long as there is at least one honest verifier, the state will end up being the correct one - and the economic incentives are aligned with honesty. 
  
[We have a bridge](https://app.optimism.io/bridge) that allows users to deposit into Optimism and withdraw from it using this mechanism.
A withdrawal requires you to waiting the challenge period (until the blockchain state becomes indisputable), but faster withdrawals are available from [third party bridges](https://www.optimism.io/apps/bridges) that run their own verifiers so they **know** the state submitted is correct. 
 
[For a video explanation that goes deeper into the details of how Optimism works, see here](https://www.youtube.com/watch?v=f4YkMj3Vijs).
  
  
<Quiz id={"fzbx3"} />


<Quiz id={"39aqi"} />

  
<Quiz id={"p1pw7"} />

  
  
# Path to decentralization

Currently Optimism is running the sole sequencer because we don't have the fault challenges running yet.
However, there are already many verifiers watching us to make sure this power is not abused.
[We are working hard at decentralization](https://medium.com/ethereum-optimism/our-pragmatic-path-to-decentralization-cb5805ca43c1).

1. Release Bedrock, enabling a multi-client architecture
2. Support (directly or indirectly) the creation of alternative Optimism clients
3. Ship the multi-client proof contracts
4. Either renounce the power to upgrade the contracts further, or transfer it to [the most trusted address in Ethereum](https://etherscan.io/address/0x0000000000000000000000000000000000000000).
  
</Section>

<Section name="Using Optimism" description="A simple exercise to use the Optimism network">  
  
# Using Optimism
  

You can follow these directions to see how easy it is to use Optimism from [the Remix IDE](https://remix.ethereum.org/). 
If you prefer to use a different development stack, [follow the steps in this exercise](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/getting-started).
We're [EVM-equivalent](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), so whatever method you are comfortable using in L1 Ethereum we support.
  
1. Add Optimism Goerli to your wallet, using [this link](https://chainid.link/?network=optimism-goerli).
1. Log on with your wallet to Optimism Goerli.
1. Browse to [Remix](https://remix.ethereum.org/).
2. Click the run icon
3. Select the Environment **Injected Web3 Provider**.
4. Accept the connection in the wallet.

## Greeter interaction

**Step 1**

Click the run icon 

<img src="https://storage.googleapis.com/ethglobal-api-production/guides%2Ffbebr%2Fimages%2F1664053690556_remix-run-icon.png" height="24" valign="top" />

-------

**Step 2**

Make sure your environment is **Injected Web3** and the network ID is **420**.

<img src="https://storage.googleapis.com/ethglobal-api-production/guides%2Ffbebr%2Fimages%2F1664053690554_remix-env.png" width="300" />

-------


**Step 3**

Click the files icon 

<img src="https://storage.googleapis.com/ethglobal-api-production/guides%2Ffbebr%2Fimages%2F1664053690554_remix-files-icon.png" height="24" valign="top" />

-------


**Step 4**

Copy **Greeter.sol**  and upload it to Remix under **contracts**.

<img src="https://storage.googleapis.com/ethglobal-api-production/guides%2Ffbebr%2Fimages%2F1664053690556_remix-upload-icon.png" height="24" valign="top" />


```solidity
//SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.0;

// import "hardhat/console.sol";


contract Greeter {
  string greeting;

  constructor(string memory _greeting) {
//    console.log("Deploying a Greeter with greeting:", _greeting);
    greeting = _greeting;
  }

  function greet() public view returns (string memory) {
    return greeting;
  }

  function setGreeting(string memory _greeting) public {
//    console.log("Changing greeting from '%s' to '%s'", greeting, _greeting);
    greeting = _greeting;
  }
}
```


-------


**Step 5**

Right-click **contracts > Greeter.sol** and select **Compile**.

-------


**Step 6**

Open **contracts > artifacts** and see that there's a `Greeter.json` file. This file is the compiled version, the API for the contract, etc.

-------


**Step 7**

Click the run icon

<img src="https://storage.googleapis.com/ethglobal-api-production/guides%2Ffbebr%2Fimages%2F1664053690556_remix-run-icon.png" height="24" valign="top" />

If you do not have Goerli ETH, get some using [our faucet](https://optimismfaucet.xyz/).
   You just need to follow five people or projects on github.

-------


**Step 8**

Scroll down. In the "At Address" field, type the contract address (`0x106941459A8768f5A92b770e280555FAF817576f`).
Then, click **At Address**. 
Expand the contract to see you can interact with it.

<img src="https://storage.googleapis.com/ethglobal-api-production/guides%2Ffbebr%2Fimages%2F1664053690550_remix-connect.png" width="300" />

-------


**Step 9**

Click **greet** and expand the transaction result in the console (bottom right).

   ![](https://storage.googleapis.com/ethglobal-api-production/guides%2Ffbebr%2Fimages%2F1664053690555_remix-query.png)

-------


**Step 10**

Type a greeting and then click **setGreeting**. Approve the transaction in your wallet. 
Note that if the greeting includes a comma you need to enclose it in quotes.

   <img src="https://storage.googleapis.com/ethglobal-api-production/guides%2Ffbebr%2Fimages%2F1664053690556_remix-tx.png" width="300" />

-------


**Step 11**

See the results on the console and then click **greet** again to see the greeting changed.   

</Section>

<Section name="What Else?" description="Other things you can do on Optimism">  

  
# NFTs
  
See [Quix, our biggest NFT marketplace](https://qx.app/).
        
# Deploying a Dapp  

If you know how to deploy contracts to L1 Ethereum, there is almost nothing for you in this subsection. 
Just use an [Optimism endpoint](https://community.optimism.io/docs/useful-tools/networks/#rpc-endpoints) and you're done.
  
If you are afraid that your users' wallets don't have Optimism set up, add a link to [`https://chainid.link/?network=optimism`](https://chainid.link/?network=optimism) to your user interface.   
  
# Launching a token
  
A token is just another contract, which is easy to deploy. 
If you already have an ERC-20 contract on L1, and you wish to deploy to have a bridgeable equivalent on Optimism, [we have directions to help you](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/standard-bridge-standard-token).
  

<Quiz id={"8kdta"} />


  
</Section>

<Section name="Getting Involved" description="Ways to get involved with Optimism">   
  
# Resources
  
Welcome to Optimism.
Here is where you can go for additional information:
       
- [User docs](https://help.optimism.io/hc/en-us)
- [Developer docs](https://community.optimism.io/)
  
If you can't find the answer in the docs, or you want to talk with real people (Optimism Foundation, OP Labs PBC, or anybody else in our ecosystem), use our Discord:
  
- [Discord](https://discord-gateway.optimism.io/)

  
What to do next?
We'd love for you to build on Optimism:
  
- [If you don't know what to build](https://web.telegram.org/k/#-1645849954)
- [If you *do* know what to build, but you'd like to discuss it with us](https://optimismpbc.typeform.com/get-in-touch)
- [If you've already built it, but want us to help you get the word out](https://optimismpbc.typeform.com/op-marketing)
  
Want to work directly with us? 
We're hiring:

- [Optimism Foundation](https://boards.greenhouse.io/optimism)
- [OP Labs PBC (the technical consultant company)](https://boards.greenhouse.io/oplabs)
    
</Section>  

Introduction to Optimism

Optimism

Binayak Pande

<Section name="1. Introduction" description="Introduction to Livepeer Ecosystem">

# What is the Livepeer Network

Livepeer is a decentralized video transcoding network that aims to enable cost effective, resilient, and censorship resistant video streaming.

Through storytelling, illustration, and data, the [Livepeer Primer](https://livepeer.org/primer) explains, at a high level, the problem Livepeer solves, and how it works.

# What is Livepeer Studio

[Livepeer Studio](https://livepeer.studio/) is the hosted gateway to the Livepeer Network and enables developers to quickly and easily integrate video capabilities such as live streaming, On Demand video, and video NFT minting into their applications. Developers can use [livepeer.js](https://livepeerjs.org/) or the [API](https://docs.livepeer.studio/) to build with Livepeer Studio. 

<Quiz id={"wgzm1"} />

</Section>

<Section name="2. Building with On Demand" description="How to get started with On Demand">

# Uploading an Asset
   
   Livepeer Studio's On Demand functionality allows developers to upload and playback existing video assets. This allows your users to ensure that any videos played on your frontend are opitimized for playback by reducing start up time and adapting to your users bandwidth enviornment. Additionally, video assets can be optionally stored at IPFS, so you can easily mint NFTs. 


When uploading an asset using the API, there are two methods.

- Upload with URL (providing a downloadable URL)

- Upload with local storage (provide a `.mp4` file)

When using either the SDK or dashboard for uploading an asset, only providing a `.mp4` file with H.264 video codec and AAC audio codec is required.

<Quiz id={"nn9zw"} />

---

# Updating an Asset

You can update the following attributes of an asset

1. asset name
2. storage (including IPFS)
3. metadata for the video/audio asset
   - title
   - description
   - anything you want to customize to optimize capability with your marketplace of choice


<Quiz id={"g82zv"} />


</Section>

<Section name="3. Livestream" description="Introduction to Livestreaming ">

# Building livestreaming into your application
   
Livepeer Studio makes it easy to implement live streaming video into your application. Using our Dashboard, you can test out streaming with Livepeer for yourself. 

1. [Download OBS](https://obsproject.com/), a common video encoder
1. Create an account at livepeer.studio
2. Navigate to the 'Streams' tab on the left-hand navigation
3. Click 'Create Stream' at the top right hand corner
4. Copy the RTMP ingest URL
5. Under 'Settings' in OBS, select 'Stream'
7. Paste the RTMP ingest URL in the 'Server' field
8. On the Dashboard, copy your Stream Key
9. Paste it into the 'Stream Key' field in OBS
10. Save changes and hit 'Start Streaming'
11. Navigate back to the stream page to view your stream!

The Studio API and SDK can help you build an application that uses this capability. Check out [our docs](https://docs.livepeer.studio/guides/live/create-a-livestream) to learn more or start building with the [SDK](https://livepeerjs.org/). 

   
# Other livestreaming features

**Video Playback**

In order to playback a livestream with the playbackURL, a video player has to be used that supports HLS format. Livepeer Studio has a video player included in the SDK and we have an easy to embed player in our [documentation.](https://docs.livepeer.studio/guides/playback-a-video-stream)
   
**Recording**
   
You can record a livestream either throught the dashboard, SDK or the API.[Check out our docs](https://docs.livepeer.studio/guides/live/record-a-livestream) for more information.

**Multistreaming**

Livepeer Studio has the ability to multistream by pushing the livestream to multiple ingest points of other targets such as Twitch, YouTube and many others.


<Quiz id={"7bfm6"} />


</Section>

<Section name="4. Minting Videos" description="Introduction to Mint NFT videos">

# Minting Video NFTs
Livepeer Studio has a step-by-step guide for minting video NFTs using the Video NFT SDK or creating your own transaction.

 🌿 [Minting Video Guide](https://docs.livepeer.studio/guides/mint-a-video-nft)

</Section>

<Section name="5. Using Livepeer Studio" description="Introduction Using Livepeer Studio">

# Using Livepeer Studio in your project

 🗝 [Create an API key](https://docs.livepeer.studio/quickstart)

 🖥 [Dashboard](https://livepeer.studio/dashboard)

🧰 [SDK](https://livepeerjs.org/)

 🛠 [API](https://docs.livepeer.studio/category/api)

</Section>

<Section name="Livepeer Studio Resources" description="Additional Resources">

# Livepeer Studio Resources

### [Quickstart](https://docs.livepeer.studio/quickstart)

Get an API key and start building with Livepeer Studio.

### [Stream via OBS](https://docs.livepeer.studio/guides/live/stream-via-obs)

Using [OBS](https://obsproject.com/) software for livestreaming.

### [In-browser Streaming](https://docs.livepeer.studio/guides/live/stream-from-the-browser)

Using Livepeer Studio's [WebRTMP SDK](https://github.com/livepeer/webrtmp-sdk) from in-browser livestreams.

### [Support Matrix](https://docs.livepeer.studio/reference/support-matrix)

Descriptions and highlights of some of Livepeer Studio's capabilities.

### [Example Applications](https://docs.livepeer.studio/reference/examples)

Example of applications that incorporated Livepeer Studio.

### [Discord](https://discord.gg/xVYJxEr3)

Join the Livepeer Studio Community

</Section>

Introduction to Livepeer

Livepeer

Shih-Yu Hwang

<Section name="Incentivized, decentralized storage" description="">

# Centralized and decentralized storage

In our Content Addressing on the Decentralized Web tutorial, we explored how content addressing enables us to trust peers on the decentralized web. The concepts of content addressing and Content Identifiers (CIDs) are key to understanding how Filecoin verifies storage, so please go check out that tutorial now if you haven't yet done so.

On a decentralized, peer-to-peer network like IPFS, we can use cryptographic hashing to confirm that any number of peers are storing exact copies of our data. However, we're depending on the generosity of those parties and have no guarantee that our data will continue to be replicated over time. Filecoin, on the other hand, adds an incentive layer to promote long term, verifiable storage on the decentralized web.

# Incentivized storage

When we pay a storage provider in a centralized system, we place explicit trust in a specific entity (AWS, etc.) to keep our data safe and store it for a promised period. With the decentralized Filecoin network, on the other hand, we have access to a variety of storage providers (referred to as storage miners) who are competing for our business. We pay for these storage deals with Filecoin tokens (FIL), a cryptocurrency.

Although we may not be familiar with these providers in the way we're acquainted with the well-known centralized storage providers, we can place our trust in the design of Filecoin's protocol and implementations, which in turn provide us with the ability to verify that storage miners are honoring their agreements to store our data for a set period of time. Thanks to Filecoin's blockchain, all participants in the network work together to verify each deal. These consensus mechanisms are how users in a distributed network come to agreement without the need for a central authority.

# Cryptographic proofs

Proving systems, used by all blockchains, are cryptographic protocols where a prover proves something to a verifier. In the case of Filecoin, the storage miner is responsible for proving that they're storing the correct data over time, and verifier duties are shared by all participants in the network.

In this tutorial we'll explore the cryptographic proofs that Filecoin uses to verify storage, called **Proof of Replication (PoRep)** and **Proof of Spacetime (PoSt)**.

It's important to note that cryptographic proofs are different from encryption. The Filecoin protocol does not provide encryption, although you may use it to store encrypted data.

Whereas blockchains often use proofs of work (meaning computation or processing power), Filecoin's proofs are proofs of useful storage (a kind of proof of stake). Because these proofs don't have to run continuously, they're more computationally efficient and less bad for the environment.


<Quiz id={"zkou1"} />

</Section>

<Section name="Preparing and transferring data" description="">

# Preparing data for storage

Before a system file (e.g. `puppy.gif`) can be stored on the Filecoin network, it must first be transformed into a Filecoin Piece.

In the first stage of this transformation, the system file is chunked up with UnixFS to create an IPLD DAG (Directed Acyclic Graph). You can learn more about DAGs (a form of merkle tree) in our Content Addressing on the Decentralized Web tutorial. This IPLD DAG has a payload CID, identical to an IPFS CID, which represents the root of the DAG.

The IPLD DAG is then serialized to a [CAR file](https://github.com/ipld/specs/blob/master/block-layer/content-addressable-archives.md#summary) and bit padded to make a Filecoin Piece. (Bit padding adds extra bits to make the piece conform to a standard size.) This piece has a unique piece CID, also known as a CommP (Piece Commitment).

Since payload CIDs and piece CIDs are cryptographic hashes of the data itself, they're unique, with identical CIDs guaranteeing identical content. Identical IPLD DAGs will produce identical payload CIDs and identical pieces will produce identical piece CIDs, no matter who's going to store or retrieve them.

# Negotiating a storage deal and transferring data

When a client negotiates a storage deal with a miner, they're hiring them to store a piece of data, which might be a whole or partial file. Miners store these pieces from one or more clients in sectors, the fundamental storage unit used by Filecoin. Sectors come in a variety of sizes, and a client can store data up to the largest sector size per deal. (Learn more about [sector sizes and storing large files](https://docs.filecoin.io/how-to/store/prepare-data/#for-files-bigger-than-a-sector).)

A piece CID is wrapped with other deal parameters to create a Deal Proposal. The deal CID contains information about the data itself, in the form of the piece CID, the identities of the miner and client, and other important transaction details.

The client sends this deal proposal to a miner, who agrees to store their data. Once the miner has confirmed, the client transfers their data to the miner. Once the miner has the data and verifies that it matches the piece CID noted in the deal proposal, they publish the deal proposal on Filecoin's blockchain, committing both parties to the deal.


<Quiz id={"5oir0"} />

</Section>

<Section name="Proof of Replication (PoRep)" description="">

In a Proof of Replication, a storage miner proves that they are storing a physically unique copy, or replica, of the data. Proof of Replication happens just once, at the time the data is first stored by the miner.

# Filling sectors and generating the CommD

As the storage miner receives each piece of client data, they place it into a sector. Sectors are the fundamental units of storage in Filecoin, and can contain pieces from multiple deals and clients.

Once a sector is full, a CommD (Commitment of Data, aka UnsealedSectorCID) is produced, representing the root node of all the piece CIDs contained in the sector.

# Sealing sectors and producing the CommR

Next, a process called sealing takes place.

During sealing, the sector data (identified by the CommD) is encoded through a sequence of graph and hashing processes to create a unique replica. The root hash of the merkle tree of the resulting replica is the CommRLast. (Learn more about merkle trees in our Content Addressing on the Decentralized Web tutorial.)

The CommRLast is then hashed together with the CommC (another merkle root output from Proof of Replication). This generates the CommR (Commitment of Replication, aka SealedSectorCID), which is recorded to the public blockchain. The CommRLast is saved privately by the miner for future use in Proof of Spacetime, but is not saved to the chain.

The encoding process is designed to be slow and computationally heavy, making it difficult to spoof. (Note that encoding is not the same as encryption. If you want to store private data, you must encrypt it before adding it to the Filecoin network.)

The CommR offers the proof we need that the miner is storing a physically unique copy of the client's data. If you store the same data with multiple storage miners, or make multiple storage deals for the same data with a single miner, each deal will have a different CommR.

The sealing process also compresses the Proof of Replication using zk-SNARKs to keep the chain smaller so that it can be stored by all members of the Filecoin network for verification purposes. We'll learn more about zk-SNARKs in a future lesson.

<Quiz id={"zi17w"} />

</Section>

<Section name="Proof of Spacetime (PoSt)" description="">

Whereas Proof of Replication is run once to prove that a miner stored a physically unique copy of the data at the time the sector was sealed, Proof of Spacetime (PoSt) is run repeatedly to prove that they are continuing to dedicate storage space to that same data over time.

PoSt builds upon several elements created during Proof of Replication: the replica, the privately saved CommRLast, and the publicly known CommR.

# How it works

First, PoSt randomly selects some leaf nodes of the encoded replica and runs merkle inclusion proofs on them to show that the miner has the specific bytes that should be there. Then, the miner uses the privately stored CommRLast to prove (without revealing its value) that they know of a root for the replica which both agrees with the inclusion proofs and can be used to derive the publicly-known CommR.

The final stage of PoSt compresses these proofs into a single zk-SNARK. (We’ll learn about zk-SNARKs in the next lesson.)

When miners agree to store data for a client, they're required to put down collateral. If they fail a Proof of Spacetime at any point during the contract, they'll be penalized. This is a key part of the incentivization that encourages good behavior amongst all the players in the Filecoin network.

<Quiz id={"oze1z"} />

</Section>

<Section name="zk-SNARKs" description="">

Both the Proof of Replication and Proof of Spacetime processes in Filecoin use zk-SNARKs for compression.

zk-SNARKs stands for "Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge." You can think of them as hashes of computations. They let us prove that a proof has been done correctly without having to reveal the details of the proof itself or the underlying data on which it's based.

# How it works

The process of creating Filecoin's zk-SNARKs is computationally expensive (slow), but the resulting end product is small and the verification process is very fast. Compared to the original proofs, zk-SNARKs are tiny, making them efficient to store in a blockchain. For example, a proof that would have taken up hundreds of kilobytes on the Filecoin chain can be compressed to just 192 bytes using a zk-SNARK.

As mentioned previously, everyone running a Filecoin node maintains an up-to-date version of the chain for verification purposes. Keeping each proof small with the assistance of zk-SNARKs minimizes the storage demands placed on each node in the Filecoin network, as well as the length of time it takes to verify a transaction.

<Quiz id={"4xdzu"} />

</Section>


<Section name="Verifying your deal" description="">

# Applications using libp2p
Once compressed, the key data needed to verify storage is stored on the Filecoin chain, a copy of which is maintained by each user running a node. This allows for Proof of Spacetime to run regularly over time.

As a storage client, you can run the `lotus client list-deals` command to list all of the storage deals proposed from that node. For example, here are the results from a node from which only one deal has been proposed:

```
$ lotus client list-deals

DealCid:    bafyreiefvrrv5j7omqzfersogg4nqzctyzj66rcmkwkbxxx5prvd5sklci
DealId:     2
Provider:   t01000
State:      StorageDealActive
On Chain?:  Y (epoch 59)
Slashed?:   N
PieceCID:   bafk4chzazx6u4luj34azuit37rlylgrcbgkaakqsjt5avsbolxale2igii3q
Size:       1016
Price:      1000000
Duration:   2744
```

Let's explore the data made available by this command:

- **DealCid**: Content identifier (CID) for the deal proposal.
- **DealId**: A unique ID for the deal.
- **Provider**: A unique identifier for the storage provider with whom the deal was made, also known as a storage miner.
- **State**: The state of the deal. This will most often be `StorageDealActive` once the data is stored and sealed. (Note that currently this will stay as `StorageDealActive` even after the duration of the deal expires or the miner fails a Proof of Spacetime, so it's important to refer to the `slashed` field for the latter case.)
- **On Chain?**: A boolean indicating whether the deal has been stored on the chain. If positive, this field will also indicate the epoch in which the data was stored. An epoch is a specific point on the chain. Lower numbers are further back in the history of the chain, while higher numbers are more recent.
- **Slashed?**: A boolean indicating whether the storage provider has failed a Proof of Spacetime. (If the miner stops storing your data, this value will change to Y and the miner will be penalized.)
- **PieceCID**: A CID (Content Identifier) representing the stored data, also known as CommP (Piece Commitment)
- **Size**: The bytes of data being stored.
- **Price**: The price per epoch in Filecoin Token (FIL) for the storage deal.
- **Duration**: The total duration of the agreed deal in epochs (one iteration of the blockchain, currently equivalent to 30 seconds.

# Compare these deals

For the quiz below, consider the following three deals:

```
$ lotus client list-deals

DealCid:    bafyreiefvrrv5j7omqzfersogg4nqzctyzj55rcmkwkbxxx6prvd5sklci
DealId:     32
Provider:   t01000
State:      StorageDealActive
On Chain?:  Y (epoch 59)
Slashed?:   N
PieceCID:   bafk4chzazx6u4luj34azuit37rlylgrcbgkaakqsjt5avsbolxale2igii3q
Size:       1016
Price:      1000000
Duration:   2744

DealCid:    bafyreiefvrrv5j7omqzfersogg4nqzctyzj44rcmkwkbxxx5prvd5sklci
DealId:     45
Provider:   t01000
State:      StorageDealActive
On Chain?:  Y (epoch 22)
Slashed?:   Y
PieceCID:   bafk4chzazx6u4luj34azuit37rlylgrcbgkaakqsjt5avsbolxale2igii3q
Size:       1016
Price:      1000000
Duration:   2744

DealCid:    bafyreiefvrrv5j7omqzfersogg4nqzctyzj33rcmkwkbxxx4prvd5sklci
DealId:     57
Provider:   t01000
State:      StorageDealActive
On Chain?:  Y (epoch 38)
Slashed?:   N
PieceCID:   bafk4chzazx6u4luj34azuit37rlylgrcbgkaakqsjt5avsbolxale2igii3q
Size:       1016
Price:      1000000
Duration:   2744
```

<Quiz id={"mmgtv"} />

</Section>


Learn how Filecoin's built-in verification methods make it possible to trust peers in an incentivized, decentralized file storage system

Verifying Storage on Filecoin

Protocol Labs

Niki Gokani

Learn how libp2p solves common networking problems through modularity, aiming to be the de facto peer-to-peer (P2P) library for the decentralized web

Introduction to libp2p

<Section name="Development" description="">

# Design guidelines

The design of the contract should be discussed ahead of time, prior writing any line of code.

# Documentation and specifications

Documentation can be written at different levels, and should be updated while implementing the contracts:

- **A plain English description of the system**, describing what the contracts do and any assumptions on the codebase.
- **Schema and architectural diagrams**, including the contract interactions and the state machine of the system. [Slither printers](https://github.com/crytic/slither/wiki/Printer-documentation) can help to generate these schemas.
- **Thorough code documentation**, the [Natspec format](https://solidity.readthedocs.io/en/develop/natspec-format.html) can be used for Solidity.

# On-chain vs off-chain computation

- **Keep as much code as you can off-chain.** Keep the on-chain layer small. Pre-process data with code off-chain in such a way that verification on-chain is simple. Do you need an ordered list? Sort the list offchain, then only check its order onchain.

# Upgradeability

We discussed the different upgradeability solutions in [our blogpost](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). Make a deliberate choice to support upgradeability or not prior to writing any code. The decision will influence how you structure our code. In general, we recommend:

- **Favoring [contract migration](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) over upgradeability.** Migration system have many of the same advantages than upgradeable, without their drawbacks.
- **Using the data separation pattern over the delegatecallproxy one.** If your project has a clear abstraction separation, upgradeability using data separation will necessitate only a few adjustments. The delegatecallproxy requires EVM expertise and is highly error-prone.
- **Document the migration/upgrade procedure before the deployment.** If you have to react under stress without any guidelines, you will make mistakes. Write the procedure to follow ahead of time. It should include:
  - The calls that initiate the new contracts
  - Where are stored the keys and how to access them
  - How to check the deployment! Develop and test a post-deployment script.

<Quiz id={"im6ar"} />

</Section>

<Section name="Implementation" description="">

**Strive for simplicity.** Always use the simplest solution that fits your purpose. Any member of your team should be able to understand your solution.

# Function composition

The architecture of your codebase should make your code easy to review. Avoid architectural choices that decrease the ability to reason about its correctness.

- **Split the logic of your system**, either through multiple contracts or by grouping similar functions together (for example, authentification, arithmetic, ...).
- **Write small functions, with a clear purpose.** This will facilitate easier review and allow the testing of individual components.

# Inheritance

- **Keep the inheritance manageable.** Inheritance should be used to divide the logic, however, your project should aim to minimize the depth and width of the inheritance tree.
- **Use Slither’s [inheritance printer](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) to check the contracts’ hierarchy.** The inheritance printer will help you review the size of the hierarchy.

# Events

- **Log all crucial operations.** Events will help to debug the contract during the development, and monitor it after deployment.

# Avoid known pitfalls

- **Be aware of the most common security issues.** There are many online resources to learn about common issues, such as [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [Capture the Ether](https://capturetheether.com/), or [Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/).
- **Be aware of the warnings sections in the [Solidity documentation](https://solidity.readthedocs.io/en/latest/).** The warnings sections will inform you about non-obvious behavior of the language.

# Dependencies

- **Use well-tested libraries.** Importing code from well-tested libraries will reduce the likelihood that you write buggy code. If you want to write an ERC20 contract, use [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20).
- **Use a dependency manager; avoid copy-pasting code.** If you rely on an external source, then you must keep it up-to-date with the original source.

# Testing and verification

- **Write thorough unit-tests.** An extensive test suite is crucial to build high-quality software. These must be combined with static analysis, property-based testing, and formal program analysis techniques to prevent vulnerabilities. Solely 100% unit test coverage is insufficient to detect all vulnerabilities. 
- **Write [Slither](https://github.com/crytic/slither) and [Echidna](https://github.com/crytic/echidna) custom checks and properties.** Automated tools will help ensure your contract is secure. Review the rest of this guide to learn how to write efficient checks and properties.

# Solidity

- **Favor Solidity versions outlined in our [Slither Recommendations](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-99)** In our opinion, older Solidity are more secure and have better built-in practices. Newer Solidity versions may be too young to be used in production and require additional time to mature.
- **Use a stable release to compile; use the latest release to check for warnings.** Check that your code has no reported issues with the latest compiler version. However, Solidity has a fast release cycle and has a history of compiler bugs, so we do not recommend the latest version for deployment (see Slither’s [solc version recommendation](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-39)).
- **Do not use inline assembly.** Assembly requires EVM expertise. Do not write EVM code if you have not _mastered_ the yellow paper.

<Quiz id={"2y4dg"} />

</Section>

<Section name="Deployment" description="">

# Best Practices

Once the contract has been developed and deployed:

- **Monitor your contracts.** Watch the logs, and be ready to react in case of contract or wallet compromise.
- **Add your contact info to [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts).** This list helps third-parties contact you if a security flaw is discovered.
- **Secure the wallets of privileged users.** Follow our [best practices](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) if you store keys in hardware wallets.
- **Have an incident response plan.** Consider that your smart contracts can be compromised. Even if your contracts are free of bugs, an attacker may take control of the contract owner's keys.

# Incident Response Recommendations 

We provide recommendations around the formulation of an incident response plan. 

- [x] **Identify who (either specific people or roles) is responsible for carrying out the mitigations (deploying smart contracts, pausing contracts, upgrading the front end, etc.).** \
Specifying these roles will strengthen the incident response plan and ease the execution of mitigating actions when necessary


- [x] **Document internal processes for situations in which a deployed remediation does not work or introduces a new bug.** \
Consider adding a fallback scenario that describes an action plan in the event of a failed remediation


- [x] **Clearly describe the intended process of contract deployment.**

- [x] **Consider whether and under what circumstances your company will make affected users whole after certain issues occur.** \
Some scenarios to consider include an individual or aggregate loss, a loss resulting from user error, a contract flaw, and a third-party contract flaw


- [x] **Document how you plan to keep up to date on new issues, both to inform future development and to secure the deployment toolchain and the external on-chain and off-chain services that the system relies on.** \
For each language and component, describe the noteworthy sources for vulnerability news. Subscribe to updates for each source. Consider creating a special private Discord/Slack channel with a bot that will post the latest vulnerability news; this will help the team keep track of updates all in one place. Also consider assigning specific team members to keep track of the vulnerability news of a specific component of the system

- [x] **Consider scenarios involving issues that would indirectly affect the system.**

- [x] **Determine when and how the team would reach out to and onboard external parties (auditors, affected users, other protocol developers, etc.).** \
Some issues may require collaboration with external parties to efficiently remediate them

- [x] **Define contract behavior that is considered abnormal for off-chain monitoring.** \
Consider adding more resilient solutions for detection and mitigation, especially in terms of specific alternate endpoints and queries for different data as well as status pages and support contacts for affected services

- [x] **Combine issues and determine whether new detection and mitigation scenarios are needed.**

- [x] **Perform periodic dry runs of specific scenarios in the incident response plan to find gaps and opportunities for improvement and to develop muscle memory.** \
Document the intervals at which the team should perform dry runs of the various scenarios. For scenarios that are more likely to happen, perform dry runs more regularly. Create a template to be filled in after a dry run to describe the improvements that need to be made to the incident response

<Quiz id={"342kn"} />

</Section>



Some tips and best practices around building secure smart contracts

Smart Contract Development Guidelines

Trail of Bits

Nat Chin

<Section name="Introduction" description="" hidden="false">

# What is a Bridge?

A bridge (or interoperability network) is a system that relays assets and/or data between blockchains.

# The Bridging Landscape

One of the key challenges of blockchains & distributed systems is that they **always have tradeoffs.**

For bridges, historically this has meant that bridges must navigate compromises between:

1. **Trust-minimization:** The system does not introduce new trust/security assumptions beyond those of the underlying domains.
2. **Generalizeability:** The system supports passing around arbitrary data and not just funds.
3. **Extensibility:** The system can be deployed without lots of custom work for a variety of different types of underlying domains.
4. **Latency:** How quickly the data is delivered to the destination domain.

We can classify all bridges by their properties/tradeoffs:

## Externally Verified Bridges

![alt text](https://i.imgur.com/TsEtUxW.png)

Externaly verified protocols rely on an external set of validators to relay data between chains. This is typically represented as an MPC system, oracle network, or threshold multisig.

These systems have low latency, support arbitrary data passing, and are easily portable between domains but you are now trusting the bridge verifiers to secure your system.

## Natively Verified Bridges

![alt text](https://i.imgur.com/XsIHnLO.png)

Natively verified protocols are ones where all of the underlying chains’ own verifiers are fully validating data passing between chains. Typically this is done by running a light client of one chain in the VM of another chain and vice versa.

These systems are the most trust-minimized systems as they rely directly on domain validators for security, support arbitrary data, and have low latency. However, because the implementation of these systems is so deeply tied with consensus, they require custom implementations for each domain.

## Locally Verified Bridges

![alt text](https://i.imgur.com/4H77ID8.png)

Locally verified protocols are ones where only the parties involved in a given cross-domain interaction verify the interaction. Locally verified protocols turn the complex n-party verification problem into a much simpler set of 2-party interactions where each party verifies only their counterparty. This model works so long as both parties are economically adversarial — i.e. there’s no way for both parties to collude to take funds from the broader chain.

These protocols are fast, extensibile, and trust-minimized but cannot support arbitrary messages due to their adversarial nature. An NFT, for instance, would not be able to be 1:1 backed by a counterparty.

## Optimistic Bridges

![alt text](https://i.imgur.com/e0bhQJC.png)

Optimistic bridges, similar to optimistic rollups, use **fraud proofs** to ensure the validity of data relayed across chains. Every message that passes through an optimistic bridge remains in a “pending” state during the dispute window until it is considered valid. During this time, **watchers** can dispute the message if the data is incorrect.

While slow, these protocols are extensible, generalizable, and trust-minimmized.

<Quiz id={"h1v4v"} />

<Quiz id={"k0zpw"} />

<Quiz id={"5zq3q"} />

</Section>

<Section name="Bridge Security" description="">

There are a few different types of important security in the bridging ecosystem, each asking a specific question:

**Economic Security.** How much does it cost to corrupt the system?
   
**Implementation Security.** How complex is the system to implement? What does the security hygiene of implementers look like?
   
**Environmental Security.** How can the system withstand attacks on underlying domains?

# Security of Different Bridge Protocols

## Economic Security

To maximize economic security, protocols must maximize the size and diversity of their validator to increase the cost and complexity of bribes.

| Bridge Type             | Corruption Costs           |
| ----------------------- | --------------------------------- |
| `External`     | `k-of-m of the external verifiers of the system` |
| `Native`       | `k-of-n of the underlying domain validators`                            |
| `Local`        | `2-of-2 counterparties`                    |
| `Optimistic`   | `m-of-m of the watchers in the system`     |

Externally validated bridges have the lowest economic security, while natively verified bridges have the highest security.

## Implementation Security

To maximize implementation security, protocols should be incredibly simple and easy to implement.

| Bridge Type             | Complexity       |
| ----------------------- | --------------------------------- |
| `External`     | `Medium (requires offchain coordination)`  |
| `Native`       | `High (requires custom implementations)`   |
| `Local`        | `Medium (requires offchain coordination)`  |
| `Optimistic`   | `Low (standalone, portable components)`    |

While natively verified bridges have a high degree of economic security, their lack of extensibility increases the implementation complexity substantially.

In addition to keeping the protocol simple, implementation risk can be constrained by:

- Following secure development practices (contract audits, fuzzing, etc.)
- Native mechanisms to prevent and deter fraud (slashing, watchers, pausability, etc.)

## Environmental Security

Bridges act as an oracle of information between chains, and must be able to preserve the integrity of state between chains with differing security thresholds (i.e. prevent 51% attacks from impacting multiple domains). While these types of attacks are difficult to detect onchain, they are trivial to detect offchain. 

To constrain environment risk, protocols should use latency to their advantage to allow system relayers to detect and respond to these types of attacks.

| Bridge Type             | Latency as a safety mechanism   |
| ----------------------- | --------------------------------- |
| `External`     | `Possible, but not required.`  |
| `Native`       | `Not possible, uses state directly.`   |
| `Local`        | `Possible, but at the expense of prolonged user lockups.`  |
| `Optimistic`   | `Exists, fraud windows are built-in`    |


<Quiz id={"yo2e6"} />

<Quiz id={"h38ot"} />

</Section>

<Section name="Understanding Connext" description="">

Connext powers fast, trust-minimized communication between blockchains.

Our goal is to create a world where:

1. Users never need to know what chain or rollup they're on (unless they want to!)
2. Developers can build applications that utilize resources from many chains/rollups simultaneously

# Modular Interoperabilty

There is no monolithic architecture that will give bridges *all* of the desirable properties, but we can get close to the ideal outcome by modularizing the protocol stack:

| Layer                   | Protocol/Stakeholders             |
| ----------------------- | --------------------------------- |
| `Application Layer`     | `Crosschain Applications (xApps)` |
| `Liquidity Layer`       | `NXTP`                            |
| `Messaging Layer`       | `Rollup AMBs, IBC, XCMP, etc.`                       |
| `Transport Layer`       | `Connext Routers`                 |


Let's take a closer look at some of these:

1. xApps are applications built by developers like you!
2. NXTP is a *liquidity* layer and *developer interface* built by Connext on top of a messaging protocol.
3. The messaging layer uses a combination of an optimistic mechanism and rollup-native AMBs to pass data between evm domains.
4. Routers “short-circuit” delays in processing messages by immediately executing calls/providing liquidity on the destination chain. **This removes latency in all user-facing cases.**

A simple mental model is to think of Connext as the liquidity layer to an AMB messaging layer. Connext and AMBs, as well as optimistic bridges, together provide the two halves of the “ideal” solution for interoperability.

# What does the Connext flow look like?

![alt text](https://i.imgur.com/SPCNlfI.png)

In this diagram we can observe two domains, "origin" and "destination", and two paths, "fast" and "slow".

In this case, let’s assume the intention of the user is to bridge tokens from the origin to the destination domain, and have access to fast liquidity.
Unlike bridging through an AMB alone, which often comes with several hours or days of latency for the user, Connext shortcuts this by allowing its routers to front you the capital, thereby taking on the liquidity risk for you while they wait for the tokens to move through the slow path. In cases where the messaging system delivers a bridge asset (i.e. minted asset), routers will also manage that complexity for you.

It's important to note that if the user is bridging data, or if the call needs to be authenticated by the caller, the bridging operation will always go through the slow path. This maintains data integrity by allowing the AMB verification process to complete.

# What can you build with Connext?

Some example use cases:

- Execute the outcome of **DAO votes** across chains
- Lock-and-mint or burn-and-mint **token bridging**
- **Aggregate DEX liquidity** across chains in a single seamless transaction
- Crosschain **vault zaps** and **vault strategy management**
- **Lend funds** on one chain and borrow on another
- Bringing **UniV3 TWAPs** to every chain without introducing oracles
- **NFT bridging** and chain-agnostic NFT marketplaces
- **Store data on Arweave/Filecoin** directly from within an Ethereum smart contract


# How do I interact with Connext?

Developers can call `xCall`, and the protocol will then splits actions between a Liquidity Layer (Connext) and a Messaging Layer.

You can interact with xCall in ways described in the `Send your first xCall` section of this document

# How do I interact with the Connext community?

Find our discord at [https://discord.gg/pef9AyEhNz](https://discord.gg/pef9AyEhNz) and join the `#dev-hub` channel

<Quiz id={"b53zb"} />

</Section>

<Section name="XCall Me Maybe" description="">

# The Entrypoint

The main entrypoint for interacting with the Connext protocol is `xcall`. This method kicks off a crosschain interaction, and all the user has to do is wait for it to complete on the destination chain. There are *no required user interactions past this transaction*!

Subgraphs are available to track the progress of all in-flight transactions.

 > If you are interested in becoming elligible for our [EthGlobal `xcall` pool bounty](https://www.notion.so/connext/Connext-Hacker-Kit-febb25e70b6c4596a57a1e05b6df4b19#e6240c491e17496cb7cd02e3d40daf09) make sure to follow this simple [quickstart tutorial](https://docs.connext.network/developers/sdk/sdk-quickstart) to submit your first `xcall`!


# Usage

```solidity
function xcall(XCallArgs calldata _args)
```

---

## XCallArgs

```solidity
struct XCallArgs {
  CallParams params;
  address transactingAsset;
  uint256 transactingAmount;
  uint256 originMinOut;
}
```

**`transactingAsset`**

Refers to the contract address of the asset that is to be bridged. This could be the adopted, local, or canonical asset (see [this](../faq#what-does-it-mean-when-referring-to-canonical-representation-and-adopted-assets) for an explanation of the different kinds of assets).

Usually a xApp will have a higher-level function wrapping `xcall` in which the asset will be passed as an argument. This allows users to specify which asset they want to work with.

If the `xcall` is calldata-only (e.g. doesn't bridge any funds), any registered asset can be used here as long as `amount: 0`.

**`transactingAmount`**

The amount of tokens to bridge specified in standard format (i.e. to send 1 USDC, a token with 10^18 decimals, you must specify the amount as `1000000000000000000`).

**`originMinOut`**

The minimum amount received after the swap from adopted -> local on the origin domain. This is the way to specify slippage due to the StableSwap Pool, if applicable. 

For example, to achieve 3% slippage tolerance this can be calculated as `(amount / 100) * 97`.

---

**`CallParams`**

```solidity
struct CallParams {
  address to;
  bytes callData;
  uint32 originDomain;
  uint32 destinationDomain;
  address agent;
  address recovery;
  bool forceSlow;
  bool receiveLocal;
  address callback;
  uint256 callbackFee;
  uint256 relayerFee;
  uint256 destinationMinOut;
}
```

**`to`**

Refers to an address on the destination chain. Whether it’s a user’s wallet or the address of another contract depends on the desired use of `xcall`. 

If the `xcall` is just used to bridge funds, then the user should be able to specify where the funds get sent to.

If the `xcall` is used to send calldata to a target contract, then this address must be the address of that contract. 

**`callData`**

In the case of bridging funds only, this should be empty (""). If calldata is sent, then the encoded calldata must be passed here. 

**`originDomain / destinationDomain`**

These refer to Domain IDs (*not* equivalent to “Chain IDs”).

**`agent`**

The address that is allowed to execute transactions on behalf of `to` on the destination domain. Usually this is a relayer's job but the user can specify an address (including themselves) to do it as well.

This cannot be `address(0)` if `receiveLocal: false`. Some address must be able to call `forceReceiveLocal` on [BridgeFacet.sol](https://github.com/connext/nxtp/blob/main/packages/deployments/contracts/contracts/core/connext/facets/BridgeFacet.sol) in case transfers are facing unfavorable slippage conditions for extended periods.

**`recovery`**

The address on destination domain that should receive funds if the execution fails. This ensures that funds are never lost with failed calls.

**`forceSlow`**

Since Solidity doesn't allow for default parameters, integrators must explicitly set this to `true` when using authenticated (slow path) calls.

If the `xcall` is unauthenticated (e.g. bridging funds), setting this to `true` allows users to force the `xcall` through the slow path and save on the 0.05% transaction fee levied by routers. This is an option for users who don’t care for speed to optimize on cost.

**`receiveLocal`**

Setting this to `true` allows users to receive the local bridge-flavored asset instead of the adopted asset on the destination domain. 

**`callback`**

The address of a contract that implements the [ICallback](https://github.com/connext/nxtp/blob/main/packages/deployments/contracts/contracts/core/promise/interfaces/ICallback.sol) interface. See the [detailed spec](https://github.com/connext/nxtp/discussions/883) for callback interaction. 

If the target contract doesn’t return anything, this field must be `address(0)`. Otherwise, the specified address must be a contract.

**`callbackFee`**

Similar to the relayerFee except this is for paying relayers on the callback execution. If `callback: address(0)`, then this must be `0`.

This fee is also bump-able from the origin domain.

**`relayerFee`**

This is a fee paid to relayers for relaying the transaction to the destination domain. The fee must be high enough to satisfy relayers’ cost conditions for relaying a transaction, which includes the gas fee plus a bit extra as incentive. This is paid in the origin domain’s native asset - it’s locked on the origin domain and eventually claimed by the relayer. 

Connext contracts will assert that the `relayerFee` matches what is sent in `msg.value` for the `xcall`. If, for any reason, the initial `relayerFee` is set too low, [BridgeFacet.sol](https://github.com/connext/nxtp/blob/main/packages/deployments/contracts/contracts/core/connext/facets/BridgeFacet.sol) has a `bumpTransfer` function that can be called on the origin domain to bump (increase) the initial fee until it’s sufficient for relayers.

**`destinationMinOut`**

The minimum amount received after the swap from local -> adopted on the destination domain. This is the way to specify slippage due to the StableSwap Pool, if applicable.

For example, to achieve 3% slippage tolerance this can be calculated as `(amount / 100) * 97`.


<Quiz id={"r8k8w"} />

</Section>

<Section name="Developer Resources" description="">

- Check out our [hacker kit](https://www.notion.so/connext/Connext-Hacker-Kit-febb25e70b6c4596a57a1e05b6df4b19) that we put together for hackathon participants
- Our [technical documentation](https://docs.connext.network) is a great starting point to read more into technical details
- Our [Connext Academy](https://connext.academy) is a community driven information hub to read more coverage
- Join our [Discord](https://discord.gg/pef9AyEhNz) to ask the team for help or to meet the community

# Existing Implementations / Guides

- With the [SDK Quickstart](https://docs.connext.network/developers/sdk/sdk-quickstart)
- With the [Solidity Quickstart](https://docs.connext.network/developers/contracts/contracts-quickstart)
- Using any language with a local [http-server](https://github.com/connext/nxtp/tree/main/packages/examples/sdk-server)
- A [bridge frontend implementation](https://github.com/connext/nxtp/tree/main/packages/examples/bridge-reference/) shows you how to quickly build a minimal bridge UI


<Quiz id={"cjwp8"} />

</Section>


Learn the specifics of Connext cross-chain protocol

Bridging Tokens & Data

Connext

Matthew Hammond

<Section name="Introduction" description="">

# What is Push Protocol

Push Protocol (Previously Ethereum Push Notification Service EPNS) is the world’s first decentralized communication & notification protocol for Web3.

Using the protocol, any smart contract, dApp, or backend service can send on-chain or off-chain notifications tied to the wallet addresses of users in a gasless, multichain, open, and platform-agnostic way.

Being an open communication middleware, notifications can be integrated and shown on any crypto wallet, mobile app, browser extension, or dApps enabling a native communication layer for Web3.0


<Quiz id={"bvs75"} />

<Quiz id={"dmqa5"} />

<Quiz id={"1k16i"} />


</Section>

<Section name="Channels" description="">

Any user who activates themselves as a service on the protocol to send notifications for its users can be considered a Channel.

In other words, any service, i.e., a dapp, protocol, or even a web2 service, that wants to send notifications out to its web3 users can choose to become a channel and establish an adequate communication bridge with its users.

# Channel Setup

The creation of a channel is just a one-time simple procedure. It must be noted that channel creation only happens on the Ethereum blockchain and one wallet address can only create one channel only the protocol.

> ***Note: Although channel creation only happens on the Ethereum blockchain, the protocol is designed to be chain-agnostic, i.e., channel owners can choose to send notification on any chain of their choice and not just Ethereum network***

A successfully created channel can send notifications to its subscribers, directly tied to their wallet addresses.

Once any user opts in and becomes a subscriber for a channel, he/she shall receive notifications from that channel directly in their inbox.
Users who are not a subscriber of a particular channel, receive notifications from that channel in their spam box.

> ***Opting In or Opting out of a Channel is a completely gasless transaction and requires no fees.***


<Quiz id={"rvwn7"} />

<Quiz id={"8kyj7"} />

<Quiz id={"1f3i5"} />

</Section>

<Section name="Notifications" description="">

Any successfully created channel, in its active state,  can send notifications to its subscribers about a wide range of things related to defi, governance proposals, web3 news, or any other crucial updates about their protocol/services.

Notifications land in the inbox of those users who are subscribed to the channel. Non-subscribers of a particular channel aren't alerted about notifications from that channel as they land in their spam box.

# Types of Notifications

**`Broadcast Notifications`**: This type of notification is basically broadcasted or sent to all the subscribers of a channel at once.

**`Targeted Notifications`**: As the name suggests, this type of notification allows channel owners to notify a specific wallet address.

**`Subset Notifications`**: Subset notifications are quite helpful when a particular group of subscribers of a channel is supposed to be notified.

# Delegated Notifications

Delegated notifications is a feature that allows channel owners to delegate their power of sending notifications to any other wallet address or multiple wallets of their choice.

Once approved by the channel owner, a wallet address can send notifications on behalf of the channel to its subscribers. The channel owner can, however, revoke the approval at any given time.

This mechanism of sending delegated notifications is quite effective in providing value-added services to the channels. It also ensures the availability of mechanisms that can be used by Push Protocol or any other third-party infrastructure to send on-chain notifications on the channel’s behalf.


<Quiz id={"z288e"} />

<Quiz id={"ru9vz"} />

<Quiz id={"hf853"} />


</Section>

<Section name="Push Protocol Smart Contracts" description="">

In order for the protocol to be chain-agnostic as well as truly decentralized, Push Protocol smart contracts play a major role.
The Push Protocol has now been divided into two different smart contracts, i.e., Push Protocol Core & Push Protocol Communicator.

# Push Protocol Core Contract

The EPNSCore protocol, as the name might indicate, is the main smart contract as it handles some of the most crucial features like Channel creation, governance, channel state changes as well as funds and incentive mechanisms, etc.
It’s very important to note, however, that the Push Protocol Core smart contract will only be deployed on the Ethereum blockchain and not on any other chain.

# Push Protocol Communicator Contract

Unlike the Push Protocol Core smart contract, the communicator protocol is designed to be deployed on multiple chains. This is also one of the imperative reasons behind the communicator contract being lightweight and not reliant on the core contract.

The Push Communicator protocol is comparatively quite simple. The communicator protocol includes features that allow users to subscribe to a channel, unsubscribe from a channel as well as the imperative one, i.e., sending notifications. As the communicator protocol can be deployed on various chains, it allows us to trigger notifications on multiple chains and not just the Ethereum blockchain.


<Quiz id={"q1n2v"} />

<Quiz id={"ut8uk"} />

<Quiz id={"xsgv2"} />


</Section>

<Section name="Push Nodes" description="">

Push Nodes are the central piece of the network that enables the blockchain of Web3 notifications to work. In essence, they are validators that can be run by anyone in the future with staking and slashing

![](https://i.imgur.com/zY9YqmS.png)

# 3 main tasks of Push Nodes

**Listening** \
Push Nodes listens to Push Protocol Communicator smart contracts on every blockchain. They also enable off-chain or direct communication via API calls either from a backend or a dApp. This enables Push Protocol to support just about any Web3 service… ie: smart contracts, dApps, backends or direct payloads.

**Validating and Governing** \
The communication which is driven by the Push Protocol Communicator layers require validation. This validation involves ensuring that whether or not the channel exists, the channel is not spamming, the channel is cross-chain verified.le governance and to verify the existence of the channel.

**Admitting to Network / Dispatching** \
Lastly, the Push Nodes admit these notifications that are tied to wallet address in the network which can then be tapped into by any crypto frontend / wallet to display them. The dispatch functionality is also present in these nodes to allow bridging of Web3 notifications to be displayed in Web2 apps in case the wallet / frontend / software wants to enable that instead of handling direct socket connection.


<Quiz id={"rhwm3"} />

<Quiz id={"eeyry"} />

<Quiz id={"8ry0a"} />


</Section>

<Section name="Creating a Channel" description="">

Creating a channel is the very first step for sending notifications via Push Protocol.

Any wallet which activates itself on the Push Protocol to send a notification is called a Channel.

Using the Push dApp or our smart contracts, anyone with a wallet address on the Ethereum network can create their own channel. It can be deployed on;

* The Ethereum Mainnet (via[ Prod dApp](https://app.epns.io/)), or
* Kovan Test Network (via [Staging dApp](https://staging-app.epns.io/))

# Requirements for Setting Up a Channel

Ideally, there are 6 crucial requirements for creating a Channel.

1. A Channel Name
2. Channel Logo (an image of size `128px x 128px`)
3. Alias Network (required for multi-chain, for example, if on Polygon, provide Polygon address of your contract, else can be left blank, currently supports only Polygon).

> *Important: This field needs to be provided at the very start in case you want to enable your channel on other blockchain networks, see  for guides and to understand the process.*

4. A brief Channel Description (250 Characters)
5. Channel CTA (Call To Action link)
6. An amount of 50 DAI in your Wallet (and some ETH )

> *If you are setting up a Channel on Staging dApp, you can get Free DAI and Kovan ETH from the dApp & online faucets. No need for real DAI/ETH on the Staging app 😁*

# Enabling Channel on Other Chain

As previously mentioned, although channel creation happens on Ethereum itself, the protocol is designed to enable the channel to send notification on any chain.

This is exactly where Channel Alias set-up plays a major role.

# Channel Alias

In order to enable your channel to be blockchain-agnostic and allow multi-chain communication, we have introduced a new term called Channel Alias. This property is what enables your channel to send notifications on any other blockchain.

In simpler terms, a channel alias address is a native representation of your Ethereum channel on any other EVM or Non-EVM chain through which you wish to communicate with your subscribers.

This means that although channel creation must happen on the Ethereum blockchain itself, notifications or communications can be carried out on any other chain through the same channel if the channel has its alias address adequately configured for that particular chain.

You can communicate with your subscribers on Polygon, BSC, Solana, etc. using an Alias address that is compatible with that respective blockchain.

## How to set up Channel Alias?

Now that we understand channel alias, it's time to understand how one set up their channel alias address for any other chain.

In order to set-up channel alias address for any preferred chain, one has to go through 2 simple steps:
* Selecting the chain and providing the right alias address for the channel during channel creation itself.
* Verification of the alias Address on the selected chain.

<Quiz id={"5ii72"} />

<Quiz id={"3f3v1"} />

<Quiz id={"1uw25"} />


</Section>

<Section name="Sending Notifications" description="">

Who can Send Notifications? As per the current design of the protocol, there can be 3 main actors who can send notifications:

**Channel Owners** \
The owners of a particular channel can send notifications to their subscribers.

**Delegate Notification Senders** \
Channel owners can allow any particular wallet address to send notifications on behalf of his/her channel. This feature is called delegated notifications.

**Notifications To Yourself** \
The Push Communicator allows any address to send notifications to themselves 😃 It’s important to note, however, that the address sends the notification to themselves only.

> **Note:**
> *Sending notifications is a **gasless** transaction and therefore notification senders need not pay any gas fee while sending notifications via the Dapp.*
>
> *Gas Fees are only applicable when on-chain notifications are triggered directly from smart contracts.*


# Triggering Notifications

Push Protocol provides many ways to trigger a notification. For instance, a channel owner or delegate can trigger notifications using:

[Push Protocol Dapp](https://docs.epns.io/developers/developer-zone/sending-notifications/dapp-serverless-workflow)
The dapp provides a simple user interface for channel owner to trigger any type of notification they want for their subscribers.

[Using Push Protocol SDK](https://docs.epns.io/developers/developer-tooling/epns-sdk)
Using the notification, one can not only send notifications of all types, but also fecth a notifications for wallet and use the sdk features to integrate notifications into their own frontends.

[Using Subgraph](https://docs.epns.io/developers/developer-zone/sending-notifications/using-subgraph)
Push Protocol has developed an in-house Helper Function specifically for The Graph Protocol that allows you to read events from the Subgraph and define notifications accordingly.
Once defined, they will be stored on the Subgraph in a Long String format.
Push Protocol Push Nodes can, later on, fetch the notifications defined on a Subgraph and push them accordingly to Subscribers of the Channel.

[Using Showrunners](https://docs.epns.io/developers/developer-zone/sending-notifications/using-showrunners-scaffold-gasless)
The showrunners framework is a scaffold that developers can use to build out notifications for their use cases. Showrunners framework provides the tools and helpers required for constructing the payload and sending the notification using the Push Protocol infrastructure.


<Quiz id={"qmr24"} />

<Quiz id={"xf875"} />


</Section>

<Section name="Receiving Notifications" description="">


Receiving notifications is a fairly simple process and can be done very easily.

As of now, Push Protocol allows you to receive notifications directly to your wallet addresses through the crypto front-ends, in the form of SNS Notifications etc.

# Receiving notifications via Push Crypto Frontends

* [Using Push Protocol dapp](https://app.epns.io/)
* [Using extension](https://chrome.google.com/webstore/detail/epns-protocol-alpha/lbdcbpaldalgiieffakjhiccoeebchmg)
* [Using Mobile App](https://play.google.com/store/apps/details?id=io.epns.epns&hl=en&gl=US)

# Receiving notifications via SNS

## What are SNS Notifications
SNS module for Push Delivery Nodes allows any developer to receive notifications, chats, or any other form of web3 communication directly to the platform they are building with the help of webhooks.

Hosted SNS Module is a mid-level solution that eliminates all the heavy load of running a node or syncing information and gives you webhooks that you implement to start receiving notifications, chats, or any other web3 communication in your software.

## How to get started with hosted SNS module?

Integrating the SNS module into your code takes less than 10 mins and contains just 3 steps:

**Step 1** \
Implement a webhook to listen to AWS SNS. Here’s a boilerplate along with specs to get you npm installed and running: https://github.com/ethereum-push-notification-service/epns-sns-boilerplate

**Step 2** \
You will need to open an endpoint either at a dedicated IP that listens to SNS or, if you are testing locally, have to expose the public endpoint for which tons of software is available.

> *Hint: For testing locally, You can also use ngrok to expose the public endpoint. If you use this with the boilerplate, the port needs to be 6000. The ngrok URL is now the SNS endpoint required in step 3*.

**Step 3** \
Once you set up this, you need to contact us by either shouting / tagging us on Discord or reaching out via the contact form. We need this as the SNS module requires whitelisting of your webhook endpoint.

> [Push Protocol Boiler Plate](https://github.com/ethereum-push-notification-service/epns-sns-boilerplate) can also be used as a starting point to consume the feeds from the Push SNS Topic.

- [x] **Watch this quick video guide to ensure the right set-up**

[**SNS for Push Delivery Node**](https://www.youtube.com/watch?v=VocGkaL0eEA)


<Quiz id={"622d8"} />

<Quiz id={"x6qbn"} />


</Section>

<Section name="Conclusion" description="">

# Congratulations, You're a ROCKSTAR!

You have successfully understood all EPNS concepts! Take a look at the following resources to get more involved in the Push ecosystem

## Push Protocol Developer Resources

1. [**Developer Documentations**](https://docs.epns.io/developers/)
2. [**Push Protocol Github**](https://github.com/ethereum-push-notification-service)  
3. **Push Protocol SDK Packages:**
* [@epnsproject/sdk-restapi](https://www.npmjs.com/package/@epnsproject/sdk-restapi) Provides access to EPNS backend APIs.
* [@epnsproject/sdk-uiweb](https://www.npmjs.com/package/@epnsproject/sdk-uiweb) Provides React based components to show Notifications, Spam, SubscribedModal etc for dApps.
* [@epnsproject/sdk-uiembed](https://www.npmjs.com/package/@epnsproject/sdk-uiembed) Provides vanilla JS sidebar notifications for any dApp.

---

1. Explore the [Push Protocol dapp ](https://app.epns.io/)
2. Connect with us on [Discord](https://discord.gg/epns)

</Section>


Learn more about how Push works and the protocol concepts

Intro to Push Protocol

Push Protocol

Zaryab Afser

<Section name="1. Introduction" description="Introduction to ENS">

## What is ENS

The way we interact with most things on-chain is through the use of our addreses.

The Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain.

ENS's job is to map human-readable names like 'alice.eth' to machine-readable identifiers such as Ethereum addresses, other cryptocurrency addresses, content hashes, and metadata.

ENS also supports 'reverse resolution', making it possible to associate metadata such as canonical names or interface descriptions with Ethereum addresses.

However ENS provides tons of cool functionality, this guide will focus on integrating Username and Avatar resolution in your dApp.

## ENS Registration

Names can be registered through the [ENS Manager](https://app.ens.domains/), third-party applications (such as [ENS Fairy](https://ensfairy.xyz/), [Coinbase](https://www.coinbase.com/), or [Rainbow](https://rainbow.me/)), or directly on-chain.

<Quiz id={"89b8i"} />

</Section>


<Section name="2. Functionality Overview" description="Understanding everything your ENS is capable of">

## Name Resolution

At its core ENS allows us to convert a human-readable name like **nick.eth** into a machine-readable address such as **0xb8c2C29ee19D8307cb7255e1Cd9CbDE883A267d5**. This is generally referred to as **forwards resolution**.

The most common place you will notice your own ENS name is in dApps. Due to the Primary Name (aka **reverse resolution**) abilities of the ENS contracts dApps can fetch a user's primary name and show this in their interface. This allows us to give users the same profile across the entire ecosystem.

![ENS Username & Avatar](https://i.imgur.com/pO8xwN9.png)

## Subdomains & Custom Resolver

ENS allows users to write their own resolver in the form of a smart contract. You can extend the behaviour of domains by altering the **Resolver** field of your domain and pointing it towards your smart contract. This means you could write your own logic to control records, subdomains, and do all sorts of things like assign subdomains to NFT holders, or anything you could image. Read more about [writing your own resolver](https://docs.ens.domains/contract-developer-guide/writing-a-resolver).

![ENS Subdomains](https://i.imgur.com/LcbrAwc.png)

## Internet Domain Compatability

In addition to the smart contract powered **.eth** TLD, the ENS smart contracts allow for any Internet Domain (.com, .net, .org, etc) to be used as an ENS Name through the use of our DNSSEC Integration. Read more about [ID Compatability](https://docs.ens.domains/dns-registrar-guide).

![Internet Domain Compatability](https://i.imgur.com/hoUNTgf.png)

## Offchain Data

With the recent implementation of CCIP Read (Also known as [EIP-3668](https://eips.ethereum.org/EIPS/eip-3668)) we are able to read data from other chains or from other external locations. This enables us to have name information controlled by for example layer 2's, rollups, other chains, and centralized servers. More information about ENS and L2 Support can be found in the [ENS Layer2 and offchain data support
](https://docs.ens.domains/dapp-developer-guide/ens-l2-offchain).

![ENS Offchain](https://i.imgur.com/tmb7Qu3.png)

## Question

<Quiz id={"bv6ew"} />


<Quiz id={"qrakr"} />


</Section>

<Section name="3. Registering an ENS" description="Getting your ">

## How to register

Registering your first ENS name is super easy through the use of the [ENS Manager](http://app.ens.domains/).

![Search your Name](https://i.imgur.com/D4ntUeO.png)

Once you arrive at the name's page and the name is available. (Checkout the **register** tab). You should see a live calculation of the costs for registering that name. Names with fewer then 5 characters, and recently expired names have different costs. For more information on registration costs, check our [FAQ](https://docs.ens.domains/permanent-registrar-faq#how-much-will-the-yearly-renewals-cost).

![](https://i.imgur.com/xlcWoJ4.png)

Once you click the **Request to Register** button and confirm the transaction the manager will reserve the name for you. After this you will need to wait for one minute. This is done to protect you from frontrunning and ensures you get the name you desired.

![](https://i.imgur.com/D8EUxod.png)

![](https://i.imgur.com/pGMw8Ce.png)

![](https://i.imgur.com/pbTJ2vq.png)

Great! Our name is now reserved for our second transaction. You can now click the **Register** button to complete the registration process.

![](https://i.imgur.com/3NrIBEl.png)

**Congratulations!** 🎉 You now own an ENS name! To set it as your **Primary Name** click the **"Set As Primary ENS Name"** button and follow the steps.

## How to set Avatar

To set your avatar you can go to the [ENS Manager](https://app.ens.domains/) and select the name you would like to set an **Avatar** for.

Now you are on the page simply hit **ADD/EDIT RECORD** and scroll down to the **avatar** field.

![](https://i.imgur.com/fLFw8Ey.png)

### The Avatar Field

The Avatar Field can be filled with a variety of different types of text. In the example below I am uploading an **IPFS** link (using **ipfs://**), however you could also use **Arweave**, a link to an NFT (using [CAIP-29](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-29.md)), base64 image, or any regular **HTTP(S)** url will do.

![](https://i.imgur.com/Scbp1AW.png)

### Question

<Quiz id={"r3wki"} />


<Quiz id={"2mtcw"} />


</Section>

<Section name="4. Integrate ENS" description="Integrate ENS into your Project">

## Resolving ENS names for Users

With the help of your favourite library such as [Ethers](https://docs.ethers.io/v5/api/providers/provider/#Provider--ens-methods), [Wagmi](https://wagmi.sh/docs/hooks/useEnsName), [ENS.js](https://www.npmjs.com/package/@ensdomains/ensjs), [Web3.js](https://web3js.readthedocs.io/en/v1.2.0/web3-eth-ens.html), [Web3j](https://github.com/web3j/web3j), [KEthereum](https://github.com/komputing/KEthereum/tree/master/ens), [web3.py](https://web3py.readthedocs.io/en/stable/ens_overview.html), [go-ens](https://github.com/wealdtech/go-ens), and many more.

![User Profile & Lookup example](https://i.imgur.com/9G8yvJ2.png)

It's that easy! Now your dApp is ready to show everyone's names everywhere! And don't forget to fallback to addresses when the user doesn't have a name.

#### React Example

Below is an example snippet of what this would look like using [wagmi](https://wagmi.sh/docs/hooks/useEnsName).

```tsx
import { useAccount, useEnsAvatar, useEnsName } from 'wagmi';
const shortenAddress = (address) => `${address.substr(0, 5)}...${address.substr(-4)}`;
export const UserProfile = () => {
    const { address } = useAccount();
    const { data: name, isSuccess: isNameSuccess } = useEnsName({ address });
    const { data: avatar, isSuccess: isAvatarSuccess } = useEnsAvatar({
        addressOrName: address,
    });
    return (
        <div>
            <div>
                {isAvatarSuccess && avatar ? (
                    <img src={avatar} />
                ) : (
                    <img src="" />
                )}
            </div>
            <div>
                {isNameSuccess && name ? (
                    <div>
                        <span>{name}</span>
                        <span>{shortenAddress(address)}</span>
                    </div>
                ) : (
                    <div>{address}</div>
                )}
            </div>
        </div>
    );
};
```

## Retrieving Address from Name

You may however want users to be able to search for each other, mention one another, or even challenge each other to a game of tic tac to. Now should this be the case there is the **resolveName** functionality that allows you to enter any valid ENS name and get back the address.

![Address Resolution & Lookup Example](https://i.imgur.com/yaMUwih.png)

## Question

<Quiz id={"qppyi"} />


</Section>

<Section name="Dev Resources" description="Developer Resources">

## ENS Developer Resources

### [Quickstart](https://docs.ens.domains/dapp-developer-guide/ens-enabling-your-dapp)

Everything you need to know to get started implementing ENS in your dApp.

### [Docs](https://docs.ens.domains)

Your go-to location for protocol information and examples.

### [Metadata Service](https://metadata.ens.domains/docs)

Metadata service that allows for fetching data .

### [Libraries](https://docs.ens.domains/dapp-developer-guide/ens-libraries)
- [Ethers](https://docs.ethers.io/v5/api/providers/provider/#Provider--ens-methods)
- [Wagmi](https://wagmi.sh/docs/hooks/useEnsName)
- [ENS.js](https://www.npmjs.com/package/@ensdomains/ensjs)
- [Web3.js](https://web3js.readthedocs.io/en/v1.2.0/web3-eth-ens.html)
- [Web3j](https://github.com/web3j/web3j)
- [KEthereum](https://github.com/komputing/KEthereum/tree/master/ens)
- [web3.py](https://web3py.readthedocs.io/en/stable/ens_overview.html)
- [go-ens](https://github.com/wealdtech/go-ens)

### [Mirror](https://ens.mirror.xyz/)

For the latest news and updates about the ENS Ecosystem.

### [Medium](https://medium.com/the-ethereum-name-service)

For our archive of Articles.

![More Coming Soon](https://i.imgur.com/TaB3p5o.png)

</Section>

Learn more about the Ethereum Name Service

Intro to Ethereum Name Service

Luc van Kampen

<Section name="1. Introduction" description="Introduction to superfluid" hidden="false">

## What is Superfluid

The way we usually move tokens on-chain is through basic ERC20 transfers. I transfer you 100 DAI and my balance goes down 100 and yours goes up 100.

Superfluid's smart contract framework takes this a step forward by introducing a new token standard, called the Super Token. The Super Token extends the basic ERC20 transfer functionality to include Super Agreements. These Super Agreements give us new and more powerful ways to move tokens on-chain!

The most popular Super Agreement lets us *stream* Super Tokens - it's called the Constant Flow Agreement (CFA). We also provide another Super Agreement called the Instant Distribution Agreement (IDA) which lets you do scalable one-to-many distributions. This guide is going to focus on money streaming with the CFA.

## Money Streaming In Solidity

Just like how a smart contract can transfer its own ERC20 tokens, you can set up a smart contract to stream its own Super Tokens. This guide will quickly walk you through how to set up a smart contract to stream Super Tokens!

<Quiz id={"d24u2"} />


</Section>

<Section name="2. Super Tokens" description="Understanding Super Tokens">

## What are Super Tokens?

The Super Token is our extension of the ERC20 token standard that plugs into the Superfluid Protocol to include Super Agreement abilities. These Super Agreements allow Super Tokens to be transferred in powerful ways such as in streams or instant distributions. Keep in mind that Super Tokens can do everything that a traditional ERC20 token can PLUS new modes of value transfer enabled by Superfluid (i.e., money streaming).

Super Tokens come in two forms: wrapper and custom. Wrapper Super Tokens are the most common, so let's discuss them. If you'd like to understand the rarer Custom Super Token, head over [here](https://docs.superfluid.finance/superfluid/protocol-overview/in-depth-overview/super-tokens#custom).

## Wrapper Super Tokens

A wrapper Super Token is an existing ERC20 token that's been "wrapped" into a Super Token to gain Super Agreement functionality.

### Wrapping and Unwrapping

When getting Wrapper Super Tokens, you first use the `upgrade(uint256 amount)` function on the Wrapper Super Token contract. This takes the desired amount of the Wrapper Super Token's underlying ERC20 token from your wallet and mints you an equal amount of Wrapper Super Tokens. Basically, you gave up the plain underlying ERC20 token and got the "Super Token version" of it. 

Say you want to go back from Wrapper Super Tokens to the underlying ERC20 token. You would simply unwrap the desired amount with the `downgrade(uint256 amount)` function and the opposite happens; the desired amount of your Super Tokens are burned and an equal amount of the underlying ERC20 token are returned to you.

![img](https://raw.githubusercontent.com/sunnyjaycer/sf-ethglobal-guides/master/Money%20Streaming%20In%20Solidity/assets/wrapper.png)



The naming convention for Wrapper Super Tokens is the original token symbol + "x" (Ex: USDC ➡ USDCx).

## Question

<Quiz id={"74hdd"} />


<Quiz id={"eio7h"} />


</Section>

<Section name="3. Super Agreements" description="Understanding Super Agreements">

## Super Agreements

Super Agreements are the additional value transfer functionality that Super Tokens have. When an account engages in a Super Agreement with another account, it agrees to have its Super Token balance modified according to the rules of the agreement and chosen parameters. Currently, there are two available Super Agreements: the Constant Flow Agreement (CFA) and the Instant Distribution Agreement (IDA).

The CFA is what lets you stream money, so let's talk about it!

## Calculating Balances with the CFA

Let's say your driving a car that's going 1 km per minute. If 13 minutes pass, then you would have travelled 1 km/min. * 13 min. = **13 km**.

Now similarly, if you are streaming at a rate of 1 DAIx per second and 13 seconds pass, then you would have moved 1 DAIx/sec. * 13 sec. = **13 DAI**.

With each passing second, the amount of DAIx you've moved changes to 14, to 15, and so on.

So that's all the CFA is doing; adding a *rate* component to balance calculation.

To put this mathematically, you can call the amount of DAIx you originally had as your "static balance" and then the amount you've streamed out as the "real-time balance" delta and by combining the two, you get your actual balance!

```
POV: You are streaming to someone at a rate of 1 DAIx per second and 13 seconds have passed since you started the stream.
Static Balance    = 100 DAIx
Real-Time Balance = -13 DAIx = -1 DAIx/sec * 13 seconds passed
                    --------
Actual Balance    =  87 DAIx = 100 + -13
```

Last thing to note, is that the real-time balance is accounted in the CFA's own contract. When you go to view your balance on the `balanceOf` function on the Super Token, we've overriden it to take your basic static balance and then add the real-time balance.

![rtb](https://raw.githubusercontent.com/sunnyjaycer/sf-ethglobal-guides/master/Money%20Streaming%20In%20Solidity/assets/rtb.png)

💡 You can see several visual examples of this process in [this](https://docs.superfluid.finance/superfluid/protocol-overview/in-depth-overview/super-agreements/constant-flow-agreement-cfa) section of our documentation.


<Quiz id={"4fjhk"} />


<Quiz id={"zetit"} />


</Section>

<Section name="Dev Resources" description="Developer Resources">

## Superfluid Developer Resources

### [Docs](https://docs.superfluid.finance)

Your go-to location for in-depth protocol information and examples.

### [Super Token Faucet](https://docs.superfluid.finance/superfluid/developers/interactive-tutorials/super-token-faucet)

Use this to get DAIx tokens on Goerli or Mumbai

### [Console](https://console.superfluid.finance)

The Etherscan of Superfluid. Useful for checking out all the money streaming activity of different accounts, drafting subgraph queries, and more.

### [Dashboard](https://app.superfluid.finance)

A no-code tool where you can connect your wallet to start streams and view your money streaming activity.

### [Solidity Library](https://docs.superfluid.finance/superfluid/developers/solidity-examples/solidity-libraries/cfav1-library)

If you’re writing smart contracts, you’ll want to include the Superfluid Ethereum contracts package, and make use of the CFA library for working with streams in your contracts.

</Section>

<Section name="Money Streaming With Solidity" description="Set up a smart contract that can stream its own Super Tokens">

# Streaming Money in Solidity

So you've seen how easy it is to stream straight from your EOA account (your plain personal wallet) using the SDK Core. Now, say you want to create a smart contract that will be able to stream tokens on its own. 

You've probably seen a contract transfer ERC20 tokens on its own with the transfer function 👇

```solidity
IERC20(tokenAddress).transfer(receiverAddress, amountToTransfer);
```

Well, here's the equivalent for a contract streaming Super Tokens on its own 👇 It's very similar!

```solidity
ISuperToken(superTokenAddress).createFlow(receiverAddress, perSecondflowRate);
```

However, there is some set up needed before hand in order for your contract to begin streaming money like that - read on!

# Basic Example - FlowSender Contract

To illustrate how a contract can send money in streams, we'll use a simple contract which we'll call the FlowSender. Basically, FlowSender is going to fund itself with fDAIx and be able to create, update, and delete streams to addresses of our choosing.

Click on this [**REMIX IDE**](https://remix.ethereum.org/?#gist=99c70cb197e84c4e61dfb1eb2e6350a6&version=soljson-v0.8.14+commit.80d49f37.js&lang=en&optimize=false&runs=200&evmVersion=null) link to find the FlowSender contract. Note that the IDE will open all the environment folders at once; you can close them such that the file directory looks like this:

![needed-directory](https://raw.githubusercontent.com/sunnyjaycer/sf-ethglobal-guides/master/Money%20Streaming%20In%20Solidity/assets/needed-directory.png)

Let's get walk through some of the code real quick!

## 1. Superfluid Set Up

First, we make these imports which are needed for setting up the contract to interact with the Superfluid Protocol:

```js
import {IFakeDAI} from "./IFakeDAI.sol";
import { ISuperfluid, ISuperToken } from "@superfluid-finance/ethereum-contracts/contracts/interfaces/superfluid/ISuperfluid.sol";
import { SuperTokenV1Library } from "@superfluid-finance/ethereum-contracts/contracts/apps/SuperTokenV1Library.sol";
```

Then, we set up the SuperTokenV1Library Library with this line of code in the FlowSender contract:

```solidity
using SuperTokenV1Library for ISuperToken;
```

All that did was set us up to be able to call Superfluid functions directly on ISuperToken objects in the FlowSender contract. To learn more about these instantiations, feel free to reference [here](https://docs.superfluid.finance/superfluid/developers/solidity-examples/solidity-libraries/cfav1-library#initializing-the-library) in our docs.

## 2. Getting the contract some Super Tokens

This is done by calling `gainDaiX`. Basically, this function mints the FlowSender contract 10,000 fDAI and wraps it into fDAIx.

fDAIx is a [wrapper Super Token](https://docs.superfluid.finance/superfluid/protocol-overview/in-depth-overview/super-tokens#wrapper). Its underlying token is fake DAI (fDAI).

fDAI has a public mint function which lets anyone mint their own fDAI whenever they want. Makes life easy for this tutorial!

```solidity
function gainDaiX() external {
    // Get address of fDAI by getting underlying token address from DAIx token
    IFakeDAI fdai = IFakeDAI( daix.getUnderlyingToken() );

    
    // Mint 10,000 fDAI
    fdai.mint(address(this), 10000e18);
    // Approve fDAIx contract to spend fDAI
    fdai.approve(address(daix), 20000e18);
    // Wrap the fDAI into fDAIx
    daix.upgrade(10000e18);
}
```

## 3. Creating a stream!

Here's how we get the contract to send a stream of fDAIx from itself to an address of choice with `createStream`.

```solidity
function createStream(int96 flowRate, address receiver) external {
    // Create stream
    daix.createFlow(receiver, flowRate);
}
```

## 4. Compile and Deploy the FlowSender

**Head to the Compile tab to compile the FlowSender contract**

![compile](https://raw.githubusercontent.com/sunnyjaycer/sf-ethglobal-guides/master/Money%20Streaming%20In%20Solidity/assets/compile.png)

**Make sure your Metamask is connected to Goerli Testnet and switch the Environment to `Injected Provider - Metamask`**

![compile](https://raw.githubusercontent.com/sunnyjaycer/sf-ethglobal-guides/master/Money%20Streaming%20In%20Solidity/assets/environment.png)

**Head to the Deploy tab and deploy the contract with the following parameters:**

`_DAIX` - 0xF2d68898557cCb2Cf4C10c3Ef2B034b2a69DAD00

The address of fDAIx (the wrapper Super Token for a free mintable fDAI token) on Mumbai Testnet. You can other addresses in our docs [here](https://docs.superfluid.finance/superfluid/developers/networks#test-networks).

![deploy](https://raw.githubusercontent.com/sunnyjaycer/sf-ethglobal-guides/master/Money%20Streaming%20In%20Solidity/assets/deploy.png)

## 5. Interact with FlowSender to load it with fDAIx

Call the `gainDaiX` function and the contract will gain 10,000 fDAIx.

![gainDAIx](https://raw.githubusercontent.com/sunnyjaycer/sf-ethglobal-guides/master/Money%20Streaming%20In%20Solidity/assets/gainDaiX.png)

## 6. Interact with FlowSender to send someone a stream of fDAIx

Using the `createStream` function, specify a receiver address and pick a by-the-second flow rate.

Note that this flow rate is always in wei per second. For instance, if you wanted the contract to stream 10 fDAIx/hour:

```
10 fDAIx/hour
= 10 * (10**18) fDAIx / hour
= 10 * (10**18) fDAIx / ( 60 seconds * 60 minutes )
= 2777777800000000 <- the flow rate number you would provide
```

Run the createStream as shown below:

![send stream](https://raw.githubusercontent.com/sunnyjaycer/sf-ethglobal-guides/master/Money%20Streaming%20In%20Solidity/assets/createStream.png)

## 7. View the stream in action.

Once the transaction confirms, head to the [Superfluid Console](https://console.superfluid.finance) and paste the address in the search bar at the top. Click in and see the balance of the FlowSender contract changing in real-time!

Congrats, you just started a money stream with Solidity! That wasn't so hard, was it?

For reference, check out this [FlowSender contract](https://console.superfluid.finance/goerli/accounts/0x8766e5755917D849E907cF5952C4aE8eB8e3C050?tab=streams) we already deployed ourselves and started a stream with.

</Section>

<Section name="Conclusion" description="Conclusion">

## Next Steps

Congrats, dev! You've gotten some Superfluid smart contract developement under your belt 💪

![meme](https://raw.githubusercontent.com/sunnyjaycer/sf-ethglobal-guides/master/Money%20Streaming%20In%20Solidity/assets/zero-to-money-streaming.png)

Check out these other guides to move on to more advanced concepts 👇

🚧 (More guides coming soon) 🚧

## Links

**[Discord](https://discord.gg/XsK7nahanQ)**

**[Twitter](https://twitter.com/intent/follow?screen_name=Superfluid_HQ)**
**[GitHub](https://github.com/superfluid-finance)**

**[Superfluid Wave Pool](https://docs.superfluid.finance/superfluid/resources/contribute/superfluid-wave-pool)**


</Section>

Learn the internals of how Superfluid Protocol works

Money Streaming with Solidity 101

Superfluid

Joel Jesudason

Superfluid Finance

<Section name="1. Introduction" description="Introduction to wallet" hidden="false">

# Getting setup with MetaMask
## What is a Wallet

In the world of cryptocurrency, a wallet refers to an application or device you can use to interact with a blockchain.

Your wallet functions as a lock-box that secures your access to the blockchain.

When your wallet is connected to a blockchain, you can make purchases, transfer digital assets, interact with applications, and more!


</Section>

<Section name="2. Wallet Recovery" description="Understanding recovery mechanisms">

## What is a recovery phrase

When you set up a new wallet, the software generates a unique recovery phrase that is specific to that wallet account.

Also sometimes called a seed phrase or secret recovery phrase, your recovery phrase can be used to access your wallet and crypto assets if:

- Your wallet app or hardware fails unexpectedly or gets damaged.
- You are unable to access it due to misplacement or theft.
- You want to access your wallet account through the wallet app on a different computer or device.

Most recovery phrases are a list of 12 to 24 words that represent a unique piece of data. That data is used to generate the public key and private key for your wallet.



</Section>

<Section name="3. Securing your keys" description="Introduction to public and private key cryptography">

## Public Key

You just learned how your recovery phrase relates to a public key and private key.

Note that a wallet can contain multiple accounts, and each account has a unique pair of public and private keys.

Think of a public key like your home address. It is public, anyone can see it, and it identifies the location to use to send crypto assets to you.


## Private Key

If your public key is like your home address, then your private key is like your house key.

It's called private because only you should have access to it.

The private key unlocks access to your wallet and your crypto assets, allowing you to send them to other wallet addresses.


## Wallet Security

**ALWAYS** do this to protect your recovery phrase:

✅ write it down

✅ use a durable material

✅ store it in a safe place

**NEVER** do this to protect your recovery phrase:

🛑 save your recovery in an online drive

🛑 screenshot your private key

🛑 reveal your recovery key to anyone

</Section>

<Section name="4. Installing Metamask" description="Getting setup with metamask">

## Metamask 

There are several non-custodial hot wallets available today. We will explore the popular MetaMask Wallet for the remainder of this lesson since:

1. It is likely to be compatible with most DeFi apps.
1. It has a browser extension for Chrome, Brave, Edge, and Firefox internet browsers.
1. It is also available as a mobile app for Android and iOS users.

### Installing up Metamask 

For convenience and ease of access throughout this lesson, you will need a MetaMask wallet. Next we will demonstrate how to set up a MetaMask wallet.

Download the browser extension from the official website: [https://metamask.io/download](https://metamask.io/download)

</Section>

<Section name="5. Using Metamask" description="Test out your web3 wallet">

## Testing everything worked

<Challenge id="q4cnq" />

</Section>



Guides

Interested in contributing? Ping us at guides@ethglobal.com