The problem Gibscard - ZK gift cards on-chain solves

Gibscard is a protocol that enables on-chain gift cards. The global gift card market is currently worth $899.3 billion and is expected to grow to $2.3 trillion by 2030 (*1). We believe that this market can be brought into the Web3 by utilizing the latest technologies, such as Account Abstraction and Zero-Knowledge proofs.

ZK technology helps us create a simple, permissionless, and secure way to share single-use gift cards with anyone. These gift cards can be shared online or printed.

The gift cards are usually used by the non-tech users, so we hide all the complexity under a social login, giving the user a web2 experience while being on-chain. When a user receives a gift card, they can log in using their email address, and we will create an AA wallet for them. They can then select a product on our website and click on the "Buy" button.

ZK proofs are used to prove ownership of deposited assets in the smart contract. We utilize similar technology that is used in Tornado Cash, but without mixing features. When gifting or receiving a gift card, the parties do not interact directly, reducing the need for trust between parties, while maintaining the same level of security.

In the smart contract, after verifying ZK proof, we will then convert tokens from USDC to the ticker used on the product they have chosen to buy. Lastly, we will send a gas-less transaction on-chain that executes the Withdraw-Swap-Buy process without the user even noticing all the infrastructure and blockchain layers.

This protocol provides a great advantage for businesses as it enables them to effortlessly release their NFT products into the market and make them available through gift cards. Businesses can earn fees by staking the gift cards' value until they are claimed or by setting an expiration date on them, which will result in distributing the unclaimed cards to the business owners.

(*1) https://capitaloneshopping.com/research/gift-card-statistics/

Challenges we ran into

We encountered several issues that were related to the third-party APIs we were using. Our plan from the beginning was to have a multi-chain version of the protocol. However, some APIs were not available on all chains, so we had to do different implementations for each chain. We faced stability issues with some solutions that provided Social Auth for creating an Account Abstraction. We opted for dynamic.xyz, and we had to set up a separate instance for each chain to ensure that the paymaster would work properly.