MiCA Whitepaper Inline XBRL

N	Field	Content
00	Table of contents	General Information Part A: Information about the offeror or the person seeking admission to trading Part B: Information about the issuer, if different from the offeror or person seeking admission to trading Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 Part D: Information about the crypto-asset project Part E: Information about the offer to the public of crypto-assets or their admission to trading Part F: Information about the crypto-assets Part G: Information on the rights and obligations attached to the crypto-assets Part H: Information on the underlying technology Part I: Information on the risks Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
01	Date of notification	2026-05-13
02	Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114	This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The operator of the trading platform of the crypto-asset is solely responsible for the content of this crypto-asset white paper.
03	Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114	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	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	The utility token referred to in this white paper may not be exchangeable against the good or service promised in this white paper, especially in the case of a failure or discontinuation of the crypto-asset project.
06	Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114	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.
07	Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114	Warning This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.
08	Characteristics of the crypto-asset	QNT is an ERC20 token issued on the Ethereum blockchain used within the Quant Network ecosystem in connection with the Overledger infrastructure. Overledger is an operating system that enables interoperability between different distributed ledger technologies and existing systems. It provides a gateway-based approach that allows applications to connect to multiple blockchains simultaneously without requiring changes to the underlying networks. Within this framework, QNT is used to access the Overledger infrastructure. The token is required to obtain licences for the use of Overledger and to enable the operation of applications built on the infrastructure. The token is therefore utilised as part of the access and licensing model implemented by Quant Network. Holders of QNT may use the token in accordance with the technical requirements of the Overledger infrastructure and any applicable licensing arrangements. The ability to use the token is dependent on access to compatible infrastructure and compliance with applicable terms set by Quant Network. Transactions involving QNT are recorded on a distributed ledger and, once confirmed, cannot be reversed. There are no inherent rights attached to QNT beyond its functional use within the Quant ecosystem. Any access to services is subject to separate contractual or technical conditions defined by Quant Network.
09		The QNT token provides access to services within the Quant Overledger infrastructure. It enables developers and users to utilise the infrastructure and associated services provided by Quant Network AG. These services include the development, deployment and use of multi-chain applications (MApps), as well as interaction with tools such as the Overledger Software Development Kit (SDK) and Blockchain Programming Interface (BPI). Access to applications within the Quant ecosystem may require the holding of a minimum quantity of QNT tokens. The token is also used within the infrastructure for authentication and authorisation purposes, enabling users to access specific functionalities and services. The quality and scope of these services depend on the continued development and operation of the Overledger infrastructure, including the release of new features, integrations and enterprise solutions.
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.

N	Field	Content
A.1	Name	N/A
A.2	Legal form	N/A
A.3	Registered address	N/A
A.4	Head office	N/A
A.5	Registration date	N/A
A.6	Legal entity identifier	N/A
A.7	Another identifier required pursuant to applicable national law	N/A
A.8	Contact telephone number	N/A
A.9	E-mail address	N/A
A.10	Response time (Days)	N/A
A.11	Parent company	N/A
A.12	Members of the management body	N/A
A.13	Business activity	N/A
A.14	Parent company business activity	N/A
A.15	Newly established	N/A
A.16	Financial condition for the past three years	N/A
A.17	Financial condition since registration	N/A

N	Field	Content
E.1	Public offering or admission to trading	ATTR
E.2	Reasons for public offer or admission to trading	By admitting the QNT asset to trading, holders of the token will gain transparent price discovery and improved liquidity. This enables the project’s community and ecosystem participants to more easily enter and exit positions, supporting a dynamic and efficient market.
E.3	Fundraising target	N/A
E.4	Minimum subscription goals	N/A
E.5	Maximum subscription goals	N/A
E.6	Oversubscription acceptance	N/A
E.7	Oversubscription allocation	N/A
E.8	Issue price	N/A
E.9	Official currency or any other crypto-assets determining the issue price	N/A
E.10	Subscription fee	N/A
E.11	Offer price determination method	N/A
E.12	Total number of offered/traded crypto-assets	12072738 The number of QNT crypto-assets in circulation may vary over time due to distribution dynamics, secondary market activity, and the use of tokens within the Overledger ecosystem. The contract was initialised with a supply of 45,467,000 QNT in 2018. On the 14th of September 2018, a subsequent burn reduced the total supply to approximately 14,612,493 QNT. The maximum supply of QNT is capped at 14,881,364 tokens, and no additional tokens can be created beyond this limit. As a result, variations in circulating supply are not driven by issuance mechanisms but instead reflect factors such as tokens held in treasury, tokens locked in enterprise licensing arrangements, tokens held by long-term holders, and tokens available on secondary markets.
E.13	Targeted holders	ALL
E.14	Holder restrictions	N/A
E.15	Reimbursement notice	N/A
E.16	Refund mechanism	N/A
E.17	Refund timeline	N/A
E.18	Offer phases	N/A
E.19	Early purchase discount	N/A
E.20	Time-limited offer	N/A
E.21	Subscription period beginning	N/A
E.22	Subscription period end	N/A
E.23	Safeguarding arrangements for offered funds/crypto-Assets	N/A
E.24	Payment methods for crypto-asset purchase	N/A
E.25	Value transfer methods for reimbursement	N/A
E.26	Right of withdrawal	N/A
E.27	Transfer of purchased crypto-assets	When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account. If a client wants to hold the token in their own wallet, they will need to (i) provide an external blockchain wallet address, where the crypto-assets will be sent if a withdrawal is initiated and (ii) satisfy all other requirements applicable to a withdrawal in line with the Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets.
E.28	Transfer time schedule	N/A
E.29	Purchaser's technical requirements	When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account and a client does not need to fulfill any other technical requirement to hold the crypto-assets on their Bitstamp account, apart from have either a computer or phone with an internet connection and appropriate software in order to interact with the Bitstamp services.
E.30	Crypto-asset service provider (CASP) name	N/A
E.31	CASP identifier	N/A
E.32	Placement form	N/A
E.33	Trading platforms name	Bitstamp Europe S.A.
E.34	Trading platforms Market identifier code (MIC)	BESA
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
E.38	Conflicts of interest	There are no conflicts of interest arising at the moment of writing the white paper in relation to the offer or admission to trading. Bitstamp Group has a strict Code of Conduct and Trading Policy in place. They both mitigate the possibility of conflicts of interest. In accordance with the Code of Conduct all officers, directors, employees, agents, representatives, contractors and consultants (and other persons, regardless of job or position), are required to report any situation where there is the potential for conflict of interest between their interests and interests of Bitstamp. The Trading Policy that is in place within the Bitstamp Group prohibits all forms of market manipulation and has been designed to prevent insider trading.
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.

N	Field	Content
F.1	Crypto-asset type	Crypto-assets other than asset-referenced tokens or e-money tokens
F.2	Crypto-asset functionality	QNT is the native crypto-asset of the Quant Network ecosystem and is designed to enable access to, and operation of, the Overledger infrastructure, which facilitates interoperability between different DLTs and existing enterprise systems. The primary functionality of QNT is to serve as a licensing and access token for the Overledger infrastructure. Enterprises, developers, and institutions are required to hold or utilise QNT tokens in order to obtain access to Overledger services, including the development and deployment of mApps. Access to the infrastructure is typically structured through time-based licensing models, where a corresponding amount of QNT tokens is locked or utilised for the duration of the licence period. QNT also functions as a means of payment within the ecosystem. It is used to pay for infrastructure usage fees, including gateway operations, transaction-related services, and other Overledger functionalities. The token enables interactions between different participants in the network, including developers, enterprises, and infrastructure providers. In addition, QNT facilitates interoperability by acting as a coordination and settlement mechanism across different blockchain networks and legacy systems connected through Overledger.
F.3	Planned application of functionalities	Not applicable, as all functionalities described in F.2 have already been implemented.
F.4	Type of crypto-asset white paper	OTHR
F.5	The type of submission	NEWT
F.6	Crypto-asset characteristics	QNT is a crypto-asset used within the Quant Network ecosystem in connection with the Overledger infrastructure. Following a crypto-asset burn conducted in September 2018, which reduced the overall supply, the total supply of QNT is now fixed at 14,881,364 assets.Within this framework, QNT is used to access the Overledger infrastructure. The token is required to obtain licences for the use of Overledger and to enable the operation of applications built on the infrastructure. The token is therefore utilised as part of the access and licensing model implemented by Quant Network. Holders of QNT may use the token in accordance with the technical requirements of the Overledger infrastructure and any applicable licensing arrangements. The ability to use the token is dependent on access to compatible infrastructure and compliance with applicable terms set by Quant Network. Transactions involving QNT are recorded on a distributed ledger and, once confirmed, cannot be reversed. There are no inherent rights attached to QNT beyond its functional use within the Quant ecosystem. Any access to services is subject to separate contractual or technical conditions defined by Quant Network. The token itself does not grant enforceable rights to goods or services without such arrangements.
F.7	Commercial name or trading name	N/A as DTI is provided in F.13
F.8	Website of the issuer	https://quant.network/
F.9	Starting date of offer to the public or admission to trading	2026-06-16
F.10	Publication date	2026-06-15
F.11	Any other services provided by the issuer	Not applicable
F.12	Language or languages of the crypto-asset white paper	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	N25N2VFT7, Z3SN3NVM7
F.14	Functionally fungible group digital token identifier, where available	L8M8X31JL
F.15	Voluntary data flag	FALSE
F.16	Personal data flag	TRUE
F.17	LEI eligibility	TRUE
F.18	Home Member State	Luxembourg
F.19	Host Member States	Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden

N	Field	Content
G.1	Purchaser rights and obligations	Not applicable as the QNT crypto-asset holders do not acquire any ownership, equity, profit participation, repayment, or redemption rights against any natural or legal person associated with the QNT project. Holding QNT does not give rise to contractual claims or entitlements against any natural or legal person. Holding QNT provides only the practical ability to access and use the Overledger infrastructure and associated services in accordance with the technical requirements and contractual terms set by Quant Network. These functionalities are described in field F.2.
G.2	Exercise of rights and obligations	Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.
G.3	Conditions for modifications of rights and obligations	Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.
G.4	Future public offers	Not applicable
G.5	Issuer retained crypto-assets	4071034
G.6	Utility Token Classification	TRUE
G.7	Key features of goods/services of utility tokens	The QNT token provides access to the Quant Overledger infrastructure, which constitutes a software-based infrastructure designed to enable interoperability between different distributed ledger technologies and to allow applications to operate across multiple blockchain networks. Through the use of QNT, users and developers are able to access a system that facilitates the exchange of data and communication between otherwise incompatible blockchain environments, thereby removing reliance on a single distributed ledger and enabling cross-chain functionality. The infrastructure supports the development and execution of multi-chain applications, which are capable of operating across different blockchain protocols while maintaining a unified application logic. The Overledger architecture is structured in multiple layers, including transaction, messaging, filtering and ordering, and application layers, which together enable the processing, validation and coordination of information across different systems. Developers are provided with standardised tools, including a Blockchain Programming Interface and Software Development Kit, which allow applications to be built and deployed without requiring detailed knowledge of each underlying blockchain protocol. The infrastructure further enables integration with legacy systems and external data sources, allowing existing infrastructure to connect with distributed ledger technologies and supporting broader use cases across enterprise and institutional environments. Access to these services is controlled through the QNT token, which is used within the infrastructure for authentication and authorisation purposes, including access to applications and infrastructure within the Quant ecosystem.
G.8	Utility tokens redemption	The QNT token does not grant a right of redemption against the issuer. Holders of QNT are not entitled to exchange the token for fiat currency, other assets, or any specific goods or services at a guaranteed value or on demand. The token functions as an access mechanism to the Quant Overledger infrastructure and associated services. Its use is limited to enabling access to the infrastructure and facilitating interaction with its infrastructure. The acquisition of QNT therefore provides the ability to use services within the ecosystem, rather than a claim for redemption or reimbursement.
G.9	Non-trading request	TRUE
G.10	Crypto-assets purchase or sale modalities	Not applicable
G.11	Crypto-assets transfer restrictions	Not applicable
G.12	Supply adjustment protocols	FALSE
G.13	Supply adjustment mechanisms	Not applicable
G.14	Token value protection schemes	FALSE
G.15	Token value protection schemes description	Not applicable
G.16	Compensation schemes	FALSE
G.17	Compensation schemes description	Not applicable
G.18	Applicable law	There is no written legal agreement between the issuer and the crypto asset-holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.
G.19	Competent court	There is no written legal agreement between the issuer and the crypto asset-holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset-holder and the issuer. In the absence of such an agreement, the laws of the competent court will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

N	Field	Content
H.1	Distributed ledger technology	Not applicable as DTI is provided in F.13
H.2	Protocols and technical standards	Token standards QNT implements the ERC-20 token standard on Ethereum Mainnet, providing total supply, balance queries, transfer, transferFrom, approve, and allowance functions. The contract emits a Transfer event on each successful token transfer and an Approval event on each successful approval. Within the Fusion rollup, a QRC20 contract type compatible with ERC-20 is available for public smart contract deployments on the rollup. This is entirely separate from the Ethereum Mainnet QNT contract. No EIP-2612 permit or gasless approval standard is implemented in the Ethereum Mainnet QNT contract. Networking and transport QNT does not operate its own peer-to-peer network. Token transfers and approvals on Ethereum Mainnet are standard Ethereum transactions that propagate through Ethereum's execution-layer peer-to-peer network. Peer discovery runs over UDP using the discv5 protocol. The DevP2P stack, operating over TCP, uses the RLPx protocol for session initiation, authentication, and maintenance. Pending transactions are gossiped between execution-layer nodes so that block builders may select them for inclusion. In the Fusion rollup environment, Quant operates as the sequencer, collecting rollup transactions and building rollup blocks. The rollup is accessed through the Quant Fusion infrastructure. ETH JSON-RPC serves as the interface layer, meaning the rollup is compatible with the existing ecosystem of EVM-compatible tooling, including standard wallets and SDKs. Before JSON-RPC requests are proxied to rollup nodes, they are validated against the sequencer's access-control and permissioning rules. Serialisation ERC-20 specifies the token interface rather than a standalone serialisation scheme. It defines methods for total supply, balance queries, transfers, transferFrom, approve, and allowance, and requires Transfer and Approval events for the corresponding operations. Ethereum JSON-RPC encodes quantities as compact hexadecimal values prefixed with 0x; addresses, hashes, bytecode, and byte arrays follow the same convention, using two hexadecimal digits per byte. Cryptography and key formats Ethereum accounts use elliptic curve key pairs over the secp256k1 curve. A private key signs transactions, and the corresponding Ethereum address is derived by taking the last 20 bytes of the Keccak-256 hash of the uncompressed public key. QNT introduces no supplementary signature scheme beyond Ethereum's account-signing model. The token contract is a contract account whose behaviour is governed by the deployed code. Contract storage is encoded in a Merkle Patricia Trie whose root forms part of the account state, enabling cryptographic verification of stored data through the root hash alone. Ledger QNT token ownership is maintained as smart-contract state on Ethereum's account-based ledger. Balances are recorded in a storage mapping; a transfer subtracts from the sender's entry and adds to the recipient's. Approvals set an allowance value that a designated spender may draw down via the transferFrom function. The contract also implements increaseApproval and decreaseApproval functions for atomic allowance adjustments. No ownership-control mechanism or proxy upgrade pattern is present in the deployed contract. Execution Ethereum contract code executes on the Ethereum Virtual Machine when the contract account receives a message call. QNT transfers and approvals are Ethereum transactions containing a recipient address, nonce, value, function-call input data, and a gas limit. Execution clients validate and process these transactions before inclusion in a block. In the Fusion rollup, the Multi-Ledger Rollup extends the Optimism technology stack with an optimistic rollup model. New rollup blocks are assumed correct unless a fraud proof is submitted within the challenge window. State roots and transaction batches are distributed across connected blockchains for data availability, and users may exit the rollup without the sequencer's co-operation by posting on-chain proof of token ownership. Approvals and access controls The approve, allowance, transferFrom, increaseApproval, and decreaseApproval functions enable third parties to spend QNT on behalf of token holders, as required by exchanges, DeFi protocols, and custody integrations. Interaction with the Fusion rollup requires prior registration through Quant Connect, and KYC verification is mandatory for Mainnet rollup transactions. Contracts deployed on the rollup may be public, permissioned, or private; public contracts are subject to a whitelist maintained by Quant. These controls apply exclusively to the rollup environment and do not affect Ethereum Mainnet QNT transfers. External APIs Ethereum JSON-RPC enables external software to query the token contract, submit signed transactions, estimate gas, and retrieve receipts and event logs through any Ethereum-compatible node. Overledger provides an additional API layer during transaction preparation, returning gas, maxPriorityFeePerGas, and maxFeePerGas for Ethereum-based interactions. Fusion exposes rollup state, including balances, transaction history, and accessible contracts, through permissioned APIs and user interfaces rather than a traditional public block explorer, consistent with the rollup's access-control model.
H.3	Technology used	Implementation and architecture The Ethereum Mainnet QNT contract is a Solidity smart contract comprising five components: ERC20Basic, which defines the core token interface; SafeMath, a library providing arithmetic overflow and underflow protections; BasicToken, which inherits from ERC20Basic and uses SafeMath to implement total supply, balance queries, and token transfers; ERC20, which extends BasicToken with allowance, transferFrom, and approve interfaces; and StandardToken, which inherits from both ERC20 and BasicToken and adds increaseApproval and decreaseApproval functions, the token constants (name, symbol, decimals), a crowdsale address, and an onlyCrowdsale modifier restricting the mint function. Apart from its internal library use, the contract makes no external smart-contract calls. Quant Fusion is structured around two complementary layers. The Multi-Ledger Rollup supports execution and settlement across multiple Layer 1 blockchains, both permissionless and permissioned, within a single shared environment. The Network of Networks enables participants to integrate their own nodes and blockchain networks into the Fusion ecosystem, providing modular extensibility with embedded privacy and fine-grained access controls. Runtime and build parameters The QNT contract executes on the EVM. The Solidity pragma in the audited contract is ^0.4.21, which EtherAuthority flagged as an outdated version and recommended upgrading to above 0.8.7 for any future deployment. The Fusion rollup is also EVM-compatible, extending the Optimism technology stack under an optimistic rollup execution model. Dependencies The QNT contract uses the SafeMath library for arithmetic safety and ERC-20 standard interfaces for token interaction. These are industry-standard open-source components and are not used in external smart-contract calls. Fusion's cross-chain infrastructure relies on deposit contracts and message contracts deployed across connected chains for deposit and withdrawal workflows. Layer 2 proofing and data availability Fusion's Multi-Ledger Rollup uses an optimistic rollup model in which new rollup blocks are assumed correct unless challenged within the fault-proof window. State roots and transaction batches are distributed across connected blockchains for data availability. Deposits require token approval followed by a call to the deposit contract on the relevant Layer 1 chain. The contract validates the request, checks token whitelisting and the user's balance, locks the tokens, and issues a cross-chain message to effect the rollup transfer. When QNT is deposited, the user receives the rollup's native coin rather than an anchored ERC-20 representation; the native coin balance is read through the Ethereum eth_getBalance RPC method. Withdrawals follow a fault-proof-based exit mechanism requiring on-chain verification before assets are released on the Layer 1 chain. Deployment and addresses The audited Ethereum Mainnet QNT contract is deployed at 0x4a220e6096b25eadb88358cb44068a3248254675, reviewed from StandardToken.sol on 14 May 2024. Published testnet deposit contract addresses for the Fusion rollup are: on Ethereum Sepolia, 0xca7b5227a6983a1d5c5841df2e8edff12bf59deb; on Polygon Amoy, 0x4603d005f60d4f6a4ed54279274767d5f47d3b63; and on Quant's Besu private testnet, 0xe32ca85bee804c26ece4106c6bde609cc92a5e94. These are testnet addresses. The Fusion Mainnet is at the time of writing within a small number of months of launch; production deposit contract addresses have not yet been publicly documented. Client interfaces and SDKs QNT is accessible through any Ethereum-compatible JSON-RPC interface, supporting contract reads for balance and allowance queries, signed transaction submission for transfers and approvals, gas estimation, and event log retrieval. Overledger provides an API layer returning Ethereum fee estimation fields during transaction preparation. Fusion exposes rollup state through permissioned APIs and user interfaces for balances, transaction history, and accessible smart contracts.
H.4	Consensus Mechanism	QNT does not have an independent consensus mechanism. Transactions on Ethereum Mainnet are validated, ordered, and finalised through Ethereum's proof-of-stake consensus. Validators deposit 32 ETH into the Ethereum deposit contract to participate. Time is divided into 12-second slots grouped into 32-slot epochs; one validator is randomly selected as block proposer per slot, and a committee of validators attests to block validity. Validators receive rewards for correct attestations, block proposals, and participation in sync committees. Slashable offences, including proposing multiple blocks for the same slot or submitting conflicting attestations, result in partial burning of the validator's staked ETH and removal from the validator set. The Fusion rollup uses a sequencer model. Quant acts as the sequencer, collecting rollup transactions and building rollup blocks. Because the rollup uses an optimistic design, blocks are not individually verified by a committee; they are assumed correct unless a fraud proof is submitted. Users may exit the rollup independently by posting proof of token ownership on the relevant Layer 1 chain without requiring the sequencer's co-operation.
H.5	Incentive Mechanisms and Applicable Fees	Network-level fees QNT transfers on Ethereum Mainnet incur gas fees denominated in ETH. Gas measures computational effort; each transaction specifies a gas limit. The total fee comprises a base fee, which is burned upon block inclusion, and a priority fee paid to the block proposer as an incentive for inclusion. The base fee adjusts dynamically according to block occupancy relative to a target size. More complex contract interactions consume more gas than simple transfers. Overledger returns gas, maxPriorityFeePerGas, and maxFeePerGas during transaction preparation for Ethereum-based interactions. Protocol-level fees The QNT token contract imposes no transfer tax, buy tax, sell tax, or proxy-controlled fee mechanism. QNT functions as a utility token on the Overledger infrastructure; Overledger infrastructure fees may be paid in USD or through a QNT subscription, which is a infrastructure-level commercial arrangement distinct from Ethereum gas costs. Within Fusion, QNT deposited into the Multi-Ledger Rollup becomes the native coin used to pay for rollup transactions. Validator and node incentives Ethereum validator incentives are governed by the proof-of-stake protocol and are part of Ethereum's consensus layer, not the QNT token contract. Within Fusion, nodes permitted to participate in the sequencer and verifier infrastructure may earn QNT rewards, subject to a QNT staking requirement. The Fusion roadmap links QNT staking to node participation and QNT reward distribution; this applies to the Fusion infrastructure layer, not to QNT operations on Ethereum Mainnet. Governance of parameters Ethereum's base fee and gas limit are protocol parameters that are adjusted through validator signalling and network upgrades, thereby indirectly affecting the cost of QNT transactions. The QNT token contract has no proxy upgrade mechanism and no general ownership control. No publicly documented governance process exists for modifying QNT token parameters or upgrading the Ethereum Mainnet contract. The mint function is restricted to the crowdsale address; no evidence is publicly available confirming whether this minting path remains operationally active.
H.6	Use of distributed ledger technology	False
H.7	DLT functionality description	Not applicable
H.8	Audit	TRUE
H.9	Audit outcome	EtherAuthority \| 14 May 2024 — Quant Token Smart Contract Object: Code review and security analysis of the Quant Token smart contract (StandardToken.sol) deployed at 0x4a220e6096b25eadb88358cb44068a3248254675 on Ethereum. The review covered contract structure, ERC-20 interface compliance, the crowdsale minting function, SafeMath library integration, claimed token features, and business-risk characteristics. Automated analysis using Slither, Solhint, and Remix IDE was supplemented by manual critical review. Results: Zero critical, zero high, zero medium, and zero low severity vulnerabilities were identified. Seven informational findings were raised: (1) use of an outdated Solidity compiler version (pragma ^0.4.21); (2) implicit visibility on state variables; (3) missing error messages in require conditions within the onlyCrowdsale modifier and transfer functions; (4) centralised risk arising from the crowdsale-only mint path; (5) the totalSupply variable not declared constant; (6) an unbounded minting capability with no maximum supply cap; and (7) several functions — mint, transferFrom, approve, allowance, increaseApproval, and decreaseApproval — declared public rather than external, resulting in unnecessary gas overhead. The overall audit result was Passed with high auditor confidence. Actions: The audit recommends updating the Solidity compiler version to above 0.8.7, adding explicit visibility specifiers to state variables, including error messages in all require statements, renouncing or retiring the crowdsale mint path once its function is completed, adding minting limits or additional permission checks, declaring totalSupply as a constant, and redeclaring the listed public functions as external to improve gas efficiency. No public confirmation of remediation status has been published.

Part I - Information on risks

N	Field	Content
I.1	Offer-related risks	Market volatility and liquidity QNT's market price can fluctuate materially and liquidity can vary across trading venues and pairs. Periods of lower trading activity or limited order-book depth can widen bid-ask spreads and increase slippage, particularly for larger transactions. QNT is not redeemable against a fixed value by Quant or any other entity, and its market price may fall to zero. Large transaction and holder concentration risk QNT has a finite maximum supply of 14,881,364 tokens and a publicly visible holder base on Etherscan. Transfers by sizable holders, or large closely sequenced orders, can materially affect available liquidity and execution quality even without manipulative intent. Exchange access and service-access risk Access to QNT trading or QNT-linked services can be affected by venue policies, KYC requirements, territorial restrictions, sanctions controls, or rejection of orders. Quant may reject orders and restrict access where legal, regulatory, or contractual requirements are not met. Irreversibility and finality Once a QNT transfer is included in a finalised Ethereum block, it cannot be reverted or altered at the protocol level. Mistaken transfers resulting from phishing, incorrectly entered addresses, or social engineering cannot be recovered through any mechanism within the token contract or Ethereum's consensus rules. Market abuse QNT, like other publicly traded ERC-20 tokens, may be subject to market manipulation across fragmented trading venues, including front-running enabled by public mempool visibility, wash trading, spoofing, layering, and coordinated pump-and-dump activity. These risks may be amplified during periods of low order-book depth or when trading is concentrated across a small number of venues. Delisting Risks Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.
I.2	Issuer-related risks	Legal and contracting structure risk Quant-related services involve more than one Quant entity, including Quant Network Limited and Quant Network AG. Where QNT is used for services, the contracting entity can differ from the website operator, which can affect applicable rights, obligations, and governing-law analysis for users. Regulatory and compliance restriction risk Quant services are subject to sanctions, anti-money-laundering, anti-bribery, and criminal-law compliance controls. These controls can restrict access to Quant services, delay onboarding, or prevent transactions where compliance conditions are not satisfied. Suspension, throttling, and access discretion risk Quant may suspend, throttle, or disable access to its services for policy breaches, unpaid amounts, security issues, or other contractual grounds. API rate limits and access controls can affect service availability and transaction workflows dependent on Overledger or Quant Connect. Operational availability risk Quant services and documentation are made available on an as-is basis without warranty of uninterrupted or error-free access. Disruptions to Overledger, Quant Connect, or related infrastructure can affect users and developers relying on Quant services for QNT-related functionality. Data handling and privacy risk Quant may collect wallet addresses, account identifiers, device data, IP addresses, KYC data, and other personal information through Quant Connect and associated services. Personal data may be processed or transferred outside the UK and EEA, creating privacy, compliance, and operational risk for users of Quant services. Third-party service provider risk Quant relies on external providers for hosting and identity-checking functions. Amazon Web Services EMEA handles hosting services and Onfido handles identity checking and KYC; outages, policy changes, or processing failures at either provider can directly affect Quant service availability and onboarding capacity.
I.3	Crypto-assets-related risks	ERC-20 token dependency risk QNT's transferability, balance visibility, and application compatibility depend on Ethereum smart-contract execution and the ERC-20 interface implemented by the QNT contract. Any failure in the EVM execution environment or the QNT contract's core functions would directly impair token utility. Key custody and transfer error risk Control over QNT depends on correct transaction signing and secure management of wallet credentials. Loss, compromise, or misuse of private keys results in permanent loss of control over the associated QNT balance. No recovery mechanism exists within the Ethereum protocol or the QNT token contract. Sending QNT to an incorrect address, an unrecoverable contract address, or the zero address is irreversible. Utility and adoption dependency risk QNT's utility depends on continued adoption of the Overledger ecosystem and Quant Fusion. On Ethereum Mainnet, QNT is required for Overledger infrastructure access and licensing; within Fusion, it is designated as the native rollup coin for transaction payments and is intended to underpin node staking. A material reduction in ecosystem adoption, or a change to the fee or staking model, would reduce or remove these utility drivers. Rollup liquidity and withdrawal risk QNT deposited into the Fusion Multi-Ledger Rollup is transformed into the rollup's native coin. Holders using rollup functionality depend on the correct operation of rollup deposit, withdrawal, and state-recovery mechanisms. Withdrawals are subject to the Layer 1 finalisation period and the optimistic rollup challenge window before funds are released; in testnet conditions on Ethereum Sepolia this has been approximately 20 minutes, though Mainnet conditions may differ. Staking and node-reward risk QNT staking is intended to underpin nodes used by the rollup sequencer and verifiers. Nodes that are not continuously available may be removed from Fusion and staking rewards may be withheld. The current documentation does not describe a mechanism to slash or destroy staked QNT principal for node unavailability; reward withholding rather than principal loss is the described consequence. Changes to the staking design before or after Mainnet launch could alter this risk profile. Supply and mint-function risk The QNT contract includes a mint function callable exclusively by the crowdsale address. The total supply variable is not declared as a constant in the contract code, meaning additional tokens can in principle be minted if the crowdsale address retains its minting authority. No on-chain transaction or publicly documented mechanism confirms that the crowdsale address has renounced this authority or that a permanent maximum supply cap has been enforced at the contract level. The audited initial supply is 45,467,000 QNT, and the independent audit identified the absence of a minting limit as an informational finding. No live freeze, blacklist, kill-switch, or upgrade authority for the QNT Ethereum Mainnet contract is evidenced. Token transparency and audit-submission risk The QNT contract source code is verified as an exact match on Etherscan, supporting independent inspection of the deployed bytecode and ABI. However, no contract security audit is listed in Etherscan's audit-submission record for the QNT contract. An independent audit was conducted by EtherAuthority in May 2024, but it is not linked from Etherscan and may not be immediately visible to holders who rely on Etherscan's audit-submission record as a transparency indicator. Privacy and on-chain traceability risk All QNT transfers occur on a public Ethereum token contract and are permanently visible through Etherscan and other block explorers. Wallet addresses and transaction patterns can be analysed over time and may be correlated with personal data collected through Quant Connect and related services. Scam and fraud risk QNT, as a publicly listed ERC-20 token with significant market profile, may be targeted by fraudulent activity including: deployment of counterfeit tokens bearing the same or similar name on Ethereum or other networks; phishing attacks targeting QNT holders and Quant Connect users; impersonation of Quant Network through social media, email, or communications channels; and fake airdrop or promotional offers. All blockchain transactions are irreversible, and funds transferred to fraudulent addresses or contracts cannot be recovered through any protocol mechanism.
I.4	Project implementation-related risks	Roadmap and delivery risk Quant Fusion roadmap items are described as general guidelines subject to change according to business and legal requirements. Changes in Mainnet timing, staking configuration, supported network list, or release sequencing can affect expected QNT utility and ecosystem adoption without triggering contractual obligations to holders. Node provider and availability risk Fusion's network model initially relies on pre-selected node providers and requires nodes to remain continuously available. Provider selection constraints, node outages, or removal of unavailable nodes can reduce network resilience and affect QNT staking reward outcomes during early deployment phases. User interface and operational readiness risk Certain Fusion user-interface components and production-readiness activities have been under active development alongside Mainnet infrastructure hardening. Delays or defects in deposit, swap, or withdrawal interfaces can affect user access to rollup functionality, including the mechanism by which QNT becomes the rollup's native coin. Network and connector expansion risk Fusion is designed to support multiple distributed ledgers, blockchains, and user-connected networks. Expansion to additional public, private, or permissioned networks depends on connectors, Quant's review processes, and implementation work. Delays or scope changes in this expansion can affect the timing and breadth of QNT utility across supported chains. SDK and integration-maintenance risk Several official Overledger SDK repositories are archived and no longer maintained. Developers relying on archived SDKs or outdated integration examples may face compatibility, dependency, and maintenance risk unless they migrate to current Developer Hub materials. Transparency and observability timing risk Devnet contract-address publication was deferred during early testing. While Quant committed to logging addresses and timestamped transactions for later publication, deferred disclosure reduces immediate independent observability during early testing phases and may limit the ability of third parties to verify devnet activity at the time it occurs. Standards and external-process risk Secure Asset Exchange Protocol development depends in part on external standards processes. Delays or changes in treatment by relevant standards bodies can affect interoperability standardisation and implementation timelines for cross-chain withdrawal functionality.
I.5	Technology-related risks	Ethereum base-layer risk QNT inherits Ethereum base-layer risks as an ERC-20 token on Ethereum. Validator collusion, network partitioning, execution-client defects, transaction-inclusion delays, or failures in the finality mechanism can impair QNT transfer execution and settlement. A successful attack on Ethereum's finalised state would require an attacker to expose at least one-third of all staked ETH to slashing, representing a very high economic barrier; this risk cannot be fully eliminated. Ethereum client and validator software risk Ethereum validators operate three separate software components: an execution client, a consensus client, and a validator client. Defects, version divergence, or correlated failures across those components can impair transaction processing, block validation, or network liveness. Smart-contract and ERC-20 implementation risk The QNT contract is compiled with Solidity v0.4.21, a version predating numerous security improvements, EIP implementations, and compiler-level protections introduced in subsequent releases. While the independent EtherAuthority audit found no critical, high, medium, or low severity vulnerabilities in the deployed contract, the use of an outdated compiler version increases the theoretical attack surface relative to contracts compiled with current Solidity releases.Smart-contract flaws, hacks, and protocol changes are identified as events that can create a risk of total loss. Fusion rollup design risk Fusion extends the Optimism technology stack under an optimistic rollup model. Rollup functionality depends on correct transaction sequencing, batch data publication, fraud-proof submission, and withdrawal processing across all connected networks. Defects in any of these components could delay settlement, block withdrawals, or produce incorrect state transitions, affecting QNT holders using the rollup environment. Sequencer concentration risk Quant will act as the sole sequencer of the Multi-Ledger Rollup, controlling transaction ordering and rollup block construction. This creates dependency on Quant's operational continuity for rollup liveness. Sequencer failure, censorship, or extended downtime would prevent new rollup transactions from being processed. Users may exit the rollup to Layer 1 by posting a fault-proof without the sequencer's agreement, but this withdrawal path is subject to the challenge window delay and requires a correctly functioning Layer 1 proof mechanism. Upgradeable-contract and admin-hook risk The Ethereum Mainnet QNT token contract has no proxy pattern and no upgrade mechanism in its deployed code. However, Fusion Firewall smart contracts employed during the devnet phase used upgradeable proxy patterns for rapid iteration. Quant has stated these are intended to be non-upgradeable once live on Mainnet. Full documentation of Mainnet-specific pause, freeze, or kill-switch controls for Fusion infrastructure has not been published in available sources; the deployed Mainnet rollup contract configuration may differ from the devnet model. Access-control and permissioning risk Fusion and Quant Connect apply access controls, KYC requirements, and smart-contract permission categories (public, permissioned, and private). These controls can reduce the on-chain attack surface but may also restrict composability, limit interaction with non-whitelisted contracts, and create dependency on correct permission configuration by Quant. Changes to whitelisting or permissioning rules could affect the accessibility or usability of QNT within the rollup environment. Node and connector-layer risk Fusion routes API requests through nodes and connectors to connected distributed ledgers. Faulty nodes, connector errors, or inconsistent responses across nodes can affect transaction routing, gas-price estimation, data accuracy, and service continuity for QNT-related rollup interactions. Interoperability and withdrawal-route risk Fusion supports withdrawals through Optimism-based routes and Secure Asset Exchange Protocol instant-withdrawal functionality. Errors in cross-ledger message handling or withdrawal-route implementations could delay, block, or misroute assets across supported networks, including QNT transferred between the rollup and connected Layer 1 chains. Explorer and state-observability risk Quant does not intend to support a traditional public block explorer for the Multi-Ledger Rollup. Holders and developers rely on permissioned APIs and user interfaces for rollup balances, transaction histories, and accessible smart contracts, which limits independent verification of rollup state compared to a public block explorer and creates dependence on Quant's API availability.
I.6	Mitigation measures	Offer-Related Risks Exchange access and service-access risk: Order-rejection controls, KYC requirements, and territorial access restrictions are applied before granting or continuing access to Quant services. An identified third-party provider supports compliance screening, providing a structured mechanism for reducing unlawful-use and sanctions exposure at the point of service access. Irreversibility and finality: Ethereum's proof-of-stake finality mechanism provides deterministic settlement certainty: reverting transactions in a finalised epoch would require an attacker to expose at least one-third of all staked ETH to slashing. This creates a high economic barrier to chain reorganisation, supporting reliable settlement for confirmed QNT transfers. Issuer-Related Risks Regulatory and compliance restriction risk: Quant's compliance requirements, including applicable sanctions regimes, AML/KYC conditions, and territorial restrictions, are set out in its publicly available terms of service, enabling prospective users to assess their eligibility before initiating onboarding. Identity verification is conducted through Onfido, a regulated third-party provider operating under standardised procedures, which reduces the risk of inconsistent or arbitrary access decisions. These measures do not eliminate the risk that applicable regulations may restrict or prevent access for certain users. They reduce the risk of that outcome occurring through unexpected, undisclosed, or poorly administered compliance processes. Suspension, throttling, and access discretion risk: The contractual framework specifying the conditions under which suspension, throttling, or rate limiting may be applied is published in Quant's terms of service, giving users and developers advance notice of the applicable rules before they rely on service access. Data handling and privacy risk: Encryption and need-to-know staff access controls are applied to personal data held by Quant, and breach-response procedures are maintained. These measures reduce the risk of unauthorised disclosure, though they do not remove the risk arising from the permanent visibility of QNT activity on the public Ethereum blockchain. Crypto-Assets-Related Risks Token transparency and audit-submission risk: The QNT token contract source code is verified as an exact match on Etherscan, enabling independent inspection of the deployed code and ABI. An independent security audit conducted by EtherAuthority in May 2024 found no critical, high, medium, or low severity vulnerabilities and was published as supporting documentation for this white paper. This provides a documented security baseline for the current contract, though it does not eliminate future implementation or integration risk. Rollup liquidity and withdrawal risk: Users may withdraw QNT from the Multi-Ledger Rollup to the connected Layer 1 chain without the sequencer's agreement by posting on-chain proof of token ownership. This mechanism, derived from the Optimism fault-proof architecture, reduces custodial dependence on the sequencer for withdrawal rights where the proof and challenge mechanisms function correctly. Staking and node-reward risk: Quant may remove nodes from the Fusion system and withhold staking rewards from operators that fail to maintain continuous availability. This creates an operational incentive for node operators without relying on confiscation of staked principal in the current documented design. Project Implementation-Related Risks Roadmap and delivery risk: Changes to the Fusion roadmap are tracked and documented, including the reasons for each change, providing an auditable trail of delivery decisions for Fusion participants and QNT holders. Node provider and availability risk: The Bring Your Own Node capability, available to Quant Connect users, allows participants to connect their own nodes to Fusion. This adds node distribution beyond the initial pre-selected provider set and progressively reduces single-provider dependency as network participation grows. User interface and operational readiness risk: Fusion features are validated on testnet before Mainnet release, and staking configuration is to be trialled on testnet prior to finalisation. This approach reduces the risk of untested implementations reaching the production environment. SDK and integration-maintenance risk: Archived SDK repositories direct developers to the current Developer Hub API reference materials for up-to-date integration examples, providing a documented migration path from deprecated packages to maintained resources. Technology-Related Risks Smart-contract and ERC-20 implementation risk: The EtherAuthority audit of May 2024 reviewed the deployed QNT contract and found no critical, high, medium, or low severity vulnerabilities. The contract source code is verified on Etherscan, enabling independent inspection of the deployed bytecode. These measures provide a documented security baseline for the current contract but do not eliminate residual risk from the outdated compiler version or future attack vectors. Fusion rollup design risk: Key rollup data, including state roots and transaction batches, is distributed publicly across connected blockchains, enabling state verification and recovery from publicly available data independently of any single data source. Sequencer concentration risk: Users may withdraw QNT from the rollup to a connected Layer 1 chain without the sequencer's agreement by submitting a fault-proof on-chain. This mechanism, when correctly implemented, allows rollup exit to proceed independently of sequencer availability or co-operation. Upgradeable-contract and admin-hook risk: The Ethereum Mainnet QNT token contract has no proxy pattern or upgrade mechanism in its deployed code. Fusion Firewall smart contracts are intended to be non-upgradeable once live on Mainnet, with upgradeability having been used only for rapid iteration during the devnet testing phase. Access-control and permissioning risk: The Fusion whitelist system restricts public contract deployments to approved implementations, reducing the on-chain attack surface for rollup interactions. Public, permissioned, and private contract categories allow appropriate access scoping for different deployment contexts. Node and connector-layer risk: Fusion can aggregate responses from multiple nodes and allows participants to connect their own nodes through the Bring Your Own Node capability, supporting resilience and reducing reliance on any single node response path for connected network interactions. Interoperability and withdrawal-route risk: Withdrawal routes have been tested across QNT, unified tokens, and single-chain tokens through Optimism-based routes and Secure Asset Exchange Protocol instant-withdrawal testing. This testing provides a documented validation baseline for the current withdrawal paths before Mainnet deployment.

General information	Page 3
Part A - Information about the offeror or the person seeking admission to trading	Page 4
Part B - Information about the issuer, if different from the offeror or person seeking admission to trading	Page 5
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	Page 6
Part D - Information about the crypto-asset project	Page 7
Part E - Information about the offer to the public of crypto-assets or their admission to trading	Page 8
Part F - Information about the crypto-assets	Page 9
Part G - Information on the rights and obligations attached to the crypto-assets	Page 10
Part H – Information on underlying technology	Page 11
Part I - Information on risks	Page 12
Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts	Page 13

Index

General information

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

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

Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114

Part D - Information about the crypto-asset project

Part E - Information about the offer to the public of crypto-assets or their admission to trading

Part F - Information about the crypto-assets

Part G - Information on the rights and obligations attached to the crypto-assets

Part H – Information on 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