# B1 v1.4 Token Transparency Template Framework: B1 TTF version: 1.4 ## Project & Team ### 1. Description of Project Instructions: Provide a concise narrative that clearly states each of (a)–(e) below. Scoring criteria: q1a: Incomplete — Blank, nonresponsive, only repeats the prompt, or describes the project generically without identifying any problem it solves. Partial — Identifies a problem but doesn't explain how the project solves it. Complete — Clearly states the specific problem and how the project solves it., q1b: Incomplete — Blank, nonresponsive, only repeats the prompt, or says nothing about how development and operations will be supported over time. Partial — Gestures at ongoing support without identifying who is responsible for ongoing development/operations or vice versa. Complete — Describes at a high level how ongoing development and operations are expected to be supported, naming the funding source(s) and the party or parties responsible., q1c: Incomplete — Blank, nonresponsive, only repeats the prompt, or gives only a category label (e.g., "an L2") with no explanation of how the project works. Partial — Gives an overly technical overview that is not high-level. Complete — Explains at a high level how the project works., q1d: Incomplete — Blank, nonresponsive, only repeats the prompt, or asserts the token has utility without naming any function. Partial — Names a token function but only in general terms (e.g., "used for governance") without explaining what the function does. Complete — Explicitly states the primary function(s) of the token and what each function enables., q1e: Incomplete — Blank, nonresponsive, only repeats the prompt, or is silent on the governance/control model and whether any evolution is anticipated. Partial — Mentions the governance/control model but leaves out the nature of the expected evolution or vice versa. Complete — Describes the governance/control model the protocol currently relies on and the anticipated or possible evolution of the governance/control model, or explicitly states that no evolution is anticipated. **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: Incomplete — 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 provides no substantive team-member disclosure for any entity. Partial — 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 two of three elements; and (c) the answer does not meet the Complete standard because one or more existing entities are missing key team members, or missing required elements. Complete — 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. **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 for each sub question. Even if there is no DAO, there must be an answer to (d). Address the lettered items below. Scoring criteria: q3a: Incomplete — Blank, nonresponsive, only repeats the prompt, or leaves it indeterminate whether the DAO owns or controls any IP. Partial — States generally that the DAO owns or controls IP without identifying what IP (e.g., specific codebases/repos, trademarks/brands), or names IP but leaves ownership versus licensing ambiguous. Complete — Identifies the IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands), noting any relevant license, or explicitly states the DAO owns/controls no IP. An explicit statement that no DAO exists is Complete., q3b: Incomplete — Blank, nonresponsive, only repeats the prompt, or leaves on-chain/administrative authorities indeterminate. Partial — Lists some authorities (e.g., pause/upgrade roles, governance executor) but omits the method of authority or threshold for one or more of them, or names holders without the powers they carry. Complete — Lists the on-chain and administrative authorities and their limits (pause/upgrade roles, governance-executor authorities), with the method of authority for each (e.g., veto, majority, super-majority), or explicitly states no such authorities exist. An explicit statement that no DAO exists is Complete., q3c: Incomplete — Claims locking/staking for additional rights exists but leaves the additional rights indeterminate, or is blank/nonresponsive where a locking mechanism is known to exist. Partial — States that locking/staking confers additional rights and names them generally, but does not explain what locked tokenholders can and cannot decide. Complete — Explains the additional rights conferred by locking/staking and what tokenholders can and cannot decide, or the field is absent/explicitly marked not applicable because no locking mechanism exists. This sub-question is conditional: if no locking/staking mechanism exists, it is Complete., q3d: Incomplete — Blank, nonresponsive, only repeats the prompt, or leaves the current governance rights and economic arrangements of tokenholders indeterminate. This sub-question must be answered even if no DAO exists, so silence or "no DAO" alone is Incomplete. Partial — Addresses either governance rights or the economic arrangements (treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources) but not both, or describes them only in general terms without stating what tokenholders can presently direct, claim, or decide. Complete — Describes the current governance rights of tokenholders and any presently operative rights or arrangements over treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources, or explicitly states that no such rights or arrangements exist. Required even where no DAO exists, so "no DAO" alone is not Complete here., q3e: Incomplete — Blank, nonresponsive, only repeats the prompt, or is silent on whether any evolution of the governance/control model is anticipated. Partial — Indicates the governance/control model may evolve but does not describe the nature of the anticipated or possible evolution, or describes an evolution without tying it to the governance/control model. Complete — Briefly describes the anticipated or possible evolution of the protocol's governance/control model, or explicitly states that no evolution is anticipated. An explicit statement that no DAO exists is Complete., q3f: Incomplete — Blank, nonresponsive, only repeats the prompt, or leaves dissolution/wind-up authority indeterminate. Partial — Identifies who can dissolve or wind up the DAO but does not state the mechanism, or states a mechanism without identifying the authority that can invoke it. Complete — States who can dissolve or wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper), or explicitly states that no dissolution authority or mechanism exists. An explicit statement that no DAO exists is Complete. **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) Current tokenholder governance rights and economic arrangements If any, describe the current governance rights of tokenholders and any presently operative rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. If none, state that explicitly. #### (e) Control surface reliance If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model. #### (f) 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 a Foundation does not exist, state so for each sub question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. **Definition:** The primary Foundation can be explained as the entity which is directly involved in the issuance of the native token at launch. Scoring criteria: q4a: Incomplete — Blank, nonresponsive, or silent on whether the Foundation exists; non-existence is implied or ambiguous rather than explicit; or the entity type and jurisdiction are both missing or indeterminate. Partial — Identifies the Foundation but gives only the entity type or only the jurisdiction, not both, or names a jurisdiction without the entity type (e.g., "a Swiss entity"). Complete — States the Foundation's entity type and jurisdiction (e.g., "Cayman Islands foundation company"), or explicitly states that the Foundation does not exist., q4b: Incomplete — Blank, nonresponsive, or leaves the Foundation's IP ownership/control indeterminate. Partial — States generally that the entity owns or controls IP without identifying what IP (repos/code, trademarks/brand) Complete — Identifies what IP the Foundation owns or controls (repos/code, trademarks/brand; license optional), or explicitly states there is no such IP. An explicit statement that the Foundation does not exist is Complete., q4c: Incomplete — Blank, nonresponsive, or leaves the Foundation's powers over DAO governance, treasury, protocol-controlled resources, or token administration indeterminate. Partial — Describes one or more powers but omits the method or threshold for exercising them. Complete — Describes the Foundation's current powers with the method/threshold for each, or explicitly states that it holds no such powers. An explicit statement that the Foundation does not exist is Complete., q4d: Incomplete — Blank, nonresponsive, or leaves it indeterminate whether the Foundation can influence the DevCo's decision-making. Partial — Asserts that the Foundation does have influence over the DevCo but does not explain the basis (e.g., shared control, contractual rights, board or ownership overlap). Complete — Explains whether the Foundation can exert influence over the DevCo's decision-making and, if it can exert influence, then also explains the basis for it (e.g., ownership, board seats, contracts, funding); or explicitly states that no such influence exists. An explicit statement that the Foundation or the DevCo does not exist is Complete., q4e: Incomplete — Blank, nonresponsive, or leaves pause/upgrade/governance-executor authorities indeterminate. Partial — Names one or more contract/admin authorities but omits the method or threshold for one or more of them (e.g., says "a multisig can pause" without the method of authority e.g. super majority). Complete — States the Foundation's pause, upgrade, and governance-executor authorities with the method for each (e.g., veto/majority/super-majority), or explicitly states that it holds no contract or admin powers. An explicit statement that the Foundation does not exist is Complete., q4f: Incomplete — Blank, nonresponsive, silent on whether any such mechanism exists. Partial — Acknowledges that mechanisms exist without identifying the mechanism and what resources flow to whom. Complete — Describes the current governance-approved, contractual, or programmatic mechanisms by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to the Foundation, its equityholders, contributors, or other participants, or explicitly states that no such mechanism currently exists. An explicit statement that the Foundation does not exist is Complete. **Answer** #### (a) Entity Type and jurisdiction. #### (b) IP ownership & control What IP the entity owns/controls (repos/code, trademarks/brand; license optional) #### (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). #### (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. ### 5. Primary DevCo Instructions: For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly across each sub-question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. **Definition:** The primary DevCo can be explained as the entity which is directly involved in the issuance of the native token at launch. Scoring criteria: q5a: Incomplete — Blank, nonresponsive, or silent on whether the DevCo exists; non-existence is implied or ambiguous rather than explicit; or the entity type and jurisdiction are both missing or indeterminate. Partial — Identifies the DevCo but gives only the entity type or only the jurisdiction, not both, or names a jurisdiction without the entity type (e.g., "a Swiss entity"). Complete — States the DevCo's entity type and jurisdiction (e.g., "Cayman Islands foundation company"), or explicitly states that the DevCo does not exist. The DevCo is a synonym for developer company and/or labs., q5b: Incomplete — Blank, nonresponsive, or leaves the DevCo's IP ownership/control indeterminate. Partial — States generally that the entity owns or controls IP without identifying what IP (repos/code, trademarks/brand) Complete — Identifies what IP the DevCo owns or controls (repos/code, trademarks/brand; license optional), or explicitly states there is no such IP. An explicit statement that the DevCo does not exist is Complete. The DevCo is a synonym for developer company and/or labs., q5c: Incomplete — Blank, nonresponsive, or leaves the DevCo's powers over DAO governance, treasury, protocol-controlled resources, or token administration indeterminate. Treat "No public data found in cited sources" or any close equivalent as an empty answer. Partial — Describes one or more powers but omits the method or threshold for exercising them, or addresses only some of the applicable areas (DAO governance, treasury actions, protocol-controlled resources, token administration, reward parameters) while leaving others unaddressed. Complete — Describes the DevCo's current powers over DAO governance, treasury actions, protocol-controlled resources (e.g., revenue), token administration, and reward parameters, with the method/threshold for each, or explicitly states that it holds no such powers. An explicit statement that the DevCo does not exist is Complete. The DevCo is a synonym for developer company and/or labs., q5d: Incomplete — Blank, nonresponsive, or leaves it indeterminate whether the DevCo can influence the Foundation's decision-making. Treat "No public data found in cited sources" or any close equivalent as an empty answer. Partial — Asserts that the DevCo does or does not influence the Foundation but does not explain the basis (e.g., shared control, contractual rights, board or ownership overlap), or addresses direct influence while ignoring indirect influence. Complete — Explains whether the DevCo can exert direct or indirect influence over the Foundation's decision-making and the basis for it (e.g., ownership, board seats, contracts, funding), or explicitly states that no such influence exists. An explicit statement that the DevCo or the Foundation does not exist is Complete. The DevCo is a synonym for developer company and/or labs., q5e: Incomplete — Blank, nonresponsive, or leaves pause/upgrade/governance-executor authorities indeterminate. Treat "No public data found in cited sources" or any close equivalent as an empty answer. Partial — Names one or more contract/admin authorities but omits the method or threshold for one or more of them (e.g., says "a multisig can pause" without the signer threshold). Complete — States the DevCo's pause, upgrade, and governance-executor authorities with the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig"), or explicitly states that it holds no contract or admin powers. An explicit statement that the DevCo does not exist is Complete. The DevCo is a synonym for developer company and/or labs., q5f: Incomplete — Blank, nonresponsive, silent on whether any such mechanism exists, or discusses only hypothetical future distributions that have not been formally adopted. Treat "No public data found in cited sources" or any close equivalent as an empty answer. Partial — Acknowledges that mechanisms exist but describes them only in general terms, without identifying the mechanism and what resources flow to whom, or leaves it ambiguous whether a stated mechanism is currently in force. Complete — Describes the current governance-approved, contractual, or programmatic mechanisms by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to the DevCo, its equityholders, contributors, or other participants, or explicitly states that no such mechanism currently exists. An explicit statement that the DevCo does not exist is Complete. The DevCo is a synonym for developer company and/or labs. **Answer** #### (a) Entity Type and jurisdiction. #### (b) IP ownership & control What IP the entity owns/controls (repos/code, trademarks/brand; license optional) #### (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: Incomplete — No initial allocation schedule is provided. Partial — An initial allocation schedule is provided but at least one required item from Mandatory items (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) is missing or ambiguous. Complete — A complete initial allocation schedule is provided and all Mandatory items (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) are present while these are optional (Notes on what each category is used for, If applicable: Contract / Wallet address). **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: State the project's airdrop status plainly, and back it up: - **Never conducted and none planned for TGE:** state so plainly. - **Planned but not yet executed:** state the target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to balance or net position), and commit to publishing a recipient wallet list in a public channel and providing it to Blockworks quarterly until the initial TGE airdrop is fully completed. - **Already executed:** state the covered user segments and the allocation method, and 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. Scoring criteria: Incomplete — Blank, nonresponsive, only repeats the prompt, or leaves the airdrop status ambiguous: status must be explicit, and an implied or inferred absence does not count. Where an airdrop has been conducted or is planned, also Incomplete if it discloses neither target user segments nor allocation method, or if an executed airdrop is identified with only minimal detail and no valid per-address source — an explorer or contract link alone does not count. Partial — States only half the status (e.g., that none is planned, without addressing whether one has ever been conducted, or the reverse), leaving the rest indeterminate. Or, where an airdrop has been conducted or is planned, discloses substantive segments and allocation method but does not meet the status-specific evidence requirement (for a planned airdrop, no clear commitment to publish the recipient wallet list; for an executed airdrop, no valid per-address source), or meets that evidence requirement but is missing either the segments or the allocation method. Complete — Satisfies whichever applies: (a) plainly states that the project has never conducted an airdrop and does not plan to execute one for TGE; (b) for a planned airdrop, states the target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position), and commits to publishing the recipient wallet list in a public channel and providing it to Blockworks quarterly until the initial TGE airdrop is fully completed; (c) for an executed airdrop, states the covered segments and allocation method and points to at least one per-address source — CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints exposing claim/amount data ("Repo/RPC contains per-address data" is acceptable). Where an airdrop has been executed and another is planned, both are addressed. **Answer** ## 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. 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). If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for (b). Scoring criteria: Incomplete — Agreements exist but no market maker is named or the disclosure is too ambiguous to determine whether market-making agreements or token loans exist, or the response ignores the prompt. Partial — At least one market maker is named and there is substantive detail, but the disclosure falls short of complete — ranging from minor gaps (one agreement missing a term, a structure label, or an allocation) to notable gaps (one or more of (a)–(d) missing for a meaningful share of named market makers, or ambiguity about whether token loans exist, with no explicit "no token loans" and no terms). Complete — Either the answer explicitly states there are no market-making 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), (c) duration/term (accept "open-ended," "month-to-month,", "none", or "until terminated on X conditions"), and (d) name of agreement structure (the financial vehicle used, e.g., loan, option/call, retainer model). **Answer** | Market Maker Name | Token Allocation Committed | Term Duration | Structure Name | | --- | --- | --- | --- | | | | | | ### 9. Exchange 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: Incomplete — 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. Partial — At least one exchange/pair is named and there is substantive detail, but the disclosure falls short of complete — ranging from minor gaps (nearly all listings have complete (a)–(d), with at most a minor omission where native-token fees exist) to notable gaps (a meaningful share of listings 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). Complete — 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. **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: Incomplete — No prior sales are disclosed and no explicit "no prior sales" statement is provided. Partial — Some prior sales are listed but at least one required field from (a)–(e) is missing for one or more sales, or other prior sales are missing. Complete — 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. **Answer** | Series Name | Investment Instrument | 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: q11a: Incomplete — Blank, nonresponsive, or omits the date and the affected chain(s)/component for one or more listed incidents, or omits incidents despite a known history. A "no incidents" statement that is not explicit or carries no date reference is Incomplete. Partial — For one or more incidents, provides either the date or the affected chain(s)/component but not both, or gives a date at lower precision than YYYY-MM. Complete — For each incident, gives the date (YYYY-MM or YYYY-MM-DD) and the chain(s)/component affected. An explicit statement that there are no prior incidents affecting the native token, with a date reference (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD"), is Complete., q11b: Incomplete — Blank, nonresponsive, or leaves the exploit vector indeterminate for one or more incidents (e.g., "funds were lost" with no explanation of how). Partial — Summarizes the vector only in broad category terms (e.g., "a contract bug," "a key compromise") without explaining what actually happened. Complete — For each incident, gives a plain-language summary of the exploit vector that explains what the hack was and how it worked. An explicit statement that there are no prior incidents affecting the native token, with a date reference (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD"), is Complete., q11c: Incomplete — Blank, nonresponsive, or leaves the impact unquantified for one or more incidents, with no clear "no loss of funds" statement. Partial — Indicates impact directionally (e.g., "a small amount was drained," "limited impact") without a figure in assets/tokens or a clear no-loss statement. Complete — For each incident, quantifies impact in assets/tokens affected, or makes a clear "no loss of funds" statement. An explicit statement that there are no prior incidents affecting the native token, with a date reference (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD"), is Complete., q11d: Incomplete — Blank, nonresponsive, or silent on what was done in response to one or more incidents. Partial — States that a response occurred (e.g., "the issue was fixed," "the team responded") without identifying the specific patches, upgrades, governance actions, or compensation. Complete — For each incident, describes the remediation/response taken (patches, upgrades, governance actions, compensation), or explicitly states that no remediation was undertaken. An explicit statement that there are no prior incidents affecting the native token, with a date reference (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD"), is Complete., q11e: Incomplete — Blank, nonresponsive, or leaves the current status of one or more incidents indeterminate. Partial — Implies a status without stating it (e.g., describes a patch shipping but never says whether the matter is resolved, under investigation, or in litigation). Complete — For each incident, states the current status (resolved, in litigation, under investigation, refunded, etc.). An explicit statement that there are no prior incidents affecting the native token, with a date reference (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD"), is Complete., q11f: Incomplete — Provides links that are broken, unrelated, or do not point to a post-mortem, advisory, or PR for a listed incident. Partial — Provides a reference for some listed incidents but not others where post-mortems, advisories, or PRs are known to exist. Complete — Provides link(s) to a post-mortem, advisory, or PR for each incident, or no links are provided. This sub-question is optional: absence of links is Complete and is never penalized. An explicit statement that there are no prior incidents affecting the native token, with a date reference (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD"), is Complete. **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 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: q12a: Incomplete — No substantive disclosure. Blank, contains only the category header, repeats the prompt, uses placeholders such as "TBD," or otherwise identifies no applicable regulatory, legal, or tax risk. Partial — Gestures at regulatory, legal, or tax risk in generic terms that could apply to any project (e.g., "regulation is uncertain") without identifying a specific risk or how it could affect the project. Complete — Provides a substantive answer to at least one applicable risk area in this category — identifying specific regulatory, legal, or tax risks (e.g., impact of regulatory change on TGE and listings, entity-level regulatory impact, tokenholder tax treatment, jurisdictional or user access restrictions). Not every listed prompt must be answered if certain risks do not apply., q12b: Incomplete — No substantive disclosure. Blank, contains only the category header, repeats the prompt, uses placeholders such as "TBD," or otherwise identifies no applicable protocol, technology, or security risk. Partial — Gestures at technology or security risk in generic terms (e.g., "smart contracts carry risk," "we have been audited") without identifying a specific risk or the limits of the measures taken. Complete — Provides a substantive answer to at least one applicable risk area in this category — identifying specific technology or security risks (e.g., bugs or design flaws in core code, contracts, bridges, rollups, or oracles and how they could cause loss of funds or disruption; security measures taken and what those measures might still fail to detect or prevent). Not every listed prompt must be answered if certain risks do not apply., q12c: Incomplete — No substantive disclosure. Blank, contains only the category header, repeats the prompt, uses placeholders such as "TBD," or otherwise identifies no applicable token economics, unlock, or incentive risk. Partial — Gestures at token economics or unlock risk in generic terms (e.g., "token price may be volatile," "unlocks may create sell pressure") without tying it to a specific assumption, parameter, or governance power of this project. Complete — Provides a substantive answer to at least one applicable risk area in this category — identifying specific token economics, unlock, or incentive risks (e.g., critical economic assumptions such as staking yields, fee revenue, liquidity incentives, MEV capture, or blockspace demand and what happens if they fail; governance control over monetary policy, fee parameters, or reward allocations and how changes could adversely affect tokenholders). Not every listed prompt must be answered if certain risks do not apply. **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?