Index

General Information
Part A: Information about the offeror or the person seeking admission to trading
Part B: Information about the issuer, if different from the offeror or person seeking admission to trading
Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D: Information about the crypto-asset project
Part E: Information about the offer to the public of crypto-assets or their admission to trading
Part F: Information about the crypto-assets
Part G: Information on the rights and obligations attached to the crypto-assets
Part H: Information on the underlying technology
Part I: Information on the risks
Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts

2026-06-01

This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union.
The operator of the trading platform of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.

The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.

The utility token referred to in this white paper may not be exchangeable against the good or service promised in this white paper, especially in the case of a failure or discontinuation of the crypto-asset project.

The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

Warning
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.

The Venice Token, VVV, is a crypto-asset issued in connection with the Venice.ai project. Venice.ai is a generative artificial intelligence platform and API service provided by Venice.ai, Inc. VVV is live on Base and is used to access Venice API inference capacity. Users, applications and AI agents may stake VVV to obtain a pro-rata share of Venice’s API capacity for generative text, image and code use cases, without spending the VVV itself.

The genesis supply of VVV was 100,000,000 VVV. Venice subsequently executed token burns, including burns of unclaimed airdrop tokens, and VVV is subject to continuing emissions and burn mechanics.

We regard VVV as a utility token within the meaning of Article 3(1)(9) of MiCA. VVV is used to access services supplied by Venice.ai, including:

• Venice API inference capacity by obtaining a pro-rata allocation of API usage capacity for generative text, image, and code services.
• Access to Venice Pro, a leading private AI application, providing text prompts, access to advanced generative image and video models, and additional premium features.
• VVV is required to mint DIEM, which provides access to internal compute and API credit mechanisms within the Venice ecosystem.

From our perspective, the core economic purpose of VVV remains access to issuer-provided services and related ecosystem functionality. The staking and DIEM mechanics are considered ancillary components of the Venice.ai service-access framework, designed to allocate, represent, and manage usage entitlements within the platform.

VVV also incorporates additional features, including staking-based rewards, token emissions, transferability, and buy-and-burn mechanisms. In our assessment, these elements may reasonably be characterised as tokenomic or incentive mechanisms supporting participation in the Venice ecosystem, rather than as separate standalone functionalities altering the token’s primary access-related purpose.

We acknowledge that certain aspects of the token design, particularly staking-based rewards and value-accrual mechanisms, may give rise to broader interpretative considerations regarding the scope of the utility-token definition and the meaning of the exclusivity requirement under Article 3(1)(9) MiCA. However, based on our interpretation, such features do not, in themselves, prevent VVV from qualifying as a utility token where the overall economic function of the token remains principally linked to access to issuer-provided services.

The token has been admitted to trading to the trading platform operated by Bitstamp Europe S.A. on its own initiative.

TRUE

Venice.ai, Inc.

VVV is issued and implemented in connection with the Venice.ai platform and Venice API. The official Venice materials state that VVV was introduced by Venice as the Venice Token, that 100,000,000 VVV were created at genesis, that there were no pre-sales, and that the TGE distribution included allocations to Venice users, crypto x AI community projects, Venice.ai, the Venice Incentive Fund and liquidity deployment.

Based on our assessment, Venice.ai, Inc. may be regarded as the issuer of VVV, or at least as the entity responsible for the initial creation, launch and allocation of the token, because the official VVV materials describe the token generation event and state that 35,000,000 VVV, representing 35% of the TGE supply, were granted to Venice.ai. This assessment does not imply that Venice.ai, Inc. controls the Base blockchain on which VVV is deployed.

9GXA

1309, Coffeen Avenue Suite 14343

US-WY

1309, Coffeen Avenue Suite 14343

US-WY

2024-04-05

2024-001437554

Not applicable

Venice.ai, Inc. operates and develops the Venice.ai platform, a generative artificial intelligence service that provides access to open-source AI models and related functionality, including text, image, code, audio and character-based AI services. Venice.ai, Inc. also provides the Venice API, Venice Pro subscription services, Venice Credits, DIEM-related compute-access functionality and the VVV token ecosystem, through which users, developers and AI agents may access AI inference capacity and related services.

Not applicable

Bitstamp Europe S.A.

5GGB

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

2015-05-19

549300XIBGTJ0PLIEO72

Bitstamp Europe S.A. is registered with the Luxembourg Trade and Companies Register under the number B196856.

Robinhood Markets, Inc with its registered office at 85 Willow Road, Menlo Park, California 94025, USA.

Bitstamp Europe S.A., acting in its capacity as a crypto-asset service provider (CASP) and operator of a trading platform, has prepared this crypto-asset white paper to support the admission to trading of the crypto-asset on its platform and to provide users with the information required under Regulation (EU) 2023/1114 (MiCA).

Bitstamp Europe S.A. is a Crypto-Asset Service Provider authorised with the CSSF under the number N00000003 to provide the following crypto-asset services:

• providing custody and administration of crypto-assets on behalf of clients;
• operation of a trading platform for crypto-assets;
• exchange of crypto-assets for funds;
• exchange of crypto-assets for other crypto-assets;
• execution of orders for crypto-assets on behalf of clients;
• reception and transmission of orders for crypto-assets on behalf of clients; and
• providing transfer services for crypto-assets on behalf of clients.

Bitstamp Europe S.A. is a payment institution authorised by the CSSF under number Z00000012 to provide the following payment services:

3.a) execution of direct debits, including one-off direct debits,

3.b) execution of payment transactions through a payment card or a similar device,

3.c) execution of credit transfers, including standing orders and

6.) money remittance.

Bitstamp Europe S.A. has notified the cross-border provision of payment services and of crypto-asset services in all EU and EEA member states.

Bitstamp has admitted the asset to which this white paper relates to, to trading on its own initiative on its trading platform.

Robinhood Markets, Inc. is the parent holding company of the Robinhood group.

MiCA Crypto Alliance Limited

MiCA Crypto Alliance Limited was mandated to assist in the white paper preparation by Bitstamp Europe S.A. Bitstamp Europe S.A. retains the role of person seeking admission to trading.

Venice.ai

Venice Token

VVV

Venice.ai is a generative artificial intelligence platform and API service. The Venice API enables users, developers and AI agents to access chat, image generation, audio synthesis and AI character functionality.

The project’s core components include the Venice application, the Venice API, Venice Pro subscriptions, the Venice Token, VVV staking, and DIEM. The Venice API provides access to chat, image generation, audio synthesis and AI character functionality. VVV may be staked to obtain access to a pro-rata share of Venice API inference capacity, including generative text, image and code functionality. DIEM is created from VVV and provides daily Venice API credit for AI inference.

The Venice Token, VVV, is used within the project as an access key through which users, applications and AI agents may stake VVV to access a pro-rata share of Venice API inference capacity without paying per request, subject to the applicable platform and staking terms.

TRUE

VVV is used to access services supplied by Venice.ai, including:

• Venice API inference capacity by obtaining a pro-rata allocation of API usage capacity for generative text, image, and code services.
• Access to Venice Pro, a leading private AI application, providing text prompts, access to advanced generative image and video models, and additional premium features.
• VVV is required to mint DIEM, which provides access to internal compute and API credit mechanisms within the Venice ecosystem.

From our perspective, the core economic purpose of VVV remains access to issuer-provided services and related ecosystem functionality. The staking and DIEM mechanics are considered ancillary components of the Venice.ai service-access framework, designed to allocate, represent, and manage usage entitlements within the platform.

VVV also incorporates additional features, including staking-based rewards, token emissions, transferability, and buy-and-burn mechanisms. In our assessment, these elements may reasonably be characterised as tokenomic or incentive mechanisms supporting participation in the Venice ecosystem, rather than as separate standalone functionalities altering the token’s primary access-related purpose.

We acknowledge that certain aspects of the token design, particularly staking-based rewards and value-accrual mechanisms, may give rise to broader interpretative considerations regarding the scope of the utility-token definition and the meaning of the exclusivity requirement under Article 3(1)(9) MiCA. However, based on our interpretation, such features do not, in themselves, prevent VVV from qualifying as a utility token where the overall economic function of the token remains principally linked to access to issuer-provided services.

Past milestones

Venice.ai launched in May 2024. In November 2024, Venice released the beta version of its API for Pro users. In December 2024, Venice was added to the Eliza Framework for AI agents. On 27 January 2025, Venice introduced VVV.

On 20 February 2025, Venice published the VVV staking and claiming instructions, stating that VVV was live on Base and that staking VVV gives access to a pro-rata share of Venice API capacity, zero-cost inference for generative text, images and code, and emissions-based staking yield. The claim window was stated to remain open until 13 March 2025.

On 20 August 2025, Venice introduced DIEM, stating that VVV holders can mint DIEM from staked VVV, that DIEM is an ERC-20 token on Base, and that DIEM can be transferred, traded or staked for API access.

In December 2025, Venice added GPT-5.2 to its supported model offering.

On 21 April 2026, Venice announced new subscription tiers, program-based VVV buy-and-burn functionality, Venice Studio and additional developer tooling. The changelog states that Venice introduced Pro, Pro+ and Max subscription levels with distinct usage limits, feature access and credit allocations.

On 6 May 2026, covering the period from 21 April 2026 to 5 May 2026, Venice announced further platform, API and token updates. The changelog states that Voice Mode became available on web, iOS and Android, that GPT-5.5 and GPT-5.5 Pro became available on Venice, and that Kling V3 and O3 video models became available with native 4K output.

Venice stated in May 6, 2026 that it had completed the first of three planned VVV emissions reductions, reducing the rate of new token issuance from 6,000,000 VVV per year to 5,000,000 VVV per year, with additional reductions planned in June and July 2026.

Future milestones

Venice further states that additional emissions reductions are planned for June 2026 and July 2026.

VVV launched on January 27th 2025 with a starting supply of 100,000,000 tokens.

Of this amount, 50,000,000 VVV, representing 50% of the token generation event supply, were allocated to an airdrop for Venice users and crypto x AI community participants. A further 35,000,000 VVV, representing 35% of the token generation event supply, were granted to Venice.ai. Within that Venice.ai allocation, 10,000,000 VVV were granted to the team, with 25% unlocked upfront and the remainder streaming over 24 months. A further 10,000,000 VVV, representing 10% of the token generation event supply, were allocated to the Venice Incentive Fund, and 5,000,000 VVV, representing 5% of the token generation event supply, were allocated to liquidity deployment. Venice states that there was no pre-sale.

VVV emissions were initially stated to be 14,000,000 VVV per year. Venice later stated, in connection with the introduction of DIEM, that VVV emissions had been reduced from 14,000,000 VVV per year to 10,000,000 VVV per year. Venice subsequently stated in its 6 May 2026 changelog that it had completed the first of 3 planned further VVV emissions reductions, reducing new issuance from 6,000,000 VVV per year to 5,000,000 VVV per year, with additional reductions planned in June and July 2026. Venice uses a portion of monthly revenue to buy and burn VVV on an ongoing basis, permanently removing tokens from circulation.

Not applicable

By admitting the VVV asset to trading, holders of the token will gain transparent price discovery and improved liquidity. This enables the project’s community and ecosystem participants to more easily enter and exit positions, supporting a dynamic and efficient market.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account. If a client wants to hold the token in their own wallet, they will need to (i) provide an external blockchain wallet address, where the crypto-assets will be sent if a withdrawal is initiated and (ii) satisfy all other requirements applicable to a withdrawal in line with the Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account and a client does not need to fulfill any other technical requirement to hold the crypto-assets on their Bitstamp account, apart from have either a computer or phone with an internet connection and appropriate software in order to interact with the Bitstamp services.

Bitstamp Europe S.A.

BESA

Investors can access the trading platform through https://www.bitstamp.net or via the Bitstamp applications.

There are no costs involved in creating an account on the trading platform, however trading fees and other costs apply in accordance with the fee schedule available at https://www.bitstamp.net/fee-schedule.

Not applicable.

There are no conflicts of interest arising at the moment of writing the white paper in relation to the offer or admission to trading. Bitstamp Group has a strict Code of Conduct and Trading Policy in place. They both mitigate the possibility of conflicts of interest.

In accordance with the Code of Conduct all officers, directors, employees, agents, representatives, contractors and consultants (and other persons, regardless of job or position), are required to report any situation where there is the potential for conflict of interest between their interests and interests of Bitstamp. The Trading Policy that is in place within the Bitstamp Group prohibits all forms of market manipulation and has been designed to prevent insider trading.

Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

Crypto-assets other than asset-referenced tokens or e-money tokens

VVV is an ERC-20 token on the Base blockchain.VVV functions as an access key enabling AI agents and developers to consume private inference through the Venice API without paying per request. VVV is used to earn staking yield, access Venice Pro, mint DIEM and participate in VVV burn mechanics. Venice Pro is the premium tier of the Venice AI platform and includes enhanced usage limits, access to advanced AI models, API access and additional platform functionalities.

VVV is not required in order to use the Venice application or the Venice API; however, a holder that chooses to stake VVV may draw on the Venice API for text, image and code inference at zero marginal cost up to the applicable daily limit, with the limit calculated by reference to the holder’s pro-rata share of staked VVV.

VVV also has DIEM-related functionality. VVV is the exclusive source for minting DIEM. VVV holders may lock staked VVV to mint DIEM, continue earning 80% of normal staking yield while the VVV remains locked, stake DIEM for USD 1 per day of API credit per DIEM, and burn DIEM to unlock the original staked VVV. DIEM is an ERC-20 token on Base and may be transferred, traded and staked.

Not applicable

VVV is an ERC-20 token on the Base blockchain.

The principal holder functionality of VVV is staking for access to Venice API capacity. The amount of API inference available to a staker depends on the holder’s pro-rata share of staked VVV. Staked VVV also participates in emissions-based staking yield. Venice materials state that there is a 7-day unstaking cool-off period after unstaking.

The genesis supply of VVV was 100,000,000 VVV. Venice subsequently executed token burns, including burns of unclaimed airdrop tokens, and VVV is subject to continuing emissions and burn mechanics.

Venice.ai

https://venice.ai/

2026-07-02

2026-07-01

Not applicable

English

1J5KDD5S0

P0SD47M0W

FALSE

TRUE

TRUE

Not applicable as the VVV crypto-asset holders do not acquire any ownership, equity, profit participation, repayment, or redemption rights against any natural or legal person associated with the Venice.ai project. Holding VVV does not give rise to contractual claims or entitlements against any natural or legal person.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable

TRUE

VVV is used to access services supplied by Venice.ai, including:

• Venice API inference capacity by obtaining a pro-rata allocation of API usage capacity for generative text, image, and code services.
• Access to Venice Pro, a leading private AI application, providing text prompts, access to advanced generative image and video models, and additional premium features.
• VVV is required to mint DIEM, which provides access to internal compute and API credit mechanisms within the Venice ecosystem.

From our perspective, the core economic purpose of VVV remains access to issuer-provided services and related ecosystem functionality. The staking and DIEM mechanics are considered ancillary components of the Venice.ai service-access framework, designed to allocate, represent, and manage usage entitlements within the platform.

VVV also incorporates additional features, including staking-based rewards, token emissions, transferability, and buy-and-burn mechanisms. In our assessment, these elements may reasonably be characterised as tokenomic or incentive mechanisms supporting participation in the Venice ecosystem, rather than as separate standalone functionalities altering the token’s primary access-related purpose.

We acknowledge that certain aspects of the token design, particularly staking-based rewards and value-accrual mechanisms, may give rise to broader interpretative considerations regarding the scope of the utility-token definition and the meaning of the exclusivity requirement under Article 3(1)(9) MiCA. However, based on our interpretation, such features do not, in themselves, prevent VVV from qualifying as a utility token where the overall economic function of the token remains principally linked to access to issuer-provided services.

VVV does not confer any claim on the issuer to return monetary value or underlying assets. Instead, VVV redemption, in the sense of use to access the token’s goods and services, is understood as an internal mechanism within the Venice ecosystem for the allocation and management of API usage entitlements.

VVV is used to obtain access to Venice Pro by being staked within the system. This staking process results in the allocation of 100 VVV, enabling users to access the Venice Pro application and its AI inference functionalities.

VVV is also used to obtain access to Venice API inference capacity through a staking-based allocation mechanism. In this case, the token is converted into a pro-rata entitlement to AI compute resources, representing usage capacity within the Venice ecosystem.

By locking staked VVV, users may also mint DIEM, which represents an internal credit-based mechanism for accessing AI compute services.

TRUE

Not applicable

Not applicable

FALSE

Not applicable

FALSE

Not applicable

FALSE

Not applicable

There is no written legal agreement between the issuer and the crypto asset-holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

There is no written legal agreement between the issuer and the crypto asset-holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset-holder and the issuer. In the absence of such an agreement, the laws of the competent court will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

Not applicable as DTI is provided in F.13

Networking and Transport

VVV transactions are submitted to Base via the Ethereum JSON-RPC interface. Users sign transactions and broadcast them through the eth_sendRaw Transaction method to any compatible node endpoint. The sequencer accepts transactions from its mempool, consolidates them with deposit transactions originating from Ethereum, and orders them into Layer 2 blocks. Base provides a public mainnet RPC endpoint and a Flashblocks RPC endpoint; both are rate-limited and not suited to production-scale usage. Production integrations are directed to commercial node providers or self-operated Base nodes.

Unsafe blocks, those committed to by the sequencer but not yet confirmed on Ethereum, are distributed to validators via a dedicated peer-to-peer network, providing low-latency access to pre-confirmation state ahead of Layer 1 batch publication.

Serialisation

Transactions submitted to Base are serialised using Recursive Length Prefix (RLP) encoding. The GasPriceOracle predeployment accepts a fully serialised, RLP-encoded transaction to compute the exact Layer 1 fee component prior to submission. At the contract level, VVV exposes a standard ERC-20 application binary interface (ABI) comprising functions and events for balance reads, allowance reads, approvals, direct transfers, delegated transfers, permit-based approvals, ownership reads, ownership transfer, total supply reads and minting. This ABI defines the machine-readable interface used by wallets, indexers, block explorers and applications to form calls and interpret responses.

Cryptography

The VVV permit function uses Keccak-256 hashing in constructing its EIP-712-compatible domain separator and message digest. The domain separator incorporates the token name, a version value, the current chain ID and the contract address, binding each permit signature to the specific network and deployed contract. Signer recovery uses ECDSA: the permit function recovers the authorising address from the typed-data signature and validates it against the declared permit owner before recording the allowance.

Ledger Model

VVV balances and allowances are stored as EVM contract state on Base, using an account-balance model. The Base rollup node derives the canonical Layer 2 chain from Layer 1 data, tracking the Layer 1 head block and Layer 2 synchronisation progress, and iterating over derivation steps as new Layer 1 inputs become available. The derivation process reads deposit transactions and sequencer batches, generates payload attributes and passes them to the execution engine to compute Layer 2 blocks. The Layer 2 chain can reorganise when Ethereum reorganises.

Execution Environment

VVV executes within Base's Ethereum-compatible execution environment, powered by a Reth-based runtime exposing the standard Ethereum JSON-RPC API. The runtime processes Layer 2 blocks produced by the consensus component and supports system contracts at fixed Layer 2 addresses, precompiles and preinstalls handling rollup-specific functions including fee distribution, Layer 1 block attribute injection and cross-domain messaging. VVV's contract source is verified as an exact match on BaseScan, compiled with Solidity 0.8.26, with optimisation enabled at 200 runs, targeting the Paris EVM version.

Token Standard

VVV conforms to the ERC-20 token standard. It implements the required metadata fields — name, symbol and 18 decimal places — alongside balance and allowance mappings, transfer and approval functions, and Transfer and Approval events. The Solmate ERC-20 dependency additionally provides permit functionality, extending the standard approval mechanism to allow allowances to be set via an off-chain signed message without requiring a separate on-chain approval transaction from the token holder. VVV has no bridge representation and no cross-chain minting path outside of Base.

Approvals and Compliance

VVV supports standard ERC-20 approvals, delegated transfers and permit-based approvals. The permit domain binds each approval signature to the VVV contract's chain ID and address, preventing replay across different networks or contracts. No transfer restrictions, sanctions-screening hooks, transfer taxes, pausing controls or compliance modules are present in the deployed VVV contract.

External Interfaces

VVV is accessible through Base-compatible node interfaces and block explorers. The Base Mainnet RPC endpoint supports transaction submission via the Ethereum JSON-RPC standard; BaseScan provides token metadata, verified contract source, ABI, holder data and transfer history. The Venice AI token dashboard separately presents live supply, staked amounts, locked amounts, circulating supply, DIEM supply and cumulative burn data.

Contract Architecture

VVV is implemented as a compact smart contract inheriting two components: a Solmate ERC-20 module and a Solmate Owned module. The ERC-20 component provides token metadata, supply tracking, balance and allowance mappings, transfer and approval logic, permit logic, and internal mint and burn functions. The Owned component stores a single owner address, enforces the ownership restriction on protected functions and exposes an ownership transfer function. The VVV contract itself sets the token name, symbol and decimal precision, mints the initial supply to a treasury address at deployment, and exposes an external mint function callable only by the owner.

The owner-only mint function introduces a centralised supply authority. There is no on-chain timelock, multisignature enforcement or governance module constraining the exercise of that authority within the deployed contract.

Base Rollup Infrastructure

Base provides the Layer 2 infrastructure through which all VVV transactions are ordered, executed and settled. Three primary actor classes interact with the network: users, who submit transactions or query state; the sequencer, which orders transactions and produces Layer 2 blocks; and validators, which independently execute the Layer 2 state transition function and serve blockchain data. Base currently operates with a single active sequencer.

The sequencer accepts user transactions, observes deposit transactions from Ethereum, consolidates both streams into ordered Layer 2 blocks, and publishes sufficient information to Layer 1 for validators to independently reconstruct those blocks. Flashblocks are produced every 200 milliseconds, committing to transaction ordering within the block as it is being built. The Base rollup comprises five primary components: a consensus module that derives the canonical Layer 2 chain from Layer 1 data; a Reth-based execution engine; a batcher that compresses Layer 2 transaction data and posts it to Ethereum as calldata or blobs; a permissionless proof and dispute system; and a bridge for deposit and withdrawal flows between Base and Ethereum.

Runtime and Build Parameters

The VVV contract was compiled with Solidity 0.8.26, with optimisation enabled at 200 runs, targeting the Paris EVM version. These parameters are recorded in the verified contract metadata on BaseScan, which confirms the deployed bytecode as an exact match to the published source. The contract's Solmate dependency is version 6.8.0.

Data Availability and Proof System

The batcher compresses Layer 2 transaction data into channel frames and submits them to the Batch Inbox address on Ethereum, enabling validators to reconstruct the Layer 2 chain independently from Layer 1 data alone. Data availability for VVV transactions is therefore contingent on Ethereum publication by Base's batching process.

Base operates a permissionless output proposal and dispute system. Any party may propose an output root to the DisputeGameFactory contract; any party may challenge it. Disputes are resolved by the FaultDisputeGame contract using the Cannon virtual machine for on-chain execution tracing of disputed state transitions. Withdrawals from Base to Ethereum can be finalised through the OptimismPortal contract only after the associated dispute game resolves in favour of the proposer.

Deployment

VVV is deployed on Base Mainnet at contract address 0xacfE6019Ed1A7Dc6f7B508C02d1b04ec88cC21bf. Base Mainnet uses chain ID 8453.

VVV does not operate a separate consensus mechanism. Transaction ordering, block production, execution and finality are all inherited from Base.

Base derives the canonical Layer 2 chain from Ethereum Layer 1 data. The rollup node reads deposit transactions and sequencing batches from Layer 1 blocks, generates payload attributes and passes them to the execution engine to produce Layer 2 blocks. Validators execute the Layer 2 state transition function independently of the sequencer, synchronise data from both Layer 1 and the sequencer, and serve state to users. Validators may also act as proposers or challengers within the Layer 1 dispute system, submitting and contesting output roots.

Finality on Base progresses through four stages. Flashblock inclusion is reached in approximately 200 milliseconds; Layer 2 block inclusion at approximately two seconds; Layer 1 batch inclusion at approximately two minutes; and Layer 1 batch finality, at which point the corresponding Ethereum batch is older than two epochs, or 64 Layer 1 blocks, at approximately 15 minutes. Withdrawals from Base to Ethereum are subject to a separate 7-day challenge window before finalisation on Layer 1. VVV transfers within Base follow the ordinary Layer 2 finality path unless the transfer forms part of a withdrawal to Ethereum.

Network Fees

Every Base transaction incurs two cost components: a Layer 2 execution fee and a Layer 1 security fee. The Layer 2 execution fee is the cost of executing the transaction on Base; the Layer 1 security fee approximates the cost of publishing the transaction data on Ethereum. The Layer 1 component typically exceeds the Layer 2 component and varies with Ethereum network activity. The Layer 2 base fee adjusts dynamically with demand under the OP Stack implementation of EIP-1559, with an elasticity multiplier of 6, a base-fee-change denominator of 125, and a maximum per-block base-fee change of 4%. As part of the Jovian upgrade, a minimum Layer 2 base fee of 5,000,000 wei (0.005 gwei) applies to Base Mainnet, preventing the base fee from falling to negligible levels during periods of low activity.

The GasPriceOracle predeployment provides two Layer 1 fee estimation methods: one returning the exact Layer 1 fee for a fully serialised transaction, and one returning an upper-bound estimate based on approximate transaction byte length. VVV transfers, approvals, permit approvals and minting operations each consume Base transaction resources and are subject to these fees.

Transaction Ordering and Priority Fees

The sequencer builds blocks using Flashblocks and conducts priority-fee auctions every 200 milliseconds. Transactions with higher priority fees are included in earlier Flashblocks; once ordering within a Flashblock is committed, later-arriving transactions with higher priority fees cannot displace earlier inclusions. This ordering model governs all Base transactions, including VVV transfers and approvals.

Protocol-Level Fees

No transfer fee, approval fee, mint fee, tax or protocol surcharge is applied within the VVV token contract. A direct transfer updates two balances and emits a Transfer event. A delegated transfer updates the applicable allowance, updates balances and emits a Transfer event. An internal burn function reduces the caller's balance and the total supply, but no external burn function is exposed in the deployed contract.

Economic Flows

Beginning November 2025, a portion of monthly Venice AI platform revenue is used to purchase VVV from the open market and permanently remove it from circulation. This programmatic buy-and-burn mechanism links platform revenue growth to a reduction in token supply. Staked VVV earns yield through the platform's staking program; a minimum stake of 100 VVV also provides access to Venice Pro. Stakers who lock their staked position may mint DIEM, which provides one dollar of Venice AI credit per day.

Governance of Parameters

Base network-level protocol parameters are governed through the Base Security Council, a body composed of 12 entities comprising 11 Security Council members and Coinbase. A supermajority of 9 out of 12 entities is required to approve any Base protocol upgrade or role change before it may take effect. Council members are required to verify, approve and sign proposed upgrades and role changes.

At the token level, supply parameters are governed by the owner role in the deployed contract. The owner may call the external mint function to issue additional VVV and may transfer ownership to a new address. No on-chain voting, timelock, multisignature enforcement or upgrade module is present within the VVV contract.

FALSE

FALSE

The VVV token contract itself has not been independently audited, but the Base/OP Stack infrastructure has been audited by multiple firms:

Trail of Bits, Optimism SystemConfig and Withdrawal Updates Security Assessment, 2023

• Object: Trail of Bits conducted a security review of the OP Stack's system configuration workflow and two-step withdrawal process on behalf of OP Labs, covering the SystemConfig contract, the op-node, op-geth, and the OptimismPortal contract. The review was conducted from November 14 to December 9, 2022 with eight person-weeks of effort.
• Results: The assessment identified one finding. It was classified as high severity. The finding concerned the ability of an attacker to block a user's withdrawal by repeatedly resubmitting withdrawal proofs to the OptimismPortal contract, resetting the seven-day finalization period with each submission.
• Actions: The OP Labs team resolved the finding by updating the proveWithdrawalTransaction function to permit re-proving only where the outputRoot value of the L2ToL1MessagePasser contract had changed. The fix was reviewed and confirmed as resolved by Trail of Bits on December 13, 2022.

Market volatility and liquidity

VVV may experience significant price volatility and variable liquidity across trading venues. Limited market depth can widen spreads and increase slippage, particularly around new listings, large orders, or periods of broader market stress. Investment in VVV can result in partial or total loss of capital.

Irreversibility and settlement finality

VVV transfers on Base become irreversible once finality is reached. Erroneous, fraudulent, or misdirected transfers cannot be reversed at protocol level; any corrective outcome depends on the control of the relevant private keys or voluntary off-chain arrangements. Base finality progresses through four stages, with full Layer 1 batch finality reached in approximately 15 minutes and a separate 7-day challenge window applying to withdrawals to Ethereum.

Access restrictions

Access to VVV related services may be affected by jurisdictional restrictions, and platform terms. Venice AI may restrict access where applicable laws or compliance requirements apply, and specific features may be unavailable in particular jurisdictions.

Delisting Risks

Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.

Issuer identification and jurisdictional exposure

Venice.ai, Inc. is a Wyoming corporation. Its services and operations may be affected by laws, compliance requirements, or jurisdictional restrictions applicable either to Venice AI or to its users.

Platform discretion over access and credits

Venice AI retains discretion over service access, API access, and Venice Credits. Venice Credits are non-transferable and Venice AI may modify, limit, or discontinue the Venice Credit system, which can affect service-related expectations connected to VVV staking and API utility.

Third-party service dependency

Venice AI services may rely on third-party software, services, and model-provider infrastructure. Failures, changes, or restrictions affecting those providers can impair output quality, service availability, or the continuity of Venice-related services, which in turn can affect the practical utility of staked VVV.

Data handling and privacy exposure

Venice AI may process account information, technical identifiers, browser data, and interaction data. Certain categories of this information may be disclosed to affiliates, vendors, service providers, or legally required recipients, creating privacy and data-governance exposure for users.

Token utility and platform dependency

VVV's utility is contingent on the continued operation and adoption of the Venice AI platform. Demand for VVV is linked to demand for Venice AI services, including API access via the staking and wallet-based API key flow and DIEM minting. A material decline in platform usage would reduce the economic rationale for holding or staking VVV.

Token contract and staking-contract dependency

VVV is an ERC-20 token deployed on Base and relies on a separate Venice AI staking contract for the API key flow. Faults, configuration errors, or operational issues affecting either contract can impair token use or staking-linked access. No official audit of the VVV token contract or the Venice AI staking contract has been published.

Centralised supply authority

The deployed VVV contract includes an owner-only external mint function with no on-chain supply cap beyond the initial 100,000,000 VVV minted at deployment. The contract owner may issue additional VVV at any time. The current owner address, key-custody arrangements, and any governance policies limiting the exercise of the mint function are not publicly disclosed. This concentrates supply authority in a single role without on-chain constraint.

Self-custody and private-key loss

VVV holders rely on the secure management of wallets and private keys. Loss, theft, or compromise of the relevant keys results in permanent, irrecoverable loss of control over VVV. Where VVV is used to access Venice AI's API through the staking flow, the wallet private key used to sign token requests must also be safeguarded; its compromise can affect both token control and service access.

Supply visibility and market impact

VVV supply and token activity are publicly visible through BaseScan, including the token contract and maximum total supply. Large or closely sequenced transfers can nonetheless affect liquidity and execution quality where market depth is limited. The ongoing buy-and-burn mechanism reduces circulating supply over time, but the rate and market impact of each burn event cannot be predicted.

Service availability and operational continuity

Venice AI does not warrant that its services will be uninterrupted or error-free. Outages, maintenance windows, rate limits, or events beyond Venice AI's control can affect access to the Venice App, Venice API, Venice API Docs, and VVV-linked service utility.

API and product-change risk

Venice AI's API supports chat, image generation, audio synthesis, and character functions, and is designed for OpenAI-compatible integration. Changes to service features, usage limits, pricing, or API compatibility can affect developers and users who have built systems around Venice AI endpoints. Demo and trial limits are subject to change without notice.

Privacy-mode implementation dependency

Venice AI privacy protections vary by mode. Anonymous, private, trusted-execution-environment, and end-to-end-encrypted modes each rely on different technical and third-party arrangements, and some modes carry feature limitations. The scope of protection depends on the mode selected and on the availability and commitments of any external technical partners involved.

Documentation and client-software dependency

Venice AI maintains official API documentation and public repositories for documentation, command-line tooling, and payment-client software. Errors, delays, or breaking changes in these materials or tools can affect developer integrations and operational reliability.

API-linked utility access

VVV's service utility is connected to Venice AI's API access mechanism, whereby a Base wallet acquires and stakes VVV to generate an API key. If payment conditions, account status, API terms, or access conditions are not satisfied, service access may be downgraded, suspended, or revoked, which can impair the practical utility of staked VVV.

Output reliability and user reliance

AI-generated outputs from Venice AI services may be incomplete, incorrect, or unreliable. Users relying on Venice AI outputs for consequential decisions may face loss or operational error where outputs are inaccurate or unsuitable for the intended purpose.

Base network dependency

VVV is deployed on Base and inherits Base's operational characteristics. Base operates as an Ethereum rollup, posts Layer 2 data to Ethereum for data availability, uses a batcher, and currently operates with a single active sequencer. Sequencer disruption, congestion, or policy changes can delay transaction ordering or impair normal VVV transfer and staking-related operations on Base.

Base sequencer centralisation

Base currently operates with a single active sequencer. Sequencer disruption can delay transaction ordering and temporarily impair VVV transfers, approvals, and staking interactions. The sequencer's control over transaction ordering also creates exposure to maximal extractable value practices that could disadvantage users in time-sensitive operations.

Base withdrawals and bridge finalisation

Withdrawals of assets from Base to Ethereum require Layer 2 withdrawal initiation, output-root availability, challenge-period resolution, and Layer 1 finalisation. This multi-stage process creates timing and operational risk for users seeking to move assets or liquidity between Base and Ethereum, with the finalisation window spanning 7 days.

Fault-proof and dispute-game dependency

Base's fault-proof system consists of a program, a virtual machine, and an interactive dispute game managed through the FaultDisputeGame contract. Defects, coordination failures, or delays in this challenge process can affect the correctness and finalisation path for cross-domain activity involving VVV.

Bridge administrative-role exposure

Base bridge materials describe legacy proposer and challenger roles, including a challenger role carrying broad administrative privileges that can affect the outcome of cross-domain operations. Privileged bridge roles and their correct operation represent a residual governance risk that VVV transactions involving Ethereum interactions inherit.

Smart-contract defect and audit-evidence gap

VVV and the Venice AI staking flow depend on token and staking smart contracts on Base. No official audit report for the VVV token contract or the Venice AI staking contract has been published. Undetected vulnerabilities in either contract could result in token loss, erroneous state changes, or denial of service for staking-linked functionality.

VVV token administrative-control evidence gap

The VVV contract source confirms the existence of an owner-only mint function, but does not disclose the full set of administrative controls held by the current contract owner. Whether supplementary controls — such as upgrade authority, pausing mechanisms, or transfer restrictions implemented outside the visible token contract — exist has not been publicly evidenced.

Quantum computing

VVV transactions on Base are authenticated using ECDSA with the secp256k1 elliptic curve, which is the standard Ethereum transaction signature scheme. A cryptographically sufficiently capable quantum computer running Shor's algorithm could, in principle, derive private keys from publicly observed signatures or exposed public keys, threatening account security across all EVM-compatible chains. Keccak-256, used for hashing within the VVV permit mechanism and throughout the EVM, offers stronger structural resistance to quantum attack through Grover's algorithm but would see its effective security margin halved. As of the date of this white paper, no post-quantum signature migration pathway has been formalised for Base or Ethereum, and the transition timeline to cryptographically relevant quantum computing remains uncertain. This represents a structural long-term risk to all ECDSA-secured accounts, including those holding VVV.

Offer-Related Risks

• Irreversibility and settlement finality: Base publishes defined finality stages, including the four-stage Layer 2 finality path and the 7-day withdrawal window for Ethereum exits. This makes settlement timing transparent to users and integrators, enabling informed operational decisions about transfer irreversibility.
• Listing, venue and access restrictions: Venice AI publishes its terms of service, which define the circumstances under which access may be restricted or revoked. Holders are informed at the point of engagement that jurisdictional restrictions may apply and that each user is responsible for compliance with their applicable laws.

Issuer-Related Risks

• Data handling and privacy exposure: Venice AI publishes a privacy policy covering the categories of data collected, the purposes of processing, and the categories of third parties to whom data may be disclosed. Venice AI states it does not sell or share personal information for cross-context behavioural advertising.
• Third-party service dependency: Venice AI's terms of service identify third-party services as separate from Venice AI's own services, allocate responsibility boundaries between Venice AI and external model providers, and state that Venice AI does not control, direct, or endorse third-party model output. This limits the scope of Venice AI's contractual responsibility for third-party failures.

Crypto-Asset-Related Risks

• Token contract and staking-contract dependency: The VVV token contract address is identified in official Venice AI materials and is accessible through BaseScan with verified source code status. The Venice AI staking contract address is referenced in official developer documentation. Public identification of both contracts reduces address-substitution and integration-error risk for users and developers.
• Supply visibility and market impact: BaseScan reports VVV token supply information in real time, including the maximum total supply and token-contract data. The programmatic buy-and-burn mechanism, active from November 2025, provides a publicly observable deflationary flow linked to platform revenue. These features allow public verification of supply dynamics.
• Self-custody and private-key loss: Venice AI's agent documentation recommends using a dedicated agent wallet for the staking-linked API key flow rather than a primary wallet, reducing the exposure of primary key holdings where the API feature is used. This recommendation does not eliminate the underlying custody risk.

Project Implementation-Related Risks

• Service availability and operational continuity: Venice AI maintains a public status page covering the operational status of the Venice App, Venice API, and Venice API Docs, providing a public channel for incident visibility independent of Venice AI's direct communications.
• Documentation and client-software dependency: Venice AI maintains official documentation, a documentation index, and public repositories for API docs, command-line tooling, and x402 client software, providing developers with official implementation references.
• Privacy-mode implementation dependency: Venice AI discloses the technical architecture of each privacy mode, including the dependency structure and feature limitations of anonymous, private, trusted-execution-environment, and end-to-end-encrypted modes. This allows users to select a mode with an informed understanding of its protection scope and trade-offs.
• Base network dependency: Base posts compressed Layer 2 transaction data to Ethereum and operates validators that independently execute the Layer 2 state transition function, anchoring data availability and state correctness to Ethereum. This provides structural resilience for VVV transaction data independent of Base's sequencer availability.

Technology-Related Risks

• Base sequencer centralisation: Base validators execute the Layer 2 state transition function independently of the sequencer and can reconstruct the Layer 2 chain from Ethereum Layer 1 data. This provides a pathway for state recovery and independent verification even in the event of sequencer disruption.
• Fault-proof and dispute-game dependency: Base allows output roots to be challenged by any party using the FaultDisputeGame contract and the Cannon virtual machine for on-chain execution tracing. This permissionless challenge mechanism provides a structural check against incorrect state transitions.
• Base withdrawals and bridge finalisation: The 7-day challenge window before Ethereum finalisation is a defined and publicly documented protocol parameter. Users can plan cross-domain operations around this timeline and verify the status of pending withdrawals through publicly available bridge interfaces.

Bitstamp Europe S.A.

549300XIBGTJ0PLIEO72

Venice token

VVV does not operate a separate consensus mechanism. Transaction ordering, block production, execution and finality are all inherited from Base.

Base derives the canonical Layer 2 chain from Ethereum Layer 1 data. The rollup node reads deposit transactions and sequencing batches from Layer 1 blocks, generates payload attributes and passes them to the execution engine to produce Layer 2 blocks. Validators execute the Layer 2 state transition function independently of the sequencer, synchronise data from both Layer 1 and the sequencer, and serve state to users. Validators may also act as proposers or challengers within the Layer 1 dispute system, submitting and contesting output roots.

Finality on Base progresses through four stages. Flashblock inclusion is reached in approximately 200 milliseconds; Layer 2 block inclusion at approximately two seconds; Layer 1 batch inclusion at approximately two minutes; and Layer 1 batch finality, at which point the corresponding Ethereum batch is older than two epochs, or 64 Layer 1 blocks, at approximately 15 minutes. Withdrawals from Base to Ethereum are subject to a separate 7-day challenge window before finalisation on Layer 1. VVV transfers within Base follow the ordinary Layer 2 finality path unless the transfer forms part of a withdrawal to Ethereum.

See H.5

2026-05-08

2026-05-28

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at : www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Land use: 0.14661 m²

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Estimates on individual node weight, hazardous components and depreciation rate are used.
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Usage of natural resources is approximated through land use metrics. Land use, water use and water recycling are calculated based on energy mix-specific estimates of purchased electricity land intensity, purchased electricity water intensity, and water recycling rates. Full methodology available at: www.micacryptoalliance.com/methodologies