# B2 v2.2 Token Transparency Template

Framework: B2
TTF version: 2.2

<!-- Complete each Answer section. Do not include private or non-public information. -->

## Project & Team

### 1. Description of Project

Instructions:

Provide a narrative description of the purpose of the project.

Scoring criteria:

Incomplete — No narrative description is provided, the answer only repeats the question, or only a URL is provided with no explanation.
Partial — A narrative is provided but it does not convey what the project actually is. 
Complete — A clear narrative is provided that conveys what the project is and the purpose it serves.

**Answer**

<!-- Add answer here. -->

### 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.

<!-- Add answer here. -->

#### (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).

<!-- Add answer here. -->

#### (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.

<!-- Add answer here. -->

#### (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.

<!-- Add answer here. -->

#### (e) Control surface reliance

If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.

<!-- Add answer here. -->

#### (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).

<!-- Add answer here. -->

### 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 was directly/indirectly involved in the issuance of the native token at launch. If the original Foundation has been dissolved and in its place a "new Foundation" was created, then detail the "new Foundation".

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.

<!-- Add answer here. -->

#### (b) IP ownership & control

What IP the entity owns/controls (repos/code, trademarks/brand; license optional)

<!-- Add answer here. -->

#### (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.

<!-- Add answer here. -->

#### (d) Powers over DevCo

Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.

<!-- Add answer here. -->

#### (e) Contract/admin powers

Pause/upgrade/governance-executor authorities, and the method/threshold for each (e.g., veto/majority/super-majority).

<!-- Add answer here. -->

#### (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.

<!-- Add answer here. -->

### 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 was directly/indirectly involved in the issuance of the native token at launch. If the original DevCo has been dissolved and in its place a "new DevCo" was created, then detail the "new DevCo".

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.

<!-- Add answer here. -->

#### (b) IP ownership & control

What IP the entity owns/controls (repos/code, trademarks/brand; license optional)

<!-- Add answer here. -->

#### (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.

<!-- Add answer here. -->

#### (d) Powers over Foundation

Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.

<!-- Add answer here. -->

#### (e) Contract/admin powers

Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").

<!-- Add answer here. -->

#### (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.

<!-- Add answer here. -->

### 6. Affiliated Protocol Contributor

Instructions:

Definition (for this section): An Affiliated Protocol Contributor (APC) is a non-issuer company - not the protocol's primary Foundation or DevCo - that materially contributes to the protocol's code, operations, governance, or funding. For example, Blockworks Advisory would be considered an APC of Ethena because it materially contributes to its operations through Ethena's risk council.

Provide a structured description per APC. If no APCs exist, state that explicitly across each sub-question. Items below apply per APC.

Scoring criteria:

q6a: Incomplete — Blank, nonresponsive, only repeats the prompt, or silent on whether any APCs exist; or APCs exist but none are identified by legal name.
Partial — Names at least one APC but omits one or more of entity type, jurisdiction, or role for one or more APCs.
Complete — For every APC, gives the legal name, entity type, jurisdiction, and role (e.g., core development, security, infrastructure, market making, operations). An explicit statement that no APCs exist is Complete.,
q6b: Incomplete — Blank, nonresponsive, or leaves it indeterminate whether the APC controls any major protocol parameters.
Partial — Identifies parameters the APC controls but omits the method of authority for one or more of them, or states that control exists without identifying which parameters.
Complete — For every APC, identifies the major protocol parameters it controls together with the method of authority for each (e.g., veto, majority, super-majority), or explicitly states that it controls none. An explicit statement that no APCs exist is Complete.,
q6c: Incomplete — Blank, nonresponsive, or leaves the APC's pause/upgrade/governance-executor authorities indeterminate.
Partial — Names one or more contract/admin powers but omits the method/threshold for one or more of them, or names the powers without their limitations.
Complete — For every APC, states the pause/upgrade powers and governance-executor authorities and their limitations, with the method/threshold for each, or explicitly states that it holds none. An explicit statement that no APCs exist is Complete.,
q6d: Incomplete — Blank, nonresponsive, or silent on whether protocol-generated resources or economic value are routed to the APC, with no explicit statement that none are.
Partial — Acknowledges that an arrangement exists but does not provide details.
Complete — For every APC, describes the resource arrangements that exist, or explicitly states that no protocol resources or resource-linked economics are routed to the APC. An explicit statement that no APCs exist is Complete.

**Answer**

#### (a) Identity & role

Legal name, entity type, jurisdiction, and role (e.g., core development, security, infrastructure, market making, operations).

<!-- Add answer here. -->

#### (b) Parameter control & scope

For each existing APC, if any, what major protocol parameters the APC controls; include the method of authority (e.g., veto, majority, super-majority). If none, say so.

<!-- Add answer here. -->

#### (c) Contract/admin powers

For each existing APC, if any, provide the pause/upgrade powers (e.g., multisig pause), governance-executor authorities and limitations; include the method of authority for each (e.g. veto, majority, super-majority). If none, say so.

<!-- Add answer here. -->

#### (d) Compensation and material economic arrangements

For each existing APC, if protocol-generated resources or economic value is dynamically routed to the APC, describe the arrangement. If applicable, include the resource sources, routing mechanism, payment frequency, and duration. If no protocol resources or resources-linked economics are routed to the APC, state that explicitly.

<!-- Add answer here. -->

## Token Supply & Allocation

### 7. 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 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

### 8. Vesting Insider Tokens

Instructions:

If there are no post-TGE token compensation plans, state explicitly they do not exist across each sub-question. If there are, explain each of (a)–(b) below.

Scoring criteria:

q8a: Incomplete — Blank, nonresponsive, or silent on whether post-TGE token compensation plans exist.
Partial — Gives a locked amount but not as a percentage of total supply, or the figure is stale, hedged, or ambiguous as to what it covers; or plans exist but no locked amount attributable to post-TGE employees is given.
Complete — States the current total tokens locked attributable to post-TGE employees as a percentage of total supply. An explicit statement that no post-TGE token compensation plans exist is Complete.,
q8b: Incomplete — Blank, nonresponsive, or leaves the standard post-TGE vesting terms indeterminate.
Partial — Describes the vesting terms but omits one or more of cliff length (or "no cliff"), vesting frequency, or total duration.
Complete — Describes the standard vesting terms for post-TGE grants including cliff length (or "no cliff"), vesting frequency (e.g., monthly/quarterly), and total duration. An explicit statement that no post-TGE token compensation plans exist is Complete.

**Answer**

#### (a) Post-TGE employee lock as % of total supply

State the current total amount of tokens locked attributable to post-TGE employees, expressed as a percentage of total supply.

<!-- Add answer here. -->

#### (b) Typical post-TGE vesting schedule

Describe the standard vesting terms used for post-TGE grants, including: cliff length (or "no cliff"), vesting frequency (e.g., monthly/quarterly), and total duration.

<!-- Add answer here. -->

### 9. Disclosure of Token Advisory Billings

Instructions:

Disclose current token-based compensation for external advisors and service providers (e.g., legal, marketing, technical, growth) funded from the on-chain treasury. Do not disclose individual payments to advisors receiving fiat-only compensation. If there are no advisors contracted in tokens then state across each sub-question that no token-based advisory compensation exists.

Scoring criteria:

q9a: Incomplete — Blank, nonresponsive, or silent on whether token-based payments to advisors exist; existence is implied or ambiguous rather than stated.
Partial — Addresses the topic but leaves existence partially ambiguous (e.g., describes fiat-only advisory spend without confirming whether any token-based advisory compensation exists).
Complete — States plainly whether any token-based payments or advisory commitments exist, or explicitly states that no token-based compensation for advisory commitments exists.,
q9b: Incomplete — Blank, nonresponsive, or token-based advisory compensation is acknowledged but no total token allocation is given.
Partial — Gives an allocation figure that is incomplete or ambiguous (e.g., is stated as a range or approximation without a clear aggregate).
Complete — Discloses the total token allocation across all advisory services; aggregate figures suffice and advisor-level detail is not required. An explicit statement that no token-based advisory compensation exists is Complete.,
q9c: Incomplete — Blank, nonresponsive, or leaves the payer entity indeterminate.
Partial — Identifies a payer only in general terms (e.g., "the project,") without specifying which entity (i.e. Foundation, Labs/DevCo, DAO/treasury).
Complete — Identifies the payer entity (e.g., Foundation, Labs/DevCo, DAO/treasury) for the token-based advisory compensation. An explicit statement that no token-based advisory compensation exists is Complete.,
q9d: Incomplete — Blank, nonresponsive, or leaves the nature of the advisory/services indeterminate.
Partial — Describes the services only in generic terms (e.g., "advisory services," "consulting") without indicating the category or nature of the work.
Complete — Gives a brief description of the advisory/services (e.g., "legal and regulatory advisory," "growth and BD support," "security advisory"). An explicit statement that no token-based advisory compensation exists is Complete.

**Answer**

#### (a) Existence

Whether any such token-based payments or advisory commitments exist (or explicitly state that no token-based compensation for advisory commitments exist).

<!-- Add answer here. -->

#### (b) Total token allocation

For all existing token-based advisors, disclose the total token allocation across all advisory services.

<!-- Add answer here. -->

#### (c) Payer entity

For each existing token-based advisor, share the payer entity (e.g., Foundation, Labs/DevCo, DAO/treasury).

<!-- Add answer here. -->

#### (d) Description of advisory/services

For each existing token-based advisor, provide a brief description of the advisory/services (e.g., "legal and regulatory advisory," "growth and BD support," "security advisory").

<!-- Add answer here. -->

### 10. KOL Marketing Activities

Instructions:

Disclose ongoing KOL/influencer relationships that partially or fully received tokens for payment. You do not need to disclose KOL/influencers that do not receive tokens for payment. If no KOL engagements exist, state for each sub-question that no KOL engagements exist.

Scoring criteria:

q10a: Incomplete — Blank, nonresponsive, or silent on whether KOLs receive tokens for payment.
Partial — Addresses KOL/influencer activity but leaves it ambiguous whether any of it is token-compensated (e.g., describes marketing relationships without stating the form of payment).
Complete — States plainly whether KOLs receive tokens for payment, or explicitly states that none do.,
q10b: Incomplete — Blank, nonresponsive.
Partial — Token-compensated KOL relationships are acknowledged but no usernames/handles are provided. Lists usernames/handles but omits platforms or the nature of their activities for one or more KOLs, or lists only some of the token-compensated KOLs.
Complete — Lists usernames/handles with platforms for every KOL that received token-based compensation and describes the nature of their activities; legal names are not required. An explicit statement that no KOLs receive tokens for payment is Complete.,
q10c: Incomplete — Blank, nonresponsive, or leaves both the aggregate token amount and the vesting/lock terms indeterminate.
Partial — Provides the aggregate token amount without summarizing vesting, lock, or release terms, or summarizes terms without the aggregate amount.
Complete — Provides the aggregate token amount across all such arrangements and summarizes the vesting, lock, or release terms (or states clearly that there are none). An explicit statement that no KOLs receive tokens for payment is Complete.

**Answer**

#### (a) Existence & scope

State plainly whether KOLs receive tokens for payment.

<!-- Add answer here. -->

#### (b) Usernames & roles

List usernames/handles (with platforms) for KOLs that received token-based compensation and describe the nature of their activities. Legal names are not required.

<!-- Add answer here. -->

#### (c) Token allocation & vesting/locks

Provide the aggregate token amount across all such arrangements and summarize vesting, lock, or release terms.

<!-- Add answer here. -->

### 11. Labelled Unissued & Operational Token Wallets

Instructions:

For each wallet that holds Unissued Tokens or is essential to operations (e.g., foundation, operations, treasury, investor reserve), disclose:

- (a) A category label explaining the wallet's primary function.
- (b) chain the wallet is on.
- (c) The unique address of the wallet.
- (d) The mechanism of control (e.g., DAO, multisig).
- (e) One verification link to a blockchain explorer.

Definition: Unissued Supply = tokens authorized by the contract but not yet issued to any party; where they sit (treasury or mint authority) does not change that they are unissued. For instance: if a token has a total supply cap of 1B, and 400M tokens have been issued to investors, the team, and users (whether vested or unlocked), then those 400M count as issued supply. The remaining 600M are authorized but unissued supply, even if they are already minted into a DAO treasury wallet.

Scoring criteria:

Incomplete — No wallets are disclosed or the answer is indeterminate. 
Partial — At least one material wallet is disclosed with a category label and unique address, but exactly one required item from (b)–(e) is missing or ambiguous for one or more disclosed wallets, OR the disclosure covers only one applicable wallet group (unissued-token wallets or operational wallets) while omitting another applicable group, OR wallets are listed without addresses, OR two or more of (a)–(e) are missing or ambiguous for any disclosed wallet, OR unissued supply is known to exist but no unissued-supply wallet is disclosed and no treasury wallet is identified as holding unissued supply.
Complete — For every disclosed wallet, all five items (a)–(e) are clearly present: category label, chain, unique address, control mechanism, and a blockchain explorer verification link. The disclosure covers wallets holding unissued tokens AND operational wallets (treasury, foundation, operations as applicable).

**Answer**

| Title | Primary Function | Chain | Address | Control Mechanism | Explorer Link |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

## Transactions & Market Structures

### 12. 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 |
| --- | --- | --- | --- |
|  |  |  |  |

### 13. 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 |
| --- | --- | --- | --- |
|  |  |  |  |

### 14. Liquidity Deals and Market Activity

Instructions:

If a category does not exist or is not applicable, make that clear in plain language.

Scoring criteria:

q14a: Incomplete — Blank, nonresponsive, or the item is not addressed at all — neither disclosed nor stated to be inapplicable.
Partial — Repurchases or secondary-market accumulations are disclosed but one or more of source of funds, treatment (burn, treasury retention, POL, redistribution, or other), policy controller (who can change the secondary-market accumulation), or whether the tokens may be re-used, re-issued, or permanently removed is missing or too vague to identify the material terms.
Complete — For each repurchase or secondary-market accumulation, gives the source of funds, treatment, policy controller, and whether the tokens may be re-used, re-issued, or permanently removed from circulation. A clear plain-language statement that the category does not exist or does not apply is Complete.,
q14b: Incomplete — Blank, nonresponsive, or the item is not addressed at all — neither disclosed nor stated to be inapplicable.
Partial — POL is disclosed but one or more of deployment venues, total token or dollar size across deployments, controller, or unwind/exit policy is missing or too vague to identify the material terms.
Complete — States where POL is deployed, the total token or dollar size across deployments, the controller, and the unwind/exit policy. A clear plain-language statement that the category does not exist or does not apply is Complete.,
q14c: Incomplete — Blank, nonresponsive, or the item is not addressed at all — neither disclosed nor stated to be inapplicable.
Partial — Liquidity deals or purchased TVL are acknowledged but the total size across all deals or where the capital participates is missing or too vague to identify the material terms.
Complete — States the total size across all liquidity deals / purchased TVL and where the capital participates; counterparty names are not required. A clear plain-language statement that the category does not exist or does not apply is Complete.,
q14d: Incomplete — Blank, nonresponsive, or the item is not addressed at all — neither disclosed nor stated to be inapplicable.
Partial — Token-secured loans or lines are disclosed but one or more of principal, gross position size, collateral, counterparties, or unwind/exit policy is missing or too vague to identify the material terms.
Complete — For each token-secured loan or line (including against unissued tokens), gives the principal, gross position size, collateral, counterparties, and unwind/exit policy. A clear plain-language statement that the category does not exist or does not apply is Complete.

**Answer**

#### (a) Token repurchases or secondary-market accumulations (if any)

Source of funds, treatment (burn, treasury retention, POL, redistribution, or other), policy controller (who can change the secondary-market accumulation strategy), and whether those tokens may be re-used, re-issued, or permanently removed from circulation.

<!-- Add answer here. -->

#### (b) Protocol-owned liquidity (POL) (if any)

Where deployed, total token or dollar size across deployments, policy controller (who can change the POL strategy), and unwind/exit policy.

<!-- Add answer here. -->

#### (c) Liquidity deals / purchased TVL (if any)

The total size across all deals, and where the capital participates - no counterparty names needed.

<!-- Add answer here. -->

#### (d) Token-secured loans/lines (incl. against unissued tokens) (if any)

Principal, gross position size, collateral, counterparties, and unwind/exit policy.

<!-- Add answer here. -->

## Resource Disclosures

### 15. 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 |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

### 16. Operational Funding, Economic Flows, and Resource Provisioning

Instructions:

Provide a narrative description of the Project's material funding sources, economic flows, and operational provisioning, broken out by entity: Foundation, Lab/DevCo, and DAO. If an entity does not exist, state that explicitly.

Scoring criteria:

q16a: Incomplete — Blank, nonresponsive, or the existence of one or more of the Foundation, Lab/DevCo, or DAO is not addressed; non-existence is implied rather than stated.
Partial — Addresses the existence of some but not all three entities, or leaves the status of one entity ambiguous (e.g., references it without confirming whether it currently exists).
Complete — Explicitly states whether each of the Foundation, Lab/DevCo, and DAO exists.,
q16b: Incomplete — Blank, nonresponsive, or funding sources or economic inflows are unstated and not marked "none" for one or more existing entities.
Partial — Describes funding sources for some existing entities but not all, or describes inflows only in general terms without identifying the primary sources.
Complete — For each existing entity, describes its primary sources of operational funding or economic inflows (e.g., service fees, grants, donations, treasury reserves, token reserves, staking rewards, validator/sequencer income, partnership payments, retained revenue, or other protocol-related receipts).,
q16c: Incomplete — Blank, nonresponsive, or the use of resources is not addressed for one or more existing entities.
Partial — Describes resource use for some existing entities but not all.
Complete — For each existing entity, briefly describes how the resources are generally used (e.g., development, operations, security, ecosystem support, grants, liquidity support).,
q16d: Incomplete — Blank, nonresponsive, no links are provided, or links are provided with no explanation of what each one is for.
Partial — Provides links but does not explain what each link is for. 
Complete — Provides links to public dashboards and tokenholder relations reports covering on-chain financial activity, treasury activity, fee flows, rewards, or other protocol-controlled resources, and explains what each link is for.

**Answer**

#### (a) Entity existence

Explicitly state whether each of Foundation, Lab/DevCo, and DAO exists.

<!-- Add answer here. -->

#### (b) Material sources of funding or economic inflows

For each existing entity, describe its primary sources of operational funding or economic inflows, if any (e.g., service fees, grants, donations, treasury reserves, token reserves, staking rewards, validator/sequencer income, partnership payments, retained revenue, or other protocol-related receipts).

<!-- Add answer here. -->

#### (c) Operational use of resources

For each existing entity, briefly describe how those resources are generally used (e.g., development, operations, security, ecosystem support, grants, liquidity support).

<!-- Add answer here. -->

#### (d) Onchain Resource Usage

For each existing entity, provide links to public dashboards and token holder relations reports that help explain on-chain financial activity, treasury activity, fee flows, rewards, or other protocol-controlled resources. Make certain to explain what each link is for.

<!-- Add answer here. -->

### 17. 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:

q17a: 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.,
q17b: 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.,
q17c: 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.,
q17d: 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.,
q17e: 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.,
q17f: 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.

<!-- Add answer here. -->

#### (b) Exploit vector summary

Plain-language summary of the exploit vector (what the hack was).

<!-- Add answer here. -->

#### (c) Quantified impact

Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).

<!-- Add answer here. -->

#### (d) Remediation/response taken

Remediation/response taken (patches, upgrades, governance actions, compensation).

<!-- Add answer here. -->

#### (e) Current status

Current status (resolved, in litigation, under investigation, refunded, etc.).

<!-- Add answer here. -->

#### (f) References

Link(s) to post-mortem/advisory/PR.

<!-- Add answer here. -->

### 18. [Optional] Offchain Foundation Or DevCo Income Statement

Instructions:

Provide a single income statement, expense summary, or comparable operating statement for the primary Foundation or Developer Company. A consolidated or entity-level presentation is acceptable. Balance Sheet and Statement of Cash Flows may be included but are not required. This item is intended to provide transparency into offchain operating resources and expenditures only.

Scoring criteria:

This item is optional and is not scored. Any answer, including a blank or absent answer, is Complete.

**Answer**

| Line Item | Amount |
| --- | --- |
|  |  |