White paper drafted under the European Markets in Crypto-Assets Regulation (EU) 2023/1114 for FFG LZ3V3Z6FD
Preamble
00. Table of Content
- Preamble
- 01. Date of notification
- 02. Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114
- 03. Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114
- 04. Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114
- 05. Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114
- 06. Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114
- Summary
- 07. Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114
- 08. Characteristics of the crypto-asset
- 09. Information about the quality and quantity of goods or services to which the utility tokens give access and restrictions on the transferability
- 10. Key information about the offer to the public or admission to trading
- Part A – Information about the offeror or the person seeking admission to trading
- A.1 Name
- A.2 Legal form
- A.3 Registered address
- A.4 Head office
- A.5 Registration date
- A.6 Legal entity identifier
- A.7 Another identifier required pursuant to applicable national law
- A.8 Contact telephone number
- A.9 E-mail address
- A.10 Response time (Days)
- A.11 Parent company
- A.12 Members of the management body
- A.13 Business activity
- A.14 Parent company business activity
- A.15 Newly established
- A.16 Financial condition for the past three years
- A.17 Financial condition since registration
- Part B – Information about the issuer, if different from the offeror or person seeking admission to trading
- B.1 Issuer different from offeror or person seeking admission to trading
- B.2 Name
- B.3 Legal form
- B4. Registered address
- B.5 Head office
- B.6 Registration date
- B.7 Legal entity identifier
- B.8 Another identifier required pursuant to applicable national law
- B.9 Parent company
- B.10 Members of the management body
- B.11 Business activity
- B.12 Parent company business activity
- 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
- C.1 Name
- C.2 Legal form
- C.3 Registered address
- C.4 Head office
- C.5 Registration date
- C.6 Legal entity identifier
- C.7 Another identifier required pursuant to applicable national law
- C.8 Parent company
- C.9 Reason for crypto-Asset white paper Preparation
- C.10 Members of the Management body
- C.11 Operator business activity
- C.12 Parent company business activity
- C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
- C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
- Part D – Information about the crypto-asset project
- D.1 Crypto-asset project name
- D.2 Crypto-assets name
- D.3 Abbreviation
- D.4 Crypto-asset project description
- D.5 Details of all natural or legal persons involved in the implementation of the crypto-asset project
- D.6 Utility Token Classification
- D.7 Key Features of Goods/Services for Utility Token Projects
- D.8 Plans for the token
- D.9 Resource allocation
- D.10 Planned use of Collected funds or crypto-Assets
- Part E – Information about the offer to the public of crypto-assets or their admission to trading
- E.1 Public offering or admission to trading
- E.2 Reasons for public offer or admission to trading
- E.3 Fundraising target
- E.4 Minimum subscription goals
- E.5 Maximum subscription goals
- E.6 Oversubscription acceptance
- E.7 Oversubscription allocation
- E.8 Issue price
- E.9 Official currency or any other crypto-assets determining the issue price
- E.10 Subscription fee
- E.11 Offer price determination method
- E.12 Total number of offered/traded crypto-assets
- E.13 Targeted holders
- E.14 Holder restrictions
- E.15 Reimbursement notice
- E.16 Refund mechanism
- E.17 Refund timeline
- E.18 Offer phases
- E.19 Early purchase discount
- E.20 Time-limited offer
- E.21 Subscription period beginning
- E.22 Subscription period end
- E.23 Safeguarding arrangements for offered funds/crypto- Assets
- E.24 Payment methods for crypto-asset purchase
- E.25 Value transfer methods for reimbursement
- E.26 Right of withdrawal
- E.27 Transfer of purchased crypto-assets
- E.28 Transfer time schedule
- E.29 Purchaser's technical requirements
- E.30 Crypto-asset service provider (CASP) name
- E.31 CASP identifier
- E.32 Placement form
- E.33 Trading platforms name
- E.34 Trading platforms Market identifier code (MIC)
- E.35 Trading platforms access
- E.36 Involved costs
- E.37 Offer expenses
- E.38 Conflicts of interest
- E.39 Applicable law
- E.40 Competent court
- Part F – Information about the crypto-assets
- F.1 Crypto-asset type
- F.2 Crypto-asset functionality
- F.3 Planned application of functionalities
- A description of the characteristics of the crypto asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article
- F.4 Type of crypto-asset white paper
- F.5 The type of submission
- F.6 Crypto-asset characteristics
- F.7 Commercial name or trading name
- F.8 Website of the issuer
- F.9 Starting date of offer to the public or admission to trading
- F.10 Publication date
- F.11 Any other services provided by the issuer
- F.12 Language or languages of the crypto-asset white paper
- F.13 Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates
- F.14 Functionally fungible group digital token identifier
- F.15 Voluntary data flag
- F.16 Personal data flag
- F.17 LEI eligibility
- F.18 Home Member State
- F.19 Host Member States
- Part G – Information on the rights and obligations attached to the crypto-assets
- G.1 Purchaser rights and obligations
- G.2 Exercise of rights and obligations
- G.3 Conditions for modifications of rights and obligations
- G.4 Future public offers
- G.5 Issuer retained crypto-assets
- G.6 Utility token classification
- G.7 Key features of goods/services of utility tokens
- G.8 Utility tokens redemption
- G.9 Non-trading request
- G.10 Crypto-assets purchase or sale modalities
- G.11 Crypto-assets transfer restrictions
- G.12 Supply adjustment protocols
- G.13 Supply adjustment mechanisms
- G.14 Token value protection schemes
- G.15 Token value protection schemes description
- G.16 Compensation schemes
- G.17 Compensation schemes description
- G.18 Applicable law
- G.19 Competent court
- Part H – information on the underlying technology
- H.1 Distributed ledger technology (DTL)
- H.2 Protocols and technical standards
- H.3 Technology used
- H.4 Consensus mechanism
- H.5 Incentive mechanisms and applicable fees
- H.6 Use of distributed ledger technology
- H.7 DLT functionality description
- H.8 Audit
- H.9 Audit outcome
- Part I – Information on risks
- I.1 Offer-related risks
- I.2 Issuer-related risks
- I.3 Crypto-assets-related risks
- I.4 Project implementation-related risks
- I.5 Technology-related risks
- I.6 Mitigation measures
- Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
- J.1 Adverse impacts on climate and other environment-related adverse impacts
- S.1 Name
- S.2 Relevant legal entity identifier
- S.3 Name of the cryptoasset
- S.4 Consensus Mechanism
- S.5 Incentive Mechanisms and Applicable Fees
- S.6 Beginning of the period to which the disclosure relates
- S.7 End of the period to which the disclosure relates
- S.8 Energy consumption
- S.9 Energy consumption sources and methodologies
- S.10 Renewable energy consumption
- S.11 Energy intensity
- S.12 Scope 1 DLT GHG emissions – Controlled
- S.13 Scope 2 DLT GHG emissions – Purchased
- S.14 GHG intensity
- S.15 Key energy sources and methodologies
- S.16 Key GHG sources and methodologies
01. Date of notification
02. Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114
03. Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114
04. Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114
05. Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114
06. Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114
Summary
07. Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114
08. Characteristics of the crypto-asset
PancakeSwap is a decentralised protocol implemented through smart contracts on supported blockchain networks. The project provides an infrastructure that allows users to interact directly with on-chain liquidity pools and other protocol-defined functions without reliance on a central intermedi ary.
Any functionalities accessible through the underlying technology are purely technical or operational in nature and do not confer rights comparable to ownership, profit participation, governance, or similar entitlements known from traditional financial instruments.
09. Information about the quality and quantity of goods or services to which the utility tokens give access and restrictions on the transferability
Not applicable.
10. Key information about the offer to the public or admission to trading
The token has been admitted to trading to the trading platform operated by Bitstamp Europe S.A. on its own initiative.
Part A – Information about the offeror or the person seeking admission to trading
A.1 Name
A.2 Legal form
A.3 Registered address
A.4 Head office
A.5 Registration date
A.6 Legal entity identifier
A.7 Another identifier required pursuant to applicable national law
A.8 Contact telephone number
A.9 E-mail address
A.10 Response time (Days)
A.11 Parent company
A.12 Members of the management body
A.13 Business activity
A.14 Parent company business activity
A.15 Newly established
A.16 Financial condition for the past three years
A.17 Financial condition since registration
Part B – Information about the issuer, if different from the offeror or person seeking admission to trading
B.1 Issuer different from offeror or person seeking admission to trading
B.2 Name
B.3 Legal form
B4. Registered address
B.5 Head office
B.6 Registration date
B.7 Legal entity identifier
B.8 Another identifier required pursuant to applicable national law
B.9 Parent company
B.10 Members of the management body
| Identity | Function | Business Address |
|---|---|---|
B.11 Business activity
Not applicable.
B.12 Parent company business activity
Not applicable.
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
C.1 Name
C.2 Legal form
C.3 Registered address
C.4 Head office
C.5 Registration date
C.6 Legal entity identifier
C.7 Another identifier required pursuant to applicable national law
C.8 Parent company
C.9 Reason for crypto-Asset white paper Preparation
As a MiCAR-licensed operator of the trading platform, Bitstamp Europe S.A. shall comply with the requirements set out in Article 5 of MiCAR when admitting to trading on its own initiative a crypto-asset for which no white paper has been published in accordance with MiCAR. In such cases, including admission of the token to trading, Bitstamp Europe S.A. shall provide, notify and publishing the crypto-asset white paper in accordance with the relevant provisions of MiCAR.
C.10 Members of the Management body
| Identity | Function | Business Address |
|---|---|---|
C.11 Operator business activity
Bitstamp Europe S.A. is a Crypto-Asset Service Provider authorized 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 authorized with 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.
C.12 Parent company business activity
Robinhood Markets, Inc is the holding company for the Robinhood group.
C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Crypto Risk Metrics GmbH, Lange Reihe 73, 20099 Hamburg
C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Crypto Risk Metrics GmbH, Lange Reihe 73, 20099 Hamburg, was mandated to draw up the white paper by Bitstamp Europe S.A.
Part D – Information about the crypto-asset project
D.1 Crypto-asset project name
D.2 Crypto-assets name
D.3 Abbreviation
D.4 Crypto-asset project description
PancakeSwap is a decentralised protocol implemented through smart contracts on supported blockchain networks. The project provides an infrastructure that allows users to interact directly with on-chain liquidity pools and other protocol-defined functions without reliance on a central intermediary.
The PancakeSwap protocol is primarily used for the exchange of crypto-assets through automated mechanisms governed by smart contracts. In addition to exchange functionality, the protocol supports further on-chain features such as liquidity provision, governance participation, and other decentralised application functions defined at the protocol level. User interaction with the protocol occurs via publicly accessible interfaces that communicate with the underlying smart contracts.
The CAKE crypto-asset is a cryptographic token associated with the PancakeSwap protocol. Its functionality is defined exclusively by the protocol rules and smart contracts deployed on the supported blockchain networks. CAKE does not represent ownership, equity, or a claim against any legal entity. The token’s role is limited to enabling participation in protocol-defined mechanisms, including governance processes and incentive structures, as specified by the applicable version of the protocol.
The PancakeSwap project has undergone several protocol and tokenomics iterations over time.
D.5 Details of all natural or legal persons involved in the implementation of the crypto-asset project
| Type of person | Name of person | Business address of person | Domicile of company |
|---|---|---|---|
D.6 Utility Token Classification
D.7 Key Features of Goods/Services for Utility Token Projects
Not applicable.
D.8 Plans for the token
This section provides an overview of the historical developments related to the PancakeSwap crypto-asset and a description of planned or anticipated project milestones as publicly communicated. All forward-looking elements are subject to significant uncertainty. They do not constitute commitments, assurances, or guarantees and may be modified, delayed, or discontinued at any time. Past developments cannot be assumed to continue, and changes may affect token holders.
Past milestones:
- Project launch and early protocol deployment (2020):
Public materials indicate that the PancakeSwap protocol was launched in 2020 as a decentralised application implemented through smart contracts on supported blockchain networks. Early development focused on enabling on-chain token exchange functionality and related protocol features.
- Protocol expansion and feature additions (2020–2022):
Following its initial deployment, PancakeSwap underwent a phase of continued development, including the introduction of additional protocol functionalities such as liquidity provision mechanisms, governance features, and other decentralised application components, as reflected in publicly available documentation.
- Tokenomics revisions and protocol adjustments (2022–2023):
Public disclosures indicate that the PancakeSwap project implemented multiple revisions to its tokenomics and protocol parameters over time. These changes were introduced through governance processes and protocol updates, reflecting an evolving framework rather than a static design.
Future milestones:
- Ongoing protocol maintenance and upgrades:
Public roadmap materials indicate an intention to continue maintaining and updating the PancakeSwap protocol. Such updates may include changes to smart contract implementations, protocol parameters, or supported functionalities, subject to governance decisions and technical feasibility.
- Tokenomics framework application and refinement:
According to publicly available information, the PancakeSwap project currently operates under a revised tokenomics framework commonly referred to as CAKE Tokenomics v3 (“CAKE 3.0”). The continued application, modification, or replacement of this framework is subject to governance processes and may evolve over time.
- Ecosystem-related initiatives:
Public communications reference potential future activities aimed at supporting broader ecosystem participation, including protocol usage, tooling, or integration-related efforts. The scope, timing, and outcome of such initiatives remain uncertain and dependent on governance decisions, resource availability, and external factors.
All described future developments represent intended or potential milestones only. They remain dependent on technological feasibility, resource allocation, regulatory considerations, and general project priorities. There is no certainty that these developments will occur, occur as described, or be maintained in the long term. Deviations from the roadmap may occur without prior notice, and changes may negatively affect the usability or relevance of the token.
D.9 Resource allocation
Publicly available project documentation indicates that the allocation and distribution of the CAKE crypto-asset have evolved over time through several iterations of the PancakeSwap tokenomics framework. The protocol has implemented multiple versions of its tokenomics, with CAKE Tokenomics v3 (“CAKE 3.0”) being applicable at the time of drafting. These changes reflect protocol-level adjustments rather than a single, fixed allocation framework established at launch.
Under the PancakeSwap protocol, CAKE units have historically been allocated through protocol-defined emission mechanisms, primarily in connection with participation in protocol activities such as liquidity provision and other smart-contract-based functions. Emission parameters, allocation logic, and supply reduction measures have been modified over time through governance decisions and protocol updates.
Resource allocation within the PancakeSwap project is therefore determined by predefined protocol rules and governance processes, rather than by a centralised project budget or discretionary allocation by a single entity.
D.10 Planned use of Collected funds or crypto-Assets
Not applicable, as this white paper was drawn up for the admission to trading and not for collecting funds for the crypto-asset-project.
Part E – Information about the offer to the public of crypto-assets or their admission to trading
E.1 Public offering or admission to trading
E.2 Reasons for public offer or admission to trading
Bitstamp Europe S.A. has admitted the token to trading based on its market considerations.
E.3 Fundraising target
E.4 Minimum subscription goals
E.5 Maximum subscription goals
E.6 Oversubscription acceptance
E.7 Oversubscription allocation
E.8 Issue price
E.9 Official currency or any other crypto-assets determining the issue price
E.10 Subscription fee
E.11 Offer price determination method
E.12 Total number of offered/traded crypto-assets
E.13 Targeted holders
E.14 Holder restrictions
E.15 Reimbursement notice
E.16 Refund mechanism
E.17 Refund timeline
E.18 Offer phases
E.19 Early purchase discount
E.20 Time-limited offer
E.21 Subscription period beginning
E.22 Subscription period end
E.23 Safeguarding arrangements for offered funds/crypto- Assets
E.24 Payment methods for crypto-asset purchase
E.25 Value transfer methods for reimbursement
E.26 Right of withdrawal
E.27 Transfer of purchased crypto-assets
E.28 Transfer time schedule
E.29 Purchaser's technical requirements
E.30 Crypto-asset service provider (CASP) name
E.31 CASP identifier
E.32 Placement form
E.33 Trading platforms name
E.34 Trading platforms Market identifier code (MIC)
E.35 Trading platforms access
Investors can access the trading platform through https://www.bitstamp.net or via the Bitstamp applications.
E.36 Involved costs
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.
E.37 Offer expenses
Not applicable, as Bitstamp Europe S.A. has only admitted token to trading on its platform on its own initiative and has not been involved in offering the token to the public.
E.38 Conflicts of interest
There are no conflicts of interest of the persons involved in the 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.
E.39 Applicable law
Not applicable, as this point pertains to an "offer to the public," whereas this white paper relates to admission to trading.
E.40 Competent court
Not applicable, as this point pertains to an "offer to the public," whereas this white paper relates to admission to trading.
Part F – Information about the crypto-assets
F.1 Crypto-asset type
F.2 Crypto-asset functionality
The CAKE crypto-asset is a cryptographic token used within the PancakeSwap protocol. PancakeSwap is a decentralised application that operates through smart contracts on supported blockchain networks and enables the exchange of digital assets and related protocol functions.
Within the PancakeSwap protocol, CAKE is used in connection with governance mechanisms, allowing holders to participate in protocol governance processes in accordance with predefined rules implemented in smart contracts.
CAKE is also used in relation to protocol participation and incentive mechanisms. Depending on the applicable protocol configuration, CAKE may be required, locked, or distributed in connection with activities such as liquidity provision, staking, or other protocol-defined participation functions.
In addition, CAKE may be used in connection with protocol features and services that require interaction with smart contracts, including access to specific functions of the exchange as defined by the protocol parameters.
Transfers of CAKE are executed on the underlying blockchain networks on which PancakeSwap is deployed and are recorded on the respective distributed ledgers. The functionality of CAKE is limited to the uses enabled by the protocol and may change over time as protocol parameters or governance decisions are updated.
F.3 Planned application of functionalities
See D.8.
A description of the characteristics of the crypto asset, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article
F.4 Type of crypto-asset white paper
F.5 The type of submission
F.6 Crypto-asset characteristics
The tokens are crypto-assets other than EMTs and ARTs, which are available on the Ethereum, BNB Smart Chain, Polygon zkEVM, Aptos, Base, zkSync Era, Arbitrum and Linea blockchain. The tokens are fungible. The tokens are a digital representation of value, and have no inherent rights attached as well as no intrinsic utility.
F.7 Commercial name or trading name
F.8 Website of the issuer
F.9 Starting date of offer to the public or admission to trading
F.10 Publication date
F.11 Any other services provided by the issuer
It is not possible to exclude a possibility that the issuer of the token provides or will provide other services not covered by Regulation (EU) 2023/1114 (i.e. MiCAR).
F.12 Language or languages of the crypto-asset white paper
F.13 Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates
F.14 Functionally fungible group digital token identifier
F.15 Voluntary data flag
F.16 Personal data flag
F.17 LEI eligibility
F.18 Home Member State
F.19 Host Member States
Part G – Information on the rights and obligations attached to the crypto-assets
G.1 Purchaser rights and obligations
No legally binding real or contractual obligations are linked to the crypto-asset. The technically possible governance participations and functionalities described in F.2 cannot be independently verified and it cannot be guaranteed that these promises have legal binding force that an investor can enforce.
G.2 Exercise of rights and obligations
As the token grants no legal binding rights nor obligations, there are no procedures and conditions for the exercise of these rights applicable.
The promise of governance participation is based on technical circumstances and relies on smart contract functionalities and voting platforms. It is not certain whether this infrastructure will be available for use of these governance functions on a permanent basis.
G.3 Conditions for modifications of rights and obligations
As the token grants no legal binding rights nor obligations, there are no procedures and conditions for the exercise of these rights applicable.
An adjustment of the technical infrastructure necessary to exercise the promised governance rights, declining functionality due to dilution, changing rights within the voting platforms, and all other adverse effects for investors may occur at any time.
G.4 Future public offers
Information on the future offers to the public of crypto-assets were not available at the time of writing this white paper (2025-12-21).
G.5 Issuer retained crypto-assets
G.6 Utility token classification
G.7 Key features of goods/services of utility tokens
G.8 Utility tokens redemption
G.9 Non-trading request
G.10 Crypto-assets purchase or sale modalities
G.11 Crypto-assets transfer restrictions
The crypto-assets as such do not have any transfer restrictions and are generally freely transferable. Bitstamp will employ the same restrictions to the token as to the other crypto-assets listed on their trading platform and strictly abide by the applicable laws in the European Union.
G.12 Supply adjustment protocols
G.13 Supply adjustment mechanisms
Although the PancakeSwap protocol does not implement demand-responsive supply adjustment protocols, it provides for protocol-defined mechanisms that affect the total and circulating supply of CAKE over time.
According to official PancakeSwap documentation, the CAKE tokenomics framework has evolved through several iterations, with CAKE Tokenomics v3 (“CAKE 3.0”) being the version applicable at the time of drafting. Under this framework, CAKE issuance and supply reduction are governed by predefined protocol rules and on-chain governance decisions.
New CAKE units may be issued through incentive and reward mechanisms associated with protocol participation, including liquidity provision and other protocol-defined activities. Emission parameters are set at the protocol level and may be modified through governance processes. These emissions increase the total supply of CAKE but are not linked to market demand indicators.
G.14 Token value protection schemes
G.15 Token value protection schemes description
G.16 Compensation schemes
G.17 Compensation schemes description
G.18 Applicable law
The token is not subject to any predetermined applicable law. Applicable law likely depends on the location of any particular party and/or the location of any particular transaction with the token.
G.19 Competent court
The token is not subject to any predetermined court jurisdiction. Competent court likely depends on the location of any particular party and/or the location of any particular transaction with the token.
Part H – information on the underlying technology
H.1 Distributed ledger technology (DTL)
Bitstamp Europe S.A. is not involved either in maintenance or in development of the distributed ledger technology used to issue the token or to validate its transfers. The description below is based on information publicly available at the time of preparation of this white paper.
The crypto-asset in scope is implemented on the Ethereum, BNB Smart Chain, Polygon zkEVM, Aptos, Base, zkSync Era, Arbitrum and Linea network following the standards described below.
H.2 Protocols and technical standards
The crypto asset that is the subject of this white paper is available on the Ethereum, BNB Smart Chain, Polygon zkEVM, Aptos, Base, zkSync Era, Arbitrum and Linea network.
The following applies to Ethereum:
The crypto-asset operates on a well-defined set of protocols and technical standards that are intended to ensure its security, decentralization, and functionality. Below are some of the key ones:
1. Network Protocols
The crypto-asset follows a decentralized, peer-to-peer (P2P) protocol where nodes communicate over the crypto-asset's DevP2P protocol using RLPx for data encoding.
- Transactions and smart contract execution are secured through Proof-of-Stake (PoS) consensus.
- Validators propose and attest blocks in Ethereum’s Beacon Chain, finalized through Casper FFG.
- The Ethereum Virtual Machine (EVM) executes smart contracts using Turing-complete bytecode.
2. Transaction and Address Standards
crypto-asset Address Format: 20-byte addresses derived from Keccak-256 hashing of public keys.
Transaction Types:
- Legacy Transactions (pre-EIP-1559)
- Type 0 (Pre-EIP-1559 transactions)
- Type 1 (EIP-2930: Access list transactions)
- Type 2 (EIP-1559: Dynamic fee transactions with base fee burning)
The Pectra upgrade introduces EIP-7702, a transformative improvement to account abstraction. This allows externally owned accounts (EOAs) to temporarily act as smart contract wallets during a transaction. It provides significant flexibility, enabling functionality such as sponsored gas payments and batched operations without changing the underlying account model permanently.
3. Blockchain Data Structure & Block Standards
- the crypto-asset's blockchain consists of accounts, smart contracts, and storage states, maintained through Merkle Patricia Trees for efficient verification.
Each block contains:
- Block Header: Parent hash, state root, transactions root, receipts root, timestamp, gas limit, gas used, proposer signature.
- Transactions: Smart contract executions and token transfers.
- Block Size: No fixed limit; constrained by the gas limit per block (variable over time). In line with Ethereum’s scalability roadmap, Pectra includes EIP-7691, which increases the maximum number of ""blobs"" (data chunks introduced with EIP-4844) per block. This change significantly boosts the data availability layer used by rollups, supporting cheaper and more efficient Layer 2 scalability.
4. Upgrade & Improvement Standards
Ethereum follows the Ethereum Improvement Proposal (EIP) process for upgrades.
The following applies to BNB Smart Chain:
Binance Smart Chain (BSC) is a Layer-1 blockchain that utilizes a Proof-of-Staked Authority (PoSA) consensus mechanism. This mechanism combines elements of Proof-of-Authority (PoA) and Proof-of-Stake (PoS) and is intended to secure the network and validate transactions. In PoSA, validators are selected based on their stake and authority, with the goal of providing fast transaction times and low fees while maintaining network security through staking.
The following applies to Polygon zkEVM:
Polygon zkEVM is an Ethereum-compatible Layer 2 solution built on zero-knowledge rollup technology. It follows EVM equivalence and supports standard Ethereum protocols such as ERC-20 and ERC-721.
The following applies to Aptos:
The Aptos blockchain operates on publicly documented protocol specifications that define ledger structure, transaction processing, and validation rules. The protocol is implemented in open-source software, and nodes communicate using peer-to-peer networking standards defined in the protocol documentation.
Protocol updates are implemented through software changes adopted by network participants in accordance with governance processes.
The following applies to Base:
Base was introduced by Coinbase and developed using Optimism's OP Stack. L2 transactions do not have their own consensus mechanism and are only validated by the execution clients. The so-called sequencer regularly bundles stacks of L2 transactions and publishes them on the L1 network, i.e. Ethereum. Ethereum's consensus mechanism (Proof-of-stake) thus indirectly secures all L2 transactions as soon as they are written to L1.
The following applies to zkSync Era:
zkSync Era operates as an Ethereum Layer 2 network implementing zk-Rollups with full EVM compatibility. It adheres to Ethereum token and contract standards, ensuring seamless interoperability.
The following applies to Arbitrum:
Arbitrum commonly refers to the Arbitrum Rollup, a Layer 2 (L2) blockchain build using the Arbitrum technology suite. The Arbitrum Rollup is an optimistic rollup on top of the Ethereum blockchain. This means that the L2 transactions do not have their own consensus mechanism and are only validated by the execution clients. The so-called sequencer regularly bundles stacks of L2 transactions and publishes them on the L1 network, i.e. Ethereum. Ethereum's consensus mechanism (Proof-of-Stake) thus indirectly secures all L2 transactions as soon as they are written to L1.
The following applies to Linea:
The Layer 2 uses rollup technology, whereby multiple transactions are aggregated (“rolled up”) and submitted in batches to Ethereum for final settlement.
A single sequencer is responsible for ordering transactions on the Layer 2 network. The sequencer collects user-submitted transactions, orders them, and produces Layer 2 blocks.
The correctness of Layer 2 state transitions is ensured through a single prover mechanism. The prover generates cryptographic proofs (validity proofs or fraud proofs, depending on the rollup type) demonstrating that the state transitions executed off-chain are consistent with the Ethereum smart contracts governing the rollup. These proofs are submitted to Ethereum for verification, ensuring that malicious or incorrect state transitions cannot be finalized on the base layer.
The Layer 2 is fully interoperable with Ethereum. Users deposit and withdraw assets via Ethereum smart contracts, and Layer 2 transactions ultimately derive their security from Ethereum’s consensus mechanism.
Future upgrades may extend interoperability to other Layer 2 solutions or blockchains.
H.3 Technology used
The crypto asset that is the subject of this white paper is available on the Ethereum, BNB Smart Chain, Polygon zkEVM, Aptos, Base, zkSync Era, Arbitrum and Linea.
The following applies to Ethereum:
Decentralized Ledger: The Ethereum blockchain acts as a decentralized ledger for all token transactions, with the intention to preserving an unalterable record of token transfers and ownership to ensure both transparency and security.
2. Private Key Management: To safeguard their token holdings, users must securely store their wallet’s private keys and recovery phrases.
3. Cryptographic Integrity: Ethereum employs elliptic curve cryptography to validate and execute transactions securely, intended to ensure the integrity of all transfers. The Keccak-256 (SHA-3 variant) Hashing Algorithm is used for hashing and address generation. The crypto-asset uses ECDSA with secp256k1 curve for key generation and digital signatures. Next to that, BLS (Boneh-Lynn-Shacham) signatures are used for validator aggregation in PoS.
The following applies to BNB Smart Chain:
1. BSC-Compatible Wallets
Tokens on BSC are supported by wallets compatible with the Ethereum Virtual Machine (EVM), such as MetaMask. These wallets can be configured to connect to the BSC network and are designed to interact with BSC using standard Web3 interfaces.
2. Ledger
BSC maintains its own decentralized ledger for recording token transactions. This ledger is intended to ensure transparency and security, providing a verifiable record of all activities on the network.
3. BEP-20 Token Standard
BSC supports tokens implemented under the BEP-20 standard, which is tailored for the BSC ecosystem. This standard is designed to facilitate the creation and management of tokens on the network.
4. Scalability and Transaction Efficiency
BSC is designed to handle high volumes of transactions with low fees. It leverages its PoSA consensus mechanism to achieve fast transaction times and efficient network performance, making it suitable for applications requiring high throughput.
The following applies to Polygon zkEVM:
Polygon zkEVM uses zero-knowledge proof cryptography to aggregate and verify transactions off-chain before submitting validity proofs to Ethereum. This enhances scalability and reduces gas costs.
The following applies to Aptos:
The network is based on distributed ledger technology that records transactions in blocks linked sequentially. Cryptographic methods are used to secure transactions, manage accounts, and verify authenticity.
Smart contracts are executed within a virtual machine environment based on the Move programming language. Account access is controlled through cryptographic key pairs, and ledger data is replicated across participating nodes.
The following applies to Base:
1. Base-Compatible Wallets:The tokens are supported by all wallets compatible with the Ethereum Virtual Machine (EVM), such as MetaMask, Coinbase Wallet, and Trust Wallet. These wallets interact with Base in the same way as with other EVM-compatible chains, using standard Web3 interfaces.
2. Decentralized Ledger:Base operates as a Layer-2 blockchain on Ethereum and maintains its own decentralized ledger for recording token transactions. Final transaction data is periodically posted to Ethereum Layer 1, ensuring long-term availability and resistance to tampering.
3. ERC-20 Token Standard:The Base network supports tokens implemented under the ERC-20 standard, the same as on Ethereum.
4. Scalability and Transaction Efficiency:
As a rollup-based Layer-2, Base is intended to handle high volumes of transactions with lower fees compared to Ethereum Layer 1. This is enabled by off-chain execution and on-chain data posting via optimistic rollup architecture
The following applies to zkSync Era:
zkSync Era combines zk-SNARK proofs with EVM-equivalent smart-contract execution. Its architecture allows high throughput while inheriting Ethereum’s security model.
The following applies to Arbitrum:
1. Arbitrum-Compatible Wallets:The tokens are supported by all wallets compatible with the Ethereum Virtual Machine (EVM), such as MetaMask.
2. Decentralized Ledger: Arbitrum operates as a Layer-2 blockchain on Ethereum and maintains its own decentralized ledger for recording token transactions. Final transaction data is periodically posted to Ethereum Layer 1, ensuring long-term availability and resistance to tampering.
3. ERC-20 Token Standard: The Arbitrum network supports tokens implemented under the ERC-20 standard, the same as on Ethereum.
4. Arbitrum supports what is called. MultiVM, which is the combination of EVM support and WASM VM support. The latter one being more efficient (lower gas costs) but specific to Arbitrum.
5. Scalability and Transaction Efficiency:
As a rollup-based Layer-2, Arbitrum is intended to handle high volumes of transactions with lower fees compared to Ethereum Layer 1. This is enabled by off-chain execution and on-chain data posting via optimistic rollup architecture.
The following applies to Linea:
The LINEA protocol is a Type 2 Zero-Knowledge Ethereum Virtual Machine (zkEVM) network that aims to scale Ethereum while preserving its security and developer experience. The Network is designed for full EVM equivalence at the bytecode level, which is a critical standard for seamless interoperability. As a zk-rollup, the Network utilizes zero-knowledge proofs (ZKPs) to ensure the integrity of off-chain transactions. The Network uses a custom, in-house proving system based on recursive SNARKs, with components named Arcane and Vortex. This system is used to generate validity proofs that confirm off-chain computations are correct. The network uses lattice-based cryptography for its ZKPs, which offers resistance to potential threats from quantum computing.
The Network’s off-chain execution environment uses data structures that mirror Ethereum's own state management. The Network uses a Merkle-Patricia Trie to record the world state and manage consensus, just as Ethereum does. To improve efficiency in tracking and updating account storage, LINEA protocol uses a sparse Merkle tree.
H.4 Consensus mechanism
The crypto asset that is the subject of this white paper is available on the Ethereum, BNB Smart Chain, Polygon zkEVM, Aptos, Base, zkSync Era, Arbitrum and Linea.
The following applies to Ethereum:
The crypto-asset's Proof-of-Stake (PoS) consensus mechanism, introduced with The Merge in 2022, replaces mining with validator staking. Validators must stake at least 32 ETH every block a validator is randomly chosen to propose the next block. Once proposed the other validators verify the blocks integrity. The network operates on a slot and epoch system, where a new block is proposed every 12 seconds, and finalization occurs after two epochs (~12.8 minutes) using Casper-FFG. The Beacon Chain coordinates validators, while the fork-choice rule (LMD-GHOST) ensures the chain follows the heaviest accumulated validator votes. Validators earn rewards for proposing and verifying blocks, but face slashing for malicious behavior or inactivity. PoS aims to improve energy efficiency, security, and scalability, with future upgrades like Proto-Danksharding enhancing transaction efficiency.
The following applies to BNB Smart Chain:
Binance Smart Chain (BSC) uses a hybrid consensus mechanism called Proof of Staked Authority (PoSA), which combines elements of Delegated Proof of Stake (DPoS) and Proof of Authority (PoA). This method ensures fast block times and low fees while maintaining a level of decentralization and security. Core Components 1. Validators (so-called “Cabinet Members”): Validators on BSC are responsible for producing new blocks, validating transactions, and maintaining the network’s security. To become a validator, an entity must stake a significant amount of BNB (Binance Coin). Validators are selected through staking and voting by token holders. There are 21 active validators at any given time, rotating to ensure decentralization and security. 2. Delegators: Token holders who do not wish to run validator nodes can delegate their BNB tokens to validators. This delegation helps validators increase their stake and improves their chances of being selected to produce blocks. Delegators earn a share of the rewards that validators receive, incentivizing broad participation in network security. 3. Candidates: Candidates are nodes that have staked the required amount of BNB and are in the pool waiting to become validators. They are essentially potential validators who are not currently active but can be elected to the validator set through community voting. Candidates play a crucial role in ensuring there is always a sufficient pool of nodes ready to take on validation tasks, thus maintaining network resilience and decentralization. Consensus Process 4. Validator Selection: Validators are chosen based on the amount of BNB staked and votes received from delegators. The more BNB staked and votes received, the higher the chance of being selected to validate transactions and produce new blocks. The selection process involves both the current validators and the pool of candidates, ensuring a dynamic and secure rotation of nodes. 5. Block Production: The selected validators take turns producing blocks in a PoA-like manner, ensuring that blocks are generated quickly and efficiently. Validators validate transactions, add them to new blocks, and broadcast these blocks to the network. 6. Transaction Finality: BSC achieves fast block times of around 3 seconds and quick transaction finality. This is achieved through the efficient PoSA mechanism that allows validators to rapidly reach consensus. Security and Economic Incentives 7. Staking: Validators are required to stake a substantial amount of BNB, which acts as collateral to ensure their honest behavior. This staked amount can be slashed if validators act maliciously. Staking incentivizes validators to act in the network's best interest to avoid losing their staked BNB. 8. Delegation and Rewards: Delegators earn rewards proportional to their stake in validators. This incentivizes them to choose reliable validators and participate in the network’s security. Validators and delegators share transaction fees as rewards, which provides continuous economic incentives to maintain network security and performance. 9. Transaction Fees: BSC employs low transaction fees, paid in BNB, making it cost-effective for users. These fees are collected by validators as part of their rewards, further incentivizing them to validate transactions accurately and efficiently.
The following applies to Polygon zkEVM:
Polygon zkEVM inherits Ethereum’s Proof-of-Stake (PoS) consensus for finality, while internally relying on zk-proof verification to confirm transaction validity.
The following applies to Aptos:
The Aptos blockchain utilises a proof-of-stake-based consensus mechanism. Validators participate in block proposal and validation in accordance with protocol-defined rules.
Validator selection, participation, and block finalisation are governed by staking and consensus parameters defined at the protocol level, which may be modified through governance processes.
The following applies to Base:
Base is a Layer-2 (L2) solution on Ethereum that was introduced by Coinbase and developed using Optimism's OP Stack. L2 transactions do not have their own consensus mechanism and are only validated by the execution clients. The so-called sequencer regularly bundles stacks of L2 transactions and publishes them on the L1 network, i.e. Ethereum. Ethereum's consensus mechanism (Proof-of-stake) thus indirectly secures all L2 transactions as soon as they are written to L1.
The following applies to zkSync Era:
zkSync Era depends on Ethereum’s consensus layer for settlement and employs zk-proof validation for transaction integrity and state verification.
The following applies to Arbitrum:
Arbitrum is a Layer-2 (L2) solution on Ethereum that is developed using the Arbitrum technology suite. L2 transactions do not have their own consensus mechanism and are only validated by the execution clients. The so-called sequencer regularly bundles stacks of L2 transactions and publishes them on the L1 network, i.e. Ethereum. Ethereum's consensus mechanism (Proof-of-Stake) thus indirectly secures all L2 transactions as soon as they are written to L1.
The following applies to Linea:
The Linea Network uses a Zero-Knowledge Rollup (ZK-Rollup) architecture with a zkEVM for Ethereum compatibility, and its consensus is derived from Ethereum's own proof-of-stake security. While the Network has components like a sequencer for ordering transactions and a coordinator for network management, its consensus mechanism is fundamentally linked to the proof and verification process of zero-knowledge proofs and the security of the Ethereum mainnet. Instead of a typical decentralized consensus on a separate blockchain, the Network inherits its security and state finality from Ethereum.
H.5 Incentive mechanisms and applicable fees
The crypto asset that is the subject of this white paper is available on the Ethereum, BNB Smart Chain, Polygon zkEVM, Aptos, Base, zkSync Era, Arbitrum and Linea.
The following applies to Ethereum:
The crypto-asset's PoS system secures transactions through validator incentives and economic penalties. Validators stake at least 32 ETH and earn rewards for proposing blocks, attesting to valid ones, and participating in sync committees. Rewards are paid in newly issued ETH and transaction fees. Under EIP-1559, transaction fees consist of a base fee, which is burned to reduce supply, and an optional priority fee (tip) paid to validators. Validators face slashing if they act maliciously and incur penalties for inactivity. This system aims to increase security by aligning incentives while making the crypto-asset's fee structure more predictable and deflationary during high network activity.
The following applies to BNB Smart Chain:
Binance Smart Chain (BSC) uses the Proof of Staked Authority (PoSA) consensus mechanism to ensure network security and incentivize participation from validators and delegators. Incentive Mechanisms 1. Validators: Staking Rewards: Validators must stake a significant amount of BNB to participate in the consensus process. They earn rewards in the form of transaction fees and block rewards. Selection Process: Validators are selected based on the amount of BNB staked and the votes received from delegators. The more BNB staked and votes received, the higher the chances of being selected to validate transactions and produce new blocks. 2. Delegators: Delegated Staking: Token holders can delegate their BNB to validators. This delegation increases the validator's total stake and improves their chances of being selected to produce blocks. Shared Rewards: Delegators earn a portion of the rewards that validators receive. This incentivizes token holders to participate in the network’s security and decentralization by choosing reliable validators. 3. Candidates: Pool of Potential Validators: Candidates are nodes that have staked the required amount of BNB and are waiting to become active validators. They ensure that there is always a sufficient pool of nodes ready to take on validation tasks, maintaining network resilience. 4. Economic Security: Slashing: Validators can be penalized for malicious behavior or failure to perform their duties. Penalties include slashing a portion of their staked tokens, ensuring that validators act in the best interest of the network. Opportunity Cost: Staking requires validators and delegators to lock up their BNB tokens, providing an economic incentive to act honestly to avoid losing their staked assets. Fees on the Binance Smart Chain 5. Transaction Fees: Low Fees: BSC is known for its low transaction fees compared to other blockchain networks. These fees are paid in BNB and are essential for maintaining network operations and compensating validators. Dynamic Fee Structure: Transaction fees can vary based on network congestion and the complexity of the transactions. However, BSC ensures that fees remain significantly lower than those on the Ethereum mainnet. 6. Block Rewards: Incentivizing Validators: Validators earn block rewards in addition to transaction fees. These rewards are distributed to validators for their role in maintaining the network and processing transactions. 7. Cross-Chain Fees: Interoperability Costs: BSC supports cross-chain compatibility, allowing assets to be transferred between Binance Chain and Binance Smart Chain. These cross-chain operations incur minimal fees, facilitating seamless asset transfers and improving user experience. 8. Smart Contract Fees: Deployment and Execution Costs: Deploying and interacting with smart contracts on BSC involves paying fees based on the computational resources required. These fees are also paid in BNB and are designed to be cost-effective, encouraging developers to build on the BSC platform.
The following applies to Polygon zkEVM:
Validators and provers in Polygon zkEVM are rewarded in MATIC for submitting validity proofs and maintaining network performance. Transaction fees are paid in ETH or MATIC.
The following applies to Aptos:
The protocol includes incentive mechanisms for validators participating in transaction validation and consensus activities. Validators may receive protocol-defined rewards in the form of newly issued APT units.
Transactions consume protocol-defined resources and may require the payment of fees denominated in APT. Fee levels and reward parameters are set by protocol rules and may be adjusted through governance mechanisms.
The following applies to Base:
Base is a Layer-2 (L2) solution on Ethereum that uses optimistic rollups provided by the OP Stack on which it was developed. Transaction on base are bundled by a, so called, sequencer and the result is regularly submitted as an Layer-1 (L1) transactions. This way many L2 transactions get combined into a single L1 transaction. This lowers the average transaction cost per transaction, because many L2 transactions together fund the transaction cost for the single L1 transaction. This creates incentives to use base rather than the L1, i.e. Ethereum, itself. To get crypto-assets in and out of base, a special smart contract on Ethereum is used. Since there is no consensus mechanism on L2 an additional mechanism ensures that only existing funds can be withdrawn from L2. When a user wants to withdraw funds, that user needs to submit a withdrawal request on L1. If this request remains unchallenged for a period of time the funds can be withdrawn. During this time period any other user can submit a fault proof, which will start a dispute resolution process. This process is designed with economic incentives for correct behavior.
The following applies to zkSync Era:
zkSync Era compensates sequencers and provers through ETH-based fees. Part of the transaction costs cover proof generation, while the remainder secures Layer 2 operations.
The following applies to Arbitrum:
Arbitrum is a Layer-2 (L2) solution on Ethereum that is developed using the Arbitrum technology suite. Transaction on Arbitrum are bundled by a, so called, sequencer and the result is regularly submitted as an Layer-1 (L1) transactions. This way many L2 transactions get combined into a single L1 transaction. This lowers the average transaction cost per transaction, because many L2 transactions together fund the transaction cost for the single L1 transaction. This creates incentives to use Arbitrum rather than the L1, i.e. Ethereum, itself. To get crypto-assets in and out of Arbitrum, a special smart contract on Ethereum is used. Since there is no consensus mechanism on L2 an additional mechanism ensures that only existing funds can be withdrawn from L2. When a user wants to withdraw funds, that user needs to submit a withdrawal request on L1. If this request remains undisputed for a period of time the funds can be withdrawn. During this time period Arbitrum validators can dispute the claim, which will start a dispute resolution process. This process is designed with economic incentives for correct behavior of all participants.
The following applies to Linea:
Like Ethereum, the Network uses a gas system, where gas is the unit of computational effort required to process a transaction. All gas fees on the Network are paid in Ether (ETH). The Network has a base fee that is designed to stabilize at 7 wei. The base fee still decreases or increases based on network traffic, similar to Ethereum, but it does not go below 7 wei.
The Network does not require token staking for transaction validation purposes and thus provides no staking rewards. It does not offer incentives for running a full network node. It does charge fees collected by the sequencer for transaction processing. Those fees are paid in ETH, 20% of which are immediately burned while the remaining 80% are converted to Tokens and then burned.
H.6 Use of distributed ledger technology
H.7 DLT functionality description
Not applicable.
H.8 Audit
H.9 Audit outcome
Not applicable.
Part I – Information on risks
I.1 Offer-related risks
1. Regulatory and Jurisdictional Risks: This white paper has been prepared with utmost caution; however, future changes in regulatory frameworks could potentially impact the token's legal status and its tradability.
Jurisdictional Limitations: Investors are required to ensure that their transactions comply with the laws applicable in their jurisdictions, as the regulatory landscape for crypto-assets varies significantly across different regions.
2. Market and Liquidity Risks:
Volatility: The token will most likely be subject to high volatility and market speculation. Price fluctuations could be significant, posing a risk of substantial losses to holders.
Liquidity Risk: Low trading volumes may restrict the buying and selling capabilities of the tokens. Liquidity of the token can vary. This could result in high slippage when trading a token.
3. Operational and Technical Risks:
Blockchain Dependency: As of now, the token is entirely dependent on the blockchains described above. Any issues like downtime, congestion, or security vulnerabilities within the networks could adversely affect the token's functionality.
Smart Contract Risks: Smart contracts governing the token may contain hidden vulnerabilities or bugs that could disrupt the token offering or distribution processes.
Human errors: Due to the irrevocability of blockchain-transactions, approving wrong transactions or using incorrect networks/addresses will most likely result in funds not being accessibly anymore.
4. Lack of Intrinsic Value: The token does not possess inherent utility, functioning solely as a speculative asset. Its valuation is predominantly influenced by community engagement, speculative activities, and overall market sentiment, which presents considerable challenges to sustaining long-term value stability.
5. Delisting Risks: Bitstamp Eurpe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.
I.2 Issuer-related risks
1. Insolvency
As with every other commercial endeavor, the risk of insolvency of the issuer is given. This could be caused by but is not limited to lack of interest from the public, lack of funding, incapacitation of key developers and project members, force majeure (including pandemics and wars) or lack of commercial success or prospects.
2. Counterparty
In order to operate, the issuer has most likely engaged in different business relationships with one or more third parties on which it strongly depends on. Loss or changes in the leadership or key partners of the issuer and/or the respective counterparties can lead to disruptions, loss of trust, or project failure. This could result in a total loss of economic value for the crypto-asset holders.
3. Legal and Regulatory Compliance
Cryptocurrencies and blockchain-based technologies are subject to evolving regulatory landscapes worldwide. Regulations vary across jurisdictions and may be subject to significant changes. Non-compliance can result in investigations, enforcement actions, penalties, fines, sanctions, or the prohibition of the trading of the crypto-asset impacting its viability and market acceptance. This could also result in the issuer to be subject to private litigation. The beforementioned would most likely also lead to changes with respect to trading of the crypto-asset that may negatively impact the value, legality, or functionality of the crypto-asset.
4. Operational
Failure to develop or maintain effective internal control, or any difficulties encountered in the implementation of such controls, or their improvement could harm the issuer's business, causing disruptions, financial losses, or reputational damage.
5. Industry
The issuer is and will be subject to all of the risks and uncertainties associated with a crypto-project. History has shown that most of this projects resulted in financial losses for the investors and were only set-up to enrich a few insiders with the money from retail investors.
6. Reputational
The issuer faces the risk of negative publicity, whether due to, without limitation, operational failures, security breaches, or association with illicit activities, which can damage the issuer reputation and, by extension, the value and acceptance of the crypto-asset.
7. Competition
There are numerous other crypto-asset projects in the same realm, which could have an effect on the crypto-asset in question.
8. Unanticipated Risk
In addition to the risks included in this section, there might be other risks that cannot be foreseen. Additional risks may also materialize as unanticipated variations or combinations of the risks discussed.
I.3 Crypto-assets-related risks
1. Market Volatility Risks: High Volatility: The value of the token is expected to be highly volatile, influenced by speculation and overall market sentiment. Significant price fluctuations could lead to substantial losses for holders.
2. Speculative Nature: The token lacks intrinsic utility or underlying value, functioning solely as a speculative asset. Its valuation is wholly dependent on market demand and community interest.
3. Liquidity Risks: Some crypto-assets suffer from limited liquidity, which can present difficulties when executing large trades without significantly impacting market prices. This lack of liquidity can lead to substantial financial losses.
4. Blockchain Risks: Network Dependency: The token operates on the blockchains described above as of now. Issues such as network downtime, congestion, or security vulnerabilities could impair the token’s transferability, trading, or overall functionality. Although the networks is known for low transaction fees, network congestion or technical issues could lead to increased costs or delays.
5. Security Risks - Smart Contract Vulnerabilities: The smart contract for the token may contain vulnerabilities or exploits that jeopardize token security or distribution.
6. Security Risks - Private Key Management: It is critical for holders to secure their wallet private keys and recovery phrases. Losing wallet credentials can result in the irreversible loss of tokens.
7. Scams: The irrevocability of transactions executed using blockchain infrastructure, as well as the pseudonymous nature of blockchain ecosystems, attracts scammers. Therefore, investors in crypto-assets must proceed with a high degree of caution when investing in if they invest in crypto-assets. Typical scams include – but are not limited to – the creation of fake crypto-assets with the same name, phishing on social networks or by email, fake giveaways/airdrops, identity theft, among others.
8. Dependence on Community Interest: The success and market value of the token heavily rely on community support.
9. Evolving Legal Frameworks: Future changes in regulations or their interpretations could affect the classification, trading availability, or usability of the tokens. Jurisdictional Restrictions: Users in certain areas may encounter legal restrictions or obligations concerning the possession or trading of crypto-assets like the token in question.
10. Technological Obsolescence: The rapid evolution of the crypto-asset landscape means new technologies or platforms could make the networks or the tokens design less competitive, potentially affecting adoption and value. Participants are advised to recognize the speculative and volatile nature of the token and be prepared for these risks.
11. Reputational concerns: Crypto-assets are often subject to reputational risks stemming from associations with illegal activities, high-profile security breaches, and technological failures. Such incidents can undermine trust in the broader ecosystem, negatively affecting investor confidence and market value, thereby hindering widespread adoption and acceptance.
12. Taxation: The taxation regime that applies to the trading of the crypto-asset by individual holders or legal entities will depend on the holder’s jurisdiction. It is the holder’s sole responsibility to comply with all applicable tax laws, including, but not limited to, the reporting and payment of income tax, wealth tax, or similar taxes arising in connection with the appreciation and depreciation of the crypto-asset.
13. Anti-Money Laundering/Counter-Terrorism Financing: It cannot be ruled out that crypto-asset wallet addresses interacting with the crypto-asset have been, or will be used for money laundering or terrorist financing purposes, or are identified with a person known to have committed such offenses.
14. Market Abuse: It is noteworthy that crypto-assets are potentially prone to increased market abuse risks, as the underlying infrastructure could be used to exploit arbitrage opportunities through schemes such as front-running, spoofing, pump-and-dump, and fraud across different systems, platforms, or geographic locations. This is especially true for crypto-assets with a low market capitalization and few trading venues, and potential investors should be aware that this could lead to a total loss of the funds invested in the crypto-asset.
I.4 Project implementation-related risks
As this white paper relates to the "Admission to trading" of the crypto-asset, the implementation risk is referring to the risks on the Crypto Asset Service Providers side. These can be, but are not limited to, typical project management risks, such as key-personal-risks, timeline-risks, and technical implementation-risks.
I.5 Technology-related risks
1. Blockchain Dependency Risks
Network Downtime: Potential outages or congestion on the blockchains could interrupt on-chain token transfers, trading, and other functions.
Scalability Challenges: Despite the blockchains comparatively high throughput design, unexpected demand or technical issues might compromise its performance.
2. Smart Contract Risks
Vulnerabilities: The smart contract governing the token could contain bugs or vulnerabilities that may be exploited, affecting token distribution or vesting schedules.
3. Wallet and Storage Risks
Private Key Management: Token holders must securely manage their private keys and recovery phrases to prevent permanent loss of access to their tokens, which includes Trading-Venues, who are a prominent target for dedicated hacks.
Compatibility Issues: The tokens require network-compatible wallets for storage and transfer. Any incompatibility or technical issues with these wallets could impact token accessibility.
4. Network Security Risks
Attack Risks: The blockchains may face threats such as denial-of-service (DoS) attacks or exploits targeting its consensus mechanism, which could compromise network integrity.
Centralization Concerns: Although claiming to be decentralized, the networks relatively smaller number of validators/concentration of stakes within the network compared to other blockchains and the influence of the Foundations might pose centralization risks, potentially affecting network resilience.
5. Evolving Technology Risks: Technological Obsolescence: The fast pace of innovation in blockchain technology may make the networks and token standards appear less competitive or become outdated, potentially impacting the usability or adoption of the token.
6. Bridges: The crypto assets are transferred between the ecosystems using the so-called Bridge. Bridges have, in the past, been very sensitive to malfunctions and hacks. Their usage is connected to additional technical risk. The bridge poses an additional source for adverse effects on the investor as it retains the right to release, burn and mint portions of the token supply.
I.6 Mitigation measures
None.
Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
J.1 Adverse impacts on climate and other environment-related adverse impacts
S.1 Name
S.2 Relevant legal entity identifier
S.3 Name of the cryptoasset
S.4 Consensus Mechanism
The crypto asset that is the subject of this white paper is available on the Ethereum, BNB Smart Chain, Polygon zkEVM, Aptos, Base, zkSync Era, Arbitrum and Linea.
The following applies to Ethereum:
The crypto-asset's Proof-of-Stake (PoS) consensus mechanism, introduced with The Merge in 2022, replaces mining with validator staking. Validators must stake at least 32 ETH every block a validator is randomly chosen to propose the next block. Once proposed the other validators verify the blocks integrity. The network operates on a slot and epoch system, where a new block is proposed every 12 seconds, and finalization occurs after two epochs (~12.8 minutes) using Casper-FFG. The Beacon Chain coordinates validators, while the fork-choice rule (LMD-GHOST) ensures the chain follows the heaviest accumulated validator votes. Validators earn rewards for proposing and verifying blocks, but face slashing for malicious behavior or inactivity. PoS aims to improve energy efficiency, security, and scalability, with future upgrades like Proto-Danksharding enhancing transaction efficiency.
The following applies to BNB Smart Chain:
Binance Smart Chain (BSC) uses a hybrid consensus mechanism called Proof of Staked Authority (PoSA), which combines elements of Delegated Proof of Stake (DPoS) and Proof of Authority (PoA). This method ensures fast block times and low fees while maintaining a level of decentralization and security. Core Components 1. Validators (so-called “Cabinet Members”): Validators on BSC are responsible for producing new blocks, validating transactions, and maintaining the network’s security. To become a validator, an entity must stake a significant amount of BNB (Binance Coin). Validators are selected through staking and voting by token holders. There are 21 active validators at any given time, rotating to ensure decentralization and security. 2. Delegators: Token holders who do not wish to run validator nodes can delegate their BNB tokens to validators. This delegation helps validators increase their stake and improves their chances of being selected to produce blocks. Delegators earn a share of the rewards that validators receive, incentivizing broad participation in network security. 3. Candidates: Candidates are nodes that have staked the required amount of BNB and are in the pool waiting to become validators. They are essentially potential validators who are not currently active but can be elected to the validator set through community voting. Candidates play a crucial role in ensuring there is always a sufficient pool of nodes ready to take on validation tasks, thus maintaining network resilience and decentralization. Consensus Process 4. Validator Selection: Validators are chosen based on the amount of BNB staked and votes received from delegators. The more BNB staked and votes received, the higher the chance of being selected to validate transactions and produce new blocks. The selection process involves both the current validators and the pool of candidates, ensuring a dynamic and secure rotation of nodes. 5. Block Production: The selected validators take turns producing blocks in a PoA-like manner, ensuring that blocks are generated quickly and efficiently. Validators validate transactions, add them to new blocks, and broadcast these blocks to the network. 6. Transaction Finality: BSC achieves fast block times of around 3 seconds and quick transaction finality. This is achieved through the efficient PoSA mechanism that allows validators to rapidly reach consensus. Security and Economic Incentives 7. Staking: Validators are required to stake a substantial amount of BNB, which acts as collateral to ensure their honest behavior. This staked amount can be slashed if validators act maliciously. Staking incentivizes validators to act in the network's best interest to avoid losing their staked BNB. 8. Delegation and Rewards: Delegators earn rewards proportional to their stake in validators. This incentivizes them to choose reliable validators and participate in the network’s security. Validators and delegators share transaction fees as rewards, which provides continuous economic incentives to maintain network security and performance. 9. Transaction Fees: BSC employs low transaction fees, paid in BNB, making it cost-effective for users. These fees are collected by validators as part of their rewards, further incentivizing them to validate transactions accurately and efficiently.
The following applies to Polygon zkEVM:
Polygon zkEVM inherits Ethereum’s Proof-of-Stake (PoS) consensus for finality, while internally relying on zk-proof verification to confirm transaction validity.
The following applies to Aptos:
The Aptos blockchain utilises a proof-of-stake-based consensus mechanism. Validators participate in block proposal and validation in accordance with protocol-defined rules.
Validator selection, participation, and block finalisation are governed by staking and consensus parameters defined at the protocol level, which may be modified through governance processes.
The following applies to Base:
Base is a Layer-2 (L2) solution on Ethereum that was introduced by Coinbase and developed using Optimism's OP Stack. L2 transactions do not have their own consensus mechanism and are only validated by the execution clients. The so-called sequencer regularly bundles stacks of L2 transactions and publishes them on the L1 network, i.e. Ethereum. Ethereum's consensus mechanism (Proof-of-stake) thus indirectly secures all L2 transactions as soon as they are written to L1.
The following applies to zkSync Era:
zkSync Era depends on Ethereum’s consensus layer for settlement and employs zk-proof validation for transaction integrity and state verification.
The following applies to Arbitrum:
Arbitrum is a Layer-2 (L2) solution on Ethereum that is developed using the Arbitrum technology suite. L2 transactions do not have their own consensus mechanism and are only validated by the execution clients. The so-called sequencer regularly bundles stacks of L2 transactions and publishes them on the L1 network, i.e. Ethereum. Ethereum's consensus mechanism (Proof-of-Stake) thus indirectly secures all L2 transactions as soon as they are written to L1.
The following applies to Linea:
The Linea Network uses a Zero-Knowledge Rollup (ZK-Rollup) architecture with a zkEVM for Ethereum compatibility, and its consensus is derived from Ethereum's own proof-of-stake security. While the Network has components like a sequencer for ordering transactions and a coordinator for network management, its consensus mechanism is fundamentally linked to the proof and verification process of zero-knowledge proofs and the security of the Ethereum mainnet. Instead of a typical decentralized consensus on a separate blockchain, the Network inherits its security and state finality from Ethereum.
S.5 Incentive Mechanisms and Applicable Fees
The crypto asset that is the subject of this white paper is available on the Ethereum, BNB Smart Chain, Polygon zkEVM, Aptos, Base, zkSync Era, Arbitrum and Linea.
The following applies to Ethereum:
The crypto-asset's PoS system secures transactions through validator incentives and economic penalties. Validators stake at least 32 ETH and earn rewards for proposing blocks, attesting to valid ones, and participating in sync committees. Rewards are paid in newly issued ETH and transaction fees. Under EIP-1559, transaction fees consist of a base fee, which is burned to reduce supply, and an optional priority fee (tip) paid to validators. Validators face slashing if they act maliciously and incur penalties for inactivity. This system aims to increase security by aligning incentives while making the crypto-asset's fee structure more predictable and deflationary during high network activity.
The following applies to BNB Smart Chain:
Binance Smart Chain (BSC) uses the Proof of Staked Authority (PoSA) consensus mechanism to ensure network security and incentivize participation from validators and delegators. Incentive Mechanisms 1. Validators: Staking Rewards: Validators must stake a significant amount of BNB to participate in the consensus process. They earn rewards in the form of transaction fees and block rewards. Selection Process: Validators are selected based on the amount of BNB staked and the votes received from delegators. The more BNB staked and votes received, the higher the chances of being selected to validate transactions and produce new blocks. 2. Delegators: Delegated Staking: Token holders can delegate their BNB to validators. This delegation increases the validator's total stake and improves their chances of being selected to produce blocks. Shared Rewards: Delegators earn a portion of the rewards that validators receive. This incentivizes token holders to participate in the network’s security and decentralization by choosing reliable validators. 3. Candidates: Pool of Potential Validators: Candidates are nodes that have staked the required amount of BNB and are waiting to become active validators. They ensure that there is always a sufficient pool of nodes ready to take on validation tasks, maintaining network resilience. 4. Economic Security: Slashing: Validators can be penalized for malicious behavior or failure to perform their duties. Penalties include slashing a portion of their staked tokens, ensuring that validators act in the best interest of the network. Opportunity Cost: Staking requires validators and delegators to lock up their BNB tokens, providing an economic incentive to act honestly to avoid losing their staked assets. Fees on the Binance Smart Chain 5. Transaction Fees: Low Fees: BSC is known for its low transaction fees compared to other blockchain networks. These fees are paid in BNB and are essential for maintaining network operations and compensating validators. Dynamic Fee Structure: Transaction fees can vary based on network congestion and the complexity of the transactions. However, BSC ensures that fees remain significantly lower than those on the Ethereum mainnet. 6. Block Rewards: Incentivizing Validators: Validators earn block rewards in addition to transaction fees. These rewards are distributed to validators for their role in maintaining the network and processing transactions. 7. Cross-Chain Fees: Interoperability Costs: BSC supports cross-chain compatibility, allowing assets to be transferred between Binance Chain and Binance Smart Chain. These cross-chain operations incur minimal fees, facilitating seamless asset transfers and improving user experience. 8. Smart Contract Fees: Deployment and Execution Costs: Deploying and interacting with smart contracts on BSC involves paying fees based on the computational resources required. These fees are also paid in BNB and are designed to be cost-effective, encouraging developers to build on the BSC platform.
The following applies to Polygon zkEVM:
Validators and provers in Polygon zkEVM are rewarded in MATIC for submitting validity proofs and maintaining network performance. Transaction fees are paid in ETH or MATIC.
The following applies to Aptos:
The protocol includes incentive mechanisms for validators participating in transaction validation and consensus activities. Validators may receive protocol-defined rewards in the form of newly issued APT units.
Transactions consume protocol-defined resources and may require the payment of fees denominated in APT. Fee levels and reward parameters are set by protocol rules and may be adjusted through governance mechanisms.
The following applies to Base:
Base is a Layer-2 (L2) solution on Ethereum that uses optimistic rollups provided by the OP Stack on which it was developed. Transaction on base are bundled by a, so called, sequencer and the result is regularly submitted as an Layer-1 (L1) transactions. This way many L2 transactions get combined into a single L1 transaction. This lowers the average transaction cost per transaction, because many L2 transactions together fund the transaction cost for the single L1 transaction. This creates incentives to use base rather than the L1, i.e. Ethereum, itself. To get crypto-assets in and out of base, a special smart contract on Ethereum is used. Since there is no consensus mechanism on L2 an additional mechanism ensures that only existing funds can be withdrawn from L2. When a user wants to withdraw funds, that user needs to submit a withdrawal request on L1. If this request remains unchallenged for a period of time the funds can be withdrawn. During this time period any other user can submit a fault proof, which will start a dispute resolution process. This process is designed with economic incentives for correct behavior.
The following applies to zkSync Era:
zkSync Era compensates sequencers and provers through ETH-based fees. Part of the transaction costs cover proof generation, while the remainder secures Layer 2 operations.
The following applies to Arbitrum:
Arbitrum is a Layer-2 (L2) solution on Ethereum that is developed using the Arbitrum technology suite. Transaction on Arbitrum are bundled by a, so called, sequencer and the result is regularly submitted as an Layer-1 (L1) transactions. This way many L2 transactions get combined into a single L1 transaction. This lowers the average transaction cost per transaction, because many L2 transactions together fund the transaction cost for the single L1 transaction. This creates incentives to use Arbitrum rather than the L1, i.e. Ethereum, itself. To get crypto-assets in and out of Arbitrum, a special smart contract on Ethereum is used. Since there is no consensus mechanism on L2 an additional mechanism ensures that only existing funds can be withdrawn from L2. When a user wants to withdraw funds, that user needs to submit a withdrawal request on L1. If this request remains undisputed for a period of time the funds can be withdrawn. During this time period Arbitrum validators can dispute the claim, which will start a dispute resolution process. This process is designed with economic incentives for correct behavior of all participants.
The following applies to Linea:
Like Ethereum, the Network uses a gas system, where gas is the unit of computational effort required to process a transaction. All gas fees on the Network are paid in Ether (ETH). The Network has a base fee that is designed to stabilize at 7 wei. The base fee still decreases or increases based on network traffic, similar to Ethereum, but it does not go below 7 wei.
The Network does not require token staking for transaction validation purposes and thus provides no staking rewards. It does not offer incentives for running a full network node. It does charge fees collected by the sequencer for transaction processing. Those fees are paid in ETH, 20% of which are immediately burned while the remaining 80% are converted to Tokens and then burned.
S.6 Beginning of the period to which the disclosure relates
S.7 End of the period to which the disclosure relates
S.8 Energy consumption
S.9 Energy consumption sources and methodologies
The energy consumption associated with this crypto-asset is aggregated of multiple contributing components, primarily the underlying blockchain network and the execution of token-specific operations. To determine the energy consumption of a token, the energy consumption of the underlying blockchains network Ethereum, BNB Smart Chain, Polygon zkEVM, Aptos, Base, zkSync Era, Arbitrum and Linea is calculated first. A proportionate share of that energy use is then attributed to the token based on its activity level within the network (e.g. transaction volume, contract execution).
The Functionally Fungible Group Digital Token Identifier (FFG DTI) is used to determine all technically equivalent implementations of the crypto-asset in scope.
Estimates regarding hardware types, node distribution, and the number of network participants are based on informed assumptions, supported by best-effort verification against available empirical data. Unless robust evidence suggests otherwise, participants are assumed to act in an economically rational manner. In line with the precautionary principle, conservative estimates are applied where uncertainty exists – that is, estimates tend towards the higher end of potential environmental impact.
S.10 Renewable energy consumption
S.11 Energy intensity
S.12 Scope 1 DLT GHG emissions – Controlled
S.13 Scope 2 DLT GHG emissions – Purchased
S.14 GHG intensity
S.15 Key energy sources and methodologies
To determine the proportion of renewable energy usage, the locations of the nodes are to be determined using public information sites, open-source crawlers and crawlers developed in-house. If no information is available on the geographic distribution of the nodes, reference networks are used which are comparable in terms of their incentivization structure and consensus mechanism. This geo-information is merged with public information from Our World in Data, see citation. The intensity is calculated as the marginal energy cost wrt. one more transaction. Ember (2025); Energy Institute - Statistical Review of World Energy (2024) - with major processing by Our World in Data. “Share of electricity generated by renewables - Ember and Energy Institute” [dataset]. Ember, “Yearly Electricity Data Europe”; Ember, “Yearly Electricity Data”; Energy Institute, “Statistical Review of World Energy” [original data]. Retrieved from https://ourworldindata.org/grapher/share-electricity-renewables.
S.16 Key GHG sources and methodologies
To determine the GHG Emissions, the locations of the nodes are to be determined using public information sites, open-source crawlers and crawlers developed in-house. If no information is available on the geographic distribution of the nodes, reference networks are used which are comparable in terms of their incentivization structure and consensus mechanism. This geo-information is merged with public information from Our World in Data, see citation. The intensity is calculated as the marginal emission wrt. one more transaction. Ember (2025); Energy Institute - Statistical Review of World Energy (2024) - with major processing by Our World in Data. “Carbon intensity of electricity generation - Ember and Energy Institute” [dataset]. Ember, “Yearly Electricity Data Europe”; Ember, “Yearly Electricity Data”; Energy Institute, “Statistical Review of World Energy” [original data]. Retrieved from https://ourworldindata.org/grapher/carbon-intensity-electricity Licenced under CC BY 4.0.