Gift Vault (FlapXVault)
Overview
The Gift Vault (also known as FlapXVault) allows you to assign an X (Twitter) account as the Gift Owner, who can direct the trading fees to any EVM address of their choice:
Assign Gift Owner: The X account you specify becomes the gift owner who controls where fees go.
Flexible Beneficiary: The gift owner can assign fees to any EVM address and change it anytime.
7-Day Grace Period: If the gift owner doesn't manage the fees at least once in the first 7 days, control is forfeited.
Fallback: Buyback & Burn: If control is forfeited, fees will automatically be used for buyback and burn.
You can use it as a way to give tax fee to a X user or you can build more interesting use cases on top of it! We build the gift vault to make it easier for a web2 developer or an agent to manage the tax fee through social proof. Here are some interesting ideas:
Create an X account for an agent and launch a tax token that assigns the agent as the gift owner. The agent can then route the tax fee to any EVM address. The Agent can manage his own fund by accepting the funding request through X: The requesters can tweet to the agent's X account and ask the agent to support them by routing the tax fee to their address for some duration. The agent can choose to accept or reject the request by managing the vault through tweeting. This could be a charity funds or a VC that supports new projects.
A social game where players tweet to a game X account, and gets the tax fee routed to their address based on some social tasks or achievements.
In the following sections, we introduce how to integrate with the Gift Vault through its API. By following this guide, you will be able to build a complete integration that allows users to manage their vaults using X tweets as social proof.
Table of contents
Prerequisites
Web3 Library: ethers.js v6, viem, or web3.js
Vault Factory Contract Address: See Network Details
Tax Token Address
X Handle (Twitter username of vault owner)
Tweet (you must fetch tweet data yourself)
Network Details
BNB Smart Chain Mainnet
Gift Vault Factory:
0x025549F52B03cF36f9e1a337c02d3AA7Af66ab32Relayer API Endpoint:
https://bnb-x-relayer.taxed.fun/submit
BNB Smart Chain Testnet
Gift Vault Factory:
0xa02DA44D67DB6D692efa7f751b5952bd670d5326Relayer API Endpoint:
https://bnbtest-x-relayer.taxed.fun/submit
Architecture overview
Flow Diagram:
Step-by-step integration
Step 1: Parse and validate tweet content
Integrators must fetch the tweet themselves. The tweet format is strictly enforced:
Tweet Format: gift the fee from [tax_token_address] to [target_address] #FlapGift
Implementation:
Step 2: ⚠️ MANDATORY PREFLIGHT CHECK
ALWAYS call this before backend submission!
Using ethers.js v6:
Using viem:
Important Notes:
xHandle must be lowercase when calling the contract
This is a view function - no gas required, instant response
Returns
[bool canManage, string errorMessage]ALWAYS check this before backend to avoid rate limit violations
Step 3: Submit to backend API
⚠️ ONLY call if Step 2 passed!
Rate Limits:
1 request per minute per IP
Violating may result in IP ban
Endpoint: POST /submit
Step 4: Poll for on-chain confirmation
The relayer processes transactions asynchronously. Poll canManageVault to confirm success.
Why Poll?
Relayer doesn't return transaction hash
Transaction is queued for later processing
Once processed,
canManageVaultreturnsfalsewith error: "The tweet is outdated"
Implementation:
Complete code example
API reference
Tweet content validation
parseTweetText(text: string)
Regex Pattern:
Valid Example:
Invalid Examples:
Contract: canManageVault()
Parameters:
taxToken(address): Tax token contract addressxHandle(string): X handle (MUST be lowercase)tweetId(uint128): Tweet ID
Returns:
canManage(bool): Whether vault can be managederrorMessage(string): Error description if false
Possible Error Messages:
"FlapXVault not found for this tax token"
No vault exists
"xHandle does not match"
Wrong X handle
"Vault is in snowball mode"
Vault cannot be managed
"The tweet is outdated"
Tweet already used (success!)
"" (empty string)
Can manage (success)
Backend API: POST /submit
Endpoint: {relayerEndpoint}/submit
Rate Limit: 1 request per minute per IP
Request:
Success Response (200):
Error Response (4xx/5xx):
Error handling
Common errors
Tweet Validation
"Tweet is not valid"
Deleted/suspended
Use valid, active tweet
"Tweet has no text"
Media-only tweet
Ensure text content
"Author mismatch"
Wrong X handle
Verify correct user
"Format mismatch"
Incorrect format
Use exact format
"Token mismatch"
Wrong address
Verify addresses match
Preflight Check
"Vault not found"
No vault exists
Check token has vault
"xHandle does not match"
Wrong vault owner
Use correct X handle
"Vault is in snowball mode"
Vault locked
Cannot manage anymore
"Tweet is outdated"
Already used
Use new tweet ID
Backend
Rate limit error
Too many requests
Wait 60 seconds
Network timeout
Backend slow
Retry later
Manual submission fallback
If the backend relayer times out after 60 seconds, you can submit the proof directly on-chain using the proof data returned from the backend:
Summary checklist
✅ Fetch tweet (you must do this yourself)
✅ Validate tweet content (Step 1)
Check tweet exists and is valid
Verify author matches X handle
Parse tweet text using regex
Verify tax token matches
✅ ⚠️ MANDATORY: Call canManageVault() (Step 2)
xHandle MUST be lowercase
If false, STOP - do NOT call backend
✅ Submit to backend (Step 3)
Only if preflight passed
Rate limited: 1 request/minute
✅ Poll canManageVault() (Step 4)
Every 15s for max 60s
Success = error: "The tweet is outdated"
✅ Error handling
Implement timeouts
Have manual submission fallback
Key Points:
NEVER skip preflight check - prevents IP ban
Backend is rate-limited (1/min) - no exceptions
xHandle must be lowercase for contract calls
Polling confirms success - relayer is async
Consider showing manual submission option to users after 30 seconds of polling, while continuing to poll up to 60 seconds in the background
Gift Vault interface
Last updated