What is a zap?

Zaps are a great way to reduce the UX friction of an application’s process. Previously, without the invention of zaps, elongated user flows were required. Such as: approve, then action, then approve, then action. Zaps aim to cut this down to simply just approve, then action. Generally, if a protocol has requires a deposit, a zap can be integrated into it.

A few examples are listed below:

Example 1

Let’s suppose stablecoin protocol works in a fashion where, you can deposit some assetA to mint assetB. Let’s also suppose that you only have assetC, and you would like to participate in this protocol and mint some assetB which is a stablecoin.

Without a zap:

1. approve assetC for spending.
2. swap assetC into assetA.
3. approve assetA for spending.
4. deposit assetA and mint assetB.

With a zap:

1. approve assetC for spending.
2. swap assetC into assetA through Ooga Booga, then deposit assetA into the vault and mint assetB

Example 2

Let’s suppose we have a DEX which has a pool with the pair of assetA/assetB, but a user only has assetC, but he wants to provide liquidity into this pool.

Without a zap:

1. approve assetC
2. swap some assetC to assetA
3. approve assetC
4. swap some assetC to assetB
5. LP assetA and assetB into the pool

With a zap:

1. approve assetC
2. swap some assetC into assetA, swap some assetC into assetB, LP assetA and assetB into the pool.

With a zap, we can greatly reduce the steps required by the user, as we can utilise the features of multicall, and bundle this swap + action into one transaction.