[FH-2] Airdrop

[FTCHD]

Part of FrameHack2 (1,000 PTS)

ℹ️ Terminology

• Viewer: The person using the Frame on a client.

• User: The person who created the Frame on FrameTrain.

• Creator: The person who created the template from which the Frame was created. This is you, creating a template right now!

• View: A React component that is called by a handler (like a controller in MVC architecture), which then gets rendered using Satori and returned as image.

• BasicView: A specific, existent, pre-made React component imported from @/sdk/components that is used for common scenarios where you need just a title, a (optional) subtitle and a (optional) bottom message. It was made so creators don’t write the same basic component over and over again. It also comes with a matching component to use in your Inspector to let the User customize it named BasicViewInspector, click here for details.

• Handler: A function that receives the VALIDATED POST message from a Farcaster client, does the handling it needs, and returns either Frame data (metadata + a View or an image), or transaction data.

• Inspector: A required React component present in each template that appears as the “Configuration” panel on FrameTrain. It’s the right side of the editor, and is made up of one Configuration.Root and multiple Configuration.Section's (see below). You import the Configuration parent from @/sdk/inspector.

• Section: In order to not overwhelm the user with all the settings at once, we separate these in tabs that the user can navigate to one at a time. This is done internally, you only have to structure the content of your Inspector in multiple Section components.

• Page: A an optional React component present in a template’s folder, that is displayed on the /${FRAME_ID}/show route. You can include such a component in your template to display a Page with a detailed view of the votes in the case of a poll template, achieving the same functionality as WePonder for example.

• SDK: The FrameTrain SDK, located in the @/sdk folder. It provides components and utilities for gating, fonts and much more. Start reading about the SDK here.

• Config: The configuration data the User sets in the Inspector for the current Frame being edited, which is saved in the DB and fed into the template at runtime.

• Storage: Think of this like the state, but persisted in the DB. You receive the storage in your handler, and can return a new value for it, which updates the column in the DB.

Description

• Add your token, let only some people or everyone claim, and launch an Airdrop as a Frame! Can also be used as a faucet.
• The User has to approve our “operator” address in order for us to move tokens from their address to the Viewer’s address. Approval is done directly through the Frame, with the “Claim” button on the Cover that functions differently for the User (than a Viewer) and builds the transaction data based on the config, allowing our “operator” address to be the spender for the User’s wallet.
• The Viewer receives the airdrop in the first address connected to their Farcaster account. We get this data in the body of our handler.
• Includes gating options so not everyone can receive tokens.
• The Page.tsx component shows the list of fids that claimed, which is saved in storage when someone signs the “Claim” transaction, along with the hash, timestamp, and username.

Inspector

• Has Section s for “General”, “Whitelist”, “Blacklist”, “Cover”, “Claimed”, and “Gating”.
• The User needs to input the token they want to airdrop (by contract address) and the wallet address where they hold the tokens for this airdrop.
• The User must also specify the amount per claimer, this can be a general amount for everyone, or they can add specific addresses in the whitelist to claim (with a specific amount for each, or the same for everyone which just sets the same amount for each inputted address)
• The User can also upload a CSV in the address,amount format and the Inspector builds the list of users and amounts, which is stored in the config as the whitelist inputted in the UI. We make no difference if it was inputted in the UI, or using a CSV file.
• The User can add 1 to 3 link buttons to the Cover. They can customize the label and target.
• The User can set a cooldown (the amount of time to pass between claims by the same user), with -1 being only once per fid.
• Gating is done in the same as the existing Cal/Poll/Gated templates, using the GatingInspector component and runGatingChecks function. For more details see the Gating section of the SDK.

Views

• Cover: displays either an image or BasicView (user picks in the Inspector), has a “Claim” button and the rest specified by the User. if the User presses the “Claim” button, we run the approve logic, if a Viewer presses it an they haven’t claimed it we run the normal logic, and if they already claimed, don’t fulfill the gating requirements, or don’t have an address attached we throw a FrameError.
• Approved: displayed to the User after approving our internal address.
• Claimed: displayed to the Viewer as callback after claiming the airdrop.