..

White paper for crypto-assets other than asset-referenced tokens or e-money tokens


Digital Token Identifier:   9JDRM54GC

Offeror or person seeking admission to trading:   254900WUMRT0UHOVGX35 - Fluent (BVI) Limited (the 'Person Seeking Admission to Trading', the 'Issuer')

Type of submission:   New


Table of content

General information

SUMMARY

Part A - Information about offeror or person seeking admission to trading

Part B - Information about issuer, if different from 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 other token project

Part E - Information about offer to public of other tokens or their admission to trading

Part F - Information about other tokens

Part G - Information on rights and obligations attached to other tokens

Part H – Information on underlying technology

Part I - Information on risks

Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts





[Table 2] Template for white papers for crypto-assets other than asset-referenced tokens or e-money tokens


Template for white papers for crypto-assets other than asset-referenced tokens or e-money tokens [abstract]

General information



00 Table of content
boolean true true

01 Date of notification
date 2026-02-16

02 Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114
boolean true This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

03 Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114
boolean true 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.

04 Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114
boolean true 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

05 Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114
boolean true Not applicable

06 Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114
boolean true 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.

SUMMARY



07 Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114
boolean true 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 offer 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.


08 Characteristics of the crypto-asset
textBlock BLEND (the 'Token') will be launched as an ERC-20 token on Fluent Network (the 'Network') to serve as its native token. The Network is an Ethereum Layer 2 ('L2') that supports different virtual machines, such as the Ethereum Virtual Machine ('EVM'), Solana Virtual Machine ('SVM'), and WebAssembly ('WASM'), in a single execution layer. The Token, as the Network's native utility token, enables holders to participate in governance processes and, if they choose, to stake tokens in order to perform validator functions within the Network.

Therefore, Token holders will have governance rights over the Network. This means that Token holders will be able to vote on governance proposals shaping the Network's future.

Moreover, Token holders will be entitled to staking rights. In other words, Token holders will have to stake a certain number of Tokens to partake as Network validators. To be eligible for validating transactions, creating new blocks, and consequently being compensated with the Token as staking rewards, validators must be part of the active validator set, which comprises the top validators by number of staked Tokens. Lastly, early contributors to the Network will be compensated with the Token through an airdrop campaign.

The Token's characteristics, rights, and obligations may be modified through the Network's governance mechanism. Changes to incentive parameters, Treasury allocation, and other ecosystem developments will require approval through governance proposals submitted and voted on by Token holders. Any modifications to the protocol and Token mechanics will be communicated through the Network's official channels.


09 Further information about utility tokens
textBlock Not applicable

10 Key information about the offer to the public or admission to trading
textBlock The Issuer is seeking admission to trading of the Token across multiple trading platforms within the European Union, which have been outlined in greater detail within E.33 of this whitepaper. This approach is structured around second market facilitation rather than primary issuance. No public offering will accompany the trading platform admissions. The focus is rather on promoting market liquidity and price discovery mechanisms for the Token.

Part A - Information about offeror or person seeking admission to trading



A.1 Name
text Fluent (BVI) Limited (the 'Person Seeking Admission to Trading', the 'Issuer')

A.2 Legal form
text Company Limited by Shares

A.3 Registered address



Registered addess
text Craigmuir Chambers, Road Town, Tortola, VG 1110

Country
enumeration
Virgin Islands (British)


Sub-division
text Tortola

A.4 Head office



Head office
text Craigmuir Chambers, Road Town, Tortola, VG 1110

Country
enumeration
Virgin Islands (British)


Sub-division
text Tortola

A.5 Registration date
date 2025-12-10

A.6 Legal entity identifier
LEI 254900WUMRT0UHOVGX35

A.7 Another identifier required pursuant to applicable national law
text 2195789

A.8 Contact telephone number
text +1 510 224 4513

A.9 E-mail address
text bvi@fluent.xyz

A.10 Response time (days)
integer 5

A.11 Parent company
text Fluent Foundation (the 'Foundation')

A.12 Members of the management body



Member #1
id 1

Identity
text Yaro Pshenitsyn

Business address
text 105 Capt Temple Drive West Bay, Grand Cayman

Function
text Director of the Fluent Foundation, which is the sole director of the person seeking admission to trading

A.13 Business activity
textBlock The Person Seeking Admission to Trading is responsible for the issuance of the Token as well as entering in agreements with trading platforms (the 'Exchanges').

A.14 Parent company business activity
textBlock The Foundation, incorporated within the Cayman Islands, operates as the parent company of the Person Seeking Admission to Trading.

A.15 Newly established
boolean true

A.16 Financial condition for the past three years
textBlock Not applicable

A.17 Financial condition since registration
textBlock The Person Seeking Admission to Trading, being the BVI entity acting as the token issuer and contracting party for exchange listing agreements, forms part of a broader organisational structure. In line with prevailing industry practice, this entity operates under a Cayman Foundation, at which level the majority of expenditure, staffing and strategic-decision making is undertaken, rather than within the Person Seeking Admission to Trading itself.

It is further noted that the Person Seeking Admission to Trading was incorporated on 10-Dec-2025 and, as a result, has not yet commenced operational activity. Notwithstanding this, the Network is in a strong financial position, as evidenced by capital raises completed earlier this year in the amounts of $8 million and $2.2 million respectively. These funds have been deployed to support core protocol development, expand the core team, commission external security audits, and establish the infrastructure necessary for testing and deployment of the Network. All resources have been applied exclusively toward advancing the Network and preparing for the launch of the Token.


Part B - Information about issuer, if different from offeror or person seeking admission to trading



B.1 Issuer different from offerror or person seeking admission to trading
boolean false

B.2 Name
N/A
.

B.3 Legal form
N/A .

B.4 Registered address

Registered addess
N/A .

Country
N/A .

Sub-division
N/A .

B.5 Head office

Head office
N/A .

Country
N/A .

Sub-division
N/A .

B.6 Registration date
N/A .

B.7 Legal entity identifier
N/A .

B.8 Another identifier required pursuant to applicable national law
N/A .

B.9 Parent company
N/A .

B.10 Members of the management body

Member #1
N/A .

Identity
N/A .

Business address
N/A .

Function
N/A .

B.11 Business activity
N/A .

B.12 Parent company business activity
N/A .

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
N/A .

C.2 Legal form
N/A .

C.3 Registered address

Registered address
N/A .

Country
N/A .

Sub-division
N/A .

C.4 Head office

Head office
N/A .

Country
N/A .

Sub-division
N/A .

C.5 Registration date
N/A .

C.6 Legal entity identifier
N/A .

C.7 Another identifier required pursuant to applicable national law
N/A .

C.8 Parent company
N/A .

C.9 Reason for crypto-asset white paper preparation
N/A .

C.10 Members of the management body

Member #1
N/A .

Identity
N/A .

Business address
N/A .

Function
N/A .

C.11 Operator business activity
N/A .

C.12 Parent company business activity
N/A .

C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
N/A .

C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
N/A .

Part D - Information about other token project



D.1 Crypto-asset project name
text Fluent Network

D.2 Crypto-asset name
text BLEND Token

D.3 Abbreviation
text BLEND

D.4 Crypto-asset project description
textBlock The Network is an Ethereum zero-knowledge ('ZK') L2, designed to support multiple virtual machines in a single execution layer. The Network tackles the fragmentation of the crypto-ecosystem, where tools and liquidity are typically distributed within incompatible virtual machines such as the EVM, SVM, and WASM. To achieve this, the Foundation developed a particular virtual machine for the Network, called reduced WebAssembly ('rWasm'). rWasm is a modified version of WebAssembly which has been optimised for zero-knowledge proofs. With rWasm, the Network is able to simulate the execution environments of the EVM, SVM, and WASM, compiling all transaction instructions to rWasm to be then executed together. This way, developers can deploy applications using both Solidity and Rust with native virtual machine support. This allows for real-time composability between smart contracts written in different programming languages and targeting different virtual machines. In the future, rWasm can be expanded to support new types of virtual machines.

The Network supports two different types of applications: shared applications and dedicated applications. Shared applications are smart contract applications that share state on the Network's execution environment. Therefore, shared application transactions can compose in real-time even when targeting different virtual machines and programming languages. Meanwhile, dedicated applications are customisable and independent state machines that can use the Network for proof aggregation and verification purposes.

To deploy smart contracts on the Network, developers can use the Fluentbase framework, which introduces an SDK and a proving system for the Network's state transition function.

The Network's future will rely on decentralised governance. Within the Network's governance, Token holders will be entitled to vote on proposals to shape the Network's future by deciding on Network parameters, treasury allocations, and grant programmes, among other topics.


D.5 Details of all natural or legal persons involved in implementation of crypto-asset project



Person #1
id 1

Type of person
enumeration
Development team


Name of person
text Fluent Labs, Inc

Business address of person
text 8 The Green #5673; Dover, DE 19901

Domicile of company
enumeration
United States of America


D.6 Utility token classification
boolean false

D.7 Key features of goods or services for utility token projects
text Not applicable

D.8 Plans for the token



Description of past milestones
textBlock The Token will be launched with a total supply of 1,000,000,000 tokens. Part of this supply will be distributed through an airdrop campaign to the Protocol's early users at the Token Generation Event ('TGE').

The Foundation conducted the Network seed round in February 2025, raising $8,000,000. In April 2025, the Blended Builders Club was introduced to incubate dApps to be developed within the Network.

In July 2025, $2,200,000 was raised from public investors on Echo. Meanwhile, in August of the current year, the Network's testnet was launched with support for Solidity, Rust, and Vyper.


Description of future milestones
textBlock Looking ahead, the Foundation plans to launch the 'Fluent Connect' programme. This programme will give a score to the Network's users based on their on-chain and social activities. Later on, the Fluent NFT sale will be conducted, where 5,000 NFTs will be minted based on the Fluent Connect programme outcomes. Finally, the Fluent Liquidity programme will be launched following the TGE, coupled with the launch of the Mainnet version of the Network.

D.9 Resource allocation
text In February 2025, in its seed round, the Foundation raised US$8,000,000. The round was led by Polychain Capital. Other investors were Primitive, Dao5, Symbolic Capital, Builder Capital, Nomad Capital, Balaji Srinivasan, Santiago Santos, and others. Subsequently, in July 2025, the Foundation raised $2,200,000 from public investors through the Echo platform.

The funds raised to date have been used to support core protocol development, expand the core team, conduct external security audits, and establish the infrastructure required for testing and deployment of the Network. Therefore, all resources have been allocated toward developing the Network and preparing the launch of the Token.


D.10 Planned use of collected funds or other tokens
text The Token's initial supply, consisting of 1,000,000,000 Tokens, will be distributed as follows:

Core Protocol Development: 40% - 400,000,000 Tokens allocated to expand the engineering team, implement new protocol components, and the Network's maintenance.
Security and Audits: 20% - 200,000,000 Tokens destined for external auditors and continuous monitoring.
Ecosystem Growth: 15% - 150,000,000 Tokens allocated to developer grants, community programmes, and different applications development within the Network.
Legal Compliance and Regulatory Operations: 15% - 150,000,000 Tokens destined for legal and compliance expenses.
Operations and Infrastructure: 10% - 100,000,000 Tokens allocated to host the Network, its testnet environments, and its operational staff.


Part E - Information about offer to public of other tokens or their admission to trading



E.1 Public offering or admission to trading
enumeration
Admission to trading


E.2 Reasons for public offer or admission to trading
textBlock The Issuer is seeking admission to trading of the Token across multiple trading platforms within the European Union, which have been outlined in greater detail within E.33 of this whitepaper. This approach is structured around second market facilitation rather than primary issuance. No public offering will accompany the trading platform admissions. The focus is rather on promoting market liquidity and price discovery mechanisms for the Token.

E.3 Fundraising target



Target expressed in currency
monetary
EUR

Target expressed in units
decimal


Target expressed in digital token identifier
text


E.4 Minimum subscription goals



Goals expressed in currency
monetary
EUR

Goals expressed in units
decimal


Goals expressed in digital token identifier
text


E.5 Maximum subscription goals



Goasl expressed in currency
monetary
EUR

Goals expressed in units
decimal


Goals expressed in digital token identifier
text


E.6 Oversubscription acceptance
boolean false

E.7 Oversubscription allocation
text


Issue price details



E.8 Issue price
decimal


E.9 Official currency determining issue price
enumeration


E.9 Any other tokens determining issue price
text


E.10 Subscription fee



Fee expressed in currency
monetary
EUR

Fee expressed in units
decimal


Fee expressed in digital token identifier
text


E.11 Offer price determination method
text


E.12 Total number of offered or traded other tokens
integer 1000000000

E.13 Targeted holders
enumeration
All types of investors


E.14 Holder restrictions
text The purchase of the Token from EU-regulated Exchanges will be available to all users of such Exchanges. Most trading and exchange services offered by Exchanges are open to retail holders and may be subject to the compliance requirements of the respective Exchange.

The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies.


E.15 Reimbursement notice
boolean true


E.16 Refund mechanism
textBlock


E.17 Refund timeline
text


E.18 Offer phases
textBlock


E.19 Early purchase discount
textBlock


E.20 Time-limited offer
boolean false

E.21 Subscription period beginning
date


E.22 Subscription period end
date


E.23 Safeguarding arrangements for offered funds or other tokens
textBlock


E.24 Payment methods for other token purchase
textBlock


E.25 Value transfer methods for reimbursement
textBlock


E.26 Right of withdrawal
textBlock


E.27 Transfer of purchased other tokens
textBlock


E.28 Transfer time schedule
text


E.29 Purchaser's technical requirements
textBlock Technical requirements will be specified by the Exchange and may include the following:

- A compatible digital wallet or account on supported exchanges;
- Internet access;
- A device (computer or mobile) to manage a digital wallet/private key and/or account on an exchange to carry out transactions


Other token services provider characteristics



E.30 Other token service provider (CASP) name
text


E.31 CASP identifier
LEI


E.32 Placement form
enumeration
Not applicable


Trading platforms characteristics



E.33 Trading platforms name
text The Issuer is seeking admission to trading of the Token on several Exchanges, including but not limited to the following:

- OKX
- Gemini
- Kraken
- Coinbase
- Crypto.com
- Bitvavo
- Bybit
- Gate.io
- Bitstamp
- Bithumb
- Upbit
- MEXC


E.34 Trading platforms market identifier code (MIC)
text Not applicable

E.35 Trading platforms access
text The Exchanges are accessible via their respective websites.

E.36 Involved costs
textBlock The use of services offered by Exchanges may involve costs, including transaction fees, withdrawal fees, and other charges. These costs are determined and set by the respective Exchanges and are not controlled, influenced, or governed by the Person Seeking Admission to Trading.

Consequently, any changes to fee structures or the introduction of new costs are solely at the discretion of these platforms.


E.37 Offer expenses
textBlock Not applicable

E.38 Conflicts of interest
textBlock Not applicable

E.39 Applicable law
textBlock Not applicable

E.40 Competent court
textBlock Not applicable

Part F - Information about other tokens



F.1 Crypto-asset type
text The Token is classified as a "crypto-asset other than asset-referenced token or e-money token" under Title II of the Markets in Crypto-Assets Regulation (EU) 2023/1114.

F.2 Other token functionality
textBlock According to the article 3(1)(5) of MiCA, a crypto-asset is a digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology. As reminded by the European Banking Authority ("EBA"), the term 'right' should be interpreted broadly in accordance with recital (2) of MiCA.

The Token qualifies as a crypto-asset within the meaning of MiCA, as it a digital representation of the right to access the Ecosystem and participate in the Ecosystem's governance. The Token can be transferred and stored using the distributed ledger technology ("DLT").

The Token facilitates Token holders' interaction with the Network by displaying the following functionalities:
- Governance: Token holders will be able to vote on governance proposals, such as Token incentives, Treasury allocation, and Network parameters.
- Staking: To participate as the Network's validators, users will have to stake a certain number of Tokens.
- Rewards: The Network validators within the active set of validators, will be compensated for their work with the Token. The Token will be used to reward early users of the Network through an airdrop campaign.


F.3 Planned application of functionalities
textBlock Each of the functionalities mentioned above will be introduced following the TGE.

A description of the characteristics of the other token, 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
enumeration
Other crypto-asset token white paper


F.5 Type of submission
enumeration
New


F.6 Other token characteristics
textBlock The Token will be launched as an ERC-20 token on the Network to serve as its native token. The Network is an Ethereum L2 that supports different virtual machines, such as the EVM, SVM, and WASM, in a single execution layer. The Token, as the Network's native token, will allow its holders to participate in the Network's governance, stake to become validators, and receive staking rewards.

Therefore, Token holders will have governance rights over the Network. This means that Token holders will be able to vote on governance proposals shaping the Network's future.

Moreover, Token holders will be entitled to staking rights. In other words, Token holders will have to stake a certain number of Tokens to partake as Network validators. To be eligible for validating transactions, creating new blocks, and consequently being compensated with the Token as staking rewards, validators must be part of the active validator set, which comprises the top validators by number of staked Tokens. Lastly, early contributors to the Network will be compensated with the Token through an airdrop campaign.

The Token's characteristics, rights, and obligations may be modified through the Network's governance mechanism. Changes to incentive parameters, Treasury allocation, and other ecosystem developments will require approval through governance proposals submitted and voted on by Token holders. Any modifications to the protocol and Token mechanics will be communicated through the Network's official channels


F.7 Commercial name or trading name
text BLEND

F.8 Website of the issuer
text https://www.fluent.xyz/

F.9 Starting date of offer to the public or admission to trading
date 2026-03-18

F.10 Publication date
date 2026-03-17

F.11 Any other services provided by the issuer
textBlock Not applicable

F.12 Language or languages of white paper
text English

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, where available
text 9JDRM54GC

F.14 Functionally fungible group digital token identifier, where available
text GNL7G95JR

F.15 Voluntary data flag
boolean false

F.16 Personal data flag
boolean true

F.17 LEI eligibility
boolean false

F.18 Home member state
enumeration
Malta


F.19 Host member states #1
enumerationSet
Austria


F.19 Host member states #2
enumerationSet
Belgium


F.19 Host member states #3
enumerationSet
Bulgaria


F.19 Host member states #4
enumerationSet
Croatia


F.19 Host member states #5
enumerationSet
Cyprus


F.19 Host member states #6
enumerationSet
Czechia


F.19 Host member states #7
enumerationSet
Denmark


F.19 Host member states #8
enumerationSet
Estonia


F.19 Host member states #9
enumerationSet
Finland


F.19 Host member states #10
enumerationSet
France


F.19 Host member states #11
enumerationSet
Germany


F.19 Host member states #12
enumerationSet
Greece


F.19 Host member states #13
enumerationSet
Hungary


F.19 Host member states #14
enumerationSet
Iceland


F.19 Host member states #15
enumerationSet
Ireland


F.19 Host member states #16
enumerationSet
Italy


F.19 Host member states #17
enumerationSet
Latvia


F.19 Host member states #18
enumerationSet
Liechtenstein


F.19 Host member states #19
enumerationSet
Lithuania


F.19 Host member states #20
enumerationSet
Luxembourg


F.19 Host member states #21
enumerationSet
Netherlands


F.19 Host member states #22
enumerationSet
Norway


F.19 Host member states #23
enumerationSet
Poland


F.19 Host member states #24
enumerationSet
Portugal


F.19 Host member states #25
enumerationSet
Romania


F.19 Host member states #26
enumerationSet
Slovakia


F.19 Host member states #27
enumerationSet
Slovenia


F.19 Host member states #28
enumerationSet
Spain


F.19 Host member states #29
enumerationSet
Sweden


Part G - Information on rights and obligations attached to other tokens



G.1 Purchaser rights and obligations
textBlock The Token gives its holders the following rights (and has the following features):

- Governance: Token holders will be able to vote on governance proposals, such as Token incentives, Treasury allocation, and Network parameters.
- Staking: To participate as Network's validators users will have to stake a certain number of Tokens.
- Rewards: The Network validators within the active set of validators, will be compensated for their work with the Token. The Token will be used to reward early users of the Network through an airdrop campaign.


G.2 Exercise of rights and obligations
textBlock The rights outlined in Section G.1 may be exercised through the following actions:

- Governance: To exercise their right to partake in the Network's governance, Token holders will have to vote on governance proposals.
- Staking: To exercise their right to stake the Token and participate as Network validators, users will have to stake a certain number of Tokens while running the required software.
- Rewards: To be rewarded with the Token, validators must remain within the active set of Network validators.


G.3 Conditions for modifications of rights and obligations
textBlock The Token's characteristics, rights, and obligations may be modified through the Network's governance mechanism. Changes to incentive parameters, Treasury allocation, and other ecosystem developments will require approval through governance proposals submitted and voted on by Token holders.

Any modifications to the protocol and Token mechanics will be communicated through the Network's official channels.


G.4 Future public offers
textBlock Not applicable

G.5 Issuer retained other token
integer 0

G.6 Utility token classification
boolean false

G.7 Key features of goods or services utility tokens
text Not applicable

G.8 Utility tokens redemption
text Not applicable

G.9 Non-trading request
boolean true

G.10 Other tokens purchase or sale modalities
text Not applicable

G.11 Other tokens transfer restrictions
text The Exchanges may impose restrictions on holders of Tokens on their respective Exchanges, in accordance with applicable laws and internal policies. Token holders who acquire the Token through 'private sales' are subject to restrictions as per the terms of sale.

G.12 Supply adjustment protocols
boolean false

G.13 Supply adjustment mechanisms
text Not applicable

Other token schemes details



G.14 Token value protection schemes
boolean false

G.15 Token value protection schemes description
textBlock Not applicable

G.16 Compensation schemes
boolean false

G.17 Compensation schemes description
textBlock Not applicable

G.18 Applicable law
textBlock Laws of the British Virgin Islands

G.19 Competent court
textBlock Courts in the British Virgin Islands

Part H – Information on underlying technology



H.1 Distributed ledger technology (DTL)
text The Token will be launched on the Network, under the ERC-20 standard.

H.2 Protocols and technical standards
text The Token will be launched on the Network, under the ERC-20 standard guaranteeing industry-standard compatibility.

H.3 Technology used
textBlock As an ERC-20 token, the Token will be deployed as a smart contract on the Network. Users will be able to manage the Token through their own non-custodial EVM-compatible wallet software provided by third parties or by directly interacting with the Token's smart contract through a third-party API.

H.4 Consensus mechanism
text The crypto-asset in scope is implemented on the Fluent, Ethereum and BNB Smart Chain networks following the standards described below.

The following applies to Fluent:
Fluent operates as an Ethereum-secured Layer-2 network that follows a rollup-based consensus model. Transactions are ordered and executed on the Layer-2, while the resulting state transitions are committed to Ethereum Layer-1 for final settlement. The correctness of state updates relies on Ethereum as the ultimate consensus layer, with verification mechanisms defined at the protocol level. Finality is achieved once the committed state is accepted by Ethereum.

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:
BNB 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.


H.5 Incentive mechanisms and applicable fees
text The crypto-asset in scope is implemented on the Fluent, Ethereum and BNB Smart Chain networks following the standards described below.

The following applies to Fluent:
Transaction fees on Fluent are paid by users to cover transaction execution and data availability costs. Fees are used to compensate the sequencer and to fund the submission of state commitments to Ethereum Layer-1.
The fee model is protocol-defined and reflects the computational and settlement resources consumed by the network. Applicable fees are paid at the Layer-2 level and are linked to Ethereum-based settlement costs.

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:
BNB 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.


H.6 Use of distributed ledger technology
boolean false

H.7 DLT functionality description
textBlock Not applicable

Other token audit details



H.8 Audit
boolean true

H.9 Audit outcome
textBlock The Network was audited twice by Veridise. No major issues were found, and every minor issue found has been rectified.

Part I - Information on risks



I.1 Offer-related risks
textBlock The Person Seeking Admission to Trading neither operates, controls, oversees, nor manages the functioning of the Exchanges where the Token will be admitted to trading. Additionally, the Token's underlying protocol may evolve due to ongoing technical, regulatory, and industry developments. Unforeseen risks may arise, and new challenges or opportunities may necessitate changes in the Network's strategies, goals, and structure. The risks outlined below highlight regulatory uncertainty, liquidity limitations, governance risks, network centralisation concerns, security vulnerabilities, and potential adjustments to fees or token supply that could impact the offer and trading of the Token.

- Regulatory Compliance Risks: Although the Token is designed to comply with existing regulations (such as MiCA), evolving regulatory landscapes could impact its classification, trading status, or market/ community acceptance. Changes in regulatory requirements may necessitate modifications to the Network's operation, structure, or governance. Token holders must ensure compliance with local laws, as regulatory treatment of crypto-assets varies across jurisdictions.
- Market Volatility: The Token is subject to extreme price fluctuations, influenced by market speculation, investor sentiment, and broader industry trends. External factors, such as regulatory announcements or technological developments, may further contribute to volatility, potentially leading to financial losses for holders.
- Liquidity Risks: The ability to buy, sell or otherwise transact Tokens depends on activity on decentralised exchanges ("DEXs") and, if applicable, centralised exchanges ("CEXs"). Limited liquidity may result in difficulties executing large trades without significant price impact, increasing the risk of loss.
- Risk of Trading Platforms: When Token holders trade on Exchanges, the Person Seeking Admission to Trading does not act as a contractual party to these transactions. All legal relationships regarding these trading platforms are subject to their respective terms and conditions, with no responsibility assumed by the Person Seeking Admission to Trading for their operations, services, or outcomes.
- Risk of Delisting: There is no guarantee that the Token will remain listed on any exchange. Delisting could significantly hinder the ability to trade Tokens, reducing liquidity and market value.
- Risk of Bankruptcy: The Exchanges or trading platforms where the Token is listed may become insolvent or cease operations, potentially resulting in a loss of access to funds or Tokens.
- Blockchain and Smart Contract Dependency: The Token relies entirely on its blockchain infrastructure. Any network downtime, congestion, security vulnerabilities, or smart contract failures could negatively impact its functionality, accessibility, or security. Additionally, the Network may initially operate under a centralised or permissioned model, where specific providers or node operators manage the network. This structure presents centralisation risks, including the potential for censorship or data monetisation.
- Operational Risks: Risks associated with the Token issuer/offeror's internal processes, personnel, and technologies may impact the ability to manage the Token's operations effectively. Failures in operational integrity could lead to disruptions, financial losses, or reputational damage.
- Financial Risks: The Token issuer/offeror may face financial risks, including liquidity shortages, credit risks, or market fluctuations, which could affect its ability to continue operations, meet obligations, or sustain the stability and value of the Token.
- Legal Risks: Uncertainties in legal frameworks, regulatory changes, potential lawsuits, or adverse legal rulings could pose significant risks, affecting the legality, usability, or value of the Token.
- Fraud and Mismanagement Risks: The risk of fraudulent activity or mismanagement within the Token issuer/offeror's operations may impact the credibility of the project and the usability or value of the Token.
- Reputational Risks: Negative publicity – whether due to operational failures, security breaches, or associations with illicit activities – could damage the Token issuer/offeror's reputation and, by extension, impact the value and acceptance of the Token.
- Technology Management Risks: Inadequate management of technological updates or failure to keep pace with advancements may result in security vulnerabilities, inefficiencies, or obsolescence of the Token and its supporting infrastructure.
- Dependency on Key Individuals: The success of the Token and its ecosystem may be highly dependent on key individuals. Loss or changes in project leadership could lead to operational disruptions, a loss of trust, or potential project failure.
- Conflicts of Interest: Misalignment of interests between the Token issuer/offeror and Token holders may lead to governance decisions that are not in the best interests of the community, potentially affecting the value of the Token or damaging the credibility of the project.
- Counterparty Risks: The Token issuer/offeror's reliance on external partners, service providers, and collaborators introduces risks related to non-fulfilment of obligations, which may affect the Token's operations, liquidity, or overall ecosystem stability.
- Industry Competition Risks: The Token issuer/offeror faces competition from other projects, including larger and well-funded ventures that may attract more users and liquidity, potentially diminishing the viability of the Token.
- Investor Vesting Risks: While Tokens allocated to the team and other stakeholders may be subject to a vesting schedule to prevent "rug pulls" and conflicts of interest, the unlocking of Tokens over time could affect supply and demand trends and liquidity.
- Speculative Nature of the Token: Other than as stated herein with respect to the rights, functions, governance, staking, and fee-payment, the Token has no inherent utility beyond market sentiment and community-driven interest. Its value is highly speculative and subject to fluctuations based on external perceptions.
- Unanticipated Risks: There may be additional risks that cannot be foreseen. Some risks may materialise as unexpected variations or combinations of the factors discussed in this section.


I.2 Issuer-related risks
textBlock N/A - the Issuer is the same as the Person Seeking the Admission of the Token to Trading.

I.3 Other tokens-related risks
textBlock - Market Volatility Risks: The Token's value is highly volatile and may fluctuate due to market speculation, investor sentiment, regulatory developments, and technological advancements. External factors, such as shifting trends in the crypto industry, changing demand for blockchain services, or macroeconomic conditions, could contribute to extreme price fluctuations, potentially leading to total depreciation.
- Speculative Nature: No assurances of future value, performance, or rewards are made regarding the Token. Other than as stated herein with respect to the rights, functions, governance, staking, and fee-payment, the Token has no inherent or guaranteed utility beyond its role in the Network, and its valuation depends entirely on user adoption, demand, and community engagement. If adoption of the Network fails to grow as expected, the Token's value may be significantly impacted.
- Liquidity Risks: The ability to trade the Token depends on the level of activity on DEXs and, where applicable, CEXs. Low trading volume may result in difficulties executing large transactions without significant price impact. Limited demand for the Token or the underlying protocol may further reduce liquidity, making it difficult to acquire, sell or otherwise transact with the Token.
- Adoption and Network Demand Risks: The long-term success of the Token is dependent on widespread adoption of the Network. Adoption is influenced by various external factors, including user demand, competitive economic conditions, and organic community-driven expansion. The Person Seeking Admission to Trading has no control over the pace of adoption, and there is no guarantee that the Network will gain sufficient traction to sustain its economic model. If demand is too low, obtaining services through the Network may be difficult, while an inadequate supply may lead to delays in accessing services.
- Blockchain Dependency Risks: The Token operates exclusively on its underlying blockchain network. Any disruptions, such as network congestion, downtime, or security vulnerabilities, could impact the ability to transfer, store, or trade the Token. Changes to blockchain infrastructure, governance, or transaction fees may also influence the Token's usability and cost-effectiveness.
Transaction Costs: While blockchain fees are generally low, network congestion, high demand, or changes in blockchain fee structures may increase transaction costs, potentially reducing the economic viability of using the Token within the Network.

Security Risks:
- Smart Contract Vulnerabilities: Despite security audits and best practices, unforeseen vulnerabilities in smart contracts could lead to security breaches, impacting Token security or functionality.
- Private Key Management: Token holders are solely responsible for safeguarding their private keys and recovery phrases. Loss of wallet credentials will result in the permanent loss of Tokens, as blockchain transactions are irreversible.
- Scam and Fraud Risks: Token holders are exposed to risks associated with scams, phishing attacks, fake giveaways, impersonation of the Token issuer/offeror or its team, counterfeit Tokens, and fraudulent airdrops. Engaging with unverified third-party platforms or unofficial communications increases the risk of fraud.
- Community and Narrative Risks: The Token's success is closely tied to community interest and the broader crypto narrative. Macroeconomic trends, emerging competitors, or declining community engagement may negatively impact the Token's perceived value and adoption.

Regulatory and Compliance Risks:
- Evolving Legal Frameworks: Regulations governing crypto-assets differ across jurisdictions and are subject to change. New legal requirements may impact the Token's classification, availability, or functionality.
- Jurisdictional Restrictions: Some jurisdictions may impose restrictions or prohibitions on the trading or use of the Token, limiting its accessibility for certain users.
- Regulatory Harmonisation Risks: A lack of global regulatory alignment may create uncertainty, with some authorities potentially classifying the Token as a security or financial instrument, leading to increased compliance costs and legal obligations.
- Regulatory Enforcement Risks: Government agencies may take enforcement actions against the Token issuer/offeror if the Token is deemed an unregistered security or if other financial laws are found to have been violated. Such actions could negatively impact the Token's availability, appeal, and value.

- Anti-Money Laundering ("AML") & Counter-Terrorism Financing ("CTF") Risks: Crypto transactions may be scrutinised for potential links to illicit activities. Authorities may take action against wallets or platforms suspected of facilitating money laundering or terrorist financing, affecting the ability of Token holders to use or trade their assets.
- Taxation Risks: The tax treatment of the Token varies by jurisdiction, and Token holders are solely responsible for understanding and complying with applicable tax laws. Any appreciation, conversion, or sale of the Token may trigger tax obligations that differ depending on the regulatory environment.
- Team Vesting and Token Release Risks: Tokens allocated to the team and other stakeholders may be subject to a vesting and unlock schedule. When these Tokens are vested, unlocked, and released into circulation, they may affect demand trends and liquidity.
- Technological Obsolescence Risks: The blockchain and crypto industries evolve rapidly. The emergence of new technologies, changes in market demand, or advancements in competing protocols could render the Token or its underlying blockchain infrastructure less competitive, reducing adoption and utility.
- Software Weakness Risks: The Token's infrastructure relies on relatively new blockchain technologies, which may contain undiscovered bugs, vulnerabilities, or inefficiencies. There is no guarantee that the process of transacting, storing, or interacting with the Token will be uninterrupted or error-free.
Unanticipated Risks: Beyond the risks outlined above, additional unforeseen risks may emerge due to changes in regulatory, technological, or macroeconomic conditions, potentially affecting the Token's security, functionality, or value.


I.4 Project implementation-related risks
textBlock The Person Seeking Admission to Trading neither operates, controls, oversees, nor manages the technology underlying the Network. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist. Additionally, the success and sustainability of the project rely on various external factors, including macroeconomic conditions, regulatory developments, and technological advancements.

Technical Development Risks:
- Smart Contract Issues: Despite robust security measures, unforeseen vulnerabilities or bugs in the smart contracts could disrupt Token distribution, refunds, or vesting mechanisms.
- Blockchain Dependency: The Token operates exclusively on its underlying blockchain. Any network congestion, downtime, or security breaches could impact the project's implementation and functionality.
- Risk of Security Weaknesses in Core Infrastructure: The project relies on open-source software, which may be modified by third parties not directly affiliated with the Issuer. Weaknesses or bugs introduced into the core infrastructure could compromise security and lead to the loss of digital assets. Furthermore, malfunctions or inadequate maintenance of the Network may negatively impact the Token's usability.
Bugs in Core Blockchain Code: Even with rigorous testing, unknown bugs may exist in the blockchain protocol, potentially leading to disruptions, incorrect transaction processing, or security vulnerabilities.

Regulatory and Compliance Risks:
- Regulatory Actions in One or More Jurisdictions: The Token and the underlying Network could be impacted by regulatory inquiries or actions, which may restrict further development, implementation, or usage.
- Evolving Laws and Regulations: New and changing laws related to financial securities, consumer protection, data privacy, cybersecurity, and intellectual property could impact the project. Compliance with these laws may require significant resources and could impose additional operational constraints.
- Governance Risk: Decision-making mechanisms in blockchain governance may be inefficient, slow, or disproportionately influenced by specific stakeholders, leading to potential centralisation or unfavourable network changes.

Operational Risks:
- Resource Allocation: The project's success depends on the issuer of the Token and its core team allocating sufficient resources (both financial and non-financial) to ensure timely development and deployment. Poor resource management could lead to delays or failure to achieve key milestones.
- Team Vesting Risks: While the team's Tokens may be subject to a vesting and unlock schedule to align interests with the community, the eventual vesting and unlocking of these Tokens may impact market stability or long-term commitment from team members.

Market Adoption Risks:
- Competitive Environment: The crypto industry is highly competitive and trend-driven. There is a risk that the Token may fail to capture sufficient interest, limiting its adoption.
- Community Engagement Risks: The success of the Token depends heavily on community-driven sentiment and engagement. Failure to build or sustain an active community could hinder growth and long-term tradability

Timeline and Milestone Risks:
- Delayed Milestones: Key deliverables such as Token distribution and liquidity access may face delays due to technical, operational, or funding challenges.
- CEX Listing Risks: Listings on centralised exchanges depend on securing the necessary funding for listing fees and meeting platform-specific requirements. Delays or insufficient resources could postpone broader market/ community access.

Ecosystem Risks:
- Dependence on External Partners: The project relies on partnerships with infrastructure providers, liquidity providers/ market makers, exchanges and other third-party service providers. Any failure or delay from these partners could disrupt implementation plans.
- Risk of Withdrawing Partners: The Token holder understands that the feasibility of the project depends strongly on the collaboration of service providers and other key stakeholders. A loss of critical partnerships could impact project sustainability.

Technology and Software Risks:
- Risk of Software Weakness: The Token holder acknowledges that blockchain and smart contract technologies are still evolving. There is no guarantee that Token usage will be uninterrupted or error-free. Vulnerabilities in the underlying blockchain, smart contracts, or supporting technologies could lead to the complete loss of Tokens or their functionality.
- Dependency on Underlying Technology: The Network relies on blockchain infrastructure, hardware, and network connectivity, all of which may be subject to failures, outages, or vulnerabilities.
- Risk of Technological Disruption: The emergence of new technology, such as quantum computing, could undermine the security of blockchain encryption and compromise the integrity of digital assets.

Network Security Risks:
- Network Attacks and Cybersecurity Threats: Blockchain networks can be vulnerable to cyberattacks such as 51% attacks, Sybil attacks, or distributed denial-of-service ("DDoS") attacks. These threats could disrupt network operations and compromise security.
Blockchain Network Attacks: The Network may be subject to validation attacks, including double-spend attacks, reorganisations, majority mining power attacks, "vampire" attacks and work race condition attacks. Successful attacks could compromise the proper execution of transactions and smart contracts.

Privacy and Anonymity Risks:
- Public Ledger Transparency: Blockchain transactions are recorded on a public ledger, which may expose transaction history and financial activity. Certain transactions could be linked to specific wallet addresses, making users vulnerable to fraud, phishing attacks, or targeted scams.

Economic and Governance Risks:
- Consensus Failures or Forks: Errors in the consensus mechanism could lead to forks, where multiple versions of the ledger coexist, or network halts, reducing trust in the network.
- Economic Self-Sufficiency: The long-term sustainability of the Token ecosystem depends on sufficient transaction volume to generate fees to support rewards for validators, which in turn maintain network security. A lack of adoption could lead to governance-driven changes to monetary policy, fee structures, or consensus mechanisms.
- Incentive Model Risks: Changes to block rewards, staking incentives, or governance models may be required to maintain network participation. Governance decisions could result in modifications that impact Token holders, including inflationary adjustments, transaction fees, or redistribution of rewards.

Software Weakness Risks:
- Unforeseen Bugs and Security Vulnerabilities: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures.

Unanticipated Risks:
- Unforeseen Regulatory, Technological, or Economic Challenges: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory crackdowns, unforeseen Network vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable.


I.5 Technology-related risks
textBlock The Person Seeking Admission to Trading neither operates, controls, oversees, nor manages the technology underlying the Network. While efforts are made to ensure security and stability, blockchain-based technologies are still evolving, and various risks exist.

Blockchain Dependency Risks:
- Network Downtime and Congestion: The Token relies entirely on its underlying blockchain network, which may experience outages, congestion, or downtime. Such events could disrupt Token transfers, trading, or other functionalities.
- Scalability Challenges: As transaction volume grows, the blockchain network may face scaling limitations. Increased congestion could lead to slower transaction processing times and higher fees, reducing efficiency and usability.
- Settlement and Transaction Finality Risks: Blockchain transactions are designed to be irreversible; however, under exceptional circumstances such as network forks or consensus failures, there remains a theoretical risk that transactions could be reversed, or multiple competing ledger versions could persist. Transactions sent to an incorrect address are not recoverable, leading to permanent loss of assets.

Smart Contract Risks:
- Vulnerabilities: While smart contracts are developed with security measures, undiscovered vulnerabilities or exploits may impact Token security, distribution, or access. Bugs in the contract code may lead to unintended loss of Tokens, unauthorised transactions, or exposure to external attacks.
- Immutability Risks: Once deployed, some smart contracts cannot be altered. Errors or security flaws in the code could result in operational failures without the possibility of corrections.
- Security Exploits: Bugs or vulnerabilities in smart contracts may expose the Token ecosystem to potential hacks, allowing attackers to manipulate transactions, drain liquidity, or disrupt contract execution.

Network Security Risks:
- Risk of Attacks and Forks: The blockchain may be susceptible to consensus-related attacks, such as double-spend attacks, majority validation power takeovers, censorship attacks, or forks. These risks could affect Token transactions, balance integrity, and overall network security.
- Cybercrime and Theft Risks: Despite security efforts, blockchain-based assets and services may be exposed to cyberattacks, including hacking, phishing, or malware threats. Compromised wallets, exchanges, or smart contracts could lead to asset theft, loss of funds, or disruptions in Token functionality.
- Data Corruption Risks: The reliability of blockchain data could be compromised due to software bugs, human error, or deliberate tampering. Such incidents may affect transaction records, network integrity, and user confidence in the system.

Wallet and Storage Risks:
- Private Key Management: Token holders are solely responsible for securing their private keys and recovery phrases. The loss of private keys results in irreversible loss of Tokens, as blockchain transactions are final and cannot be undone.
- Compatibility Issues: The Token is supported only by blockchain-compatible wallets. Incompatibility with specific wallet software, network malfunctions, or wallet provider shutdowns may affect access to and usability of the Token.

Ecosystem Dependency Risks:
- DEX and CEX Integration Issues: The Token's availability depends on integration with DEXs and CEXs. Technical failures, security breaches, or delisting from these platforms could limit liquidity, disrupt trading, and reduce Network accessibility.
- Reliance on Third-Party Services: Many blockchain services, including wallets, bridges, and oracles, depend on third-party providers. Failures, security breaches, or regulatory actions against these services could negatively affect the functionality of the Token.
- Centralisation Concerns: Although blockchain networks are designed to be decentralised, a small number of validators or node operators could introduce centralisation risks. This may lead to potential censorship, control over transactions, or increased vulnerability to governance attacks.

Software and Protocol Risks:
- Bugs in Core Blockchain Code: Despite rigorous testing, undiscovered bugs in the core blockchain protocol could lead to network failures, incorrect transaction processing, or security vulnerabilities. A failure to address such issues promptly could result in loss of user confidence and network instability.
- Risk of Technological Disruption: Emerging technologies, such as quantum computing, could potentially compromise blockchain encryption, making networks vulnerable to attacks that could compromise data integrity or enable unauthorised asset transfers.
- Dependency on Underlying Technology: The stability of the Token ecosystem relies on underlying technical infrastructures, including internet connectivity, computing hardware, and cryptographic algorithms. Disruptions in these foundational technologies may impact network security and operational efficiency.

Privacy and Anonymity Risks:
- Public Ledger Transparency: Blockchain transactions are recorded on a publicly accessible ledger, which may expose sensitive transaction data. While addresses do not directly reveal identities, sophisticated data analysis could potentially link certain transactions to specific individuals or entities.
- Exposure to Fraud and Targeted Attacks: Increased transparency may lead to risks such as phishing, fraud, or unauthorised tracking of user activity by malicious actors. Individuals with significant Token holdings may be targeted for scams or social engineering attacks.

Economic and Network Viability Risks:
- Economic Self-Sufficiency: The long-term sustainability of the Token ecosystem depends on maintaining sufficient transaction volume to generate rewards for incentivising validators to ensure network security. If network adoption remains low, there is a risk of reduced validator participation, increased transaction costs, or a need for governance-driven changes to monetary policy, fee structures, or consensus mechanisms.
- Incentive Model Risks: Changes to block rewards, staking incentives, or governance models may be required to ensure ongoing network security and sustainability. Governance proposals may introduce modifications that impact Token holders, including inflation adjustments, transaction fees, or redistribution of rewards.

Software Weakness Risks:
- Unforeseen Bugs and Security Vulnerabilities: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures.

Unanticipated Risks:
- Unforeseen Regulatory, Technological, or Economic Challenges: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory crackdowns, unforeseen Network vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable.


I.6 Mitigation measures
textBlock Not applicable

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
textBlock The token operates across Fluent L2, Ethereum, and BNB Smart Chain networks with an estimated annual energy consumption of 20,191 kWh and carbon emissions of 6.72 tonnes CO2e per year, calculated using a conservative bottom-up approach based on node hardware requirements and network participation. Approximately 31.59% of the network's energy derives from renewable sources, determined by mapping node geographic distribution against regional renewable energy data from Our World in Data. The relatively modest environmental impact reflects the energy-efficient Proof-of-Stake and Proof-of-Staked Authority consensus mechanisms employed by these networks, which eliminated energy-intensive mining operations following Ethereum's 2022 transition from Proof-of-Work.

Mandatory information on principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism



General information about adverse impacts



S.1 Name
text Fluent (BVI) Limited

S.2 Relevant legal entity identifier
text 2195789

S.3 Name of the crypto-asset
text BLEND Token

S.4 Consensus mechanism
text The crypto-asset in scope is implemented on the Fluent, Ethereum and BNB Smart Chain networks following the standards described below.

The following applies to Fluent:
Fluent operates as an Ethereum-secured Layer-2 network that follows a rollup-based consensus model. Transactions are ordered and executed on the Layer-2, while the resulting state transitions are committed to Ethereum Layer-1 for final settlement. The correctness of state updates relies on Ethereum as the ultimate consensus layer, with verification mechanisms defined at the protocol level. Finality is achieved once the committed state is accepted by Ethereum.

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:
BNB 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.


S.5 Incentive mechanisms and applicable fees
text The crypto-asset in scope is implemented on the Fluent, Ethereum and BNB Smart Chain networks following the standards described below.

The following applies to Fluent:
Transaction fees on Fluent are paid by users to cover transaction execution and data availability costs. Fees are used to compensate the sequencer and to fund the submission of state commitments to Ethereum Layer-1.
The fee model is protocol-defined and reflects the computational and settlement resources consumed by the network. Applicable fees are paid at the Layer-2 level and are linked to Ethereum-based settlement costs.

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:
BNB 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.


S.6 Beginning of period to which disclosed information relates
date 2026-01-05

S.7 End of period to which disclosed information relates
date 2027-01-05

Mandatory key indicator



S.8 Energy consumption
energy (kWh)  20191.42942

Sources and methodologies



S.9 Energy consumption sources and methodologies
textBlock Since the crypto-asset is not yet been fully implemented at the time of writing the white paper, conservative estimates regarding the expected activity have been made.

For the calculation of energy consumptions of the underlying networks, the so called 'bottom-up' approach is being used. The nodes are considered to be the central factor for the energy consumption of the network. The main determinants for estimating the hardware used within the network are the requirements for operating the client software.

To determine the energy consumption of a token, the energy consumption of the networks involved is calculated first. For the energy consumption of the token, a fraction of the energy consumption of the network is attributed to the token, which is determined based on the (expected) activity of the crypto-asset within the network.

The information regarding the hardware used and the number of participants in the network is based on assumptions that are verified with best effort using empirical data. In general, participants are assumed to be largely economically rational. As a precautionary principle, we make assumptions on the conservative side when in doubt, i.e. making higher estimates for the adverse impacts.


Supplementary information on principal adverse impacts on climate and other environment-related adverse impacts of consensus mechanism



Supplementary key indicators



S.10 Renewable energy consumption
percent 31.5940287361%

S.11 Energy intensity
energy (kWh) 0.00010

S.12 Scope 1 DLT GHG emissions - controlled
GHG emissions (tCO2e) 0.00000

S.13 Scope 2 DLT GHG emissions - purchased
GHG emissions (tCO2e) 6.71983

S.14 GHG intensity
GHG emissions (tCO2e) 0.00004

Sources and methodologies



S.15 Key energy sources and methodologies
textBlock 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
textBlock 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.

Optional information on principal adverse impacts on the climate and on other environment-related adverse impacts of the consensus mechanism



Optional indicators



S. 17 Energy mix
percent


S.18 Energy use reduction



Energy use reduction target (absolute value)
energy (kWh)


Energy use reduction target (percentage)
percent


S.19 Carbon intensity (kgCO2e/kWh)
decimal


S.20 Scope 3 DLT GHG emissions - value chain
GHG emissions (tCO2e)


S.21 GHG emissions reduction targets or commitments
textBlock


S.22 Generation of waste electrical and electronic equipment (WEEE)
mass (tonnes)


S.23 Non-recycled WEEE ratio
percent


S.24 Generation of hazardous waste
mass (tonnes)


S.25 Generation of waste (all types)
mass (tonnes)


S.26 Non-recycled waste ratio (all types)
percent


S.27 Waste intensity (all types)
mass (tonnes)


S.28 Waste reduction targets or commitments (all types)
textBlock


S.29 Impact of use of equipment on natural resources
textBlock


S.30 Natural resources use reduction targets or commitments
textBlock


S.31 Water use
volume (m3)


S.32 Non recycled water ratio
percent


Sources and methodologies



S.33 Other energy sources and methodologies
textBlock


S.34 Other GHG sources and methodologies
textBlock


S.35 Waste sources and methodologies
textBlock


S.36 Natural resources sources and methodologies
textBlock

https://xbrl.org/2024/iso3166#VG https://xbrl.org/2024/iso3166#VG https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#DevelopmentTeam https://xbrl.org/2024/iso3166#US https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#AdmissionToTrading https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#AllTypesOfInvestors https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#NotApplicablePlacementForm https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#OtherCryptoassetWhitePaper https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#NewTypeOfSubmission https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#MaltaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#AustriaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#BelgiumMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#BulgariaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#CroatiaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#CyprusMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#CzechiaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#DenmarkMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#EstoniaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#FinlandMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#FranceMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#GermanyMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#GreeceMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#HungaryMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#IcelandMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#IrelandMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#ItalyMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#LatviaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#LiechtensteinMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#LithuaniaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#LuxembourgMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#NetherlandsMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#NorwayMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#PolandMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#PortugalMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#RomaniaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#SlovakiaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#SloveniaMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#SpainMemberState https://www.esma.europa.eu/taxonomy/2025-03-31/mica/#SwedenMemberState xbrli:pure utr:kWh utr:tCO2e 254900WUMRT0UHOVGX35 2025-01-012035-12-31 254900WUMRT0UHOVGX35 2035-12-31 254900WUMRT0UHOVGX35 2025-01-012035-12-31 1 254900WUMRT0UHOVGX35 2025-01-012035-12-31 1