# B1 v1.0 Token Transparency Template Framework: B1 TTF version: 1.0 ## Project & Team ### 1. Description of Project Category: Project & Team Instructions: Provide a concise narrative that clearly states: - (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, **Answer** ### 2. Known Project Team Category: Project & Team Instructions: For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: - (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. Edge note: A compound role (e.g., Founder/CEO) counts as one person with a compound title. **Answer** ### 3. DAO Structure Category: Project & Team Instructions: Provide a structured description of the DAO’s governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Item (c) may be left absent if not applicable. Even if there is no DAO, there must be an answer to (d). - (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). **Answer** ### 4. Primary Foundation Category: Project & Team Instructions: For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn’t exist. - (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. **Answer** ### 5. Primary Dev Co Category: Project & Team Instructions: For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn’t exist. - (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. **Answer** ## Token Supply & Allocations ### 6. Initial Allocation Category: Token Supply & Allocations Instructions: Disclose launch and initial supply details in a single initial allocation schedule covering the token’s launch. Include: - (a) Launch supply totals — the total number of tokens issued at launch, the total number of tokens locked at launch, and 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 — the expected initial price per token; - (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); **Answer** ### 7. Airdrop Process Category: Token Supply & Allocations Instructions: If the project has planned but not yet airdropped, it must: - (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 table, 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”). **Answer** ## Transactions & Market Structures ### 8. Market Maker Agreements & Deals Category: Transactions & Market Structures Instructions: Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table: - (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. **Answer** ### 9. CEX / DEX Agreements & Deals Category: Transactions & Market Structures Instructions: Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table: - (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. If no native-token listing fees were paid, state that explicitly; cash/fiat fee amounts are not required for this item. **Answer** ## Financial Disclosures & Risks ### 10. Prior Token Sales & Fundraising Category: Financial Disclosures & Risks Instructions: Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide: - (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.”) **Answer** ### 11. Previous Exploits Affecting The Project Category: Financial Disclosures & Risks Instructions: If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. For each incident, provide: - (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”). **Answer** ### 12. Material Risk Factors (Regulation, Technology, Token Economics) Category: Financial Disclosures & Risks **Answer**