MAID - Multi Access Incentive Distribution

MAID - Multi Access Incentive Distribution

Once upon a time in the bustling world of cafes and restaurants, there existed a humble paper card. It was a loyal companion to customers, tucked away in wallets and purses, eagerly awaiting its moment to shine. This was the era of stamp cards, where each visit to your favorite eatery brought you one step closer to a delectable reward.

Fast forward to today, a new age of technology and innovation has dawned. MAID brings the nostalgic charm of loyalty stamp cards into the realm of Web3. We've transformed the trusty paper card into a digital wonder, offering a seamless and friendly solution for protocol users and developers.

Protocols have the ability to define their own requirements for obtaining a stamp. We provide an interface that protocol developers are expected to implement, where the verification logic takes place. Once all the requirements are met (the user collects all the stamps on the card), the user is rewarded.

The rewards come in the form of ERC3525 tokens (Semi-Fungible Tokens). Protocol developers are also expected to implement the logic determining how these rewards can be used. Some examples include token allocation or airdrops, in-protocol discounts, and exclusive member benefits.

MAID - Multi Access Incentive Distribution

We provide an interface that protocol developers are expected to implement, where the verification logic takes place.

A Factory contract is responsible for managing all the coupons. After developers implement their requirements logic, they should add it to the Factory. Users interact with the Factory when they want to claim their rewards. The Factory forwards the verification logic to the appropriate coupon logic, and if successful, rewards users with the ERC3525 token.

We provide examples for this interface implementation for "Proof of OG" (demonstrating that the user was among the first users or token holders of a specific protocol), "Proof of Badge" (showing that the user holds at least a certain number of Sismo badges) and "Proof of Safe" (proving that the user owns a certain number of Safes).

For the verification of the rewards we use Herodotus, that allows to prove information cross-chain (for example purposes we check the eligibility on goerli and verify it on starknet), as well as proving historical data.

• Proof of OG of APE Coin and claim coupon on Starknet
• Proof of OG of GHO Coin and claim coupon on Starknet
• Proof of OG of BOB Coin and claim coupon on Starknet
• Proof of Badge of SISMO Badges and claim coupon on Starknet (TBD)
• Proof of Safe for owning a certain number of Safes and claim coupon on StarkNet

[ TECH STACK ]

• QuickNode for JSON-RPC calls
• Aave GHO, ZkBOB, ApeCoin, Safe and Sismo for demonstrating potential use cases.
• NextJS, ArgentX, Stark-React, Stark.js, Wagmi for frontend
• ERC3525 for user reward
• Herodotus for multi-chain and historical validation of eligibility
• Cairo for validation contracts
• UI designs and architecture in Figma