*By [Sara Reynolds](https://twitter.com/saraareynolds) and [Zach Pomerantz](https://github.com/zzmp)*

A safe swapping experience must balance security and speed. Token approvals are a great example of this tradeoff. Self-custody lets users specify who has permission to move funds from their wallets, but sending a token approval transaction takes time and costs gas. To improve this process and lower the number of clicks to swap, we released the [Permit2](https://github.com/Uniswap/permit2/) smart contract [last year](https://blog.uniswap.org/permit2-and-universal-router).

Instead of signing a token approval for each new smart contract, Permit2 allows token approvals to be shared and managed across different contracts, creating a more unified, cost-efficient, and safer UX. Permit2 is already improving Uniswap's product UX, but it was designed for anyone to use.

This guide will show you how. In it, we will:

- Set up a sample demo contract to call the `AllowanceTransfer` function
- Use Permit2 to permit and transfer funds
- Construct Permit2 signatures on a frontend using the Permit2 SDK

![image2](//images.ctfassets.net/oc3ca6rftwdu/WEj84srnjtuCZaBvyw9hm/c5db1ef9f5a1c86018d972542805404a/image2.png)

# What can Permit2 do
Permit2 is a token approval contract that iterates on existing token approval mechanisms by introducing signature-based approvals and transfers for any ERC20 token, regardless of [EIP-2612](https://eips.ethereum.org/EIPS/eip-2612) support.

For each token, users have to submit a one-time traditional approval that sets Permit2 as an approved spender. Contracts that integrate with Permit2 can "borrow" the spender status for any token a user has approved on the canonical [Permit2 contract](https://etherscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3). Any integrated contract can temporarily become a spender with a signed offchain Permit2 message. This effectively "shares" the one-time traditional token approval and skips the individual approval transaction for every protocol that supports Permit2 -- until the Permit2 message expires. It's a major UX upgrade with additional safety bumpers like expiring approvals and the lockdown [feature](https://github.com/Uniswap/permit2/#features).

![image1](//images.ctfassets.net/oc3ca6rftwdu/4SCDyYzjU6dzde1vaVxm5i/fb9205624a14ba86f21809f244ee210f/image1.jpg)

Permit2's design gives us a few helpful features. The full list of features can be found in our [readme](https://github.com/Uniswap/permit2/tree/main), but notably:

1. **Permits for any token**. Applications can have a single transaction flow by sending a signature along with the transaction data for any token, including those not supporting a native `permit` method.
2. **Expiring approvals**. Approvals can be time-bound, removing security concerns around hanging approvals on a wallet's entire token balance. Revoking approvals do not necessarily have to be a new transaction.
3. **Signature-based transfers**. Users can bypass setting allowances entirely by releasing tokens to a permissioned spender through a one-time signature.
4. **Batch approvals and transfers**. Users can set approvals on multiple tokens or execute multiple transfers with one transaction.
5. **Batch revoking allowances**. Remove allowances on any number of tokens and spenders in one transaction.

Permit2 benefits greatly from network effects. As more teams integrate with Permit2, we'll begin to see network effects. So how do we do it?

# How to accept Permit2 signatures in your contract
For app developers, Permit2 is an incredibly useful way to create a simpler, less expensive, and safer UX that your users will appreciate. In this guide, we’ll write a contract that integrates with Permit2 to make use of this new meta-transaction approval system.

### AllowanceTransfer
The `AllowanceTransfer` [contract](https://github.com/Uniswap/permit2/blob/main/src/AllowanceTransfer.sol) shares and manages approvals with other spenders using a time-bounded expiry. It's functionally similar to traditional token approvals, handling allowances, transfers, and approval expiries. This style of approval works best if your application needs to access and transfer tokens frequently. With allowance transfer style approvals, an approved amount and expiry are set and saved in storage for each permitted spender. This allows the spender to transfer tokens as needed up until the spending limit is reached or until the approval expires.

### SignatureTransfer
The `SignatureTransfer` [contract](https://github.com/Uniswap/permit2/blob/main/src/SignatureTransfer.sol) introduces one-time permits for token transfers. Spenders are permitted to transfer tokens, but only in the same transaction where the signature is spent. To transfer funds again, you would need to request this signature again. The signature transfer method is great for applications that infrequently need tokens from users and want to ensure tighter restrictions on approvals. Persistent limits and expiries are not stored and never leave "hanging approvals." SignatureTransfer also lets you do a more advanced integration with Permit2 through permitWitnessTransferFrom, which we plan to detail in a later blog post.

Depending on the type of approval you need for your application, your contract will need to call one of these functions --- though these are not the only callable functions in Permit2:

- [permit](https://github.com/Uniswap/permit2/blob/main/src/AllowanceTransfer.sol#LL33C15-L33C15)
- [permitTransferFrom](https://github.com/Uniswap/permit2/blob/main/src/SignatureTransfer.sol#L22)
- [permitWitnessTransferFrom](https://github.com/Uniswap/permit2/blob/main/src/SignatureTransfer.sol#L32)

## Setting up your contract
In this example, we'll write a contract to use the allowance transfer style approval on Permit2. We'll assume that a user has already set a token approval to let Permit2 be a spender.

Since the `permit` entrypoint we want lives in the `AllowanceTransfer` contract, we'll first create our `Demo` contract to use the `IAllowanceTransfer` [interface](https://github.com/Uniswap/permit2/blob/main/src/interfaces/IAllowanceTransfer.sol) exposed in Permit2. In your constructor, you can pass the [Permit2 address](https://etherscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) and save it as an immutable value. Permit2 is deployed to the [same address](https://etherscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) across mainnet, Ethereum, Optimism, Arbitrum, Polygon, and Celo.

```solidity
import {IAllowanceTransfer} from "Permit2/src/interfaces/IAllowanceTransfer.sol";

   contract Demo {
   IAllowanceTransfer public immutable permit2;

   constructor(address _permit2) {
       permit2 = IAllowanceTransfer(_permit2);
   }
}
```

## Calling permit
Now that you've initialized with the canonical Permit2 contract, your contract can set an approval by calling `permit`. This `permit` [function](https://github.com/Uniswap/permit2/blob/main/src/AllowanceTransfer.sol#L33) has a few parameters.

```solidity
function permit(address owner, IAllowanceTransfer.PermitSingle memory permitSingle, bytes calldata signature) external
```

To call `permit` we need the owner's address, their signature, and the `PermitSingle` information. [PermitSingle](https://github.com/Uniswap/permit2/blob/main/src/interfaces/IAllowanceTransfer.sol#L57) is a struct that holds the `permit` information that has been signed by the user. Before Permit2 can let our demo contract be a spender, it has to verify the user with their signature and `PermitSingle` data.

To call `permit`, we can create a `permitThroughPermit2` function that will pass these parameters through. Later on, we will see how the application frontend requests and constructs the `PermitSingle`.

```solidity
   function permitThroughPermit2(PermitSingle calldata permitSingle, bytes calldata signature) public {
       permit2.permit(msg.sender, permitSingle, signature);
   }
```

By passing `msg.sender` for the `owner` variable, we’re requiring that the caller of the function is also the one who signed the `PermitSingle` information. That’s one less parameter we need to collect for `permitThroughPermit2`.

Before we allow a contract to transfer a user’s tokens using the Permit2 approvals, we need to check that our demo contract is set to be spender. This checks if a user has called this function. If so, then we know we have spending permissions on our contract. We can add a custom error, `InvalidSpender`, and write a check that enforces that signatures passed through `permitThroughtPermit2` construct our demo contract address as the spender.

Our function now looks something like this:

```solidity
   function permitThroughPermit2(PermitSingle calldata permitSingle, bytes calldata signature) public {
       if (permitSingle.spender != address(this)) revert InvalidSpender();
       permit2.permit(msg.sender, permitSingle, signature);
   }
```

## Transferring tokens
Permit2 uses a persistent mapping based design. This design stores token approvals information set by the user like the spender, amount, and expiration. Because this information is stored, this approval will last until the `permitSingle.permitDetails.expiration`. Until that timestamp, our demo contract can transfer the funds up to the allowance. Let’s write another function to send funds to this contract by calling the `transferFrom` [function](https://github.com/Uniswap/permit2/blob/main/src/AllowanceTransfer.sol#L59) in Permit2.

```solidity
function transferToMe(address token, uint160 amount) public {
       permit2.transferFrom(msg.sender, address(this), amount, token);
	// ...Do cool stuff ...
   }
```

By passing in `msg.sender`, we ensure that only the approved user can trigger this function to send some amount of a desired token from the sender to the demo contract. If this was instead a parameter that we pass in, then anyone could trigger the function pulling the funds from the user. After calling this function, our demo contract now has tokens that they can swap, deposit into a lending protocol, or do anything else with.

You may have noticed that `permit` and `transferFrom` are two separate entry points in our contract. If left like this, it would mean that the user has to initiate two transactions to get their tokens with any contract that is integrated with Permit2. We can instead combine the `permit` and `transferFrom` calls into one entrypoint:

```solidity
   function permitAndTransferToMe(IAllowanceTransfer.PermitSingle calldata permitSingle, bytes calldata signature, uint160 amount) public {

       if (permitSingle.spender != address(this)) revert InvalidSpender();
       permit2.permit(msg.sender, permitSingle, signature);
       permit2.transferFrom(msg.sender, address(this), amount, permitSingle.details.token);
       //...Do cooler stuff ...
   }
```

If our demo contract is approved through a `permit` for longer than a single transaction, we do not need to pass in a signature each time to call `transferFrom` and pull tokens.

We used `AllowanceTransfer` as our entrypoint. `SignatureAllowance` lets us do the same thing, but the approval would not last beyond the single transaction. We could use the  `permitTransferFrom` and `permitWitnessTransferFrom` functions to ensure even tighter restrictions at the expense of greater transaction costs.

# How to construct Permit2 signatures on the frontend
To integrate Permit2 on the frontend we will be using the [Permit2 SDK](https://github.com/Uniswap/permit2-sdk). We'll be calling into our demo contract, using `permitAndTransferToMe`.

First, in order to get the signature for a `PermitSingle`, you'll need the next valid nonce, which you can get using the SDK.

```javascript
import { AllowanceProvider, PERMIT2_ADDRESS } from '@uniswap/Permit2-sdk'

const allowanceProvider = new AllowanceProvider(ethersProvider, PERMIT2_ADDRESS)
const { amount: permitAmount, expiration, nonce } = allowanceProvider.getAllowanceData(user, token, ROUTER_ADDRESS);

// You may also check amount/expiration here to see if you are already permitted -
// you may not need to generate a new signature.
```

Once you have that, you can construct the `PermitSingle` object which we’ll need to pass as our first parameter. This object is defined by the SDK as a typed interface to ensure it matches the contract’s struct. To construct it, we’ll need a few things:
- The address of the token
- The maximum amount of the token that will be permitted to be transferred
- The deadline after which the `permit` will no longer be valid. At Uniswap Labs, we use 30 days.
- The address of the spender that will be permitted to transfer funds on behalf of the user

These are the same input variables that our demo contract sends to the Permit2 contract.

```javascript
import { MaxAllowanceTransferAmount, PermitSingle } from '@uniswap/Permit2-sdk'

const PERMIT_EXPIRATION = ms`30d`
const PERMIT_SIG_EXPIRATION = ms`30m`

/**
* Converts an expiration (in milliseconds) to a deadline (in seconds) suitable for the EVM.
* Permit2 expresses expirations as deadlines, but JavaScript usually uses milliseconds,
* so this is provided as a convenience function.
*/
function toDeadline(expiration: number): number {
return Math.floor((Date.now() + expiration) / 1000)
}

const permitSingle: PermitSingle = {
details: {
token: tokenAddress,
amount: MaxAllowanceTransferAmount,
// You may set your own deadline - we use 30 days.
expiration: toDeadline(/* 30 days= */ 1000 * 60 * 60 * 24 * 30),
nonce,
},
spender: spenderAddress,
// You may set your own deadline - we use 30 minutes.
sigDeadline: toDeadline(/* 30 minutes= */ 1000 * 60 * 60 * 30),
}
```

Now that you have your `PermitSingle` object you can pass it to the SDK to get back [typed data](https://eips.ethereum.org/EIPS/eip-712#definition-of-typed-structured-data-%F0%9D%95%8A) for the user to sign, using `AllowanceTransfer.getPermitData`. This takes the `PermitSingle`, the address off the Permit2 contract on the chain, and the chain ID and returns typed data that you can pass directly to a library like `ethers` to request the user's signature.

```javascript
import { AllowanceTransfer, PERMIT2_ADDRESS } from '@uniswap/Permit2-sdk'

const { domain, types, values } = AllowanceTransfer.getPermitData(permitSingle, PERMIT2_ADDRESS, chainId)

// We use an ethers signer to sign this data:
const signature = await provider.getSigner().signTypedData(domain, types, value)

// This assumes ethers@6. Our web app uses ethers@5, and we've run into a few cross-wallet compatibility issues, so we actually sign using a helper method: https://github.com/Uniswap/conedison/blob/6fdf4baf13a799ca6d37f6d3222f9194e1750007/src/provider/signing.ts#L32.
```

You should get a `signature` back from `ethers`, which you can pass onto other methods which use it. For another example, check out how we [pass ours to the Universal Router](https://github.com/Uniswap/interface/blob/ec547ab100f793d127246186d5fd60786758a862/src/hooks/useUniversalRouter.ts#L63-L67).

Finally, we'll instantiate our contract using `ethers`, and use it to call `permitAndTransferToMe`.

```javascript
import { Contract } from ‘ethers’

// We only need to provide the ABI that we will use.
const demoAbi = [
‘function permitAndTransferToMe(PermitSingle calldata permitSingle, bytes calldata signature, uint160 amount)’,
]
const demoContract = new Contract(demoContractAddress, demoAbi, provider.getSigner())

await demoContract.permitAndTransferToMe(permitSingle, signature, amount)
```

# Conclusion
You made it to the end! While it may initially seem daunting, we hope this blog makes it easier. And remember to check out the [Permit2 code](https://github.com/Uniswap/permit2), our [SDK](https://github.com/uniswap/permit2-sdk), and [docs](https://docs.uniswap.org/contracts/permit2/overview) for more.

This guide will show you how to call the AllowanceTransfer function using Permit2 and construct a signature on a front end using the Permit2 SDK.

How to Integrate with Permit2

Part 1 focused on Q notation, ticks, and exchange rates. Part 2 of this math series focuses on virtual liquidity, calculating LP positions, and uncollected fees.

A Primer on Uniswap v3 Math Part 2: Stay Awake by Reading it Aloud

_By [Zach Pomerantz](https://github.com/zzmp)_

The Unix philosophy, popularized in the 1980s, emphasizes breaking down complex software systems into smaller, interchangeable pieces of code that developers can easily reuse. While it may seem like conventional practice today, it was revolutionary when developers were far more focused on monolithic systems. This approach became popular among developers, allowing them to ship better code faster and get new technology into the hands of users without delay.

Web3 applications, which generally exist in a public and open-source ecosystem, have embraced this philosophy to develop software. By sharing useful code across developers and building on emerging standards, Web3 developers create increasingly sophisticated software at a rapid pace. I see this directly with how quickly we can ship code at Uniswap Labs.

In drawing from the Unix philosophy, Web3 developers have been able to work in real time with developing technology to solve challenging problems. This approach has revolutionized how software is built and is a testament to the power of collaboration and shared standards.

# Unix Philosophy and Web Development

The Unix philosophy emerged with the development of the Unix operating system. Later summarized by [Peter H. Salus](https://en.wikipedia.org/wiki/Peter_H._Salus), the Unix philosophy was distilled to:
1. Write programs that do one thing and do it well. 
2. Write programs to work together. 
3. Write programs to handle text streams, because that is a universal interface. [^1]

[^1]: I propose modernizing this to “Write programs to handle domain-specific languages.”

These three brief principles result in simpler code that can be easily combined to perform more complex operations. For example, copying and pasting text from one file into another:

```
cat file1.txt | pbcopy
pbpaste > file2.txt
```

 Each CLI command is a tool whose combined inputs and outputs can be piped together for more useful actions. String together enough commands, you can build scripts or create new and reusable tools to perform more sophisticated tasks, elevating the playing field for all developers. From Unix came the POSIX specification, a standard library to maintain compatibility between operating systems. It was a big step that allowed us to focus on our applications without worrying about tasks delegated to these foundational tools, like file system access and permissions.

Fast forward a few decades, and we see the Unix philosophy break new limits. Node.js and its package manager, npm, gives JavaScript developers better tools for more sophisticated software. Instead of coding smaller tasks, npm provides foundational libraries like [left-pad](https://www.npmjs.com/package/left-pad). These allow programs to delegate smaller tasks and keep their application code focused.

When something gets too big, it becomes harder to think through. Design doc reviews often boil down to paring a project to its constituent parts, scoping them, and then building it back up. By treating each constituent as a black box, teams only need to reason about how to “do one thing and do it well”, and not the myriad of requirements necessary for the final product. In this way, every developer is standing on the shoulders of giants.

# Unix Philosophy and Web3
As I learned more about web development and Web3 applications, I realized that this type of development eventually consolidates around open standards. Blockchain code is publicly callable, and developers use this to their advantage by rallying around standards that let them focus on the applications they want to build.

The Request for Comments-style [Ethereum Improvement Proposal](https://eips.ethereum.org/) (EIP) process encourages discussion around new standards and facilitates broader adoption with new foundational libraries. In 2018, Web3 applications did not have a standardized way to connect to user wallets. Each wallet API implementation was slightly different. Writing your own Web3 application meant accounting for how a user's wallet might connect. [EIP-1193](https://eips.ethereum.org/EIPS/eip-1193) solved that. The proposed Ethereum Provider JavaScript API introduced basic functionality like connection and request logic between apps and wallets. With a standard API to follow, app developers could spend more time on core functionality and less time accommodating conflicting connection methods.

As with Node.js and npm, each new standard library gives developers a new tool to work more precisely by using them to abstract important logic unrelated to their core application and create more sophisticated software. String together enough of these libraries and developers can unlock powerful new tools.

We built one of these new tools with [Permit2](https://uniswap.org/blog/permit2-and-universal-router). When users interact with a Web3 application, they must give the application permission to send tokens from their wallet. Permit2 allows these approvals to be shared across multiple applications instead of each application requiring its own approval.

But Permit2 was only possible because we built on already-existing standards like ERC-20, ERC-1155, and ERC-712. [ERC-20](https://eips.ethereum.org/EIPS/eip-20) defined the token standard. [ERC-1155](https://eips.ethereum.org/EIPS/eip-1155) extended the token standard to "approve" spending by another contract. [ERC-712](https://eips.ethereum.org/EIPS/eip-712) extends EIP-1193 with a way for wallets to sign data to verify user permission.

Permit2 extends the ecosystem further by taking a token's approval and a wallet's signatures to prove that a user has permitted it to spend a token across other applications resulting in a more unified, cost-efficient, and safer user experience. In turn, we wanted developers to use Permit2 to manage token access control list functions, so we made it easy for developers to integrate with it.

***

Developers can steadily enhance their capabilities by leveraging existing EIPs and foundational libraries, codifying and abstracting these patterns into even better libraries. Whenever this pattern repeats itself, it elevates the baseline of what is possible, making Web3 an exciting space to work in.

Web3 intrinsically operates in public. We don't just build applications; we create the building blocks with tools and libraries that make them easy to use. I'm excited to participate in this ecosystem by building at Uniswap Labs. If you think you'd like, consider [joining us](https://boards.greenhouse.io/uniswaplabs)!

Uniswap Labs’ front-end engineer draws parallels between the Unix philosophy and Web3 applications, which creates interoperable, extensible, and reusable code, allowing us to ship better code faster.

The Unix Philosophy at Uniswap Labs

The [Uniswap mobile wallet](https://blog.uniswap.org/uniswap-mobile-wallet-release) is a self-custodial wallet that is simple, safe, and easy to use. Now that it's out, we wanted to give you a behind-the-scenes look at our design principles, why we [open sourced](https://github.com/Uniswap/wallet) it, and how we think about security and privacy.

# Open Source
We open sourced the [Uniswap mobile wallet](https://github.com/Uniswap/wallet) for a few reasons:
- **Open Source is User Aligned:** Users have a right to choose the product that is best for them. Instead of trusting our claims about security, privacy, and data retention, users should be able to validate these claims by directly viewing the source code. Open source products allow users to evaluate their options to the greatest extent possible.
- **Open Source Builds Trust:** The Uniswap mobile wallet has been audited by multiple parties, including [Trail of Bits](https://github.com/trailofbits/publications/blob/master/reviews/UniswapMobileWallet-securityreview.pdf). These security reviews build trust in the safety of our products. Open sourcing takes this [one step further](https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/open-source-security.html). By exposing our codebase to the public forum, security researchers can further vet our wallet.
- **Open Source is Collaborative:** When we started building the wallet, there weren't many open sourced wallets to learn from. By publishing our code, the Uniswap mobile wallet becomes a reference for other builders.

We've open sourced the entire wallet, including code that touches private keys, seed phrases, and on-chain data. You can inspect our repo, but some noteworthy code includes [key management](https://github.com/Uniswap/wallet/blob/main/ios/RNEthersRS.swift), [iCloud backup](https://github.com/Uniswap/wallet/blob/main/ios/RNICloudBackupsManager.swift), arbitrary transaction signing using [WalletConnect](https://github.com/Uniswap/wallet/blob/main/src/features/walletConnect/saga.ts#L289), [token swaps](https://github.com/Uniswap/wallet/blob/main/src/features/transactions/swap/swapSaga.ts) on multiple chains, viewing [NFTs](https://github.com/Uniswap/wallet/blob/main/src/components/images/NFTViewer.tsx), and various [UI components](https://github.com/Uniswap/wallet/tree/main/src/components).

# Security
We had two goals that informed the mobile wallet design principles:
1. Protect the user's wallet from being drained by securely storing and accessing the seed phrase
2. Protect the user from losing wallet access with backup options

### Seed Phrase Storage
Seed phrases and private keys stored on local devices use a combination of [iOS Keychain](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/1/web/1) and [Secure Enclave](https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web) to maximize security.

Apple built the iOS Keychain as a SQLite database that securely stores secrets, like passwords, certificates, and private keys. Some unique properties of the Keychain include:
- Items are encrypted using two AES-256-GCM keys: A table key and per-row key
- Items never leave your device
- Items cannot be shared between applications
- Items do not sync to the iCloud keychain

Keychain items are encrypted using 256-bit keys stored in Apple's [Secure Enclave](https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/protecting_keys_with_the_secure_enclave), a dedicated hardware-based key manager isolated from the main processor.

Decrypting data within the Keychain requires a round trip through the Secure Enclave adding an extra layer of security. If the iOS keychain or application processor is compromised, Uniswap mobile wallet keychain items remain encrypted because the encryption key is kept in a hardened hardware module separate from the main processor. iOS Keychain and Secure Enclave are Apple implementations and are not specific to our wallet.

![storage](//images.ctfassets.net/oc3ca6rftwdu/2jxQoIK1lsIIKJtUgCkbsJ/1b62682ce2fdd508747debcdfb3a5084/storage.jpeg)

### Accessing Private Keys & Seed Phrases
The Uniswap mobile wallet accesses seed phrases and private keys to
1. Display the seed phrase on-screen
2. Create signatures

To display items on-screen, we use a native [UI component](https://github.com/Uniswap/wallet/blob/main/ios/RNEthersRS.swift) written in Swift to fetch and display the seed phrase from the secure iOS Keychain.

The flow for creating signatures is more extensive. When the wallet has a message or transaction to sign, it is sent from React Native to Swift. The wallet's private key is securely fetched from the iOS keychain, and the `ethers-rs-mobile` [library](https://github.com/Uniswap/ethers-rs-mobile) - written in Rust - generates the signature. The valid signature is passed back through Swift and Javascript to execute transactions.

To further protect these sensitive user flows, you can enable biometric authentication via Face ID or Touch ID. Whenever you attempt to view your seed phrase or sign a transaction, you will be prompted to complete biometric authentication.

We compiled the `ethers-rs` [library](https://github.com/gakonst/ethers-rs) written in Rust to an iOS-compatible [version](https://github.com/Uniswap/ethers-rs-mobile) in C++, `ethers-rs-mobile`, giving us performance and security benefits with key derivation and signing functions. While React Native is fantastic for mobile app development, Javascript is susceptible to supply chain attacks from upstream dependencies. The `ethers-rs-mobile` library ensures that wallet seed phrases and private keys never touch Javascript code.

### Backups
All self-custodial wallets come with manual backups, encouraging users to write down their seed phrase for later recovery. But if a user loses their phone without a manual backup, they will lose access to their wallet. That’s why the Uniswap mobile wallet offers two recovery methods:
1. Manual seed phrase
2. iCloud backup

Users can manually back up their seed phrase by viewing it during the onboarding flow or by revealing it in-app after passing an authentication check. They are encouraged to physically write it down. We strongly recommend Face ID as the strongest authentication treatment.

iCloud recovery is optional but highly recommended for those new to crypto. When a user chooses the iCloud backup,  we require a user password to encrypt the seed phrase before storing it in iCloud. This way, even if a user's iCloud account is compromised their wallet is still protected. 

The seed phrase is locally encrypted using Apple's [AES.GCM](https://developer.apple.com/documentation/cryptokit/aes/gcm) cipher suite with a key derived from the user password using the [Argon2](https://datatracker.ietf.org/doc/rfc9106/) key derivation function. Even in this flow, sensitive data like the encryption key does not touch Javascript.

![store](//images.ctfassets.net/oc3ca6rftwdu/6bRWbgLqIhHFFRUk9dXRjy/451d0b955a2e7769629251bdca3183a0/store.jpeg)

To restore a wallet from iCloud backup, users must be logged into their iCloud account and enter the password they used to encrypt their seed phrase.

![restore](//images.ctfassets.net/oc3ca6rftwdu/IWsfxxt7brLPQWjVrXwQ7/31d50cba7590e0f2e529378dcb4264fe/restore.jpeg)

This additional encryption mechanic maximizes security while still supporting an intuitive and familiar backup experience.

# Privacy
Uniswap Labs **does not** keep any information that allows us to identify individuals. We do not store first name, last name, street address, date of birth, email address, or IP address in any of our products, including our mobile wallet.

Anything we keep is confined to on-chain data and very limited off-chain data like device type and browser version, which allows us to troubleshoot errors and improve products for our users. None of this data is identifiable.

The Uniswap mobile wallet uses APIs like Infura, OpenSea, Covalent, TRM, and more. Many of these APIs help us serve data to the user, like token prices, NFT data, and on-chain activity. Most requests sent to these APIs are proxied through a Uniswap Labs server that removes and deletes IP addresses. A handful of API calls sent to Infura are direct, which includes IP. We are actively working to obfuscate non-proxied API calls.

# Download the mobile wallet!
As of this blog post, the Uniswap mobile wallet is [waiting for App Store approval](https://www.coindesk.com/business/2023/03/03/uniswap-wants-to-launch-crypto-wallet-app-but-apple-says-not-so-fast/). In the meantime, we have released the mobile wallet on TestFlight. We'll periodically release access links on [Twitter](https://twitter.com/uniswap), so please watch our feed. You can also learn more about the wallet features in our [announcement post](https://uniswap.org/blog/uniswap-mobile-wallet-early-access) and dive into the [wallet repo](https://github.com/Uniswap/wallet).

If you have any questions or feedback, please join [Discord](https://discord.gg/FCfyBSbCU5) and ask!

*Update (April 13th, 2023): The Uniswap mobile wallet GA release was cut. Download it from the [App Store](https://apps.apple.com/app/apple-store/id6443944476?pt=123625782&ct=Announcement%20Blog&mt=8).*

Uniswap engineers give a behind the scenes look at how we built the Uniswap mobile wallet, with a focus on security architecture, open source principles, and privacy considerations.

A Technical Overview of the Uniswap Mobile Wallet


_By: [Austin Adams](https://twitter.com/AustinAdams10), [Sara Reynolds](https://twitter.com/saraareynolds), and [Rachel Eichenberger](https://twitter.com/eich4all) [^1]_

[^1]: We thank [Atis Elsts](https://twitter.com/atiselsts) for their comments.

Uniswap Protocol makes swapping simple and accessible, but its math may not be. To help developers building on the Protocol, analysts drawing insights, and researchers studying market activity, let’s dig into a few of the most common technical questions we see.
- What is Q Notation?
- How do I calculate the current exchange rate?
- How do tick and tick spacing relate to sqrtPrice?

[Part 2](https://blog.uniswap.org/uniswap-v3-math-primer-2) focuses on:
- Working with virtual liquidity
- Calculating LP holdings
- Calculating uncollected fees in a position

![figure1 (1)](//images.ctfassets.net/oc3ca6rftwdu/6EXUbqrPBsyeuoiGtEAXuP/c10bb96e4e9cc8e069a5cbf01f11dc6f/figure1__1_.png)

<font size="1">
<a href="https://twitter.com/0xKaden/status/1603545440913223682">Source</a>
</font>

# What is a Q notation?

If you've ever read the Uniswap v3 code and seen variables that end with X96 or X128, you have come across what we call Q notation. With Uniswap v3 came the heavy usage of the Q notation to represent fractional numbers in [fixed point](https://en.wikipedia.org/wiki/Q_(number_format)) arithmetic. If that seems like word salad to you, then don't worry! 

Long story short, you can convert from Q notation to the “actual value” by dividing by <Latex>$ 2^k $</Latex> where <Latex>$ k $</Latex> is the value after the X. For example, you can convert `sqrtPriceX96` to sqrtPrice by dividing by <Latex> $ 2^{96}$</Latex>

Q notation specifies the parameters of the binary fixed point number format, which allows variables to remain integers, but function similarly to floating point numbers. Variables that must be as precise as possible in Uniswap v3 are represented with a maximum of 256 bits and account both for overflow and potential rounding issues. By using Q notation, the protocol can ensure that granular decimal precision is not lost.

### Code example
```js
//  Get sqrtPriceX96 from token reserves
//  In scripts that use Javascript, we are limited by the size of numbers with a max of 9007199254740991. Since crypto 
//  handles everything in lowest decimal format, We have to use a version of BigNumber, allowing Javascript to handle 
//  numbers that are larger than the max.
//  Here we use a Pure BigNumber script from EthersJS along with BigNumber itself
//  you will also see us use JSBI is a pure-JavaScript implementation of the official ECMAScript BigInt proposal

import { BigNumber } from 'ethers'; // ← used to convert bn object to Ethers BigNumber standard 
import bn from 'bignumber.js'      //  ← here we use BigNumber pure to give us more control of precision
                                  //     and give access to sqrt function

//bn.config allows us to extend precision of the math in the BigNumber script
bn.config({ EXPONENTIAL_AT: 999999, DECIMAL_PLACES: 40 }) 
function encodePriceSqrt(reserve1, reserve0){
  return BigNumber.from(
    new bn(reserve1.toString()).div(reserve0.toString()).sqrt()
      .multipliedBy(new bn(2).pow(96))
      .integerValue(3)
      .toString()
  )
}

              // reserve1         ,  reserve0
encodePriceSqrt(1000000000000000000, 1539296453)
```

# How do I calculate the current exchange rate?
One of the first questions people naturally ask in a market is “what is the current price”? For Uniswap v3, the price is quoted as the current exchange from token 0 to token 1 and is found in `sqrtPriceX96`. 

Uniswap v3 shows the current price of the pool in `slot0`. `slot0` is where most of the commonly accessed values are stored, making it a good starting point for data collection. You can get the price from two places; either from the `sqrtPriceX96` or calculating the price from the pool `tick` value[^2]. Using `sqrtPriceX96` should be preferred over calculating the price from the current `tick`, because the current `tick` may lose precision due to the integer constraints (which will be discussed more in depth in a later section).

[^2]: price = 1.0001^tick, and this equation will be explained more later in the blog post.

`sqrtPriceX96` represents the sqrtPrice times <Latex> $ 2^{96}$</Latex> as described in the Q notation section. <Latex> $ 2^{96}$</Latex> was specifically was chosen because it was the largest value for precision that allowed the protocol team to squeeze the most variables into the contract storage slot for gas efficiency. 

### Math

First, as previously discussed, sqrtPrice is the `sqrtPriceX96` of the pool divided by <Latex> $ 2^{96}$</Latex>

<Latex displayMode={true}>$ sqrtPrice = sqrtPriceX96 / 2^&#123;96&#125; $</Latex>

You can convert the sqrtPrice of the pool into the price of the pool by squaring the sqrtPrice.

<Latex displayMode={true}>$ price = sqrtPrice^2 $</Latex>

Putting those equations together

<Latex displayMode={true}>$ price = (sqrtPriceX96 / 2^&#123;96&#125;)^2 $</Latex>

### Math Example

In the USDC-WETH 5-bps pool (also the .05% fee tier), token0 for this pool is USDC and token 1 is WETH. For this pool, <Latex> $ price = \frac&#123;token1&#125;&#123;token0&#125; = \frac&#123;WETH&#125;&#123;USDC&#125; $</Latex>. This also represents the exchange rate from <Latex> $ token0 $</Latex> to <Latex> $ token1 $</Latex>.  For this specific pool, this exchange rate is the amount of WETH that could be traded for 1 USDC[^3].

[^3]: It is important to note that this is backwards to what people expect, which is a problem that many developers run into. Uniswap v3 chooses token ordering by their contract address, and the USDC contract address comes first.

From `slot0` in the pool contract at address [0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640](https://etherscan.io/address/0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640) at [block number 15436494](https://etherscan.io/block/15436494).

<Latex displayMode={true}>$ sqrtPriceX96 = 2018382873588440326581633304624437 $</Latex>

Plugging this value into the equation above, we have

<Latex displayMode={true}>$ \frac&#123;WETH&#125;&#123;USDC&#125; = (2018382873588440326581633304624437 / 2^&#123;96&#125;)^2 $</Latex>

<Latex displayMode={true}>$ \frac&#123;WETH&#125;&#123;USDC&#125; = 649004842.70137 $</Latex>

erc20 tokens have built in decimal values. For example, 1 WETH actually represents <Latex> $ 10^{18} $</Latex> WETH in the contract whereas USDC is <Latex> $ 10^6 $</Latex>. Therefore, USDC has 6 decimals and WETH has 18.

<Latex displayMode={true}>$ adj\frac&#123;WETH&#125;&#123;USDC&#125; = 649004842.70137 / \frac&#123;10^&#123;18&#125;&#125;&#123;10^6&#125; $</Latex>

<Latex displayMode={true}>$ adj\frac&#123;WETH&#125;&#123;USDC&#125; = 649004842.70137 / 10^&#123;12&#125; $</Latex>

Most exchanges quote the multiplicative inverse, <Latex> $ price = $ $ adj\frac&#123;USDC&#125;&#123;WETH&#125; $</Latex> which is the amount of USDC that represents 1 WETH. To adjust for this, we also need to divide <Latex> $ 1/price $</Latex> as 

<Latex displayMode={true}> $ adj\frac&#123;USDC&#125;&#123;WETH&#125; = \frac&#123;1&#125;&#123;adj\frac&#123;WETH&#125;&#123;USDC&#125;&#125; $</Latex> 

<Latex displayMode={true}> $ adj\frac&#123;USDC&#125;&#123;WETH&#125; = \frac&#123;1&#125;&#123;649004842.70137 / 10^&#123;12&#125;&#125; $</Latex> 

<Latex displayMode={true}> $ adj\frac&#123;USDC&#125;&#123;WETH&#125; = \frac&#123;10^&#123;12&#125;&#125;&#123;649004842.70137&#125; $</Latex>

<Latex displayMode={true}> $ price = adj\frac&#123;USDC&#125;&#123;WETH&#125; = \space \space \sim1540.82  $</Latex> 

This is the number generally seen quoted on exchanges and data sources. See the formula and math here: <a href="https://www.symbolab.com/solver/step-by-step/%5Cfrac%7B1%7D%7B%5Cleft(%5Cfrac%7B2018382873588440326581633304624437%7D%7B2%5E%7B96%7D%7D%5Cright)%5E%7B2%7D%5Ccdot%20%5Cleft(%5Cfrac%7B10%5E%7B6%7D%7D%7B10%5E%7B18%7D%7D%5Cright)%7D?or=input">Symbolab Big Math</a>

### Code Example
This will give the price of both tokens in relation to the other, as all pools will have two prices.

```js
// Get the two token prices of the pool
// PoolInfo is a dictionary object containing the 4 variables needed
// {"SqrtX96" : slot0.sqrtPriceX96.toString(), "Pair": pairName, "Decimal0": Decimal0, "Decimal1": Decimal1}
// to get slot0 call factory contract with tokens and fee, 
// then call the pool slot0, sqrtPriceX96 is returned as first dictionary variable
// var FactoryContract =  new ethers.Contract(factory, IUniswapV3FactoryABI, provider);
// var V3pool = await FactoryContract.getPool(token0, token1, fee);
// var poolContract =  new ethers.Contract(V3pool, IUniswapV3PoolABI, provider);
// var slot0 = await poolContract.slot0();

function GetPrice(PoolInfo){
	let sqrtPriceX96 = PoolInfo.SqrtX96;
	let Decimal0 = PoolInfo.Decimal0;
	let Decimal1 = PoolInfo.Decimal1;

    const buyOneOfToken0 = ((sqrtPriceX96 / 2**96)**2) / (10**Decimal1 / 10**Decimal0).toFixed(Decimal1);

	const buyOneOfToken1 = (1 / buyOneOfToken0).toFixed(Decimal0);
	console.log("price of token0 in value of token1 : " + buyOneOfToken0.toString());
	console.log("price of token1 in value of token0 : " + buyOneOfToken1.toString());
	console.log("");
		// Convert to wei
	const buyOneOfToken0Wei =(Math.floor(buyOneOfToken0 * (10**Decimal1))).toLocaleString('fullwide', {useGrouping:false});
	const buyOneOfToken1Wei =(Math.floor(buyOneOfToken1 * (10**Decimal0))).toLocaleString('fullwide', {useGrouping:false});
	console.log("price of token0 in value of token1 in lowest decimal : " + buyOneOfToken0Wei);
	console.log("price of token1 in value of token1 in lowest decimal : " + buyOneOfToken1Wei);
	console.log("");
}

        // WETH / USDC pool 0.05%    →(1% == 10000, 0.3% == 3000, 0.05% == 500, 0.01 == 100)
("0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", 500)
// Output
price of token0 in value of token1 : 1539.296453
price of token1 in value of token0 : 0.000649647439939888
price of token0 in value of token1 in lowest decimal : 1539296453
price of token1 in value of token1 in lowest decimal : 649647439939888
```

# Relationship between tick and sqrtPrice

Ticks are used in Uniswap v3 to determine the liquidity that is in-range. Uniswap v3 pools are made up of ticks ranging from -887272 to 887272, which functionally equate to a token price between 0 and infinity[^4], respectively. More on this below.

[^4]: This conversion from tick to price directly equates to 2^-128 to 2^128, which are functionally 0 to infinity.

## Ticks vs Tick-Spacing
We find that end users are constantly confused by ticks vs tick-spacing.
- Ticks: Units of measurement that are used to define specific price ranges
- Tick-spacing: The distance between two ticks, as defined by the fee tier

Not every `tick` can be initialized. Instead, each pool is initialized with a `tick-spacing` that determines the space between each `tick`. Tick-spacings are also important to determine where liquidity can be placed or removed. If there is an initialized `tick` at tick 202910, then liquidity at most can change as early as the first value given by the `tick-spacing`, which is 202910 + 10 for the 5 bps pool[^5].

[^5]: Ticks are only initialized if someone has placed liquidity that either starts or ends at that tick. It is possible that no one placed liquidity ending at the next tick, so it may not be initialized. However, positions can only be placed at ticks that are determined by the tick-spacing.

<div align="center">
  <strong>Table 1.</strong>  Relationship between fees and tick-spacing
</div>

![table1 (2)](//images.ctfassets.net/oc3ca6rftwdu/4frFW4vjWztra6jaQRqjve/241b6f514df980da1e1afc11709a82bd/table1__2_.png)

Using the table above, we can determine the `tick-spacing` of the pool directly from the fee-tier. We show both the percentage and the bps format for these values, as used interchangeably by practitioners, but may be confusing for new users. 

<div align="center">
  <strong>Figure 1.</strong> Example of tick-spacing vs ticks for WETH-USDC 5 bps pool
</div>

![figure2 (1)](//images.ctfassets.net/oc3ca6rftwdu/1CAALWusWI2Q2Ns1CvS2Zs/2388c8df6c862e74cbb88830847a6296/figure2__1_.jpeg)

In Figure 1, we show a small portion of the liquidity distribution for the WETH-USDC 5 bps pool at the block previously discussed. The dashed black lines indicate possible initialized ticks (which occur every at minimum `tick-spacing` of 10 for 5 bps pools). The solid black line indicates the current `tick` of the pool. 

Also notice that liquidity is constant between two dashed lines. This is because liquidity can only change when a tick-spacing is crossed. Between those ticks, the liquidity in-range is treated like an xy=k curve like Uniswap v2 for trading. If that confuses you, don't worry, it's not important. If you want to learn more about liquidity, we will talk more about liquidity in a later post.

## What does a tick represent?
Ticks are related directly to price. To convert from tick <Latex> $ \tau $</Latex>, to price, take <Latex> $ 1.0001^\tau $</Latex> 1.0001  to get the corresponding price. Let the tick-spacing be <Latex> $ ts $</Latex> and <Latex> $ i_c $</Latex> be the lower bound of the active tick-range, then the current tick-range is  <Latex> $ [i_c, i_c + ts) $</Latex> We can then map the current tick-range to the current price-range with 

<Latex displayMode={true}>  $ [1.0001^&#123;i_c&#125;, 1.0001^&#123;i_c + ts&#125;) $</Latex>

**Note**: Everything up-to, but not including the upper tick is part of the current range

While liquidity can only be added at initialized ticks, the current market-price can be between initialized ticks. In the example above, the USDC-WETH 5-bps pool is at tick 202919. This number is not evenly divisible by the `tick-spacing` of 10, we need to find the nearest numbers above and below that are. This corresponds to tick 202910 and tick 202920, which we showed in Figure 1.

The current `tick-range` can also be calculated by [^6]

[^6]: <Latex>  $ \lfloor x \rfloor $</Latex> represents the floor of the value <Latex>$ x $</Latex>, or the greatest integer value that is less than or equal to <Latex>$ x $</Latex>

<Latex displayMode={true}>  $ [( \lfloor i_c / ts \rfloor * ts, ( \lfloor i_c / ts \rfloor) * ts + ts)) $</Latex>

In the USDC-WETH example we get:

<Latex displayMode={true}>  $ [\lfloor 202919 / 10 \rfloor * 10, \lfloor 202919 / 10 \rfloor * 10 + 10)) $</Latex>

<Latex displayMode={true}>  $ [\lfloor 20291.9 \rfloor * 10, \lfloor 20291.9 \rfloor * 10 + 10)) $</Latex>

<Latex displayMode={true}>  $ [20291 * 10, 20291 * 10 + 10) $</Latex>

<Latex displayMode={true}>  $ [202910, 202920) $</Latex>

Thus, the current `tick-range` of in-range liquidity for the USDC-WETH pool is currently <Latex>  $ [202910, 202920) $</Latex>, but what prices does this `tick-range` map to? Its maps to

<Latex displayMode={true}>  $ [1.0001^&#123;202910&#125;, 1.0001^&#123;202920&#125;) = [648378713.2500573, 649027383.8115474) $</Latex>

Let's convert to `tick-range` in terms of adjusted <Latex> $ \frac&#123;USDC&#125;&#123;WETH&#125; $</Latex>  as done previously. Remember that we need to adjust for the decimal differences between USDC and WETH, and invert the price since we want <Latex> $ \frac&#123;USDC&#125;&#123;WETH&#125; $</Latex> (the amount of USDC given by 1 WETH) not <Latex> $ \frac&#123;WETH&#125;&#123;USDC&#125; $</Latex> (the amount of WETH given by 1 USDC).

<Latex displayMode={true}>  $ 1 / ([648378713.2500573, 649027383.8115474)  / 10^&#123;12&#125;) $</Latex>

<Latex displayMode={true}>  $ 1 / [0.0006483787133, 0.0006490273838) $</Latex>

<Latex displayMode={true}>  $ [1542.30, 1540.76) $</Latex>

The price we calculated from `sqrtPriceX96` in the previous example falls between this range - a good sanity check that we've calculated the price ranges properly![^7]

[^7]: Notice that the larger price is now first. That is because of the inverting of the exchange rate. This can cause a lot of confusion and problems with code!

## How does tick and tick spacing relate to sqrtPriceX96?
You may be asking, if <Latex> $ price = 1.0001^{202919} $</Latex> (the current tick of the pool) and <Latex> $ price = 649004842.70137 $</Latex> (derived from the sqrtPriceX96 of the pool) then why does <Latex> $ price = 1.0001^{202919} = 648962487.5642413 \neq 649004842.70137 $</Latex>

Instead of calculating the price using the `tick` value from the `slot0` call, let's derive it from the `sqrtPriceX96` value and see where the discrepancy between the current `tick` and `sqrtPriceX96` lies.

We know that <Latex> $ price = 1.0001^&#123;i_c&#125; $</Latex>, then 

<Latex displayMode={true}>  $ 649004842.70137 = 1.0001^&#123;i_c&#125; $</Latex>

<Latex displayMode={true}>  $ \log(649004842.70137) = \log(1.0001^&#123;i_c&#125;) $</Latex>

<Latex displayMode={true}>  $ \log(649004842.70137) = i_c\log(1.0001) $</Latex>

<Latex displayMode={true}>  $ \frac&#123;\log(649004842.70137)&#125;&#123;\log(1.0001)&#125; = i_c $</Latex>

<Latex displayMode={true}>  $ 202919.6526706078 = i_c $</Latex>

This explains why using ticks can be less precise than `sqrtPriceX96` in Uniswap v3. 

Just like ticks can be in between initialized ticks, ticks can also be in-between integers as well! The protocol itself reports the floor <Latex> $ \lfloor i_c \rfloor $</Latex> of the current tick, which the `sqrtPriceX96` retains. 

### Example Tick to Price
```js
let price0 = (1.0001**tick)/(10**(Decimal1-Decimal0))
let price1 = 1 / price0
```

### Example sqrtPriceX96 to Tick
**Note:** the Math.floor as stated above, the calculation will have decimals, not needed for tick

```js
const Q96 = JSBI.exponentiate(JSBI.BigInt(2), JSBI.BigInt(96));
let tick = Math.floor(Math.log((sqrtPriceX96/Q96)**2)/Math.log(1.0001));
```

# Conclusion

Overall, we hope that this long primer on Uniswap v3 is helpful. Helping our community gracefully and efficiently understand Uniswap v3 will help push along the ecosystem to be the best that it can be. For anything else, feel free to join the dev-chat in our [discord](https://discord.gg/vcZv8DbbE3) and ask.

Read part 2 [here](https://blog.uniswap.org/uniswap-v3-math-primer-2).

---

## Related References

1. [Liquidity Math in Uniswap v3](https://atiselsts.github.io/pdfs/uniswap-v3-liquidity-math.pdf) by Atis Elsts
2. [Uniswap v3 Development Book](https://uniswapv3book.com/) by Ivan Kuznetsov
3. [Uniswap v3 Core](https://uniswap.org/whitepaper-v3.pdf) by the Uniswap Labs' team
4. [Uniswap v3 - New Era of AMMs?](https://www.youtube.com/watch?v=Ehm-OYBmlPM) By Finematics

The math for Uniswap v3 can be confusing. This guide answers some of our most common questions, including Q Notation, ticks, exchange rates, and more!

A Primer on Uniswap v3 Math: As Easy As 1, 2, v3

Build your first on chain integration with the Uniswap Protocol

Building Your First Uniswap Integration

_By [Noah Zinsmeister](https://twitter.com/NoahZinsmeister)_

Today, I'm pleased to announce that I've transferred ownership of [web3-react](https://github.com/Uniswap/web3-react) to Uniswap Labs. For the uninitiated, web3-react is a simple, maximally extensible, dependency minimized framework for building modern Ethereum dApps. The repository’s new home is now [Uniswap/web3-react](https://github.com/Uniswap/web3-react), though distribution will still be under the `@web3-react` npm organization. This is the culmination of a multi-year, ongoing integration, and I'm thrilled that my fellow engineers at Uniswap Labs will be able to take an ownership stake in one of the most widely used web3 frontend libraries — with the goal of leveling up the library in the long run.

When I first became interested in Ethereum in late 2017, I started a side project called [ProveIt](https://github.com/NoahZinsmeister/ProveIt). I had tons of fun brainstorming use cases for a public, immutable ledger, and writing my first smart contract. But I struggled to create even a rudimentary frontend for my project (though in the end, it [turned out okay](https://noahzinsmeister.github.io/ProveIt/)).

![proveit](//images.ctfassets.net/oc3ca6rftwdu/5E4ASenvc2b5wCGYSgeKYd/3415d4ffab78fe70858e554b5d8a9438/proveit.png)

I quickly realized that I wasn't just a bad frontend developer — or at least that wasn't the only problem... Frontend tooling for dApps was in a sorry state, so in 2018 I set out to build what became [web3-webpacked](https://github.com/NoahZinsmeister/web3-webpacked), a "drop-in web3 solution for single-page Ethereum dApps". This experience quickly brought me to the boundaries of my technical knowledge, and while the library was beginning to pick up steam, I realized that a more elegant approach built on stronger foundations was warranted. This approach was the beginning of [web3-react](https://github.com/Uniswap/web3-react), which is still in use today and has nearly 4k stars on Github and over [300k monthly downloads](https://npm-stat.com/charts.html?package=%40web3-react%2Fcore&from=2020-01-01&to=2022-06-30).

![downloads per month](//images.ctfassets.net/oc3ca6rftwdu/vblhpCaumIqjzVNPdiH7Z/5b34ce7b8dc5392dace955aa27b4cf7d/downloads_per_month.png)

web3-react was actually (indirectly) responsible for landing me my role at Uniswap, and my first official project was updating the Uniswap interface to use my library (which I completed in commit [#4e41391](https://github.com/Uniswap/interface/commit/4e413915f8fa3bfdda98c6d623dd35d207cda150)). This effort neatly separated the majority of wallet connection logic from app logic and offered easy access to a user's address and web3 connection throughout the codebase. This migration represented a big DevEx/UX improvement (at a time when dApps were regularly blocking interaction behind a required MetaMask popup!), and I was proud to have contributed, albeit in a small way, to the improvement of web3 developer tooling.

However, as the years went on, and wallet standards came and went, I was only able to give intermittent support to web3-react. Because I'd dogfooded the library, I always made an effort to keep it functional, but I occasionally fell behind the state of the art, as more and more of my time went into smart contract development.

Recently, I felt compelled to modernize the library in a v8 release, which is currently in a fully functional beta. This release dramatically improved performance and reduced developer friction, but it also included some breaking changes, and I quickly realized that as a solo maintainer I wasn't going to be able to offer the level of support and backwards compatibility that's required for a library used by applications with Uniswap's level of scale. By transferring ownership of web3-react to Uniswap Labs, we now have a much larger and more talented team dedicated to maintaining the library.

Being able to write and maintain open-source, copyleft code has always been a pleasure and an honor for me, and I'm excited for what this new chapter will bring to web3-react.

Download the repo [here](https://github.com/Uniswap/web3-react).

Engineering Lead, Noah Zinsmeister, transfers ownership of GitHub repo, web3-react, to Uniswap Labs