# NASDAFUQ: full context for your agent Updated September 17, 2026. This brief is self-contained so you can paste it into a new conversation. ## Start the conversation Use the context below to explain NASDAFUQ naturally: what the community is about, why the name contains the basket, and how holding relates to asset distributions. Start with a short, clear explanation, then follow my questions. You can go deeper into the culture, token mechanism, contracts or receipts as needed. Keep the product design distinct from its current deployment status and describe any sources you haven't opened as project-provided information. ## The coin and the community NASDAFUQ combines memecoin culture with a stock-market basket mechanism. Its identity is loud anime, rave music, late-night internet energy and a cursed Windows-95 trading terminal. Community is central: a shared name, shared culture and a mechanism holders can understand together. The stock-market connection gives the meme its structure. A share of the coin's trading fees enters a vault, buys a fixed basket of assets, and is distributed directly to eligible holders according to their balances. There is no holder claim step. The intended asset category is **Stock Tokens & Tokenized ETFs**. “Buy NASDAFUQ. Get the Nasdaq.” and “100% fees to holders” are the marketing shorthand. The first points to the basket, especially QQQ; it doesn't mean NASDAFUQ is the Nasdaq index itself. The second refers to net distributable fees after the published operating reserve and execution costs, as explained below. Neither line replaces the deployment details or the actual accounting. ## The name is the basket The last five letters, D A F U Q, map to the five slots: | Letter | Ticker | Theme | Budget weight | | --- | --- | --- | --- | | D | DELL | Dell, AI servers | 20% | | A | AMD | AI silicon and GPUs | 20% | | F | FLY | Firefly Aerospace, space launch | 20% | | U | USAR | USA Rare Earth, the materials supply chain | 20% | | Q | QQQ | Invesco QQQ, the Nasdaq-100 | 20% | These are equal purchase-budget allocations, not equal token quantities or equal future values. The deployed basket policy fixes the assets and weights. A different basket requires a new deployment; the system doesn't rotate tickers or use AI stock selection. Older project research mentioning DDOG/APLD/FLY/USAR/QUBT describes a superseded basket. ## How one cycle works An *epoch* is a distribution cycle. **Fees accumulate.** Registered trading sources deposit fees into the FeeVault. Fee activity funds the mechanism; the system doesn't manufacture a fixed return for holding. **The cycle closes.** The vault applies its reserve and brings forward unspent quote tokens from earlier cycles: ```text keeper reserve = gross fees × the deployed reserve percentage net purchase budget = gross fees + carried-in quote − keeper reserve allocation per asset = net purchase budget × 20%, rounded down ``` The reserve percentage is fixed at deployment and capped at 20% of gross fees. Accrued reserve can go only to the fixed treasury address. Execution costs and slippage affect the asset quantities bought. “100% fees to holders” means the net distributable amount goes to holders after these deductions, not that gross fees arrive unchanged. Allocation-rounding dust is carried forward. **Holder balances are recorded.** The snapshot tool replays NASDAFUQ transfers through the chain-native block containing the epoch-close event. It computes eligible balances, total eligible balance, a Merkle root and a dataset hash. A Merkle root is a compact fingerprint used to prove that a wallet and balance belong to that snapshot. The keeper publishes the commitment once per cycle. The supplied tooling excludes the zero address and known protocol-contract addresses. **The vault buys.** A permitted route adapter executes purchases of the registered basket assets. Checks cover asset status, reference-price freshness and deviation, available liquidity, minimum acceptable output and a deadline. The keeper can't pass arbitrary purchase assets, recipients or amounts. **The distributor sends.** Available inventory for an asset is what was bought plus inherited inventory. The contract calculates each holder's amount: ```text holder share = eligible snapshot balance ÷ total eligible snapshot balance holder amount = available inventory × holder share, rounded down ``` Proofs bind recipients to the committed snapshot. Batches send assets directly to those wallets. Anyone with valid proofs can submit a batch or retry; normally the operator does this and pays the transaction gas. Holders don't need to connect to the website, sign a claim, stake or pay gas to receive. Snapshot balance determines the share, rather than time held or an equal allocation per wallet. ## Why FLY is bought in sips FLY is the basket's thin-liquidity slot. Large purchases can move their own price, so its route supports spaced, size-capped clips. Before close, *drips* buy within FLY's share of net fees already collected. The contract subtracts the reserve before applying the basket weight; it doesn't budget against forecast fees. After close, further clips can finish the remaining allocation. Every clip still passes the purchase checks. The site calls these purchases “sips, not gulps.” ## Carryover and retries When a purchase can't execute within its checks, its unspent allocation remains in the vault for a later cycle. The system doesn't substitute a different asset. Earlier successful clips remain inventory. A post-trade balance mismatch instead reverts the transaction, leaving the purchase unresolved for intervention or retry. Failed holder transfers are recorded and can be retried. A successful transfer can't be paid twice. After the retry cap, an admin can roll unpaid inventory forward; below-minimum amounts also become later inventory. A rollover is shared under the later cycle's snapshot, not reserved as a personal balance for the original wallet. ## Who runs what The contracts enforce the basket, permitted routes, committed-snapshot membership, distribution amounts and duplicate-payment prevention. The keeper advances cycles and publishes snapshot commitments. Operator availability matters for timing. The snapshot computation is reproducible from public history. Its proof confirms membership in the committed dataset; independent replay checks whether that dataset matches historical holders. The contract doesn't reconstruct token history itself. Admin functions cover pauses, asset status, bounded clip settings, route/oracle changes through the applicable timelock, and restricted reserve/recovery operations. They don't turn the website into a control panel. The site is read-only and cannot move funds. No AI decides the allocations or sends assets. ## Reading the receipts The website formats `data/tracker.json`, a saved index of contract events. It isn't a continuous blockchain connection. Its generation timestamp identifies the record's freshness, and transaction links lead to the corresponding explorer. - **OBSERVED ONCHAIN:** a recorded event, such as a purchase or successful transfer. - **ESTIMATED:** a derived quantity rather than a completed transfer. - **PENDING:** waiting to be bought or sent. - **FAILED:** an unsuccessful transfer attempt. - **ROLLED OVER:** funds or inventory moved into a later cycle. Historical failures can remain visible after retries succeed. Outstanding failed amounts describe what is still unresolved in that index. Missing or malformed data produces an offline state, never demonstration figures presented as observations. ## Current deployment The deployment established by the September 17 records is **Robinhood Chain Testnet, chain ID 46630**. NASDAFUQ, the `mUSDG` quote token, fee source, registered price source, route and reward assets are mocks. `mDELL`, `mAMD`, `mFLY`, `mUSAR` and `mQQQ` have no monetary value and don't represent company or ETF ownership. The published receipts cover two mock distribution cycles, including FLY sips, a QQQ allocation rollover and a failed DELL transfer followed by a successful retry. They aren't evidence of real-asset payouts. This deployment uses a 10% keeper reserve, operator-set mock prices and one disposable wallet for privileged roles. An official mainnet network/address, final supply and allocations, trading-fee share, distribution cadence and launch eligibility aren't established in the supplied records. Real Stock Tokens & Tokenized ETFs depend on issuer access and a resolved distribution structure, including how the revenue-sharing mechanism is characterized. No launch date or real-asset distribution is established. There is no affiliation with Robinhood, Nasdaq, Invesco or the basket companies. ## Sources The repository is [exsulatus/nasdafuq](https://github.com/exsulatus/nasdafuq). `docs/SITE_BRIEF.md` is the current product handoff; the mechanism is detailed in `docs/NASDAFUQ_HANDBOOK.md` and `docs/ARCHITECTURE.md`. `docs/HOLDER_GUIDE.md` is the shorter explanation. The indexed dataset is `data/tracker.json`, and deployment addresses and parameters are in `deployments/robinhood-testnet.json`. Source locators for the deployment described above: - [FeeVault](https://explorer.testnet.chain.robinhood.com/address/0x3650b295e5c8D321E27eF953fC7522db0Fb564F7) - [PushDistributor](https://explorer.testnet.chain.robinhood.com/address/0x12aD71C3Db2ee02Db1262A4EE00E151E7E771089) - Basket version: `0xe854756de2b356ab1ab481b4719ffc2cfa99080851a92c7723cf89c459d7e061` These links identify the documented deployment. When discussing newer activity, read the current sources rather than treating this dated brief as a fresh chain query.