Project & Team
Description of Project
- (a) Problem the project solves — the problem the project is solving,
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time
- (c) High-level project overview — how the project works at a high level,
- (d) Primary token functions — the primary functions of the token (e.g. gov participation),
- (e) Control surface reliance — if any, briefly describe the anticipated or possible evolution of the protocol’s governance/control model
(a) Problem the project solves
Flash trade offers oracle based, pool-to-peer asset backed perpetual futures at lowest possible fees and highest leverage with guaranteed payoffs and protection against counterparty manipulation across a variety of assets under a single unified decentralized exchange interface.
(b) Operational priorities
The team takes 50% of the revenue the protocol currently generates while having a bootstrapped runway of about $2 million in various assets (like $USDC, $SOL, $BTC, and $ZEC excluding the protocol’s native token $FAF) to support the ongoing and future operations.
(c) High-level project overview
Flash offers various multi-token pools categorized by the index of assets comprising the pool and the perpetual futures markets listed against the pool. These pools are funded by independent liquidity providers to underwrite trades matched against the respective pools in exchange for a fee alongside the underlying realizable profits/losses. Traders can access liquidity from these pools to back margined perpetual positions settled using oracles that fetch prices from aggregated sources guaranteeing the ability to realize PnL with predefined spreads and eliminating the risk of unwanted manipulation.
(d) Primary token functions
The token offers the rights to 50% share of revenue and utility in the form of discounts in trading fees when staked and futarchic governance rights through MetaDAO’s ownership model over the project’s IP, programs and token mint authority.
(e) Control surface reliance
Governance control rests entirely with the DAO representing token holders and any future change would require a governance vote.
Known Project Team
- (a) full names,
- (b) official titles,
- (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Labs/DevCo
| Full Name | Official Title | Prior Experience |
|---|---|---|
| Anas Abdul Khader | CEO and Co-founder | Exited as COO of a stealth drone defense company. Founder of AAK Capital, a market maker on BitMEX. Later spent time as a DeFi degen while building an on-chain fund management protocol on Ethereum. |
| Mohammed Raashid Junaid | CTO and Co-founder | Full-stack engineer with 3 years of experience building software solutions as a consultant in the UK, followed by web3 development on Ethereum and Solana blockchains for the last 5 years. |
| Mohammed Zoheb Shahzan | Director of Engineering and Co-founder | 2 years of collective experience working at Deloitte and Salesforce building infrastructure for institutions, before moving into smart contract development across Ethereum and Solana. |
| Abdul Wahed | Lead Backend engineer and Co-founder | Full-stack engineer with 2 years at NCR Atleos, now bringing his expertise to Web3 and backend infrastructure. |
| Mohammed Abdul Bari Rehan | Lead Rust Engineer and Co-founder | Silver medalist at the International Mathematical Olympiad with deep expertise in on-chain development, having studied blockchain architecture and smart contract programming since graduation. |
Foundation - Futarchy Technology Foundation (F.TEC)
| Full Name | Official Title | Prior Experience |
|---|---|---|
| Natasha Diaz Proll | Independent Director/ | Worked as representative of multiple corporations to ease the process of day to day legal proceedings and have detailed understanding of inner workings of onchain protocols. |
DAO/Onchain Governance DAO is operated under MetaDAO’s Futarchy governance structure wherein the team holds the right to put up necessary proposals to vote on.
DAO Structure
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
The Futarchy governed DAO owns full rights to all codebases, token mint, token liquidity, trademarks and the brand.
(b) Contract/admin powers
The team/co-founders listed above have the sole rights to put up governance proposals while the outcome is decided by a futarchy based voting system powered by MetaDAO. The team acts as the sole governance-executor authority and manages the program upgrade authority through a timelocked 3/7 multisig operated via squads.
(c) Locked-token rights
All token holders who stake/lock their tokens are eligible to receive the corresponding share from 50% of the revenue and the staked tokens unlock linearly over a period of 3 months once requested to unstake and continue to accrue revenue over the remaining locked portion of their stake. In addition to this, stakers are entitled to discounts on trading fees and increased referral rebates on the platform based on a tiered system.
(d) Value accrual & holder rights
The token holders who stake get 50% of all protocol revenue every day and have full voting rights over governance proposals.
(e) Dissolution authority
The DAO can be dissolved either by the team or the Futarchy Foundation upon a vote put forth which needs to be approved by token holders.
Primary Foundation
- (a) Entity — type and jurisdiction.
- (b) IP ownership & control — what IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; “3/5 multisig”).
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
(a) Entity
FUTARCHY TECHNOLOGY FOUNDATION (a Private Interest Foundation, incorporated under the laws of the Republic of Panama)
(b) IP ownership & control
The entity owns all IP related to Flash Trade including the brand, codebases and token mint authority.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
The DAO solely acts as a representative of FAF holders interest and does not have authority to act upon itself while it can only reject execution of proposal if they go against the laws of the country it's established in.
(d) Powers over DevCo
The foundation can only exert direct influence in the cases DevCo takes certain steps that go against the rights of token holders and the law of incorporated country.
(e) Contract/admin powers
The foundation has no direct control over the onchain programs or multi sigs.
(f) Current economic arrangements and distribution policies
No such mechanism exists the DAO serves as a representative to carry out the final governance outcomes as voted by the token holders.
Primary Dev Co
- (a) Entity — type and jurisdiction.
- (b) IP ownership & control — what IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; “3/5 multisig”).
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
(a) Entity
D5 LABS INC. a company incorporated and existing under the laws of the Jurisdiction of Panama
(b) IP ownership & control
Have update and upgrade control overs repos/code
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
The Primary Dev Co have full control over proposal creation that goes ahead for vote and upon its approval are obliged to follow it. Dev Co has no control over treasury or token mint authority.
(d) Powers over Foundation
No except for putting up proposal that token holders can vote on.
(e) Contract/admin powers
No
(f) Current economic arrangements and distribution policies
50% of the all revenue generated by the onchain programs goes to the primary Dev Co as money to maintain and upgrade the underlying infrastructure.
Token Supply & Allocations
Initial Allocation
- (a) Launch supply totals — the total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch;
- (b) Recipient categories & use of funds — the recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket;
- (c) Initial price per token (if applicable) — the initial price per token at TGE.. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
- (d) Ticker / market symbol — the ticker/market symbol;
- (e) Total supply & supply regime — the total supply and whether the supply is fixed (if not explain inflation rate or deflation rate);
- (f) Initial vesting / release schedules — the initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic);
(a) Launch supply totals
80% of the supply was distributed amongst holders of the beast NFT (beast NFT was minted to bootstrap the initial liquidity pool to launch the exchange) 1 billion issued at launch and 800,000,000 distributed amongst users of Flash
(b) Recipient categories & use of funds
- 80% i.e. 800,000,000 FAF - Users who staked tokens to earn revenue share and unlock perks on the exchange
- 9.6% i.e. 96,000,000 FAF - To team squads for FAF reward distribution that happens every month to incentivise usage of the exchange more details on how this program worked can befound here (this program has concluded fully now)
- 5.4% i.e 54,000,000 FAF - Tokens for incubation of Flash since the exchange was bootstrapped Solana labs incubated the exchange at the beginning by helping the team with hands on engineering, auditing and designing expertise.
- 4% i.e. 40,000,000 FAF Add as liquidity on Metadao AMM
- 1% i.e. 10,000,000 FAF Distributed to advisors who helped Flash during early days of its formation with direct hands-on work, these tokens are currently vesting through streamflow. More details of all the trxs of how tokens are vesting or distributed can be found here
(c) Initial price per token
We launched at a fixed price of 0.005c and added liquidity at the marketcap of $5 million because the total evaluation of the NFTs we had launched earlier through tensor launchpad was at $5 million. The team bootstrapped the pool using their own capital with the FAF liquidity that was allotted.
(d) Ticker / market symbol
FAF (CA: FAFxVxnkzZHMCodkWyoccgUNgVScqMw2mhhQBYDFjFAF)
(e) Total supply & supply regime
Total Supply is 1,000,000,000 tokens and its a mintable token; the mint authority is held by the DAO and governed using futarchy.
(f) Initial vesting / release schedules
Currently only advisor tokens and incubation tokens are being vested which amounts to 5.925% i.e. 59,250,000 FAF tokens
-
- Incubation tokens: 5.4% supply allocated with a 2 year linear vesting period (as of today 41.2% is still vesting with a completion date of Apr 14, 2027)
-
- Advisory tokens: 1% supply was allocated and was distributed/vested over different durations.A. 0.542% unlocked at TGEB. 0.1% 2 years linear vesting (currently ongoing here)C. 0.175% 6months cliff with 2 years linear vesting (completed according to agreement that counted start date since our engagement with the advisor that started before TGE)D. 0.15% 2 years linear vesting (currently ongoing here) All their details can be found here.
Airdrop Process
- (a) commit to publish, in a public channel and provide to Blockworks quarterly a recipient wallet list until the initial TGE airdrop is fully completed,
- (b) Generally state the possible target user segments (e.g., “stakers of X,” “Aave users”) and the allocation method (e.g., proportional to ve-balance or net position). If the project has already airdropped, it must:
- (a) For executed airdrops, point to an per-address source such as CSV/TSV/JSON files, a Dune dashboard, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone don’t count.
- (b) Clearly state covered user segments (e.g., “stakers of X,” “Aave users”) and the allocation method (e.g., proportional to ve-balance or net position). If the project does not plan to do an airdrop for TGE, it must:
- (a)If no airdrop has ever been conducted, say so plainly (“We have never conducted an airdrop to date and do not plan to execute one”).
Flash did one of a kind airdrop where all activity on the platform was recorded onchain using programmatically controlled dynamic NFTs which acted as receipts that updated on each interaction of the user with the platform and at TGE these receipts were converted to tokensaccording to the level of each NFT. Here is the google sheet with all transactions where usersburnt their Flash Beast NFT and according to the level of NFT they received corresponding amounts of FAF tokens 80% i.e. 800,000,000 was allocated for community out of which 78.8% was allocated for beast NFT holders and 1.2% was given to active discord members who helped the community in various forms and the airdrop was done through squads. Below are the 2 batch send trxs which sent 1.2% of the tokens to 28 wallets. Google sheet of all the trxs along with recipient address and FAF amount is attached here 1st tranch trx link here 2nd tranch trx link here
Transactions & Market Structures
Market Maker Agreements & Deals
- (a) Market maker’s name — the market maker’s name;
- (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
- (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
- (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
We don't have any such deals with any market maker or individual.
CEX / DEX Agreements & Deals
- (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
- (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
- (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
- (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership. If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
No agreements as such with any CEX or DEX.
Financial Disclosures & Risks
Prior Token Sales & Fundraising
- (a) Series Name
- (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
- (c) Date of sale (at least month & year).
- (d) Number of tokens sold (or % of total supply)
- (e) Vesting schedule
- If no prior sales occurred, state that explicitly (e.g., “No prior fundraising, OTC, or discounted MM sales have occurred.”)
No prior fundraising activity, OTC or discounted MM sales have occurred.
Previous Exploits Affecting The Project
- (a) Date & component affected — date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected;
- (b) Exploit vector summary — plain-language summary of the exploit vector (what the hack was);
- (c) Quantified impact — quantified impact (assets/tokens affected or a clear “no loss of funds” statement);
- (d) Remediation/response taken — remediation/response taken (patches, upgrades, governance actions, compensation);
- (e) Current status — current status (resolved, in litigation, under investigation, refunded, etc.);
- (f) References (optional) — references (optional): link(s) to post-mortem/advisory/PR.
- If no prior incidents, state this explicitly (e.g., “No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD”).
No exploits affecting the native token.
Material Risk Factors (Regulation, Technology, Token Economics)
A. Regulatory, Legal & Tax Risks
Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
- Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
- Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
- Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
- Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
Impact of Regulatory Change on TGE and Listings Not applicable Entity-Level Regulatory Impact Regulatory changes might force the current entity to change the jurisdiction of its foundation to safeguard the rights of the DAO that owns the exchange and has full rights to FLASH.TRADE's domain, codebase, and IP. Tokenholder Tax Treatment According to the terms and conditions of Flash.trade, individuals are responsible for filing taxes according to their own jurisdiction's requirements, while the exchange, being fully onchain, can be audited in any way needed to obtain details for tax filing purposes. Jurisdictional & User Access Restrictions We restrict users from the US, UAE, and sanctioned countries, and have clear terms and conditions covering this.
B. Protocol, Technology & Security Risks
Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
- Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
- Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
Bugs and Design Flaws The protocol depends on external oracles (Pyth Pro) for its core pricing engine and any misconfiguration either internal or external can potentially cause direct loss of funds. Security Measures & Their Limitations We have had one economic and two separate code audits along with ongoing efforts to build anintegrated formal verification system that continuously updates based on changing market and protocol dynamics. These systems can’t fully detect or prevent oracle manipulation attacks that are beyond the protocols control.
C. Token Economics, Unlocks & Incentive Risks
Describe how the token’s economic design and supply schedule could affect holders by answering, at a minimum, questions like:
- Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
- Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
Critical Economic Assumptions Token's utility is heavily tied around revenue generation of the exchange and if the exchange does not make money it will affect the structure of staking tokens to get revenue share. Governance Control over Monetary Policy & Rewards The governance proposal can only be put up by core team and every proposal that is put up can affect the monetary policy or any future reward allocation that would require minting of new tokens which can only happen if a proposal is put and it passes. Disclaimer: This Token Transparency Filing is prepared by FlashTrade and is provided for general informational purposes only. Blockworks makes no representations or warranties, express or implied, regarding the accuracy, completeness, or timeliness of the information provided (including any external links to third-party content), and Blockworks is not liable for any errors or omissions in the content or for any actions taken in reliance on this content.
This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Flash Trade is solely responsible for the content, accuracy, and legality of its disclosures.