# B1 v1.3 Token Transparency Template Framework: B1 TTF version: 1.3 ## Project & Team ### 1. Description of Project Instructions: Provide a concise narrative that clearly states each of (a)–(e) below. Scoring criteria: 0 — The answer is blank, nonresponsive, only repeats the prompt, or fails to cover two or more of (a)–(e). 4.5 — The answer covers exactly four of the five required items and is missing exactly one of (a)–(e). 5 — The answer explicitly covers all of (a)–(e). Maximum score: 5 **Answer** #### (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. ### 2. Known 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. Scoring criteria: Allowed scores are 0, 1, and 3 only. 0 — Fail if any of the following is true for the answer text, ignoring links: (a) No existing entity lists any key team member by full name; or (b) The roster is provided only via external links, with no names, titles, or prior experience in the answer text; or (c) The answer is blank, non-responsive, or only repeats the question/instructions; or (d) The answer references entities but does not provide any substantive team-member disclosure for any entity. 1 — Partial disclosure if all of the following are true: (a) At least one existing entity lists at least one key team member in the answer text; and (b) At least one listed key team member includes the required elements: full name, official title, and prior experience; and (c) The answer does not satisfy the 3-point standard because one or more existing entities are missing key team members, missing required elements, or only state that no public data was found. 3 — Complete disclosure ONLY if all of the following are true in the answer text: (a) For every existing entity, at least one key team member is listed with full name, official title, and prior experience; and (b) For every non-existent entity, the answer explicitly states that the entity does not exist; and (c) The roster appears in the answer text, not only through external links. Important: "No public data found" does not count as listing a key team member and does not count as saying the entity does not exist. If one entity has a complete key team member disclosure but other existing entities have no names or only say "No public data found," assign 1, not 0 or 3. Maximum score: 3 **Answer** #### Labs / DevCo | Full Name | Official Title | Prior Experience | | --- | --- | --- | | | | | #### Foundation | Full Name | Official Title | Prior Experience | | --- | --- | --- | | | | | #### DAO / Onchain Governance | Full Name | Official Title | Prior Experience | | --- | --- | --- | | | | | ### 3. DAO Structure 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. Even if there is no DAO, there must be an answer to (d). Scoring criteria: 5.0 — Complete: Covers all applicable core items: (a), (b), (d), and (e). Includes (c) if locking/staking exists; acceptable to omit (c) if no locking/staking mechanism exists. Edge condition: If the answer explicitly states that there is no DAO, then (a), (b), and (e) are not applicable, but (d) must still be answered to receive full points. 4.0 — Partial: Missing exactly one applicable core item (i.e., covers all applicable core items except one). Edge condition: If the answer explicitly states that there is no DAO but does not answer (d), award 4.0. 0 — Insufficient: Missing two or more applicable core items, leaves governance powers/economic rights/dissolution authority indeterminate where applicable, or is blank/nonresponsive. Maximum score: 5 **Answer** #### (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). ### 4. Primary Foundation 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. 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. Scoring criteria: Be strict with the score here. 2.5 — For each entity: either (i) explicitly states the entity does not exist, or (ii) if it exists, all six core items (a)–(f) are clearly present. 0.5 — has four or five of the core items but is missing one or more items; any non-existence may be implied/ambiguous rather than explicit. 0 — silent on whether it exists, or (if it exists) <4 core items are present, or facts are indeterminate. If something says - No public data found in cited sources - or something close to that -then that answer for that subquestion is considered empty. Maximum score: 2.5 **Answer** #### (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. ### 5. Primary Dev Co 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. 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. Scoring criteria: Be strict with the score here. 2.5 — For each entity: either (i) explicitly states the entity does not exist, or (ii) if it exists, all six core items (a)–(f) are clearly present. 0.5 — If the entity exists, four or five of the six core items are clearly present, but one or more required items are missing. 0 — Silent on whether it exists, non-existence is implied or ambiguous rather than explicit, or (if it exists) fewer than four core items are present, or facts are indeterminate. If something says "No public data found in cited sources" or something close to that, then that answer for that subquestion is considered empty. Maximum score: 2.5 **Answer** #### (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. ## Token Supply & Allocations ### 6. Initial Allocation Scoring criteria: 0 — No initial allocation schedule is provided. 3.5 — An initial allocation schedule is provided but at least one required item from (a)–(f) is missing or ambiguous. 4 — A complete initial allocation schedule is provided and all items (a)–(f) are present. Maximum score: 4 **Answer** | Ticker | Date | Allocation Category Name | Recipient Type | Allocation % | Allocation Tokens | TGE Unlock % | TGE Unlock Tokens | Cliff Months | Cliff Unlock % | Linear Vesting Months | Cadence Months | Circulating Treatment | Notes on what each category is used for | If applicable: Contract / Wallet address | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | | | | | | | | | | | | | | | | ### 7. Airdrop Process Instructions: Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly. Scoring criteria: 0 — Opaque / Not disclosed. Award 0 if the answer is blank, nonresponsive, only repeats the prompt, is vague or arbitrary, does not explicitly state whether an airdrop exists/planned/does not exist, or provides only an explorer/contract link for an executed airdrop without substantive segment and allocation-method disclosure. "No airdrop" must be explicit; otherwise 0. 1 — Minimal disclosure. Award 1 if a planned-only airdrop discloses segments and allocation method but does not clearly commit to publish the per-address recipient list. Award 1 if an executed airdrop identifies that an airdrop occurred but provides only minimal detail and no valid per-address source. 2.5 — Partial / Weak. Award 2.5 if an executed airdrop provides substantive segments and allocation method but lacks a valid per-address source, or if a planned airdrop provides a clear recipient-list publication commitment but is missing either segments or allocation method. 3 — Fully Disclosed (or Explicitly N/A). States both segments and method, and for executed airdrops provides at least one per-address source (CSV/TSV/JSON, Dune table, Merkle dump, repo file with allocations, or RPC exposing amounts). "Repo/RPC contains per-address data" is acceptable. Alternatively, an explicit "no airdrop ever" earns 3. Planned-only earns 3 if segments + method are disclosed and there is a commitment to publish the per-address list, and (when applicable) the quarterly public + Blockworks recipient-list commitment until initial TGE airdrop completion is stated. Maximum score: 3 **Answer** #### (a) Planned but not yet executed airdrop If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, 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). #### (b) Executed airdrop If the project has already airdropped, point to a 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 do not count. Additionally, 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). #### (c) No airdrop planned or conducted If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one"). ## Transactions & Market Structures ### 8. Market Maker Agreements & Deals 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. Scoring criteria: 2.5 — Fully answered (≈100%): Award 2.5 if either the answer explicitly states there are no market-making agreements (cash/fiat retainers alone don't count as agreements) or for every named market maker, all required elements are clearly provided: (a) market maker's name, (b) token allocation or loaned amount as % of total supply (accept absolute token counts if % is computable or clearly implied), (c) duration/term (accept "open-ended," "month-to-month," or "until terminated on X conditions"), and (d) name of agreement structure (the financial vehicle used, e.g., loan, option/call, retainer model). 1.0 — >90% but <100% complete: Award 1.0 if agreements exist and the disclosure is nearly complete: all market makers are named and (a)–(d) are complete for ≥90% of named market makers, with only minor gaps (e.g., one agreement missing a term, a structure label, or a % that is otherwise deducible from a provided token count). 0.5 — >25% but <90% complete: Award 0.5 when there is some substantive detail but notable gaps: at least one market maker is named and one or more of (a)–(d) are missing for >10% of named market makers or the answer is ambiguous about whether token loans exist (no explicit "no token loans" and no terms). 0 — Insufficient / ambiguous: Award 0 if agreements exist but no market maker is named, or for any named market maker two or more of (a)–(d) are missing, or the disclosure is too ambiguous to determine whether market-making agreements or token loans exist, or the response ignores the prompt. Maximum score: 2.5 **Answer** | Market Maker Name | Token Allocation Committed | Term Duration | Structure Name | | --- | --- | --- | --- | | | | | | ### 9. CEX / DEX Agreements & Deals 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; cash/fiat fee amounts are not required for this item. Scoring criteria: 2.5 — Fully answered (~100%): Award 2.5 if either the answer explicitly states there are no agreements or deals with CEX/DEX, or for every listing/partnership all required elements are provided: (a) exchange name (and DEX pair/pool), (b) token allocation supplied or committed as % of total supply (accept token count if % is clearly computable), (c) duration/term of any lockups, liquidity, or incentive programs (accept "open-ended," "month-to-month," or "until terminated on X conditions"), (d) native-token listing fee details when applicable: amount (tokens or % of supply), recipient, and any vesting/lock terms (or a clear "N/A / none" if not applicable). "Organic trading only, no incentives or locks" is valid if the exchange/pair is named and (b)–(c) are clearly N/A. 1.0 — >90% but <100% complete: Award 1.0 if all exchanges/pairs are named and ≥90% of listings have complete (a)–(d); any remaining gap is minor. (d) is present wherever native-token fees exist, with at most a minor omission. 0.5 — >25% but <90% complete: Award 0.5 if at least one exchange/pair is named but there are notable gaps: >10% of listings are missing any of (a)–(c), or native-token fees exist but (d) is missing or vague, or silence on native-token fees leaves applicability unclear. 0 — Insufficient / ambiguous: Award 0 if listings/partnerships exist but no exchange is named, or for any named listing two or more of (a)–(c) are missing, or disclosure is too ambiguous to determine whether CEX/DEX listings or deals exist, or the prompt is ignored. Maximum score: 2.5 **Answer** | Exchange Name | Token Allocation Committed | Term Duration | Native Token Listing Fees | | --- | --- | --- | --- | | | | | | ## Financial Disclosures & Risks ### 10. Prior Token Sales & Fundraising 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."). Scoring criteria: 0 — No prior sales are disclosed and no explicit "no prior sales" statement is provided. 1 — Some prior sales are listed (or an explicit "no prior sales" statement is given), but at least one required field from (a)–(e) is missing for one or more sales, or other prior sales are missing. 2 — All prior sales (if any) are listed and each includes all required fields: (a) Series Name, (b) Early-Stage Investment Instrument used, (c) Date of sale (at least month & year), (d) Number of tokens sold or % of total supply, and (e) Vesting schedule. Alternatively, an explicit "no prior sales" statement is provided. Maximum score: 2 **Answer** | Series Name | Investment Vehicle | Date Of Sale | Number of tokens sold | Vesting Schedule | | --- | --- | --- | --- | --- | | | | | | | ### 11. Previous Exploits Affecting The Native Token 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. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD"). Scoring criteria: 0 — Omits incidents despite history or provides only vague statements without covering at least (b) and (d) for each listed incident and does not explicitly state "no prior incidents" if none. 2.5 — Provides incidents, but for one or more incidents is missing any of (a), (b), (c), (d), or (e); links (f) may be absent without penalty. 5 — For each incident, includes (a)–(e) (links (f) optional); or explicitly states "no prior incidents" with a date reference. Maximum score: 5 **Answer** #### (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) Link(s) to post-mortem/advisory/PR. ### 12. Material Risk Factors (Regulation, Technology, Token Economics) Instructions: Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum. Scoring criteria: 3 -- if the response provides a substantive answer to at least one applicable risk area. A response counts as substantive if it directly answers the prompt or identifies specific regulatory, legal, tax, technology, security, token economics, unlock, or incentive risks. The project does not need to answer every listed risk prompt if certain risks do not apply, but it must provide at least one responsive risk disclosure. 0 -- No substantive risk disclosure is provided. Award 0 if the section is blank, contains only the section header, repeats the prompt, uses placeholders such as “TBD,” or otherwise fails to identify any applicable risk. Maximum score: 3 **Answer** #### (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? #### (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? #### (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?