BID Protocol
Token Transparency Filing
Project & Team
Description of Project
Provide a narrative description of the purpose of the project.
CreatorBid has been pioneering in agentic crypto since 2024 as one of the first and biggest agent launchpads on Base.
Our vision remains unchanged: enabling users to create and monetize web3-native agents. Today the company focuses on providing the infrastructure and marketplace for trading agents.
Known Project Team
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.
Labs / DevCo
Full Name | Official Title | Prior Experience |
|---|---|---|
Philipp Kothe | CEO | Blockchain Consultancy and startups |
DAO Structure
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.
- (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).
(a) IP ownership & control
n/a
Primary Foundation
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".
- (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.
(a) Entity
n/a
Primary DevCo
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".
- (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.
(a) Entity
Limited Company - BVI
Affiliated Protocol Contributor
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.
- (a) Identity & role — Legal name, entity type, jurisdiction, and role (e.g., core development, security, infrastructure, market making, operations).
- (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.
- (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.
- (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.
Token Supply & Allocation
Initial Allocation
Download the Worksheet, enable macros, complete the Initial Allocation sheet, then use Convert To CSV to export the file for import here. To make edits after importing, update the worksheet, use Convert To CSV again, then re-import the new CSV. The table is the final answer.
Vesting Insider Tokens
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.
- (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.
- (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.
Disclosure of Token Advisory Billings
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.
- (a) Existence — Whether any such token-based payments or advisory commitments exist (or explicitly state that no token-based compensation for advisory commitments exist).
- (b) Total token allocation — For all existing token-based advisors, disclose the total token allocation across all advisory services.
- (c) Payer entity — For each existing token-based advisor, share the payer entity (e.g., Foundation, Labs/DevCo, DAO/treasury).
- (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").
(a) Existence
yes, we have a 1% total supply agreement with Moonrock Capital
(b) Total token allocation
Moonrock Capital - 1% - 24 months vest network launch
(c) Payer entity
Limited Company
(d) Description of advisory/services
Business Strategy
KOL Marketing Activities
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.
- (a) Existence & scope — State plainly whether KOLs receive tokens for payment.
- (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.
- (c) Token allocation & vesting/locks — Provide the aggregate token amount across all such arrangements and summarize vesting, lock, or release terms.
(a) Existence & scope
non
(c) Token allocation & vesting/locks
No token for KOL activations
Labelled Unissued & Operational Token Wallets
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.
Transactions & Market Structures
Market Maker Agreements & Deals
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).
Exchange Agreements & Deals
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.
Exchange Name | Token Allocation Committed | Term Duration | Native Token Listing Fees |
|---|---|---|---|
Gate | 0 | 0 | |
MEXC | 0 | 0 |
Liquidity Deals and Market Activity
If a category does not exist or is not applicable, make that clear in plain language.
- (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.
- (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.
- (c) Liquidity deals / purchased TVL (if any) — The total size across all deals, and where the capital participates - no counterparty names needed.
- (d) Token-secured loans/lines (incl. against unissued tokens) (if any) — Principal, gross position size, collateral, counterparties, and unwind/exit policy.
(b) Protocol-owned liquidity (POL) (if any)
Aerodrome: 1,000,000 USD at deployment
Pankcake Swap: 1,000,000 USD at deployment
Resource Disclosures
Prior Token Sales & Fundraising
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.").
Series Name | Investment Instrument | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
Pre-seed | SAFT | 01/03/2024 | 87,000,000 | 24 moths after network launch (start Jan 2026) |
Launch | Public Sale on Binance Wallet ICO | 23/01/2025 | 100,000,000 | unlocked |
Operational Funding, Economic Flows, and Resource Provisioning
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.
- (a) Entity existence — Explicitly state whether each of Foundation, Lab/DevCo, and DAO exists.
- (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).
- (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).
- (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.
(a) Entity existence
Lime Tree Labs Ltd. BVI company
(b) Material sources of funding or economic inflows
- Revenue product e.g. from agent token trading (og.creator.bid / trenches.bid launchpad) and BID Protocol trading competitions
- Token sales
- LP fees
(c) Operational use of resources
- HR
- Operations (hosting, etc.)
Previous Exploits Affecting The Native Token
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").
- (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.
(a) Date & component affected
non
(b) Exploit vector summary
non
[Optional] Offchain Foundation Or DevCo Income Statement
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.
This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. BID Protocol is solely responsible for the content, accuracy, and legality of its disclosures.
