Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (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.
(a) Problem the project solves
Venice is a private, uncensored AI platform that removes surveillance, censorship, and per-request payment friction from AI inference. The platform provides access to more than 100 AI models across text, image, code, video, audio, music, and speech with zero data retention. Prompts and responses are stored on the user's own device rather than on Venice servers. (Source: Launch post, Product docs, Moonwell governance proposal)
(b) Operational priorities
Venice.ai, Inc. funds ongoing development and operations through Pro subscription revenue at $18 per month and API revenue, combined in July 2026 with a $65 million Series A equity financing at a $1 billion valuation led by Dragonfly. The company turned profitable in the first quarter of 2026 with annualized run-rate revenue above $70 million. A portion of platform revenue funds a programmatic VVV buy-and-burn program, and the company has executed a scheduled series of emissions reductions targeting a net deflationary token. (Source: Moonwell governance proposal, GeekWire Series A coverage, TheStreet Series A coverage, Programmatic buy-and-burn update)
(c) High-level project overview
VVV is an ERC-20 token on Base, deployed January 27, 2025 at contract address 0xacfE6019Ed1A7Dc6f7B508C02d1b04ec88cC21bf. Holders stake VVV for emissions-based yield and lock staked VVV (sVVV) to mint DIEM, Venice's API credit token. Each staked DIEM provides $1 per day of Venice API credit, giving stakers ongoing private inference access without per-request charges. The pre-DIEM Utilization Rate access model was retired on August 20, 2025 when DIEM launched. (Source: VVV landing page, DIEM launch post, Current tokenomics FAQ, Moonwell governance proposal)
(d) Primary token functions
The token's primary functions are staking for yield, locking staked VVV to mint DIEM for ongoing Venice API compute credit, and liquidity provisioning on Base DEXs. VVV carries no governance rights. (Source: Launch post, VVV landing page, Current tokenomics FAQ)
(e) Control surface reliance
VVV has no tokenholder governance. The VVV token contract is a minimal, immutable ERC-20 whose single privileged function, mint(), is restricted to the contract owner. The owner is the staking contract at 0x321b7ff75154472B18EDb199033fF4D116F340Ff, an ERC1967 UUPS proxy. The staking contract is owned by a 4-of-6 Gnosis Safe multisig at 0x2D8CB8DC596daD0e1E34E2042E7ae6Df93B11524, which controls staking contract upgrades, the staking rewards pause function, and the emissions schedule. Venice has announced no plan to transition control to tokenholder governance. (Source: Launch post, Moonwell governance proposal)
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.
Full Name | Entity | Official Title | Prior Experience |
|---|---|---|---|
Erik Voorhees | Labs | Founder & CEO | Founded the crypto exchange ShapeShift. Provided the seed capital for Venice himself. (Source: Welcome to Venice, GeekWire Series A coverage) |
Jesse Proudman | Labs | Co-Founder, President & CTO | Founded cloud company Blue Box Group, acquired by IBM in 2015. Founded crypto startup Strix Leviathan, acquired by Parataxis in early 2025. Runs product and engineering at Venice. (Source: GeekWire Series A coverage, TheStreet Series A coverage) |
Teana Baker-Taylor | Labs | Co-Founder & COO | Former Vice President at stablecoin issuer Circle. (Source: The Block launch coverage, Silicon Valley Investclub Series A coverage) |
Blockworks note: Labs/DevCo Venice.ai, Inc. is the operating entity. Its co-founders and key executives are listed below. The company employs approximately 45 people as of July 2026. (Source: Terms of Service, GeekWire Series A coverage) |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (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 onchain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., onchain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
Not applicable. No DAO exists, and no IP is owned or controlled by a DAO.
(b) Contract/admin powers
No DAO executor exists. All contract and administrative authority sits with Venice.ai, Inc. through the following onchain structure. The VVV token contract at 0xacfE6019Ed1A7Dc6f7B508C02d1b04ec88cC21bf is a minimal, immutable ERC-20 built on Solmate with a single privileged function, mint(), restricted to the contract owner. The token contract owner is the staking contract at 0x321b7ff75154472B18EDb199033fF4D116F340Ff, an ERC1967 UUPS proxy currently implementing StakingV2 at 0xe37A7920dbc11253ac6d031C29f592f71B348DCA. The staking contract owner is a 3-of-5 Gnosis Safe multisig at 0x2D8CB8DC596daD0e1E34E2042E7ae6Df93B11524, which authorizes staking contract upgrades and the staking rewards pause function. The token contract has no blacklist functionality and is not pausable. Minting occurs only through the staking contract's emissions logic, which is governed by the 4-of-6 multisig. (Source: Moonwell governance proposal, BaseScan token page, sVVV BaseScan page)
(c) Locked-token rights (conditional)
Holders stake VVV for emissions-based yield and lock staked VVV (sVVV) to mint DIEM, which provides $1 per day of Venice API credit per staked DIEM. While sVVV is locked backing minted DIEM, the staker earns 80% of the standard yield and the remaining 20% flows to Venice. A 7-day cooldown applies to unstaking. Locking confers no governance or protocol policy rights. Tokenholders cannot decide protocol changes, emissions parameters, or treasury allocations. All such decisions are made unilaterally by Venice.ai, Inc. (Source: VVV landing page, Current tokenomics FAQ, Tokenomics.com Venice page)
(d) Value accrual & holder rights
Tokenholders hold no rights over revenue distribution or the treasury. Venice.ai, Inc. directs a portion of platform revenue to programmatic VVV buy-and-burn at its own discretion, which reduces supply but confers no distribution or claim rights on holders. VVV and DIEM are utility tokens, not governance tokens, and the public buy-and-burn program does not create or imply any governance rights for holders. (Source: Programmatic buy-and-burn update, Venice is Burning)
(e) Dissolution authority
Not applicable. No DAO exists, so no dissolution authority over a DAO exists.
Blockworks note: Venice does not have a DAO or onchain governance mechanism. The launch materials state that VVV has no governance. (Source: Launch post)
Primary Foundation
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
Venice does not operate a foundation entity. The token was issued by Venice.ai, Inc., the operating company, and no non-profit or foundation entity exists in the project's structure. Items (a) through (f) are not applicable. (Source: Terms of Service, Launch post)
Primary Dev Co
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
Venice.ai, Inc. is a Wyoming corporation with a registered office in Sheridan, Wyoming. It is the operating entity for the Venice platform and issued the VVV token at launch. (Source: Terms of Service, Launch post)
(b) IP ownership & control
Venice.ai, Inc. is the entity that owns and controls all project IP. It owns the VENICE trademark registration filed with the USPTO covering downloadable AI software and related categories, and it controls the Venice codebase through the veniceai GitHub organization. The Venice privacy proxy code is closed source and operated by the company. No subsidiary entities are publicly disclosed, and no other entity shares or holds control over the project's IP. (Source: USPTO trademark record, Moonwell governance proposal)
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No DAO exists. Venice.ai, Inc. holds unilateral control over all protocol-controlled resources, including its own company treasury, which it directly controls. The entity is the sole link in the legal and decision-making chain; there is no DAO or other body sharing or checking this authority. The company received 35% of genesis supply, is the largest VVV holder, holds the treasury multisig containing 17.97% of total supply as of March 2026, sets the emissions schedule through its control of the staking contract, and directs platform revenue to programmatic buy-and-burn. Emissions and token administration decisions are executed through the 3-of-5 multisig described in item (e). Tokenholders hold no countervailing authority. (Source: Launch post, Moonwell governance proposal, Programmatic buy-and-burn update)
(d) Powers over Foundation
Not applicable. No foundation entity exists.
(e) Contract/admin powers
The VVV token contract is immutable and not pausable, with no blacklist functionality. Its only privileged function, mint(), is callable solely by the staking contract through its emissions logic. The staking contract at 0x321b7ff75154472B18EDb199033fF4D116F340Ff is an ERC1967 UUPS proxy upgradeable by a 3-of-5 Gnosis Safe multisig at 0x2D8CB8DC596daD0e1E34E2042E7ae6Df93B11524. The same 3-of-5 multisig controls the staking rewards pause function. Venice authored and published this control structure, including the five signer addresses, in its March 2026 Moonwell listing proposal. (Source: Moonwell governance proposal, BaseScan token page, sVVV BaseScan page)
(f) Current economic arrangements and distribution policies
Venice.ai, Inc. received 35 million VVV (35% of genesis supply) at TGE, of which 10 million VVV (10% of total supply) was granted to the team with 25% unlocked upfront and the remainder streaming linearly over 24 months, ending January 2027. The separate 10 million VVV Venice Incentive Fund is controlled by Venice for ecosystem support and cannot be used to pay or grant tokens to Venice team members. Venice earns 20% of staking yield on sVVV locked to back minted DIEM. Platform revenue funds programmatic buy-and-burn of VVV, which is a supply reduction mechanism rather than a distribution to the entity. Venice.ai, Inc. completed a $65 million Series A equity financing in July 2026 at a $1 billion valuation led by Dragonfly with participation from Coinbase Ventures, Archetype, Morgan Creek, North Island Ventures, Liquid2 Ventures, and Founders' Co-op. (Source: Launch post, Venice Incentive Fund FAQ, Tokenomics.com Venice page, GeekWire Series A coverage)
Token Supply & Allocations
Initial Allocation
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.
- (a) Launch supply totals — The total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch.
- (b) Recipient categories & use of funds — The recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket.
- (c) Initial price per token (if applicable) — The initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
- (d) Ticker / market symbol — The ticker/market symbol.
- (e) Total supply & supply regime — The total supply and whether the supply is fixed (if not explain inflation rate or deflation rate).
- (f) Initial vesting / release schedules — The initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).
(a) Launch supply totals
100 million VVV were created at genesis on January 27, 2025. 92.5 million VVV (92.5%) were unlocked at TGE and 7.5 million VVV (7.5%, the streaming portion of the team allocation) were locked at TGE. (Source: Launch post, Gate Learn VVV overview)
(b) Recipient categories & use of funds
50 million VVV (50%) airdropped to Venice users and the crypto AI community on Base for adoption and distribution. 35 million VVV (35%) granted to Venice.ai, Inc. for development and growth, within which 10 million VVV (10% of total supply) was granted to the team via vesting contracts as part of that 35% company allocation. 10 million VVV (10%) allocated to the Venice Incentive Fund for ecosystem support, which cannot be used to pay Venice team members. 5 million VVV (5%) deployed as DEX liquidity. (Source: Launch post, Current tokenomics FAQ, Venice Incentive Fund FAQ, Moonwell governance proposal)
(c) Initial price per token (if applicable)
No fixed offering price was set. The token was never sold or offered to purchasers; the entire distributed supply outside the team grant, incentive fund, and liquidity allocation was distributed via airdrop, and price was established by the market only after genesis, through a public liquidity pool that Venice seeded on Aerodrome on Base at TGE, followed by same-day and subsequent CEX listings including Coinbase and Kraken. (Source: Launch post, Kraken listing announcement, Moonwell governance proposal)
(d) Ticker / market symbol
VVV. (Source: Launch post, Kraken listing announcement)
(e) Total supply & supply regime
Supply is not fixed. 100 million VVV were minted at genesis, with ongoing annual emissions paid to stakers. Emissions started at 14 million VVV per year and were reduced six times on the following schedule. 14M to 10M on August 20, 2025. 10M to 8M on October 23, 2025. 8M to 6M on February 10, 2026. 6M to 5M on May 1, 2026. 5M to 4M on June 1, 2026. 4M to 3M on July 1, 2026. Against emissions, 33,539,739 unclaimed airdrop VVV were burned on March 12, 2025, and platform revenue funds ongoing programmatic buy-and-burn with a stated goal of net deflation. Circulating supply is approximately 47 million VVV as of July 2026. (Source: Launch post, Supply-change FAQ, Venice emissions schedule on X, CryptoBriefing emissions coverage, Programmatic buy-and-burn update)
(f) Initial vesting / release schedules
The team allocation of 10 million VVV (part of the 35% company grant) was the only vested bucket, with 25% (2.5 million VVV) unlocked at TGE and the remaining 7.5 million VVV streaming linearly over 24 months, ending January 2027. This is a distinct allocation from the separate 10 million VVV Venice Incentive Fund, which is not subject to vesting and was fully unlocked at TGE for ecosystem support. The airdrop and liquidity allocations were also fully unlocked at TGE. (Source: Launch post, Gate Learn VVV overview, Tokenomics.com Venice page, Venice Incentive Fund FAQ)
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
-
Executed airdrop: (a) Per-address source
No public per-address allocation source (CSV/TSV/JSON, Dune table, Merkle dump, GitHub per-address file, or claim-data RPC endpoint) is published for the VVV airdrop.
(b) Covered segments and allocation method
The airdrop was executed at TGE on January 27, 2025 and distributed 50 million VVV (50% of genesis supply) across two segments. 25 million VVV went to over 100,000 Venice platform users, with eligibility requiring an active account from October 1, 2024, at least 25 points as of the December 31, 2024 snapshot at 23:59 UTC, and a Pro account to claim. Allocation was based on usage and points earned. 25 million VVV went to crypto AI community protocols and developers on Base, including VIRTUAL, AERO, DEGEN, AIXBT, GAME, LUNA, VADER, CLANKER, and MOR communities, plus a reserve for Nous Research and roughly 200 registered Coinbase AgentKit developers. The claim window expired 45 days after TGE on March 13, 2025, and all 33,539,739 unclaimed VVV were burned on March 12, 2025. (Source: Launch post, Airdrop eligibility FAQ, Airdrop burn FAQ, Airdrop expiry FAQ)
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; doing so earns full credit. For each market maker, include in a table:
- (a) Market maker's name — the market maker's name;
- (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
- (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
- (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes.
If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Blockworks note: No market maker agreements or native-token allocations or loans to market makers are publicly disclosed. Venice deployed its 5% liquidity allocation directly to public DEX pools on Aerodrome rather than through disclosed third-party market-making arrangements. (Source: Launch post, Moonwell governance proposal)
CEX / DEX 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.
Blockworks note: No listing agreements, listing-related token allocations, listing lockups, or native-token listing fees are publicly disclosed. Venice has confirmed it has never paid for a CEX listing in any form. VVV trades on more than 30 markets including Coinbase (Day 1 listing), Kraken, KuCoin, Gate.io, Bybit, MEXC, and others, and on Aerodrome (SlipStream and v2), Uniswap V3, and Uniswap V4 on Base. The only disclosed token commitment related to trading venues is the 5 million VVV (5%) liquidity deployment to public DEX pools, seeded by Venice on Aerodrome. (Source: Moonwell governance proposal, Kraken listing announcement, Launch post)
Financial Disclosures & Risks
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.").
Blockworks note: No prior token sales, pre-sales, OTC token sales, or discounted market-maker token sales have occurred. The launch post states there were no pre-sales of any kind, and Erik Voorhees was the sole investor in the company prior to and at TGE. (Source: Launch post, The Block launch coverage)
Separately from token sales, Venice.ai, Inc. closed a $65 million Series A equity financing in July 2026 at a $1 billion valuation, led by Dragonfly with participation from Coinbase Ventures, Archetype, Morgan Creek, North Island Ventures, Liquid2 Ventures, and Founders' Co-op. This was an equity round in the operating company. No token component of the round is publicly disclosed. (Source: GeekWire Series A coverage, SiliconANGLE Series A coverage)
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 (optional) — References (optional): link(s) to post-mortem/advisory/PR.
(f) References (optional)
Blockworks note: No exploits affecting tokenholders, native token supply, staked balances, or protocol funds have occurred as of July 23, 2026. The VVV token and staking contracts have operated without a disclosed loss event since deployment on January 27, 2025. (Source: Moonwell governance proposal, BaseScan token page)
Material Risk Factors (Regulation, Technology, Token Economics)
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?
(a) Regulatory, Legal & Tax Risks
VVV launched on January 27, 2025 and trades on more than 30 venues including Coinbase, Kraken, KuCoin, Gate.io, and Bybit, so the operative regulatory risk is continued distribution, listing maintenance, and entity operations under changing law rather than launch completion. Adverse regulatory developments in key jurisdictions could force delistings or restrict venue access. (Source: Launch post, Kraken listing announcement, Moonwell governance proposal)
The sole core entity is Venice.ai, Inc., a Wyoming corporation. Regulatory or legal changes affect the project through this single entity, including potential enforcement actions, licensing requirements, or compelled operational changes covering the platform, the API, the privacy proxy architecture, uncensored model access, or token administration. The Terms of Service expressly reserve Venice's right to restrict access where use may violate local law. The concentration of all protocol control in one U.S. operating company means entity-level regulatory action would directly affect token emissions, buy-and-burn execution, and DIEM redemption value. (Source: Terms of Service, Moonwell governance proposal)
Tokenholder tax treatment is unsettled. Staking yield, DIEM minting and daily credit accrual, burns, and a changing emissions schedule each create tax characterization uncertainty that varies by jurisdiction. Tokenholders are responsible for understanding and meeting their own tax obligations. (Source: VVV landing page, Current tokenomics FAQ, Supply-cap FAQ)
Publicly stated access restrictions include minimum-age requirements and a reservation of rights to restrict service access where local law would be violated. These restrictions create the risk that users in affected jurisdictions lose platform access, which would reduce the utility value of staked VVV and DIEM held by those users. (Source: Terms of Service)
(b) Protocol, Technology & Security Risks
The technical risk surface is concentrated in privileged staking and emissions logic rather than the token contract itself. The VVV token contract is a minimal, immutable, non-pausable ERC-20 of 23 lines of custom code built on Solmate, with mint() as its only privileged function. That mint path is owned by the staking contract, an ERC1967 UUPS proxy upgradeable by a 3-of-5 Gnosis Safe multisig. The mint function is uncapped, so compromise of the multisig or a malicious staking contract upgrade would enable unlimited VVV minting and dilution. Independent risk analysis by Anthias Labs for Moonwell identifies this owner-controlled uncapped mint path as the primary asset risk. The platform additionally depends on Base network liveness and, for downstream DeFi integrations, on DIA and Chainlink VVV/USD oracles. (Source: Moonwell governance proposal, BaseScan token page, sVVV BaseScan page)
Security measures include a Trust Security audit of the token contracts, published at trust-security.xyz/venice-ai-audit, and an active bug bounty program, both disclosed by Venice in its March 2026 Moonwell proposal. Venice remediated a May 2025 platform security issue in which inference-only API keys could manipulate an API-key administration endpoint. The privacy architecture routes prompts through a Venice-controlled closed-source proxy and partner GPUs. These measures do not eliminate residual risk from privileged contract control, upgrade execution, emissions authority, multisig signer compromise, or the offchain trust boundary at the proxy and GPU partner layer, none of which an audit of contract code alone can prevent. (Source: Moonwell governance proposal, Security changelog, How Venice handles your privacy)
(c) Token Economics, Unlocks & Incentive Risks
VVV's value rests on continued demand for private AI inference, staking participation, DIEM minting demand, and Venice's ability to sustain revenue-funded burns. Annual emissions were reduced six times, from 14M at launch to 10M on August 20, 2025, 8M on October 23, 2025, 6M on February 10, 2026, 5M on May 1, 2026, 4M on June 1, 2026, and 3M on July 1, 2026, with a stated goal of net deflation where burns exceed emissions. If platform usage, subscription revenue, or compute-credit demand decline, burn volume falls, staking yield attractiveness weakens, and the token's access value and deflation trajectory deteriorate together. At 3M annual emissions, roughly 250,000 new VVV enter supply monthly, so net deflation depends entirely on revenue-funded burns exceeding that threshold. (Source: Venice emissions schedule on X, CryptoBriefing emissions coverage, Programmatic buy-and-burn update, What is DIEM?)
Monetary policy control sits entirely with Venice.ai, Inc. and not with tokenholders. VVV has no governance, and emissions, staking parameters, the yield split on DIEM-locked sVVV, and burn policy are all set through the staking contract and its 3-of-5 multisig ownership chain. Venice has changed emissions six times without tokenholder approval because no approval mechanism exists. Future changes to monetary policy, reward allocations, or fee parameters can adversely affect holders without any disclosed tokenholder voting right or veto. (Source: Launch post, Moonwell governance proposal, Current tokenomics FAQ)
This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.