Provide a concise narrative that clearly states each of (a)–(e) below.
Response
Index products (baskets of assets held as a single instrument) traditionally require trusted intermediaries: a sponsor, custodian, manager, and transfer infrastructure, each of which introduces fees, counterparty risk, and discretionary control over investor assets, including the ability to change strategy, raise fees, or gate redemptions. On Robinhood Chain specifically, no native mechanism existed for holding a diversified basket of tokenized equities and chain-native assets as a single token, and no price infrastructure existed for chain-native assets at all. Vimen addresses both: fully collateralized on-chain index baskets whose rules cannot be changed after deployment and whose redemption cannot be blocked by any party, and a public TWAP price layer for chain-native assets that the protocol operates and publishes, including a live model of each feed's manipulation cost.
The protocol is designed to minimize ongoing operational dependency: basket contracts are immutable, hold their own collateral, and function (mint, redeem, verification) without any operator. Ongoing operations consist of the rebalancing engine and oracle keeper (lightweight infrastructure run by the project), frontend hosting, and continued development of curator tooling and public documentation. Ongoing costs are low and are supported by the protocol's share of mint fees: mint fees on baskets are split by an immutable contract, 60% to the basket's curator and 40% to the protocol treasury. This split is a constant in deployed code and cannot be redirected. Development priorities are sequenced publicly and shipped when complete; the project does not commit to dates. If the project's operators ceased activity, all deployed baskets would remain fully functional, redeemable, and verifiable indefinitely.
Response
State the project's airdrop status plainly, and back it up:
Response
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:
If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for (b).
Response
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
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.
Response
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:
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Response
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").
Response
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. Vimen is solely responsible for the content, accuracy, and legality of its disclosures.
Vimen is a protocol for tokenized index baskets on Robinhood Chain. A basket token is an ERC-20 fully backed by fixed quantities of underlying tokens (tokenized equities, ETFs, and chain-native assets) held by its own immutable contract. Minting deposits the underlyings; redeeming returns them pro rata, permissionlessly, with no fee and no party able to block it. Baskets come in two forms. Frozen baskets have a composition fixed forever at deployment. Agentic baskets permit exactly one mutation, a rebalance function callable only by a designated agent key, bounded by immutable constraints (minimum one-day cooldown, maximum 25% turnover of NAV per rebalance, maximum 1% NAV slippage, registered assets only); after every trade the contract recomputes holdings from actual balances, so full collateralization holds by construction. Surplus generated by agentic baskets is swept to an immutable per-basket distributor that pays holders in USDG. Basket creation is permissionless and gated by a token burn rather than approval. The protocol also operates a public price layer of TWAP feeds for chain-native assets, with per-feed manipulation-cost estimates published live. All contracts are verified on the chain's public explorer.
VIM's primary function is licensing basket creation. Publishing a frozen basket requires permanently burning 10,000 VIM; publishing an agentic basket requires permanently burning 25,000 VIM. Burns are irreversible, grant a permanent license, require no approval from the project, and cannot be revoked. Each license reduces total VIM supply permanently. VIM carries no governance rights (the protocol has no governance mechanism over deployed contracts, by design), no claim on protocol revenue, and no promised yield or return.
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:
For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Response
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.
Response
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.
Response
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.
Response
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
(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?
Response
